From: Michael Walle <michael@walle.cc> To: Biju Das <biju.das.jz@bp.renesas.com> Cc: Mark Brown <broonie@kernel.org>, Miquel Raynal <miquel.raynal@bootlin.com>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, linux-spi@vger.kernel.org, linux-mtd@lists.infradead.org, Geert Uytterhoeven <geert+renesas@glider.be>, Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>, "biju.das.au" <biju.das.au@gmail.com>, linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH RFC 0/4] Add set_iofv() callback Date: Fri, 10 Nov 2023 11:11:00 +0100 [thread overview] Message-ID: <dcfa2cab21fc85bb9b2b0c1ceb754a1a@walle.cc> (raw) In-Reply-To: <TYCPR01MB112699263B2EC0EC229746D3786AFA@TYCPR01MB11269.jpnprd01.prod.outlook.com> Hi Biju, >> >> Thus I was saying, that we probably wont support that and the easiest >> >> fix should be to disable this behavior for the atmel flash (there was >> >> nv setting). >> > >> > The fix up is invoked only for quad mode, I believe it is safe to add >> > fixup for micron flash As it is the one deviating from normal >> > according to you, rather than adding fixup for generic flash like >> > ATMEL flash(Now Renesas flash) >> >> Could you please try setting bit 4 in the Nonvolatile Configuration >> Register (Table 7) and see if the problem goes away? > > You mean, if it works, we need to disable reset for all the boards, > maybe at bootloader level?? Not necessarily. First, just to confirm that it is actually the reset circuit. You can also compare the part numbers of the flash. There is a flash with IO3/RESET# and IO3/HOLD# (and a flash with a dedicated reset pin). If that's the case, it looks like a hardware bug on your board. You left the reset pin floating. So you'd also not be able to boot from the NOR flash, right? > OK, I will check that. Currently I have read that register and it is > showing a value > Of 0xffbb. I need to do write operation. Before that how do we recover > flash, if > something goes wrong during writing for NV register? You should always be able to write that register from the bootloader. Maybe also through raw commands (like sspi in uboot). >> Also could you have a look at the schematics, does the IO3/RESET# have >> a >> pull-up? If not, who is in control of driving the correct value here? >> If >> it has a pull-up, I'm puzzled why you need any other setting than HiZ. > > Unfortunately, there is no pullup on IO3 line and also there is no SoC > pullup. See above. -michael >> The correct fix would be to the information about the missing IO state >> in >> the "struct spi_mem_op". That is, what should be the default values of >> all >> the IO lines which are unused. For example if we have a 1s1s4s >> transaction, what should be the state of IO0, >> IO2 and IO3 during the command and address phase. If we have a 1s2s2s, >> what should be the state of IO0 during the command phase etc. >> >> That can then be used within your driver to set the corresponding IOFV >> values (for each spi-mem op). >> >> But I'm not sure if other SPI controllers will support that, though. > > Currently driving SoC IOFV register, it fixes the issue and it is just > one time > operation during post sfdp. I take this as a SoC feature which other > controllers > don't have. > > Cheers, > Biju ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/
WARNING: multiple messages have this Message-ID (diff)
From: Michael Walle <michael@walle.cc> To: Biju Das <biju.das.jz@bp.renesas.com> Cc: Mark Brown <broonie@kernel.org>, Miquel Raynal <miquel.raynal@bootlin.com>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, linux-spi@vger.kernel.org, linux-mtd@lists.infradead.org, Geert Uytterhoeven <geert+renesas@glider.be>, Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@bp.renesas.com>, "biju.das.au" <biju.das.au@gmail.com>, linux-renesas-soc@vger.kernel.org Subject: Re: [PATCH RFC 0/4] Add set_iofv() callback Date: Fri, 10 Nov 2023 11:11:00 +0100 [thread overview] Message-ID: <dcfa2cab21fc85bb9b2b0c1ceb754a1a@walle.cc> (raw) In-Reply-To: <TYCPR01MB112699263B2EC0EC229746D3786AFA@TYCPR01MB11269.jpnprd01.prod.outlook.com> Hi Biju, >> >> Thus I was saying, that we probably wont support that and the easiest >> >> fix should be to disable this behavior for the atmel flash (there was >> >> nv setting). >> > >> > The fix up is invoked only for quad mode, I believe it is safe to add >> > fixup for micron flash As it is the one deviating from normal >> > according to you, rather than adding fixup for generic flash like >> > ATMEL flash(Now Renesas flash) >> >> Could you please try setting bit 4 in the Nonvolatile Configuration >> Register (Table 7) and see if the problem goes away? > > You mean, if it works, we need to disable reset for all the boards, > maybe at bootloader level?? Not necessarily. First, just to confirm that it is actually the reset circuit. You can also compare the part numbers of the flash. There is a flash with IO3/RESET# and IO3/HOLD# (and a flash with a dedicated reset pin). If that's the case, it looks like a hardware bug on your board. You left the reset pin floating. So you'd also not be able to boot from the NOR flash, right? > OK, I will check that. Currently I have read that register and it is > showing a value > Of 0xffbb. I need to do write operation. Before that how do we recover > flash, if > something goes wrong during writing for NV register? You should always be able to write that register from the bootloader. Maybe also through raw commands (like sspi in uboot). >> Also could you have a look at the schematics, does the IO3/RESET# have >> a >> pull-up? If not, who is in control of driving the correct value here? >> If >> it has a pull-up, I'm puzzled why you need any other setting than HiZ. > > Unfortunately, there is no pullup on IO3 line and also there is no SoC > pullup. See above. -michael >> The correct fix would be to the information about the missing IO state >> in >> the "struct spi_mem_op". That is, what should be the default values of >> all >> the IO lines which are unused. For example if we have a 1s1s4s >> transaction, what should be the state of IO0, >> IO2 and IO3 during the command and address phase. If we have a 1s2s2s, >> what should be the state of IO0 during the command phase etc. >> >> That can then be used within your driver to set the corresponding IOFV >> values (for each spi-mem op). >> >> But I'm not sure if other SPI controllers will support that, though. > > Currently driving SoC IOFV register, it fixes the issue and it is just > one time > operation during post sfdp. I take this as a SoC feature which other > controllers > don't have. > > Cheers, > Biju
next prev parent reply other threads:[~2023-11-10 10:11 UTC|newest] Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-11-08 17:11 [PATCH RFC 0/4] Add set_iofv() callback Biju Das 2023-11-08 17:11 ` Biju Das 2023-11-08 17:11 ` [PATCH RFC 1/4] spi: spi-mem: " Biju Das 2023-11-08 17:11 ` Biju Das 2023-11-09 7:56 ` Geert Uytterhoeven 2023-11-09 7:56 ` Geert Uytterhoeven 2023-11-09 8:28 ` Biju Das 2023-11-08 17:11 ` [PATCH RFC 2/4] mtd: spi-nor: Add post_sfdp() callback Biju Das 2023-11-08 17:11 ` Biju Das 2023-11-08 17:11 ` [PATCH RFC 3/4] memory: renesas-rpc-if: Add support for overriding IO fixed values Biju Das 2023-11-21 9:08 ` Krzysztof Kozlowski 2023-11-08 17:11 ` [PATCH RFC 4/4] spi: rpc-if: Add set_iofv() callback Biju Das 2023-11-09 9:01 ` [PATCH RFC 0/4] " Michael Walle 2023-11-09 9:01 ` Michael Walle 2023-11-09 10:04 ` Biju Das 2023-11-09 10:48 ` Michael Walle 2023-11-09 10:48 ` Michael Walle 2023-11-09 11:48 ` Biju Das 2023-11-09 12:40 ` Michael Walle 2023-11-09 12:40 ` Michael Walle 2023-11-09 18:02 ` Biju Das 2023-11-10 10:11 ` Michael Walle [this message] 2023-11-10 10:11 ` Michael Walle 2023-11-10 11:35 ` Biju Das 2023-11-11 12:26 ` Biju Das 2023-11-11 13:08 ` Biju Das 2023-11-13 14:04 ` Michael Walle 2023-11-13 14:04 ` Michael Walle 2023-11-13 14:27 ` Biju Das 2023-11-13 14:48 ` Michael Walle 2023-11-13 14:48 ` Michael Walle 2023-11-13 14:59 ` Biju Das 2023-11-13 15:10 ` Michael Walle 2023-11-13 15:10 ` Michael Walle 2023-11-13 15:55 ` Biju Das 2023-11-14 10:05 ` Michael Walle 2023-11-14 10:05 ` Michael Walle 2023-11-12 20:24 ` Biju Das 2023-11-13 14:37 ` Michael Walle 2023-11-13 14:37 ` Michael Walle 2023-11-13 14:47 ` Michael Walle 2023-11-13 14:47 ` Michael Walle
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=dcfa2cab21fc85bb9b2b0c1ceb754a1a@walle.cc \ --to=michael@walle.cc \ --cc=biju.das.au@gmail.com \ --cc=biju.das.jz@bp.renesas.com \ --cc=broonie@kernel.org \ --cc=geert+renesas@glider.be \ --cc=krzysztof.kozlowski@linaro.org \ --cc=linux-mtd@lists.infradead.org \ --cc=linux-renesas-soc@vger.kernel.org \ --cc=linux-spi@vger.kernel.org \ --cc=miquel.raynal@bootlin.com \ --cc=prabhakar.mahadev-lad.rj@bp.renesas.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.