Add QSPI[01] support to the RZ/G1C SoC specific device tree.
Signed-off-by: Fabrizio Castro
---
arch/arm/boot/dts/r8a77470.dtsi | 34 ++
1 file changed, 34 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470.dtsi b/arch/arm/boot/dts/r8a77470.dtsi
index
Add r8a77470 to the list of examples with soctypes.
No driver change is needed as "renesas,qspi" will activate
the right code within the corresponding driver.
Signed-off-by: Fabrizio Castro
---
As per Mark Brown's comment on patch "dt-bindings: spi: rspi: Add
r8a7744 to the compatible list",
The is25lp016d is found on the iwg23s from iWave, therefore
add driver support for it so that we can upstream board support.
Signed-off-by: Fabrizio Castro
---
drivers/mtd/spi-nor/spi-nor.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi-nor/spi-nor.c
This commit adds QSPI flash support to the iwg23s board specific
device tree.
Signed-off-by: Fabrizio Castro
---
arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts | 26 ++
1 file changed, 26 insertions(+)
diff --git a/arch/arm/boot/dts/r8a77470-iwg23s-sbc.dts
Dear All,
this series includes all that is necessary to add QSPI flash
support to the iwg23s board powered by the RZ/G1C SoC (a.k.a.
r8a77470).
Thanks,
Fab
Fabrizio Castro (4):
spi: rspi: Add r8a77470 to the compatible list
mtd: spi-nor: Add support for is25lp016d
ARM: dts: r8a77470: Add
On Thu, Nov 01, 2018 at 12:13:38AM +0100, Niklas Söderlund wrote:
> From: Niklas Söderlund
>
> Latest datasheet makes it clear that not all ES revisions of the H3 and
> M3-W have the 4-tap HS400 mode quirk, currently the quirk is set
> unconditionally for these two SoCs. Prepare to handle the
> This is the result of the SDHI hackathon for a possible solution to the
> clock issue on early ES versions. It is based on the Gen2 solution where
> a row of the possible clock settings are ignored on the effected SoC+ES
> versions. The first row is not effected when reading settings left by
On Wed, Oct 31, 2018 at 11:59:44PM +0100, Niklas Söderlund wrote:
> From: Niklas Söderlund
>
> The driver sets an incorrect clock and depends on the clock driver
> knowledge of this incorrect setting to still set a 200Mhz SDn clock.
> Instead of spreading the workaround between the two drivers
On Thu, Nov 01, 2018 at 12:00:43AM +0100, Niklas Söderlund wrote:
> From: Masaharu Hayakawa
>
> The manual does not contain information that a wait is needed in the
> tuning process, this might be a leftover from early development.
> Removing the wait don't have any effect on operation so delete
> Patch 1/3 adds support to select quirks based on SoC + ES revision using
> soc_device_match() and converts the only existing quirk. Patch 2/3
> Removes the old method to select quirk based on compatibility string.
> While Patch 3/3 adds a new quirk from the BSP which blacklists some
>
All patches tested on M3N, H2, and E2.
Tested-by: Wolfram Sang
signature.asc
Description: PGP signature
> This patch have quiet a few dependencies I'm afraid, let me know if you
> wish to be notified once they all upstream. I don't think it's a good
> idea to pick this up before all dependencies are resolved.
Yes, we should do that. Ping Simon once all dependencies are in next. It
is still fine
On Thu, Nov 01, 2018 at 12:05:54AM +0100, Niklas Söderlund wrote:
> From: Niklas Söderlund
>
> The initial value of the interrupt mask register may be different from
> the H/W manual at the startup of the kernel by setting from the
> bootloader. Since the error interrupts may be unmasked, the
On Thu, Nov 01, 2018 at 12:05:53AM +0100, Niklas Söderlund wrote:
> From: Niklas Söderlund
>
> SD / MMC did not operate properly when suspend transition failed.
> Because the SCC was not reset at resume, issue of the command failed.
> Call the host specific reset function and reset the hardware
On Thu, Nov 01, 2018 at 12:25:17AM +0100, Niklas Söderlund wrote:
> From: Niklas Söderlund
>
> Document the known use cases of the different clock settings. This is
> useful as different SoC and ES versions uses different settings to do
> the same thing as there are more then one combination to
On Thu, Nov 01, 2018 at 12:25:18AM +0100, Niklas Söderlund wrote:
> From: Niklas Söderlund
>
> On H3 (ES1.0,ES2.0) and M3-W (ES1.0,ES1.1) the clock setting for HS400
> needs a quirk to function properly. The reason for the quirk is that
> there are two settings which produces same divider vale
On Thu, Nov 01, 2018 at 12:00:43AM +0100, Niklas Söderlund wrote:
> From: Masaharu Hayakawa
>
> The manual does not contain information that a wait is needed in the
> tuning process, this might be a leftover from early development.
> Removing the wait don't have any effect on operation so delete
On Thu, Nov 01, 2018 at 12:05:52AM +0100, Niklas Söderlund wrote:
> From: Niklas Söderlund
>
> On runtime power management resume, the host clock needs to be
> enabled before calling tmio_mmc_reset. If the mmc device has a power
> domain entry, the host clock is enabled via genpd_runtime_resume,
On Thu, Nov 01, 2018 at 12:13:39AM +0100, Niklas Söderlund wrote:
> From: Niklas Söderlund
>
> It was though all ES revisions of H3 and M3-W SoCs required the
> TMIO_MMC_HAVE_4TAP_HS400 flag. Recent datasheet updates tells us this is
> not true, only early ES revisions of the SoC do.
>
> Since
On Thu, Nov 01, 2018 at 12:13:40AM +0100, Niklas Söderlund wrote:
> From: Niklas Söderlund
>
> The Renesas BSP confirms that H3 ES1.x and M3-W ES1.x do not properly
> support HS400. Add a quirk to indicate this and disable HS400 in the MMC
> capabilities if the quirk is set.
>
> Signed-off-by:
And this concludes my first patch review session while being on a ship
:) Thanks for this SDHI hackathon guys, and looking forward to seeing
you again!
signature.asc
Description: PGP signature
All patches tested on M3N:
Tested-by: Wolfram Sang
signature.asc
Description: PGP signature
So, we agreed on this series during our Renesas SDHI hackathon.
Comments / testing from Yamada-san would be very welcome because we
really don't want to cause regressions on his hardware.
signature.asc
Description: PGP signature
On Wed, Oct 31, 2018 at 11:59:44PM +0100, Niklas Söderlund wrote:
> From: Niklas Söderlund
>
> The driver sets an incorrect clock and depends on the clock driver
> knowledge of this incorrect setting to still set a 200Mhz SDn clock.
> Instead of spreading the workaround between the two drivers
24 matches
Mail list logo
