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

2018-07-09 Thread Wolfram Sang
On Thu, Jul 05, 2018 at 04:18:37PM +0200, 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 small fixes, updated commit messages and rebased on latest
> mmc/next but Hayakawa-san did all the real work.

Thanks, Niklas! I will try to get them reviewed this week.



signature.asc
Description: PGP signature


Re: [PATCH 0/2] dma: sh: rcar-dmac: Add dma_pause operation

2018-07-09 Thread Vinod
On 02-07-18, 18:21, Yoshihiro Shimoda wrote:
> This patch set is based on the lasest slave-dma / next branch.
> 
> This issue can be reproduced by the following commands on r8a7795
> Salvator-XS with the fixed patch [1] and Windows Teraterm :) :
>  # stty 921600
>  (Change Teraterm baud rate)
>  # cat > rx.txt
>  (Send 5MiB file by Teraterm.)
>  # cmp  rx.txt
>  output "differ: byte N, line MMM"

Looks okay to me, Acks/tested-by..?

> 
> [1] https://patchwork.kernel.org/patch/10500775/
> 
> Yoshihiro Shimoda (2):
>   dma: sh: rcar-dmac: add a new function to clear CHCR.DE with barrier
>   dma: sh: rcar-dmac: Add dma_pause operation
> 
>  drivers/dma/sh/rcar-dmac.c | 27 +++
>  1 file changed, 23 insertions(+), 4 deletions(-)
> 
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
~Vinod


Re: [PATCH] dma: sh: rcar-dmac: avoid to write CHCR.TE to 1 if TCR is set to 0

2018-07-09 Thread Vinod
On 02-07-18, 18:18, Yoshihiro Shimoda wrote:
> This patch fixes an issue that unexpected retransfering happens
> if TCR is set to 0 before rcar_dmac_sync_tcr() writes DE bit to
> the CHCR register. For example, sh-sci driver can reproduce this
> issue like below:
> 
>  In rx_timer_fn():/* CHCR DE bit may be set to 1 */
>   dmaengine_tx_status()
>rcar_dmac_tx_status()
> rcar_dmac_chan_get_residue()
>  rcar_dmac_sync_tcr() /* TCR is possible to be set to 0 */
> 
> According to the description of commit 73a47bd0da66 ("dmaengine:
> rcar-dmac: use TCRB instead of TCR for residue"), "this buffered data
> will be transferred if CHCR::DE bit was cleared". So, this patch
> doesn't need to check TCRB register.
> 
> Fixes: 73a47bd0da66 ("dmaengine: rcar-dmac: use TCRB instead of TCR for 
> residue")
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  This patch is based on the latest slave-dma / fixes branch.
> 
>  This issue can be reproduced by the following commands on r8a7795
> Salvator-XS and Windows Teraterm :) :
>  # stty 921600
>  (Change Teraterm baud rate)
>  # cat > rx.txt
>  (Send 5MiB file by Teraterm. After a few minutes later, we cannot
>   input any commands by the serial console.)

Ack/tested-by ..?

> 
>  drivers/dma/sh/rcar-dmac.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 2a2ccd9..8305a1c 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -774,8 +774,9 @@ static void rcar_dmac_sync_tcr(struct rcar_dmac_chan 
> *chan)
>   /* make sure all remaining data was flushed */
>   rcar_dmac_chcr_de_barrier(chan);
>  
> - /* back DE */
> - rcar_dmac_chan_write(chan, RCAR_DMACHCR, chcr);
> + /* back DE if remain data exists */
> + if (rcar_dmac_chan_read(chan, RCAR_DMATCR))
> + rcar_dmac_chan_write(chan, RCAR_DMACHCR, chcr);
>  }
>  
>  static void rcar_dmac_chan_halt(struct rcar_dmac_chan *chan)
> -- 
> 1.9.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe dmaengine" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
~Vinod


Re: [PATCH v3] dmaengine: rcar-dmac: clear channel register when error

2018-07-09 Thread Vinod
On 03-07-18, 00:29, Kuninori Morimoto wrote:
> 
> From: Kuninori Morimoto 
> 
> We need to clear channel register in error case as recovery.
> The channel is already stopped in such case, thus we don't need to call
> rcar_dmac_chan_halt() before clearing.
> 
> rcar_dmac_chan_halt() will clear and confirm DE bit.
> But it will be failed because channel is already stopped in error case.
> In other words, we shouldn't call it then.

Applied, thanks

-- 
~Vinod


Re: [git pull] pinctrl: sh-pfc: Updates for v4.19

2018-07-09 Thread Linus Walleij
On Wed, Jul 4, 2018 at 11:45 AM Geert Uytterhoeven
 wrote:

> The following changes since commit ce397d215ccd07b8ae3f71db689aedb85d56ab40:
>
>   Linux 4.18-rc1 (2018-06-17 08:04:49 +0900)
>
> are available in the Git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git 
> tags/sh-pfc-for-v4.19-tag1
>
> for you to fetch changes up to a742fcf72902ed28f8836b8327cde50bebfb9ff1:
>
>   pinctrl: sh-pfc: r8a77990: Add USB3.0 pins, groups and functions 
> (2018-07-04 11:05:29 +0200)

Pulled into my "devel" branch, thanks for excellent work as usual!

Yours,
Linus Walleij


Re: [PATCH v2] pinctrl: sh-pfc: r8a77970: remove SH_PFC_PIN_CFG_DRIVE_STRENGTH flag

2018-07-09 Thread Linus Walleij
On Tue, Jul 3, 2018 at 5:19 PM Niklas Söderlund
 wrote:

> The datasheet does not document any registers to control drive strength,
> and no drive strength registers are for this reason described for this
> SoC. The flags indicating that drive strength can be controlled are
> however set for some pins in the driver.
>
> This leads to a NULL pointer dereference when the sh-pfc core tries to
> access the struct describing the drive strength registers, for example
> when reading the sysfs file pinconf-pins.
>
> Fix this by removing the SH_PFC_PIN_CFG_DRIVE_STRENGTH from all pins.
>
> Fixes: b92ac66a1819602b ("pinctrl: sh-pfc: Add R8A77970 PFC support")
> Signed-off-by: Niklas Söderlund 
> Reviewed-by: Simon Horman 
> Reviewed-by: Sergei Shtylyov 
> Reviewed-by: Geert Uytterhoeven 

Patch applied directly for fixes per Geert's suggestion.

Yours,
Linus Walleij


Re: [PATCH] ARM: dts: gr-peach: Add GR-Peach audiocamerashield support

2018-07-09 Thread Simon Horman
On Thu, Jul 05, 2018 at 06:00:42PM +0200, Simon Horman wrote:
> On Tue, Jul 03, 2018 at 10:41:09PM +0200, Jacopo Mondi wrote:
> > Add device tree header for GR-Peach's audiocamerashield with MT9V111
> > image sensor.
> > 
> > Signed-off-by: Jacopo Mondi 
> > ---
> > 
> > The GR-Peach audiocamera shield is an expansion board for the GR-Peach that
> > comes with an MT9V111 camera module.
> > 
> > https://www.core.co.jp/product/m2m/gr-peach/audio-camera.html
> > https://www.digikey.com/product-detail/en/renesas-electronics-america/YGRPEACHAUDIOCAMERASHIELD/YGRPEACHAUDIOCAMERASHIELD-ND/5800301
> > 
> > The series functionally depends on the already sent support for the MT9V111
> > sensor, but does not have any compile time dependency on it (a checkpatch
> > warning on the un-documented "aptina-mt9v111" compatible string apart).
> > 
> > https://lkml.org/lkml/2018/6/11/469
> > 
> > (copied the linux-media list to which I'll send a gentle ping for the
> > driver later ;)
> > 
> > Thanks
> >j
> > ---
> >  arch/arm/boot/dts/gr-peach-audiocamerashield.dtsi | 79 
> > +++
> >  1 file changed, 79 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/gr-peach-audiocamerashield.dtsi
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.

Thanks, applied.


Re: [PATCH 0/5] ARM: shmobile: defconfig: Miscellaneous updates

2018-07-09 Thread Simon Horman
On Thu, Jul 05, 2018 at 05:56:30PM +0200, Simon Horman wrote:
> On Wed, Jul 04, 2018 at 01:43:28PM +0200, Geert Uytterhoeven wrote:
> > Hi Simon, Magnus,
> > 
> > Here are a few updates for shmobile_defconfig, all fairly independant.
> > 
> > If accepted, I'll submit the corresponding changes for
> > multi_v7_defconfig.
> 
> Thanks,
> 
> This looks fine to me but I will wait to see if there are other reviews
> before applying.
> 
> Reviewed-by: Simon Horman 

Thanks Geert,

applied.


Re: [PATCH 5/5] ARM: shmobile: defconfig: Set CONFIG_LOCALVERSION

2018-07-09 Thread Simon Horman
On Fri, Jul 06, 2018 at 09:56:23AM +0200, Geert Uytterhoeven wrote:
> Hi Simon,
> 
> On Thu, Jul 5, 2018 at 5:55 PM Simon Horman  wrote:
> > On Wed, Jul 04, 2018 at 01:43:33PM +0200, Geert Uytterhoeven wrote:
> > > This allows to derive the kernel flavor from the kernel version at
> > > runtime.
> >
> > For my edification could you expand on what this is used for?
> 
> With this, the kernel version (as printed during boot, and returned by
> e.g. "uname -r") will be something like
> 
> 4.18.0-rc3-shmobile-02146-gd2f8e14acc47b8ea
> 
> instead of
> 
> dmesg-4.18.0-rc3
> 
> which makes it easy to differentiate them from
> 
> 4.18.0-rc3-koelsch-02146-gd2f8e14acc47b8ea
> 4.17.0-rc1-rcar2-initrd-00547-g19c9f87b5c449c23-dirty
> 
> which are built from my personal configs for Koelsch resp. R-Car Gen2
> with initrd.
> 
> > > Signed-off-by: Geert Uytterhoeven 
> 
> > > --- a/arch/arm/configs/shmobile_defconfig
> > > +++ b/arch/arm/configs/shmobile_defconfig
> > > @@ -1,3 +1,4 @@
> > > +CONFIG_LOCALVERSION="-shmobile"
> 
> We already have
> 
> CONFIG_LOCALVERSION="-arm64-renesas"
> 
> in arch/arm64/configs/renesas_defconfig, to differentiate kernels built
> from that config with kernels built from arm64 defconfig (which set it to
> "-arm64" in my local tree).
> 
> All of this makes it easy to keep e.g. a collection of boot logs using
> "dmesg > dmesg-$(uname -r)", and compare them.

Thanks, sounds good!


Re: [PATCH v2] dt-bindings: watchdog: renesas-wdt: Add support for the R8A77990 wdt

2018-07-09 Thread Geert Uytterhoeven
Hi Günter,

On Mon, Jul 9, 2018 at 12:43 AM Guenter Roeck  wrote:
> On 07/06/2018 01:55 AM, Geert Uytterhoeven wrote:
> > From: Masaharu Hayakawa 
> >
> > Document support for the Watchdog Timer (WDT) Controller in the Renesas
> > R-Car E3 (R8A77990) SoC.
> >
> > No driver update is needed.
> >
> > Signed-off-by: Masaharu Hayakawa 
> > Signed-off-by: Geert Uytterhoeven 
> > Reviewed-by: Guenter Roeck 
> > Acked-by: Rob Herring 
>
> The patch is queued in my tree, so there should be no need to resend it 
> anymore.

Thank you, I wasn't aware of that. Your last reply was "it doesn't apply",
and the patch is not in linux-watchdog-next.git.

Aha, it's in your linux-staging.git#watchdog-next.
Perhaps that should be documented in MAINTAINERS, and be included in
linux-next, too?

BTW, the git links on https://linux-watchdog.org/ give 404.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds