Hi Mike,
> when you're editing a commit in the middle of a rebase, you can add on any
> number of commits you like on top of it. so usually the way i split commits:
> git rebase -i ^
>
>
> git format-patch -1
>
> patch -p1 -R < 0001-*
> git commit -a
Dear Reinhard Meyer,
In message <4c760243.6030...@emk-elektronik.de> you wrote:
> Dear Mike Frysinger,
> > i dont have a problem with going through the env as a hook, but it doesnt
> > seem
> > to scale. what if you have 2 fram devices and a winbond spi flash ?
> > perhaps
> > the name spec sh
On 29.08.2010 06:34, Mike Frysinger wrote:
> when you're editing a commit in the middle of a rebase, you can add on any
> number of commits you like on top of it. so usually the way i split commits:
> git rebase -i^
>
>
> git format-patch -1
>
> patch -p1 -R<
On Saturday, August 28, 2010 23:35:08 Reinhard Meyer wrote:
> On 29.08.2010 04:26, Mike Frysinger wrote:
> > On Saturday, August 28, 2010 21:59:26 Reinhard Meyer wrote:
> >> On 29.08.2010 02:14, Mike Frysinger wrote:
> >>> if you want to take the patch i posted and extend that by itself with
> >>>
On 29.08.2010 04:26, Mike Frysinger wrote:
> On Saturday, August 28, 2010 21:59:26 Reinhard Meyer wrote:
>> On 29.08.2010 02:14, Mike Frysinger wrote:
>>> if you want to take the patch i posted and extend that by itself with the
>>> comments here, and then do the ramtron patch separately on top of
On Saturday, August 28, 2010 21:59:26 Reinhard Meyer wrote:
> On 29.08.2010 02:14, Mike Frysinger wrote:
> > if you want to take the patch i posted and extend that by itself with the
> > comments here, and then do the ramtron patch separately on top of that,
> > that'd be great.
>
> Hehe, you like
On 29.08.2010 02:14, Mike Frysinger wrote:
> if you want to take the patch i posted and extend that by itself with the
> comments here, and then do the ramtron patch separately on top of that, that'd
> be great.
Hehe, you like to impose extra work on poor moi
the first patch would add the tab
On Saturday, August 28, 2010 19:45:57 Reinhard Meyer wrote:
> On 29.08.2010 01:17, Mike Frysinger wrote:
> > On Saturday, August 28, 2010 17:48:39 Mike Frysinger wrote:
> >> + /* Make sure the ID was jedec extended */
> >> + j = flashes[i].shift - 1;
> >> +
On 29.08.2010 01:17, Mike Frysinger wrote:
> On Saturday, August 28, 2010 17:48:39 Mike Frysinger wrote:
>> +/* Make sure the ID was jedec extended */
>> +j = flashes[i].shift - 1;
>> +while (j>= 0&& idcode[j] == 0x7f)
>> +
On Saturday, August 28, 2010 17:48:39 Mike Frysinger wrote:
> + /* Make sure the ID was jedec extended */
> + j = flashes[i].shift - 1;
> + while (j >= 0 && idcode[j] == 0x7f)
> + continue;
thinko ... this loop
On Saturday, August 28, 2010 18:15:43 Reinhard Meyer wrote:
> Dear Mike Frysinger,
> > On Thursday, August 26, 2010 16:00:50 Reinhard Meyer wrote:
> > interesting, but what if we push it further. something like this
> > (untested):
>
> That code does not address the following issues to complete ex
Dear Mike Frysinger,
> On Thursday, August 26, 2010 16:00:50 Reinhard Meyer wrote:
> interesting, but what if we push it further. something like this (untested):
That code does not address the following issues to complete extend:
1. JEDEC conformant that have ID in first byte
2. JEDEC conformant
On Thursday, August 26, 2010 16:00:50 Reinhard Meyer wrote:
> 1. according to Ramtron, 0x7f is a continuation byte defined in a
> JEDEC standard (I could not find a spec for that) and shall be
> ignored until a non-0x7f shows.
yep
http://www.jedec.org/standards-documents/results/taxonomy%3A3127
>
Dear Mike,
I have been looking at the possible solutions quite some time now,
the issue is rather complex:
1. according to Ramtron, 0x7f is a continuation byte defined in a
JEDEC standard (I could not find a spec for that), and shall be
ignored until a non-0x7f shows. That shall be Manufacturer I
On Thursday, August 26, 2010 04:27:36 Reinhard Meyer wrote:
> 1. looking at spi_flash.c, shall I add the standard copyright,
> keeping atmel as author?
doesnt matter to me
> 2. I can find the following lengths of idcode used:
> atmel 2
> macronix 3
> ramtron 9
> spansion 5
> sst 3
> stmicro 4
> w
Dear Mike,
1. looking at spi_flash.c, shall I add the standard copyright,
keeping atmel as author?
2. I can find the following lengths of idcode used:
atmel 2
macronix 3
ramtron 9
spansion 5
sst 3
stmicro 4
winbond 3
Do you really want to flexify this? Even before relocation 5 bytes
more on stac
Dear Mike Frysinger,
>>> #if defined(CONFIG_SPI_FRAM_RAMTRON)
>>> # define IDCODE_LEN 10
>>> #else
>>> # define IDCODE_LEN 5
>>> #endif
>>
>> OK, see below. Can't we have it 10 generally? The impact should be
>> negligible?
>
> hrm, i guess ... but i didnt even really like raising it to the 5 for o
On Thursday, August 26, 2010 01:57:23 Reinhard Meyer wrote:
> Dear Mike Frysinger,
> > #if defined(CONFIG_SPI_FRAM_RAMTRON)
> > # define IDCODE_LEN 10
> > #else
> > # define IDCODE_LEN 5
> > #endif
>
> OK, see below. Can't we have it 10 generally? The impact should be
> negligible?
hrm, i guess .
Dear Mike Frysinger,
> i dont have a problem with going through the env as a hook, but it doesnt seem
> to scale. what if you have 2 fram devices and a winbond spi flash ? perhaps
> the name spec should be:
> fram_dev..
>
> then you can signal that only certain. locations should get specia
On Wednesday, August 25, 2010 08:47:19 Reinhard Meyer wrote:
> +/*
> + * Unfortunately, some RAMTRON FRAMs do not have a means of
> + * identifying them. We use an environment variable to select
> + * the device we will handle. The variable "fram_device" should
> + * be set from VPD data.
> + */
i
From: Reinhard Meyer
Signed-off-by: Reinhard Meyer
---
drivers/mtd/spi/Makefile |1 +
drivers/mtd/spi/ramtron.c| 297 ++
drivers/mtd/spi/spi_flash.c | 13 ++
drivers/mtd/spi/spi_flash_internal.h |2 +
4 files changed, 3
21 matches
Mail list logo
