Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756579AbdDPRXq (ORCPT ); Sun, 16 Apr 2017 13:23:46 -0400 Received: from 7.mo177.mail-out.ovh.net ([46.105.61.149]:54047 "EHLO 7.mo177.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756167AbdDPRXn (ORCPT ); Sun, 16 Apr 2017 13:23:43 -0400 X-Greylist: delayed 1819 seconds by postgrey-1.27 at vger.kernel.org; Sun, 16 Apr 2017 13:23:43 EDT Subject: Re: [PATCH v1 1/1] mtd: mtk-nor: set controller's address width according to nor flash To: Guochun Mao References: <1491381462-21893-1-git-send-email-guochun.mao@mediatek.com> <1491381462-21893-2-git-send-email-guochun.mao@mediatek.com> <1492051237.2866.36.camel@mhfsdcap03> <3cf1c63e-c56f-2f07-9d16-7ec346758dfa@wedev4u.fr> Cc: Mark Rutland , devicetree@vger.kernel.org, Richard Weinberger , Russell King , linux-kernel@vger.kernel.org, Rob Herring , linux-mtd@lists.infradead.org, Matthias Brugger , linux-mediatek@lists.infradead.org, Cyrille Pitchen , David Woodhouse , linux-arm-kernel@lists.infradead.org From: Cyrille Pitchen Message-ID: Date: Sun, 16 Apr 2017 19:18:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <3cf1c63e-c56f-2f07-9d16-7ec346758dfa@wedev4u.fr> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Ovh-Tracer-Id: 12062891604578293756 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrfeeliedrvdeggdduuddvucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddm Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3902 Lines: 136 Le 13/04/2017 à 10:24, Cyrille Pitchen a écrit : > Hi Guochun, > > Le 13/04/2017 à 04:40, Guochun Mao a écrit : >> Hi Cyrille, >> >> On Wed, 2017-04-12 at 22:57 +0200, Cyrille Pitchen wrote: >>> Hi Guochun, >>> >>> Le 05/04/2017 à 10:37, Guochun Mao a écrit : >>>> When nor's size larger than 16MByte, nor's address width maybe >>>> set to 3 or 4, and controller should change address width according >>>> to nor's setting. >>>> >>>> Signed-off-by: Guochun Mao st > > Acked-by: Cyrille Pitchen > Applied to github/spi-nor Thanks! >>>> --- >>>> drivers/mtd/spi-nor/mtk-quadspi.c | 27 +++++++++++++++++++++++++++ >>>> 1 file changed, 27 insertions(+) >>>> >>>> diff --git a/drivers/mtd/spi-nor/mtk-quadspi.c b/drivers/mtd/spi-nor/mtk-quadspi.c >>>> index e661877..b637770 100644 >>>> --- a/drivers/mtd/spi-nor/mtk-quadspi.c >>>> +++ b/drivers/mtd/spi-nor/mtk-quadspi.c >>>> @@ -104,6 +104,8 @@ >>>> #define MTK_NOR_MAX_RX_TX_SHIFT 6 >>>> /* can shift up to 56 bits (7 bytes) transfer by MTK_NOR_PRG_CMD */ >>>> #define MTK_NOR_MAX_SHIFT 7 >>>> +/* nor controller 4-byte address mode enable bit */ >>>> +#define MTK_NOR_4B_ADDR_EN BIT(4) >>>> >>>> /* Helpers for accessing the program data / shift data registers */ >>>> #define MTK_NOR_PRG_REG(n) (MTK_NOR_PRGDATA0_REG + 4 * (n)) >>>> @@ -230,10 +232,35 @@ static int mt8173_nor_write_buffer_disable(struct mt8173_nor *mt8173_nor) >>>> 10000); >>>> } >>>> >>>> +static void mt8173_nor_set_addr_width(struct mt8173_nor *mt8173_nor) >>>> +{ >>>> + u8 val; >>>> + struct spi_nor *nor = &mt8173_nor->nor; >>>> + >>>> + val = readb(mt8173_nor->base + MTK_NOR_DUAL_REG); >>>> + >>>> + switch (nor->addr_width) { >>>> + case 3: >>>> + val &= ~MTK_NOR_4B_ADDR_EN; >>>> + break; >>>> + case 4: >>>> + val |= MTK_NOR_4B_ADDR_EN; >>>> + break; >>>> + default: >>>> + dev_warn(mt8173_nor->dev, "Unexpected address width %u.\n", >>>> + nor->addr_width); >>>> + break; >>>> + } >>>> + >>>> + writeb(val, mt8173_nor->base + MTK_NOR_DUAL_REG); >>>> +} >>>> + >>>> static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr) >>>> { >>>> int i; >>>> >>>> + mt8173_nor_set_addr_width(mt8173_nor); >>>> + >>>> for (i = 0; i < 3; i++) { >>> >>> Should it be 'i < nor->addr_width' instead of 'i < 3' ? >>> Does it work when accessing data after 128Mbit ? >> >> Yes, it can work. >> >> Let's see the whole function, >> >> static void mt8173_nor_set_addr(struct mt8173_nor *mt8173_nor, u32 addr) >> { >> int i; >> >> mt8173_nor_set_addr_width(mt8173_nor); >> >> for (i = 0; i < 3; i++) { >> writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG >> + i * 4); >> addr >>= 8; >> } >> /* Last register is non-contiguous */ >> writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR3_REG); >> } >> >> The nor controller has 4 registers for address. >> This '3' indicates the number of contiguous address' registers >> base + MTK_NOR_RADR0_REG(0x10) >> base + MTK_NOR_RADR1_REG(0x14) >> base + MTK_NOR_RADR2_REG(0x18), >> but the last address register is non-contiguous, >> it's base + MTK_NOR_RADR3_REG(0xc8) >> >> mt8173_nor_set_addr will set addr into these 4 registers by Byte. >> The bit MTK_NOR_4B_ADDR_EN will decide whether 3-byte(0x10,0x14,0x18) >> or 4-byte(0x10,0x14,x018,0xc8) been sent to nor device. >> and, it can access data after 128Mbit when sent 4-byte address. > > Indeed, you're right. Sorry for the noise! > >> >> Best regards, >> >> Guochun >> >>> >>> Best regards, >>> >>> Cyrille >>> >>>> writeb(addr & 0xff, mt8173_nor->base + MTK_NOR_RADR0_REG + i * 4); >>>> addr >>= 8; >>>> >>> >> >> >> > > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ >