* Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
From: Pierre Ossman @ 2008-06-28 13:45 UTC (permalink / raw)
To: Haavard Skinnemoen
Cc: Dan Williams, linux-kernel, linux-embedded, kernel,
shannon.nelson, David Brownell
In-Reply-To: <20080628144313.353bbf18@hskinnemo-gx745.norway.atmel.com>
[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]
On Sat, 28 Jun 2008 14:43:13 +0200
Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote:
> Tests 15 and 17 return -EILSEQ instead of -ETIMEDOUT. The at91_mci
> driver has the same problem, and I think it's a hardware issue -- the
> controller wrongly flags a CRC error instead of a data timeout error
> if the card doesn't respond with any CRC status after a write. I don't
> know how to work around that problem.
If that's how the hardware behaves, then EILSEQ will have to do. The
test is more about forcing people to do proper error management in the
driver than anything else. Have a check that you don't report a bad
bytes_xfered though.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
From: Haavard Skinnemoen @ 2008-06-28 14:01 UTC (permalink / raw)
To: Pierre Ossman
Cc: Dan Williams, linux-kernel, linux-embedded, kernel,
shannon.nelson, David Brownell
In-Reply-To: <20080628154515.0eb002f6@mjolnir.drzeus.cx>
Pierre Ossman <drzeus-list@drzeus.cx> wrote:
> On Sat, 28 Jun 2008 14:43:13 +0200
> Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote:
>
> > Tests 15 and 17 return -EILSEQ instead of -ETIMEDOUT. The at91_mci
> > driver has the same problem, and I think it's a hardware issue -- the
> > controller wrongly flags a CRC error instead of a data timeout error
> > if the card doesn't respond with any CRC status after a write. I don't
> > know how to work around that problem.
>
> If that's how the hardware behaves, then EILSEQ will have to do. The
> test is more about forcing people to do proper error management in the
> driver than anything else. Have a check that you don't report a bad
> bytes_xfered though.
bytes_xfered is 0 if any block failed. If I understand correctly, this
is good enough, but not optimal. I want to improve this later, but I
might need some more feedback from the DMA engine subsystem (e.g.
adding "actual" and "status" fields to the descriptor.)
The DMA slave interface isn't perfect yet, but I think the current
incarnation is actually useful and performs well even though it's very
basic. We can make incremental improvements later to improve error
reporting, offer more advanced control over the transfers, and support
other use cases better (e.g. audio.)
Haavard
^ permalink raw reply
* Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
From: Pierre Ossman @ 2008-06-28 14:11 UTC (permalink / raw)
To: Haavard Skinnemoen
Cc: Dan Williams, linux-kernel, linux-embedded, kernel,
shannon.nelson, David Brownell
In-Reply-To: <20080628160121.10c7c1b0@hskinnemo-gx745.norway.atmel.com>
[-- Attachment #1: Type: text/plain, Size: 921 bytes --]
On Sat, 28 Jun 2008 16:01:21 +0200
Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote:
>
> bytes_xfered is 0 if any block failed. If I understand correctly, this
> is good enough, but not optimal. I want to improve this later, but I
> might need some more feedback from the DMA engine subsystem (e.g.
> adding "actual" and "status" fields to the descriptor.)
>
That's good enough yes. The only incorrect value is reporting more than
was actually written as that would completely undermine any attempts of
keeping data integrity in upper layers.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Atmel AT91SAM7S and AT91SAM7A3
From: Michelle Konzack @ 2008-06-29 2:37 UTC (permalink / raw)
To: Embedded
In-Reply-To: <1214642184.4265.9.camel@moss.renham>
[-- Attachment #1: Type: text/plain, Size: 1093 bytes --]
Hello Ben,
Am 2008-06-28 18:36:24, schrieb Ben Nizette:
> I would recommend posting this to a forum at http://www.at91.com. This
> is a list more for discussion of embedded issues in the kernel than SoC
> end-user support :-)
I was already on <http://www.at91.com/> but where I live, I can not
access the Web-Forum. I need a mailinglist.
Also I realy do not knoe whether accessing the AD-Converters in a Micro-
controller is a user space issue or a Kernel one, since I need Kernel
modules or not?
I realy do not know, how to begin this stuff...
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH v4 6/6] Atmel MCI: Driver for Atmel on-chip MMC controllers
From: Pierre Ossman @ 2008-06-29 16:49 UTC (permalink / raw)
To: Haavard Skinnemoen
Cc: linux-embedded, shannon.nelson, kernel, linux-kernel,
David Brownell, Dan Williams
In-Reply-To: <20080628153144.128faa7b@hskinnemo-gx745.norway.atmel.com>
[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]
On Sat, 28 Jun 2008 15:31:44 +0200
Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote:
> Haavard Skinnemoen <haavard.skinnemoen@atmel.com> wrote:
> > Tests 7 and 9 are not supported by the card, so I can't do much about
> > it except go through all the cards I have available and see if one of
> > them supports this test.
>
> Turns out none of my 12 cards of various brands and models support this
> test. Do you know some specific model I can try?
>
Of the set I have here, only one supported partial writes. A prototype
samsung MMC 4.2 card. It has the markings "MM8GH04GNACA-9A" on it. A
quick google doesn't turn up anything, but some other new Samsung MMC
card might have good odds.
Rgds
--
-- Pierre Ossman
Linux kernel, MMC maintainer http://www.kernel.org
rdesktop, core developer http://www.rdesktop.org
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: selecting initramfs support without initrd?
From: Rob Landley @ 2008-07-01 4:46 UTC (permalink / raw)
To: Robert P. J. Day; +Cc: linux-embedded
In-Reply-To: <alpine.LFD.1.10.0806241805390.5000@localhost.localdomain>
On Tuesday 24 June 2008 17:11:01 Robert P. J. Day wrote:
> i'm not sure if this is the proper forum for this, but while
> perusing the early boot code, i noticed that selecting the config
> variable BLK_DEV_INITRD gives you support for both initramfs, and an
> initrd image.
It gives you support for an _external_ initramfs. (I.E. the bootloader can
load an external blob into memory and feed the physical address into the
kernel via the ramdisk_start=12345 command line option. If this blob gunzips
to a cpio image, it's extracted into rootfs. If it gunzips to a recognized
filesystem type, it's used as an initrd.)
The one built into the kernel is always used and can't be disabled, that I am
aware of. If you have files in the static cpio archive and files in an
internally supplied cpio archive, the file in the external one replaces the
corresponding file in the internal one.
> based on a quick inspection of the source under init/, it would seem
> that you could whack out sizable chunks of code if you had no need for
> initrd, but i could be wrong.
If you disable BLK_DEV_INITRD you'll still have a cpio image built into your
kernel:
make allnoconfig
make -j 3
It's possible that inclusion of the external image loading logic should be
based on a symbol other than BLK_DEV_INITRD, since initramfs can use that
logic when you never use a ram disk block device. It's a question of
untangling stuff and figuring out how much config granularity you want...
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
^ permalink raw reply
* Dump Management
From: Marco Stornelli @ 2008-07-01 7:38 UTC (permalink / raw)
To: Linux-Embedded
Hi,
what's the standard way to manage the core dump and therefore the
post-mortem debug? For my experience it could be useful to have a
mechanism to have little dump image (only some information) to store it
in flash and maybe to have an hook (or something like this) for each
application to customize the dump information. What do you think about it?
Regards,
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* RE: [PATCH v4 1/6] dmaengine: Add dma_client parameter to device_alloc_chan_resources
From: Sosnowski, Maciej @ 2008-07-01 13:50 UTC (permalink / raw)
To: haavard.skinnemoen
Cc: Williams, Dan J, drzeus-list, lkml, linux-embedded, kernel,
Nelson, Shannon, david-b
In-Reply-To: <f12847240806270223j71ddb6d5j9716fb8c335edd00@mail.gmail.com>
> ---------- Original message ----------
> From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
> Date: Jun 26, 2008 3:23 PM
> Subject: [PATCH v4 1/6] dmaengine: Add dma_client parameter to
> device_alloc_chan_resources
> To: Dan Williams <dan.j.williams@intel.com>, Pierre Ossman
> <drzeus-list@drzeus.cx>
> Cc: linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
> kernel@avr32linux.org, shannon.nelson@intel.com, David Brownell
> <david-b@pacbell.net>, Haavard Skinnemoen
> <haavard.skinnemoen@atmel.com>
>
>
> A DMA controller capable of doing slave transfers may need to know a
> few things about the slave when preparing the channel. We don't want
> to add this information to struct dma_channel since the channel hasn't
> yet been bound to a client at this point.
>
> Instead, pass a reference to the client requesting the channel to the
> driver's device_alloc_chan_resources hook so that it can pick the
> necessary information from the dma_client struct by itself.
>
> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
> ---
> drivers/dma/dmaengine.c | 3 ++-
> drivers/dma/ioat_dma.c | 5 +++--
> drivers/dma/iop-adma.c | 7 ++++---
> include/linux/dmaengine.h | 3 ++-
> 4 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index 99c22b4..a57c337 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -174,7 +174,8 @@ static void dma_client_chan_alloc(struct
dma_client
> *client) if (!dma_chan_satisfies_mask(chan,
> client->cap_mask)) continue;
>
> - desc =
> chan->device->device_alloc_chan_resources(chan); +
desc
> = chan->device->device_alloc_chan_resources( +
> chan, client); if (desc >= 0) {
> ack = client->event_callback(client,
> chan,
> diff --git a/drivers/dma/ioat_dma.c b/drivers/dma/ioat_dma.c
> index 318e8a2..90e5b0a 100644
> --- a/drivers/dma/ioat_dma.c
> +++ b/drivers/dma/ioat_dma.c
> @@ -452,7 +452,8 @@ static void ioat2_dma_massage_chan_desc(struct
> ioat_dma_chan *ioat_chan)
> * ioat_dma_alloc_chan_resources - returns the number of allocated
descriptors
> * @chan: the channel to be filled out
> */
> -static int ioat_dma_alloc_chan_resources(struct dma_chan *chan)
> +static int ioat_dma_alloc_chan_resources(struct dma_chan *chan,
> + struct dma_client *client)
> {
> struct ioat_dma_chan *ioat_chan = to_ioat_chan(chan);
> struct ioat_desc_sw *desc;
> @@ -1049,7 +1050,7 @@ static int ioat_dma_self_test(struct
> ioatdma_device *device)
> dma_chan = container_of(device->common.channels.next,
> struct dma_chan,
> device_node);
> - if (device->common.device_alloc_chan_resources(dma_chan) < 1)
{
> + if (device->common.device_alloc_chan_resources(dma_chan, NULL)
< 1) {
> dev_err(&device->pdev->dev,
> "selftest cannot allocate chan resource\n");
> err = -ENODEV;
> diff --git a/drivers/dma/iop-adma.c b/drivers/dma/iop-adma.c
> index 0ec0f43..2664ea5 100644
> --- a/drivers/dma/iop-adma.c
> +++ b/drivers/dma/iop-adma.c
> @@ -444,7 +444,8 @@ static void iop_chan_start_null_memcpy(struct
> iop_adma_chan *iop_chan);
> static void iop_chan_start_null_xor(struct iop_adma_chan *iop_chan);
>
> /* returns the number of allocated descriptors */
> -static int iop_adma_alloc_chan_resources(struct dma_chan *chan)
> +static int iop_adma_alloc_chan_resources(struct dma_chan *chan,
> + struct dma_client *client)
> {
> char *hw_desc;
> int idx;
> @@ -838,7 +839,7 @@ static int __devinit
> iop_adma_memcpy_self_test(struct iop_adma_device *device)
> dma_chan = container_of(device->common.channels.next,
> struct dma_chan,
> device_node);
> - if (iop_adma_alloc_chan_resources(dma_chan) < 1) {
> + if (iop_adma_alloc_chan_resources(dma_chan, NULL) < 1) {
> err = -ENODEV;
> goto out;
> }
> @@ -936,7 +937,7 @@ iop_adma_xor_zero_sum_self_test(struct
> iop_adma_device *device)
> dma_chan = container_of(device->common.channels.next,
> struct dma_chan,
> device_node);
> - if (iop_adma_alloc_chan_resources(dma_chan) < 1) {
> + if (iop_adma_alloc_chan_resources(dma_chan, NULL) < 1) {
> err = -ENODEV;
> goto out;
> }
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index d08a5c5..cffb95f 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -279,7 +279,8 @@ struct dma_device {
> int dev_id;
> struct device *dev;
>
> - int (*device_alloc_chan_resources)(struct dma_chan *chan);
> + int (*device_alloc_chan_resources)(struct dma_chan *chan,
> + struct dma_client *client);
> void (*device_free_chan_resources)(struct dma_chan *chan);
>
> struct dma_async_tx_descriptor *(*device_prep_dma_memcpy)(
> --
> 1.5.5.4
Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com>
Regards,
Maciej
^ permalink raw reply
* RE: [PATCH v4 2/6] dmaengine: Add dma_chan_is_in_use() function
From: Sosnowski, Maciej @ 2008-07-01 13:52 UTC (permalink / raw)
To: haavard.skinnemoen
Cc: Williams, Dan J, drzeus-list, lkml, linux-embedded, kernel,
Nelson, Shannon, david-b
In-Reply-To: <f12847240806270224v29de65e8h612a077e12c4d5e1@mail.gmail.com>
> ---------- Original message ----------
> From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
> Date: Jun 26, 2008 3:23 PM
> Subject: [PATCH v4 2/6] dmaengine: Add dma_chan_is_in_use() function
> To: Dan Williams <dan.j.williams@intel.com>, Pierre Ossman
> <drzeus-list@drzeus.cx>
> Cc: linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
> kernel@avr32linux.org, shannon.nelson@intel.com, David Brownell
> <david-b@pacbell.net>, Haavard Skinnemoen
> <haavard.skinnemoen@atmel.com>
>
>
> This moves the code checking if a DMA channel is in use from
> show_in_use() into an inline helper function, dma_is_in_use(). DMA
> controllers can use this in order to give clients exclusive access to
> channels (usually necessary when setting up slave DMA.)
>
> I have to admit that I don't really understand the channel refcounting
> logic at all... dma_chan_get() simply increments a per-cpu value. How
> can we be sure that whatever CPU calls dma_chan_is_in_use() sees the
> same value?
>
> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
> ---
> drivers/dma/dmaengine.c | 12 +-----------
> include/linux/dmaengine.h | 17 +++++++++++++++++
> 2 files changed, 18 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index a57c337..ad8d811 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -105,17 +105,7 @@ static ssize_t show_bytes_transferred(struct
> device *dev, struct device_attribut
> static ssize_t show_in_use(struct device *dev, struct
> device_attribute *attr, char *buf)
> {
> struct dma_chan *chan = to_dma_chan(dev);
> - int in_use = 0;
> -
> - if (unlikely(chan->slow_ref) &&
> - atomic_read(&chan->refcount.refcount) > 1)
> - in_use = 1;
> - else {
> - if (local_read(&(per_cpu_ptr(chan->local,
> - get_cpu())->refcount)) > 0)
> - in_use = 1;
> - put_cpu();
> - }
> + int in_use = dma_chan_is_in_use(chan);
>
> return sprintf(buf, "%d\n", in_use);
> }
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index cffb95f..4b602d3 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -180,6 +180,23 @@ static inline void dma_chan_put(struct dma_chan
*chan)
> }
> }
>
> +static inline bool dma_chan_is_in_use(struct dma_chan *chan)
> +{
> + bool in_use = false;
> +
> + if (unlikely(chan->slow_ref) &&
> + atomic_read(&chan->refcount.refcount) > 1)
> + in_use = true;
> + else {
> + if (local_read(&(per_cpu_ptr(chan->local,
> + get_cpu())->refcount)) > 0)
> + in_use = true;
> + put_cpu();
> + }
> +
> + return in_use;
> +}
> +
> /*
> * typedef dma_event_callback - function pointer to a DMA event
callback
> * For each channel added to the system this routine is called for
each
> client. --
> 1.5.5.4
Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com>
Regards,
Maciej
^ permalink raw reply
* RE: [PATCH v4 3/6] dmaengine: Add slave DMA interface
From: Sosnowski, Maciej @ 2008-07-01 13:59 UTC (permalink / raw)
To: haavard.skinnemoen
Cc: Williams, Dan J, drzeus-list, lkml, linux-embedded, kernel,
Nelson, Shannon, david-b
In-Reply-To: <f12847240806270225x1d6168b0i452c6e6e964157d3@mail.gmail.com>
> ---------- Original message ----------
> From: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
> Date: Jun 26, 2008 3:23 PM
> Subject: [PATCH v4 3/6] dmaengine: Add slave DMA interface
> To: Dan Williams <dan.j.williams@intel.com>, Pierre Ossman
> <drzeus-list@drzeus.cx>
> Cc: linux-kernel@vger.kernel.org, linux-embedded@vger.kernel.org,
> kernel@avr32linux.org, shannon.nelson@intel.com, David Brownell
> <david-b@pacbell.net>, Haavard Skinnemoen
> <haavard.skinnemoen@atmel.com>
>
>
> This patch adds the necessary interfaces to the DMA Engine framework
> to use functionality found on most embedded DMA controllers: DMA from
> and to I/O registers with hardware handshaking.
>
> In this context, hardware hanshaking means that the peripheral that
> owns the I/O registers in question is able to tell the DMA controller
> when more data is available for reading, or when there is room for
> more data to be written. This usually happens internally on the chip,
> but these signals may also be exported outside the chip for things
> like IDE DMA, etc.
>
> A new struct dma_slave is introduced. This contains information that
> the DMA engine driver needs to set up slave transfers to and from a
> slave device. Most engines supporting DMA slave transfers will want to
> extend this structure with controller-specific parameters. This
> additional information is usually passed from the platform/board code
> through the client driver.
>
> A "slave" pointer is added to the dma_client struct. This must point
> to a valid dma_slave structure iff the DMA_SLAVE capability is
> requested. The DMA engine driver may use this information in its
> device_alloc_chan_resources hook to configure the DMA controller for
> slave transfers from and to the given slave device.
>
> A new struct dma_slave_descriptor is added. This extends the standard
> dma_async_tx_descriptor with a few members that are needed for doing
> slave DMA from/to peripherals.
>
> A new operation for creating such descriptors is added to struct
> dma_device. Another new operation for terminating all pending
> transfers is added as well. The latter is needed because there may be
> errors outside the scope of the DMA Engine framework that may require
> DMA operations to be terminated prematurely.
>
> DMA Engine drivers may extend the dma_device, dma_chan and/or
> dma_slave_descriptor structures to allow controller-specific
> operations. The client driver can detect such extensions by looking at
> the DMA Engine's struct device, or it can request a specific DMA
> Engine device by setting the dma_dev field in struct dma_slave.
>
> Signed-off-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>
>
> dmaslave interface changes since v3:
> * Use dma_data_direction instead of a new enum
> * Submit slave transfers as scatterlists
> * Remove the DMA slave descriptor struct
>
> dmaslave interface changes since v2:
> * Add a dma_dev field to struct dma_slave. If set, the client can
> only be bound to the DMA controller that corresponds to this
> device. This allows controller-specific extensions of the
> dma_slave structure; if the device matches, the controller may
> safely assume its extensions are present.
> * Move reg_width into struct dma_slave as there are currently no
> users that need to be able to set the width on a per-transfer
> basis.
>
> dmaslave interface changes since v1:
> * Drop the set_direction and set_width descriptor hooks. Pass the
> direction and width to the prep function instead.
> * Declare a dma_slave struct with fixed information about a slave,
> i.e. register addresses, handshake interfaces and such.
> * Add pointer to a dma_slave struct to dma_client. Can be NULL if
> the DMA_SLAVE capability isn't requested.
> * Drop the set_slave device hook since the alloc_chan_resources hook
> now has enough information to set up the channel for slave
> transfers.
> ---
> drivers/dma/dmaengine.c | 16 ++++++++++++-
> include/linux/dmaengine.h | 53
> ++++++++++++++++++++++++++++++++++++++++++++- 2 files changed, 67
> insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
> index ad8d811..2e0035f 100644
> --- a/drivers/dma/dmaengine.c
> +++ b/drivers/dma/dmaengine.c
> @@ -159,7 +159,12 @@ static void dma_client_chan_alloc(struct
> dma_client *client)
> enum dma_state_client ack;
>
> /* Find a channel */
> - list_for_each_entry(device, &dma_device_list, global_node)
> + list_for_each_entry(device, &dma_device_list, global_node) {
> + /* Does the client require a specific DMA controller?
*/
> + if (client->slave && client->slave->dma_dev
> + && client->slave->dma_dev !=
device->dev)
> + continue;
> +
> list_for_each_entry(chan, &device->channels,
device_node) {
> if (!dma_chan_satisfies_mask(chan,
client->cap_mask))
> continue;
> @@ -180,6 +185,7 @@ static void dma_client_chan_alloc(struct
dma_client
> *client) return;
> }
> }
> + }
> }
>
> enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t
cookie)
> @@ -276,6 +282,10 @@ static void dma_clients_notify_removed(struct
> dma_chan *chan)
> */
> void dma_async_client_register(struct dma_client *client)
> {
> + /* validate client data */
> + BUG_ON(dma_has_cap(DMA_SLAVE, client->cap_mask) &&
> + !client->slave);
> +
> mutex_lock(&dma_list_mutex);
> list_add_tail(&client->global_node, &dma_client_list);
> mutex_unlock(&dma_list_mutex);
> @@ -350,6 +360,10 @@ int dma_async_device_register(struct dma_device
*device)
> !device->device_prep_dma_memset);
> BUG_ON(dma_has_cap(DMA_INTERRUPT, device->cap_mask) &&
> !device->device_prep_dma_interrupt);
> + BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&
> + !device->device_prep_slave_sg);
> + BUG_ON(dma_has_cap(DMA_SLAVE, device->cap_mask) &&
> + !device->device_terminate_all);
>
> BUG_ON(!device->device_alloc_chan_resources);
> BUG_ON(!device->device_free_chan_resources);
> diff --git a/include/linux/dmaengine.h b/include/linux/dmaengine.h
> index 4b602d3..8ce03e8 100644
> --- a/include/linux/dmaengine.h
> +++ b/include/linux/dmaengine.h
> @@ -89,10 +89,23 @@ enum dma_transaction_type {
> DMA_MEMSET,
> DMA_MEMCPY_CRC32C,
> DMA_INTERRUPT,
> + DMA_SLAVE,
> };
>
> /* last transaction type for creation of the capabilities mask */
> -#define DMA_TX_TYPE_END (DMA_INTERRUPT + 1)
> +#define DMA_TX_TYPE_END (DMA_SLAVE + 1)
> +
> +/**
> + * enum dma_slave_width - DMA slave register access width.
> + * @DMA_SLAVE_WIDTH_8BIT: Do 8-bit slave register accesses
> + * @DMA_SLAVE_WIDTH_16BIT: Do 16-bit slave register accesses
> + * @DMA_SLAVE_WIDTH_32BIT: Do 32-bit slave register accesses
> + */
> +enum dma_slave_width {
> + DMA_SLAVE_WIDTH_8BIT,
> + DMA_SLAVE_WIDTH_16BIT,
> + DMA_SLAVE_WIDTH_32BIT,
> +};
>
> /**
> * enum dma_ctrl_flags - DMA flags to augment operation preparation,
> @@ -115,6 +128,33 @@ enum dma_ctrl_flags {
> typedef struct { DECLARE_BITMAP(bits, DMA_TX_TYPE_END); }
dma_cap_mask_t;
>
> /**
> + * struct dma_slave - Information about a DMA slave
> + * @dev: device acting as DMA slave
> + * @dma_dev: required DMA master device. If non-NULL, the client can
not be
> + * bound to other masters than this. The master driver may use
> + * this to determine whether it's safe to access
> + * @tx_reg: physical address of data register used for
> + * memory-to-peripheral transfers
> + * @rx_reg: physical address of data register used for
> + * peripheral-to-memory transfers
> + * @reg_width: peripheral register width
> + *
> + * If dma_dev is non-NULL, the client can not be bound to other DMA
> + * masters than the one corresponding to this device. The DMA master
> + * driver may use this to determine if there is controller-specific
> + * data wrapped around this struct. Drivers of platform code that
sets
> + * the dma_dev field must therefore make sure to use an appropriate
> + * controller-specific dma slave structure wrapping this struct.
> + */
> +struct dma_slave {
> + struct device *dev;
> + struct device *dma_dev;
> + dma_addr_t tx_reg;
> + dma_addr_t rx_reg;
> + enum dma_slave_width reg_width;
> +};
> +
> +/**
> * struct dma_chan_percpu - the per-CPU part of struct dma_chan
> * @refcount: local_t used for open-coded "bigref" counting
> * @memcpy_count: transaction counter
> @@ -219,11 +259,14 @@ typedef enum dma_state_client
> (*dma_event_callback) (struct dma_client *client,
> * @event_callback: func ptr to call when something happens
> * @cap_mask: only return channels that satisfy the requested
capabilities
> * a value of zero corresponds to any capability
> + * @slave: data for preparing slave transfer. Must be non-NULL iff
the
> + * DMA_SLAVE capability is requested.
> * @global_node: list_head for global dma_client_list
> */
> struct dma_client {
> dma_event_callback event_callback;
> dma_cap_mask_t cap_mask;
> + struct dma_slave *slave;
> struct list_head global_node;
> };
>
> @@ -280,6 +323,8 @@ struct dma_async_tx_descriptor {
> * @device_prep_dma_zero_sum: prepares a zero_sum operation
> * @device_prep_dma_memset: prepares a memset operation
> * @device_prep_dma_interrupt: prepares an end of chain interrupt
operation
> + * @device_prep_slave_sg: prepares a slave dma operation
> + * @device_terminate_all: terminate all pending operations
> * @device_issue_pending: push pending transactions to hardware
> */
> struct dma_device {
> @@ -315,6 +360,12 @@ struct dma_device {
> struct dma_async_tx_descriptor *(*device_prep_dma_interrupt)(
> struct dma_chan *chan, unsigned long flags);
>
> + struct dma_async_tx_descriptor *(*device_prep_slave_sg)(
> + struct dma_chan *chan, struct scatterlist *sgl,
> + unsigned int sg_len, enum dma_data_direction
direction,
> + unsigned long flags);
> + void (*device_terminate_all)(struct dma_chan *chan);
> +
> enum dma_status (*device_is_tx_complete)(struct dma_chan *chan,
> dma_cookie_t cookie, dma_cookie_t *last,
> dma_cookie_t *used);
> --
> 1.5.5.4
Acked-by: Maciej Sosnowski <maciej.sosnowski@intel.com>
Regards,
Maciej
^ permalink raw reply
* Re: Dump Management
From: Gilad Ben-Yossef @ 2008-07-01 14:05 UTC (permalink / raw)
To: Marco Stornelli; +Cc: Linux-Embedded
In-Reply-To: <4869DEF0.5060109@coritel.it>
hI,
Marco Stornelli wrote:
> what's the standard way to manage the core dump and therefore the
> post-mortem debug?
For most embedded systems I know, core dumps are useful on the developer
desk and in the testing lab. For analyzing field post-mortem (where it
is feasible), use a custom fault signal hander in your app to catch the
relevant information and save it.
If you're interested in a tutorial in doing this, I'm giving one at this
year OLS. Or you can just check out the slides and example code here:
http://tuxology.net/lectures/crash-and-burn-writing-linux-application-fault-handlers/
> For my experience it could be useful to have a mechanism to have
> little dump image (only some information) to store it in flash and
> maybe to have an hook (or something like this) for each application to
> customize the dump information. What do you think about it?
>
That's exactly what a custom fault signal handler does :-)
Cheers,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
Codefidence Ltd.
The code is free, your time isn't.(TM)
Web: http://codefidence.com
Email: gilad@codefidence.com
Office: +972-8-9316883 ext. 201
Fax: +972-8-9316885
Mobile: +972-52-8260388
Q: How many NSA agents does it take to replace a lightbulb?
A: dSva7DrYiY24yeTItKyyogFXD5gRuoRqPNQ9v6WCLLywZPINlu!
^ permalink raw reply
* Re: Recommendation for activating a deferred module init in the kernel
From: Gilad Ben-Yossef @ 2008-07-01 14:20 UTC (permalink / raw)
To: Tim Bird; +Cc: linux-embedded
In-Reply-To: <485FDFF1.7010408@am.sony.com>
Tim Bird wrote:
> Gilad Ben-Yossef wrote:
>
>> Tim Bird wrote:
>>
>>> I agree. When you say "have the application call modprobe directly",
>>> I'm not sure I understand what you mean.
>>>
>> I simply meant that you can fork and exec modprobe itself (or use
>> system() but that
>> would require a working shell). This would "save" the need for a
>> separate script and a shell.
>>
>
> Well, this would explain why I didn't follow your original
> point. I thought you were using the word "modprobe" as a placeholder
> for some other module-installation-related concept.
Well, modprobe could just as well be insmod, but the basic idea is still
the same.
>
>> The only downside I see of calling the sys_init_module syscall directly
>> is that it
>> doesn't do any of the dependency tracking that modprobe does, so it's more
>> a insmod replacement then a modprobe one, but I doubt this matters at
>> all in an
>> embedded system anyway.
>>
> It may just be my own blind spot, but I can't think of a good
> reason to do such dependency tracking in an embedded device.
> It is a sad state of affairs if the product developers don't
> know the module dependencies for their own products.
>
For custom built modules written in house , I agree - but think of one
of those devices that has an OTG USB port, the kind that you can one day
connect it to a computer to play the part of a USB storage gadget and
the next day hook a it to up to a serial USB connected GSM modem.
It's crazy to have all that functionality loaded into the device RAM at
all times and the using modprobe to track the dependencies of the module
makes just as much sense as it does for your laptop.
I guess the term "embedded" gets kind of blurry with these things, but I
also think Linux adoption in the embedded world is driven by this trend.
Cheers,
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
Codefidence Ltd.
The code is free, your time isn't.(TM)
Web: http://codefidence.com
Email: gilad@codefidence.com
Office: +972-8-9316883 ext. 201
Fax: +972-8-9316885
Mobile: +972-52-8260388
Q: How many NSA agents does it take to replace a lightbulb?
A: dSva7DrYiY24yeTItKyyogFXD5gRuoRqPNQ9v6WCLLywZPINlu!
^ permalink raw reply
* Re: Dump Management
From: Marco Stornelli @ 2008-07-01 14:49 UTC (permalink / raw)
To: Gilad Ben-Yossef; +Cc: Linux-Embedded
In-Reply-To: <486A39AE.4040308@codefidence.com>
Gilad Ben-Yossef ha scritto:
> hI,
>
>
> Marco Stornelli wrote:
>
>> what's the standard way to manage the core dump and therefore the
>> post-mortem debug?
> For most embedded systems I know, core dumps are useful on the developer
> desk and in the testing lab. For analyzing field post-mortem (where it
> is feasible), use a custom fault signal hander in your app to catch the
> relevant information and save it.
>
> If you're interested in a tutorial in doing this, I'm giving one at this
> year OLS. Or you can just check out the slides and example code here:
>
> http://tuxology.net/lectures/crash-and-burn-writing-linux-application-fault-handlers/
>
>> For my experience it could be useful to have a mechanism to have
>> little dump image (only some information) to store it in flash and
>> maybe to have an hook (or something like this) for each application to
>> customize the dump information. What do you think about it?
>>
> That's exactly what a custom fault signal handler does :-)
>
> Cheers,
> Gilad
>
Very interesting....Thanks.
--
Marco Stornelli
Embedded Software Engineer
CoRiTeL - Consorzio di Ricerca sulle Telecomunicazioni
http://www.coritel.it
marco.stornelli@coritel.it
+39 06 72582838
^ permalink raw reply
* Re: [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections
From: Valdis.Kletnieks @ 2008-07-01 22:56 UTC (permalink / raw)
To: Denys Vlasenko
Cc: linux-arch, Andrew Morton, Russell King, David Howells,
Ralf Baechle, Lennert Buytenhek, Josh Boyer, Paul Mackerras,
David Woodhouse, Andi Kleen, torvalds, Paul Gortmaker,
linux-embedded, linux-kernel, Tim Bird, Martin Schwidefsky,
Dave Miller
In-Reply-To: <200807020233.48646.vda.linux@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
On Wed, 02 Jul 2008 02:33:48 +0200, Denys Vlasenko said:
> The purpose of these patches is to make kernel buildable
> with "gcc -ffunction-sections -fdata-sections".
>
> Newer gcc and binutils can do dead code and data removal
> at link time. It is achieved using combination of
> -ffunction-sections -fdata-sections options for gcc and
> --gc-sections for ld.
Interesting idea. Do you happen to have before-and-after 'size vmlinux'
numbers to show how much space is actually reclaimed?
[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply
* Re: [PATCH 5/23] make section names compatible with -ffunction-sections -fdata-sections: blackfin
From: Mike Frysinger @ 2008-07-01 22:58 UTC (permalink / raw)
To: Denys Vlasenko
Cc: linux-arch, Russell King, David Howells, Ralf Baechle,
Lennert Buytenhek, Josh Boyer, Paul Mackerras, David Woodhouse,
Andi Kleen, torvalds, akpm, Paul Gortmaker, linux-embedded,
linux-kernel, Tim Bird, Martin Schwidefsky, Dave Miller
In-Reply-To: <200807020235.08025.vda.linux@googlemail.com>
On Tue, Jul 1, 2008 at 8:35 PM, Denys Vlasenko wrote:
> The purpose of this patch is to make kernel buildable
> with "gcc -ffunction-sections -fdata-sections".
> This patch fixes blackfin architecture.
the comment right above what you changed says it already works for
Blackfin. so you arent fixing it at all.
> /* This gets done first, so the glob doesn't suck it in */
> . = ALIGN(32);
> - *(.data.cacheline_aligned)
> + *(.cacheline_aligned.data)
ive built Blackfin kernels with function/data sections a long time ago
... but iirc, there were toolchain problems, so i havent pursued it
since.
if you're going to muck with names, you might as well do it right the
first time: move the names into asm-generic/vmlinux.lds.h so we dont
have to worry about this kind of churn again.
-mike
^ permalink raw reply
* Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
From: James Bottomley @ 2008-07-01 23:41 UTC (permalink / raw)
To: Denys Vlasenko
Cc: linux-arch, Russell King, David Howells, Ralf Baechle,
Lennert Buytenhek, Josh Boyer, Paul Mackerras, David Woodhouse,
Andi Kleen, torvalds, akpm, Paul Gortmaker, linux-embedded,
linux-kernel, Tim Bird, Martin Schwidefsky, Dave Miller
In-Reply-To: <200807020239.11410.vda.linux@googlemail.com>
On Wed, 2008-07-02 at 02:39 +0200, Denys Vlasenko wrote:
> The purpose of this patch is to make kernel buildable
> with "gcc -ffunction-sections -fdata-sections".
> This patch fixes parisc architecture.
>
> Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Um ... if you look at the Makefile you'll see we already build parisc
with -ffunction-sections; we have to: our relative jumps are too small
to guarantee finding the stubs in large files.
Since our text is -ffunction-sections compatible already, I question the
need for transformations like this:
> - *(.text.do_softirq)
> - *(.text.sys_exit)
> - *(.text.do_sigaltstack)
> - *(.text.do_fork)
> + *(.do_softirq.text)
> + *(.sys_exit.text)
> + *(.do_sigaltstack.text)
> + *(.do_fork.text)
And thus by the same token the data transformations.
James
^ permalink raw reply
* Re: [PATCH 14/23] make section names compatible with -ffunction-sections -fdata-sections: parisc
From: Denys Vlasenko @ 2008-07-02 0:00 UTC (permalink / raw)
To: James Bottomley
Cc: linux-arch, Russell King, David Howells, Ralf Baechle,
Lennert Buytenhek, Josh Boyer, Paul Mackerras, David Woodhouse,
Andi Kleen, torvalds, akpm, Paul Gortmaker, linux-embedded,
linux-kernel, Tim Bird, Martin Schwidefsky, Dave Miller
In-Reply-To: <1214955660.3316.31.camel@localhost.localdomain>
On Wednesday 02 July 2008 01:41, James Bottomley wrote:
> On Wed, 2008-07-02 at 02:39 +0200, Denys Vlasenko wrote:
> > The purpose of this patch is to make kernel buildable
> > with "gcc -ffunction-sections -fdata-sections".
> > This patch fixes parisc architecture.
> >
> > Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
>
> Um ... if you look at the Makefile you'll see we already build parisc
> with -ffunction-sections; we have to: our relative jumps are too small
> to guarantee finding the stubs in large files.
>
> Since our text is -ffunction-sections compatible already, I question the
> need for transformations like this:
>
> > - *(.text.do_softirq)
> > - *(.text.sys_exit)
> > - *(.text.do_sigaltstack)
> > - *(.text.do_fork)
> > + *(.do_softirq.text)
> > + *(.sys_exit.text)
> > + *(.do_sigaltstack.text)
> > + *(.do_fork.text)
arch/parisc/kernel/vmlinux.lds.S contains these lines:
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
*(.text.do_softirq)
*(.text.sys_exit)
*(.text.do_sigaltstack)
*(.text.do_fork)
which suggested to me that for parisc it is important to have
these sections in that place (after LOCK_TEXT) and order.
If you use -ffunction-sections, any function with the name
do_fork (say, a static function somewhere) will end up in
.text.do_fork function, and will be "mixed up" with
global do_fork(). For parisc it is maybe not a problem
(I am not an expert) but in other places/arches people
clearly would not want this kind of things to happen.
In order to handle these situations uniformly, in these patches
I decided to _never_ use .text.XXXX names for sections,
effectively leaving them "reserved for gcc's use".
Did I understand you right that in this chunk I need to
leave .text.FUNC_NAME as it was before?
> And thus by the same token the data transformations.
It would be easiest for me if you will reply to the parisc patch
and indicate all parts where I should NOT do name change.
Thanks!
--
vda
^ permalink raw reply
* Re: [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections
From: Denys Vlasenko @ 2008-07-02 0:03 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: linux-arch, Andrew Morton, Russell King, David Howells,
Ralf Baechle, Lennert Buytenhek, Josh Boyer, Paul Mackerras,
David Woodhouse, Andi Kleen, torvalds, Paul Gortmaker,
linux-embedded, linux-kernel, Tim Bird, Martin Schwidefsky,
Dave Miller
In-Reply-To: <60320.1214952973@turing-police.cc.vt.edu>
On Wednesday 02 July 2008 00:56, Valdis.Kletnieks@vt.edu wrote:
> On Wed, 02 Jul 2008 02:33:48 +0200, Denys Vlasenko said:
>
> > The purpose of these patches is to make kernel buildable
> > with "gcc -ffunction-sections -fdata-sections".
> >
> > Newer gcc and binutils can do dead code and data removal
> > at link time. It is achieved using combination of
> > -ffunction-sections -fdata-sections options for gcc and
> > --gc-sections for ld.
>
> Interesting idea. Do you happen to have before-and-after 'size vmlinux'
> numbers to show how much space is actually reclaimed?
After this patch there will be no change - it does not do
dead code and data removal. I submitted bigger change before
but it was probably too big for digestion.
That earlier version was achieving ~10% kernel size reduction
if kernel is built without loadable module support
(loadable modules interfere with linker's dead code
and data removal, need to add some rather contrived magic
to make it work there too. Left as TODO for later).
--
vda
^ permalink raw reply
* Re: [PATCH 5/23] make section names compatible with -ffunction-sections -fdata-sections: blackfin
From: Denys Vlasenko @ 2008-07-02 0:08 UTC (permalink / raw)
To: Mike Frysinger
Cc: linux-arch, Russell King, David Howells, Ralf Baechle,
Lennert Buytenhek, Josh Boyer, Paul Mackerras, David Woodhouse,
Andi Kleen, torvalds, akpm, Paul Gortmaker, linux-embedded,
linux-kernel, Tim Bird, Martin Schwidefsky, Dave Miller
In-Reply-To: <8bd0f97a0807011558u2c02f6fcre2f3af3d5cced936@mail.gmail.com>
On Wednesday 02 July 2008 00:58, Mike Frysinger wrote:
> On Tue, Jul 1, 2008 at 8:35 PM, Denys Vlasenko wrote:
> > The purpose of this patch is to make kernel buildable
> > with "gcc -ffunction-sections -fdata-sections".
> > This patch fixes blackfin architecture.
>
> the comment right above what you changed says it already works for
> Blackfin. so you arent fixing it at all.
> > /* This gets done first, so the glob doesn't suck it in */
> > . = ALIGN(32);
> > - *(.data.cacheline_aligned)
> > + *(.cacheline_aligned.data)
This may pull in an unrelated data object named "cacheline_aligned"
(say, a static variable in a driver). If that variable is not
itself aligned to the cacheline size, it will mess up alignment of all
objects in .data.cacheline_aligned which follow. Not good.
To be safe from such weird and hard to debug problems
it's better to not use names like .data.XXXX at all.
I just uniformly renamed al such "special sections"
in the kernel to .XXXXX.data
--
vda
^ permalink raw reply
* [PATCH 1/23] make section names compatible with -ffunction-sections -fdata-sections
From: Denys Vlasenko @ 2008-07-02 0:33 UTC (permalink / raw)
To: linux-arch, Andrew Morton
Cc: Russell King, David Howells, Ralf Baechle, Lennert Buytenhek,
Josh Boyer, Paul Mackerras, David Woodhouse, Andi Kleen, torvalds,
Paul Gortmaker, linux-embedded, linux-kernel, Tim Bird,
Martin Schwidefsky, Dave Miller
Hi Andrew, folks,
I am unsure how to synchronize propagation of these patches
across all architectures.
Andrew, how this can be done without causing lots of pain
for arch maintainers? Please advise.
The purpose of these patches is to make kernel buildable
with "gcc -ffunction-sections -fdata-sections".
Newer gcc and binutils can do dead code and data removal
at link time. It is achieved using combination of
-ffunction-sections -fdata-sections options for gcc and
--gc-sections for ld.
Theory of operation:
-ffunction-sections instructs gcc to place each function
(including static ones) in it's own section named .text.function_name
instead of placing all functions in one big .text section.
At link time, ld normally coalesce all such sections into one
output section .text again. It is achieved by having *(.text.*) spec
along with *(.text) spec in built-in linker scripts.
If ld is invoked with --gc-sections, it tracks references, starting
from entry point and marks all input sections which are reachable
from there. Then it discards all input sections which are not marked.
This isn't buying much if you have one big .text section per .o module,
because even one referenced function will pull in entire section.
You need -ffunction-sections in order to split .text into per-function
sections and make --gc-sections much more useful.
-fdata-sections is analogous: it places each global or static variable
into .data.variable_name, .rodata.variable_name or .bss.variable_name.
If we ever want to use described mechanism, we need to adapt
existing code for new section names. Basically, we need to stop using
section names of the form
.text.xxxx
.data.xxxx
.rodata.xxxx
.bss.xxxx
in the kernel - otherwise section placement done by kernel's
custom linker scripts produces broken vmlinux and vdso images.
The following patches fix section names, one per architecture.
The patch in _this_ mail fixes generic part.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
--
vda
--- 0.org/Documentation/mutex-design.txt Wed Jul 2 00:40:39 2008
+++ 1.fixname/Documentation/mutex-design.txt Wed Jul 2 00:44:40 2008
@@ -66,14 +66,14 @@
c0377ccb <mutex_lock>:
c0377ccb: f0 ff 08 lock decl (%eax)
- c0377cce: 78 0e js c0377cde <.text.lock.mutex>
+ c0377cce: 78 0e js c0377cde <.lock.mutex.text>
c0377cd0: c3 ret
the unlocking fastpath is equally tight:
c0377cd1 <mutex_unlock>:
c0377cd1: f0 ff 00 lock incl (%eax)
- c0377cd4: 7e 0f jle c0377ce5 <.text.lock.mutex+0x7>
+ c0377cd4: 7e 0f jle c0377ce5 <.lock.mutex.text+0x7>
c0377cd6: c3 ret
- 'struct mutex' semantics are well-defined and are enforced if
--- 0.org/include/asm-generic/vmlinux.lds.h Wed Jul 2 00:40:50 2008
+++ 1.fixname/include/asm-generic/vmlinux.lds.h Wed Jul 2 00:54:09 2008
@@ -41,7 +41,7 @@
/* .data section */
#define DATA_DATA \
*(.data) \
- *(.data.init.refok) \
+ *(.init.refok.data) \
*(.ref.data) \
DEV_KEEP(init.data) \
DEV_KEEP(exit.data) \
@@ -206,8 +206,8 @@
ALIGN_FUNCTION(); \
*(.text) \
*(.ref.text) \
- *(.text.init.refok) \
- *(.exit.text.refok) \
+ *(.init.refok.text) \
+ *(.exit.refok.text) \
DEV_KEEP(init.text) \
DEV_KEEP(exit.text) \
CPU_KEEP(init.text) \
@@ -347,8 +347,8 @@
#define PERCPU(align) \
. = ALIGN(align); \
__per_cpu_start = .; \
- .data.percpu : AT(ADDR(.data.percpu) - LOAD_OFFSET) { \
- *(.data.percpu) \
- *(.data.percpu.shared_aligned) \
+ .percpu.data : AT(ADDR(.percpu.data) - LOAD_OFFSET) { \
+ *(.percpu.data) \
+ *(.percpu.shared_aligned.data) \
} \
__per_cpu_end = .;
--- 0.org/include/linux/cache.h Wed Jul 2 00:40:51 2008
+++ 1.fixname/include/linux/cache.h Wed Jul 2 00:45:51 2008
@@ -31,7 +31,7 @@
#ifndef __cacheline_aligned
#define __cacheline_aligned \
__attribute__((__aligned__(SMP_CACHE_BYTES), \
- __section__(".data.cacheline_aligned")))
+ __section__(".cacheline_aligned.data")))
#endif /* __cacheline_aligned */
#ifndef __cacheline_aligned_in_smp
--- 0.org/include/linux/init.h Wed Jul 2 00:40:51 2008
+++ 1.fixname/include/linux/init.h Wed Jul 2 00:54:13 2008
@@ -62,9 +62,9 @@
/* backward compatibility note
* A few places hardcode the old section names:
- * .text.init.refok
- * .data.init.refok
- * .exit.text.refok
+ * .init.refok.text
+ * .init.refok.data
+ * .exit.refok.text
* They should be converted to use the defines from this file
*/
@@ -299,7 +299,7 @@
#endif
/* Data marked not to be saved by software suspend */
-#define __nosavedata __section(.data.nosave)
+#define __nosavedata __section(.nosave.data)
/* This means "can be init if no module support, otherwise module load
may call it." */
--- 0.org/include/linux/percpu.h Wed Jul 2 00:40:51 2008
+++ 1.fixname/include/linux/percpu.h Wed Jul 2 00:45:39 2008
@@ -10,13 +10,13 @@
#ifdef CONFIG_SMP
#define DEFINE_PER_CPU(type, name) \
- __attribute__((__section__(".data.percpu"))) \
+ __attribute__((__section__(".percpu.data"))) \
PER_CPU_ATTRIBUTES __typeof__(type) per_cpu__##name
#ifdef MODULE
-#define SHARED_ALIGNED_SECTION ".data.percpu"
+#define SHARED_ALIGNED_SECTION ".percpu.data"
#else
-#define SHARED_ALIGNED_SECTION ".data.percpu.shared_aligned"
+#define SHARED_ALIGNED_SECTION ".percpu.shared_aligned.data"
#endif
#define DEFINE_PER_CPU_SHARED_ALIGNED(type, name) \
--- 0.org/include/linux/spinlock.h Wed Jul 2 00:40:51 2008
+++ 1.fixname/include/linux/spinlock.h Wed Jul 2 00:44:40 2008
@@ -59,7 +59,7 @@
/*
* Must define these before including other files, inline functions need them
*/
-#define LOCK_SECTION_NAME ".text.lock."KBUILD_BASENAME
+#define LOCK_SECTION_NAME ".lock.text."KBUILD_BASENAME
#define LOCK_SECTION_START(extra) \
".subsection 1\n\t" \
--- 0.org/kernel/module.c Wed Jul 2 00:40:51 2008
+++ 1.fixname/kernel/module.c Wed Jul 2 00:45:39 2008
@@ -433,7 +433,7 @@
Elf_Shdr *sechdrs,
const char *secstrings)
{
- return find_sec(hdr, sechdrs, secstrings, ".data.percpu");
+ return find_sec(hdr, sechdrs, secstrings, ".percpu.data");
}
static void percpu_modcopy(void *pcpudest, const void *from, unsigned long size)
--- 0.org/scripts/mod/modpost.c Wed Jul 2 00:40:54 2008
+++ 1.fixname/scripts/mod/modpost.c Wed Jul 2 00:54:21 2008
@@ -794,9 +794,9 @@
/* sections that may refer to an init/exit section with no warning */
static const char *initref_sections[] =
{
- ".text.init.refok*",
- ".exit.text.refok*",
- ".data.init.refok*",
+ ".init.refok.text*",
+ ".exit.refok.text*",
+ ".init.refok.data*",
NULL
};
@@ -915,7 +915,7 @@
* Pattern 0:
* Do not warn if funtion/data are marked with __init_refok/__initdata_refok.
* The pattern is identified by:
- * fromsec = .text.init.refok* | .data.init.refok*
+ * fromsec = .init.refok.text* | .init.refok.data*
*
* Pattern 1:
* If a module parameter is declared __initdata and permissions=0
@@ -939,8 +939,8 @@
* *probe_one, *_console, *_timer
*
* Pattern 3:
- * Whitelist all refereces from .text.head to .init.data
- * Whitelist all refereces from .text.head to .init.text
+ * Whitelist all refereces from .head.text to .init.data
+ * Whitelist all refereces from .head.text to .init.text
*
* Pattern 4:
* Some symbols belong to init section but still it is ok to reference
^ permalink raw reply
* [PATCH 2/23] make section names compatible with -ffunction-sections -fdata-sections: alpha
From: Denys Vlasenko @ 2008-07-02 0:34 UTC (permalink / raw)
To: linux-arch
Cc: Russell King, David Howells, Ralf Baechle, Lennert Buytenhek,
Josh Boyer, Paul Mackerras, David Woodhouse, Andi Kleen, torvalds,
akpm, Paul Gortmaker, linux-embedded, linux-kernel, Tim Bird,
Martin Schwidefsky, Dave Miller
The purpose of this patch is to make kernel buildable
with "gcc -ffunction-sections -fdata-sections".
This patch fixes alpha architecture.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
--
vda
--- 0.org/arch/alpha/kernel/head.S Wed Jul 2 00:40:39 2008
+++ 1.fixname/arch/alpha/kernel/head.S Wed Jul 2 00:44:22 2008
@@ -10,7 +10,7 @@
#include <asm/system.h>
#include <asm/asm-offsets.h>
-.section .text.head, "ax"
+.section .head.text, "ax"
.globl swapper_pg_dir
.globl _stext
swapper_pg_dir=SWAPPER_PGD
--- 0.org/arch/alpha/kernel/init_task.c Wed Jul 2 00:40:39 2008
+++ 1.fixname/arch/alpha/kernel/init_task.c Wed Jul 2 00:45:57 2008
@@ -18,5 +18,5 @@
EXPORT_SYMBOL(init_task);
union thread_union init_thread_union
- __attribute__((section(".data.init_thread")))
+ __attribute__((section(".init_thread.data")))
= { INIT_THREAD_INFO(init_task) };
--- 0.org/arch/alpha/kernel/vmlinux.lds.S Wed Jul 2 00:40:39 2008
+++ 1.fixname/arch/alpha/kernel/vmlinux.lds.S Wed Jul 2 00:46:09 2008
@@ -16,7 +16,7 @@
_text = .; /* Text and read-only data */
.text : {
- *(.text.head)
+ *(.head.text)
TEXT_TEXT
SCHED_TEXT
LOCK_TEXT
@@ -93,18 +93,18 @@
/* Freed after init ends here */
/* Note 2 page alignment above. */
- .data.init_thread : {
- *(.data.init_thread)
+ .init_thread.data : {
+ *(.init_thread.data)
}
. = ALIGN(PAGE_SIZE);
- .data.page_aligned : {
- *(.data.page_aligned)
+ .page_aligned.data : {
+ *(.page_aligned.data)
}
. = ALIGN(64);
- .data.cacheline_aligned : {
- *(.data.cacheline_aligned)
+ .cacheline_aligned.data : {
+ *(.cacheline_aligned.data)
}
_data = .;
^ permalink raw reply
* [PATCH 3/23] make section names compatible with -ffunction-sections -fdata-sections: arm
From: Denys Vlasenko @ 2008-07-02 0:34 UTC (permalink / raw)
To: linux-arch
Cc: Russell King, David Howells, Ralf Baechle, Lennert Buytenhek,
Josh Boyer, Paul Mackerras, David Woodhouse, Andi Kleen, torvalds,
akpm, Paul Gortmaker, linux-embedded, linux-kernel, Tim Bird,
Martin Schwidefsky, Dave Miller
The purpose of this patch is to make kernel buildable
with "gcc -ffunction-sections -fdata-sections".
This patch fixes arm architecture.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
--
vda
--- 0.org/arch/arm/kernel/head-nommu.S Wed Jul 2 00:40:39 2008
+++ 1.fixname/arch/arm/kernel/head-nommu.S Wed Jul 2 00:44:22 2008
@@ -33,7 +33,7 @@
* numbers for r1.
*
*/
- .section ".text.head", "ax"
+ .section ".head.text", "ax"
.type stext, %function
ENTRY(stext)
msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode
--- 0.org/arch/arm/kernel/head.S Wed Jul 2 00:40:39 2008
+++ 1.fixname/arch/arm/kernel/head.S Wed Jul 2 00:44:22 2008
@@ -74,7 +74,7 @@
* crap here - that's what the boot loader (or in extreme, well justified
* circumstances, zImage) is for.
*/
- .section ".text.head", "ax"
+ .section ".head.text", "ax"
.type stext, %function
ENTRY(stext)
msr cpsr_c, #PSR_F_BIT | PSR_I_BIT | SVC_MODE @ ensure svc mode
--- 0.org/arch/arm/kernel/init_task.c Wed Jul 2 00:40:39 2008
+++ 1.fixname/arch/arm/kernel/init_task.c Wed Jul 2 00:45:57 2008
@@ -30,7 +30,7 @@
* The things we do for performance..
*/
union thread_union init_thread_union
- __attribute__((__section__(".data.init_task"))) =
+ __attribute__((__section__(".init_task.data"))) =
{ INIT_THREAD_INFO(init_task) };
/*
--- 0.org/arch/arm/kernel/vmlinux.lds.S Wed Jul 2 00:40:39 2008
+++ 1.fixname/arch/arm/kernel/vmlinux.lds.S Wed Jul 2 00:46:03 2008
@@ -23,10 +23,10 @@
#else
. = PAGE_OFFSET + TEXT_OFFSET;
#endif
- .text.head : {
+ .head.text : {
_stext = .;
_sinittext = .;
- *(.text.head)
+ *(.head.text)
}
.init : { /* Init code and data */
@@ -65,8 +65,8 @@
#endif
. = ALIGN(4096);
__per_cpu_start = .;
- *(.data.percpu)
- *(.data.percpu.shared_aligned)
+ *(.percpu.data)
+ *(.percpu.shared_aligned.data)
__per_cpu_end = .;
#ifndef CONFIG_XIP_KERNEL
__init_begin = _stext;
@@ -125,7 +125,7 @@
* first, the init task union, aligned
* to an 8192 byte boundary.
*/
- *(.data.init_task)
+ *(.init_task.data)
#ifdef CONFIG_XIP_KERNEL
. = ALIGN(4096);
@@ -137,7 +137,7 @@
. = ALIGN(4096);
__nosave_begin = .;
- *(.data.nosave)
+ *(.nosave.data)
. = ALIGN(4096);
__nosave_end = .;
@@ -145,7 +145,7 @@
* then the cacheline aligned data
*/
. = ALIGN(32);
- *(.data.cacheline_aligned)
+ *(.cacheline_aligned.data)
/*
* The exception fixup table (might need resorting at runtime)
--- 0.org/arch/arm/mm/proc-v6.S Wed Jul 2 00:40:40 2008
+++ 1.fixname/arch/arm/mm/proc-v6.S Wed Jul 2 00:44:28 2008
@@ -164,7 +164,7 @@
.asciz "ARMv6-compatible processor"
.align
- .section ".text.init", #alloc, #execinstr
+ .section ".init.text", #alloc, #execinstr
/*
* __v6_setup
--- 0.org/arch/arm/mm/proc-v7.S Wed Jul 2 00:40:40 2008
+++ 1.fixname/arch/arm/mm/proc-v7.S Wed Jul 2 00:44:28 2008
@@ -146,7 +146,7 @@
.ascii "ARMv7 Processor"
.align
- .section ".text.init", #alloc, #execinstr
+ .section ".init.text", #alloc, #execinstr
/*
* __v7_setup
--- 0.org/arch/arm/mm/tlb-v6.S Wed Jul 2 00:40:40 2008
+++ 1.fixname/arch/arm/mm/tlb-v6.S Wed Jul 2 00:44:28 2008
@@ -87,7 +87,7 @@
mcr p15, 0, r2, c7, c5, 4 @ prefetch flush
mov pc, lr
- .section ".text.init", #alloc, #execinstr
+ .section ".init.text", #alloc, #execinstr
.type v6wbi_tlb_fns, #object
ENTRY(v6wbi_tlb_fns)
--- 0.org/arch/arm/mm/tlb-v7.S Wed Jul 2 00:40:40 2008
+++ 1.fixname/arch/arm/mm/tlb-v7.S Wed Jul 2 00:44:28 2008
@@ -78,7 +78,7 @@
isb
mov pc, lr
- .section ".text.init", #alloc, #execinstr
+ .section ".init.text", #alloc, #execinstr
.type v7wbi_tlb_fns, #object
ENTRY(v7wbi_tlb_fns)
^ permalink raw reply
* [PATCH 4/23] make section names compatible with -ffunction-sections -fdata-sections: avr
From: Denys Vlasenko @ 2008-07-02 0:34 UTC (permalink / raw)
To: linux-arch
Cc: Russell King, David Howells, Ralf Baechle, Lennert Buytenhek,
Josh Boyer, Paul Mackerras, David Woodhouse, Andi Kleen, torvalds,
akpm, Paul Gortmaker, linux-embedded, linux-kernel, Tim Bird,
Martin Schwidefsky, Dave Miller
The purpose of this patch is to make kernel buildable
with "gcc -ffunction-sections -fdata-sections".
This patch fixes avr architecture.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
--
vda
--- 0.org/arch/avr32/kernel/init_task.c Wed Jul 2 00:40:40 2008
+++ 1.fixname/arch/avr32/kernel/init_task.c Wed Jul 2 00:45:57 2008
@@ -24,7 +24,7 @@
* Initial thread structure. Must be aligned on an 8192-byte boundary.
*/
union thread_union init_thread_union
- __attribute__((__section__(".data.init_task"))) =
+ __attribute__((__section__(".init_task.data"))) =
{ INIT_THREAD_INFO(init_task) };
/*
--- 0.org/arch/avr32/kernel/vmlinux.lds.S Wed Jul 2 00:40:40 2008
+++ 1.fixname/arch/avr32/kernel/vmlinux.lds.S Wed Jul 2 00:45:57 2008
@@ -105,11 +105,11 @@
/*
* First, the init task union, aligned to an 8K boundary.
*/
- *(.data.init_task)
+ *(.init_task.data)
/* Then, the cacheline aligned data */
. = ALIGN(L1_CACHE_BYTES);
- *(.data.cacheline_aligned)
+ *(.cacheline_aligned.data)
/* And the rest... */
*(.data.rel*)
^ permalink raw reply
* [PATCH 5/23] make section names compatible with -ffunction-sections -fdata-sections: blackfin
From: Denys Vlasenko @ 2008-07-02 0:35 UTC (permalink / raw)
To: linux-arch
Cc: Russell King, David Howells, Ralf Baechle, Lennert Buytenhek,
Josh Boyer, Paul Mackerras, David Woodhouse, Andi Kleen, torvalds,
akpm, Paul Gortmaker, linux-embedded, linux-kernel, Tim Bird,
Martin Schwidefsky, Dave Miller
The purpose of this patch is to make kernel buildable
with "gcc -ffunction-sections -fdata-sections".
This patch fixes blackfin architecture.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
--
vda
--- 0.org/arch/blackfin/kernel/vmlinux.lds.S Wed Jul 2 00:40:40 2008
+++ 1.fixname/arch/blackfin/kernel/vmlinux.lds.S Wed Jul 2 00:45:51 2008
@@ -91,7 +91,7 @@
__sdata = .;
/* This gets done first, so the glob doesn't suck it in */
. = ALIGN(32);
- *(.data.cacheline_aligned)
+ *(.cacheline_aligned.data)
#if !L1_DATA_A_LENGTH
. = ALIGN(32);
^ permalink raw reply
* [PATCH 6/23] make section names compatible with -ffunction-sections -fdata-sections: cris
From: Denys Vlasenko @ 2008-07-02 0:35 UTC (permalink / raw)
To: linux-arch
Cc: Russell King, David Howells, Ralf Baechle, Lennert Buytenhek,
Josh Boyer, Paul Mackerras, David Woodhouse, Andi Kleen, torvalds,
akpm, Paul Gortmaker, linux-embedded, linux-kernel, Tim Bird,
Martin Schwidefsky, Dave Miller
The purpose of this patch is to make kernel buildable
with "gcc -ffunction-sections -fdata-sections".
This patch fixes cris architecture.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
--
vda
--- 0.org/arch/cris/arch-v10/vmlinux.lds.S Wed Jul 2 00:40:40 2008
+++ 1.fixname/arch/cris/arch-v10/vmlinux.lds.S Wed Jul 2 00:45:57 2008
@@ -51,7 +51,7 @@
_edata = . ;
. = ALIGN(PAGE_SIZE); /* init_task and stack, must be aligned */
- .data.init_task : { *(.data.init_task) }
+ .init_task.data : { *(.init_task.data) }
. = ALIGN(PAGE_SIZE); /* Init code and data */
__init_begin = .;
--- 0.org/arch/cris/arch-v32/vmlinux.lds.S Wed Jul 2 00:40:40 2008
+++ 1.fixname/arch/cris/arch-v32/vmlinux.lds.S Wed Jul 2 00:45:57 2008
@@ -63,7 +63,7 @@
_edata = . ;
. = ALIGN(PAGE_SIZE); /* init_task and stack, must be aligned. */
- .data.init_task : { *(.data.init_task) }
+ .init_task.data : { *(.init_task.data) }
. = ALIGN(PAGE_SIZE); /* Init code and data. */
__init_begin = .;
--- 0.org/arch/cris/kernel/process.c Wed Jul 2 00:40:40 2008
+++ 1.fixname/arch/cris/kernel/process.c Wed Jul 2 00:45:57 2008
@@ -52,7 +52,7 @@
* "init_task" linker map entry..
*/
union thread_union init_thread_union
- __attribute__((__section__(".data.init_task"))) =
+ __attribute__((__section__(".init_task.data"))) =
{ INIT_THREAD_INFO(init_task) };
/*
^ 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