Re: [PATCH v3 0/3] mmc: renesas_sdhi: extend quirk selection to handle ES revisions

On Wed, 28 Nov 2018 at 17:19, Niklas Söderlund wrote: > > 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. >

Re: [PATCH v2] mmc: document 'Reliable Write' bit in uapi header

On Mon, 3 Dec 2018 at 20:56, Wolfram Sang wrote: > > If we use it this way, people should know about it. Also, replace > true/false with nonzero/zero because the flag is not strictly a bool > anymore. > > Signed-off-by: Wolfram Sang > Reviewed-by: Geert Uytterhoeven Applied for next, thanks!

Re: [PATCH v4 0/3] mmc: tmio: fix reset operation

On Mon, 26 Nov 2018 at 18:03, Niklas Söderlund wrote: > > 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

Re: [PATCH 1/2] mmc: core: use mrq->sbc when sending CMD23 for RPMB

On Mon, 26 Nov 2018 at 14:38, Wolfram Sang wrote: > > When sending out CMD23 in the blk preparation, the comment there > rightfully says: > > * However, it is not sufficient to just send CMD23, > * and avoid the final CMD12, as on an error condition > * CMD12 (stop)

Re: [PATCH 2/2] mmc: core: remove obsolete mmc_set_blockcount() function

On Mon, 26 Nov 2018 at 14:38, Wolfram Sang wrote: > > The only user was converted to fill a sbc command which is the proper > way to do it because of AutoCMD23 feature of some hosts. > > Signed-off-by: Wolfram Sang > Tested-by: Clément Péron Applied for next, thanks! Kind regards Uffe > ---

Re: [RFC PATCH 0/3] mmc: refactor RPMB block count handling

+ Avri, Clément (due to recent related discussions) On 21 November 2018 at 00:08, Wolfram Sang wrote: > On Renesas R-Car SDHI hardware, we sometimes had timeouts accessing the RPMB. > This is because AutoCMD23/12 features needs a properly filled sbc to work > correctly. But RPMB sends an

Re: [PATCH v3 0/3] mmc: tmio: fix reset operation

On 19 November 2018 at 13:14, Wolfram Sang wrote: > >> I noticed there were a minor comment from Yamada-san, however I >> decided to pick this as is and leave further improvements to be made >> on top. > > Can I vote for waiting until Niklas comes back from Plumbers and have a > proper V2 applied

Re: [PATCH v3 0/3] mmc: tmio: fix reset operation

On 1 November 2018 at 00:05, Niklas Söderlund wrote: > 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

Re: [PATCH] mmc: renesas_sdhi: Whitelist R8A77990 SDHI

t; Cc: Yoshihiro Shimoda > Cc: Ulf Hansson > Cc: linux-renesas-soc@vger.kernel.org Applied for next, thanks! Kind regards Uffe > --- > drivers/mmc/host/renesas_sdhi_internal_dmac.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/mmc/host/renes

Re: [PATCH v2 0/3] mmc: renesas_sdhi: extend quirk selection to handle ES revisions

On 1 November 2018 at 00:13, Niklas Söderlund wrote: > 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

Re: [PATCH] mmc: renesas_sdhi: remove workaround for HS400 clock

On 31 October 2018 at 23:59, 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 the clock >

Re: [PATCH] mmc: tmio: delete wait in tuning process

On 1 November 2018 at 00:00, 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 the wait >

Re: [PATCH v5 3/3] dt-bindings: mmc: tmio_mmc: Document Renesas R7S9210

On 25 October 2018 at 00:23, Chris Brandt wrote: > Document support for the RZ/A2 (R7S9210) SoC. > > Signed-off-by: Chris Brandt > Reviewed-by: Geert Uytterhoeven > Reviewed-by: Rob Herring > Reviewed-by: Simon Horman Applied for next, thanks! Kind regards Uffe > --- > v3: > * Added

Re: [PATCH v5 2/3] mmc: renesas_sdhi_internal_dmac: Add R7S9210 support

On 25 October 2018 at 00:23, Chris Brandt wrote: > The SDHI/MMC controller in the RZ/A2 is almost the same as R-Car gen3, but > with some minor differences. > > Signed-off-by: Chris Brandt Applied for next, thanks! Kind regards Uffe > --- > v5: > * Rebased against -next to fix conficts with

Re: [PATCH v4 0/3] mmc: tmio_mmc: Add support for RZ/A2

On 24 October 2018 at 00:28, Chris Brandt wrote: > On Tuesday, October 23, 2018, Ulf Hansson wrote: >> On 12 October 2018 at 14:29, Chris Brandt >> wrote: >> > Basically the same HW block that was used in R-Car Gen 3 is used in >> > RZ/A2 (wit

Re: [PATCH v4 0/3] mmc: tmio_mmc: Add support for RZ/A2

On 12 October 2018 at 14:29, Chris Brandt wrote: > Basically the same HW block that was used in R-Car Gen 3 is used in > RZ/A2 (with only a couple small differences). > > Not sure if you're going to like the Kconfig change or not. > > Chris Brandt (3): > clk: renesas: r7s9210: Add SDHI clocks >

Re: [PATCH v3 1/6] dt-bindings: mmc: renesas_sdhi: Add r8a77470 support

On 8 October 2018 at 10:51, Fabrizio Castro wrote: > The RZ/G1C (a.k.a. R8A77470) comes with three SDHI interfaces, > SDHI0 and SDHI2 are compatible with R-Car Gen2 SDHIs, and > SDHI1 is compatible with R-Car Gen3 SDHIs, as it comes with an > internal DMAC, therefore SDHI1 is fully compatible

Re: [PATCH v3 0/2] mmc: tmio: remove confusing TMIO_MMC_HAVE_HIGH_REG flag

On 10 October 2018 at 05:51, Masahiro Yamada wrote: > CTL_SDIO_REGS is a register specific to tmio_mmc.c > > Currently, we handle it in tmio_mmc_core.c, hence need > TMIO_MMC_HAVE_HIGH_REG flag to prevent the other platforms > from accessing to it. > > We can just move CTL_SDIO_REGS to tmio_mmc.c

Re: [PATCH v3 3/6] mmc: renesas_sdhi: Add r8a77470 SDHI1 support

On 8 October 2018 at 10:51, Fabrizio Castro wrote: > The RZ/G1C (a.k.a. R8A77470) comes with three SDHI interfaces, > SDHI0 and SDHI2 are compatible with the R-Car Gen2 SDHIs, SDHI1 > is compatible with R-Car Gen3 SDHIs and it can be used as > eMMC as well. This patch adds driver compatibility,

Re: [PATCH] mmc: tmio: simplify the DMA mode test

On 12 October 2018 at 17:03, Masahiro Yamada wrote: > host->chan_{rx,tx} represents the DMA capability of the platform. > Even if DMA is supported, there are cases where we want to use PIO, > for example, data length is short enough as commit 5f52c3552946 > ("mmc: tmio: use PIO for short

Re: [PATCH] dt-bindings: mmc: sh_mmcif: Document r8a7744 DT bindings

On 25 September 2018 at 19:27, Biju Das wrote: > Add support for r8a7744 SoC. Renesas RZ/G1N (R8A7744) MMCIF is identical > to the R-Car Gen2 family. > > Signed-off-by: Biju Das > Reviewed-by: Chris Paterson Applied for next, thanks! Kind regards Uffe > --- >

Re: [PATCH] dt-bindings: mmc: renesas_sdhi: Add r8a7744 support

On 25 September 2018 at 19:23, Biju Das wrote: > Add support for r8a7744 SoC. Renesas RZ/G1N (R8A7744) SDHI is identical > to the R-Car Gen2 family. > > Signed-off-by: Biju Das > Reviewed-by: Chris Paterson Applied for next, thanks! Kind regards Uffe > --- >

Re: [PATCH v3] mmc: renesas_sdhi_internal_dmac: set scatter/gather max segment size

On 13 September 2018 at 16:47, Wolfram Sang wrote: > From: Niklas Söderlund > > Fix warning when running with CONFIG_DMA_API_DEBUG_SG=y by allocating a > device_dma_parameters structure and filling in the max segment size. The > size used is the result of a discussion with Renesas hardware

Re: [RFC PATCH] mmc: sdhi: sys_dmac: check for all Gen3 types when whitelisting

On 11 September 2018 at 15:06, Wolfram Sang wrote: > From: Wolfram Sang > > Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support") > Signed-off-by: Wolfram Sang Applied for fixes, thanks! Kind regards Uffe > --- > > So, adding HS400 support broke the detection here. I suggest

Re: [RFC PATCH] mmc: sdhi: sys_dmac: check for all Gen3 types when whitelisting

On 11 September 2018 at 15:06, Wolfram Sang wrote: > From: Wolfram Sang > > Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support") > Signed-off-by: Wolfram Sang > --- > > So, adding HS400 support broke the detection here. I suggest we discuss > internally, if this kind of white

Re: [PATCH] mmc: tmio: remove now unused variable

On 30 August 2018 at 14:16, Wolfram Sang wrote: > This variable is unused now after some refactoring. > > Signed-off-by: Wolfram Sang Applied for next, thanks! Kind regards Uffe > --- > drivers/mmc/host/tmio_mmc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git

Re: [PATCH v3 5/6] mmc: renesas_sdhi: merge clk_{start,stop} functions to set_clock

On 23 August 2018 at 06:44, Masahiro Yamada wrote: > renesas_sdhi_clk_start() and renesas_sdhi_clk_stop() are now only > called from renesas_sdhi_set_clock(). Merge them. > > Signed-off-by: Masahiro Yamada Applied for next, thanks! Kind regards Uffe > --- > > Changes in v3: None > Changes in

Re: [PATCH] mmc: tmio: more concise clk calculation

On 30 August 2018 at 14:14, Wolfram Sang wrote: > Concise, but still readable. > > Signed-off-by: Wolfram Sang Applied for next, thanks! Kind regards Uffe > --- > drivers/mmc/host/tmio_mmc.c | 11 +++ > 1 file changed, 3 insertions(+), 8 deletions(-) > > diff --git

Re: [PATCH v4 0/3] mmc: {tmio,renesas_sdhi}: retune if SCC error detected

On 30 August 2018 at 01:32, Niklas Söderlund wrote: > Hi, > > These patches triggers a retune if a SCC error is detected. They where > ported from the renesas BSP. Masaharu-san did all the real work I just > ported them to upstream and did small fixups. > > These patches where broken out of my

Re: [PATCH v3 1/2] mmc: renesas_sdhi: skip SCC error check when retuning

On 27 August 2018 at 17:13, Niklas Söderlund wrote: > From: Masaharu Hayakawa > > Checking for SCC error during retuning is unnecessary. > > Signed-off-by: Masaharu Hayakawa > [Niklas: fix small style issue] > Signed-off-by: Niklas Söderlund > > --- > > * Changes since v2 > - Add comment to

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: fix #define RST_RESERVED_BITS

On 22 August 2018 at 22:03, Sergei Shtylyov wrote: > On 08/22/2018 10:45 PM, Wolfram Sang wrote: > > The DM_CM_RST register actually has bits 0-31 defaulting to 1s and bits > 32-63 defaulting to 0s -- fix off-by-one in #define RST_RESERVED_BITS. > > Signed-off-by: Sergei Shtylyov

Re: [PATCH v2] mmc: renesas_sdhi_internal_dmac: mask DMAC interrupts

On 22 August 2018 at 22:07, Sergei Shtylyov wrote: > On 08/22/2018 10:37 PM, Wolfram Sang wrote: > >>> I have encountered an interrupt storm during the eMMC chip probing (and >>> the chip finally didn't get detected). It turned out that U-Boot left >>> the SDHI DMA interrupts enabled while the

Re: [PATCH] dt-bindings: mmc: tmio_mmc: document Renesas R8A77970 bindings

On 21 August 2018 at 21:14, Sergei Shtylyov wrote: > Document the R-Car V3M (R8A77970) SoC in the R-Car SDHI bindings -- it's > the usual R-Car gen3 compatible controller with the internal DMA engine. > > Signed-off-by: Sergei Shtylyov Thanks, queued for v4.20! Kind regards Uffe > > --- >

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: add R8A77970 to whitelist

On 20 August 2018 at 21:44, Sergei Shtylyov wrote: > On 08/20/2018 07:42 PM, Wolfram Sang wrote: > >>> I've successfully tested eMMC on the V3H Starter Kit board. R8A77970 SoC >>> has a single SDHI core anyway, so can't be a subject to the known RX DMA >>> errata... >>> >>> Signed-off-by:

Re: [PATCH 0/2] Fix some typos in Renesas R-Car gen3 SDHI driver

On 17 August 2018 at 22:16, Sergei Shtylyov wrote: > Hello! > > Here's a set of 2 patches against the 'next' branch of Ulf Hannsson's > 'mmc.git' repo. > They fix some typos I noticed... > > [1/2] mmc: renesas_sdhi_internal_dmac: fix typo in DM_CM_DTRAN_MODE.BUS_WIDTH > field name > [2/2] mmc:

Re: [PATCH 0/2] Add SDHI support to r8a774a1

On 14 August 2018 at 14:34, Fabrizio Castro wrote: > Dear All, > > this series aims at documenting SDHI support for RZ/G2M (a.k.a. R8A774A1). > > Cheers, > Fab > > Fabrizio Castro (2): > mmc: renesas_sdhi_internal_dmac: Whitelist r8a774a1 > mmc: renesas_sdhi: Add r8a774a1 support > >

Re: [PATCH v2 0/7] mmc: tmio: refactor TMIO core a bit and add UniPhier SD/eMMC controller support

On 21 August 2018 at 04:57, Masahiro Yamada wrote: > Hi Wolfram, > > > 2018-08-21 4:07 GMT+09:00 Wolfram Sang : >> >> So, today I did test these patches successfully on a Gen3 board (M3-N) >> and reviewed half of the patches. I will continue tomorrow with >> reviewing and testing more boards. >>

Re: [PATCH v4 0/2] mmc: {tmio,renesas_sdhi}: fix tuning behavior

On 24 July 2018 at 16:51, Niklas Söderlund wrote: > Hi, > > Tuning failed on my R-Car H3 ES2.0 board using latest mmc/next while the > Renesas BSP kernel worked. After some digging I found patches in the BSP > which remedied this and whit these applied tuning now works for me. > > I have done

Re: [PATCH 1/2] mmc: tmio: rename files and CONFIG options to have the same prefix

ussion with Wolfram Sang, my suggestion was rejected > because it implied drastic function renaming, which is too invasive. > > Ulf Hansson was still happy with file renaming to clarify the > relationship between variants. So, the accepted solution was: > > - Make 'tmio_mmc'

Re: [PATCH] mmc: renesas_sdhi: Add r8a77990 support

On 21 July 2018 at 13:14, Wolfram Sang wrote: > This patch adds SDHI support for the R8A77990 SoC (R-Car E3). No driver > changes > needed for anything except HS400 which we will enable separately later. > > Signed-off-by: Wolfram Sang Thanks, applied for next! Kind regards Uffe > --- > >

Re: [PATCH v5 0/3] mmc: renesas_sdhi: add eMMC HS400 mode support

On 18 June 2018 at 14:57, Simon Horman wrote: > Hi, > > this patch-set provides SDHI driver support for eMMC HS400. > > Based on mmc-v4.18-rc1 > > Dependencies for applying these patches: > * none > > Dependencies to test eMMC HS400: > * [PATCH] clk: renesas: rcar-gen3: Fix SD divider setting > *

Re: [PATCH] soc: renesas: rcar-sysc: Make PM domain initialization more robust

ixes: 086b399965a7ee7e ("soc: renesas: r8a77990-sysc: Add workaround for > 3DG-{A,B}") > Signed-off-by: Geert Uytterhoeven Reviewed-by: Ulf Hansson Kind regards Uffe > --- > drivers/soc/renesas/rcar-sysc.c | 35 +-- > 1 file changed, 29

Re: [PATCH] mmc: renesas_sdhi: really fix WP logic regressions

On 4 June 2018 at 09:32, Wolfram Sang wrote: > On Mon, Jun 04, 2018 at 08:44:42AM +0200, Ulf Hansson wrote: >> On 1 June 2018 at 13:00, Wolfram Sang >> wrote: >> > This reverts commit e060d376cc61 ("mmc: renesas_sdhi: fix WP detection") >> > and a

Re: [PATCH] mmc: renesas_sdhi: really fix WP logic regressions

On 1 June 2018 at 13:00, Wolfram Sang wrote: > This reverts commit e060d376cc61 ("mmc: renesas_sdhi: fix WP detection") > and adds some code to really fix the regressions. > > It was missed so far that Renesas R-Car instantiations of SDHI chose to > disable internal WP and used the existence of

Re: [PATCH v4 2/4] mmc: core: more fine-grained hooks for HS400 tuning

On 18 April 2018 at 11:56, Simon Horman wrote: > This adds two new HS400 tuning operations: > * prepare_hs400_tuning_downgrade > * complete_hs400_tuning > > These supplement the existing HS400 operation: > * prepare_hs400_tuning > > This is motivated by a requirement

Re: [PATCH v4 0/4] mmc: renesas_sdhi: add eMMC HS400 mode support

On 13 May 2018 at 10:23, Simon Horman wrote: > Hi Ulf, > > On Wed, Apr 18, 2018 at 11:56:56AM +0200, Simon Horman wrote: >> Hi, >> >> this patch-set provides SDHI driver support for eMMC HS400. >> >> Based on mmc-v4.17-2 >> >> Dependencies for applying these patches: >> * none

Re: [PATCH v2] mmc: renesas_sdhi: Add r8a77965 support

On 9 May 2018 at 14:38, Yoshihiro Kaneko wrote: > From: Masaharu Hayakawa > > This patch adds r8a77965 support in SDHI. > > Signed-off-by: Masaharu Hayakawa > Signed-off-by: Yoshihiro Kaneko

Re: [PATCH] i2c: busses: remove superfluous ignoring of children for RPM

ers to > repeat that again. > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org> Kind regards Uffe > --- > > I tested it using a Renesas Salvator-X board (M3-W) which has an EEPROM > connected to a bu

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: add R8A77980 to whitelist

On 19 April 2018 at 22:07, Sergei Shtylyov wrote: > I've successfully tested eMMC on R8A77980/Condor. R8A77980 has a single > SDHI core anyway, so can't be a subject of the known RX DMA errata... > > Signed-off-by: Sergei Shtylyov

Re: [PATCH 28/61] mmc: host: simplify getting .drvdata

On 19 April 2018 at 16:05, Wolfram Sang wrote: > We should get drvdata from struct device directly. Going via > platform_device is an unneeded step back and forth. > > Signed-off-by: Wolfram Sang Thanks, applied for next! Kind

Re: [PATCH] mmc: renesas_sdhi_internal_dmac: add R8A77980 to whitelist

On 19 April 2018 at 22:09, Wolfram Sang wrote: > On Thu, Apr 19, 2018 at 11:07:44PM +0300, Sergei Shtylyov wrote: >> I've successfully tested eMMC on R8A77980/Condor. R8A77980 has a single >> SDHI core anyway, so can't be a subject of the known RX DMA errata... > > Lucky you

Re: [PATCH v3 0/5] mmc: renesas_sdhi_internal_dmac: DMA handling fixes

On 18 April 2018 at 20:20, Wolfram Sang wrote: > I have collected the patches floating around for renesas_sdhi_internal_dmac > and > grouped them to avoid dependency issues. > > Regarding stable: I think patch 1 is clearly for stable. Patch 3 maybe, but it >

Re: [PATCH] DT: mmc: tmio_mmc: document R8A77980 bindings

On 16 April 2018 at 20:30, Sergei Shtylyov wrote: > Document the R-Car V3H (R8A77980) SoC in the Renesas SDHI bindings. > > Signed-off-by: Sergei Shtylyov Thanks, applied for next! Kind regards Uffe > > --- > This patch

Re: [PATCH v3 0/2] mmc: renesas_sdhi: add eMMC HS400 mode support

On 27 March 2018 at 13:12, Simon Horman wrote: > On Tue, Feb 27, 2018 at 02:02:23PM +0100, Wolfram Sang wrote: >> >> > Perhaps someone need to explain in more detail what the HW controller >> > needs to manage tuning for HS400? I don't like that we may end up >> > getting it

Re: [RFC PATCH] mmc: renesas_sdhi_internal_dmac: fall back to PIO if scatterlist doesn't match

On 4 April 2018 at 19:00, Wolfram Sang wrote: > From: Wolfram Sang > > If we detect an incompatible scatterlist, we should fall back to PIO, > too. > > Signed-off-by: Wolfram Sang > --- > > I found this

Re: [RFC PATCH] mmc: renesas_sdhi_internal_dmac: limit DMA RX for old SoCs

On 4 April 2018 at 18:45, Wolfram Sang wrote: > From: Wolfram Sang > > Early revisions of certain SoCs cannot do multiple DMA RX streams in > parallel. To avoid data corruption, only allow one DMA RX channel and > fall back to PIO, if needed.

Re: [PATCH] mmc: tmio: Fix error handling when issuing CMD23

On 3 April 2018 at 23:57, Wolfram Sang wrote: > From: Masaharu Hayakawa > > If an error was detected when CMD23 was issued, command sequence should > be terminated with errors and CMD23 should be issued after retuning. > > Fixes: 8b22c3c18be5

Re: [PATCH] mmc: renesas_sdhi: replace EXT_ACC with HOST_MODE

On 20 March 2018 at 22:42, Wolfram Sang wrote: > From: Masaharu Hayakawa > > All our documentation says HOST_MODE, we don't really know where EXT_ACC > came from. Rename it to reduce the confusion. > > Signed-off-by: Masaharu

Re: [PATCH] mmc: renesas_sdhi: fix WP detection

On 5 March 2018 at 21:48, Wolfram Sang wrote: > Commit "mmc: renesas_sdhi: use MMC_CAP2_NO_WRITE_PROTECT instead of > TMIO own flag" activated MMC_CAP2_NO_WRITE_PROTECT for Renesas SDHI > which incorrectly disabled WP altogether instead of only disabling the >

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

On 5 March 2018 at 10:34, Masahiro Yamada wrote: > Hi Ulf, Wolfram, > > 2018-03-05 18:22 GMT+09:00 Wolfram Sang : >> >>> I have added Wolframs tags to the already applied patches and applied >>> that last two, 15 and 16. >> >> Thanks. Please note

Re: [PATCH] mmc: tmio: populate correct callback when using GPIO CD

On 4 March 2018 at 23:49, Wolfram Sang wrote: > The patch "mmc: tmio: support IP-builtin card detection logic" had a > typo and populated RO instead of CD. Fix it. > > Signed-off-by: Wolfram Sang > --- > > Ulf: I didn't add a

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

On 4 March 2018 at 23:42, Wolfram Sang wrote: > On Thu, Jan 18, 2018 at 01:28:00AM +0900, Masahiro Yamada wrote: >> >> In the previous batch (https://lkml.org/lkml/2017/11/24/428) >> I sent 22 patches for TMIO MMC. >> >> 14 patches were applied, the rest is under discussion.

Re: [PATCH v3 0/2] mmc: renesas_sdhi: add eMMC HS400 mode support

On 27 February 2018 at 10:07, Wolfram Sang wrote: > >> Is this ready to be queued up for next? It looks good to me. > > Ulf, out of your head, do you have an idea why preparing HS400 during > set_ios works but populating host->ops->prepare_hs400_tuning() does not > (according

Re: [PATCH v3 0/2] mmc: renesas_sdhi: add eMMC HS400 mode support

On 13 February 2018 at 13:33, Simon Horman wrote: > Hi, > > this patch-set provides SDHI driver support for eMMC HS400. > > Based on mmc/next > > Dependencies for applying these patches: none > > Dependencies to test eMMC HS400: > * [PATCH] clk: renesas: rcar-gen3: Fix

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

On 14 February 2018 at 11:23, Wolfram Sang wrote: > >> You need to check again. :-) > > Seems like it. Sorry for the noise. > >> I am eager to apply those patches you already have reviewed (to >> patch14), as those mostly seemed rather trivial and should be nice >> cleanups.

Re: [PATCH] mmc: sh_mmcif: remove some cruft

On 5 February 2018 at 14:28, Wolfram Sang wrote: > The TODO section from 2010 is obsolete. We have DMA and PM meanwhile and > we always want to handle errors better, if possible. Also DRIVER_VERSION > is not used anymore these days. > > Signed-off-by: Wolfram

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

On 14 February 2018 at 10:43, Masahiro Yamada <yamada.masah...@socionext.com> wrote: > Hi Ulf, > > > 2018-02-14 18:36 GMT+09:00 Ulf Hansson <ulf.hans...@linaro.org>: >> On 7 February 2018 at 20:11, Wolfram Sang <w...@the-dreams.de> wrote: >>> >

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

On 7 February 2018 at 20:11, Wolfram Sang wrote: > >> I picked patch5 and patch6, as those seemed trivial. Unless there is a >> rc9, let's aim for 4.17 for the rest. > > I can't find the branch where you picked these patches? I wanted to use > it to apply the rest of the

Re: [PATCH v3 0/3] renesas: irqchip: Use wakeup_path i.s.o. explicit clock handling

> drivers/irqchip/irq-renesas-irqc.c| 30 --- > 3 files changed, 48 insertions(+), 60 deletions(-) > For the series: Reviewed-by: Ulf Hansson <ulf.hans...@linaro.org> Kind regards Uffe

Re: [PATCH] mmc: MMC_SDHI_{SYS,INTERNAL}_DMAC should depend on HAS_DMA

On 30 January 2018 at 14:24, Geert Uytterhoeven wrote: > If NO_DMA=y: > > ERROR: "bad_dma_ops" [drivers/mmc/host/renesas_sdhi_sys_dmac.ko] > undefined! > ERROR: "bad_dma_ops" [drivers/mmc/host/renesas_sdhi_internal_dmac.ko] > undefined! > > Add dependencies on

Re: [PATCH v3 00/16] mmc: tmio: another batch of TMIO MMC fixes and cleanups

On 17 January 2018 at 17:28, Masahiro Yamada wrote: > > In the previous batch (https://lkml.org/lkml/2017/11/24/428) > I sent 22 patches for TMIO MMC. > > 14 patches were applied, the rest is under discussion. > > This series consists of 16 patches. > > Patch 1-4:

Re: [PATCH] dmaengine: rcar-dmac: Make DMAC reinit during system resume explicit

l hang silently > after a system resume on R-Car Gen3. > > Make this explicit by using pm_runtime_force_{suspend,resume}() as the > system sleep callbacks instead. Use SET_LATE_SYSTEM_SLEEP_PM_OPS() as > DMA engines must be initialized before all DMA slave devices. > >

Re: [PATCH 0/2] PM / core: genpd fix and pm_runtime_force_suspend|resume() rework

On 15 January 2018 at 14:22, Geert Uytterhoeven wrote: > Hi Rafael, > > On Mon, Jan 15, 2018 at 9:16 AM, Geert Uytterhoeven > wrote: >> On Mon, Jan 15, 2018 at 1:04 AM, Rafael J. Wysocki wrote: >>> On Sun, Jan 14, 2018 at 10:48 AM,

Re: [PATCH v2 09/22] mmc: tmio: use mmc_can_gpio_cd() instead of checking TMIO_MMC_USE_GPIO_CD

On 24 November 2017 at 17:24, Masahiro Yamada wrote: > To use a GPIO line for card detection, TMIO_MMC_USE_GPIO_CD is set > by a legacy board (arch/sh/boards/mach-ecovec24). > > For DT platforms, the "cd-gpios" property is a legitimate way for that > in case the

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

[...] >>> Index: linux-pm/drivers/base/power/domain.c >>> === >>> --- linux-pm.orig/drivers/base/power/domain.c >>> +++ linux-pm/drivers/base/power/domain.c >>> @@ -1048,8 +1048,9 @@ static int genpd_finish_suspend(struct d >>>

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On 9 January 2018 at 17:28, Rafael J. Wysocki wrote: > On Tuesday, January 9, 2018 5:03:18 PM CET Rafael J. Wysocki wrote: >> On Tue, Jan 9, 2018 at 4:30 PM, Geert Uytterhoeven >> wrote: >> > Hi Rafael, >> > >> > CC usb >> > >> > On Tue, Jan 9, 2018 at

Re: [PATCH v2] PM / runtime: Rework pm_runtime_force_suspend/resume()

On 9 January 2018 at 14:37, Geert Uytterhoeven wrote: > Hi Rafael, > > On Wed, Jan 3, 2018 at 12:06 PM, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki >> >> One of the limitations of pm_runtime_force_suspend/resume() is

[PATCH] PM / wakeup: Enable option to specify wakeup as a non in-band wakeup

a helper function, device_set_no_inband_wakeup(), which drivers shall use to set/clear the ->dev.power.no_inband_wakeup flag. Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- To get some additional background, one may look at earlier discussions from various threads. The most recent is in and RFD [1] from Ra

[PATCH v4 1/2] PM / core: Re-structure code for clearing the direct_complete flag

self-explanatory. Like this: dpm_clear_suppliers_direct_complete -> dpm_clear_superiors_direct_complete dpm_propagate_to_parent -> dpm_propagate_wakeup_to_parent Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/base/power/main.c | 15 ++- 1 file changed, 1

[PATCH v4 2/2] PM / core: Propagate wakeup_path status flag in __device_suspend_late()

rom a ->suspend_late() callback, its value doesn't get propagated to the parent by the PM core. Let's address this limitation, by also propagating the flag at __device_suspend_late(). Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/base/power

[PATCH v4 0/2] PM / core: Extend behaviour for wakeup paths

Changes in v4: - Dropped the changes that already been applied. - Patch 1 is new, should not introduce any functional changes, but only structural code changes, as requested by Rafael. - Patch 2, re-based on top of new patch. Ulf Hansson (2): PM / core: Re

[PATCH v4] PM / wakeup: Print warn if device gets enabled as wakeup source during sleep

to properly manage wakeup settings, let's print a warning in cases someone calls device_wakeup_enable() during system sleep. Suggested-by: Rafael J. Wysocki <raf...@kernel.org> Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- Changes in v4: - Send this as a sep

Re: [PATCH v3 4/4] PM / wakeup: Print warn if device gets enabled as wakeup source during sleep

On 6 January 2018 at 00:57, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Tue, Jan 2, 2018 at 5:08 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> In general, wakeup settings are not supposed to be changed during any of >> the system wide PM phases. The reason is

[PATCH v3 4/4] PM / wakeup: Print warn if device gets enabled as wakeup source during sleep

to properly manage wakeup settings, let's print a warning in cases someone calls device_wakeup_enable() during system sleep. Suggested-by: Rafael J. Wysocki <raf...@kernel.org> Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/base/power/wakeup.c | 3 +++ 1 file changed,

[PATCH v3 0/4] PM / core: Extend behaviour for wakeup paths

needed to fix the problems for the Renesas SoCs. Ulf Hansson (4): PM / core: Assign the wakeup_path status flag in __device_prepare() PM / core: Propagate wakeup_path status flag in __device_suspend_late() PM / wakeup: Add device_set_wakeup_path() helper to control wakeup path PM / wakeu

[PATCH v3 1/4] PM / core: Assign the wakeup_path status flag in __device_prepare()

legacy cases should be corrected, however until that is done, let's address the issue from the PM core, by moving the assignment of the wakeup_path status flag to the __device_suspend() phase and after the ->suspend() callback has been invoked. Signed-off-by: Ulf Hansson <ulf.hans..

[PATCH v3 2/4] PM / core: Propagate wakeup_path status flag in __device_suspend_late()

rom a ->suspend_late() callback, its value doesn't get propagated to the parent by the PM core. Let's address this limitation, by also propagating the flag at __device_suspend_late(). Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/base/power

[PATCH v3 3/4] PM / wakeup: Add device_set_wakeup_path() helper to control wakeup path

th(). Typically a driver that manages a resource needed in the wakeup path, should call device_set_wakeup_path() from its ->suspend() or ->suspend_late() callback. Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- include/linux/pm_wakeup.h | 7 +++ 1 file changed, 7 insertions(+)

Re: [PATCH v2 3/3] gpio: rcar: Use WAKEUP_PATH driver PM flag

On 2 January 2018 at 14:53, Geert Uytterhoeven <ge...@linux-m68k.org> wrote: > On Tue, Jan 2, 2018 at 1:53 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> On 2 January 2018 at 11:48, Rafael J. Wysocki <raf...@kernel.org> wrote: >>> On Tue, Jan 2, 2018 at

Re: [PATCH v2 1/3] phy: core: Move runtime PM reference counting to the parent device

On 24 December 2017 at 13:00, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > On Saturday, December 23, 2017 4:09:33 PM CET Ulf Hansson wrote: >> [...] >> >> > >> > So IMO the changes you are proposing make sense regardless of the >> > genpd iss

Re: [PATCH v2 1/4] PM / core: Assign the wakeup_path status flag in __device_prepare()

On 2 January 2018 at 12:43, Rafael J. Wysocki <r...@rjwysocki.net> wrote: > On Tuesday, January 2, 2018 12:36:55 PM CET Ulf Hansson wrote: >> On 30 December 2017 at 01:44, Rafael J. Wysocki <raf...@kernel.org> wrote: >> > On Fri, Dec 29, 2017 at 12:37 PM, Ulf H

Re: [PATCH v2 3/3] gpio: rcar: Use WAKEUP_PATH driver PM flag

>>> Signed-off-by: Geert Uytterhoeven >>> [Ulf: Converted to use the WAKEUP_PATH driver PM flag] > > Ulf: + killing the DEV_PM_OPS define, increasing kernel size if PM_SUSPEND=n? Oh, yes - correct! The code looks nicer, with the penalty of one static struct declared and

Re: [PATCH v2 3/3] gpio: rcar: Use WAKEUP_PATH driver PM flag

needed. This enables us to remove all >>>> explicit clock handling code from the driver, so let's do that as well. >>>> >>>> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> >>>> [Ulf: Converted to use the WAKEUP_PATH driver PM flag] >

Re: [PATCH v2 4/4] PM / core: Print warn if device gets enabled as wakeup source during sleep

On 30 December 2017 at 01:58, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> In general, wakeup settings are not supposed to be changed during any of >> the system wide PM phases. The rea

Re: [PATCH v2 3/4] PM / Domains: Take WAKEUP_PATH driver flag into account in genpd

On 30 December 2017 at 01:47, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> In case the WAKEUP_PATH flag has been set in a later phase than from the >> ->suspend() c

Re: [PATCH v2 1/4] PM / core: Assign the wakeup_path status flag in __device_prepare()

On 30 December 2017 at 01:44, Rafael J. Wysocki <raf...@kernel.org> wrote: > On Fri, Dec 29, 2017 at 12:37 PM, Ulf Hansson <ulf.hans...@linaro.org> wrote: >> The PM core in the device_prepare() phase, resets the wakeup_path status >> flag to the value of devi

[PATCH v2 0/3] renesas: irqchip: Use WAKEUP_PATH driver PM flag

From: Geert Uytterhoeven <geert+rene...@glider.be> Changes in v2: [By Ulf Hansson] - I have picked up the series from Geert [1] and converted it into use the WAKEUP_PATH driver PM flag. This includes some minor changes to each patch and updates to the chan

[PATCH v2 1/3] irqchip/renesas-intc-irqpin: Use WAKEUP_PATH driver PM flag

m the driver, so let's do that as well. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> [Ulf: Converted to use the WAKEUP_PATH driver PM flag] Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/irqchip/irq-renesas-intc-irqpin.c | 42 +++

[PATCH v2 3/3] gpio: rcar: Use WAKEUP_PATH driver PM flag

from the driver, so let's do that as well. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> [Ulf: Converted to use the WAKEUP_PATH driver PM flag] Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/gpio/gpio-rcar.c | 40 +++- 1

[PATCH v2 2/3] irqchip/renesas-irqc: Use WAKEUP_PATH driver PM flag

as well. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> [Ulf: Converted to use the WAKEUP_PATH driver PM flag] Signed-off-by: Ulf Hansson <ulf.hans...@linaro.org> --- drivers/irqchip/irq-renesas-irqc.c | 32 +++- 1 file changed, 15 insertions(+),

  1   2   3   >