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 in order to
add reset of SCC. This change also fixes tuning on some stubborn
From: Niklas Söderlund
Hi,
While looking at the Renesas BSP kernel I found patches which improves
the state of the hardware at probe and after runtime resume.
Patch 1/3 make sure the module clock is enabled after resuming before
register are accessed. Patch 2/3 is the real change in this
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,
running before tmio_mmc_host_runtime_resume. If the mmc device has no
power
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 driver sets
initial value.
The initial value is only known for R-Car Gen2 and
From: Niklas Söderlund
Successfully tested on H3 ES2.0 and M3-N ES1.0.
Transfer rates where >160MB/s for H3 and >200MB/s for M3-N.
Signed-off-by: Niklas Söderlund
---
arch/arm64/boot/dts/renesas/salvator-common.dtsi | 1 +
arch/arm64/boot/dts/renesas/ulcb.dtsi| 1 +
2 files
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 for the SDn
clock. On the effected boards the one currently selected results
From: Niklas Söderlund
Hi Geert,
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
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 achieve the
same SDn clock speed.
Signed-off-by: Niklas Söderlund
---
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: Niklas Söderlund
---
drivers/mmc/host/renesas_sdhi_core.c | 20
From: Niklas Söderlund
Hi,
Recent datasheet updates have made it clear that some quirks are not SoC
specific but SoC + ES version specific. Currently the quirks are
selected using compatibility values but whit this new information that
is not enough.
Patch 1/3 adds support to select quirks
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 quirk based on
SoC revision instead of compatibility value by using
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 quirk matching based on ES revisions is now used to handle the
flag it's
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 the wait
to shorten the initialization time.
Signed-off-by: Masaharu
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 the clock
driver should be made aware of the ES versions where the special
On 10/31/2018 5:30 PM, Simon Horman wrote:
The "official" Condor boards have always been wired to mount NFS via
GEther, not EtherAVB -- the boards resoldered for EtherAVB were local
to Cogent Embedded, so we've been having an unpleasant situation where
a "normal" Condor board still can't mount
On Wed, Oct 31, 2018 at 02:18:40PM +0100, jacopo mondi wrote:
> Hi Simon,
>
> On Wed, Oct 31, 2018 at 01:48:13PM +0100, Simon Horman wrote:
> > On Tue, Oct 30, 2018 at 02:57:59PM +0200, Laurent Pinchart wrote:
> > > Hi Jacopo,
> > >
> > > On Tuesday, 30 October 2018 12:14:31 EET jacopo mondi
On Mon, Oct 15, 2018 at 11:59:24AM +0200, Simon Horman wrote:
> From: Takeshi Kihara
>
> This patch enables Audio for the Ebisu board on R8A77990 SoC.
>
> Signed-off-by: Takeshi Kihara
> [simon: rebased]
> Signed-off-by: Simon Horman
Applied for v4.21.
On Mon, Oct 15, 2018 at 11:59:23AM +0200, Simon Horman wrote:
> From: Yoshihiro Kaneko
>
> This patch adds Audio-DMAC0 device node and Sound device node
> for the R8A77990 SoC.
>
> Based on work by Takeshi Kihara and Hai Nguyen Pham.
>
> Signed-off-by: Yoshihiro Kaneko
> [simon: dropped
On Mon, Oct 15, 2018 at 11:59:22AM +0200, Simon Horman wrote:
> Enable the scu-simple-card which is used by
> the R-Car E3 (r8a77990) based Ebisu board.
>
> Signed-off-by: Simon Horman
> ---
> N.B: This is targeted at the devel branch of the renesas tree
> but not upstream where
On Mon, Oct 15, 2018 at 11:59:21AM +0200, Simon Horman wrote:
> Enable the scu-simple-card which is used by
> the R-Car E3 (r8a77990) based Ebisu board.
>
> Signed-off-by: Simon Horman
Applied for v4.21.
On Thu, Oct 18, 2018 at 07:48:53PM +0300, Sergei Shtylyov wrote:
> The "official" Condor boards have always been wired to mount NFS via
> GEther, not EtherAVB -- the boards resoldered for EtherAVB were local
> to Cogent Embedded, so we've been having an unpleasant situation where
> a "normal"
On Wed, Oct 31, 2018 at 01:55:16PM +0100, Simon Horman wrote:
> On Fri, Oct 26, 2018 at 09:48:19AM +, Fabrizio Castro wrote:
> > > Subject: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a77470 CMT
> > > support
> > >
> > > Document SoC specific compatible strings for r8a77470. No
Hi Simon,
On Wed, Oct 31, 2018 at 01:48:13PM +0100, Simon Horman wrote:
> On Tue, Oct 30, 2018 at 02:57:59PM +0200, Laurent Pinchart wrote:
> > Hi Jacopo,
> >
> > On Tuesday, 30 October 2018 12:14:31 EET jacopo mondi wrote:
> > > On Mon, Sep 10, 2018 at 05:12:30PM +0300, Laurent Pinchart wrote:
>
> But can we discuss this in the context of describing the hardware?
The SDHI node needs two kinds of pinmux settings, one for normal speeds
and one for highspeeds. They might differ in supplied voltage, i.e. 3v3
and 1v8. This eMMC always works with 1v8, so both settings needed by the
SDHI node
On 10/31/2018 01:46 PM, Simon Horman wrote:
> On Mon, Oct 29, 2018 at 08:57:21AM +, Wolfram Sang wrote:
>>
<_pins>;". So, basically the same phandles for both pinctrls. We
can re-add the second one when we need it.
>>>
>>> I wonder if removing the sdhi2_pins_uhs is what we want to
On Fri, Oct 26, 2018 at 09:48:19AM +, Fabrizio Castro wrote:
> > Subject: [PATCH] dt-bindings: timer: renesas, cmt: Document r8a77470 CMT
> > support
> >
> > Document SoC specific compatible strings for r8a77470. No driver change
> > is needed as the fallback strings will activate the right
On Tue, Oct 30, 2018 at 04:48:30PM +, Biju Das wrote:
> Hi Simon,
>
> Thanks for the feedback.
>
> > Subject: Re: [PATCH 2/2] ARM: dts: iwg23s-sbc: Enable cmt0
> >
> > On Fri, Oct 26, 2018 at 09:48:29AM +0100, Biju Das wrote:
> > > This patch enables cmt0 support on the iWave iwg23s sbc.
> >
On Tue, Oct 30, 2018 at 02:57:59PM +0200, Laurent Pinchart wrote:
> Hi Jacopo,
>
> On Tuesday, 30 October 2018 12:14:31 EET jacopo mondi wrote:
> > On Mon, Sep 10, 2018 at 05:12:30PM +0300, Laurent Pinchart wrote:
> > > On Wednesday, 5 September 2018 18:29:43 EEST Jacopo Mondi wrote:
> > >> From:
On Mon, Oct 29, 2018 at 08:57:21AM +, Wolfram Sang wrote:
>
> > > <_pins>;". So, basically the same phandles for both pinctrls. We
> > > can re-add the second one when we need it.
> >
> > I wonder if removing the sdhi2_pins_uhs is what we want to do, given
> > that we might need to adjust
29 matches
Mail list logo
