Re: [PATCH v5 1/3] mmc: sh_mobile_sdhi: add support for 2 clocks

andt <chris.bra...@renesas.com> Reviewed-by: Wolfram Sang <wsa+rene...@sang-engineering.com> signature.asc Description: PGP signature

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

> The issue happened with renesas-devel, i.e. without those patches. > It was mentioned during last core meeting, so have a look at that log. No need to. As I said, the behaviour is expected without the patches. Thanks for the update! signature.asc Description: PGP signature

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

> > Do you already fetch from Ulf's kernel.org tree? He switched away from > > the Linaro tree for MMC for a while. I only realized when he complained "since a while" not "for a while", of course. > Thanks, I had not realised that. I've pulled the kernel.org tree. So, there is hope for the

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

> > Do you have the HS200 enablement patches in that branch? They are > > currently in -next. > > I tried mmc/next (but didn't notice anything special there). > Which patches should I be looking for? The series starting with 59c21074b582aa ("mmc: sh_mobile_sdhi: simplify accessing DT data") up

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

> I have tested with "the new mmc/next" and things seem better. Good. The issue you saw is expected when you have not the enablement patches in place. > I am still of a mind to drop the M3-W patch of this series because unless > we can control the order that things are merged into Linus's tree

Re: [PATCH v3 1/8] pinctrl: sh-pfc: Add r7s72100 PFC driver

This squash combines commits for Magnus' original driver, several > "groups" definitions and minor fixes on top to forward-port it to a more > recent kernel (v4.10) > > Signed-off-by: Magnus Damm <d...@opensource.se> > Signed-off-by: Wolfram Sang <w...@sang-eng

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

> Using renesas-next without mmc-next I see the problem above on the M3-W. > Using renesas-next with mmc-next I do not see the problem above. > Using v4.10-rc2 I also do not see the problem above. OK. So there is no problem with the code, at least. > So I believe we should delay the integration

Re: [PATCH i2c/for-next] i2c: sh_mobile: document support for r8a7796 (R-Car M3-W)

On Thu, Jan 26, 2017 at 09:47:31AM +0100, Simon Horman wrote: > Explicitly list per-SoC binding for r8a7796. No driver change > is required as the initialisation sequence is currently the same > as for the R-Car Gen3 fallback binding. > > Signed-off-by: Simon Horman

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

On Thu, Jan 26, 2017 at 11:01:17AM +0100, Simon Horman wrote: > On Fri, Jan 13, 2017 at 09:39:28AM +0100, Wolfram Sang wrote: > > > Sorry for missing these. > > > I have queued them up for v4.11. > > > > Thank you! > > On my r8a7796/salvator-x I see

Re: [PATCH i2c/for-next] i2c: sh_mobile: document support for r8a7796 (R-Car M3-W)

ne...@verge.net.au> Acked-by: Wolfram Sang <wsa+rene...@sang-engineering.com> signature.asc Description: PGP signature

Re: [PATCH v6 0/3] mmc: sh_mobile_sdhi: fix missing r7s72100 clocks

> Thanks, applied patch1 and patch2 for next. Patch3 is for Simon, I > guess!? (And I can add Rob's ack afterwards). Can you add my tags as well. They got dropped somehow: Reviewed-by: Wolfram Sang <wsa+rene...@sang-engineering.com> signature.asc Description: PGP signature

[PATCH v7 0/2] arm64: dts: r8a779x: add thermal to DTS

Since the driver is now merged into next, we can add the DTS snipplets as well. Changes from V6: * rebased to latest renesas/arm64-dt-for-v4.11 * changed critical temp from 90° to 120° which is the state in the latest BSP Wolfram Sang (2): arm64: dts: r8a7795: Add R-Car Gen3 thermal support

[PATCH v7 2/2] arm64: dts: r8a7796: Add R-Car Gen3 thermal support

edubez...@gmail.com> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 58 1 file changed, 58 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renes

[PATCH v7 1/2] arm64: dts: r8a7795: Add R-Car Gen3 thermal support

edubez...@gmail.com> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 58 1 file changed, 58 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi b/arch/arm64/boot/dts/renes

Re: [PATCH v4 2/3] mmc: sh_mobile_sdhi: explain clock bindings

> It sounds like your suggestion is to just put the HW description in > the DT bindings, but move the dirty details into the driver. > > Keep in DT: > > +- clocks: Most controllers only have 1 clock source per channel. However, on > + some variations of this controller, the internal card

Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add support for 2 clocks

> > Is this clock solely about card detection? So in cases when you have a > > GPIO card detect, the clock isn't needed? > > > > Just trying to understand things a bit better... > > According to the hardware manual, enabling the "core" clock but not the > "cd" clock is not a valid setting. So

Re: [PATCH RESEND 0/2] arm64: gen3: enable eMMC HS200 in DT

> The problem I see is the following logged to the console > (which makes the console semi-unusable). > > sh_mobile_sdhi ee14.sd: timeout waiting for hardware interrupt (CMD13) Just to make sure: with the HS200 enablement patches present? signature.asc Description: PGP signature

[PATCH] ASoC: rsnd: drop useles self-assignments

Coverity reported (CID 1397992) this self-assignment. I think the code stays readable even with the assignments removed. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- sound/soc/sh/rcar/core.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/soc/sh/rcar/co

[PATCH] ASoC: rsnd: check return value of init function

Currently, this function cannot fail for the ADG case. Still, let's apply defensive programming techniques to make sure we fail gracefully whenever rsnd_mod_init() gets extended with another failure case. Reported by Coverity (CID 1397893). Signed-off-by: Wolfram Sang <wsa+rene...@s

[PATCH v2] mmc: host: tmio: ensure end of DMA and SD access are in sync

is done. In the callback, we then use a completion to make sure the SD access has already ended. Then, we proceed as before. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Changes since V1/RFC: * removed #ifdef DEBUG * rebased to latest mmc/next * did some more perfo

[PULL REQUEST] renesas/topic/sdhi-dma-sync-v2 for renesas drivers

and SD access are in sync (2017-02-17 18:43:28 +0100) Wolfram Sang (1): mmc: host: tmio: ensure end of DMA and SD access are in sync drivers/mmc/host/tmio_mmc.h | 2 +- drivers/mmc/host/tmio_mmc_dma.c | 58

[RFC] mmc: core: check also R1 response for stop commands

Introduce a helper function to not only check the error value but also error bits of a R1 response. Use the helper for the stop command. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- So, here is a first draft of what we talked about recenlty. Let me know what you

[PATCH 1/4] mmc: host: tmio: use defines for CTL_STOP_INTERNAL_ACTION values

Don't use hardcoded values. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/mmc/host/tmio_mmc.h | 4 drivers/mmc/host/tmio_mmc_pio.c | 6 +++--- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mm

[PATCH 2/4] mmc: host: tmio: fix minor typos in a comment

Making sure we match the actual register name. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/mmc/host/tmio_mmc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/tmio_mmc.h b/drivers/mmc/host/tmio_mmc.h index b20b451a

[PATCH 3/4] mmc: host: tmio: don't BUG on unsupported stop commands

Halting the kernel on an unsupported stop command seems overkill, report the error and say what we already did (due to autocmd12) instead. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/mmc/host/tmio_mmc_pio.c | 9 + 1 file changed, 5 insertions

[PATCH 4/4] mmc: host: tmio: fill in response from auto cmd12

After we received the dataend interrupt, R1 response register carries the value from the automatically generated stop command. Report that info back to the MMC block layer, so we will be notified in case of e.g. ECC errors which happened during the last transfer. Signed-off-by: Wolfram Sang <

[PATCH 0/4] mmc: host: tmio: properly report status from autocmd12

/linux/kernel/git/wsa/linux.git renesas/topic/sdhi-autocmd12-resp Thanks and all the best, Wolfram [1] http://elinux.org/Tests:SDHI-autocmd12-responses Wolfram Sang (4): mmc: host: tmio: use defines for CTL_STOP_INTERNAL_ACTION values mmc: host: tmio: fix minor typos in a comment mmc

[PULL REQUEST] renesas/topic/sdhi-autocmd12-resp for renesas drivers

-07 11:47:26 +0100) Wolfram Sang (4): mmc: host: tmio: use defines for CTL_STOP_INTERNAL_ACTION values mmc: host: tmio: fix minor typos in a comment mmc: host: tmio: don't BUG on unsupported stop commands mmc

Re: [PATCH v2 4/4] mmc: host: tmio: fill in response from auto cmd12

Shimoda-san, Ulf, On Tue, Feb 14, 2017 at 10:06:47AM +, Yoshihiro Shimoda wrote: > Hi, > > > From: Wolfram Sang [mailto:wsa+rene...@sang-engineering.com] > > Sent: Tuesday, February 14, 2017 3:04 AM > > > > After we received the dataend interrupt, R1 response

Re: [PATCH 2/4] mmc: host: tmio: fix minor typos in a comment

> > -/* Definitions for values the CTRL_STATUS register can take. */ > > +/* Definitions for values the CTL_STATUS register can take */ > > #define TMIO_STAT_CMDRESPENDBIT(0) > > #define TMIO_STAT_DATAEND BIT(2) > > #define TMIO_STAT_CARD_REMOVE BIT(3) > > Is a similar update for

Re: [PATCH v2 4/4] mmc: host: tmio: fill in response from auto cmd12

Hi Ulf, On Thu, Feb 16, 2017 at 08:57:36AM +0100, Ulf Hansson wrote: > On 15 February 2017 at 16:02, Wolfram Sang <w...@the-dreams.de> wrote: > > > >> > I see. Ulf, do you think it makes sense to extend the condition when to > >> > call mmc_blk_cmd_recovery(

Re: [RFC] mmc: host: tmio: ensure end of DMA and SD access are in sync

On Thu, Feb 16, 2017 at 09:28:24AM +0100, Ulf Hansson wrote: > On 15 February 2017 at 19:05, Wolfram Sang > <wsa+rene...@sang-engineering.com> wrote: > > The current code assumes that DMA is finished before SD access end is > > flagged. Thus, it schedules the 'dma_complete

[RFC] mmc: host: tmio: ensure end of DMA and SD access are in sync

is done. In the callback, we then use a completion to make sure the SD access has already ended. Then, we proceed as before. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- I tried various synchronization approaches and liked this one best. There are a couple of reasons this

[PULL REQUEST] renesas/topic/sdhi-dma-sync for renesas drivers

are in sync (2017-02-15 23:17:55 +0100) Wolfram Sang (1): mmc: host: tmio: ensure end of DMA and SD access are in sync drivers/mmc/host/tmio_mmc.h | 2 +- drivers/mmc/host/tmio_mmc_dma.c | 70

Re: [PATCH] ARM: shmobile: r7s72100: add restart handler

> > #1 and #3 look like they are the same thing (except #3 is enabled on power > > on reset). The renesas_wdt.c uses the register names from #1. > > Is the idea that you only use #3 to make sure your systems boots and get > > into > > Linux, then from there you use #1 and stop #3 (hence no

Re: [PATCHv6 0/4] thermal: add driver for R-Car Gen3

> larger. Therefore I would like to ask Morimoto-san and/or Khiem to > provide or proxy testing of this less accurate formula and feedback if > it's OK, let me know if there is anything I can do to help out. We now got the results of Renesas internal testing via internal channels. So, for this

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

> So, should sh_mobile_sdhi_remove() be changed to call > sh_mobile_sdhi_clk_disable()? Give me a minute, I already did a patch for this :) signature.asc Description: PGP signature

Re: [PATCH v2 2/3] mmc: sh_mobile_sdhi: explain clock bindings

On Tue, Jan 17, 2017 at 02:59:39PM -0500, Chris Brandt wrote: > In the case of a single clock source, you don't need names. However, > if the controller has 2 clock sources, you need to name them correctly > so the driver can find the 2nd one. > > Signed-off-by: Chris Brandt

Re: [PATCH v4 1/2] iio: adc: Add Maxim MAX11100 driver

> + * Copyright (C) 2016 Renesas Electronics Corporation > + * Copyright (C) 2016 Jacopo Mondi In case you need to resend: 2016-17?

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

> > and then in the code do: > > > > struct *cd_clk; > > cd_clk = devm_clk_get(>dev, "cd"); > > if (cd_clk) { > > clk_prepare_enable(cd_clk); > > } > > > > (this simple 1-line fix patch is getting a lot more complicated) > > Disclaimer: I don't

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

> The reason is that would then keep me from having to modify the existing > functions sh_mobile_sdhi_clk_enable/disable. Why do you prefer this? I may be missing something but a small if-block per function are not expensive IMO. > Is anyone going to have an issue if I turn the card-detect

Re: [PATCH] ARM: dts: r7s72100: fix sdhi clock define

> If we handle them as one, won't we miss card detect events due to the > card detect clock being disabled while SDHI is idle? You mean this? 1208 /* 1209 * While using internal tmio hardware logic for card detection, we need 1210 * to ensure it stays powered for it

[PATCH 0/3] mmc: host: tmio: sdio irq improvements

Here is a small series with two minor improvements (patches 1+2) and one bigger change (patch 3) for SDIO handling with TMIO/SDHI. Since RFC, I addressed all comments (Thanks Simon!) and since it is needed for the WLAN cards, I think it should go in now. Wolfram Sang (3): mmc: host: tmio

[PATCH v2 1/3] mmc: host: tmio: refactor calls to sdio irq

tmio_mmc_sdio_irq() is not used as a seperate irq handler anymore, so we can make it similar to the other irq helper functions, namely: * only give the host as argument function which is what it really needs * prefix function name with __ Signed-off-by: Wolfram Sang <wsa+rene...@s

Re: [PATCH] watchdog: softdog: make pretimeout support a compile option

> > +#if IS_ENABLED(CONFIG_SOFT_WATCHDOG_PRETIMEOUT) > > static void softdog_pretimeout(unsigned long data) > > I would prefer __maybe_unused here .. > > > { > > watchdog_notify_pretimeout(_dev); > > @@ -82,16 +83,23 @@ static void softdog_pretimeout(unsigned long data) > > static struct

[PATCH v2 3/3] mmc: tmio: discard obsolete SDIO irqs before enabling irqs

Before enabling SDIO irqs, clear the status bit, so we discard old and stale interrupts. Needed to get two wireless cards working. Use the newly introduced macro in all places. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Change since RFC: use #define for SETBIT

[PATCH v2 2/3] mmc: host: tmio: SDIO_STATUS_QUIRK is rather SDIO_STATUS_SETBITS

QUIRK sounds like there is something wrong, but actually there are just some bits which need to be 1. Rename it to be more clear. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Change since RFC: make comments more precise drivers/mmc/host/sh_mobile_sdhi

Re: [PATCH v3 1/3] mmc: sh_mobile_sdhi: add support for 2 clocks

On Wed, Jan 18, 2017 at 12:25:00PM -0500, Chris Brandt wrote: > Some controllers have 2 clock sources instead of 1, so they both need > to be turned on/off. > > Signed-off-by: Chris Brandt <chris.bra...@renesas.com> Reviewed-by: Wolfram Sang <wsa+rene...@sang-engineering.

Re: [PATCH v3 2/3] mmc: sh_mobile_sdhi: explain clock bindings

andt <chris.bra...@renesas.com> Reviewed-by: Wolfram Sang <wsa+rene...@sang-engineering.com> signature.asc Description: PGP signature

Re: [RFC 2/3] mmc: host: tmio: SDIO_STATUS_QUIRK is rather SDIO_STATUS_SETBITS

> > --- a/include/linux/mfd/tmio.h > > +++ b/include/linux/mfd/tmio.h > > @@ -97,7 +97,7 @@ > > /* > > * Some controllers needs to set 1 on SDIO status reserved bits > > */ > > Is the following update to the above appropriate? > In particular, is it some or all? Some. > * Controllers

Re: [RFC 3/3] mmc: tmio: discard obsolete SDIO irqs before enabling irqs

> > + if (host->pdata->flags & TMIO_MMC_SDIO_STATUS_SETBITS) > > + sdio_status |= 6; > > Perhaps a #define would be an improvement over "6". OK.

Re: [PATCHv6 0/4] thermal: add driver for R-Car Gen3

> Add this to my tree and to my linux-next branch. However, as usual, I am Thanks! > taking the driver+docs, the dt binding must go through your arch tree, Yes, sure. I do the same in the I2C subsystem. > Acked-by: Eduardo Valentin Done. Will resend the DTS patches in a

Re: [PATCH 1/2] ARM: shmobile: r8a7790: only use smp_init when SMP is selected

Hi Simon, > > We use the helper function which populates the smp_init pointer only in > > case of SMP. > > > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> > > could you describe the motivation for this change in the changelog? I am

Re: [PATCH v2 3/9] mmc: tmio: Add UHS-I mode support

> I'll try to remove it. Note that sh73a0-kzm9g.dts also uses broken-cd, > without ill effects. This one does have a seperate card-detect-irq (which is not populated for sdhi2) while the other one only has one, generic irq. That's at least a difference. We could try to see if there are

[PATCH] Documentation: devicetree: changesets do locking on their own meanwhile

Since commit 183223770ae862 ("drivers/of: Export OF changeset functions"), the mentioned functions do all necessary locking. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> Fixes: 201c910bd6898d ("of: Transactional DT support.") --- Documentation/devi

[PATCH] i2c: mux: demux-pinctrl: invalidate properly when switching fails

Make sure the index to the active channel is invalidated when switching fails. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/muxes/i2c-demux-pinctrl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/i2c/muxes/i2c-demux-pinctrl.c b/drivers/i2c

Re: [PATCH] Documentation: devicetree: changesets do locking on their own meanwhile

On Mon, Aug 22, 2016 at 04:42:58PM +0200, Wolfram Sang wrote: > Since commit 183223770ae862 ("drivers/of: Export OF changeset functions"), > the mentioned functions do all necessary locking. > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com

Re: [PATCH v2 3/9] mmc: tmio: Add UHS-I mode support

> [] (__mmc_start_request) from [] > (mmc_start_request+0x104/0x118) This function calls card_busy only for SDIO cards. I assume you don't have one inserted? Maybe the "broken-cd" property doesn't work correctly and causes side-effects? This would explain why it only affects SDHI1 and not

[PATCH 0/2] mmc: sh_mobile_sdhi: use SDR & card_busy only on Gen2+

test, please? Wolfram Sang (2): mmc: host: sh_mobile_sdhi: move card_busy from tmio to sdhi mmc: host: sh_mobile_sdhi: don't populate unneeded functions drivers/mmc/host/sh_mobile_sdhi.c | 16 +++- drivers/mmc/host/tmio_mmc.h | 1 + drivers/mmc/host/tmio_mmc_pio.c | 9

[PATCH 1/2] i2c: sh_mobile: use proper device with dma_mapping_error

We must use the same device we used for mapping. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/busses/i2c-sh_mobile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/i2c/busses/i2c-sh_mobile.c b/drivers/i2c/busses/i2c-sh_mo

[PATCH 2/2] mmc: host: sh_mobile_sdhi: don't populate unneeded functions

Populating card_busy caused a side-effect on a chip variant we don't have documentation for (r8a73a4). So, enable it and voltage switching only on devices known to support those features. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/mmc/host/sh_mobile_sdhi.

[PATCH 1/2] mmc: host: sh_mobile_sdhi: move card_busy from tmio to sdhi

card_busy is only used/tested on SDHI for R-Car Gen2 and later. Move it to the SDHI driver, so we can then activate it conditionally depending on the SDHI type. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/mmc/host/sh_mobile_sdhi.c | 8 drivers/mm

Re: [PATCH 2/2] mmc: host: sh_mobile_sdhi: don't populate unneeded functions

> > It can be argued that this tag could be added: > > > > Fixes: 452e5eef6d311e ("mmc: tmio: Add UHS-I mode support") > > > > I don't know how well it applies, though, because the code has been > > modified a lot recently. But we can try. > > Please tell me if you would like me to drop any of

Re: [PATCH v5 10/11] arm64: dts: r8a7795: salvator-x: Enable UHS-I SDR-104

On Tue, Aug 30, 2016 at 11:09:58PM +0200, Simon Horman wrote: > Add the sd-uhs-sdr104 property to SDHI0 and SDHI1. > > Signed-off-by: Simon Horman After removing a SDR104 card from the slot, the interface is stalled here. No new cards (even non-SDR104) can be

Re: renesas-drivers-2016-08-23-v4.8-rc3

> I can reproduce this on Lager board now. > If I OFF:ed on SW8 : 4bit (= MD21), kernel boot will be failed. > It happened on both board Even with my recent patch? signature.asc Description: PGP signature

[PATCH v2] ARM: shmobile: fix regulator quirk for Gen2

on specific boards only, the addresses are not going to change. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be> Tested-by: Geert Uytterhoeven <geert+rene...@glider.be> (r8a7791/koelsch) --- Added a comment desc

Re: [PATCH 2/2] mmc: host: sh_mobile_sdhi: don't populate unneeded functions

Magnus, > To my eye it looks like this patch might be adding a fix for a bug > introduced by another patch. R-Car Gen2 and later are quite recent > SoCs but I believe support for other mobile chips and earlier R-Car > SoCs also also covered by the SDHI driver. Also there are theTMIO > chips that

Re: [PATCH] i2c: mux: demux-pinctrl: run properly with multiple instances

On Tue, Aug 23, 2016 at 05:28:03PM +0200, Wolfram Sang wrote: > We can't use a static property for all the changesets, so we now create > dynamic ones for each changeset. > > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> > Fixes: 50a5ba87690814 ("i2

[PATCH] ARM: shmobile: fix regulator quirk for Gen2

on specific boards only, the addresses are not going to change. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- arch/arm/mach-shmobile/regulator-quirk-rcar-gen2.c | 61 +- 1 file changed, 25 insertions(+), 36 deletions(-) diff --git a/arch/arm/mach-sh

Re: [PATCH v3 01/13] ARM: dts: lager: rename and reindex i2cexio

Hi Simon, > serial0 = > serial1 = > - i2c8 = "i2cexio"; > + i2c10 = "i2cexio0"; Those should be pointers, i.e. "", here and in the rest of your series. Sorry for the broken template! Did you have a chance to test my fix for the demuxer?

[PATCH v2] watchdog: softdog: implement pretimeout support

From: Wolfram Sang <wsa+rene...@sang-engineering.com> Give devices which do not have hardware support for pretimeout at least a software version of it. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Change since v1: added 'else' block in softdog_ping(), to actu

Re: [PATCH] ARM: shmobile: fix regulator quirk for Gen2

On Thu, Sep 01, 2016 at 04:22:37PM +0200, Simon Horman wrote: > On Tue, Aug 30, 2016 at 05:15:58PM +0200, Geert Uytterhoeven wrote: > > Hi Wolfram, > > > > On Tue, Aug 30, 2016 at 4:54 PM, Wolfram Sang > > <wsa+rene...@sang-engineering.com> wrote: > >

Re: [PATCH v5 10/11] arm64: dts: r8a7795: salvator-x: Enable UHS-I SDR-104

On Thu, Sep 01, 2016 at 04:25:40PM +0200, Simon Horman wrote: > On Thu, Sep 01, 2016 at 09:23:54AM +0200, Wolfram Sang wrote: > > On Tue, Aug 30, 2016 at 11:09:58PM +0200, Simon Horman wrote: > > > Add the sd-uhs-sdr104 property to SDHI0 and SDHI1. > > > > > >

[PULL REQUEST] renesas/topic/i2c_sdhi_maintenance for renesas drivers

/i2c_sdhi_maintenance for you to fetch changes up to 91d6e42f0ba217c5d26d88648a18022f573d75de: ARM: shmobile: fix regulator quirk for Gen2 (2016-08-31 08:51:08 +0200) Wolfram Sang (9): arm64: dts: r8a7795: set maximum frequency for SDHI

Re: [PATCH v5 08/11] arm64: r8a7795: Set maximum frequencies for SDHI clocks

On Tue, Aug 30, 2016 at 11:09:56PM +0200, Simon Horman wrote: > Signed-off-by: Simon Horman > --- > v5 > * New patch Huh? There is already 721e9a08aa514c ("arm64: dts: r8a7795: set maximum frequency for SDHI clocks") in renesas/drivers? Why didn't you pick this one?

Re: renesas-drivers-2016-08-23-v4.8-rc3

> The revision doesn't seem to be printed on the chip package, but it is > identified by the da9063 driver (CONFIG_REGULATOR_DA9063=y). Am I recalling correctly that noone of us has access to DA9063 documentation? Is this still true? Or do we know the differences of the revisions?

Re: [PATCH 2/3] pinctrl: sh-pfc: r8a7791: Implement voltage switching for SDHI

he card. > > > > Based on work by Wolfram Sang for the r8a7790. > > > > Cc: Wolfram Sang <wsa+rene...@sang-engineering.com> > > Signed-off-by: Simon Horman <horms+rene...@verge.net.au> > > If you correct the copy-and-pasted comment below, you

Re: [PATCH 3/3] pinctrl: sh-pfc: r8a7794: Implement voltage switching for SDHI

turn 31 + 16 - (pin & 0x1f); > > While your code is correct, I think it's easier for the casual reader to use > a plain switch () statement, and let the optimizer handle the rest. Both is fine with me: Acked-by: Wolfram Sang <wsa+rene...@sang-engineering.com> signature.asc Description: PGP signature

Re: [PATCH] pinctrl: sh-pfc: r8a7796: Add voltage switch operations for SDHI

On Thu, Sep 08, 2016 at 01:57:33PM +0200, Simon Horman wrote: > This patch supports the {get,set}_io_voltage operations of SDHI. > > This operates the POCCTRL0 register on R8A7796 SoC and makes 1.8v/3.3v > voltage switch. > > Based on work by Takeshi Kihara and Wolfram Sang

Re: [PATCH] i2c: mux: demux-pinctrl: run properly with multiple instances

> > > Simon: I think you can retest your demuxer-dts-series now. > > > > Simon: you think we can get that into 4.9? Would be awesome. > > Sorry, this slipped through the cracks. > Lets aim for v4.10. A ;) Ok, will update the todo. signature.asc Description: PGP signature

Re: [PATCH v7 0/6] UHS-I SDR-104 support for sh_mobile_sdhi

_sdhi. It builds on work by Shinobu Uehara, Rob Taylor, William > > Towle and Ian Molton, Ben Hutchings, Wolfram Sang and others to add UHS-I > > SDR-50 support to the same driver. > > > > It is based on a merge of the next branches of the mmc tree. > > > > To aid

[PATCH 4/4] mmc: tmio: add eMMC support

We need to add R1 without CRC support, refactor the bus width routine a little and extend a quirk check. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/mmc/host/tmio_mmc.h | 3 +++ drivers/mmc/host/tmio_mmc_pio.c | 29 + 2

[PATCH 2/4] mmc: rtsx_pci: use new macro for R1 without CRC

Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/mmc/host/rtsx_pci_sdmmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c b/drivers/mmc/host/rtsx_pci_sdmmc.c index 396c9b7e4121b0..3ccaa1415f33b2 100644 --- a/d

[PATCH 1/4] mmc: add define for R1 response without CRC

The core uses it for polling. Give drivers a proper define to handle this case like all other response types. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- include/linux/mmc/core.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/mmc/core.h b/i

[PATCH 3/4] mmc: rtsx_usb: use new macro for R1 without CRC

Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/mmc/host/rtsx_usb_sdmmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mmc/host/rtsx_usb_sdmmc.c b/drivers/mmc/host/rtsx_usb_sdmmc.c index 6c71fc9f76c7ec..4106295527b9d0 100644 --- a/d

[PATCH 0/4] tmio: add support for eMMC with 8 bit bus width

From: Wolfram Sang <w...@the-dreams.de> This series enables SDHI instances on R-Car Gen3 to access eMMC with 8 bit bus width. I think the patch descriptions speak for themselves. I decided to not protect this new feature with a flag because it needs specifically to be enabled by setting t

[PATCH 1/2] arm64: dts: r8a7795: salvator: enable on-board eMMC

Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 43 ++ 1 file changed, 43 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-sa

[PATCH 2/2] arm64: dts: r8a7796: salvator: enable on board eMMC

Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts | 44 +- 1 file changed, 43 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7796-salvator-x.dts b/arch/arm64/boot/dts/r

[PATCH 0/2] gen3: dts: enable on-board eMMC

From: Wolfram Sang <w...@the-dreams.de> Here are the DTS changes to enable the on-board eMMC memory at 8 bit bus widths on R-Car Gen3 Salvator-X boards. Note that 'non-removable' is not supported yet because of Runtime PM issues. It seems we need to overhaul Runtime PM handling for other r

Re: [PATCH v7 0/6] UHS-I SDR-104 support for sh_mobile_sdhi

_sdhi. It builds on work by Shinobu Uehara, Rob Taylor, William > > Towle and Ian Molton, Ben Hutchings, Wolfram Sang and others to add UHS-I > > SDR-50 support to the same driver. > > > > It is based on a merge of the next branches of the mmc tree. > > > > To aid

Re: [PATCH v7 02/11] arm64: dts: r8a7795: salvator-x: enable UHS for SDHI 0 & 3

On Fri, Sep 16, 2016 at 11:55:00AM +0200, Simon Horman wrote: > On Tue, Sep 13, 2016 at 12:56:59PM +0200, Simon Horman wrote: > > From: Wolfram Sang <wsa+rene...@sang-engineering.com> > > > > Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be> > >

Re: [PATCH v7 06/11] ARM: dts: r8a7794: set maximum frequency for SDHI clocks

On Tue, Sep 13, 2016 at 12:57:03PM +0200, Simon Horman wrote: > Define the upper limit otherwise the driver cannot utilize max speeds. > > Signed-off-by: Simon Horman <horms+rene...@verge.net.au> Reviewed-by: Wolfram Sang <wsa+rene...@sang-engineering.com> signature

Re: [PATCH v7 07/11] ARM: dts: alt: Enable UHS-I SDR-50 and SDR-104

e for now as well: Reviewed-by: Wolfram Sang <wsa+rene...@sang-engineering.com> signature.asc Description: PGP signature

Re: [PATCH v7 08/11] arm64: dts: r8a7796: add SDHI nodes

.be> If you remove the two lines you removed from H3 already: Reviewed-by: Wolfram Sang <wsa+rene...@sang-engineering.com> > + sdhi2: sd@ee14 { > + compatible = "renesas,sdhi-r8a7796"; > + reg = <

Re: [PATCH v7 09/11] arm64: dts: r8a7796: salvator-x: enable SDHI0 & 3

eert Uytterhoeven <geert+rene...@glider.be> Reviewed-by: Wolfram Sang <wsa+rene...@sang-engineering.com> signature.asc Description: PGP signature

Re: [PATCH v7 05/11] ARM: dts: koelsch: Enable UHS-I SDR-50 and SDR-104

gned-off-by: Simon Horman <horms+rene...@verge.net.au> > > As SDR50 support is present in the driver in mainline (correct me if I am > wrong!) I have queued this up after dropping the sdr104 portion and > updating the changelog accordingly. Looks good! Acked-by: Wolfram Sa

Re: [PATCH v7 10/11] arm64: dts: r8a7796: salvator-x: enable UHS for SDHI 0 & 3

On Tue, Sep 13, 2016 at 12:57:07PM +0200, Simon Horman wrote: > Based on work for the r8a7796 by Wolfram Sang. > > Cc: Wolfram Sang <wsa+rene...@sang-engineering.com> > Signed-off-by: Simon Horman <horms+rene...@verge.net.au> Reviewed-by: Wolfram Sang <wsa+r

[PULL REQUEST] renesas/topic/sdhi-8bit-emmc for renesas drivers

on board eMMC (2016-09-14 18:16:06 +0200) Wolfram Sang (7): hotfix for sdr104-v7 mmc: add define for R1 response without CRC mmc: rtsx_pci: use new macro for R1 without CRC mmc: rtsx_usb: use new macro for R1

[PATCH v2 5/6] arm64: dts: r8a7795: salvator: enable on-board eMMC

Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts | 43 ++ 1 file changed, 43 insertions(+) diff --git a/arch/arm64/boot/dts/renesas/r8a7795-salvator-x.dts b/arch/arm64/boot/dts/renesas/r8a7795-sa

[PATCH v2 1/6] mmc: add define for R1 response without CRC

The core uses it for polling. Give drivers a proper define handle this case like for other response types. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- include/linux/mmc/core.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/mmc/core.h b/include

<    1   2   3   4   5   6   7   8   9   10   >