* RE: i2c device for a linux 2.6 in XUPV2P
From: Stephen Neuendorffer @ 2008-01-09 17:52 UTC (permalink / raw)
To: Josep Maria Batlle, linuxppc-embedded; +Cc: git
In-Reply-To: <ef1737dc0712241327t3cc7c14kcb91e9a4e550df18@mail.gmail.com>
Yes, it should be possible, however I don't believe the Linux adapter
for the i2c driver has been updated for current 2.6 kernel versions.
It's not currently on git.xilinx.com, and apparently the i2c subsystem
has changed significantly since the adapter was written, so it's not a
straightforward update.
If all you want to do is some simple configuration, then bitbanging the
i2c is straightforward. I'll send you a driver that I cooked up at one
point in a separate email.
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Josep =
Maria
Batlle
> Sent: Monday, December 24, 2007 1:27 PM
> To: linuxppc-embedded@ozlabs.org
> Subject: i2c device for a linux 2.6 in XUPV2P
>=20
> Hi all,
>=20
> I have booted up linux 2.6 on Xilinx XUPV2P (using the base of ml300
config file).
> Now I am trying to use the i2c in the user-space. First of all: is it
possible?
>=20
> My first attempts have not worked. I have made this:
> 1) I enable "I2C Support" and "I2C device interface" in the kernel
recompilation.
> 2) I added the "i2c-0" device in /dev (# mknod i2c-0 c 89 0)
> 3) then I run a simple program to open the device (provided by the
"dev-interface" file of i2c kernel
> documentation) that returns this errno message: "No such device".
>=20
> I have tried to use the device number 1, 2, 3, 4 but these have not
worked. I have tried to use the
> device "i2cn" but not worked. I have tried to use all the BSP's from
the EDK (7.1i) and then only the
> "xparameters_ml300.h" in the compilation. After all of this, now I am
modifying the RFS for "mdev"...
> Somebody can tell me what I am doing wrong if this use is possible?
>=20
> I use the kernel tree "virtex-for-2.6.24" from SecretLab and Busybox
1.7.2.
>=20
> Thanks.
^ permalink raw reply
* [PATCH] Kconfig scsi_wait_scan
From: Sean MacLennan @ 2008-01-09 17:44 UTC (permalink / raw)
To: langa2; +Cc: linuxppc-dev
Michael,
I find I need to add a string to the SCSI_WAIT_SCAN tristate in order to
be able to turn the module off. See the patch below. On our embedded
appliance the only use for SCSI is for the usb_storage driver.
Cheers,
Sean MacLennan
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index a6676be..960dc78 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -248,7 +248,7 @@ config SCSI_SCAN_ASYNC
or async on the kernel's command line.
config SCSI_WAIT_SCAN
- tristate
+ tristate "SCSI wait scan"
default m
depends on SCSI
depends on MODULES
^ permalink raw reply related
* Re: [RFC] add phy-handle property for fec_mpc52xx
From: Matt Sealey @ 2008-01-09 17:44 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, olaf
In-Reply-To: <20080109171849.GC6789@powerlinux.fr>
Sven Luther wrote:
> This is crazy, and not future proof. The way Grant did it, checking for
> the existence of the node before creating is enough for any reasonable
> upgrade to the firmware.
>
> If future firmware will break with this, then they will break other
> stuff anyway, and a new patch is needed.
In other words, Grant's method is crazy and not future-proof, too.
I don't see the difference, Sven, and this demonstrates entirely
>> Just make sure it's less than.. let's say, a certain version of efika.forth,
>> and I will roll a version which has a higher version and some extra features
>> like CAN/I2C exposure.
>>
>> If you run efika.forth it will not touch the device tree. If you don't, it
>> will add the small amount of patches. Add a huge comment that this hunk of
>> code should be scheduled for deletion at some later date. Put a Kconfig
>> around it so it can be taken out, even, at distro option.
>
> Have you not read Grant's code ? It create the nodes only if they are
> not existent already.
What if they ARE existant under other names, you will have two ethernet-phy
in the system, maybe with the same name, and this is stupid. What if it adds
the wrong properties if we work out something is wrong somewhere?
Linux prom_init must not be a moving target for firmware development - it is
the hardest thing to replace (it is not like loading and unloading a module)
and it may in fact be polluting valid device trees REGARDLESS of any checks
you might make. You cannot make Linux try and PREDICT how the device tree
looks based on arbitrary name strings, because Linux device tree usage does
not comply with the IEEE 1275-1994 definition of device tree properties.
Grant's patch should look for a compatible property with "ethernet-phy" in
it, check for phy-handle in the ethernet node, make sure that a node very
similar to mdio does not already exist, etc, it is going into a screen of
code to do it comprehensively and future proof.
Just don't do it at all. The burden is on Genesi. So, it's difficult right
now, and hard for users, so what? That's OUR problem, I dare say today it
is MY problem. I do not want this to become a LINUX problem in the future
when a new board comes out that is Efika-compatible, requiring patch
removal, reshuffling, compliance testing etc.
You do realise any new firmware with this kernel needs to work, regardless
of the patch being present, in order to be validated? We can't ship an
Efika board with a firmware which actively breaks because of a Linux
kernel patch for older boards and some ancient bad decision, and saying
"to use a new Efika you must use a brand new Linux kernel" is the kind of
insanity in embedded development which made us choose SmartFirmware over
U-Boot and FDT in the first place..
I am not happy that we are being dragged into this model of playing
"first to mainline" with arbitrary snippets of code which do NOT improve
things in the long term.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: Linux for ml310
From: Joachim Meyer @ 2008-01-09 17:29 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
Hi again
In which xparams* files should i look for the right definition=3F
In the xparameters.h from the BSP I can't find it, it looks like this:
-------------------------------------------------------------------
/*
* include/asm-ppc/xparameters.h
*
* This file includes the correct xparameters.h for the CONFIG'ed board
*
* Author: MontaVista Software, Inc.
* source@mvista.com
*
* 2004 (c) MontaVista Software, Inc. This file is licensed under the ter=
ms
* of the GNU General Public License version 2. This program is licensed
* "as is" without any warranty of any kind, whether express or implied.
*/
#include <linux/config.h>
#if defined(CONFIG=5FXILINX=5FML300)
#include <platforms/4xx/xparameters/xparameters=5Fml300.h>
#endif
#if defined(CONFIG=5FXILINX=5FML40x)
#include <platforms/4xx/xparameters/xparameters=5Fml40x.h>
#endif
#if defined(CONFIG=5FMEMEC=5F2VPX)
#include <platforms/4xx/xparameters/xparameters=5F2vpx.h>
#endif
/*
* A few reasonable defaults for the #defines which could be missing depen=
ding
* on the IP version or variant (e.g. OPB vs PLB)
*/
#ifndef XPAR=5FEMAC=5F0=5FCAM=5FEXIST
#define XPAR=5FEMAC=5F0=5FCAM=5FEXIST 0
#endif
#ifndef XPAR=5FEMAC=5F0=5FJUMBO=5FEXIST
#define XPAR=5FEMAC=5F0=5FJUMBO=5FEXIST 0
#endif
#ifndef XPAR=5FEMAC=5F0=5FTX=5FDRE=5FTYPE
#define XPAR=5FEMAC=5F0=5FTX=5FDRE=5FTYPE 0
#endif
#ifndef XPAR=5FEMAC=5F0=5FRX=5FDRE=5FTYPE
#define XPAR=5FEMAC=5F0=5FRX=5FDRE=5FTYPE 0
#endif
#ifndef XPAR=5FEMAC=5F0=5FTX=5FINCLUDE=5FCSUM
#define XPAR=5FEMAC=5F0=5FTX=5FINCLUDE=5FCSUM 0
#endif
#ifndef XPAR=5FEMAC=5F0=5FRX=5FINCLUDE=5FCSUM
#define XPAR=5FEMAC=5F0=5FRX=5FINCLUDE=5FCSUM 0
#endif
#ifndef XPAR=5FEMAC=5F1=5FCAM=5FEXIST
#define XPAR=5FEMAC=5F1=5FCAM=5FEXIST 0
#endif
#ifndef XPAR=5FEMAC=5F1=5FJUMBO=5FEXIST
#define XPAR=5FEMAC=5F1=5FJUMBO=5FEXIST 0
#endif
#ifndef XPAR=5FEMAC=5F1=5FTX=5FDRE=5FTYPE
#define XPAR=5FEMAC=5F1=5FTX=5FDRE=5FTYPE 0
#endif
#ifndef XPAR=5FEMAC=5F1=5FRX=5FDRE=5FTYPE
#define XPAR=5FEMAC=5F1=5FRX=5FDRE=5FTYPE 0
#endif
#ifndef XPAR=5FEMAC=5F1=5FTX=5FINCLUDE=5FCSUM
#define XPAR=5FEMAC=5F1=5FTX=5FINCLUDE=5FCSUM 0
#endif
#ifndef XPAR=5FEMAC=5F1=5FRX=5FINCLUDE=5FCSUM
#define XPAR=5FEMAC=5F1=5FRX=5FINCLUDE=5FCSUM 0
#endif
#ifndef XPAR=5FGPIO=5F0=5FIS=5FDUAL
#define XPAR=5FGPIO=5F0=5FIS=5FDUAL 0
#endif
#ifndef XPAR=5FGPIO=5F1=5FIS=5FDUAL
#define XPAR=5FGPIO=5F1=5FIS=5FDUAL 0
#endif
#ifndef XPAR=5FGPIO=5F2=5FIS=5FDUAL
#define XPAR=5FGPIO=5F2=5FIS=5FDUAL 0
#endif
#ifndef XPAR=5FGPIO=5F3=5FIS=5FDUAL
#define XPAR=5FGPIO=5F3=5FIS=5FDUAL 0
#endif
#ifndef XPAR=5FGPIO=5F4=5FIS=5FDUAL
#define XPAR=5FGPIO=5F4=5FIS=5FDUAL 0
#endif
----------------------------------------------------
Did I something wrong in the edk Projekt, or are there other xparameters w=
here I must look=3F
Greetings & THX
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Jetzt neu! Sch=FCtzen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/=3Fmc=3D022220
^ permalink raw reply
* [PATCH] [POWERPC] Fix handling of memreserve if the range lands in highmem
From: Kumar Gala @ 2008-01-09 17:28 UTC (permalink / raw)
To: linuxppc-dev
There were several issues if a memreserve range existed and happened
to be in highmem:
* The bootmem allocator is only aware of lowmem so calling
reserve_bootmem with a highmem address would cause a BUG_ON
* All highmem pages were provided to the buddy allocator
Added a lmb_is_reserved() api that we now use to determine if a highem
page should continue to be PageReserved or provided to the buddy
allocator.
Also, we incorrectly reported the amount of pages reserved since all
highmem pages are initally marked reserved and we clear the
PageReserved flag as we "free" up the highmem pages.
---
As normal, posted here for review, will be pushed via my for-2.6.25 branch
arch/powerpc/mm/lmb.c | 13 +++++++++++++
arch/powerpc/mm/mem.c | 14 ++++++++++----
include/asm-powerpc/lmb.h | 1 +
3 files changed, 24 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/lmb.c b/arch/powerpc/mm/lmb.c
index 8f4d2dc..4ce23bc 100644
--- a/arch/powerpc/mm/lmb.c
+++ b/arch/powerpc/mm/lmb.c
@@ -342,3 +342,16 @@ void __init lmb_enforce_memory_limit(unsigned long memory_limit)
}
}
}
+
+int __init lmb_is_reserved(unsigned long addr)
+{
+ int i;
+
+ for (i = 0; i < lmb.reserved.cnt; i++) {
+ unsigned long upper = lmb.reserved.region[i].base +
+ lmb.reserved.region[i].size - 1;
+ if ((addr >= lmb.reserved.region[i].base) && (addr <= upper))
+ return 1;
+ }
+ return 0;
+}
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 5402fb6..a004032 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -218,9 +218,13 @@ void __init do_init_bootmem(void)
#endif
/* reserve the sections we're already using */
- for (i = 0; i < lmb.reserved.cnt; i++)
- reserve_bootmem(lmb.reserved.region[i].base,
- lmb_size_bytes(&lmb.reserved, i));
+ for (i = 0; i < lmb.reserved.cnt; i++) {
+ unsigned long addr = lmb.reserved.region[i].base +
+ lmb_size_bytes(&lmb.reserved, i) - 1;
+ if (addr < total_lowmem)
+ reserve_bootmem(lmb.reserved.region[i].base,
+ lmb_size_bytes(&lmb.reserved, i));
+ }
/* XXX need to clip this if using highmem? */
sparse_memory_present_with_active_regions(0);
@@ -334,11 +338,13 @@ void __init mem_init(void)
highmem_mapnr = total_lowmem >> PAGE_SHIFT;
for (pfn = highmem_mapnr; pfn < max_mapnr; ++pfn) {
struct page *page = pfn_to_page(pfn);
-
+ if (lmb_is_reserved(pfn << PAGE_SHIFT))
+ continue;
ClearPageReserved(page);
init_page_count(page);
__free_page(page);
totalhigh_pages++;
+ reservedpages--;
}
totalram_pages += totalhigh_pages;
printk(KERN_DEBUG "High memory: %luk\n",
diff --git a/include/asm-powerpc/lmb.h b/include/asm-powerpc/lmb.h
index b5f9f4c..5d1dc48 100644
--- a/include/asm-powerpc/lmb.h
+++ b/include/asm-powerpc/lmb.h
@@ -51,6 +51,7 @@ extern unsigned long __init __lmb_alloc_base(unsigned long size,
extern unsigned long __init lmb_phys_mem_size(void);
extern unsigned long __init lmb_end_of_DRAM(void);
extern void __init lmb_enforce_memory_limit(unsigned long memory_limit);
+extern int __init lmb_is_reserved(unsigned long addr);
extern void lmb_dump_all(void);
--
1.5.3.7
^ permalink raw reply related
* Re: Base Warp Platform support
From: Sean MacLennan @ 2008-01-09 17:30 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4783C7DD.1050202@pikatech.com>
So no comments? I got it perfect the first time :D
Cheers,
Sean
^ permalink raw reply
* Re: [PATCH] Miscellaneous for Taco
From: Sean MacLennan @ 2008-01-09 17:26 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200801082023.11475.sr@denx.de>
Stefan Roese wrote:
> On Tuesday 08 January 2008, Sean MacLennan wrote:
>
>> How about just 44x?
>>
>> Cheers,
>> Sean
>>
>> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
>> index 7580aa5..682deae 100644
>> --- a/drivers/usb/Kconfig
>> +++ b/drivers/usb/Kconfig
>> @@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI
>> # PPC:
>> default y if STB03xxx
>> default y if PPC_MPC52xx
>> + default y if 44x
>>
>
> No. Not all 44x have OHCI built in. Currently 440EP, 440EPx and 405EZ have it.
> But since your patch only touches 440EP, you should just enable OHCI for
> exactly this platform.
>
> Best regards,
> Stefan
>
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
index 7580aa5..2660f30 100644
--- a/drivers/usb/Kconfig
+++ b/drivers/usb/Kconfig
@@ -39,6 +39,7 @@ config USB_ARCH_HAS_OHCI
# PPC:
default y if STB03xxx
default y if PPC_MPC52xx
+ default y if 440EP
# MIPS:
default y if SOC_AU1X00
# more:
^ permalink raw reply related
* Re: add phy-handle property for fec_mpc52xx
From: Sven Luther @ 2008-01-09 17:22 UTC (permalink / raw)
To: Matt Sealey; +Cc: Sven Luther, Olaf Hering, linuxppc-dev
In-Reply-To: <478501C0.9040905@genesi-usa.com>
On Wed, Jan 09, 2008 at 05:17:52PM +0000, Matt Sealey wrote:
>
> Sven Luther wrote:
> >On Wed, Jan 09, 2008 at 04:36:19PM +0000, Matt Sealey wrote:
> >>The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is*
> >>the upstream support for now. What his patch does is say, the upstream
> >>support exists, but we don't like it, so we will supplement the patch..
> >
> >Matt, your work on efika.forth is laudable, and it is nice that you took
> >the time to support it.
> >
> >*BUT* it is not acceptable for a distribution, or for someone who will
> >have to do user support, to have to launch a second binary before
> >launching the kernel. Especially when netbooting for example.
>
> Then I think you are all missing the fact that I said there *IS A REALLY
> CUTE WAY OF INSTALLING IT ONCE* by uploading it into nvramrc, it will not
> be a runnable script, but executed on boot, because it'll be flashed into
> nvramrc.
>
> However I don't have the time to go into making this app, creating the
> tools to munge efika.forth into a correct more uploadable format, and
> creating the install tool. I barely have enough time to track this list
> and make sure any drivers requiring firmware tree changes are taken care
> of (I definitely lost the plot with the USB one, I haven't even checked
> it even though I was asked to 2 weeks ago..)
>
> Unfortunately one guy who already has a significant amount of work to do
> all day, who is not the responsible person for firmware issues, and is
> not being assisted by anyone in the community either generated and
> maintained by Genesi or existing around Linux, poses some serious problems
> with timeliness of updates.
>
> If anyone wants to stop patching Linux and instead make efika.forth easier
> to use, feel free, REALLY. Sven, are you volunteering for this REALLY
> tiny task? It will probably take all of a day for a couple of guys to
> work up the tools to do it based on very simple instructions and data
> provided.. the work is probably worth the price of a pizza, so no
> contracts are going to be worked out for it.
Just fix it conditionally in linux, like it is being proposed, and
everyone is happy :)
Friendly,
Sven Luther
^ permalink raw reply
* [PATCH] ad7414 driver
From: Sean MacLennan @ 2008-01-09 17:21 UTC (permalink / raw)
To: mhoffman; +Cc: linuxppc-dev, Stefan Roese
Mark,
This patch adds a driver for the ad7414 chip. It was written by Stefan
Roese based on the ad7418 driver. All I did was get it compiling under
the newer kernels.
Cheers,
Sean MacLennan
Signed-off-by: Stefan Roese <sr@denx.de>
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index a0445be..f14972a 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -57,6 +57,16 @@ config SENSORS_ABITUGURU3
This driver can also be built as a module. If so, the module
will be called abituguru3.
+config SENSORS_AD7414
+ tristate "Analog Devices AD7414"
+ depends on I2C && EXPERIMENTAL
+ help
+ If you say yes here you get support for the Analog Devices
+ AD7414 temperature monitoring chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called ad7414.
+
config SENSORS_AD7418
tristate "Analog Devices AD7416, AD7417 and AD7418"
depends on I2C && EXPERIMENTAL
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 55595f6..fa6066e 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_SENSORS_W83791D) += w83791d.o
obj-$(CONFIG_SENSORS_ABITUGURU) += abituguru.o
obj-$(CONFIG_SENSORS_ABITUGURU3)+= abituguru3.o
+obj-$(CONFIG_SENSORS_AD7414) += ad7414.o
obj-$(CONFIG_SENSORS_AD7418) += ad7418.o
obj-$(CONFIG_SENSORS_ADM1021) += adm1021.o
obj-$(CONFIG_SENSORS_ADM1025) += adm1025.o
@@ -72,4 +73,3 @@ obj-$(CONFIG_SENSORS_W83L785TS) += w83l785ts.o
ifeq ($(CONFIG_HWMON_DEBUG_CHIP),y)
EXTRA_CFLAGS += -DDEBUG
endif
-
--- /dev/null 2005-11-20 22:22:37.000000000 -0500
+++ drivers/hwmon/ad7414.c 2008-01-09 12:09:51.000000000 -0500
@@ -0,0 +1,322 @@
+/*
+ * An hwmon driver for the Analog Devices AD7414
+ *
+ * Copyright 2006 Stefan Roese <sr@denx.de>, DENX Software Engineering
+ *
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
+ * Based on ad7418.c
+ * Copyright 2006 Tower Technologies, Alessandro Zummo <a.zummo@towertech.it>
+ *
+ * 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.
+ */
+
+#include <linux/module.h>
+#include <linux/jiffies.h>
+#include <linux/i2c.h>
+#include <linux/hwmon.h>
+#include <linux/err.h>
+#include <linux/mutex.h>
+#include <linux/delay.h>
+
+
+#define DRV_VERSION "0.2"
+
+/* straight from the datasheet */
+#define AD7414_TEMP_MIN (-55000)
+#define AD7414_TEMP_MAX 125000
+
+/* Addresses to scan */
+static unsigned short normal_i2c[] = { 0x48, 0x4a, I2C_CLIENT_END };
+
+/* Insmod parameters */
+I2C_CLIENT_INSMOD;
+
+/* AD7414 registers */
+#define AD7414_REG_TEMP 0x00
+#define AD7414_REG_CONF 0x01
+#define AD7414_REG_T_HIGH 0x02
+#define AD7414_REG_T_LOW 0x03
+
+struct ad7414_data {
+ struct i2c_client client;
+ struct device *dev;
+ struct mutex lock;
+ char valid; /* !=0 if following fields are valid */
+ unsigned long last_updated; /* In jiffies */
+ u16 temp_input; /* Register values */
+ u8 temp_max;
+ u8 temp_min;
+ u8 temp_alert;
+ u8 temp_max_flag;
+ u8 temp_min_flag;
+};
+
+
+struct ad7414_dev {
+ struct list_head list;
+ struct device *dev;
+};
+
+static LIST_HEAD(ad7414_dev_list);
+
+
+static int ad7414_attach_adapter(struct i2c_adapter *adapter);
+static int ad7414_detect(struct i2c_adapter *adapter, int address, int kind);
+static int ad7414_detach_client(struct i2c_client *client);
+
+static struct i2c_driver ad7414_driver = {
+ .driver = {
+ .name = "ad7414",
+ },
+ .attach_adapter = ad7414_attach_adapter,
+ .detach_client = ad7414_detach_client,
+};
+
+/*
+ * TEMP: 0.001C/bit (-55C to +125C)
+ * REG: (0.5C/bit, two's complement) << 7
+ */
+static inline int AD7414_TEMP_FROM_REG(u16 reg)
+{
+ /* use integer division instead of equivalent right shift to
+ * guarantee arithmetic shift and preserve the sign
+ */
+ return ((s16)reg / 128) * 500;
+}
+
+/* All registers are word-sized, except for the configuration registers.
+ * AD7414 uses a high-byte first convention, which is exactly opposite to
+ * the usual practice.
+ */
+static int ad7414_read(struct i2c_client *client, u8 reg)
+{
+ if (reg == AD7414_REG_TEMP)
+ return swab16(i2c_smbus_read_word_data(client, reg));
+ else
+ return i2c_smbus_read_byte_data(client, reg);
+}
+
+static int ad7414_write(struct i2c_client *client, u8 reg, u16 value)
+{
+ return i2c_smbus_write_byte_data(client, reg, value);
+}
+
+static void ad7414_init_client(struct i2c_client *client)
+{
+ struct ad7414_dev *new;
+
+ new = kzalloc(sizeof(*new), GFP_KERNEL);
+ if(new == NULL)
+ printk(KERN_ERR "ad7414_init_client: Unable to allocate memory\n");
+ else {
+ new->dev = &client->dev;
+ list_add_tail(&new->list, &ad7414_dev_list);
+ }
+}
+
+static struct ad7414_data *ad7414_update_device(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct ad7414_data *data = i2c_get_clientdata(client);
+
+ mutex_lock(&data->lock);
+
+ if (time_after(jiffies, data->last_updated + HZ + HZ / 2)
+ || !data->valid) {
+ dev_dbg(&client->dev, "starting ad7414 update\n");
+
+ data->temp_input = ad7414_read(client, AD7414_REG_TEMP);
+ data->temp_alert = (data->temp_input >> 5) & 0x01;
+ data->temp_max_flag = (data->temp_input >> 4) & 0x01;
+ data->temp_min_flag = (data->temp_input >> 3) & 0x01;
+ data->temp_max = ad7414_read(client, AD7414_REG_T_HIGH);
+ data->temp_min = ad7414_read(client, AD7414_REG_T_LOW);
+
+ data->last_updated = jiffies;
+ data->valid = 1;
+ }
+
+ mutex_unlock(&data->lock);
+
+ return data;
+}
+
+int ad7414_get_temp(int index)
+{
+ struct ad7414_dev *dev;
+
+ list_for_each_entry(dev, &ad7414_dev_list, list) {
+ if(index <= 0) {
+ struct ad7414_data *data = ad7414_update_device(dev->dev);
+ return data->temp_input;
+ }
+ --index;
+ }
+
+ return 0x1f4; /* +125 */
+}
+EXPORT_SYMBOL(ad7414_get_temp);
+
+#define show(value) \
+static ssize_t show_##value(struct device *dev, struct device_attribute *attr, char *buf) \
+{ \
+ struct ad7414_data *data = ad7414_update_device(dev); \
+ return sprintf(buf, "%d\n", AD7414_TEMP_FROM_REG(data->value)); \
+}
+show(temp_input);
+
+#define show_8(value) \
+static ssize_t show_##value(struct device *dev, struct device_attribute *attr, char *buf) \
+{ \
+ struct ad7414_data *data = ad7414_update_device(dev); \
+ return sprintf(buf, "%d\n", data->value); \
+}
+show_8(temp_max);
+show_8(temp_min);
+show_8(temp_alert);
+show_8(temp_max_flag);
+show_8(temp_min_flag);
+
+#define set(value, reg) \
+static ssize_t set_##value(struct device *dev, struct device_attribute *attr, const char *buf, size_t count) \
+{ \
+ struct i2c_client *client = to_i2c_client(dev); \
+ struct ad7414_data *data = i2c_get_clientdata(client); \
+ int temp = simple_strtoul(buf, NULL, 10); \
+ \
+ mutex_lock(&data->lock); \
+ data->value = temp; \
+ ad7414_write(client, reg, data->value); \
+ mutex_unlock(&data->lock); \
+ return count; \
+}
+set(temp_max, AD7414_REG_T_HIGH);
+set(temp_min, AD7414_REG_T_LOW);
+
+static DEVICE_ATTR(temp1_max, S_IWUSR | S_IRUGO, show_temp_max, set_temp_max);
+static DEVICE_ATTR(temp1_min, S_IWUSR | S_IRUGO, show_temp_min, set_temp_min);
+static DEVICE_ATTR(temp1_input, S_IRUGO, show_temp_input, NULL);
+static DEVICE_ATTR(temp1_alert, S_IRUGO, show_temp_alert, NULL);
+static DEVICE_ATTR(temp1_max_flag, S_IRUGO, show_temp_max_flag, NULL);
+static DEVICE_ATTR(temp1_min_flag, S_IRUGO, show_temp_min_flag, NULL);
+
+static int ad7414_attach_adapter(struct i2c_adapter *adapter)
+{
+ if (!(adapter->class & I2C_CLASS_HWMON))
+ return 0;
+ return i2c_probe(adapter, &addr_data, ad7414_detect);
+}
+
+static struct attribute *ad7414_attributes[] = {
+ &dev_attr_temp1_input.attr,
+ &dev_attr_temp1_max.attr,
+ &dev_attr_temp1_min.attr,
+ &dev_attr_temp1_alert.attr,
+ &dev_attr_temp1_max_flag.attr,
+ &dev_attr_temp1_min_flag.attr,
+ NULL
+};
+
+static const struct attribute_group ad7414_group = {
+ .attrs = ad7414_attributes,
+};
+
+static int ad7414_detect(struct i2c_adapter *adapter, int address, int kind)
+{
+ struct i2c_client *client;
+ struct ad7414_data *data;
+ int err = 0;
+
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_BYTE_DATA |
+ I2C_FUNC_SMBUS_WORD_DATA))
+ goto exit;
+
+ if (!(data = kzalloc(sizeof(struct ad7414_data), GFP_KERNEL))) {
+ err = -ENOMEM;
+ goto exit;
+ }
+
+ client = &data->client;
+ client->addr = address;
+ client->adapter = adapter;
+ client->driver = &ad7414_driver;
+ client->flags = 0;
+
+ i2c_set_clientdata(client, data);
+
+ mutex_init(&data->lock);
+
+ /* TODO: not testing for AD7414 done yet... */
+
+ strlcpy(client->name, ad7414_driver.driver.name, I2C_NAME_SIZE);
+
+ if ((err = i2c_attach_client(client)))
+ goto exit_free;
+
+ dev_info(&client->dev, "chip found, driver version " DRV_VERSION "\n");
+
+ /* Initialize the AD7414 chip */
+ ad7414_init_client(client);
+
+ /* Register sysfs hooks */
+ if ((err = sysfs_create_group(&client->dev.kobj, &ad7414_group)))
+ goto exit_detach;
+
+ data->dev = hwmon_device_register(&client->dev);
+ if (IS_ERR(data->dev)) {
+ err = PTR_ERR(data->dev);
+ goto exit_remove;
+ }
+
+ return 0;
+
+exit_remove:
+ sysfs_remove_group(&client->dev.kobj, &ad7414_group);
+exit_detach:
+ i2c_detach_client(client);
+exit_free:
+ kfree(data);
+exit:
+ return err;
+}
+
+static int ad7414_detach_client(struct i2c_client *client)
+{
+ struct ad7414_data *data = i2c_get_clientdata(client);
+ struct ad7414_dev *dev;
+
+ list_for_each_entry(dev, &ad7414_dev_list, list)
+ if(dev->dev == &client->dev) {
+ list_del(&dev->list);
+ break;
+ }
+
+ hwmon_device_unregister(data->dev);
+ sysfs_remove_group(&client->dev.kobj, &ad7414_group);
+ i2c_detach_client(client);
+ kfree(data);
+ return 0;
+}
+
+static int __init ad7414_init(void)
+{
+ return i2c_add_driver(&ad7414_driver);
+}
+
+static void __exit ad7414_exit(void)
+{
+ i2c_del_driver(&ad7414_driver);
+}
+
+MODULE_AUTHOR("Stefan Roese <sr@denx.de>");
+MODULE_DESCRIPTION("AD7414 driver");
+MODULE_LICENSE("GPL");
+MODULE_VERSION(DRV_VERSION);
+
+module_init(ad7414_init);
+module_exit(ad7414_exit);
^ permalink raw reply related
* Re: [RFC] add phy-handle property for fec_mpc52xx
From: Sven Luther @ 2008-01-09 17:18 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, olaf, sven
In-Reply-To: <4784FCB1.3010509@genesi-usa.com>
On Wed, Jan 09, 2008 at 04:56:17PM +0000, Matt Sealey wrote:
> Okay I have a better suggestion.
>
> Apply all the prom_init fixes you like. But, instead of swizzling on the
> individual nodes, do it blanket for the firmware version.
>
> For instance, wrap the entire efika fixups stuff with a check for the
> openprom property "built-on" - this is the date the firmware was built.
> efika.forth will change this!
This is crazy, and not future proof. The way Grant did it, checking for
the existence of the node before creating is enough for any reasonable
upgrade to the firmware.
If future firmware will break with this, then they will break other
stuff anyway, and a new patch is needed.
> Just make sure it's less than.. let's say, a certain version of efika.forth,
> and I will roll a version which has a higher version and some extra features
> like CAN/I2C exposure.
>
> If you run efika.forth it will not touch the device tree. If you don't, it
> will add the small amount of patches. Add a huge comment that this hunk of
> code should be scheduled for deletion at some later date. Put a Kconfig
> around it so it can be taken out, even, at distro option.
Have you not read Grant's code ? It create the nodes only if they are
not existent already.
Friendly,
Sven Luther
^ permalink raw reply
* Re: Generic MMC-over-SPI binding?
From: Simon Richter @ 2008-01-09 17:17 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
In-Reply-To: <200801081827.13940.arnd@arndb.de>
Hi,
Arnd Bergmann wrote:
> The important part where this connects to the mmc-spi driver is that
> you need to set spi_board_info->modalias to "mmc-spi", if the
> device node can be identified as an mmc card.
Doing that now, using the code you provided as a base. The SPI child
device gets registered, but it appears something is still missing as no
messages I could attribute to mmc-spi appear. My suspicion would be that
it doesn't like the monolithic kernel for some reason (the mmc-spi
driver registers itself as a driver called "mmc_spi", not sure if the
modalias handling will catch that; still investigating there).
> Then you call that function after registering the master, from
> mpc52xx_psc_spi_of_probe.
I've changed mpc52xx_psc_spi_do_probe to have an additional argument for
the OF device node of the SPI master; ARCH=ppc can call this with NULL
as long as it still exists.
Simon
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Matt Sealey @ 2008-01-09 17:17 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <20080109170540.GA6789@powerlinux.fr>
Sven Luther wrote:
> On Wed, Jan 09, 2008 at 04:36:19PM +0000, Matt Sealey wrote:
>> The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is*
>> the upstream support for now. What his patch does is say, the upstream
>> support exists, but we don't like it, so we will supplement the patch..
>
> Matt, your work on efika.forth is laudable, and it is nice that you took
> the time to support it.
>
> *BUT* it is not acceptable for a distribution, or for someone who will
> have to do user support, to have to launch a second binary before
> launching the kernel. Especially when netbooting for example.
Then I think you are all missing the fact that I said there *IS A REALLY
CUTE WAY OF INSTALLING IT ONCE* by uploading it into nvramrc, it will not
be a runnable script, but executed on boot, because it'll be flashed into
nvramrc.
However I don't have the time to go into making this app, creating the
tools to munge efika.forth into a correct more uploadable format, and
creating the install tool. I barely have enough time to track this list
and make sure any drivers requiring firmware tree changes are taken care
of (I definitely lost the plot with the USB one, I haven't even checked
it even though I was asked to 2 weeks ago..)
Unfortunately one guy who already has a significant amount of work to do
all day, who is not the responsible person for firmware issues, and is
not being assisted by anyone in the community either generated and
maintained by Genesi or existing around Linux, poses some serious problems
with timeliness of updates.
If anyone wants to stop patching Linux and instead make efika.forth easier
to use, feel free, REALLY. Sven, are you volunteering for this REALLY
tiny task? It will probably take all of a day for a couple of guys to
work up the tools to do it based on very simple instructions and data
provided.. the work is probably worth the price of a pizza, so no
contracts are going to be worked out for it.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Sven Luther @ 2008-01-09 17:05 UTC (permalink / raw)
To: Matt Sealey; +Cc: Sven Luther, Olaf Hering, linuxppc-dev
In-Reply-To: <4784F803.9030003@genesi-usa.com>
On Wed, Jan 09, 2008 at 04:36:19PM +0000, Matt Sealey wrote:
>
> Sven Luther wrote:
> >On Wed, Jan 09, 2008 at 04:30:13PM +0000, Matt Sealey wrote:
> >>Sven Luther wrote:
> >>>Let's just fix this in the kernel, until we get a fixed efika firmware,
> >>>then we can drop it easily enough. But until this happens, we need to be
> >>>able to boot the kernel without any extra work on the users part.
> >>That is exactly why I don't like the idea. Yes, it makes it easier for
> >>users
> >>and easier for distro managers to say "it supports the Efika" but it makes
> >>the Forth fixing, and any further firmware development (ignore the lack of
> >>releases, it means nothing) much harder.
> >
> >efika firmware development is dead. Until we see a release we should
> >assume that the efika is a firmware with breakage, and no upstream
>
> The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is*
> the upstream support for now. What his patch does is say, the upstream
> support exists, but we don't like it, so we will supplement the patch..
Matt, your work on efika.forth is laudable, and it is nice that you took
the time to support it.
*BUT* it is not acceptable for a distribution, or for someone who will
have to do user support, to have to launch a second binary before
launching the kernel. Especially when netbooting for example.
Friendly,
Sven Luther
^ permalink raw reply
* [PATCH] i2c-ibm_iic driver
From: Sean MacLennan @ 2008-01-09 17:05 UTC (permalink / raw)
To: i2c, khali; +Cc: linuxppc-dev
This patch allows the i2c-ibm_iic driver to be built either as an ocp
driver or an of_platform driver. This allows it to run under the powerpc
arch but maintains backward compatibility with the ppc arch.
Cheers,
Sean MacLennan
Signed-off-by: Sean MacLennan <smaclennan@pikatech.com>
---
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index c466c6c..e9e1493 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -241,7 +241,6 @@ config I2C_PIIX4
config I2C_IBM_IIC
tristate "IBM PPC 4xx on-chip I2C interface"
- depends on IBM_OCP
help
Say Y here if you want to use IIC peripheral found on
embedded IBM PPC 4xx based systems.
diff --git a/drivers/i2c/busses/i2c-ibm_iic.c b/drivers/i2c/busses/i2c-ibm_iic.c
index 9b43ff7..98476fc 100644
--- a/drivers/i2c/busses/i2c-ibm_iic.c
+++ b/drivers/i2c/busses/i2c-ibm_iic.c
@@ -6,6 +6,9 @@
* Copyright (c) 2003, 2004 Zultys Technologies.
* Eugene Surovegin <eugene.surovegin@zultys.com> or <ebs@ebshome.net>
*
+ * Copyright (c) 2008 PIKA Technologies
+ * Sean MacLennan <smaclennan@pikatech.com>
+ *
* Based on original work by
* Ian DaSilva <idasilva@mvista.com>
* Armin Kuster <akuster@mvista.com>
@@ -39,12 +42,17 @@
#include <asm/io.h>
#include <linux/i2c.h>
#include <linux/i2c-id.h>
+
+#ifdef CONFIG_IBM_OCP
#include <asm/ocp.h>
#include <asm/ibm4xx.h>
+#else
+#include <linux/of_platform.h>
+#endif
#include "i2c-ibm_iic.h"
-#define DRIVER_VERSION "2.1"
+#define DRIVER_VERSION "2.2"
MODULE_DESCRIPTION("IBM IIC driver v" DRIVER_VERSION);
MODULE_LICENSE("GPL");
@@ -650,13 +658,14 @@ static inline u8 iic_clckdiv(unsigned int opb)
opb /= 1000000;
if (opb < 20 || opb > 150){
- printk(KERN_CRIT "ibm-iic: invalid OPB clock frequency %u MHz\n",
+ printk(KERN_WARNING "ibm-iic: invalid OPB clock frequency %u MHz\n",
opb);
opb = opb < 20 ? 20 : 150;
}
return (u8)((opb + 9) / 10 - 1);
}
+#ifdef CONFIG_IBM_OCP
/*
* Register single IIC interface
*/
@@ -672,7 +681,7 @@ static int __devinit iic_probe(struct ocp_device *ocp){
ocp->def->index);
if (!(dev = kzalloc(sizeof(*dev), GFP_KERNEL))) {
- printk(KERN_CRIT "ibm-iic%d: failed to allocate device data\n",
+ printk(KERN_ERR "ibm-iic%d: failed to allocate device data\n",
ocp->def->index);
return -ENOMEM;
}
@@ -687,7 +696,7 @@ static int __devinit iic_probe(struct ocp_device *ocp){
}
if (!(dev->vaddr = ioremap(ocp->def->paddr, sizeof(struct iic_regs)))){
- printk(KERN_CRIT "ibm-iic%d: failed to ioremap device registers\n",
+ printk(KERN_ERR "ibm-iic%d: failed to ioremap device registers\n",
dev->idx);
ret = -ENXIO;
goto fail2;
@@ -746,7 +755,7 @@ static int __devinit iic_probe(struct ocp_device *ocp){
adap->nr = dev->idx >= 0 ? dev->idx : 0;
if ((ret = i2c_add_numbered_adapter(adap)) < 0) {
- printk(KERN_CRIT "ibm-iic%d: failed to register i2c adapter\n",
+ printk(KERN_ERR "ibm-iic%d: failed to register i2c adapter\n",
dev->idx);
goto fail;
}
@@ -779,7 +788,7 @@ static void __devexit iic_remove(struct ocp_device *ocp)
struct ibm_iic_private* dev = (struct ibm_iic_private*)ocp_get_drvdata(ocp);
BUG_ON(dev == NULL);
if (i2c_del_adapter(&dev->adap)){
- printk(KERN_CRIT "ibm-iic%d: failed to delete i2c adapter :(\n",
+ printk(KERN_ERR "ibm-iic%d: failed to delete i2c adapter :(\n",
dev->idx);
/* That's *very* bad, just shutdown IRQ ... */
if (dev->irq >= 0){
@@ -831,3 +840,189 @@ static void __exit iic_exit(void)
module_init(iic_init);
module_exit(iic_exit);
+#else
+/*
+ * Register single IIC interface
+ */
+static int __devinit iic_probe(struct of_device *ofdev,
+ const struct of_device_id *match)
+{
+ static int index = 0;
+ struct device_node *np = ofdev->node;
+ struct ibm_iic_private* dev;
+ struct i2c_adapter* adap;
+ const u32 *indexp, *freq;
+ int ret;
+
+ dev = kzalloc(sizeof(*dev), GFP_KERNEL);
+ if (!dev) {
+ printk(KERN_ERR "ibm-iic: failed to allocate device data\n");
+ return -ENOMEM;
+ }
+
+ /* This assumes we don't mix index and non-index entries. */
+ indexp = of_get_property(np, "index", NULL);
+ dev->idx = indexp ? *indexp : index++;
+
+ dev_set_drvdata(&ofdev->dev, dev);
+
+ dev->vaddr = of_iomap(np, 0);
+ if (dev->vaddr == NULL) {
+ printk(KERN_ERR "ibm-iic%d: failed to ioremap device registers\n",
+ dev->idx);
+ ret = -ENXIO;
+ goto fail1;
+ }
+
+ init_waitqueue_head(&dev->wq);
+
+ if (iic_force_poll)
+ dev->irq = NO_IRQ;
+ else {
+ dev->irq = irq_of_parse_and_map(np, 0);
+ if (dev->irq == NO_IRQ)
+ printk(KERN_ERR __FILE__ ": irq_of_parse_and_map failed\n");
+ else {
+ /* Disable interrupts until we finish initialization,
+ assumes level-sensitive IRQ setup...
+ */
+ iic_interrupt_mode(dev, 0);
+ if (request_irq(dev->irq, iic_handler, 0, "IBM IIC", dev)){
+ printk(KERN_ERR "ibm-iic%d: request_irq %d failed\n",
+ dev->idx, dev->irq);
+ /* Fallback to the polling mode */
+ dev->irq = NO_IRQ;
+ }
+ }
+ }
+
+ if (dev->irq == NO_IRQ)
+ printk(KERN_WARNING "ibm-iic%d: using polling mode\n",
+ dev->idx);
+
+ /* Board specific settings */
+ if (iic_force_fast || of_get_property(np, "fast-mode", NULL))
+ dev->fast_mode = 1;
+ else
+ dev->fast_mode = 0;
+
+ /* clckdiv is the same for *all* IIC interfaces, but I'd rather
+ * make a copy than introduce another global. --ebs
+ */
+ freq = of_get_property(np, "clock-frequency", NULL);
+ if (freq == NULL) {
+ freq = of_get_property(np->parent, "clock-frequency", NULL);
+ if (freq == NULL) {
+ printk(KERN_ERR "ibm-iic%d: Unable to get bus frequency\n",
+ dev->idx);
+ ret = -EBUSY;
+ goto fail;
+ }
+ }
+
+ dev->clckdiv = iic_clckdiv(*freq);
+ DBG("%d: clckdiv = %d\n", dev->idx, dev->clckdiv);
+
+ /* Initialize IIC interface */
+ iic_dev_init(dev);
+
+ /* Register it with i2c layer */
+ adap = &dev->adap;
+ adap->dev.parent = &ofdev->dev;
+ strcpy(adap->name, "IBM IIC");
+ i2c_set_adapdata(adap, dev);
+ adap->id = I2C_HW_OCP;
+ adap->class = I2C_CLASS_HWMON;
+ adap->algo = &iic_algo;
+ adap->client_register = NULL;
+ adap->client_unregister = NULL;
+ adap->timeout = 1;
+ adap->retries = 1;
+ adap->nr = dev->idx;
+
+ ret = i2c_add_numbered_adapter(adap);
+ if (ret < 0) {
+ printk(KERN_ERR "ibm-iic%d: failed to register i2c adapter\n",
+ dev->idx);
+ goto fail;
+ }
+
+ printk(KERN_INFO "ibm-iic%d: using %s mode\n", dev->idx,
+ dev->fast_mode ? "fast (400 kHz)" : "standard (100 kHz)");
+
+ return 0;
+
+fail:
+ if (dev->irq != NO_IRQ){
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+
+ iounmap(dev->vaddr);
+fail1:
+ dev_set_drvdata(&ofdev->dev, NULL);
+ kfree(dev);
+ return ret;
+}
+
+/*
+ * Cleanup initialized IIC interface
+ */
+static int __devexit iic_remove(struct of_device *ofdev)
+{
+ struct ibm_iic_private* dev = dev_get_drvdata(&ofdev->dev);
+
+ BUG_ON(dev == NULL);
+ if (i2c_del_adapter(&dev->adap)){
+ printk(KERN_ERR "ibm-iic%d: failed to delete i2c adapter :(\n",
+ dev->idx);
+ /* That's *very* bad, just shutdown IRQ ... */
+ if (dev->irq != NO_IRQ){
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ dev->irq = NO_IRQ;
+ }
+ } else {
+ if (dev->irq != NO_IRQ){
+ iic_interrupt_mode(dev, 0);
+ free_irq(dev->irq, dev);
+ }
+ iounmap(dev->vaddr);
+ kfree(dev);
+ }
+
+ return 0;
+}
+
+
+static const struct of_device_id ibm_iic_match[] =
+{
+ { .type = "i2c", .compatible = "ibm,iic-405ex", },
+ { .type = "i2c", .compatible = "ibm,iic-405gp", },
+ { .type = "i2c", .compatible = "ibm,iic-440gp", },
+ { .type = "i2c", .compatible = "ibm,iic-440gpx", },
+ { .type = "i2c", .compatible = "ibm,iic-440grx", },
+ {}
+};
+
+static struct of_platform_driver ibm_iic_driver =
+{
+ .name = "ibm-iic",
+ .match_table = ibm_iic_match,
+ .probe = iic_probe,
+ .remove = iic_remove,
+};
+
+static int __init ibm_iic_init(void)
+{
+ printk(KERN_INFO "IBM IIC driver v" DRIVER_VERSION "\n");
+ return of_register_platform_driver(&ibm_iic_driver);
+}
+module_init(ibm_iic_init);
+
+static void __exit ibm_iic_exit(void)
+{
+ of_unregister_platform_driver(&ibm_iic_driver);
+}
+module_exit(ibm_iic_exit);
+#endif
^ permalink raw reply related
* Re: [RFC] add phy-handle property for fec_mpc52xx
From: Matt Sealey @ 2008-01-09 16:56 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, olaf, sven
In-Reply-To: <20080109163058.21643.30876.stgit@trillian.secretlab.ca>
Okay I have a better suggestion.
Apply all the prom_init fixes you like. But, instead of swizzling on the
individual nodes, do it blanket for the firmware version.
For instance, wrap the entire efika fixups stuff with a check for the
openprom property "built-on" - this is the date the firmware was built.
efika.forth will change this!
Just make sure it's less than.. let's say, a certain version of efika.forth,
and I will roll a version which has a higher version and some extra features
like CAN/I2C exposure.
If you run efika.forth it will not touch the device tree. If you don't, it
will add the small amount of patches. Add a huge comment that this hunk of
code should be scheduled for deletion at some later date. Put a Kconfig
around it so it can be taken out, even, at distro option.
Does that sound better? Right now I'm a little too busy to write and
compile test code for it so I will not venture to submit a patch..
do we want to work on a comprehensive, required efika.forth release
that fixes these things together, or is it just my job for now?
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
Grant Likely wrote:
> From: Olaf Hering <olaf@aepfle.de>
>
> The new network driver fec_mpc52xx will not work on efika because the
> firmware does not provide all required properties.
> http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
> create more properties. But only the phy stuff is required to get a
> working network.
>
> This should go into the kernel because its appearently
> impossible to boot the script via tftp and then load the real boot
> binary (yaboot or zimage).
>
> (Olaf's s-o-b line needs to go here)
> Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> ---
>
> Here's my respin of Olaf's patch to move it to fixup_device_tree_efika()
> and to make it check if the nodes exist before blindly creating them.
>
> Cheers,
> g.
>
> arch/powerpc/kernel/prom_init.c | 39 +++++++++++++++++++++++++++++++++++++++
> 1 files changed, 39 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> index 1add6ef..5d89a21 100644
> --- a/arch/powerpc/kernel/prom_init.c
> +++ b/arch/powerpc/kernel/prom_init.c
> @@ -2216,6 +2216,45 @@ static void __init fixup_device_tree_efika(void)
> prom_printf("fixup_device_tree_efika: ",
> "skipped entry %x - setprop error\n", i);
> }
> +
> + /* Make sure ethernet mdio bus node exists */
> + node = call_prom("finddevice", 1, 1, ADDR("/builtin/mdio"));
> + if (!PHANDLE_VALID(node)) {
> + prom_printf("Adding Ethernet MDIO node\n");
> + call_prom("interpret", 1, 1,
> + " s\" /builtin\" find-device"
> + " new-device"
> + " 1 encode-int s\" #address-cells\" property"
> + " 0 encode-int s\" #size-cells\" property"
> + " s\" mdio\" 2dup device-name device-type"
> + " s\" mpc5200b-fec-phy\" encode-string"
> + " s\" compatible\" property"
> + " 0xf0003000 0x400 reg"
> + " 0x2 encode-int"
> + " 0x5 encode-int encode+"
> + " 0x3 encode-int encode+"
> + " s\" interrupts\" property"
> + " finish-device");
> + };
> +
> + /* Make sure ethernet phy device node exist */
> + node = call_prom("finddevice", 1, 1, ADDR("/builtin/mdio/ethernet-phy"));
> + if (!PHANDLE_VALID(node)) {
> + prom_printf("Adding Ethernet PHY node\n");
> + call_prom("interpret", 1, 1,
> + " s\" /builtin/mdio\" find-device"
> + " new-device"
> + " s\" ethernet-phy\" device-name"
> + " 0x10 encode-int s\" reg\" property"
> + " my-self"
> + " ihandle>phandle"
> + " finish-device"
> + " s\" /builtin/ethernet\" find-device"
> + " encode-int"
> + " s\" phy-handle\" property"
> + " device-end");
> + }
> +
> }
> #else
> #define fixup_device_tree_efika()
>
^ permalink raw reply
* Re: Linux for ml310
From: Grant Likely @ 2008-01-09 16:48 UTC (permalink / raw)
To: Joachim Meyer, linuxppc-dev
In-Reply-To: <524178230@web.de>
always CC the mailing list when replying.
On 1/9/08, Joachim Meyer <Jogi95@web.de> wrote:
> arch/ppc/boot/common/ns16550.c:21: error: `XPAR_UARTNS550_0_CLOCK_FREQ_HZ' undeclared here (not in a function)
> arch/ppc/boot/common/ns16550.c:21: error: initializer element is not constant
> arch/ppc/boot/common/ns16550.c:21: error: (near initialization for `rs_table[0].baud_base')
> arch/ppc/boot/common/ns16550.c:21: error: `XPAR_INTC_0_UARTNS550_0_VEC_ID' undeclared here (not in a function)
> arch/ppc/boot/common/ns16550.c:21: error: initializer element is not constant
> arch/ppc/boot/common/ns16550.c:21: error: (near initialization for `rs_table[0].irq')
> arch/ppc/boot/common/ns16550.c:21: error: `XPAR_UARTNS550_0_BASEADDR' undeclared here (not in a function)
> arch/ppc/boot/common/ns16550.c:21: error: initializer element is not constant
> arch/ppc/boot/common/ns16550.c:21: error: (near initialization for `rs_table[0].iomem_base')
> arch/ppc/boot/common/ns16550.c:21: error: initializer element is not constant
> arch/ppc/boot/common/ns16550.c:21: error: (near initialization for `rs_table[0]'
You're xparameters_ml300.h file does not define
`XPAR_UARTNS550_0_CLOCK_FREQ_HZ', `XPAR_INTC_0_UARTNS550_0_VEC_ID' and
`XPAR_UARTNS550_0_BASEADDR'.
You'll need to look in your xparams file, find out what the real
#defines are for the uart and add fixups to xparameter.h so ns16550
can find them.
You're almost there! :-)
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* RE: MMU failure, Virtex4-FX60
From: Stephen Neuendorffer @ 2008-01-09 16:46 UTC (permalink / raw)
To: Robert Woodworth, Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <1199829276.4598.7.camel@PisteOff>
Passed along....
"Most likely bootloop is not enabled. The processor takes an invalid
instruction and registers a following machine check exception. The
machine check exception is taken when it is enabled in the MSR causing
Linux to crash."
Steve
> -----Original Message-----
> From: linuxppc-embedded-bounces+stephen=3Dneuendorffer.name@ozlabs.org
[mailto:linuxppc-embedded-
> bounces+stephen=3Dneuendorffer.name@ozlabs.org] On Behalf Of Robert
Woodworth
> Sent: Tuesday, January 08, 2008 1:55 PM
> To: Grant Likely
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: MMU failure, Virtex4-FX60
>=20
> After further investigation...
> There is a pending interrupt from the PLB waiting at bootup and it
gets
> hit by Linux when the MSR gets set and enables critical interrupts
(same
> time that it jumps into 0xC000XXXX). The kernel code detects the
> interrupt as a PLB data bus error and goes into crash sequence die().
>=20
> I think I have a problem with my reset hardware, such that the PLB is
> not getting reset correctly with the PPC. With all interrupts
disabled
> and running a standalone C program, the PLB and memory work fine.
> Any Virtex experts out there have any hints?
>=20
>=20
>=20
> RJW.
>=20
>=20
>=20
>=20
> On Mon, 2008-01-07 at 11:21 -0700, Grant Likely wrote:
> > On 1/7/08, Robert Woodworth <rwoodworth@securics.com> wrote:
> > > Hello!
> > >
> > > I'm building a new Virtex4-FX60 device. I have built it with the
new
> > > MPMC3 and a 256MB SO-DIMM. It works successfully with a
"mem-test" type
> > > embedded program.
> > >
> > > I cannot get it to boot a Linux kernel. I have traced it down to
the
> > > MMU not getting mapped correctly.
> > >
> > > I can load the kernel via jtag, get the pre-boot messages on the
serial
> > > but then when it tries to jump to 0xc0002218 (start_here:
head_4xxx.S)
> > > it fails with a "Machine check exception; invalid instruction
address".
> > >
> > > Using the debugger and examining the memory once the mmu is
suppose to
> > > be configured, I see that it is not mapping 0xc0000000 to the
proper
> > > location. I'm sure I've set something up wrong in my FPGA and I
need to
> > > re-synthesize. But what?
> >
> > Hmmm, I haven't seen that failure mode before. MMU handling on an
of
> > my virtex platforms has never been a problem. Take a look at the
TLB
> > registers to see how they are configured to see if the mappings are
> > really getting written.
> >
> > What kernel version are you using?
> >
> > Cheers,
> > g.
> >
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Matt Sealey @ 2008-01-09 16:48 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <1199893757.2978.73.camel@pmac.infradead.org>
David Woodhouse wrote:
> On Wed, 2008-01-09 at 15:26 +0000, Matt Sealey wrote:
>> If anyone wants to help/assist/suggest any updates to efika.forth,
>> create binary tools which assist the installation of the script for
>> users and for placement on Linux distro CDs etc. I would be very
>> grateful, but it seems we have hit the Wall of Apathy where users
>> complain for a feature but are not willing to work for it.
>
> We're already shipping efika.forth in Fedora rawhide, and in my updated
> spins of Fedora 8. It's a pain in the arse, but it kind of works.
I already said I don't like that solution either :]
efika.forth may change between Fedora 8 spins and user downloading it,
meaning updated kernels in the repositories stop working or so. This is
what I am hoping to stop happening by having the kernel *really just not
do anything* so it is entirely the fault of efika.forth or firmware
releases not happening, and not a bastardised combination of both.
> It would be much better if the kernel would 'just work'. The ideal way
> of achieving that is for the firmware to be fixed -- but that's been
> promised for a long time now, and we just don't believe you any more. So
> working round it in the kernel seems to be the next best option.
I don't blame you for thinking that; announcing a firmware update was
a rather ill-thought-out decision not made by anyone who works on the
firmware or with firmware issues.
Don't rely on a real flashable firmware update any time soon, but don't
take that as a task to "fix" the Linux kernel instead.
Your firmware update is and will be for the time being, that Forth
script, which is easy enough to paste into a serial console into nvramrc,
or run from GRUB, or run manually and edit the boot line at the bottom..
When a new firmware appears, and for all you and I know this could
happen this afternoon, this patch will become obselete and needs to
be removed - even Grant's version, because there is no guarantee
whatsoever that Nico will call the device /builtin/mdio when the
search for the device in the driver is for a compatible of "ethernet-phy"
for example.
By hard coding these things into Linux you are shaping firmware
development and making it harder. You are fixing things in the
efika.forth script which needn't be fixed - now we will need to
keep the script entirely compatible with that patch, even if it's
wrong. I don't like this situation because it causes me more work.
The guys in Germany don't release new firmwares BECAUSE of the
chop and change of Linux device tree expectations. If we released
a firmware every time you have a new idea on how it should look,
there would be one every month, and no other bugs would have time
to be fixed due to the extensive regression testing firmware has
to go through on multiple current and future board revisions with
multiple current and future kernels.
>> (I am invoking the Open Source Fallacy of that if the source is
>> available you can patch it, I say that patching Linux is not the
>> solution, but patching the firmware is. But nobody is willing to
>> work on patching the firmware and keeping Linux entirely independant
>> of our so-deemed "crappy" firmware)
>
> /me looks at http://git.infradead.org/?p=openfirmware.git
> /me looks at the Efika...
It would be quicker to update efika.forth with an installer (I already
told you how I would do it.. the whole technical detail!) than to
bring up SmartFirmware again for the Efika.
I really want to shift the burden to Genesi and not onto the Linux
kernel, as involving Linux patches means double the work, which will
delay firmware releases, delay efika.forth updates due to extended
testing with myriad different versions of patches etc.
It is better if the Linux kernel is simply a known quantity, non-working
without external assistance, if that be the case. It is not your fault
if the Linux kernel doesn't work on stock Efikas, it's OURS. However
without significant support behind fixing the firmware (Genesi is working
on it and efika.forth is PART of that - a good testing bed with no
flashing required!) and with patches being continually submitted to the
kernel to work around supposed firmware weaknesses, it is just going to
be too complicated.
After all, if Linux just trashes the firmware, replaces anything it
doesn't deem right, why bother releasing a new firmware ever? The
patch alone states the case that you do not need us to ever fix anything,
I don't think you really mean to go there.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Grant Likely @ 2008-01-09 16:44 UTC (permalink / raw)
To: Matt Sealey; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <4784F7D1.1050301@genesi-usa.com>
On 1/9/08, Matt Sealey <matt@genesi-usa.com> wrote:
> > However, I'm still inclined to pick up Olaf's patch with the
> > appropriate protections around it so it is only done if the nodes are
> > missing.
>
> Eh.. yeah. Maybe. Seems like a cop-out to me. I would rather you removed
> the patch and called us a bunch of idiots for coding bad firmware, than
> have the fixups be dependant on what could turn into a very well coded
> but essentially screen-long list of fixups for myriad firmware versions
> where the properties may or may not be present or correct for various
> firmware versions and devices.
I've come to the conclusion that Postel knew what he was talking
about; "Be conservative in what you do; be liberal in what you accept
from others." :-)
I 100% agree that this stuff is better done in firmware. However,
until that stuff is in place; it is 100% reasonable and desirable to
work around it in prom_init. That being said, I will modify prom_init
to not blindly apply fixups if they have already been done in
firmware.
> Grant, are you any good at coding firmware-level stuff without utilizing
> any preexisting code under the GPL? I'd like to collaborate on an installer
> tool which can put efika.forth (and therefore all these fixes) in.
I'm good at firmware stuff, but time comes at a premium. This level
of work would require a contract arrangement between our two
companies.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: Use 2G RAM in 8548, vmalloc fail, adjust_total_lowmem
From: Dale Farnsworth @ 2008-01-09 16:06 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <OF590B6FCB.576A8335-ON482573CB.00169CC3@alphanetworks.com>
> I am using a MCP8548 board with 2.6.14.5 kernel.
> And I would like to upgrade memory from 512MB to 2048MB.
> Finally, I realize this is not so easy as I think. I encounter several
> problems. :~~
>
> First, I change mem=512M to mem=2048M.
>
> 1. vmalloc fail problem
> So, I change kernel config in "advanced setup"
> Change "Set maximum low memory" from 0x30000000 to 0x80000000.
> Change "Virtual address of kernel base" from 0xC0000000 to 0x60000000.
> Change "Set custom user task size" from 0x80000000 to 0x60000000
Just enable CONFIG_HIGHMEM=y to use your 2GB. It's not worth the effort
to try making it all accessible as lowmem.
-Dale
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Matt Sealey @ 2008-01-09 16:36 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <20080109162923.GA6290@powerlinux.fr>
Sven Luther wrote:
> On Wed, Jan 09, 2008 at 04:30:13PM +0000, Matt Sealey wrote:
>> Sven Luther wrote:
>>> Let's just fix this in the kernel, until we get a fixed efika firmware,
>>> then we can drop it easily enough. But until this happens, we need to be
>>> able to boot the kernel without any extra work on the users part.
>> That is exactly why I don't like the idea. Yes, it makes it easier for users
>> and easier for distro managers to say "it supports the Efika" but it makes
>> the Forth fixing, and any further firmware development (ignore the lack of
>> releases, it means nothing) much harder.
>
> efika firmware development is dead. Until we see a release we should
> assume that the efika is a firmware with breakage, and no upstream
The link that Olaf presented, www.powerdeveloper.org/asset/by-id/46 *is*
the upstream support for now. What his patch does is say, the upstream
support exists, but we don't like it, so we will supplement the patch..
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* [RFC] add phy-handle property for fec_mpc52xx
From: Grant Likely @ 2008-01-09 16:32 UTC (permalink / raw)
To: olaf, linuxppc-dev, matt, sven
From: Olaf Hering <olaf@aepfle.de>
The new network driver fec_mpc52xx will not work on efika because the
firmware does not provide all required properties.
http://www.powerdeveloper.org/asset/by-id/46 has a Forth script to
create more properties. But only the phy stuff is required to get a
working network.
This should go into the kernel because its appearently
impossible to boot the script via tftp and then load the real boot
binary (yaboot or zimage).
(Olaf's s-o-b line needs to go here)
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
---
Here's my respin of Olaf's patch to move it to fixup_device_tree_efika()
and to make it check if the nodes exist before blindly creating them.
Cheers,
g.
arch/powerpc/kernel/prom_init.c | 39 +++++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
index 1add6ef..5d89a21 100644
--- a/arch/powerpc/kernel/prom_init.c
+++ b/arch/powerpc/kernel/prom_init.c
@@ -2216,6 +2216,45 @@ static void __init fixup_device_tree_efika(void)
prom_printf("fixup_device_tree_efika: ",
"skipped entry %x - setprop error\n", i);
}
+
+ /* Make sure ethernet mdio bus node exists */
+ node = call_prom("finddevice", 1, 1, ADDR("/builtin/mdio"));
+ if (!PHANDLE_VALID(node)) {
+ prom_printf("Adding Ethernet MDIO node\n");
+ call_prom("interpret", 1, 1,
+ " s\" /builtin\" find-device"
+ " new-device"
+ " 1 encode-int s\" #address-cells\" property"
+ " 0 encode-int s\" #size-cells\" property"
+ " s\" mdio\" 2dup device-name device-type"
+ " s\" mpc5200b-fec-phy\" encode-string"
+ " s\" compatible\" property"
+ " 0xf0003000 0x400 reg"
+ " 0x2 encode-int"
+ " 0x5 encode-int encode+"
+ " 0x3 encode-int encode+"
+ " s\" interrupts\" property"
+ " finish-device");
+ };
+
+ /* Make sure ethernet phy device node exist */
+ node = call_prom("finddevice", 1, 1, ADDR("/builtin/mdio/ethernet-phy"));
+ if (!PHANDLE_VALID(node)) {
+ prom_printf("Adding Ethernet PHY node\n");
+ call_prom("interpret", 1, 1,
+ " s\" /builtin/mdio\" find-device"
+ " new-device"
+ " s\" ethernet-phy\" device-name"
+ " 0x10 encode-int s\" reg\" property"
+ " my-self"
+ " ihandle>phandle"
+ " finish-device"
+ " s\" /builtin/ethernet\" find-device"
+ " encode-int"
+ " s\" phy-handle\" property"
+ " device-end");
+ }
+
}
#else
#define fixup_device_tree_efika()
^ permalink raw reply related
* Re: add phy-handle property for fec_mpc52xx
From: Matt Sealey @ 2008-01-09 16:35 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <fa686aa40801090746k4ec5c208j9daf224cb2570071@mail.gmail.com>
Grant Likely wrote:
> On 1/9/08, Matt Sealey <matt@genesi-usa.com> wrote:
>> Please let's keep the nature of our firmware and the Linux codebase
>> independant, and move the burden of support to Genesi, and not the
>> Linux PowerPC team. After all, what is next, after phy-handle do
>> you want to add i2c, irda, missing xlb/cdm entries in the patch so
>> that other things work? Does everyone have to custom compile their
>> own kernel? What happens if we do another firmware release and
>> the Linux kernel overwrites important values without checking as
>> it does now? It simply causes problems.
>
> FWIW, I've got a patch in my tree that removes a bunch of the efika
> fixups. I've learned a lot over the past year and I'm taking a more
> pragmatic approach. So, fixups that are not absolutely required to
> get a working Efika are going away.
>
> However, I'm still inclined to pick up Olaf's patch with the
> appropriate protections around it so it is only done if the nodes are
> missing.
Eh.. yeah. Maybe. Seems like a cop-out to me. I would rather you removed
the patch and called us a bunch of idiots for coding bad firmware, than
have the fixups be dependant on what could turn into a very well coded
but essentially screen-long list of fixups for myriad firmware versions
where the properties may or may not be present or correct for various
firmware versions and devices.
Grant, are you any good at coding firmware-level stuff without utilizing
any preexisting code under the GPL? I'd like to collaborate on an installer
tool which can put efika.forth (and therefore all these fixes) in.
The end result would be efika_device_tree_fixups() reporting if you have
an old firmware and saying, things may not work. efika.forth is steering
towards hacking /openprom/built-on with an appropriate date for firmware
and device tree version checking, so any date lower than the appropriate
script or firmware version can be warned about.
(a similar tactic is employed by lmsensors if you have a Via SMB driver
loaded but the BIOS has left the SMB block in the southbridge disabled,
it says you need to update your BIOS or use force=1 and leaves it non
working. You will see this on Pegasos. I like this tactic, just not the
recommendation to update your BIOS when it may or may not exist.. a
simple warning that some devices may not work correctly is essential though)
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Sven Luther @ 2008-01-09 16:29 UTC (permalink / raw)
To: Matt Sealey; +Cc: Sven Luther, Olaf Hering, linuxppc-dev
In-Reply-To: <4784F695.7050507@genesi-usa.com>
On Wed, Jan 09, 2008 at 04:30:13PM +0000, Matt Sealey wrote:
>
> Sven Luther wrote:
> >
> >Let's just fix this in the kernel, until we get a fixed efika firmware,
> >then we can drop it easily enough. But until this happens, we need to be
> >able to boot the kernel without any extra work on the users part.
>
> That is exactly why I don't like the idea. Yes, it makes it easier for users
> and easier for distro managers to say "it supports the Efika" but it makes
> the Forth fixing, and any further firmware development (ignore the lack of
> releases, it means nothing) much harder.
efika firmware development is dead. Until we see a release we should
assume that the efika is a firmware with breakage, and no upstream
support at all.
Friendly,
Sven Luther
^ permalink raw reply
* Re: add phy-handle property for fec_mpc52xx
From: Matt Sealey @ 2008-01-09 16:30 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-dev, Olaf Hering
In-Reply-To: <20080109153511.GA5086@powerlinux.fr>
Sven Luther wrote:
>
> Let's just fix this in the kernel, until we get a fixed efika firmware,
> then we can drop it easily enough. But until this happens, we need to be
> able to boot the kernel without any extra work on the users part.
That is exactly why I don't like the idea. Yes, it makes it easier for users
and easier for distro managers to say "it supports the Efika" but it makes
the Forth fixing, and any further firmware development (ignore the lack of
releases, it means nothing) much harder.
It should not be a function of Linux to fix firmware problems. This was
the FIRM line by Ben, Segher and the rest of the LinuxPPC guys when we
released the Efika - fix the firmware, not Linux, don't hack drivers, don't
rely on fixups. I disagreed at the time due to the urgency to release the
board, but now, we have the luxury of not having to rush it through to get
a product on sale.
I would much rather the Linux kernel did not implement fixups for firmware
which we can fix. The phy-handle part that Olaf specifies in his patch
can be added by a user to nvramrc, BY HAND, in around 10 lines of Forth
code. Those 6 lines are in the efika.forth script, and in fact Olaf is
simply running "interpret" over an encoded version of this! (I say 10 lines
because the efika.forth script is needlessly verbose for the purpose of
being readable by humans).
It is not scary or difficult to do this if you need ethernet to work, and
not beyond the scope of the installation documentation or an Efika wiki
page. The Forth stuff will work fine for *all* operating systems.
If you don't like not having your Linux distro or a default kernel working
on our default firmware, PLEASE FEEL FREE TO BLAME US. PROFUSELY.
Alternatively I'd love to work with people to create a comprehensive
pre-update binary fix (not a boot loader but an installer) for the Forth
script so that users can run it before they boot any distro disk, and then
the kernel on the CD, the kernel in the distro repositories, will not have
the burden of tracking firmware releases, and the Linux team will not have
the burden of maintaining tiny fixes for things which may always be fixed.
After all, there is no profit or benefit in fixing something 5 times just
in case the user only has 4 of them installed.
--
Matt Sealey <matt@genesi-usa.com>
Genesi, Manager, Developer Relations
^ 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