headers
Pavel Pisa | 1 Apr 2007 13:04

Re: dm9000 on i.mxl

On Thursday 29 March 2007 11:42, Andrew Ip wrote:
> Hi,
>
> In fact I have used your config in 2.6.16.14.  Just wonder, in what
> circumstances will trigger packet length error.
>
> Here is my setup.
>
> static struct resource imx_dm9000_resources[] = {
>          [0] = {
>                  .start  = IMX_CS5_VIRT,
>                  .end    = IMX_CS5_VIRT + 4,
>                  .flags  = IORESOURCE_MEM,
>          },
>          [1] = {
>                  .start  = IRQ_GPIOA(19),
>                  .end    = IRQ_GPIOA(19),
>                  .flags  = IORESOURCE_IRQ,
>          },
> };
>
> static struct dm9000_plat_data imx_dm9000x_platdata = {
>                  .flags  = DM9000_PLATF_16BITONLY
> };
>
> static struct platform_device imx_dm9000_device = {
>          .name           = "dm9000",
>          .id             = 0,
>          .num_resources  = ARRAY_SIZE(imx_dm9000_resources),
>          .resource       = imx_dm9000_resources,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Uwe Kleine-König | 1 Apr 2007 14:47
Picon
Favicon

Re: [PATCH,RFC] New platform support: TI DaVinci

Hello,

> +	  has I2C exapnder with ATA, USB, CF.
Typo: s/exapnder/expander/

> +/* other misc. init functions */
> +extern void __init davinci_psc_init(void);
> +extern void __init davinci_irq_init(void);
> +extern void __init davinci_map_common_io(void);
are these functions worth a header?  I don't know what's the effect of
using extern for functions is.  I think I read somewhere there is no.
So it's a matter of taste if you want these "extern"s here?

> +#if defined(CONFIG_BLK_DEV_DAVINCI) || defined(CONFIG_BLK_DEV_DAVINCI_MODULE)
> +	printk(KERN_WARNING "WARNING: both IDE and NOR flash are enabled, "
> +	       "but share pins.\n\t Disable IDE for NOR support.\n");

This sounds serious to me.  Is it sane to continue with a warning?  IMHO
you should disable on of them.  Maybe you want a mechanism to reserve
these pins and make the corresponding drivers exit if they don't get the
pin?  As the user has to connect something to the pin, she must decide
anyhow which function she wants, so #error might be appropriate, too?

> +#define DAVINCI_DEV_ID		0x01c40028
Here DAVINCI_DEV_ID looks like a magic value, but further down it
becomes clear that it's an address.  Maybe

	#define DAVINCI_DEV_ID		(volatile char *)0x01c40028

or something like that would be clearer.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Quinn Jensen | 1 Apr 2007 18:21
Picon

Re: i.MX31 support

Valentin,

On 3/30/07, Valentin Longchamp <valentin.longchamp <at> epfl.ch> wrote:
> So they do not have a public git tree or something similar yet ? There were
> several possibilities (opensource.freescale.com, source.mvista.com) but I
> checked them and found no i.MX31 git tree. Did I miss an e-mail ?
>
> Because it would be great to be able to review their changes.

I'll post the core patch here again soon.  And, hopefully, we'll
have the git tree available this week.  The plan is to have two
branches, one with all of the mx31/mx27 code in it's current
state, and another branch containing the evolving patch set
that is being prepared for the mainline (using StGIT).

I also want to post a list of tasks that we need more
community help with -- a big one being keeping the working
branch in reasonable synch with kernel.org while the
merge scrubbing proceeds.  There will also be plenty
of drivers that need to begin to be reviewed on their
respective mailing lists.

Quinn

-------------------------------------------------------------------
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 | 0 comments |
headers
Pavel Pisa | 2 Apr 2007 00:30

[PATCH] arm: i.MX/MX1 GPIO support implementation

Support for generic input output for MX1 family.
The implementation prevents allocation of one pin
by two users, but does not store pointer to the user
description permanently, because this solution
would have bigger memory overhead.

Signed-off-by: Pavel Pisa <pisa <at> cmp.felk.cvut.cz>

PATCH FOLLOWS
KernelVersion: 2.6.21-rc5

 arch/arm/Kconfig                |    1 
 arch/arm/mach-imx/generic.c     |   65 +++++++++++++++++++++++++++++++
 include/asm-arm/arch-imx/gpio.h |   83 ++++++++++++++++++++++++++++++++++++++++
 3 files changed, 149 insertions(+)

Index: linux-2.6.21-rc5/include/asm-arm/arch-imx/gpio.h
===================================================================
--- /dev/null
+++ linux-2.6.21-rc5/include/asm-arm/arch-imx/gpio.h
 <at>  <at>  -0,0 +1,83  <at>  <at> 
+#ifndef _IMX_GPIO_H
+
+#include <asm/arch/imx-regs.h>
+
+int imx_gpio_request(unsigned gpio, const char *label);
+
+void imx_gpio_free(unsigned gpio);
+
+int imx_gpio_direction_input(unsigned gpio);
(Continue reading)

Permalink | Reply | 3 comments |
headers
Russell King - ARM Linux | 2 Apr 2007 00:34
Picon

REMINDER: Patch Comments/description formatting

The patch system has the following on the help page concerning the
description of patches:

| * Detailed explanation.
|
|   Include some text in the message explaining what the new feature is,
|   the bug, or why the patch is needed.  If the patch relies on some
|   other patch being applied before hand, please supply this information
|   here.  Please also bear in mind that the description will appear in
|   the message sent to upstream to Linus, and in the mainline BitKeeper
|   repository.
|
|   This explanation text should be wrapped around column 68 for consistency
|   and readability sake; these comments are also sent to Linus so Linus
|   himself can understand the reasoning behind the changes.

What this means is that you have to be careful with graphical email
clients which don't do sensible message wrapping.

The reason for pointing this out is that I received the following
in response to my request to merge the latest set of ARM changes from
Linus:

| However, is there any reason why your descriptions have 190-character
| lines (and one 160+ character one)?
|
| That's just ugly.
|
|                 Linus
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dan Williams | 2 Apr 2007 00:50
Picon
Favicon

is it too late in the release cycle to update the mach-types?

Building iop32x_defconfig has been broken since:
---
commit 094f127588679591a871eb20b136f6b2f2796c98
Author: Dan Williams <dan.j.williams <at> intel.com>
Date:   Fri Mar 16 19:31:06 2007 +0100

    [ARM] 4271/1: iop32x: fix ep80219 detection (support iq80219 platforms)

    An iq80219 is a board with an iq31244 layout and an 80219 processor.  It
    breaks the current assumption that all 80219 processors run on ep80219
    platforms.  This patch adds the "force_ep80219" option to the kernel to
    override boot loaders that have passed in the iq31244 id, and adds the
    MACHINE_START definition for ep80219.

    [ patch assumes that EP80219 has been added to mach-types ]

    Signed-off-by: Dan Williams <dan.j.williams <at> intel.com>
    Signed-off-by: Russell King <rmk+kernel <at> arm.linux.org.uk>

---

Regards,
Dan

-------------------------------------------------------------------
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 | 1 comment |
headers
jonghne | 2 Apr 2007 02:33
Favicon

question of tty program functioning prin ciple

hello:
     In a tty program, I use function "tcsetattr" to set the tty port attribute, I want to know how this function
pass attribute parameters to tty driver? My board system  is AT91RM9200-LINUX-2.6.15. I think setting
tty attribute actually set USART mode register, if so , how does linux relate "tcsetattr" function with
at91rm9200 serial driver? what is the functioning routine?
Best regards.
-------------------------------------------------------------------
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
Permalink | Reply | 0 comments |
headers
Joerg Wagner | 2 Apr 2007 08:47
Picon

Re: Beginners question: Kernel freeze after unpacking

Thank you all guys,

we got a contact with ARM and hope to get rid of this issue soon.

Just to inform you:
The serial output should work by default (as the single core kernel image of the same version provides a lot
of serial output on the same board).
So we suppose a problem with the path for SMP (initialization) code, the comments from ARM  also hinted in
that direction. Unfortunately for us it seems to be a problem which does not occur on all MPCore boards :/

Have a nice week !

Joerg

-------------------------------------------------------------------
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
Permalink | Reply | 2 comments |
headers
Russell King - ARM Linux | 2 Apr 2007 10:21
Picon

Re: is it too late in the release cycle to update the mach-types?

On Sun, Apr 01, 2007 at 03:50:49PM -0700, Dan Williams wrote:
> Building iop32x_defconfig has been broken since:

It probably isn't, but I just forget to do it.  It'll be a week away
now until it hits Linus' tree.

-------------------------------------------------------------------
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
Permalink | Reply | 0 comments |
headers
Catalin Marinas | 2 Apr 2007 11:49
Favicon

Re: [rfc, patch] xsc3: use shared device memory for uncached mappings (micro-optimization)

Lennert Buytenhek <buytenh <at> wantstofly.org> wrote:
> On Fri, Mar 23, 2007 at 11:59:12PM +0000, Catalin Marinas wrote:
>> > "For regions of memory marked as Non-shared Non-cacheable, a DMB
>> > memory barrier must be used in situations where the forwarding of
>> > data from the internal buffering of previous accesses within the
>> > single processor is required."
>> 
>> But, as I said, reading through the same Normal memory address on the
>> same CPU will first look in the internal write buffer, hence it is
>> coherent with itself.
>
> What the ARM ARM says is (more or less) that 'a DMB must be used in
> situations where the forwarding of data from the internal buffering
> of previous accesses within the single processor is required'.
>
> 'Forwarding' is the kind of word that a CPU architect would use when
> describing the type of hardware circuitry responsible for making sure
> that Read-After-Write hazards do not occur.
>
> To me, it sounds like the CPU is not consistent with itself unless
> you use DMBs.  I don't understand why they would put the above language
> in the ARM if it were very easy to always satisfy loads from stores
> pending in the 'internal buffering of previous accesses'.
>
>> I can check on Monday with the CPU architects (it's too late here to
>> read and understand the ARM ARM :-)), but I doubt this may be different.
>
> I'd be very interested in what they have to say..

It is one week later but here is the answer I got. The wording is
(Continue reading)

Permalink | Reply | 3 comments |

Gmane