Hello LKML
LKML
http://chanathleticassociationbaseball.assn.la/Goto.asp?URL=https://bit.ly/2KAzcan&AssocID=12781
Mark Underwood
--
Importance is one of the most important of our illusions. - Herbert Salzer
[no subject]
hi LKML http://www.ferolux.com/index_1.php?difficult=px2b7cae2fa4g7 Mark
hello LKML
Good morning LKML http://jyt.org.uk/valuable.php?theres=khya20h4t8hkzymt2 Mark
Re: SPI redux ... driver model support
--- Grant Likely <[EMAIL PROTECTED]> wrote: > On 9/8/05, David Brownell <[EMAIL PROTECTED]> > wrote: > > That implies whoever is registering is actually > going and creating the > > SPI devices ... and doing it AFTER the controller > driver is registered. > > I actually have issues with each of those > implications. > > > > However, I was also aiming to support the model > where the controller > > drivers are modular, and the "add driver" and > "declare hardware" steps > > can go in any order. That way things can work > "just like other busses" > > when you load the controller drivers ... and the > approach is like the > > familiar "boot firmware gives hardware description > tables to the OS" > > approach used by lots of _other_ hardware that > probes poorly. (Except > > that Linux is likely taking over lots of that > "boot firmware" role.) > To clarify/confirm what your saying: > > (I'm going to make liberal use of stars to hilight > "devices" and > "drivers" just to make sure that a critical word > doesn't get > transposed) > > There should be four parts to the SPI model: > 1. SPI bus controller *devices*; attached to another > bus *instance* > (ie. platform, PCI, etc) > 2. SPI bus controller *drivers*; registered with the > other bus > *subsystem* (platform, PCI, etc) > 3. SPI slave *devices*; attached to a specifiec SPI > bus *instance* > 4. SPI slave *drivers*; registered with the SPI > *subsystem* > > a. SPI bus controller *drivers* and slave *drivers* > can be registered > at any time in any order > b. SPI bus controller *devices* can be attached to > the bus subsystem at any time > c. SPI bus controller *drivers* attach to bus > controller *devices* to > create new spi bus instances whenever the driver > model makes a 'match' > d. SPI slave devices can be attached to an SPI bus > instance only after > that bus instance is created. > e. SPI slave *drivers* attach to SPI slave *devices* > when the driver > model makes a match. (let's call it an SPI slave > instance) > f. Unregistration of any SPI bus controller *driver* > or *device* will > cause attached SPI bus instance(s) and any attached > devices to go away > g. Unregistration of any SPI slave *driver* or > *device* will cause SPI > slave instance to go away. > > [pretty much exactly how the driver model is > supposed to work I guess :) ] > > Ideally controller drivers, controller devices, > slave drivers and > slave devices are all independent of each other. > The board setup code > will probably take care of attaching devices to > busses independent of > the bus controller drivers and spi slave drivers. > Driver code is > responsible for registering itself with the SPI > subsystem. > > If this is what your saying, then I *strongly* > second that opinion. > If not, then what is your view? > > I've been dealing with the same problems on my > project. Just for > kicks, here's another implementation to look at. > > http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019259.html > http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019260.html > http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019261.html > http://ozlabs.org/pipermail/linuxppc-embedded/2005-July/019262.html > > It also is not based on i2c in any way and it tries > ot follow the > device model. It solves my problem, but I've held > off active work on > it while looking at the other options being > discussed here. Another interesting proposal :), although it doesn't address the platform abstraction issue along with some others which people have raised in reply to your posts. It's good to see other people interested in this, if we can get up enough people then maybe we can push a SPI subsystem into the kernel :). Mark > > Thanks, > g. > - > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > Send instant messages to your online friends http://uk.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SPI redux ... driver model support
--- David Brownell <[EMAIL PROTECTED]> wrote: > > Date: Wed, 7 Sep 2005 19:38:43 +0100 (BST) > > From: Mark Underwood <[EMAIL PROTECTED]> > > ... > > > > I see several posabiltiys of how SPI devices could > be > > connected to an adapter. > > Certainly, and all are addressed cleanly by the kind > of > configuration scheme I showed. And by my scheme :) > > > > 1) All SPI devices are hardwired to the adapter. I > > think this would be the most common. > > For custom hardware, not designed for expansion, > yes. Zaurus Corgi > models, for example, keep three SPI devices busy. > > But in that category I'd also include custom > hardware that happens to > be packaged by connecting boards, which is also the > territory of #2 or > #3 below. "Hard wired" can include connectors that > are removable by > breaking the warranty. :) > > > > 2) Some SPI devices are hardwired and some are > > removable. > > Development/Evaluation boards -- the reference > implementations in most > environments, not just Linux -- seem to all but > universally choose this > option (or, more rarely, #3). There might be some > domain-specific chips > hardwired (touchscreen or CAN controller, ADC/DAC, > etc), but expansion > connectors WILL expose SPI. > > That makes sense; one goal is to support system > prototyping, and it's > hard to do that if for any reason one of the major > hardware connectivity > options is hard to get at! > > > > 3) All SPI devices are removable. > > This is common for the sort of single board > computers that get sold > to run Linux (or whatever) as part of semicustom > hardware: maybe not > much more than a few square inches packed with an > SOC CPU, FLASH, RAM, > and expansion connectors providing access to a few > dozen SOC peripherals. > (There might be 250 or so SOC pins, with expansion > connectors providing > access to some big portion of those pins ... > including some for SPI.) > > It'd be nice to be able to support those SBCs with a > core Linux port, > and then just layer support for addon boards on top > of that without > needing to touch a line of arch code. And > convenient for folk who > are adding value through those addons. :) > And with my subsystem you don't can to change any arch code, yay again! :) > > > > When you plug a card in you use > > spi_device_register to add that device to the > system > > and when you remove the card you call > > spi_device_unregister. You can then do the same > for a > > different card and at no time have you changed the > > declaration of the controller. > > That implies whoever is registering is actually > going and creating the > SPI devices ... and doing it AFTER the controller > driver is registered. > I actually have issues with each of those > implications. But how can you have a device that has no connection to the system (i.e. no registered adapter) :(. Why would you want to add SPI devices to adapters which aren't yet in the system? > > However, I was also aiming to support the model > where the controller > drivers are modular, and the "add driver" and > "declare hardware" steps > can go in any order. That way things can work "just > like other busses" My subsystem does that. Once you have registered the core layer you can add SPI device drivers before or after registering SPI devices the only restriction is the you have to register a SPI adapter before registering any SPI devices which use that adapter. I think this is sensible as otherwise you have to keep a list of all SPI devices that have been registered and didn't have an adapter at that time and go through this list every time you register an adapter. This sounds like putting the cart before the horse ;). > when you load the controller drivers ... and the > approach is like the > familiar "boot firmware gives hardware description > tables to the OS" > approach used by lots of _other_ hardware that > probes poorly. (Except > that Linux is likely taking over lots of that "boot > firmware" role.) > > > > > I'll post a refresh of my patch that seems to me > to be > > > a much better match for those goals. The > refresh includes > > > some tweaks based on what you sent, but it's > still just > > > one KByte of overhead in the target ROM. :) > > Grr. I added sysfs attributes and an I/O utility > function, > and now it's a bit bigger than 1KByte. Especially > with > debugging enabled, it's nearer 1.5KB. The cu
Re: SPI redux ... driver model support
--- David Brownell <[EMAIL PROTECTED]> wrote:
> > With my subsystem that would look like:
> >
> > static const struct spi_cs_table
> > platform_spi1_cs_table[] = {
> > {
> > .name = "touchscreen",
> > .cs_no = 1,
> > .platform_data = NULL,
> > .flags = SPI_CS_IDLE_HIGH,
> > .cs_data = 0,
> > },
> > {
> > .name = "flash",
> > .cs_no = 3,
> > .platform_data = NULL,
> > .flags = SPI_CS_IDLE_HIGH,
> > .cs_data = 0,
> > },
> > };
>
> The problem scenario was that only one configuration
> is valid at a time ... it would have been clearer if
> both the add-on boards used CS1, so that device
> would
> be either ads7864 _or_ at25640a, but not both.
>
>
>
> > As far as I can see most SPI devices have fixed
> > wirering to an adapter as SPI is not really a
> hotplug
> > bus.
>
> That wiring can be through an expansion connector
> though, which
> is what I meant when I wrote that it's "vaguely
> hotplug-ish".
> Example, the mainboard could have some SPI devices
> hard-wired,
> on CS0 and CS2, while each different plugin board
> might add very
> different devices on CS1 and/or CS3.
>
> In any case, you were the one who also wanted to
> ship sample USB
> peripherals that acted as adapters to various SPI
> chips... so that
> bus adapters would really need to hotplug! :)
>
I see several posabiltiys of how SPI devices could be
connected to an adapter.
1) All SPI devices are hardwired to the adapter. I
think this would be the most common. In this case you
would register a cs table as part of the platform data
of the SPI adapter like in the example platform in my
patch. Note: this is even the case with a PCI or usb
based device as it is the adapter that is hotpluged
and not the SPI devices on that device.
2) Some SPI devices are hardwired and some are
removable. In this case these the hardwired ones would
be put in the cs table and the other SPI devices would
be registered by calling spi_device_register. I would
add a call in my core layer to which you could pass
the bus_id and it would pass back the adapters pointer
to put in the spi_device structure.
3) All SPI devices are removable. An empty cs table
would be used and SPI devices would be registered by
calling spi_device_register.
>
> > The subsystem does allow you to add extra devices
> that
> > aren't in the cs table if you want by calling
> > spi_device_register in which case you have to
> setup
> > the spi_device with the correct information.
>
> Right, but as I had explained, the scenario is that
> the
> SPI devices are on some easily-swapped add-on card.
> That's a common physical arrangement for small
> embeddable
> boards, because it takes so few wires per device.
>
> Swapping those SPI connectors shouldn't involve
> changing
> the declaration of the controller on the mainboard
> ...
Your not when you use spi_device_register /
spi_device_unregister. You can register an adapter
with an empty cs table if you don't have any hardwired
SPI devices. When you plug a card in you use
spi_device_register to add that device to the system
and when you remove the card you call
spi_device_unregister. You can then do the same for a
different card and at no time have you changed the
declaration of the controller.
>
>
> > > One reason I posted this driver-model-only patch
> was
> > > to highlight how
> > > minimal an SPI core can be if it reuses the
> driver
> > > model core. I'm
> > > not a fan of much "mid-layer" infrastructure in
> > > driver stacks.
> > >
> >
> > This is what my SPI core tries to do. I would like
> to
> > make at 'as small as possible and no smaller'
>
> I'll post a refresh of my patch that seems to me to
> be
> a much better match for those goals. The refresh
> includes
> some tweaks based on what you sent, but it's still
> just
> one KByte of overhead in the target ROM. :)
OK. I will post an updated version of my SPI subsystem
within the next few days with the transfer stuff added
and maybe the interrupt and GPO abstraction as well.
I haven't seen any replies to my SPI patch :( did you
reply to it?
Mark
>
> - Dave
>
>
___
To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre. http://uk.security.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SPI redux ... driver model support
--- David Brownell <[EMAIL PROTECTED]> wrote:
> > > > I did think about doing this but the problem
> is how do
> > > > you know bus 2 is the bus you think it is?
> > >
> > > The numbering is board-specific, but in most
> cases
> > > that can be simplified to being SOC-specific.
> ...
> > >
> > > Hotpluggable SPI controllers are not common, but
> > > that's where that sysfs API to define new
> devices
> > > would really hit the spot. ...
> > >
> > > (What I've seen a bit more often is that
> expansion
> > > cards will be wired for SPI, so the thing that's
> > > vaguely hotplug-ish is that once you know what
> > > card's hooked up, you'll know the SPI devices it
> > > has. Then the question is how to tell the
> kernel
> > > about them ... same solution, which again must
> work
> > > without hardware probing.)
> >
> > This is why I decided to pass the cs table as
> platform
> > data when an adapter is registered. This way you
> don't
> > have to try to find out an adapters bus number as
> the
> > adapter has the cs table in it, but because it was
> > passed in as platform data it still abstracts that
> > from the adapter driver. Simple, yet effective :)
>
> Except that it doesn't work in that primary case,
> where the SPI devices
> are physically decoupled from any given SPI (master)
> controller.
> One expansion card uses CS1 for a touchscreen;
> another uses CS3 for
> SPI flash ... the same "cs table" can't handle both
> configurations.
> It's got to be segmented, with devices separated
> from controllers.
With my subsystem that would look like:
static const struct spi_cs_table
platform_spi1_cs_table[] = {
{
.name = "touchscreen",
.cs_no = 1,
.platform_data = NULL,
.flags = SPI_CS_IDLE_HIGH,
.cs_data = 0,
},
{
.name = "flash",
.cs_no = 3,
.platform_data = NULL,
.flags = SPI_CS_IDLE_HIGH,
.cs_data = 0,
},
};
As far as I can see most SPI devices have fixed
wirering to an adapter as SPI is not really a hotplug
bus.
The subsystem does allow you to add extra devices that
aren't in the cs table if you want by calling
spi_device_register in which case you have to setup
the spi_device with the correct information.
>
> Plus, that depends on standardizing platform_data
> between platforms.
> That's really not the model for platform_data! And
> "struct clk" is
> ARM-only for now, too ...
The struct clk should have been removed, I missed it
on that tidy up.
Why not pass platform data through the platform_data
pointer? I have now provided an extra field now which
lets you pass in any other platform data.
>
>
> > Have you looked at the patch which I sent?
> >
>
http://www.ussg.iu.edu/hypermail/linux/kernel/0509.0/0817.html
> >
> > I would appreciate any comments on this approach.
>
> Yes, I plan to follow up to that with comments. As
> with Dmitry's
> proposal, it's modeled closely on I2C, and is in
> consequence larger
> than needed for what it does.
I hope not, I spent a long time learning about the
features of the 2.6 driver model. I'm happy to trim
down any fat.
>
> One reason I posted this driver-model-only patch was
> to highlight how
> minimal an SPI core can be if it reuses the driver
> model core. I'm
> not a fan of much "mid-layer" infrastructure in
> driver stacks.
>
This is what my SPI core tries to do. I would like to
make at 'as small as possible and no smaller'
Mark
> - Dave
>
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Send instant messages to your online friends http://uk.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: SPI redux ... driver model support
--- David Brownell <[EMAIL PROTECTED]> wrote:
> > > @@ -193,6 +193,34 @@
> > >
> > > #ifdef CONFIG_OMAP_OSK_MISTRAL
> > >
> > > +#include
> > > +
> > > +struct ads7864_info {/* FIXME put in standard
> header */
> > > + u16 pen_irq, busy; /* GPIO lines */
> > > + u16 x_ohms, y_ohms;
> > > +};
> > > +
> > > +static struct ads7864_info mistral_ts_info = {
> > > + .pen_irq= OMAP_GPIO_IRQ(4),
> > > + .busy = /* GPIO */ 6,
> > > + .x_ohms = 419,
> > > + .y_ohms = 486,
> > > +};
> > > +
> > > +static const struct spi_board_info
> mistral_boardinfo[] = {
> > > +{
> > > + /* MicroWire CS0 has an ads7846e with
> touchscreen and
> > > + * other sensors. It's currently glued into
> some OMAP
> > > + * touchscreen support that ignores the driver
> model.
> > > + */
> > > + .driver_name= "ads7846",
> > > + .platform_data = &mistral_ts_info,
> > > + .max_speed_hz = 200,
> > > + .bus_num= 2,/* spi2 == microwire */
> >
> > I did think about doing this but the problem is
> how do
> > you know bus 2 is the bus you think it is?
>
> The numbering is board-specific, but in most cases
> that can be simplified
> to being SOC-specific. In this case I numbered the
> SPI-capable controllers
> (from 1..7, not included in this patch) and this one
> came out "2". The
> consistency matters, not the actual (nonzero)
> numbers.
>
> Hotpluggable SPI controllers are not common, but
> that's where that sysfs
> API to define new devices would really hit the spot.
> That would be how the
> kernel learns about "struct spi_board_info"
> structures associated with some
> dynamically assigned bus_num. Likely some
> convention for dynamically
> assigned IDs would help, like "they're all
> negative".
>
> (What I've seen a bit more often is that expansion
> cards will be wired
> for SPI, so the thing that's vaguely hotplug-ish is
> that once you know
> what card's hooked up, you'll know the SPI devices
> it has. Then the
> question is how to tell the kernel about them ...
> same solution, which
> again must work without hardware probing.)
>
This is why I decided to pass the cs table as platform
data when an adapter is registered. This way you don't
have to try to find out an adapters bus number as the
adapter has the cs table in it, but because it was
passed in as platform data it still abstracts that
from the adapter driver. Simple, yet effective :)
Have you looked at the patch which I sent?
http://www.ussg.iu.edu/hypermail/linux/kernel/0509.0/0817.html
I would appreciate any comments on this approach.
>
> > This would
> > work for SPI adapters that are platform devices,
> but
> > what about hot-plug devices like PCI and USB (we
> are
> > thinking of actually making a USB to SPI converter
> so
> > customers can try out some of our SPI devices on a
> PC
>
> Some of the microcontrollers that talk both USB
> (slave) and SPI (master)
> will even run Linux for you. :)
Yes, but not on a 8051 bassed Cypress USB chip ;)
>
> - Dave
>
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
___
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
http://uk.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC][PATCH] SPI subsystem
e more of what is going
+ on.
+
+config SPI_DEBUG_BUS
+ bool "SPI Bus debugging messages"
+ depends on SPI
+ help
+ Say Y here if you want the SPI bus drivers to produce a bunch of
+ debug messages to the system log. Select this if you are having
+ a problem with SPI support and want to see more of what is going
+ on.
+
+config SPI_DEBUG_CHIP
+ bool "SPI Chip debugging messages"
+ depends on SPI
+ help
+ Say Y here if you want the SPI chip drivers to produce a bunch of
+ debug messages to the system log. Select this if you are having
+ a problem with SPI support and want to see more of what is going
+ on.
+
+endmenu
diff -uprN -X dontdiff linux-2.6.10.orig/drivers/spi/Makefile linux-2.6.10/drivers/spi/Makefile
--- linux-2.6.10.orig/drivers/spi/Makefile 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.10/drivers/spi/Makefile 2005-09-02 14:19:15.0 +0100
@@ -0,0 +1,10 @@
+#
+# Makefile for the SPI core.
+#
+
+obj-$(CONFIG_SPI) += spi-core.o
+obj-y+= busses/ chips/ algos/ test/
+
+ifeq ($(CONFIG_SPI_DEBUG_CORE),y)
+EXTRA_CFLAGS += -DDEBUG
+endif
diff -uprN -X dontdiff linux-2.6.10.orig/drivers/spi/algos/Kconfig linux-2.6.10/drivers/spi/algos/Kconfig
--- linux-2.6.10.orig/drivers/spi/algos/Kconfig 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.10/drivers/spi/algos/Kconfig 2005-09-02 14:04:49.0 +0100
@@ -0,0 +1,19 @@
+#
+# SPI algorithm device configuration
+#
+
+menu "SPI Algorithms"
+ depends on SPI
+
+config SPI_ALGOBIT
+ tristate "SPI bit-banging interfaces"
+ depends on SPI
+ help
+ This allows you to use a range of SPI adapters called bit-banging
+ adapters. Say Y if you own an SPI adapter belonging to this class
+ and then say Y to the specific driver for you adapter below.
+
+ This support is also available as a module. If so, the module
+ will be called spi-algo-bit.
+
+endmenu
diff -uprN -X dontdiff linux-2.6.10.orig/drivers/spi/algos/Makefile linux-2.6.10/drivers/spi/algos/Makefile
--- linux-2.6.10.orig/drivers/spi/algos/Makefile 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.10/drivers/spi/algos/Makefile 2005-09-02 14:05:34.0 +0100
@@ -0,0 +1,9 @@
+#
+# Makefile for the spi algorithms
+#
+
+obj-$(CONFIG_SPI_ALGOBIT) += spi-algo-bit.o
+
+ifeq ($(CONFIG_SPI_DEBUG_ALGO),y)
+EXTRA_CFLAGS += -DDEBUG
+endif
diff -uprN -X dontdiff linux-2.6.10.orig/drivers/spi/busses/Kconfig linux-2.6.10/drivers/spi/busses/Kconfig
--- linux-2.6.10.orig/drivers/spi/busses/Kconfig 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.10/drivers/spi/busses/Kconfig 2005-09-02 14:10:40.0 +0100
@@ -0,0 +1,17 @@
+#
+# SPI adapter(s) configuration
+#
+
+menu "SPI Hardware Bus support"
+ depends on SPI
+
+config SPI_BUS_TEST
+ tristate "Dummy SPI adapter used only for testing the subsystem"
+ depends on SPI
+ help
+ See above ;)
+
+ This support is also available as a module. If so, the module
+ will be called spi-bus-test.
+
+endmenu
diff -uprN -X dontdiff linux-2.6.10.orig/drivers/spi/busses/Makefile linux-2.6.10/drivers/spi/busses/Makefile
--- linux-2.6.10.orig/drivers/spi/busses/Makefile 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.10/drivers/spi/busses/Makefile 2005-09-02 14:11:35.0 +0100
@@ -0,0 +1,9 @@
+#
+# Makefile for the spi bus drivers.
+#
+
+obj-$(CONFIG_SPI_BUS_TEST) += spi-bus-test.o
+
+ifeq ($(CONFIG_SPI_DEBUG_BUS),y)
+EXTRA_CFLAGS += -DDEBUG
+endif
diff -uprN -X dontdiff linux-2.6.10.orig/drivers/spi/busses/spi-bus-test.c linux-2.6.10/drivers/spi/busses/spi-bus-test.c
--- linux-2.6.10.orig/drivers/spi/busses/spi-bus-test.c 1970-01-01 01:00:00.0 +0100
+++ linux-2.6.10/drivers/spi/busses/spi-bus-test.c 2005-09-02 17:08:39.0 +0100
@@ -0,0 +1,103 @@
+/*
+ * linux/driver/spi/busses/spi-test_adap.c - dummy example SPI adapter
+ * for un/registration demo only
+ *
+ * Copyright (C) 2005 Philips Semicondutors, All Rights Reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * Authors:
+ * Mark Underwood
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME "spi-test"
+
+
+static int spi_test_probe(struct device *dev);
+static int spi_test_remove(struct device *dev);
+
+/* Platform structures for 2.6.x */
+static struct device_driver spi_test_driver = {
+ .owner = THIS_MODULE,
+ .name = DRIVER_NAME,
+ .bus = &platform_bus_type,
+ .probe = spi_test_probe,
+ .remove = spi_test_remove,
+};
+
+
+static int spi_test_probe(struct device *dev)
+{
+ struct spi_adapter *sadap;
+ struct platform_device *pdev = to_platform_device(dev);
+ int stat;
+
+ printk("spi_test_probe\n");
+
+ sadap = kmalloc(sizeof(struct spi_adapter), GFP_KERNEL);
+ if(!sadap)
+ {
+ return -ENOMEM;
+ }
+ memset(sadap, 0, sizeof(struct spi_adapter));
+
+ sadap->s
Re: How to create patch statistics?
Thanks for all your quick responses. Cheers, Mark --- Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Fri, Sep 02, 2005 at 06:22:32PM +0100, Mark > Underwood wrote: > > > Sorry to ask such a n00b question, but how do you > > create the patch statistics that many people show > at > > the top of a patch set? I couldnt see it the the > > SubmittingPatches doc and google didnt help (or I > > dont know what to look for ;) > > diffstat -p1 -w72 /path/to/patch > > > Cheers, > > > > Mark > > cu > Adrian > > -- > >"Is there not promise of rain?" Ling Tan > asked suddenly out > of the darkness. There had been need of rain > for many days. >"Only a promise," Lao Er said. >Pearl S. Buck > - Dragon Seed > > ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How to create patch statistics?
Sorry to ask such a n00b question, but how do you create the patch statistics that many people show at the top of a patch set? I couldnt see it the the SubmittingPatches doc and google didnt help (or I dont know what to look for ;) Cheers, Mark ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: SPI redux ... driver model support
--- David Brownell <[EMAIL PROTECTED]> wrote:
> > Date: Wed, 31 Aug 2005 08:59:44 +0100 (BST)
> > From: Mark Underwood <[EMAIL PROTECTED]>
> >
> > --- David Brownell wrote:
> >
> > > The last couple times SPI frameworks came up
> here, some of the feedback
> > > included "make it use the driver model properly;
> don't be like I2C".
> > >
> > > In hopes that it'll be useful, here's a small
> SPI core with driver model
> > > support driven from board-specific tables
> listing devices. I expect the
> > > I/O call(s) could stand to change; but at least
> this one starts out right,
> > > based on async I/O. (There's a synchronous
> call; it's a trivial wrapper.)
> > >
> > > ...
> >
> > Well I guess great minds think alike ;-). After
> > looking though my SPI core layer I released that
> it in
> > no way reflected the new driver model (not
> surprising
> > as it was a copy of i2c-core.c) and I would
> probably
> > get laughed off the kernel mailing list if I sent
> it
> > as was ;-).
>
> That usually doesn't happen. You'd just be told
> "make it use the driver
> model properly; don't be like I2C." Though maybe
> there'd be a fiew
> other criticisms mixed in. :)
>
>
> > I am now writing a new spi-core.c which uses the
> new
> > driver model.
>
> How about just merging the code I sent? It's not
> large, and it solves
> that problem. I don't much care about the I/O model
> issues quite yet,
> though requirements for quick sensor captures
> (RPC-ish) would seem
> different from ones like reading bulk SPI flash
> data.
>
>
> > For registering an adapter:
> > 1) Register an adapter that has a cs table showing
> > where devices sit on the adapter.
>
> But how is the adapter driver itself supposed to
> know that?
It gets passed the cs table as part of its platform
data.
>
> That's what I addressed with my patch: the need for
> the config tables
> to be **independent** of controller (and protocol)
> code. It decouples
> all the board-specific tables from the drivers.
>
> (Example shown below.)
>
> The nightmare to avoid is this: EVERY time someone
> adds a new
> SPI-equipped board, working/debugged/stable drivers
> need to change,
> because the board-specific config data was never
> separated from the
> drivers. (And we know it can be, as shown in the
> patch I posted...)
Now I've fixed my version I'll have a more detailed
look.
>
> Ideally adding a new board means adding a source
> file for just that one
> board, with the relevent implementation parameters.
> Only when hardware
> guys do something funky should any driver need to
> change.
>
That's what happens in my SPI subsystem. The adapter
driver only knows how the driver the adapter. When a
adapter gets probed it has platform data passed to it
which contains a pointer to the cs table, the number
of entrys in the cs table and the pointer to a
function to control some GPIO(s) as cs for adapters
that dont have any built in.
>
> > 2) This causes spi-core to enumerate the devices
> on
> > the cs table and register them.
> >
> > For un-registering an adapter:
> > 1) Unregister an adapter
> > 2) This causes spi-core to remove all the children
> of
> > the adapter
>
> Right, that's all exactly as in the patch I posted,
> though I punted
> on the "unregister" path -- an exercise for the
> reader! -- because I
> wanted to focus on (a) the driver model structure,
> like where things
> land in sysfs, and (b) how to keep board-specific
> initialization code
> out of controller and protocol drivers.
OK. If you want I could do the same, that is send the
un/registration and sysfs code before I put the
transfer methods in. I have some dummy devices so you
can see what happens in sysfs.
>
> - Dave
>
>
> --- o26.orig/arch/arm/mach-omap1/board-osk.c
> 2005-08-27 02:11:45.0 -0700
> +++ o26/arch/arm/mach-omap1/board-osk.c 2005-08-27
> 18:44:20.0 -0700
> @@ -193,6 +193,34 @@ static struct
> omap_board_config_kernel o
>
> #ifdef CONFIG_OMAP_OSK_MISTRAL
>
> +#include
> +
> +struct ads7864_info {/* FIXME put in standard
> header */
> + u16 pen_irq, busy; /* GPIO lines */
> + u16 x_ohms, y_ohms;
> +};
> +
> +static struct ads7864_info mistral_ts_info = {
> + .pen_irq= OMAP_GPIO_IRQ(4),
> + .busy = /* GPIO */ 6,
> + .
Re: SPI redux ... driver model support
--- David Brownell <[EMAIL PROTECTED]> wrote: > The last couple times SPI frameworks came up here, > some of the feedback > included "make it use the driver model properly; > don't be like I2C". > > In hopes that it'll be useful, here's a small SPI > core with driver model > support driven from board-specific tables listing > devices. I expect the > I/O call(s) could stand to change; but at least this > one starts out right, > based on async I/O. (There's a synchronous call; > it's a trivial wrapper.) > > arch/arm/Kconfig |2 > drivers/Kconfig|2 > drivers/Makefile |1 > drivers/spi/Kconfig| 302 > + > drivers/spi/Makefile | 32 > drivers/spi/spi_init.c | 233 > ++ > include/linux/spi.h| 179 > ++ > 7 files changed, 751 insertions(+) > > Here's one instance of the sysfs "spi_host" class: > > [EMAIL PROTECTED] sys]# cd /sys/class > [EMAIL PROTECTED] class]# ls > i2c-adapter/ misc/ pcmcia_socket/ > spi_host/ usb_host/ > input/ mtd/ scsi_device/ tty/ > vc/ > mem/ net/ scsi_host/ usb/ > [EMAIL PROTECTED] class]# ls spi_host > spi2/ > [EMAIL PROTECTED] class]# ls -l spi_host/spi2 > drwxr-xr-x2 root root0 Aug 29 > 18:46 ./ > drwxr-xr-x3 root root0 Dec 31 > 1969 ../ > lrwxrwxrwx1 root root0 Aug 29 > 18:46 device -> > ../../../devices/platform/omap-uwire/ > [EMAIL PROTECTED] class]# > > Here are the real sysfs objects for that host and > its single child > (on chipselect 0). Notice that the device exists, > but is waiting for > driver-modelized ads7846 support (touchscreen and > other sensors): > > [EMAIL PROTECTED] class]# cd > /sys/devices/platform/omap-uwire > [EMAIL PROTECTED] omap-uwire]# ls > bus@driver@ power/ > spi2.0-ads7846/ > [EMAIL PROTECTED] omap-uwire]# ls -l spi* > lrwxrwxrwx1 root root0 Aug 29 > 18:46 bus -> ../../../../bus/spi/ > -r--r--r--1 root root 4096 Aug 29 > 18:46 modalias > drwxr-xr-x2 root root0 Aug 29 > 18:46 power/ > [EMAIL PROTECTED] omap-uwire]# cat spi*/modalias > ads7846 > [EMAIL PROTECTED] omap-uwire]# > > For your viewing pleasure, and without the broadast > flag that would > prevent further redistribution, a patch is appended. > > - Dave > > > - SNIP!! > This is the start of a small SPI framework that > started fresh, so it > doesn't continue the "i2c driver model mess". -= snip =- Well I guess great minds think alike ;-). After looking though my SPI core layer I released that it in no way reflected the new driver model (not surprising as it was a copy of i2c-core.c) and I would probably get laughed off the kernel mailing list if I sent it as was ;-). I am now writing a new spi-core.c which uses the new driver model. For registering an adapter: 1) Register an adapter that has a cs table showing where devices sit on the adapter. 2) This causes spi-core to enumerate the devices on the cs table and register them. For un-registering an adapter: 1) Unregister an adapter 2) This causes spi-core to remove all the children of the adapter I have a test adapter and a couple of test devices and am currently debugging a usage count problem. I will send a patch once I have a working system. Mark ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] improve i2c probing
Interestingly (we for me at least ;-) I have been working on an SPI subsystem that was/is a copy of the I2C subsystem with changes as SPI doesnt have a protocol like I2C. I am at the stage of tidying up the structures in the head files and looking at where they are used in the core layer. To me, what I have, like I2C, doesnt tie in very well with the new driver model (although Im not overly familiar with it, I think I finally understand platform devices :-). The current I2C core layer seems to be only registering a bus type and devices so you can see them in sysfs as none of the functions seem to do anything. I wonder how much work the new kernel subsystems can do for us to cut down the size of i2c-core (and thus also spi-core). I guess there is no escaping the fact that Im going to gave to do some more homework and study the code. Any thoughts or insights would be very welcome. Mark --- David Brownell <[EMAIL PROTECTED]> wrote: > Hmm, some of this resembles my prototype from last > month: > > > http://lists.lm-sensors.org/pipermail/lm-sensors/2005-July/013012.html > > Both ended up with new driver probe() methods > attaching to *devices* not > to busses, and used the probe signature the i2c core > already handles. > That helps eliminate one of the surprises hitting > anyone starting to use > the I2C driver stack. But not the more fundamental > one... > > What would you think about actually making I2C > probing work more like > standard driver model probing, instead? That is, > have the probe method > signature look like this: > > int probe(struct i2c_client *dev, void > *driver_data) > > In normal driver model usage, infrastructure creates > the devices, and the > device drivers just bind to them. But I2C doesn't > support that even for > the submodel where it's very appropriate: devices > that have been probed, > or which (as with platform_bus) were explicitly > declared to exist. > > I2C drivers would either continue the old school way > ... or could start > acting more like they do in other mainstream Linux > driver frameworks. > > - Dave > > > - > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi
--- [EMAIL PROTECTED] wrote: > Well I like this a bit better, but it's still in > transition from > the old I2C style stuff over to a newer driver model > based one. > (As other folk have noted, with the "bus" v. > "adapter" confusion.) > > - Can you make the SPI messages work with an async > API? > It suffices to have a callback and a "void *" > for the > caller's data. Those callbacks should be able > to start > the next stage of a device protocol request ... > e.g. the > first one issues some command bytes, and its > completion > callback starts the data transfer. (It's easy > to build > synchronous models over async ones; but not the > other way.) > > (I see Mark Underwood commented that he was > working with > one like that.) Yep. I'm doing some tidying up. The work is still in development but I'm trying to get some patches ready so people and compare and contrast :-). > > - The basic thing that bothers me is that, like > original I2C, > the roles and responsibilities here don't > correspond in any > consistent way to the driver model. For new > code like SPI, > there's no excuse for that to happen. > > - It should probably also not assume Linux can > only act in > the "master" role. SPI controllers are simple, > and often > can implement slave roles just as well. (This > is one of > several technical details that bother me...) I'm afraid my SPI subsystem doesn't either :-(. But it hopefully shouldn't be hard to add :-) > > > One thing I've been looking for in your posts about > SPI is an > example of how to configure a system using it. Some > examples > come quickly to mind (all Linux-based boards): > > * System 1 has one SPI bus with two chipselects > wired. > CS0 is for a DataFlash chip on the motherboard; > while > CS3 is a MMC/SD/SPI socket (cards can be > added/removed) > that's primarily used for DataFlash cards. > > * System 2 uses SPI to talk to to a multi function > chip, > with sensors for battery, temperature, and > touchscreen > (and others not used) as well as stereo audio > over what's > esentially an I2S channel. Plus an MMC/SD/SPI > socket, > not yet used in SPI mode (it'd use the MMC > controller in > SPI mode, not yet implemented or required). > > * System 3 uses SPI to talk to an AVR based > microcontroller, > using application-specific protocols to collect > sensor > data and to issue (robotics) commands. (AVR is > an 8-bit > microcontroller. In this case its firmware is > open, but > clearly not running under Linux. In other > cases, there's > no reason both sides can't run Linux.) > > Given that those SPI devices can't usefully be > probed, and that > things like some CAN drivers will cheerfully bind to > a DataFlash > device, how do you see systems like those getting > configured? > Lots of board-specific logic in the SPI bus and > device drivers? > (I'd hope to avoid that, though it clearly works!) > The way my subsystem gets around this is that each adaptor has a CS table which describes what clients are on what chip select. This is then used in the core layer to 'probe' for devices. If a match is found (the name of a client driver matches a name in the CS table) then the clients probe function gets called from which the client could also do some checking (like I2C) and if it is happy that it is talking to the device it was written for then it attaches the cline to the bus. > > Anyway, more detailed comments below. I'm afraid I > jumped > right to the end of your post, where you had the > highest level > overview I could find: the header. > Next time > it might be quicker to just review that part. :) > > I recently came across a FAQ entry that read "SPI is > actually a > lot simpler than for example I2C". True; but I > don't think it > looks that way yet in this API! Hmm, SPI as no protocol like I2C but, to me, that makes it harder as you can do more things with it. You also have different clock modes and speeds unlike I2C. > > - Dave > === message truncated === Hopefully more SPI patches coming soon. You have been warned :-) Mark ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.11.5 on R3912 problems
OK. Fixed this one myself :-), I had misunderstood the MIPS timer stuff and thus the kernel wasn't scheduling. Mark --- Mark Underwood <[EMAIL PROTECTED]> wrote: > Hi, > > I have now been trying to get Linux 2.6.11.5 (built > with gcc 3.3.3 and binutils 2.15.91.0.2) up and > running on my Helio PDA, a MIPS R3912 based ASSP > (the > emulator to be exact) and have been stuck at the > last > step for a while now :-(. > > The kernel runs up fine, the problem starts when > init > is started. Bellow is my kernel log up to freeing > init. > > Uncompressing > Linux > done, booting the kernel. > done decompressing kernel. > e_entry: 8016b000, e_ehsize: 52, e_phentsize 32, > e_phnum 2, > e_shentsize 40, e_shnum 25 > copying 0x10c320 bytes from file offset 0x80 to > address 0x8004 > zeroing from 8014c320 to to 8014c320, 0x0 bytes > copying 0x36084 bytes from file offset 0x10e000 to > address 0x8014e000 > zeroing from 80184084 to to 80198b58, 0x14ad4 bytes > done loading kernel, about to jump in! > mips_machgroup 0x0017, mips_machtype 0x > arcs_cmdline: root=1f01 console=ttyS0,115200n8 > Linux version 2.6.11.5 ([EMAIL PROTECTED]) (gcc version > 3.3.3) #297 Mon Jul 18 20:19 > :39 UTC 2005 > V nasty hack. The Emulator doesn't report which > subset > of the TX39 family it bel > ongs to :,-(. I hope the hardware does! > Forcing cpu type to CPU_TX3912 > CPU revision is: 2200 > Determined physical RAM map: > memory: 00267000 @ 00199000 (usable) > memory: 0040 @ 0200 (usable) > memory: 0020 @ 9fc0 (ROM data) > Built 1 zonelists > Kernel command line: root=1f01 > console=ttyS0,115200n8 > Primary instruction cache 1kB, linesize 16 bytes > Primary data cache 1kB, linesize 4 bytes > Synthesized TLB handler (17 instructions). > Synthesized TLB load handler fastpath (37 > instructions). > Synthesized TLB store handler fastpath (37 > instructions). > Synthesized TLB modify handler fastpath (29 > instructions). > PID hash table entries: 256 (order: 8, 4096 bytes) > r39xx_set_termios > Dentry cache hash table entries: 8192 (order: 3, > 32768 > bytes) > Inode-cache hash table entries: 4096 (order: 2, > 16384 > bytes) > Memory: 6168k/6556k available (981k kernel code, > 348k > reserved, 212k data, 104k > init, 0k highmem) > Mount-cache hash table entries: 512 (order: 0, 4096 > bytes) > Checking for 'wait' instruction... unavailable. > cpu_wait = 0x0 > Linux NoNET1.0 for Linux 2.6 > schedule = 0x801327f8. ret = 0 > Can't analyze prologue code at 80133ea0 > schedule_timeout = 0x80133ea0. ret = -1 > sleep_on = 0x8013395c. ret = 0 > sleep_on_timeout = 0x80133a54. ret = 0 > wait_for_completion = 0x80133148. ret = 0 > Serial: r39xx internal UART driver $ > r39xx_config_port > r39xx_request_port > ttyS0 at MMIO 0x0r39xx_type > (irq = 74) is a R39XX > io scheduler noop registered > io scheduler anticipatory registered > io scheduler deadline registered > io scheduler cfq registered > RAMDISK driver initialized: 16 RAM disks of 4096K > size > 1024 blocksize > loop: loaded (max 8 devices) > Helio Boot ROM: 0x0020 at 0x9fc0 > helio_mtd_map.virt 0x9fc0 > Helio Boot ROM: probing for ROM > Creating 2 MTD partitions on "Helio Boot ROM": > 0x-0x00097eec : "Bootloader + Kernel" > mtd: Giving out device 0 to Bootloader + Kernel > 0x00097eec-0x0013deec : "cramfs Filesystem" > mtd: Giving out device 1 to cramfs Filesystem > block2mtd: version $Revision: 1.23 $ > VFS: Mounted root (cramfs filesystem) readonly. > Freeing unused kernel memory: 104k freed > > I have had to write a UART driver so I thought the > problem might be with that so I put lots of debug in > tty layer, serial_core and my driver to see what was > going on. After doing this and changing the > interrupt > handler (int-handler.S) I saw the echo that I had > put > in my inittab. > So I started to remove debug and found it stopped > working. The strange thing is that it stops before > it > gets as far as sending the echo from inittab. > If I dont have enough debug the kernel stops just > before printing out: > > Algorithmics/MIPS FPU Emulator v1.5 > > When I connect to the emulator with GDB and look at > the registers I find the CPU is still running and is > in cpu_idle. > I wondered if it might be a timer/task scheduler > related problem but as it gets passed the bogomips > calculation the timer must be working. > > Any help would be great as I have been stuck here > for > a while. > > Many Thanks, > > Mark > &g
Re: Where is place of arch independed companion chips?
--- Richard Purdie <[EMAIL PROTECTED]> wrote: > On Mon, 2005-08-01 at 11:13 -0700, Greg KH wrote: > > > Good question. I was about to submit a patch > that created > > > drivers/platform because the toplevel driver for > MQ11xx is a > > > platform_device driver. Any thoughts on this? > > > > drivers/platform sounds good to me. > > In another thread (about the ucb1x00) we came up > with the idea of > drivers/mfd (mfd = multi function devices). > > The core and platform specific parts would live here > with suitable clear > naming and the subsection specific parts that were > separable would live > in the appropriate place within the kernel. > > Just another idea to add to the mix and removes the > dilemma of a > multifunction device with isn't platform based... This is where my sugguestion on the ucb1x00 comess in (although it seems to have ot lost as I have had no reply :-( ). To repeat myself: I was thinking of something like driver/bus into which we might also be able to put the I2C and LL3 buses. The only problem is that this might leave some parts of the multi function chip homeless (if they can't find a home in other subsystems). I need to do more homework ;-), but I think we need a bus driver (I need to see what the bus subsystem offers) (IP block specific, platform and arch independent), a core driver to register busses and clients, and client drivers. Mark > > Richard > > - > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] spi
--- dmitry pervushin <[EMAIL PROTECTED]> wrote:
>
> > Surely this should be locked with bus lock?
> Why not ? Until the transfer on device is not
> finished, the bus will be
> locked. Otherwise, the another device (on the same
> bus) might want to
> transfer something...
OK. My confusion was that we are also working on a SPI
subsystem which works in a different way.
Our SPI subsystem works much like the USB subsystem in
that drivers can queue up transfers and they will get
a callback when the transfer is complete.
Actually I think we have 4 modes of operation which
also allows transfers to be done in interrupt context,
with callback, wait for completion or high priority
(used to transfer high priority messages by bypassing
the transfer queue). I'll see if I can submit a patch
to the mailing list as I know its not only ideas but
code that counts ;-).
> >
> > -= snip =-
> >
> > Some other comments:
> > 1) I think you need to fix some of your comments
> > especially those describing how the interfaces
> work.
> > 2) I take it spi adaptor drivers now use
> > spi_bus_register/spi_bus_unregister?
> > 3) Different clients on one bus will want to run
> at
> > different speeds, how will you handle this?
> > 3) This subsystem can only handle small transfers
> like
> > I2C. SPI peripherals like SPI Ethernet devices
> will
> > have to do lots of large transfers and with your
> > current subsystem the device will be forced to
> wait
> > until its transfer has finished (as well as other
> > clients) when it might have other important work
> to
> > do.
> Hmm.. In the sample (it needs some polishing!), the
> bus initiates the
> DMA transfers and waits for completion on it. Do you
> want to have
> something like state machine (the function that will
> be called upon the
> end of transfer ?)
Yes, please see above.
>
>
> Kconfig | 12 +
> Makefile|7
> pnxalloc.c | 70 ++
> pnxalloc.h |9
> spi-pnx010x_atmel.c | 91
> spipnx-resources.h | 138
> spipnx.c| 581
>
>
> spipnx.h| 309
> +++
> 8 files changed, 1455 insertions(+)
>
> Index: linux-2.6.10/drivers/spi/spipnx-resources.h
>
===
> --- /dev/null
> +++ linux-2.6.10/drivers/spi/spipnx-resources.h
> @@ -0,0 +1,138 @@
> +#ifdef CONFIG_MACH_PNX0106_GH450
> +struct resource spipnx_010x_resources_0[] =
> +{
> + {
> + .start = BLAS_SPI0_BASE,
> + .end = BLAS_SPI0_BASE + SZ_4K,
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = SPI0_FIFO_DMA_SLAVE_NR,
> + .flags = IORESOURCE_DMA,
> + },
> + /*
> + * Note that the clocks are shutdown in this order
> and resumed
> + * in the opposite order.
> + */
> + {
> + .start = CGU_SWITCHBOX_BLAS_SPI0_PCLK_ID,
> + .flags = IORESOURCE_CLOCK_ID,
> + }, {
> + .start = CGU_SWITCHBOX_BLAS_SPI0_PCLK_GAT_ID,
> + .flags = IORESOURCE_CLOCK_ID,
> + }, {
> + .start = CGU_SWITCHBOX_BLAS_SPI0_FIFO_PCLK_ID,
> + .flags = IORESOURCE_CLOCK_ID,
> + }, {
> +.start =
> CGU_SWITCHBOX_BLAS_SPI0_DUMMY_VPBCLK_ID,
> + .flags = IORESOURCE_CLOCK_ID,
> + }, {
> + .start = VH_INTC_INT_NUM_BLAS_SPI0_INT,
> + .flags = IORESOURCE_IRQ,
> + }, {
> +.flags = 0,
> + }
> +};
> +
> +struct resource spipnx_010x_resources_1[] =
> +{
> + {
> + .start = BLAS_SPI1_BASE,
> + .end = BLAS_SPI1_BASE + SZ_4K,
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = SPI1_FIFO_DMA_SLAVE_NR,
> + .flags = IORESOURCE_DMA,
> + },
> + /*
> + * Note that the clocks are shutdown in this order
> and resumed
> + * in the opposite order.
> + */
> + {
> + .start = CGU_SWITCHBOX_BLAS_SPI1_PCLK_ID,
> + .flags = IORESOURCE_CLOCK_ID,
> + }, {
> +.start = CGU_SWITCHBOX_BLAS_SPI1_PCLK_GAT_ID,
> +.flags = IORESOURCE_CLOCK_ID,
> + }, {
> + .start = CGU_SWITCHBOX_BLAS_SPI1_FIFO_PCLK_ID,
> + .flags = IORESOURCE_CLOCK_ID,
> + }, {
> +.start =
> CGU_SWITCHBOX_BLAS_SPI1_DUMMY_VPBCLK_ID,
> + .flags = IORESOURCE_CLOCK_ID,
> + }, {
> + .start = VH_INTC_INT_NUM_BLAS_SPI1_INT,
> + .flags = IORESOURCE_IRQ,
> + }, {
> +.flags = 0,
> + }
> +};
> +#endif
> +
> +#ifdef CONFIG_MACH_PNX0105_GH448
> +struct resource spipnx_010x_resources[] =
> +{
> + {
> + .start = BLAS_SPI_BASE,
> + .end = BLAS_SPI_BASE + SZ_4K,
> + .flags = IORESOURCE_MEM,
> + }, {
> + .start = BLAS_SPI_DMA_SLAVE_NR,
> + .flags = IORESOURCE_DMA,
> + },
> + /*
> + * Note that the clocks are shutdown in this order
> and resumed
> + * in the opposite order.
> + */
> + {
> +.start
Re: [PATCH] spi
--- dmitry pervushin <[EMAIL PROTECTED]> wrote:
> Hello all,
>
>
> Here is the spi core patch (slightly redesigned
> again). Now it operates
> with three abstractions:
> a) the spi bus, which is registered in system and is
> resposible for
> general things like registering devices on it,
> handling PM events for
> entire bus, providing bus-wide operations;
> b) the spi device, which is responsible for
> interactions between the
> device and the bus (selecting/deselecting device)
> and PM events for the
> specifi device;
> c) the driver, which is attached to spi devices and
> (possibly) provide
> interface to the upper level like block device
> interface. The spi-dev is
> the good starting point for people who does not want
> anything but simple
> character device access.
> The new abstraction is the spi bus, which
> functionality was represented
> by spi_device structure.
>
> Especially for Greg K-H: yes, I ran this code
> through sparse :), thank
> you.
>
Please can we have an example client driver as it
would aid understanding :-). But in the mean time.
-= snip =-
+/**
+ * spi_add_adapter - register a new SPI bus adapter
+ * @spidev: spi_device structure for the registering
adapter
+ *
+ * Make the adapter available for use by clients
using name
adap->name.
+ * The adap->adapters list is initialised by this
function.
+ *
+ * Returns error code ( 0 on success ) ;
+ */
+struct spi_bus* spi_bus_find( char* id )
+{
+ struct bus_type* the_bus = find_bus( id );
+
+ return the_bus ? container_of( the_bus, struct
spi_bus, the_bus ) :
NULL;
+}
Eh? The comment is for spi_add_adapter but the
function is spi_bus_find! Where is spi_add_adapter?
-= snip =-
+/**
+ * spi_del_adapter - unregister a SPI bus adapter
+ * @dev: spi_device structure to unregister
+ *
+ * Remove an adapter from the list of available SPI
Bus adapters.
+ *
+ * Returns error code (0 on success);
+ */
+
+void spi_device_del(struct spi_device *dev)
+{
+ device_unregister(&dev->dev);
+}
Eh? The comment is for spi_del_adapter but the
function is spi_device_del! Where is spi_del_adapter?
-= snip =-
+/**
+ * spi_transfer - transfer information on an SPI bus
+ * @adap: adapter structure to perform transfer on
+ * @msgs: array of spi_msg structures describing
transfer
+ * @num: number of spi_msg structures
+ *
+ * Transfer the specified messages to/from a device
on the SPI bus.
+ *
+ * Returns number of messages successfully
transferred, otherwise
negative
+ * error code.
+ */
+int spi_transfer(struct spi_device *dev, struct
spi_msg msgs[], int
num)
+{
+ int ret = -ENOSYS;
+ struct spi_bus* bus;
+
+ bus = TO_SPI_BUS( dev->dev.bus );
+
+ if (bus->xfer) {
+ down( &dev->lock );
+ ret = bus->xfer(bus, dev, msgs, num, 0);
+ up(&dev->lock);
+ }
+ return ret;
+}
Surely this should be locked with bus lock?
-= snip =-
Some other comments:
1) I think you need to fix some of your comments
especially those describing how the interfaces work.
2) I take it spi adaptor drivers now use
spi_bus_register/spi_bus_unregister?
3) Different clients on one bus will want to run at
different speeds, how will you handle this?
3) This subsystem can only handle small transfers like
I2C. SPI peripherals like SPI Ethernet devices will
have to do lots of large transfers and with your
current subsystem the device will be forced to wait
until its transfer has finished (as well as other
clients) when it might have other important work to
do.
Best Regards,
Mark
___
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail
http://uk.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
How do we handle multi-function devices? [was Re: [patch] ucb1x00: touchscreen cleanups]
--- Richard Purdie <[EMAIL PROTECTED]> wrote: > On Sun, 2005-07-31 at 23:11 +0100, Mark Underwood > wrote: > > As this isn't the only chip of this sort (i.e. a > > multi-function chip not on the CPU bus) maybe we > > should store the bus driver in a common place. If > > needed we could have a very simple bus driver > > subsystem (this might already be in the kernel, I > > haven't looked at the bus stuff) in which you > register > > a bus driver and client drivers register with the > bus > > driver. Just an idea :-). > > This was the idea with the drivers/soc suggestion > although I think that > name is perhaps misleading. > > How about drivers/mfd where mfd = Multi Functional > Devices? I was thinking of something like driver/bus into which we might also be able to put the I2C and LL3 buses. The only problem is that this might leave some parts of the multi function chip homeless (if they can't find a home in other subsystems). > > I think it would be acceptable (and in keeping with > the other drivers > e.g. pcmcia) to seeing the arch and platform > specific modules with the > main driver as long as the naming reflected it (like > the existing mcp > and ucb code does) i.e.: > > mcp-core.c > mcp-sa1100.c > ucb1x00-code.c > ucb1x00-assabet.c > ucb1x00-collie.c Maybe, I haven't looked at pcmcia but the I2C subsystem manages to avoid any arch dependent stuff so couldn't we? I need to do more homework ;-), but surely we only need a bus driver (IP block specific, platform and arch independent), a core driver to register busses and clients, and client drivers. > > If code can be separated out into subsystems, I'm > not so sure where they > should go though. The existing policy would suggest > drivers/input/touchscreen and sound/xxx for these... > > ucb1x00-ts.c > ucb1x00-audio.c Yes, any function of a multi function device that can live in a subsystem should do otherwise imagine the mess, for example, with a chip that has a USB master on it. Mark > > Opinions/Comments? > > Richard > > ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ucb1x00: touchscreen cleanups
--- Russell King <[EMAIL PROTECTED]> wrote: > On Sat, Jul 30, 2005 at 10:46:58PM +0200, Pavel > Machek wrote: > > Hi! > > > > > > > Note that I'm maintaining the code and will > be > > > > > publishing a new set > > > > > of patches for it based upon Pavel's fixes. > > > > > > > > Thanks. I'll check them out then. > > > > > > Since there appears to be some interest in > these, I'll set about > > > converting the audio bits to ALSA rather than > Nico's SA11x0 audio > > > driver. I thought no one was using these chips > anymore, and the > > > driver was dead! > > > > > > I've recently edited the mcp structure which may > make things less > > > awkward for others, and I'll continue moving in > that direction > > > with this driver. > > > > > > You can get the updated patches at: > > > > > > http://zeniv.linux.org.uk/pub/people/rmk/ucb/ > > > > Okay, what's the plan with mainstreaming those? Do > they stay in > > drivers/misc? > > Let me put the second question a slightly different > way: can anyone > think of a better way to organise the files which > makes more sense > and doesn't end up with just a couple of files for > the core UCB > and MCP support in some random directory elsewhere? > > Arjan? hch? any comments / good ideas? As this isn't the only chip of this sort (i.e. a multi-function chip not on the CPU bus) maybe we should store the bus driver in a common place. If needed we could have a very simple bus driver subsystem (this might already be in the kernel, I haven't looked at the bus stuff) in which you register a bus driver and client drivers register with the bus driver. Just an idea :-). Mark > > -- > Russell King > Linux kernel2.6 ARM Linux - > http://www.arm.linux.org.uk/ > maintainer of: 2.6 Serial core > - > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ucb1x00: touchscreen cleanups
--- Russell King <[EMAIL PROTECTED]> wrote: > On Tue, Jul 26, 2005 at 09:04:12AM +0100, Mark > Underwood wrote: > > I am in the process of porting Linux 2.6.11.5 to > the > > Helio PDA (MIPS R3912 based) and if I remember > > correctly it is using a UCB1x00 (or Toshiba > clone). > > Please could you make sure your patches will work > > across arch. > > Which UCB1x00 version? There's about three of them > - 1200, 1300 and > 1400. The 1200 and 1300 are non-AC'97 devices, > which are targetted > by this driver. It is the UCB1200 (also known as the Toshiba TC35143F or Betty). > > > Now I have my kernel up and running (well > > mainly falling :-() my next task is to get write > the > > frame buffer driver and then look at the UCB1x00 > as I > > need it for sound and touch screen. So in a day or > two > > I will start to try to integrate your work into my > > kernel. > > Note that I'm maintaining the code and will be > publishing a new set > of patches for it based upon Pavel's fixes. Thanks. I'll check them out then. > > -- > Russell King > Linux kernel2.6 ARM Linux - > http://www.arm.linux.org.uk/ > maintainer of: 2.6 Serial core > ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux tty layer hackery: Heads up and RFC
Hi Alan, Thanks for your help, I might give this ago once I've fixed some flow control problems in my driver. On a loosely related topic I have extended serial_core.c to handle DMA UARTS (only the TX path is effected). Once I'm happy with my changes I post a patch. Best Regards, Mark --- Alan Cox <[EMAIL PROTECTED]> wrote: > On Maw, 2005-07-26 at 10:55 +0100, Mark Underwood > wrote: > > What my driver would like to do is to handle its > own > > input buffers. It would pass the buffer to the tty > > layer when it is full and the tty layer would pass > the > > In theory you can do that already, although the > locking is a bit screwed > up for it. Actually all the tty locking is broken > for rx I believe. > Everyone should be holding the tty read lock when > updating flip buffers > but right now we don't > > > buffer back once it has drained the data from it. > > The problem is that I don't always receive a block > > worth of characters so I also need to pass the tty > > layer a buffer (which I'm still DMAing into) with > a > > count of how many chars there are in the buffer > and a > > offset of where to start from. > > You can do this now providing you don't do it > blindly from IRQ context. > > >From a workqueue do > > struct tty_ldisc *ld = tty_ldisc_ref(tty); > int space; > > if(ld == NULL) /* Bin/defer */ > return; > space = ld->receive_room(tty); > if(count > space) count = space; > > ld->receive_buf(tty, charbuf, flagbuf, count); > > > There is a corner case if TTY_DONT_FLIP is set where > you should queue > but not all drivers do this and the DONT_FLIP hack > 'has to die' > > - > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux tty layer hackery: Heads up and RFC
Hi Rogier, Having just written a DMA UART driver I can say this is good news :-). Here are some things to think about: What my driver would like to do is to handle its own input buffers. It would pass the buffer to the tty layer when it is full and the tty layer would pass the buffer back once it has drained the data from it. The problem is that I don't always receive a block worth of characters so I also need to pass the tty layer a buffer (which I'm still DMAing into) with a count of how many chars there are in the buffer and a offset of where to start from. If I can't do this then I have to stop the DMA transfer, pass you a mostly empty buffer with a char count, and setup DMA transfer into another buffer. If during this I get a burst of data I could well lose it :-(. Best Regards, Mark --- Rogier Wolff <[EMAIL PROTECTED]> wrote: > On Thu, Jul 21, 2005 at 06:46:32PM +0100, Alan Cox > wrote: > > int tty_prepare_flip_string(tty, strptr, len) > > > > Adjust the buffer to allow len characters to be > added. Returns a buffer > > pointer in strptr and the length available. This > allows for hardware > > that needs to use functions like insl or > mencpy_fromio. > > Ok, So then I start copying characters into the > flipstring, but how do > I say I'm done? > > Or is there a race between that I call > tty_prepare_flip_string, and > other processes start pulling my not-yet-filled > string from the > buffer? (Surely not!) > > Roger. > > -- > ** [EMAIL PROTECTED] ** > http://www.BitWizard.nl/ ** +31-15-2600998 ** > *-- BitWizard writes Linux device drivers for any > device you may have! --* > Q: It doesn't work. A: Look buddy, doesn't work is > an ambiguous statement. > Does it sit on the couch all day? Is it unemployed? > Please be specific! > Define 'it' and what it isn't doing. - > Adapted from lxrbot FAQ > - > To unsubscribe from this list: send the line > "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at > http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > ___ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ucb1x00: touchscreen cleanups
Hi Pavel,
I am in the process of porting Linux 2.6.11.5 to the
Helio PDA (MIPS R3912 based) and if I remember
correctly it is using a UCB1x00 (or Toshiba clone).
Please could you make sure your patches will work
across arch. Now I have my kernel up and running (well
mainly falling :-() my next task is to get write the
frame buffer driver and then look at the UCB1x00 as I
need it for sound and touch screen. So in a day or two
I will start to try to integrate your work into my
kernel.
Best Regards,
Mark
--- Pavel Machek <[EMAIL PROTECTED]> wrote:
> These are small ucb1x00-ts cleanups, as suggested by
> Vojtech, Dmitri
> and the lists.
>
> Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
>
> Cleanups suggested by Dmitri, Vojtech and lists.
>
> ---
> commit 79c98a2279c45098d102ba69ecf940c00da3dfee
> tree f15a3d27de9a84694f4588374a5e383938866a54
> parent 080578bff89927c0f5aeddd588bc2f5f7373f232
> author <[EMAIL PROTECTED](none)> Tue, 26 Jul 2005 09:44:33
> +0200
> committer <[EMAIL PROTECTED](none)> Tue, 26 Jul 2005
> 09:44:33 +0200
>
> drivers/misc/ucb1x00-ts.c | 87
> -
> 1 files changed, 23 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/misc/ucb1x00-ts.c
> b/drivers/misc/ucb1x00-ts.c
> --- a/drivers/misc/ucb1x00-ts.c
> +++ b/drivers/misc/ucb1x00-ts.c
> @@ -1,7 +1,8 @@
> /*
> - * linux/drivers/misc/ucb1x00-ts.c
> + * Touchscreen driver for UCB1x00-based
> touchscreens
> *
> * Copyright (C) 2001 Russell King, All Rights
> Reserved.
> + * Copyright (C) 2005 Pavel Machek
> *
> * This program is free software; you can
> redistribute it and/or modify
> * it under the terms of the GNU General Public
> License version 2 as
> @@ -30,6 +31,7 @@
> #include
> #include
> #include
> +#include
>
> #include
> #include
> @@ -42,10 +44,7 @@ struct ucb1x00_ts {
> struct ucb1x00 *ucb;
>
> wait_queue_head_t irq_wait;
> - struct semaphoresem;
> - struct completion init_exit;
> struct task_struct *rtask;
> - int use_count;
> u16 x_res;
> u16 y_res;
>
> @@ -55,20 +54,6 @@ struct ucb1x00_ts {
>
> static int adcsync;
>
> -static inline void ucb1x00_ts_evt_add(struct
> ucb1x00_ts *ts, u16 pressure, u16 x, u16 y)
> -{
> - input_report_abs(&ts->idev, ABS_X, x);
> - input_report_abs(&ts->idev, ABS_Y, y);
> - input_report_abs(&ts->idev, ABS_PRESSURE,
> pressure);
> - input_sync(&ts->idev);
> -}
> -
> -static inline void ucb1x00_ts_event_release(struct
> ucb1x00_ts *ts)
> -{
> - input_report_abs(&ts->idev, ABS_PRESSURE, 0);
> - input_sync(&ts->idev);
> -}
> -
> /*
> * Switch to interrupt mode.
> */
> @@ -176,12 +161,6 @@ static int ucb1x00_thread(void
> *_ts)
> DECLARE_WAITQUEUE(wait, tsk);
> int valid;
>
> - ts->rtask = tsk;
> -
> - daemonize("ktsd");
> - /* only want to receive SIGKILL */
> - allow_signal(SIGKILL);
> -
> /*
>* We could run as a real-time thread. However,
> thus far
>* this doesn't seem to be necessary.
> @@ -189,12 +168,10 @@ static int ucb1x00_thread(void
> *_ts)
> // tsk->policy = SCHED_FIFO;
> // tsk->rt_priority = 1;
>
> - complete(&ts->init_exit);
> -
> valid = 0;
>
> add_wait_queue(&ts->irq_wait, &wait);
> - for (;;) {
> + while (!kthread_should_stop()) {
> unsigned int x, y, p, val;
> signed long timeout;
>
> @@ -212,10 +189,7 @@ static int ucb1x00_thread(void
> *_ts)
> ucb1x00_ts_mode_int(ts);
> ucb1x00_adc_disable(ts->ucb);
>
> - set_task_state(tsk, TASK_UNINTERRUPTIBLE);
> - schedule_timeout(HZ / 100);
> - if (signal_pending(tsk))
> - break;
> + msleep(10);
>
> ucb1x00_enable(ts->ucb);
> val = ucb1x00_reg_read(ts->ucb, UCB_TS_CR);
> @@ -231,7 +205,8 @@ static int ucb1x00_thread(void
> *_ts)
>* spit out a "pen off" sample here.
>*/
> if (valid) {
> - ucb1x00_ts_event_release(ts);
> + input_report_abs(&ts->idev, ABS_PRESSURE, 0);
> + input_sync(&ts->idev);
> valid = 0;
> }
>
> @@ -245,7 +220,10 @@ static int ucb1x00_thread(void
> *_ts)
>* to do any filtering they please.
>*/
> if (!ts->restart) {
> - ucb1x00_ts_evt_add(ts, p, x, y);
> + input_report_abs(&ts->idev, ABS_X, x);
> + input_report_abs(&ts->idev, ABS_Y, y);
> + input_report_abs(&ts->idev, ABS_PRESSURE, p);
> + input_sync(&ts->idev);
>
Linux 2.6.11.5 on R3912 problems
Hi, I have now been trying to get Linux 2.6.11.5 (built with gcc 3.3.3 and binutils 2.15.91.0.2) up and running on my Helio PDA, a MIPS R3912 based ASSP (the emulator to be exact) and have been stuck at the last step for a while now :-(. The kernel runs up fine, the problem starts when init is started. Bellow is my kernel log up to freeing init. Uncompressing Linux done, booting the kernel. done decompressing kernel. e_entry: 8016b000, e_ehsize: 52, e_phentsize 32, e_phnum 2, e_shentsize 40, e_shnum 25 copying 0x10c320 bytes from file offset 0x80 to address 0x8004 zeroing from 8014c320 to to 8014c320, 0x0 bytes copying 0x36084 bytes from file offset 0x10e000 to address 0x8014e000 zeroing from 80184084 to to 80198b58, 0x14ad4 bytes done loading kernel, about to jump in! mips_machgroup 0x0017, mips_machtype 0x arcs_cmdline: root=1f01 console=ttyS0,115200n8 Linux version 2.6.11.5 ([EMAIL PROTECTED]) (gcc version 3.3.3) #297 Mon Jul 18 20:19 :39 UTC 2005 V nasty hack. The Emulator doesn't report which subset of the TX39 family it bel ongs to :,-(. I hope the hardware does! Forcing cpu type to CPU_TX3912 CPU revision is: 2200 Determined physical RAM map: memory: 00267000 @ 00199000 (usable) memory: 0040 @ 0200 (usable) memory: 0020 @ 9fc0 (ROM data) Built 1 zonelists Kernel command line: root=1f01 console=ttyS0,115200n8 Primary instruction cache 1kB, linesize 16 bytes Primary data cache 1kB, linesize 4 bytes Synthesized TLB handler (17 instructions). Synthesized TLB load handler fastpath (37 instructions). Synthesized TLB store handler fastpath (37 instructions). Synthesized TLB modify handler fastpath (29 instructions). PID hash table entries: 256 (order: 8, 4096 bytes) r39xx_set_termios Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 6168k/6556k available (981k kernel code, 348k reserved, 212k data, 104k init, 0k highmem) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) Checking for 'wait' instruction... unavailable. cpu_wait = 0x0 Linux NoNET1.0 for Linux 2.6 schedule = 0x801327f8. ret = 0 Can't analyze prologue code at 80133ea0 schedule_timeout = 0x80133ea0. ret = -1 sleep_on = 0x8013395c. ret = 0 sleep_on_timeout = 0x80133a54. ret = 0 wait_for_completion = 0x80133148. ret = 0 Serial: r39xx internal UART driver $ r39xx_config_port r39xx_request_port ttyS0 at MMIO 0x0r39xx_type (irq = 74) is a R39XX io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize loop: loaded (max 8 devices) Helio Boot ROM: 0x0020 at 0x9fc0 helio_mtd_map.virt 0x9fc0 Helio Boot ROM: probing for ROM Creating 2 MTD partitions on "Helio Boot ROM": 0x-0x00097eec : "Bootloader + Kernel" mtd: Giving out device 0 to Bootloader + Kernel 0x00097eec-0x0013deec : "cramfs Filesystem" mtd: Giving out device 1 to cramfs Filesystem block2mtd: version $Revision: 1.23 $ VFS: Mounted root (cramfs filesystem) readonly. Freeing unused kernel memory: 104k freed I have had to write a UART driver so I thought the problem might be with that so I put lots of debug in tty layer, serial_core and my driver to see what was going on. After doing this and changing the interrupt handler (int-handler.S) I saw the echo that I had put in my inittab. So I started to remove debug and found it stopped working. The strange thing is that it stops before it gets as far as sending the echo from inittab. If I dont have enough debug the kernel stops just before printing out: Algorithmics/MIPS FPU Emulator v1.5 When I connect to the emulator with GDB and look at the registers I find the CPU is still running and is in cpu_idle. I wondered if it might be a timer/task scheduler related problem but as it gets passed the bogomips calculation the timer must be working. Any help would be great as I have been stuck here for a while. Many Thanks, Mark ___ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
