[PATCH 09/27] staging: ks7010: delete seperate debug header

From: Wolfram Sang <wsa+rene...@sang-engineering.com> Move the one debug macro to the generic wlan header. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/staging/ks7010/ks7010_config.c | 1 - drivers/staging/ks7010/ks7010_sdio.c | 1 - drivers/st

[PATCH 11/27] staging: ks7010: make loading config file optional

From: Wolfram Sang <wsa+rene...@sang-engineering.com> We have sane defaults, so we don't need to bail out if there is no config file. Note that the config file should go away completely in favour of configuration mechanisms already upstream. Signed-off-by: Wolfram Sang <wsa+ren

[PATCH 08/27] staging: ks7010: use kernel helper to print buffer

From: Wolfram Sang <wsa+rene...@sang-engineering.com> No need for an open coded one. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/staging/ks7010/Makefile | 2 +- drivers/staging/ks7010/ks7010_sdio.c | 9 + drivers/staging/ks7010/ks_deb

[PATCH 12/27] staging: ks7010: fix printk format warnings

From: Wolfram Sang <wsa+rene...@sang-engineering.com> Use proper type for size_t. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/staging/ks7010/ks7010_config.c | 2 +- drivers/staging/ks7010/ks7010_sdio.c | 2 +- 2 files changed, 2 insertions(+),

[PATCH 10/27] staging: ks7010: really iterate over multicast addresses

From: Wolfram Sang <wsa+rene...@sang-engineering.com> The loop variable was defined but not really used. Fix this. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/staging/ks7010/ks_hostif.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --g

Re: [PATCH v2 2/9] mmc: tmio, sh_mobile_sdhi: Add support for variable input clock frequency

> > 1. The SDHI/MMC clocks now run much slower than before. Perhaps this is > > intentional, and a consequence of finding the best way to drive the SD > > card at the target frequency? > > I don't think is generally a problem. Probably even saves a little > power. If you insert an

Re: [PATCH v2 2/9] mmc: tmio, sh_mobile_sdhi: Add support for variable input clock frequency

> > That seems like a bug in the clock driver. If it doesn't have > > independent dividers for each clock client then it shouldn't allow any > > client to change the frequency. So, we need MSTP clocks which do not use CLK_SET_RATE_PARENT on r8a7740. Probably the best way is to use the

[RFC 2/2] ARM: shmobile: r8a7740: add "sd" clock and use it

From: Wolfram Sang <wsa+rene...@sang-engineering.com> Create the "sd" clock and connect the SDHI MSTP clocks to it. Those shouldn't be connect to HP directly, because they shouldn't be allowed to change the rate of the HP clock. Signed-off-by: Wolfram Sang <wsa+rene...@s

[RFC 1/2] clk: renesas: r8a7740: add an "sd" clock

From: Wolfram Sang <wsa+rene...@sang-engineering.com> Create a virtual "sd" clock to feed the MSTP clocks for the SDHI cores. MSTP clocks can change the rate of their parents which is undesired for a generic clock as HP. So, add this static "sd" clock where the MSTP

[RFC 0/2] r8a7740: fix SDHI clock handling

Here is a less intrusive approach of handling the r8a7740 flaw when handling SDHI clocks. Let me know what you think of it. Not tested due to no hw! Thanks, Wolfram Wolfram Sang (2): clk: renesas: r8a7740: add an "sd" clock ARM: shmobile: r8a7740: add "sd" clock a

[PATCH] ARM: shmobile: r8a7790: fix max-frequency for SDHI

From: Wolfram Sang <wsa+rene...@sang-engineering.com> The wrong values come from an old datasheet. Fix them. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- arch/arm/boot/dts/r8a7790.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/a

Re: [PATCH v2 2/9] mmc: tmio, sh_mobile_sdhi: Add support for variable input clock frequency

On Fri, Apr 15, 2016 at 10:41:57PM +0200, Wolfram Sang wrote: > > > That seems like a bug in the clock driver. If it doesn't have > > > independent dividers for each clock client then it shouldn't allow any > > > client to change the frequency. > > So, we

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

> Whether we want a clock to influence its parent is policy, not hardware > description. So IMHO it doesn't belong in DT. Yeah, I agree to that. > IMHO it's more worthwhile to convert r8a7740 to use the CPG/MSSR driver. > There it can be handled easily by adding a flag to the mssr_mod_clk

[PATCH 1/5] mmc: tmio: give read32/write32 functions more descriptive names

From: Wolfram Sang <wsa+rene...@sang-engineering.com> Looking at the backlogs, I am not the only one who missed that the above functions do not read u32 from one register, but create a virtual u32 from reading to adjacent u16 registers (which depending on 'bus_shift' can be up to 8 byte

[PATCH 2/5] mmc: tmio: use BIT() within defines

From: Wolfram Sang <wsa+rene...@sang-engineering.com> BIT() makes it easier to match the bits to the datasheet. This is especially important here, since some variants have different names in their datasheets (like with Renesas R-Car). Signed-off-by: Wolfram Sang <wsa+rene...@sang-engine

[PATCH 5/5] mmc: tmio: document CTL_STATUS handling

From: Wolfram Sang <wsa+rene...@sang-engineering.com> Now that reading CTL_STATUS is consistent, we can remove CTL_STATUS2 and document how this is handled internally. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/mmc/host/tmio_mmc.h | 3 ++- 1 fil

[PATCH 4/5] mmc: tmio/sdhi: distinguish between SCLKDIVEN and ILL_FUNC

From: Wolfram Sang <wsa+rene...@sang-engineering.com> This bit has a different meaning in SDHI and original TMIO. Document that and use the proper naming. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/mmc/host/sh_mobile_sdhi.c | 3 ++- drivers/mmc/hos

[PATCH 3/5] mmc: tmio: use CTL_STATUS consistently

From: Wolfram Sang <wsa+rene...@sang-engineering.com> To prevent confusion, use the virtual u32 CTL_STATUS in card_busy() the same way as in other parts of this driver. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/mmc/host/tmio_mmc.h | 3 +-- driv

[PATCH 0/5] mmc: tmio: make CTL_STATUS handling consistent

complex and easier to work with. Tested on Renesas R-Car Gen2 and Gen3. It is on top of my not-yet applied series "[PATCH 0/6] mmc: tmio/sdhi: clean up cruft". A complete branch is here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/sdhi-uhs Wolfram Wolfr

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

> Hence I think it should be handled in the driver. I knew it ;) If we change the MSTP driver, we should do it in a generic way. MSTP clocks which should/should not change the parent's clock rate can be anywhere. My best bet so far would be encoding this in DT, because all the heuristics I

Re: [RFC 0/2] r8a7740: fix SDHI clock handling

> Can you please give more detail about this r8a7740 issue? Just > "r8a7740 flaw" does not make me understand. Ah, sorry. This RFC series was merely meant as a "right direction?" series for Geert, thus the short CC list. The full series will have better documentation. The flaw is: On r8a7740,

[PATCH] mmc: sdio: fall back to SDIO 1.0 for broken 1.1 cards

From: Wolfram Sang <wsa+rene...@sang-engineering.com> I have two SDIO WLAN cards which specify being SDIO Rev. 1.1 cards but their FUNCE tuple reports the smaller size of a Rev 1.0 card. So, enforce 1.0 on these cards to avoid reading the not present registers. They are not really used anyh

[PATCH] MAINTAINERS: update entry for TMIO MMC driver

From: Wolfram Sang <wsa+rene...@sang-engineering.com> I have some more additions planned for this driver, so I'd like to get notified of other changes and coordinate them. Drop Ian as maintainer because he hasn't been involved in development for a while. Thanks for all the initial work, of

[PATCH] mmc: sh_mobile_sdhi: enable SDIO IRQs for RCar Gen3

From: Wolfram Sang <wsa+rene...@sang-engineering.com> Tested on a Salvator-X board with a Spectec SDW-823 WLAN card. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/mmc/host/sh_mobile_sdhi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --g

[PATCH 5/7] watchdog: add pretimeout support to the core

From: Wolfram Sang <wsa+rene...@sang-engineering.com> Since the watchdog framework centrializes the IOCTL interfaces of device drivers now, SETPRETIMEOUT and GETPRETIMEOUT need to be added in the common code. Signed-off-by: Robin Gong <b38...@freescale.com> Signed-off-by: Wolfram Sa

[PATCH 2/7] watchdog: pretimeout: add panic pretimeout governor

From: Vladimir Zapolskiy <vladimir_zapols...@mentor.com> Panic watchdog pretimeout governor, on watchdog pretimeout event the kernel shall panic. Signed-off-by: Vladimir Zapolskiy <vladimir_zapols...@mentor.com> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>

[PATCH 3/7] watchdog: pretimeout: add noop pretimeout governor

From: Vladimir Zapolskiy <vladimir_zapols...@mentor.com> Noop watchdog pretimeout governor, only an informational message is added to the kernel log buffer. Signed-off-by: Vladimir Zapolskiy <vladimir_zapols...@mentor.com> Signed-off-by: Wolfram Sang <wsa+rene...@sang-

[PATCH 7/7] 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> --- drivers/watchdog/softdog.c | 20 +++- 1 file

[RFC 0/2] watchdog: pretimeout: userspace governor

we want to introduce select/poll support only for pretimeouts? Other ideas? Thanks, Wolfram Vladimir Zapolskiy (1): watchdog: pretimeout: add userspace notifier pretimeout governor Wolfram Sang (1): watchdog: dev: add helper for creating uevent on dev drivers/watchdog/Kconfig

[PATCH 1/7] watchdog: add watchdog pretimeout framework

From: Wolfram Sang <wsa+rene...@sang-engineering.com> The change adds a simple watchdog pretimeout framework infrastructure, its purpose is to allow users to select a desired handling of watchdog pretimeout events, which may be generated by a watchdog driver. By design every watchdog pret

[RFC 1/2] watchdog: dev: add helper for creating uevent on dev

From: Wolfram Sang <wsa+rene...@sang-engineering.com> Mechanisms like pretimeout governors may want to notify userspace via uevents. Add a helper because all the needed data is private to the watchdog device. To allow calling it in atomic contexts, put actual signalling to a workqueue.

[RFC 2/2] watchdog: pretimeout: add userspace notifier pretimeout governor

From: Vladimir Zapolskiy <vladimir_zapols...@mentor.com> Userspace notifier watchdog pretimeout governor, on watchdog pretimeout event sends a notification to userspace for further handling. Signed-off-by: Vladimir Zapolskiy <vladimir_zapols...@mentor.com> Signed-off-by: Wolfram Sa

Re: [PATCH v4 0/4] UHS-I SDR-104 support for sh_mobile_sdhi

good to go in and we could improve incrementally from here: Tested-by: Wolfram Sang <wsa+rene...@sang-engineering.com> Maybe Ulf can have another high-level view on those. I guess he is more experienced with the tuning stuff? Thanks, Wolfram

Re: [PATCH] i2c: mux: demux-pinctrl: properly roll back when adding adapter fails

On Fri, Aug 12, 2016 at 06:40:23PM +0200, Wolfram Sang wrote: > We also need to revert the dynamic OF change, so we get a consistent > state again. Otherwise, we might have two devices enabled e.g. after > pinctrl setup fails. > > Signed-off-by: Wolfram Sang <wsa+rene...@sa

Re: [PATCH v4 2/4] mmc: tmio: Add tuning support

> +static int tmio_mmc_execute_tuning(struct mmc_host *mmc, u32 opcode) > +{ > + struct tmio_mmc_host *host = mmc_priv(mmc); > + unsigned int num; > + int i, ret = 0; > + bool *tap; > + > + if (!host->init_tuning || !host->select_tuning) Check host->prepare_tuning, too? > +

[PATCH] i2c: mux: demux-pinctrl: properly roll back when adding adapter fails

We also need to revert the dynamic OF change, so we get a consistent state again. Otherwise, we might have two devices enabled e.g. after pinctrl setup fails. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- drivers/i2c/muxes/i2c-demux-pinctrl.c | 4 +++- 1 file chan

Re: [RFC] ARM: shmobile: allow non-SMP builds again

> Wasn't this fixed by > > Commit: 869ec056fa8450184423c8076e0a342db127795c Ooops, yes. Sorry, overlooked this new 'if' after rebasing from rc1 to rd/master :( signature.asc Description: PGP signature

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

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> --- arch/arm/mach-shmobile/setup-r8a7790.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-shmobile/setup-r

[PATCH 2/2] ARM: shmobile: r8a7791: only use smp_init when SMP is selected

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> --- arch/arm/mach-shmobile/setup-r8a7791.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-shmobile/setup-r

[RFC] ARM: shmobile: allow non-SMP builds again

platform_can_secondary_boot() is only available for SMP, so guard the smp_init function with some ifdeffery to allow building without SMP. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- This is the easiest solution, but I wonder if it is the proper one? It might make

Re: [PATCH v2] ARM: dts: r8a7794: Correct SDHI register size

; > Signed-off-by: Simon Horman <horms+rene...@verge.net.au> Reviewed-by: Wolfram Sang <wsa+rene...@sang-engineering.com> signature.asc Description: PGP signature

Re: [PATCH] clk: renesas: r8a7795: Fix SD clocks

On Wed, Jul 20, 2016 at 02:06:24PM +0200, Wolfram Sang wrote: > > > Wolfram, Dirk: any comments? > > Looks proper. > > Reviewed-by: Wolfram Sang <wsa+rene...@sang-engineering.com> > > I couldn't really test it, though, since I still have problems with the >

[PATCH] arm64: dts: r8a7795: set maximum frequency for SDHI clocks

From: Wolfram Sang <wsa+rene...@sang-engineering.com> Define the upper limit otherwise the driver cannot utilize max speeds. Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- arch/arm64/boot/dts/renesas/r8a7795.dtsi | 4 1 file changed, 4 insertions(+) diff

Re: [PATCH] ARM: shmobile: r8a7794: tidyup SDHI register size on DTSI

> - reg = <0 0xee10 0 0x200>; > + reg = <0 0xee10 0 0x384>; All other r8a779x.dtsi have 0x328 there. signature.asc Description: PGP signature

Re: [PATCH] clk: renesas: r8a7795: Fix SD clocks

> Wolfram, Dirk: any comments? Looks proper. Reviewed-by: Wolfram Sang <wsa+rene...@sang-engineering.com> I couldn't really test it, though, since I still have problems with the Gen3 DMA series. signature.asc Description: PGP signature

Re: [PATCH/RFC 0/4] mmc: renesas_sdhi: add R-Car Gen-3 DMA support

> git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git > topic/sdhi-gen3-dma Strange, with this branch and the attached config, the driver fails to register to the driver core?? Reverting this series, the driver gets registered (and probed) again. # # Automatically generated file;

Re: [PATCH 3/3] arm64: dts: r8a7795: salvator: enable UHS for SDHI 0 & 3

> Could you kindly share the recent status of the MMC support for RCar3? Esp. > the eMMC support on the Salvator-X? From time to time I get this question > from several people ;) Nothing changed since last time. Meaning that it could work in 4-bit mode (haven't tested it, though, and am on the

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

> The first SDHI channel (ee10.sd) doesn't seem to be affected > by the problem. Hmm, I sadly don't have any docs about 73a4 and/or its SDHI variants. I'll ask around. signature.asc Description: PGP signature

Re: [PATCH 00/11] media: rcar-vin: fix OPS and format/pad index issues

ing capabilites. But since rebinding was a major motivation for this series to be factored out of a bigger one: Tested-by: Wolfram Sang <wsa+rene...@sang-engineering.com> signature.asc Description: PGP signature

[RFC 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

[RFC 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

[RFC 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

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

. A branch can be found here: git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/topic/sdhi-autocmd12-resp Thanks and all the best, Wolfram Wolfram Sang (4): mmc: host: tmio: use defines for CTL_STOP_INTERNAL_ACTION values mmc: host: tmio: fix minor typos in a comment

[RFC 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 v2] watchdog: softdog: make pretimeout support a compile option

explicitly. This also removes the overhead if pretimeout support is not used because it will now be compiled away (saving ~10% on ARM32). Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com> --- Change since V1: * use IS_DEFINED as if-conditions, removing the need for #ifdef I have to

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

detect logic. > > Signed-off-by: Chris Brandt <chris.bra...@renesas.com> Reviewed-by: Wolfram Sang <wsa+rene...@sang-engineering.com> signature.asc Description: PGP signature

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

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