headers
Nicolas Pitre | 1 Oct 2008 05:20

Re: [PATCH 21/25] [ARM] fix value of MAX_DMA_ADDRESS

On Tue, 30 Sep 2008, Russell King - ARM Linux wrote:

> On Tue, Sep 30, 2008 at 02:24:00PM -0400, Nicolas Pitre wrote:
> > On Tue, 30 Sep 2008, Russell King - ARM Linux wrote:
> > > Given the definition I've just given, if there's no restrictions on
> > > what can be DMA'd from, defining 'MAX_DMA_ADDRESS' to a constant well
> > > in excess of the maximum amount of RAM is quite reasonable.  Since most
> > > ARM platforms don't have any restrictions on memory that can be DMA'd,
> > > the existing code is perfectly reasonable and correct.
> > 
> > It falls apart when the range check on values passed to __pa() is 
> > enabled in a highmem context.
> 
> As I say, having it in excess of the real amount of RAM fitted is not a
> problem.  Unfortunately, it makes the range check fall apart but I suspect
> that's because of inappropriate use.

Being in excess of the real amount of RAM might be fine, but has no real 
benefit that I can see.

Since this is marginally used anyway, and only relevant for devices 
unlikely to be found on ARM systems with highmem, maybe we could simply 
define it as the maximum allowed kernel virtual address when 
CONFIG_DEBUG_HIGHMEM is set?  Any other ideas?

Nicolas

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
(Continue reading)

Permalink | Reply | 0 comments |
headers
Nicolas Pitre | 1 Oct 2008 05:58

[PATCH] make ZONE_DMA optional


Most ARM machines simply don't need a special "DMA" memory zone, and
when configured out, the kernel becomes a bit smaller:

|   text    data     bss     dec     hex filename
|3826182  102384  111700 4040266  3da64a vmlinux
|3823593  101616  111700 4036909  3d992d vmlinux.nodmazone

So let's configure this zone only on machines that need it, and use
the proper MAX_DMA_ADDRESS definition to initialize it instead of a
redundant  arch_adjust_zones() macro.

Finally move this stuff in */dma.h instead of */memory.h to ease
maintenance.

Signed-off-by: Nicolas Pitre <nico <at> marvell.com>
---

 arch/arm/Kconfig                            |    4 ++-
 arch/arm/common/Kconfig                     |    3 +-
 arch/arm/common/sa1111.c                    |   11 --------
 arch/arm/include/asm/dma.h                  |   16 +++++++++++-
 arch/arm/include/asm/memory.h               |    4 ---
 arch/arm/mach-davinci/include/mach/dma.h    |    8 +++++-
 arch/arm/mach-davinci/include/mach/memory.h |   26 --------------------
 arch/arm/mach-ixp4xx/common-pci.c           |   23 -----------------
 arch/arm/mach-ixp4xx/include/mach/dma.h     |   13 +++++++++-
 arch/arm/mach-ixp4xx/include/mach/memory.h  |   13 ----------
 arch/arm/mach-pxa/Kconfig                   |    1 +
 arch/arm/mach-pxa/cm-x270-pci.c             |   27 ---------------------
(Continue reading)

Permalink | Reply | 2 comments |
headers
Russell King - ARM Linux | 1 Oct 2008 08:00
Picon

Mailing List Etiquette

This message is sent to this mailing list once a week.

This can also be found (with html links) at:
   http://www.arm.linux.org.uk/mailinglists/etiquette.php

             The list below are specific to the lists.arm.linux.org.uk mailing
             lists. Where they differ with respect to RFC1855, these points
             override those in RFC1855:

              1. [12]Subscription requirements.
              2. [13]Sending a new message to the list.
              3. [14]Replying to a message from the list.
              4. [15]Sending a message to multiple linux-arm* lists.
              5. [16]HTML encoded messages.
              6. [17]Email attachments.
              7. [18]Commercial email.
              8. [19]Searching the archives.
              9. [20]Support for commercial products.
             10. [21]Cross-posting between linux-arm* lists and other lists.
             11. [22]Automatic replies.
             12. [23]Virus scanners and email sanitisers.

             1. Subscription requirements. [[24]rmk]
                Recently, we have had to impose a restriction on the mailing lists.
                You must be subscribed to the mailing list in order to post
                messages to that mailing list. This is because of the UK Data
                Protection laws. Only subscribe to these lists if you accept the
                legal notice displayed on the relevant pages; by subscribing, you
                accept the terms laid out in the legal notice. Answers will be
                copied to you.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell King - ARM Linux | 1 Oct 2008 08:00
Picon

Mailing List FAQ

This message is sent to this mailing list once a week.

This can also be found (with html links) at:
   http://www.arm.linux.org.uk/mailinglists/faq.php

                   1. [12]How do I compile a kernel for ARM?
                   2. [13]Can I use Intel IXP425 AccessLibrary with 2.6 kernels?
                   3. [14]What are the available solutions for floating point support?
                   4. [15]Can I use the both hard & soft float at the same time or only choose one
                      of them?
                   5. [16]When I compile my 2.6.x kernel for ARM I get a compiler/assembler error.
                      Any idea ?
                   6. [17]When I trace kernel in head.S I found problems that may be caused by
                      __turn_mmu_on. Any idea ?
                   7. [18]I'm working on a bootloader, where can I find ARM Linux kernel booting
                      requirements ?
                   8. [19]How can I access /dev/mem ? - How can I map memory in user space ?
                   9. [20]I see '$a', '$d' and '$t' symbols in the backtrace/ksymoops
                      output/System.map/linker error messages. What are they and how can I get rid
                      of them ?
                  10. [21]Where can I find -rmk -pxa -* patches for the 2.6 kernel ?
                  11. [22]I'm using this 2.4 kernel, and ...
                  12. [23]I'm using this 2.6 kernel, and ...
                  13. [24]Why does my debugger trap in __arch_clear_user?

              3. Patch Submission (via git/patches etc)

                   1. [25]Where should patches be reviewed?
                   2. [26]What does rmk's "ok" mean?
                   3. [27]Which git commit should I base my tree on?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Russell King - ARM Linux | 1 Oct 2008 10:21
Picon

Re: [PATCH] make ZONE_DMA optional

On Tue, Sep 30, 2008 at 11:58:04PM -0400, Nicolas Pitre wrote:
> +#elif !defined(CONFIG_ZONE_DMA)
> +#error "your machine defines MAX_DMA_ADDRESS but doesn't select CONFIG_ONE_DMA"
> +#endif
> +
> +/*
> + * The DMA mask corresponding to the maximum bus address allocatable
> + * using GFP_DMA.  The default here places no restriction on DMA
> + * allocations.  This must be the smallest DMA mask in the system,
> + * so a successful GFP_DMA allocation will always satisfy this.
> + */
> +#ifndef ISA_DMA_THRESHOLD
> +#define ISA_DMA_THRESHOLD	(0xffffffffULL)
>  #endif

ISA_DMA_THRESHOLD must be via asm/scatterlist.h

> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 30a69d6..3b9dea2 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
>  <at>  <at>  -276,21 +276,30  <at>  <at>  bootmem_init_node(int node, int initrd_node, struct meminfo *mi)
>  	 * to do anything fancy with the allocation of this memory to the
>  	 * zones, now is the time to do it.
>  	 */
> -	zone_size[0] = end_pfn - start_pfn;
> +	zone_size[ZONE_NORMAL] = end_pfn - start_pfn;
>  
>  	/*
>  	 * For each bank in this node, calculate the size of the holes.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Kristoffer Ericson | 1 Oct 2008 10:52
Picon

Re: Upgrade from 2.4 to 2.6.26 with u-boot 1.1.4

On Wed, 01 Oct 2008 08:58:01 +1300
Michal Ludvig <mludvig <at> logix.net.nz> wrote:

You should get early_printk going since it will
tell you more about where it actually stops.

> Hi all,
> 
> I've got a small device based on Samsung S3C2410 ARM9 CPU. Currently
> the board runs 2.4.18-rmk7 (from MiziLinux SDK) and I'm trying to
> upgrade it to 2.6.26. We're using u-boot 1.1.4 as the bootloader.
> 
> ==== 2.4.18-rmk7-pxe1-mz5 ====
> NAND Flash Reading
> dst base address          = 0x30100000
> Source start block number = 20
> Source size  (0x4000*n)   = 0xf0000
> ## Booting image at 30100000 ...
>    Image Name:   Kernel Image
>    Created:      2008-09-29   9:00:19 UTC
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    804912 Bytes = 786 kB
>    Load Address: 30008000
>    Entry Point:  30008000
>    Verifying Checksum ... OK
> OK
> 
> Starting kernel ...
> Uncompressing Linux ......................... done, booting the kernel.
> Linux version 2.4.18-rmk7-pxa1 (mludvig <at> rumburak) (gcc version 2.95.3
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paulius Zaleckas | 1 Oct 2008 11:04
Picon

Re: Upgrade from 2.4 to 2.6.26 with u-boot 1.1.4

Michal Ludvig wrote:
> Hi all,
> 
> I've got a small device based on Samsung S3C2410 ARM9 CPU. Currently
> the board runs 2.4.18-rmk7 (from MiziLinux SDK) and I'm trying to
> upgrade it to 2.6.26. We're using u-boot 1.1.4 as the bootloader.
> 
[...]
> However with 2.6.26 the kernel only uncompresses and that's it.
> 
> ==== 2.6.26 ====
> ## Booting image at 30308000 ...
>    Image Name:   Kernel Image
>    Created:      2008-09-30   2:27:05 UTC
>    Image Type:   ARM Linux Kernel Image (uncompressed)
>    Data Size:    1385796 Bytes =  1.3 MB
>    Load Address: 30008000
>    Entry Point:  30008000
>    Verifying Checksum ... OK
> OK
> 
> Starting kernel ...
> Uncompressing Linux ......................... done, booting the kernel.
> <that's it, no more output>
> ==== /2.6.26 ====
> 
> How can I tell what's going on and what the kernel does, if anything?
> The 2.6.26 is configured, to my best knowledge, for the right S3C2410
> CPU and architecture and it's compiled with gcc-3.4.6
> (arm-linux-gcc). My .config is at
(Continue reading)

Permalink | Reply | 12 comments |
headers
Adhiraj Joshi | 1 Oct 2008 12:07
Favicon

Implementing P+Q on iop 348

Hi All,

I am working on an iop348 machine on which I want to use iop's P+Q
facility. I found out from the iop-adma driver that not all functions
are implemented. The iop348 is supposed to support these functions:

1. XOR operation
2. XOR operation with P+Q RAID6
3. Dual XOR operation
4. P+Q update operation
5. Zero result buffer check operation
6. P+Q zero result buffer check operation

Out of these 1, 3 and 5 are implemented. I didnt find anything about 2
and 4 which I want to use and implement in case they are not
implemented. Any idea, if there is any work going on, on these things?
Also any help in providing pointers for implementing P+Q functionality
using iop's hardware support will be highly appreciated. I do have
Intel's developers manual in hand and I know the P+Q theory (have
implemented it in userland :-)).

Thanks and regards,
Adhiraj.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php
(Continue reading)

Permalink | Reply | 6 comments |
headers
pHilipp Zabel | 1 Oct 2008 15:53
Picon
Gravatar

Re: PXA and SA1100 RTC compatibility break

On Tue, Sep 30, 2008 at 4:35 PM, Robert Jarzmik <robert.jarzmik <at> free.fr> wrote:
> I'm submitting a patch to ARM patch system to change the behaviour of PXA real
> time clock at kernel initialization. If you don't really care, just drop the
> mail (a reply with an "I don't care" would be appreciated if you can).
>
> Now, if you read that far, you care, good.
>
> The behaviour of drivers/rtc/rtc-sa1100.c will be changed as follows :
>  - at probe(), initial time will be taken from PXA registers RYCR and RDCR,
>  instead of RCNR
>   => this initial time is stored in RCNR
>  - at write() (called by hwclock -w), time is stored in RCNR, RYCR and RDCR
>
> This change is motivated by known IPL and other OSes, which store time in
> RDCR+RYCR, and reset RCNR when the device jumps to ROM bootstrap (when getting
> out of deep suspend for example).
>
> Now, to let that patch be pushed, Russell wants to be sure nobody's code relies
> on RCNR for initial time. So, I'd like you, maintainers of pxa boards or
> machine, to test that patch to see if the patch messes up your code.
>
> Would you be so kind as to reply be either :
>  (a) an Tested-by

Unfortunately I won't be able to test anything until November, so for
now you have my

>  (b) an NAK, with an explanation and the board reference
>  (c) an "I don't care because I don't rely on RTC initial time"
(Continue reading)

Permalink | Reply | 1 comment |
headers
Nicolas Pitre | 1 Oct 2008 18:19

Re: [PATCH] make ZONE_DMA optional

On Wed, 1 Oct 2008, Russell King - ARM Linux wrote:

> On Tue, Sep 30, 2008 at 11:58:04PM -0400, Nicolas Pitre wrote:
> > +#elif !defined(CONFIG_ZONE_DMA)
> > +#error "your machine defines MAX_DMA_ADDRESS but doesn't select CONFIG_ONE_DMA"
> > +#endif
> > +
> > +/*
> > + * The DMA mask corresponding to the maximum bus address allocatable
> > + * using GFP_DMA.  The default here places no restriction on DMA
> > + * allocations.  This must be the smallest DMA mask in the system,
> > + * so a successful GFP_DMA allocation will always satisfy this.
> > + */
> > +#ifndef ISA_DMA_THRESHOLD
> > +#define ISA_DMA_THRESHOLD	(0xffffffffULL)
> >  #endif
> 
> ISA_DMA_THRESHOLD must be via asm/scatterlist.h

Well, I'm thinking that all this stuff is crap.  As we've seen on lkml 
today this is not even defined and/or used consistently.  I'm thinking 
that maybe we should have a MAX_MACH_DMA_SIZE that affected machines can 
define, and then have the common header file define whatever 
MAX_DMA_ADDRESS and ISA_DMA_THRESHOLD (or any successor) derived from 
that.

> > +#ifdef CONFIG_ZONE_DMA
> >  	/*
> >  	 * Adjust the sizes according to any special requirements for
> >  	 * this machine type.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane