From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot0-x241.google.com ([2607:f8b0:4003:c0f::241]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1cTRME-0001ur-HC for linux-mtd@lists.infradead.org; Tue, 17 Jan 2017 10:51:20 +0000 Received: by mail-ot0-x241.google.com with SMTP id 36so8840340otx.3 for ; Tue, 17 Jan 2017 02:50:58 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <20170116220916.2603-1-zajec5@gmail.com> <41e65a7a-e413-9e00-f629-98636ed76212@gmail.com> <353656d9-d2a4-92b6-ce6c-9a3f1d69409f@gmail.com> From: =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= Date: Tue, 17 Jan 2017 11:50:57 +0100 Message-ID: Subject: Re: [PATCH] mtd: bcm47xxsflash: support reading flash out of mapping window To: Marek Vasut Cc: David Woodhouse , Brian Norris , Boris Brezillon , Richard Weinberger , Cyrille Pitchen , "linux-mtd@lists.infradead.org" , Hauke Mehrtens , =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On 17 January 2017 at 11:49, Marek Vasut wrote: > On 01/17/2017 11:39 AM, Rafa=C5=82 Mi=C5=82ecki wrote: >> On 17 January 2017 at 10:49, Marek Vasut wrote: >>> On 01/17/2017 07:58 AM, Rafa=C5=82 Mi=C5=82ecki wrote: >>>> On 17 January 2017 at 04:18, Marek Vasut wrote= : >>>>> On 01/16/2017 11:09 PM, Rafa=C5=82 Mi=C5=82ecki wrote: >>>>>> From: Rafa=C5=82 Mi=C5=82ecki >>>>>> >>>>>> For reading flash content we use MMIO but it's possible to read only >>>>>> first 16 MiB this way. It's simply an arch design/limitation. >>>>>> To support flash sizes bigger than 16 MiB implement indirect access >>>>>> using ChipCommon registers. >>>>>> This has been tested using MX25L25635F. >>>>>> >>>>>> Signed-off-by: Rafa=C5=82 Mi=C5=82ecki >>>>>> --- >>>>>> drivers/mtd/devices/bcm47xxsflash.c | 12 +++++++++++- >>>>>> drivers/mtd/devices/bcm47xxsflash.h | 3 +++ >>>>>> 2 files changed, 14 insertions(+), 1 deletion(-) >>>>>> >>>>>> diff --git a/drivers/mtd/devices/bcm47xxsflash.c b/drivers/mtd/devic= es/bcm47xxsflash.c >>>>>> index 4decd8c..5d57119 100644 >>>>>> --- a/drivers/mtd/devices/bcm47xxsflash.c >>>>>> +++ b/drivers/mtd/devices/bcm47xxsflash.c >>>>>> @@ -110,7 +110,17 @@ static int bcm47xxsflash_read(struct mtd_info *= mtd, loff_t from, size_t len, >>>>>> if ((from + len) > mtd->size) >>>>>> return -EINVAL; >>>>>> >>>>>> - memcpy_fromio(buf, b47s->window + from, len); >>>>>> + if (from + len <=3D BCM47XXSFLASH_WINDOW_SIZE) { >>>>>> + memcpy_fromio(buf, b47s->window + from, len); >>>>>> + } else { >>>>>> + size_t i; >>>>>> + >>>>>> + for (i =3D 0; i < len; i++) { >>>>>> + b47s->cc_write(b47s, BCMA_CC_FLASHADDR, from++= ); >>>>>> + bcm47xxsflash_cmd(b47s, OPCODE_ST_READ4B); >>>>>> + *(buf++) =3D b47s->cc_read(b47s, BCMA_CC_FLASH= DATA) & 0xff; >>>>> >>>>> Do you really need to send command on every write into the FLASHADDR >>>>> register ? Doesn't this hardware support some sort of seqeuntial read= ing? >>>> >>>> Yes, I need to. If there is some other way it's undocumented and not >>>> used by Broadcom. As a quick check I tried not writing to FLASHADDR >>>> every time, but it didn't work. >>> >>> Oh well, that's a bit sad. Thanks for checking. >>> >>>>> Are you sure this has no side-effects when you mix this with reading >>>>> from the flash window ? >>>> >>>> No side effects. I also tried reading whole flash content using this >>>> indirect access and it worked as well. >>> >>> Well, if you read the whole flash, you will trigger the first windowed >>> read and then the new code, in sequence. Try doing some read pattern >>> where you read from the beginning and mix it with reads from the end. >>> That will alternate between these two bits of code. >> >> I really can't follow your possible-fail scenario. With my patch first >> 16 MiB are read using windowed access, another 16 MiB using indirect >> access. I scanned whole flash this way, it worked. I got a working >> system. It just works... >> > Well if you scanned the whole flash, you triggered the memcpy_fromio() > first and then the b47s->cc_write(..) stuff , in that order. So does it > work if you read the first 16 MiB after you read the region past 16 MiB? Yes, of course it does. --=20 Rafa=C5=82