headers
Ulf Samuelsson | 1 Dec 2008 01:08
Favicon

Re: atmel_spi and dataflash problems on at91rm9200


> Hi,
> O.K it does  not  appear to be a NAND device as such, and your good to
> either  33 or 66MHZ  depending on the read mode,
>  so obviously the device has got to be able to work way above the
> 5mhz your using now.
>

You better check the errata #13 of the AT91RM9200 before
running SPI above 5 Mbps.
You will need to have a fix in H/W if you want to run faster.

Best Regards
Ulf Samuelsson

> Also you need a  logic analyser or storage scope, it will allow you to
> see the command sequence in & out of the chip.
>
>
> Yes the device is driven by the #cs,  which WILL terminate the read
> (6.1 in data sheet),  have a look to see what is driving the #cs
> transition
>
> Also if we look at   (1,6) of the data sheet is says the device can be
> configured one of 2 ways,
> 1. (power of 2 binary page size), I don't know if your reading 1024 or
> 1056 bytes and assuming something is missing, because of the device
> setting.
>
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
Jaya Kumar | 1 Dec 2008 02:10
Picon

Re: [RFC 2.6.27 1/1] gpiolib: add support for batch set of pins

On Mon, Dec 1, 2008 at 1:55 AM, David Brownell <david-b <at> pacbell.net> wrote:
>
> They wouldn't want names so easily confused with the current set
> of GPIO calls, no.
>

Okay, how does gpio_set/get_values_batch() sound?

>
>> >
>> > Then separately two more things:
>> >
>> >  - A gpio_* interface proposal for higher-level bitmask calls.
>> >   This is worth some discussion; the calls should clearly
>> >   be optional (not everything will implement them), and I
>> >   can't help but suspect <linux/bitmap.h> interfaces should
>> >   interoperate smoothly.
>
> ... including probably ganged request/free, and direction updates.
> When bitbanging a multiplexed parallel databus, you'll often need
> to change directions.

Okay, so I'll also add gpio_direction_output/input_batch and request/free_batch.

>
>
>> >
>> >  - A gpiolib based implementation, using those new gpio_chip
>> >   methods as accelerators if they're present.  This should
>> >   probably also be optional, even at the Kconfig level; many
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eric Miao | 1 Dec 2008 02:38
Picon
Gravatar

Re: [RFC] [PATCH] Add basic gumstix verdex support

On Thu, Nov 27, 2008 at 2:31 PM, Mike Rapoport <mike <at> compulab.co.il> wrote:
> Andre Puschmann wrote:
>> Hi,
>>
>> Mike Rapoport schrieb:
>>> Please send patches inline, it's easier to review them this way.
>>
>> Sorry, I'll do it next time!
>>
>>
>>> diff -r 60e44d66a8ce arch/arm/mach-pxa/cpu-pxa.c
>>> --- a/arch/arm/mach-pxa/cpu-pxa.c    Tue Nov 25 16:48:20 2008 +0100
>>> +++ b/arch/arm/mach-pxa/cpu-pxa.c    Wed Nov 26 16:56:23 2008 +0100
>>>  <at>  <at>  -64,7 +64,11  <at>  <at>  typedef struct {
>>>
>>>  /* Define the refresh period in mSec for the SDRAM and the number of rows */
>>>  #define SDRAM_TREF  64      /* standard 64ms SDRAM */
>>> +#ifndef ARCH_GUMSTIX
>>>  #define SDRAM_ROWS  4096    /* 64MB=8192 32MB=4096 */
>>> +#else
>>> +#define SDRAM_ROWS  8192
>>> +#endif /* ARCH_GUMSTIX */
>>>
>>> #ifdef's here break support for multiple PXA platforms in single kernel
>>
>> What do you mean exactly? What would you suggest in order to configure
>> the refresh period for 64MB systems? Merging this define into board config?
>
> At the very least you can make SDRAM_ROWS a variable rather than define, and
> then mdrefr_dri can be
(Continue reading)

Permalink | Reply | 16 comments |
headers
Dmitry Baryshkov | 1 Dec 2008 03:17
Picon
Gravatar

Re: [PATCH] tosa: add physmap mapping for ROM

On Tue, Nov 25, 2008 at 12:57:27AM +0300, Dmitry Baryshkov wrote:
> Add mapping for system ROM using physmap-flash mapping.
> 
> Signed-off-by: Dmitry Baryshkov <dbaryshkov <at> gmail.com>

What about this patchserie? I've made it available, ready to be pulled:

The following changes since commit d9d060a98ff89fe0f86e24c9c0c3d2f0c566781c:
  Linus Torvalds (1):
        Merge branch 'drm-fixes' of git://git.kernel.org/.../airlied/drm-2.6

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/lumag/tosa-2.6.git misc/mtd/sharpsl-physmap

Dmitry Baryshkov (5):
      tosa: add physmap mapping for ROM
      spitz: add physmap mapping for ROM
      corgi: add physmap mapping for ROM
      poodle: add physmap mapping for ROM
      [MTD] Drop now unused sharpsl-flash map

 arch/arm/mach-pxa/corgi.c        |   32 ++++++++++
 arch/arm/mach-pxa/poodle.c       |   32 ++++++++++
 arch/arm/mach-pxa/spitz.c        |   32 ++++++++++
 arch/arm/mach-pxa/tosa.c         |   32 ++++++++++
 drivers/mtd/maps/Kconfig         |    6 --
 drivers/mtd/maps/Makefile        |    1 -
 drivers/mtd/maps/sharpsl-flash.c |  116
--------------------------------------
(Continue reading)

Permalink | Reply | 1 comment |
headers
Eric Miao | 1 Dec 2008 04:46
Picon
Gravatar

[PATCH] locomo: export locomo_frontlight_set()

This symbol is required by locomo backlight driver, exporting this
allows the driver to be built as a module.

Signed-off-by: Eric Miao <eric.miao <at> marvell.com>
---
 arch/arm/common/locomo.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
index 7c6b4b9..2293f0c 100644
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
 <at>  <at>  -1108,6 +1108,7  <at>  <at>  void locomo_frontlight_set(struct locomo_dev
*dev, int duty, int vr, int bpwf)
 	locomo_writel(bpwf | LOCOMO_ALC_EN, lchip->base + LOCOMO_FRONTLIGHT
+ LOCOMO_ALS);
 	spin_unlock_irqrestore(&lchip->lock, flags);
 }
+EXPORT_SYMBOL(locomo_frontlight_set);

 /*
  *	LoCoMo "Register Access Bus."
--

-- 
1.6.0.4

-------------------------------------------------------------------
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
Eric Miao | 1 Dec 2008 04:49
Picon
Gravatar

[ARM] pxa: explicit #include <mach/dma.h> in various drivers

Where 'pxa_dma_desc' and 'pxa_{request,free}_dma' are referenced.

Signed-off-by: Eric Miao <eric.miao <at> marvell.com>
---
 drivers/mtd/nand/pxa3xx_nand.c |    2 +-
 drivers/net/smc911x.h          |    3 +++
 sound/arm/pxa2xx-pcm.h         |    2 +-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/pxa3xx_nand.c b/drivers/mtd/nand/pxa3xx_nand.c
index c0fa9c9..64b3be1 100644
--- a/drivers/mtd/nand/pxa3xx_nand.c
+++ b/drivers/mtd/nand/pxa3xx_nand.c
 <at>  <at>  -20,8 +20,8  <at>  <at> 
 #include <linux/mtd/partitions.h>
 #include <linux/io.h>
 #include <linux/irq.h>
-#include <asm/dma.h>

+#include <mach/dma.h>
 #include <mach/pxa-regs.h>
 #include <mach/pxa3xx_nand.h>

diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
index cc7d85b..870b4c3 100644
--- a/drivers/net/smc911x.h
+++ b/drivers/net/smc911x.h
 <at>  <at>  -200,6 +200,9  <at>  <at>  static inline void SMC_outsl(struct smc911x_local
*lp, int reg,
(Continue reading)

Permalink | Reply | 0 comments |
headers
Eric Miao | 1 Dec 2008 08:41
Picon
Gravatar

Re: [PATCH] tosa: add physmap mapping for ROM

On Mon, Dec 1, 2008 at 10:17 AM, Dmitry Baryshkov <dbaryshkov <at> gmail.com> wrote:
> On Tue, Nov 25, 2008 at 12:57:27AM +0300, Dmitry Baryshkov wrote:
>> Add mapping for system ROM using physmap-flash mapping.
>>
>> Signed-off-by: Dmitry Baryshkov <dbaryshkov <at> gmail.com>
>
> What about this patchserie? I've made it available, ready to be pulled:
>

Looks OK, and verified roughly on akita/corgi. Note I'm not taking the
last patch, which should go through linux-mtd tree instead.

-------------------------------------------------------------------
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
Marc Pignat | 1 Dec 2008 08:54
Picon
Favicon

Re: atmel_spi and dataflash problems on at91rm9200

Hi all!

On Monday 01 December 2008, Ulf Samuelsson wrote:
...
> You better check the errata #13 of the AT91RM9200 before
> running SPI above 5 Mbps.
> You will need to have a fix in H/W if you want to run faster.

Errata #13 is about TWI (i2c) not about spi, but I assume we're talking
about datasheet revision G (september 2006).

Best regards

Marc

-------------------------------------------------------------------
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
Antonio R. Costa | 1 Dec 2008 09:57
Picon

Re: [PATCH 3/5] [RFC PATCH] Support for AT572D940HF-EK [RFC PATCH]

2008/11/30 Russell King - ARM Linux <linux <at> arm.linux.org.uk>:
> On Tue, Nov 25, 2008 at 04:37:15PM +0100, Antonio R. Costa wrote:
>> +config ARCH_AT572D940HF
>> +     bool "AT572D940HF"
>> +     select GENERIC_TIME
>> +     select GENERIC_CLOCKEVENTS
>
> This needs to select the appropriate CPU option.

1) About the CPU option I followed the same path of AT91 chips, so I
will insert:
   select CPU_ARM926T

>
>> diff --git a/arch/arm/mach-at91/clock.h b/arch/arm/mach-at91/clock.h
>> index 1ba3b95..0212c37 100644
>> --- a/arch/arm/mach-at91/clock.h
>> +++ b/arch/arm/mach-at91/clock.h
>>  <at>  <at>  -22,10 +22,15  <at>  <at>  struct clk {
>>       struct clk      *parent;
>>       u32             pmc_mask;
>>       void            (*mode)(struct clk *, int);
>> +#ifdef ARCH_AT572D940HF
>> +     unsigned        id:3;           /* AT572D940HF needs an extra bit */
>> +#else
>>       unsigned        id:2;           /* PCK0..3, or 32k/main/a/b */
>> +#endif
>
> Is there anything wrong with just making this a three bit field?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Paulius Zaleckas | 1 Dec 2008 10:02
Picon

Re: linux-gemini (gitorious.org)

Frédéric Pecourt wrote:
> Dear Sir,
> 
> I found a few weeks ago your great work for the Gemini family processors.

Nice to hear.

> I managed to compile it successfuly. I only had to change :
> MACHINE_START(RUT100, "Teltonika RUT100")
> to
> MACHINE_START(GEMINI, "Teltonika RUT100")
> in
> |arch/arm/mach-gemini/rut1xx.c

Currently I have only our RUT100 board. I had Storlink devboard, but
after some hardware modifications it is dead now :(

> |On my side I am still using an original Storlink port for kernel
> 2.6.15. I was wondering if you had time to go on working on your
> project, and especially around the USB controller.

Yes, I have USB host working (not the mainline quality yet).
I am heavily working on this port and have lots of changes since my
last commit to gitorious.org. Currently I am working on ARM assembler
routines for memory management and context switching. Those chinese
guys did a lot of horrible things :) I plan to commit my changes
this week if everything goes well.

> Best Regards,
> Frederic
(Continue reading)

Permalink | Reply | 0 comments |

Gmane