* linux/drivers/net/fec_8xx/* vs. linux/arch/ppc/8xx_io/fec.c
From: Guillaume Autran @ 2005-06-09 21:19 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <4434E283.3000201@eircom.net>
Can anyone tell me what is the difference between:
linux/arch/ppc/8xx_io/fec.c
and
linux/drivers/net/fec_8xx/fec_*
They both seem to be mpc8xx fec drivers....
Thanks.
Guillaume.
--
=======================================
Guillaume Autran
Senior Software Engineer
MRV Communications, Inc.
Tel: (978) 952-4932 office
E-mail: gautran@mrv.com
=======================================
^ permalink raw reply
* 8xx fixes GIT tree
From: Marcelo Tosatti @ 2005-06-09 16:26 UTC (permalink / raw)
To: linux-ppc-embedded; +Cc: Aristeu Sergio Rozanski Filho
Hi,
I've put up a GIT tree with some 8xx fixes.
I plan to continue collecting fixes there - I encourage other folks
working with v2.6 on 8xx to join in and contribute.
Its about time to setup a "TODO" list for v2.6 8xx, a few which I
remember from the top of my head:
- merge CPU15 workaround
- merge PCMCIA driver
- merge arch/ppc/8xx_io/fec.c v2.6 update
- Remove misc-embedded.c
It should live somewhere in the web (wiki would be ideal).
It contains the following changes at the moment:
commit f17c5c6e4e1d1b7e8b01f323dfd2bd2197a0743f
tree ee66f3f546b0b68f8af3debf1ade40d3ce67f74a
parent 8d2fde72d6a5921136d6e605168e3c4995288b64
author Marcelo <marcelo@xeon.cnet> Thu, 09 Jun 2005 17:47:50 -0300
committer Marcelo Tosatti <marcelo.tosatti@cyclades.com> Thu, 09 Jun 2005 17:47:50 -0300
[PATCH] handle access to non-present IO ports on 8xx
Accessing non present "IO ports" on 8xx generates MCE's. The exception
is easily triggered during insertion/removal/suspension of PCMCIA cards.
The following adds exception table entries for I/O instructions on 8xx (copied
from the original Paul's PowerMac code), and changes MachineCheckException() slightly
to cover 8xx specific's (on 8xx the MCE can be generated while
executing the IO access instruction itself, which is not the case on
PowerMac's, as the comment on traps.c details).
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
commit 8d2fde72d6a5921136d6e605168e3c4995288b64
tree ba3161acbeab3b4559c63a4d08eff435a53f378a
parent 65df60a129cc12e89b93cec068f527a9650e5914
author Marcelo Tosatti <marcelo.tosatti@cyclades.com> Sat, 04 Jun 2005 14:13:34 -0700
committer Marcelo Tosatti <marcelo.tosatti@cyclades.com> Wed, 08 Jun 2005 22:17:47 -0300
[PATCH] 8xx: avoid "dcbst" misbehaviour with unpopulated TLB
On 8xx, cache control instructions (particularly "dcbst" from
flush_dcache_icache) fault as write operation if there is an
unpopulated TLB entry for the address in question. To workaround
that, we invalidate the TLB here, thus avoiding dcbst misbehaviour.
commit 65df60a129cc12e89b93cec068f527a9650e5914
tree 2ed7d42019c3ee29435bb9c7e4dc5e002fa4690c
parent 97d26b8042a6f14cc4a19e84e911a953363e3d69
author Marcelo Tosatti <marcelo.tosatti@cyclades.com> Sat, 04 Jun 2005 14:13:34 -0700
committer Marcelo Tosatti <marcelo.tosatti@cyclades.com> Wed, 08 Jun 2005 22:16:50 -0300
[PATCH] 8xx commproc: Do not touch pte directly - use dma coherent API instead
Touching the pte directly causes the 8Mbyte TLB entry to be invalidated.
This has been fixed in v2.4 for ages.
^ permalink raw reply
* Re: [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
From: Jean Delvare @ 2005-06-09 19:29 UTC (permalink / raw)
To: Mark A. Greer; +Cc: LM, linuxppc-embedded, Sensors
In-Reply-To: <42A89338.209@mvista.com>
Hi Mark,
> I interpreted the doc the same way Randy did when I did the m41t00
> chip code. Also, Mark Studebaker seemed to support that
> interpretation in this email:
> http://archives.andrew.net.au/lm-sensors/msg29325.html
I am not discussing the fast that using basic SMBus commands increases
the number of system the driver will be usable on. This is quite
obviously true, and I am fine with using this when there is no
performance drawback.
However, in the case of the DS1374, reading the registers as a block
would make the driver *much* faster and more simple. This has to be
considered, especially if the DS1374 chip is found on a limited number
of systems.
If you think the documentation should be updated to reflect that better,
well, patches are welcome ;)
> I suppose the best thing to do is check if the adapter is a true i2c
> ctlr (something like: i2c_check_functionality(adapter, I2C_FUNC_I2C))
> and base the cmds used on that.
>
> We can do something similar with I2C_FUNC_SMBUS_READ_I2C_BLOCK &
> I2C_FUNC_SMBUS_WRITE_BLOCK_DATA to check if we can use the smbus
> block cmds too, correct?
There is actually no benefit in checking for true I2C, since the
commands you would then build would be exactly I2C_FUNC_SMBUS_READ_I2C
and I2C_FUNC_SMBUS_WRITE_BLOCK_DATA. Better check for these directly, as
some non-I2C masters will support them (especially the second, the first
one is only rarely found). If both functions are supported, go with
this. If not, either fallback to the current code, or drop this code and
state that this isn't supported (I'd do that). If it happens that this
support is ever needed, it can be added back at that time - but that
time may never actually come.
Thanks,
--
Jean Delvare
^ permalink raw reply
* Re: [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
From: Mark A. Greer @ 2005-06-09 19:06 UTC (permalink / raw)
To: Jean Delvare; +Cc: LM, linuxppc-embedded, Sensors
In-Reply-To: <20050609192551.76b103ea.khali@linux-fr.org>
Hi Jean,
Jean Delvare wrote:
>Hi Randy and all,
>
>Sorry for the delay.
>
>[Eugene Surovegin]
>
>
>>I wonder, why you chose to use those 1-byte SMBus transfers instead
>>of i2c transfer.
>>
>>
>
>[Randy Vinson]
>
>
>>I was simply following the guidelines in
>>Documentation/i2c/writing-clients as noted in the driver header. This
>>note was in the driver I used as my base, so I just followed along.
>>
>>
>
>The document file says:
>
>"If you can choose between plain i2c communication and SMBus level
>communication, please use the last. All adapters understand SMBus level
>commands, but only some of them understand plain i2c!"
>
>The "if you can choose" is important. It doesn't suggest that you should
>use a less efficient way, but that you use the SMBus API when the I2C
>transfer you want to use happens to exist in the SMBus API.
>
>Even when sticking to SMBus commands, it is quite frequent that there
>are different ways to retrieve the same information, of varying
>availability and speed. One good example of this are EEPROMs. EEPROMs
>are I2C devices which can be accessed using SMBus commands. You can read
>bytes one by one (SMBus Read Byte Data command), or continuously as
>different reads (first one SMBus Write Byte, then many SMBus Read Byte),
>or continuously as a single read (I2C Block Read, supported by some
>SMBus controllers). If you look at the eeprom.c drivers, you'll see that
>the second and the third method are both implemented. The advantage is
>that:
>
I interpreted the doc the same way Randy did when I did the m41t00 chip
code. Also, Mark Studebaker seemed to support that interpretation in
this email: http://archives.andrew.net.au/lm-sensors/msg29325.html
I suppose the best thing to do is check if the adapter is a true i2c
ctlr (something like: i2c_check_functionality(adapter, I2C_FUNC_I2C))
and base the cmds used on that.
We can do something similar with I2C_FUNC_SMBUS_READ_I2C_BLOCK &
I2C_FUNC_SMBUS_WRITE_BLOCK_DATA to check if we can use the smbus block
cmds too, correct?
Mark
^ permalink raw reply
* Re: consistent_alloc() on 82xx
From: Dan Malek @ 2005-06-09 19:05 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linuxppc-embedded
In-Reply-To: <20050609100437.7cdef573.ajz@cambridgebroadband.com>
On Jun 9, 2005, at 5:04 AM, Alex Zeffertt wrote:
> An example of non-cache coherency in the CPM2: In the ATM chapter of
> the 8260 UM it says that the CPM will only assert GBL and "snoop"
> buffers, Buffer Descriptors, and interrupt queues if you set TCT[GBL]
> and RCT[GBL].
Right.
> ... Presumably this means that it *does not* by-pass the
> cache if this flag is not set.
It means just what it says. If this flag is set, CPM DMA will
snoop the cache. If you choose not to do this, you have to
maintain cache coherency through software.
> ..... More seriously, for address compression
> tables, and external connection tables there is no way of specifying
> that it *should* snoop - (which I assume means "use the cache").
You need to be more clear with your terms. Only the 60x core
"uses" the cache. The CPM is a DMA device that can utilize
cache coherency protocols if you enable that with the GBL flags.
> I have seen this causing problems. When I map a VPI/VCI to a
> connection
> table using the address compression table,
Where are you placing the VP-level and VC-level tables? I assume
you are properly configuring the GMODE to indicate their locations?
Does it work properly if the tables are in DP RAM?
> With external connection tables the problem is more severe.
There are some very subtle assumptions made by the ATM
controller regarding all channel data structures. There aren't
configuration location flags for every level of table, and assumptions
are made that tables for a connection are either internal or
external. Be careful with that. I either entirely use DP RAM for
everything or external memory for everything, which seemed
to work for me in the past. Maybe I was just lucky :-)
> .... During
> frame transmission, the core is constantly having to read and write to
> the Transmit Connection Table in order to use Auto-VC-ofF. I couldn't
> get this to work until I added lots of "invalidate_dcache_range" and
> "flush_dcache_range" calls.
Are you sure this is really a cache problem and not a race condition
with CPM access to the CTs? The CPM does atomic burst read/write
of the RCT/TCT entries, and buy doing cache flush operations, the
60x core does the same.
Thanks.
-- Dan
^ permalink raw reply
* Re: MPC52xx: sysfs failure on adding new device driver
From: Grant Likely @ 2005-06-09 18:48 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <02ea73261175dc6bfb99047e73395fb1@freescale.com>
On 6/9/05, Kumar Gala <kumar.gala@freescale.com> wrote:
>=20
> >> That changes the semantic of the driver names for the platform bus
> >> however, making the dot a "special" char.
> > Who needs to be asked about this? Should I take this discussion over
> > the the LKML?
>=20
> GregKH would be the person to talk to about the driver core and taking
> this to LKML would be useful. We probably have a similar issue with
> CPM comm channels.
>=20
> I always assumed multiple drivers would get probed and the drivers
> would fail in probe if they were not suppose to bind to the given
> channel/psc, etc..
>=20
I took another look at the sysfs layout, and it doesn't really look
like it is intended to support multiple drivers with the same name.=20
:-( I'll ask GregKH about it.
In the mean time, here's another option: Leave
arch/ppc/syslib/mpc52xx_devices.c alone, but modify the table in the
board setup code to assign specific drivers to the PSC devices before
the table is parsed by the platform bus. This has the added advantage
of eliminating the need for mpc52xx_match_psc_function() and it's
cousins.
Thoughts? Will this scheme negatively affect portability?
Here's a working example patch:
--------------------------------------------------------------------------
diff -ruN linux-2.6.12rc6.orig/arch/ppc/platforms/lite5200.c
linux-2.6.12rc6.spi2/arch/ppc/platforms/lite5200.c
--- linux-2.6.12rc6.orig/arch/ppc/platforms/lite5200.c=092005-06-08
17:22:05.000000000 -0600
+++ linux-2.6.12rc6.spi2/arch/ppc/platforms/lite5200.c=092005-06-09
12:23:26.000000000 -0600
@@ -50,17 +50,6 @@
/* Platform specific code =
*/
/* =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D */
=20
-/* Supported PSC function in "preference" order */
-struct mpc52xx_psc_func mpc52xx_psc_functions[] =3D {
-=09=09{ .id =3D 0,
-=09=09=09.func =3D "uart",
-=09=09},
-=09=09{ .id =3D -1, /* End entry */
-=09=09=09.func =3D NULL,
-=09=09}
-=09};
-
-
static int
lite5200_show_cpuinfo(struct seq_file *m)
{
@@ -198,6 +187,11 @@
=09isa_io_base=09=09=3D 0;
=09isa_mem_base=09=09=3D 0;
=20
+=09/* Assign driver names to PSC devices */
+=09ppc_sys_platform_devices[MPC52xx_PSC1].name =3D "mpc52xx-psc.uart";
+=09ppc_sys_platform_devices[MPC52xx_PSC2].name =3D "mpc52xx-psc.uart";
+=09ppc_sys_platform_devices[MPC52xx_PSC3].name =3D "mpc52xx-psc.spi";
+
=09/* Powersave */
=09/* This is provided as an example on how to do it. But you
=09 need to be aware that NAP disable bus snoop and that may
diff -ruN linux-2.6.12rc6.orig/arch/ppc/syslib/mpc52xx_setup.c
linux-2.6.12rc6.spi2/arch/ppc/syslib/mpc52xx_setup.c
--- linux-2.6.12rc6.orig/arch/ppc/syslib/mpc52xx_setup.c=092005-06-08
17:22:05.000000000 -0600
+++ linux-2.6.12rc6.spi2/arch/ppc/syslib/mpc52xx_setup.c=092005-06-09
12:11:31.000000000 -0600
@@ -216,15 +216,3 @@
=09tb_to_us =3D mulhwu_scale_factor(xlbfreq / divisor, 1000000);
}
=20
-int mpc52xx_match_psc_function(int psc_idx, const char *func)
-{
-=09struct mpc52xx_psc_func *cf =3D mpc52xx_psc_functions;
-
-=09while ((cf->id !=3D -1) && (cf->func !=3D NULL)) {
-=09=09if ((cf->id =3D=3D psc_idx) && !strcmp(cf->func,func))
-=09=09=09return 1;
-=09=09cf++;
-=09}
-
-=09return 0;
-}
diff -ruN linux-2.6.12rc6.orig/drivers/Kconfig
linux-2.6.12rc6.spi2/drivers/Kconfig
--- linux-2.6.12rc6.orig/drivers/Kconfig=092005-03-02 00:38:26.000000000 -0=
700
+++ linux-2.6.12rc6.spi2/drivers/Kconfig=092005-06-08 17:27:23.000000000 -0=
600
@@ -58,4 +58,6 @@
=20
source "drivers/infiniband/Kconfig"
=20
+source "drivers/spi/Kconfig"
+
endmenu
diff -ruN linux-2.6.12rc6.orig/drivers/Makefile
linux-2.6.12rc6.spi2/drivers/Makefile
--- linux-2.6.12rc6.orig/drivers/Makefile=092005-06-08 17:22:08.000000000 -=
0600
+++ linux-2.6.12rc6.spi2/drivers/Makefile=092005-06-08 17:27:13.000000000 -=
0600
@@ -64,3 +64,4 @@
obj-$(CONFIG_BLK_DEV_SGIIOC4)=09+=3D sn/
obj-y=09=09=09=09+=3D firmware/
obj-$(CONFIG_CRYPTO)=09=09+=3D crypto/
+obj-$(CONFIG_SPI)=09=09+=3D spi/
diff -ruN linux-2.6.12rc6.orig/drivers/serial/mpc52xx_uart.c
linux-2.6.12rc6.spi2/drivers/serial/mpc52xx_uart.c
--- linux-2.6.12rc6.orig/drivers/serial/mpc52xx_uart.c=092005-06-08
17:22:23.000000000 -0600
+++ linux-2.6.12rc6.spi2/drivers/serial/mpc52xx_uart.c=092005-06-09
12:14:40.000000000 -0600
@@ -29,8 +29,9 @@
/* Platform device Usage :
*
* Since PSCs can have multiple function, the correct driver for each one
- * is selected by calling mpc52xx_match_psc_function(...). The function
- * handled by this driver is "uart".
+ * is selected based on the name assigned to the psc. By convention, the
+ * function is appended to the device name in the board setup code. For
+ * example, this uart psc driver will only bind to mpc52xx_psc.uart device=
s.
*
* The driver init all necessary registers to place the PSC in uart
mode without
* DCD. However, the pin multiplexing aren't changed and should be set eit=
her
@@ -730,9 +731,6 @@
=09if (idx < 0 || idx >=3D MPC52xx_PSC_MAXNUM)
=09=09return -EINVAL;
=20
-=09if (!mpc52xx_match_psc_function(idx,"uart"))
-=09=09return -ENODEV;
-
=09/* Init the port structure */
=09port =3D &mpc52xx_uart_ports[idx];
=20
@@ -804,7 +802,7 @@
#endif
=20
static struct device_driver mpc52xx_uart_platform_driver =3D {
-=09.name=09=09=3D "mpc52xx-psc",
+=09.name=09=09=3D "mpc52xx-psc.uart",
=09.bus=09=09=3D &platform_bus_type,
=09.probe=09=09=3D mpc52xx_uart_probe,
=09.remove=09=09=3D mpc52xx_uart_remove,
diff -ruN linux-2.6.12rc6.orig/drivers/spi/Kconfig
linux-2.6.12rc6.spi2/drivers/spi/Kconfig
--- linux-2.6.12rc6.orig/drivers/spi/Kconfig=091969-12-31 17:00:00.00000000=
0 -0700
+++ linux-2.6.12rc6.spi2/drivers/spi/Kconfig=092005-06-08 17:29:37.00000000=
0 -0600
@@ -0,0 +1,19 @@
+#
+# Character device configuration
+#
+
+menu "SPI support"
+
+config SPI
+=09tristate "SPI support"
+=09---help---
+=09 SPI is a serial bus protocol for connecting between ICs
+
+config SPI_MPC52XX_PSC
+=09tristate "SPI bus via MPC5xxx PSC port"
+=09depends on SPI
+=09help
+=09 Say Y here if you want SPI via an MPC5xxx PSC port.
+
+endmenu
+
diff -ruN linux-2.6.12rc6.orig/drivers/spi/Makefile
linux-2.6.12rc6.spi2/drivers/spi/Makefile
--- linux-2.6.12rc6.orig/drivers/spi/Makefile=091969-12-31
17:00:00.000000000 -0700
+++ linux-2.6.12rc6.spi2/drivers/spi/Makefile=092005-06-08
17:29:17.000000000 -0600
@@ -0,0 +1,6 @@
+#
+# Makefile for the spi core.
+#
+
+obj-$(CONFIG_SPI_MPC52XX_PSC)=09+=3D spi-mpc5xxx-psc.o
+
diff -ruN linux-2.6.12rc6.orig/drivers/spi/spi-mpc5xxx-psc.c
linux-2.6.12rc6.spi2/drivers/spi/spi-mpc5xxx-psc.c
--- linux-2.6.12rc6.orig/drivers/spi/spi-mpc5xxx-psc.c=091969-12-31
17:00:00.000000000 -0700
+++ linux-2.6.12rc6.spi2/drivers/spi/spi-mpc5xxx-psc.c=092005-06-09
12:20:28.000000000 -0600
@@ -0,0 +1,54 @@
+
+#include <linux/device.h>
+#include <linux/module.h>
+#include <linux/fs.h>
+#include <linux/cdev.h>
+
+#include <asm/mpc52xx.h>
+#include <asm/mpc52xx_psc.h>
+
+MODULE_LICENSE("Dual BSD/GPL");
+
+static int __devinit
+spi_mpc52xx_psc_probe(struct device *dev)
+{
+=09struct platform_device *pdev =3D to_platform_device(dev);
+=09/*struct resource *res =3D pdev->resource;*/
+=09int idx =3D pdev->id;
+
+=09printk(KERN_ALERT "spi-mpc52xx-psc: probing idx=3D%i\n", idx);
+
+=09return 0;
+}
+
+static int=20
+spi_mpc52xx_psc_remove(struct device *dev)
+{
+=09return 0;
+}
+
+static struct device_driver spi_mpc52xx_psc_platform_driver =3D {
+=09.name=09=09=3D "mpc52xx-psc.spi",
+=09.bus=09=09=3D &platform_bus_type,
+=09.probe=09=09=3D spi_mpc52xx_psc_probe,
+=09.remove=09=09=3D spi_mpc52xx_psc_remove,
+};
+
+static int __init spi_mpc52xx_psc_init(void)
+{
+=09int ret;
+
+=09printk(KERN_ALERT "spi_mpc52xx_psc: initializing\n");
+
+=09ret =3D driver_register(&spi_mpc52xx_psc_platform_driver);
+=09return ret;
+}
+
+static void __exit spi_mpc52xx_psc_exit(void)
+{
+=09driver_unregister(&spi_mpc52xx_psc_platform_driver);
+=09printk(KERN_ALERT "spi_mpc52xx_psc: exiting\n");
+}
+
+module_init(spi_mpc52xx_psc_init);
+module_exit(spi_mpc52xx_psc_exit);
diff -ruN linux-2.6.12rc6.orig/include/asm-ppc/mpc52xx.h
linux-2.6.12rc6.spi2/include/asm-ppc/mpc52xx.h
--- linux-2.6.12rc6.orig/include/asm-ppc/mpc52xx.h=092005-06-08
17:22:29.000000000 -0600
+++ linux-2.6.12rc6.spi2/include/asm-ppc/mpc52xx.h=092005-06-09
12:11:19.000000000 -0600
@@ -415,17 +415,6 @@
=20
extern void mpc52xx_find_bridges(void);
=20
-
-=09/* Matching of PSC function */
-struct mpc52xx_psc_func {
-=09int id;
-=09char *func;
-};
-
-extern int mpc52xx_match_psc_function(int psc_idx, const char *func);
-extern struct mpc52xx_psc_func mpc52xx_psc_functions[];
-=09/* This array is to be defined in platform file */
-
#endif /* __ASSEMBLY__ */
^ permalink raw reply
* Re: MPC52xx: sysfs failure on adding new device driver
From: Grant Likely @ 2005-06-09 18:34 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded
In-Reply-To: <00b701c56d07$e3b166a0$0301a8c0@chuck2>
On 6/9/05, Mark Chambers <markc@mail.com> wrote:
> Sylvain:
> > btw, if not yet integrated you should send your patch to Wolfang, he's
> > the one maintaining that tree.
>=20
> Wolfgang:
> > I've seen the patch, but did not decide yet what to do with it. Many
> > drivers don't support devfs anyway, and in my opinion devfs makes
> > little sense in embedded systems anyway. Not to mention that it will
> > officially be removed from the kernel tree in less than 4 weeks from
> > now (see Documentation/feature-removal-schedule.txt).
>=20
> This is nonsense. You know, when I made this patch I said
> to myself, "Self, you're wasting your time, these guys won't take patches
> from somebody they don't know" But I thought it was enough of a
> no-brainer that it might go through.
>=20
> Seems I was wrong.
>=20
Don't take things too personally. (I understand where you're coming
from; I'm virtually unknown around here also). You have to remember
that devfs is pretty much considered to be a bastard stepchild and
there is a lot of negative opinion surrounding it. Because of that it
is very hard to get *any* devfs patches to be considered.
Just posting your patch on the ML is important and valuable. That
makes things easy when somebody else has the same problem. I
certainly remember seeing your original post, and I made note of it
for if I ever see that problem.
Cheers,
g.
^ permalink raw reply
* Re: [lm-sensors] [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
From: Jean Delvare @ 2005-06-09 18:21 UTC (permalink / raw)
To: Randy Vinson; +Cc: linuxppc-embedded, LM Sensors
In-Reply-To: <42A0CD46.60300@mvista.com>
Hi Randy,
Here are a few random comments on your code, sorry for the delay.
> +static struct i2c_client_address_data addr_data = {
> + .normal_i2c = normal_addr,
> + .normal_i2c_range = ignore,
> + .probe = ignore,
> + .probe_range = ignore,
> + .ignore = ignore,
> + .ignore_range = ignore,
> + .force = ignore,
> +};
Ranges are gone in -mm, please drop them. You should always base your
patches on -mm BTW, as this is what we will attempt to apply it against.
> +static ulong ds1374_read_rtc(void)
> +{
> + ulong time = 0;
> + int reg = DS1374_REG_WDALM0;
> +
> + while (reg--) {
> + s32 tmp;
> + if ((tmp = i2c_smbus_read_byte_data(save_client, reg)) < 0) {
> + dev_warn(&save_client->dev,
> + "can't read from rtc chip\n");
> + return 0;
> + }
> + time = (time << 8) | (tmp & 0xff);
& 0xff isn't needed.
> +ulong ds1374_get_rtc_time(void)
> +{
> + ulong t1, t2;
> + int limit = 10; /* arbitrary retry limit */
> +
> + down(&ds1374_mutex);
> +
> + /*
> + * Since the reads are being performed one byte at a time using
> + * the SMBus vs a 4-byte i2c transfer, there is a chance that a
> + * carry will occur during the read. To detect this, 2 reads are
> + * performed and compared.
> + */
> + do {
> + t1 = ds1374_read_rtc();
> + t2 = ds1374_read_rtc();
> + } while (t1 != t2 && limit--);
> +
> + up(&ds1374_mutex);
> +
> + if (t1 != t2) {
> + dev_warn(&save_client->dev,
> + "can't get consistent time from rtc chip\n");
> + t1 = 0;
> + }
> +
> + return t1;
> +}
> +
> +static void ds1374_set_tlet(ulong arg)
> +{
> + ulong t1, t2;
> + int limit = 10; /* arbitrary retry limit */
> +
> + t1 = *(ulong *) arg;
> +
> + down(&ds1374_mutex);
> +
> + /*
> + * Since the writes are being performed one byte at a time using
> + * the SMBus vs a 4-byte i2c transfer, there is a chance that a
> + * carry will occur during the write. To detect this, the write
> + * value is read back and compared.
> + */
> + do {
> + ds1374_write_rtc(t1);
> + t2 = ds1374_read_rtc();
> + } while (t1 != t2 && limit--);
> +
> + up(&ds1374_mutex);
> +
> + if (t1 != t2)
> + dev_warn(&save_client->dev,
> + "can't confirm time set from rtc chip\n");
> +}
The above two functions suggest that a continuous read from the chip
would be very welcome (see my previous message). I even doubt anyone
would connect this kind of RTC to a bus NOT supporting I2C block reads,
because then other models would make more sense. So I'd suggest you use
I2C block reads (and SMBus block writes) here. If anyone really needs a
different access method, they can add it afterwards. Doing so will make
your driver much faster, smaller and more simple.
Which bus are you using this chip BTW, some bit-banging I2C?
Oh, and the ulong* vs. ulong cast is really ugly. Can't it be done
differently?
> +ulong new_time;
Shouldn't it be static?
> +static int ds1374_probe(struct i2c_adapter *adap, int addr, int kind)
> +{
> + struct i2c_client *client;
> + int rc;
Here you should check whether the adapter supports the I2C/SMBus
commands you are about to throw upon it. See how the other i2c chip
drivers do.
> +
> + client = kmalloc(sizeof(struct i2c_client), GFP_KERNEL);
> + if (!client)
> + return -ENOMEM;
> +
> + memset(client, 0, sizeof(struct i2c_client));
> + strncpy(client->name, DS1374_DRV_NAME, I2C_NAME_SIZE);
> + client->flags = I2C_DF_NOTIFY;
This is a *driver* flag, not meaningful nor suitable for a client
structure. Where did you copy that from?
> + client->addr = addr;
> + client->adapter = adap;
> + client->driver = &ds1374_driver;
You should have some kind of chip detection at this point. Failing to do
so, you may catch any chip at this address and misdrive it. Detection of
these chips is always a bit tricky, but you could do the following:
* Check the 6 zero bits of status register.
* If there are other register-based assertions, use them (I have no time
to read the full datasheet).
* See what happens when you try to read past the register count (0x0A
and above) in either individual byte or block mode. Sometimes it wraps,
sometimes it returns an error, sometimes in repeats the last register,
depends on the chip. This is a trick, but very useful in this situation.
> +static int ds1374_detach(struct i2c_client *client)
> +{
> + int rc;
> +
> + if ((rc = i2c_detach_client(client)) == 0) {
> + kfree(i2c_get_clientdata(client));
> + tasklet_kill(&ds1374_tasklet);
> + }
You should kill the tasklet first, else it might try to use the client
after you freed it, right?
> +static struct i2c_driver ds1374_driver = {
> + .owner = THIS_MODULE,
> + .name = DS1374_DRV_NAME,
> + .id = I2C_DRIVERID_DS1374,
You don't need this ID, so you should just omit it. Also, it is
recommended to align structure declarations on the equal sign (using
tabs, not spaces), for a better readability.
Other comments:
1* Your driver construction makes it impossible to support more than one
device.
2* You seem to have two public functions in this driver, yet there is no
symbol export of these?
--
Jean Delvare
^ permalink raw reply
* Re: consistent_alloc() on 82xx
From: Dan Malek @ 2005-06-09 18:05 UTC (permalink / raw)
To: Pantelis Antoniou; +Cc: linuxppc-embedded
In-Reply-To: <42A7DE75.8040205@intracom.gr>
On Jun 9, 2005, at 2:15 AM, Pantelis Antoniou wrote:
> I may also need consistent_alloc for some testing reasons Dan. :)
No, you don't :-)
Thanks.
-- Dan
^ permalink raw reply
* Re: [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
From: Jean Delvare @ 2005-06-09 17:25 UTC (permalink / raw)
To: Randy Vinson; +Cc: LM, Sensors, linuxppc-embedded
In-Reply-To: <42A0D714.1050601@mvista.com>
Hi Randy and all,
Sorry for the delay.
[Eugene Surovegin]
> I wonder, why you chose to use those 1-byte SMBus transfers instead
> of i2c transfer.
[Randy Vinson]
> I was simply following the guidelines in
> Documentation/i2c/writing-clients as noted in the driver header. This
> note was in the driver I used as my base, so I just followed along.
The document file says:
"If you can choose between plain i2c communication and SMBus level
communication, please use the last. All adapters understand SMBus level
commands, but only some of them understand plain i2c!"
The "if you can choose" is important. It doesn't suggest that you should
use a less efficient way, but that you use the SMBus API when the I2C
transfer you want to use happens to exist in the SMBus API.
Even when sticking to SMBus commands, it is quite frequent that there
are different ways to retrieve the same information, of varying
availability and speed. One good example of this are EEPROMs. EEPROMs
are I2C devices which can be accessed using SMBus commands. You can read
bytes one by one (SMBus Read Byte Data command), or continuously as
different reads (first one SMBus Write Byte, then many SMBus Read Byte),
or continuously as a single read (I2C Block Read, supported by some
SMBus controllers). If you look at the eeprom.c drivers, you'll see that
the second and the third method are both implemented. The advantage is
that:
1* The SMBus Write/Read Byte method is supported by almost all SMBus and
all I2C masters.
2* The I2C Block Read method is twice as fast, and works on all true I2C
masters and a few SMBus masters.
So we get the best from each hardware configuration.
As I read the DS1374 datasheet, it appears to support all three modes
(it's a true I2C device) so you should be able to do something similar
to what is done in the eeprom driver.
> I checked http://secure.netroedge.com/~lm78/supported.html,
> http://secure.netroedge.com/~lm78/newdrivers.html and looked in the
> lm_sensors-2.9.1 tarball before I started and didn't see a driver for
> the DS1374 listed. That's why I threw mine together. Maybe I missed
> it.
The DS1374 isn't a hardware monitoring driver, so it doesn't have to be
listed here (although we happen to list a few miscellaneous drivers).
--
Jean Delvare
^ permalink raw reply
* Re: MPC52xx: sysfs failure on adding new device driver
From: Mark Chambers @ 2005-06-09 15:28 UTC (permalink / raw)
Cc: linuxppc-embedded
In-Reply-To: <20050609135509.AD5C2C1512@atlas.denx.de>
Sylvain:
> btw, if not yet integrated you should send your patch to Wolfang, he's
> the one maintaining that tree.
Wolfgang:
> I've seen the patch, but did not decide yet what to do with it. Many
> drivers don't support devfs anyway, and in my opinion devfs makes
> little sense in embedded systems anyway. Not to mention that it will
> officially be removed from the kernel tree in less than 4 weeks from
> now (see Documentation/feature-removal-schedule.txt).
This is nonsense. You know, when I made this patch I said
to myself, "Self, you're wasting your time, these guys won't take patches
from somebody they don't know" But I thought it was enough of a
no-brainer that it might go through.
Seems I was wrong.
Mark Chambers
^ permalink raw reply
* Re: MPC52xx: sysfs failure on adding new device driver
From: Kumar Gala @ 2005-06-09 15:20 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc05060907544d58da41@mail.gmail.com>
>> That changes the semantic of the driver names for the platform bus
>> however, making the dot a "special" char.
> Who needs to be asked about this? Should I take this discussion over
> the the LKML?
GregKH would be the person to talk to about the driver core and taking
this to LKML would be useful. We probably have a similar issue with
CPM comm channels.
I always assumed multiple drivers would get probed and the drivers
would fail in probe if they were not suppose to bind to the given
channel/psc, etc..
- kumar
^ permalink raw reply
* Re: RE : PPC arch and spinlocks
From: Geoff Levand @ 2005-06-09 15:19 UTC (permalink / raw)
To: �; +Cc: linuxppc-dev
In-Reply-To: <D4FDDD1349B5AC46B68FC26AD8AF42D6226B32@exnet.3il.fr>
� wrote:
> First of all,tks Jeff for this link.
> So reading that, I understood that I need to enable the SMP support in
> the makemenuconfig
> in order to use spinlocks even if I'm working on UP platform.
> That's what I did but I now go through compile errors (I'm using a
> montavista PE 3.1):
>
> In file included from
> /myWorks/en-cours/linux-2.4.20_mvl31/include/linux/smp.h:14,
> from ppc4xx_setup.c:34:
> /myWorks/en-cours/linux-2.4.20_mvl31/include/asm/smp.h:28: error:
> `NR_CPUS' undeclared here (not in a function)
> /myWorks/en-cours/linux-2.4.20_mvl31/include/asm/smp.h:30: error:
> `NR_CPUS' undeclared here (not in a function)
> /myWorks/en-cours/linux-2.4.20_mvl31/include/asm/smp.h:31: error:
> `NR_CPUS' undeclared here (not in a function)
> /myWorks/en-cours/linux-2.4.20_mvl31/include/asm/smp.h:31: embrouill�
> par les erreurs pr�c�dentes, abandon
> make[1]: *** [ppc4xx_setup.o] Erreur 1
> make[1]: Quitte le r�pertoire
> `/myWorks/en-cours/linux-2.4.20_mvl31/arch/ppc/kernel'
> make: *** [_dir_arch/ppc/kernel] Erreur 2
>
ppc4xx core doesn't support SMP.
^ permalink raw reply
* Re: R?f. : Re: Read in /dev/port with Segmentation Fault
From: Matt Porter @ 2005-06-09 14:58 UTC (permalink / raw)
To: scarayol; +Cc: linuxppc-embedded
In-Reply-To: <OFD05D82FF.63484065-ONC125701B.00332983@brime.fr>
On Thu, Jun 09, 2005 at 11:30:53AM +0200, scarayol@assystembrime.com wrote:
>
> Matt,
>
> then what is the use of /dev/port driver file ? When i do "cat /dev/port"
> on the standard console, i have also a segmentation fault.
Well, it's of no use on PPC. It's an x86-specific driver. It is simply
an alternative method to access x86 I/O ports. This is a hardware
construct that simply does not exist on PPC.
> Another question, if i use mmap to map physical addresses of I/O registers,
> could i dereference the pointer on virtual adresse to access data or should
> i use read/write on the file descriptor ?
Yes you can dereference, that's the point of mmaping I/O into userspace.
You may want to read Linux Device Drivers (either hardcopy or free
version online) for more details. If you google around you'll find
countless examples of people doing simple userspace driver work via
mmaped regs...those might help as a guideline.
-Matt
^ permalink raw reply
* Re: MPC52xx: sysfs failure on adding new device driver
From: Grant Likely @ 2005-06-09 14:54 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-embedded
In-Reply-To: <42A827DC.8000803@246tNt.com>
On 6/9/05, Sylvain Munaut <tnt@246tnt.com> wrote:
>=20
> Grant Likely wrote:
> >>From what I can tell, I should be able to register more than one
> > driver for a particular device name (mpc52xx_psc).
>=20
> I always assumed that yes.
> But now looking more closely, I'm not sure what I based that assumption
> on ... And if not the case that's indeed a problem because that's what's
> used to support the different function supported by the PSCs.
I was assuming so too, and it seems that the device structure would
support it. Who would know the answer to this?
>=20
> > Otherwise I would
> > need to change arch/ppc/syslib/mpc52xx_devices.c to have a different
> > name for each psc.
>=20
> No you shouldn't have to touch that. The
> mpc52xx_match_psc_function(idx, "spi") is there to know which driver
> should be used for what PSC and you're using it correctly so it _should_
> work.
I thought so, if I disable the mpc52xx_uart driver then my driver will
register correctly. I agree that it is not desireable to touch
mpc52xx_devices.c
>=20
> > If I change the sysfs code to ignore the failure
> > to create a directory then the driver seems to register fine.
>=20
> A "better" quick-fix would be to change the platform_match
> (drivers/platform.c) to support "sub-fonctions". For example when using
> mpc52xx_psc.spi it only matches what's before the dot (if any) with the
> device name.
... so that a different directory will be created in sysfs for each
driver? That's got possibilities.
>=20
> That changes the semantic of the driver names for the platform bus
> however, making the dot a "special" char.
Who needs to be asked about this? Should I take this discussion over
the the LKML?
Thanks,
g.
^ permalink raw reply
* Re: Read in /dev/port with Segmentation Fault : OK
From: scarayol @ 2005-06-09 14:55 UTC (permalink / raw)
To: stephane.fillod; +Cc: linuxppc-embedded
St=E9phane,
I used your file (in the Denx's FAQ) to mmap and access PPC I/O regist=
ers
using "/dev/mem" instead of "/dev/port". It works fine.
Thanks a lot for your help.
Sophie.
=
^ permalink raw reply
* Re: PPC arch and spinlocks
From: Hollis Blanchard @ 2005-06-09 14:13 UTC (permalink / raw)
To: Garcia Jérémie; +Cc: linuxppc-dev
In-Reply-To: <D4FDDD1349B5AC46B68FC26AD8AF42D6226B31@exnet.3il.fr>
On Jun 8, 2005, at 9:29 AM, Garcia J=E9r=E9mie wrote:
> I'm new to kernel device driver (linux newbie) and I'd like to control=20=
> concurrent access
> to our hardware resources. (I'm working on a ppc405EP platform=20
> uniprocessor)
> ...
> So, I decided to declare a spinlock in my module and offer, via ioctl,=20=
> the possibilty to user
> space programs to handle it with spin_trylock(), spin_lock() and=20
> spin_unlock().
I don't think this makes any sense. Kernel spinlocks are to protect=20
critical sections of kernel code from race conditions.
> I really need to have an equivalent of the spin_trylock() routine in=20=
> order not to have the processus waiting till the semaphore is=20
> available when tryin to get it. (ask and take if available, but not=20
> sleep).
It sounds like what you want is to enforce only a single user of your=20
device driver. If that's the case, you will need an atomic operation,=20
but if that fails then simply return an appropriate error code from=20
your open() routine.
You could use a spinlock like drivers/char/nvram.c:
static int
nvram_open(struct inode *inode, struct file *file)
{
spin_lock(&nvram_state_lock);
if ((nvram_open_cnt && (file->f_flags & O_EXCL)) || ...)
spin_unlock(&nvram_state_lock);
return -EBUSY;
}
...
nvram_open_cnt++;
spin_unlock(&nvram_state_lock);
return 0;
}
In this example, "nvram_open_cnt++" is one of the operations being=20
protected from race conditions, such as two processes on an SMP system=20=
both entering open() at literally the same time. Of course, since you=20
aren't building SMP, you know that there will not be two processes in=20
open() simultaneously, so the spinlocks will be compiled out, and you=20
will be left with a plain counter returning -EBUSY if the device is=20
already in use.
-Hollis=
^ permalink raw reply
* Re: MPC52xx: sysfs failure on adding new device driver
From: Wolfgang Denk @ 2005-06-09 13:55 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: linuxppc-embedded
In-Reply-To: <42A828B7.4030305@246tNt.com>
In message <42A828B7.4030305@246tNt.com> Sylvain Munaut wrote:
>
> Don't think so. Your patch applies to the 2.4 while Grant problem is
> specific to the way the different functions of PSCs are handled to work
> the 2.6 ppc_sys model.
>
> btw, if not yet integrated you should send your patch to Wolfang, he's
> the one maintaining that tree.
I'm subscribed here, too :-)
I've seen the patch, but did not decide yet what to do with it. Many
drivers don't support devfs anyway, and in my opinion devfs makes
little sense in embedded systems anyway. Not to mention that it will
officially be removed from the kernel tree in less than 4 weeks from
now (see Documentation/feature-removal-schedule.txt).
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Man is the best computer we can put aboard a spacecraft ... and the
only one that can be mass produced with unskilled labor.
-- Wernher von Braun
^ permalink raw reply
* Re: [UPDATE] Getting ownership for various boards/platforms configs
From: Kyle McMartin @ 2005-06-09 13:07 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Linux PPC Embedded list
In-Reply-To: <d0e588f233a722f3175a48a7fe146c0f@freescale.com>
On Tue, Jun 07, 2005 at 04:47:35PM -0500, Kumar Gala wrote:
> ep405
>
I can take care of this.
Regards,
Kyle McMartin
^ permalink raw reply
* Re: MPC52xx: sysfs failure on adding new device driver
From: Sylvain Munaut @ 2005-06-09 11:32 UTC (permalink / raw)
To: Mark Chambers; +Cc: linuxppc-embedded
In-Reply-To: <002201c56ce5$561a6c50$0301a8c0@chuck2>
Hi Mark
Mark Chambers wrote:
>>I'm working on an MPC52xx SPI device driver using one of the PSC.
>>However, when I call driver_register() I get a failure (-17, EEXISTS)
>>with a traceback (posted below).
>
>
> Hey Grant,
>
> This sounds exactly like a problem I had with PSC with devfs. I posted
> a patch here on 5/27, I bet you'll find it's a similar problem.
>
> (Let me know if you don't have access to that patch, I'll forward you my
> copy)
Don't think so. Your patch applies to the 2.4 while Grant problem is
specific to the way the different functions of PSCs are handled to work
the 2.6 ppc_sys model.
btw, if not yet integrated you should send your patch to Wolfang, he's
the one maintaining that tree.
Sylvain
^ permalink raw reply
* Re: MPC52xx: sysfs failure on adding new device driver
From: Sylvain Munaut @ 2005-06-09 11:28 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-embedded
In-Reply-To: <528646bc05060816514c2d5860@mail.gmail.com>
Grant Likely wrote:
> I'm working on an MPC52xx SPI device driver using one of the PSC.
> However, when I call driver_register() I get a failure (-17, EEXISTS)
> with a traceback (posted below).
>
> I've tracked it down to failing when trying to create a sysfs entry
> for the driver. It fails because sysfs tries to create a directory
> that already exists (mpc52xx_psc). The directory was already created
> when the psc serial port device driver was registered.
>
>>From what I can tell, I should be able to register more than one
> driver for a particular device name (mpc52xx_psc).
I always assumed that yes.
But now looking more closely, I'm not sure what I based that assumption
on ... And if not the case that's indeed a problem because that's what's
used to support the different function supported by the PSCs.
> Otherwise I would
> need to change arch/ppc/syslib/mpc52xx_devices.c to have a different
> name for each psc.
No you shouldn't have to touch that. The
mpc52xx_match_psc_function(idx, "spi") is there to know which driver
should be used for what PSC and you're using it correctly so it _should_
work.
> If I change the sysfs code to ignore the failure
> to create a directory then the driver seems to register fine.
A "better" quick-fix would be to change the platform_match
(drivers/platform.c) to support "sub-fonctions". For example when using
mpc52xx_psc.spi it only matches what's before the dot (if any) with the
device name.
That changes the semantic of the driver names for the platform bus
however, making the dot a "special" char.
Sylvain
^ permalink raw reply
* Re: MPC52xx: sysfs failure on adding new device driver
From: Mark Chambers @ 2005-06-09 11:21 UTC (permalink / raw)
To: Grant Likely, linuxppc-embedded
In-Reply-To: <528646bc05060816514c2d5860@mail.gmail.com>
>I'm working on an MPC52xx SPI device driver using one of the PSC.
>However, when I call driver_register() I get a failure (-17, EEXISTS)
>with a traceback (posted below).
Hey Grant,
This sounds exactly like a problem I had with PSC with devfs. I posted
a patch here on 5/27, I bet you'll find it's a similar problem.
(Let me know if you don't have access to that patch, I'll forward you my
copy)
Mark Chambers
^ permalink raw reply
* Re: Read in /dev/port with Segmentation Fault
From: scarayol @ 2005-06-09 10:05 UTC (permalink / raw)
To: Fillod Stephane; +Cc: linuxppc-embedded
Dear St=E9phane,
Yes i remember your mail about /dev/mem access. But, I never succeed to=
read or write physical memory with reliability so i wrote a driver and =
use
ioremap inside intead of mmap (before i put all the needed memory on I=
O
memory with the boot command "mem=3DxM" and then it works. So, i think =
i have
some problems with "mmap" :-).
I think my .../char/mem.c is OK for mmap support.
Why is it necessary to use size+ofs_addr for size and page_addr instead=
of
physaddr, i thought mmap( ) do it itself ?
Thank you for your help.
Kenavo.
Sophie.
=
=
=20
"Fillod Stephane" =
=
=20
<stephane.fillod@th Pour : <scarayol@assyst=
embrime.com> =
=20
omson.net> cc : <linuxppc-embedd=
ed@ozlabs.org> =
=20
Objet : RE: R=E9f. =
: Re: Read in /dev/port with Segmentation Fault =
=20
09/06/05 11:35 =
=
=20
=
=
=20
=
=
=20
Sophie CARAYOL wrote:
>Another question, if i use mmap to map physical addresses of I/O
registers,
>could i dereference the pointer on virtual adresse to access data or
should
>i use read/write on the file descriptor ?
Yes, you can dereference the pointer.
Don't you remember my past mail?
>From the Denx's FAQ (TFQ hits the list monthly) for accessing memory bu=
s:
http://www.denx.de/twiki/bin/view/PPCEmbedded/DeviceDrivers#Section_Acc=
essingPeripheralsFromUserSpace
or shorter: http://tinyurl.com/6c7th
See linux/drivers/char/mem.c to check if mmap support is ok on your arc=
h.
Kenavo
--
St=E9phane
=
^ permalink raw reply
* RE: Réf. : Re: Read in /dev/port with Segmentation Fault
From: Fillod Stephane @ 2005-06-09 9:35 UTC (permalink / raw)
To: scarayol; +Cc: linuxppc-embedded
Sophie CARAYOL wrote:
>Another question, if i use mmap to map physical addresses of I/O =
registers,
>could i dereference the pointer on virtual adresse to access data or =
should
>i use read/write on the file descriptor ?
Yes, you can dereference the pointer.
Don't you remember my past mail?
>From the Denx's FAQ (TFQ hits the list monthly) for accessing memory =
bus:
http://www.denx.de/twiki/bin/view/PPCEmbedded/DeviceDrivers#Section_Acces=
singPeripheralsFromUserSpace
or shorter: http://tinyurl.com/6c7th
See linux/drivers/char/mem.c to check if mmap support is ok on your =
arch.
Kenavo
--=20
St=E9phane
^ permalink raw reply
* RE : PPC arch and spinlocks
From: Garcia Jérémie @ 2005-06-09 9:28 UTC (permalink / raw)
To: jeff; +Cc: linuxppc-dev
First of all,tks Jeff for this link.=20
So reading that, I understood that I need to enable the SMP support in =
the makemenuconfig
in order to use spinlocks even if I'm working on UP platform.
That's what I did but I now go through compile errors (I'm using a =
montavista PE 3.1):
In file included from =
/myWorks/en-cours/linux-2.4.20_mvl31/include/linux/smp.h:14,
from ppc4xx_setup.c:34:
/myWorks/en-cours/linux-2.4.20_mvl31/include/asm/smp.h:28: error: =
`NR_CPUS' undeclared here (not in a function)
/myWorks/en-cours/linux-2.4.20_mvl31/include/asm/smp.h:30: error: =
`NR_CPUS' undeclared here (not in a function)
/myWorks/en-cours/linux-2.4.20_mvl31/include/asm/smp.h:31: error: =
`NR_CPUS' undeclared here (not in a function)
/myWorks/en-cours/linux-2.4.20_mvl31/include/asm/smp.h:31: embrouill=E9 =
par les erreurs pr=E9c=E9dentes, abandon
make[1]: *** [ppc4xx_setup.o] Erreur 1
make[1]: Quitte le r=E9pertoire =
`/myWorks/en-cours/linux-2.4.20_mvl31/arch/ppc/kernel'
make: *** [_dir_arch/ppc/kernel] Erreur 2
Is it a known problem for the montavista ppc users??
-------- Message d'origine--------
De: Jeff Angielski [mailto:jeff@theptrgroup.com]
Date: mer. 08/06/2005 17:26
=C0: Garcia J=E9r=E9mie
Cc: linuxppc-dev@ozlabs.org
Objet : Re: PPC arch and spinlocks
=20
On Wed, 2005-06-08 at 16:29 +0200, Garcia J=E9r=E9mie wrote:
> Hi everybody, I need your help one more time.
> I'm new to kernel device driver (linux newbie) and I'd like to control =
concurrent access
> to our hardware resources. (I'm working on a ppc405EP platform =
uniprocessor)
You might find this guide useful:
http://www.kernelnewbies.org/documents/kdoc/kernel-locking/lklockingguide=
.html
Jeff Angielski
The PTR Group
^ 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