[RFC 0/6] mmc: sdhi: add basic r8a7795 support

[RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Wolfram Sang]

So, I started working on the SDHI part. Since Dirk seems to be working on the
clocks already (thanks!), I evaluated the patches for the mmc-subsystem and
refactored the subset which gets the basic functionality run. A few cleanups
were applied, too. The patches are RFC because I want to check one more issue
(restore clock settings after software reset) and also I need to do Gen2
regression testing. However, release early, I wanted to show you what I am
hacking on here. A branch for testing (with Dirk's clock patches and DTS
additions can be found here):

git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/v8-sdhi-nodma

Further testing much appreciated. It works fine on my Salvator using SD cards
on both, SDHI0 and SDHI3. Simple testing, though, no stress testing yet.

Thanks,

   Wolfram


Shinobu Uehara (1):
  mmc: sdhi: Add EXT_ACC register busy check

Wolfram Sang (5):
  mmc: sdhi: error message on ENOMEM is superfluous
  mmc: tmio: add flag to reduce delay after changing clock status
  mmc: tmio: remove stale comments
  mmc: sdhi: use faster clock handling on RCar Gen2
  mmc: sdhi: Add r8a7795 support

 Documentation/devicetree/bindings/mmc/tmio_mmc.txt |  1 +
 drivers/mmc/host/Kconfig                           |  2 +-
 drivers/mmc/host/sh_mobile_sdhi.c                  | 54 +++++++++++++++-------
 drivers/mmc/host/tmio_mmc_pio.c                    |  7 +--
 include/linux/mfd/tmio.h                           |  4 ++
 5 files changed, 45 insertions(+), 23 deletions(-)

-- 
2.1.4

Re: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Dirk Behme]

Hi Wolfgang,

On 19.01.2016 17:20, Wolfram Sang wrote:
> So, I started working on the SDHI part. Since Dirk seems to be working on the
> clocks already (thanks!), I evaluated the patches for the mmc-subsystem and
> refactored the subset which gets the basic functionality run. A few cleanups
> were applied, too. The patches are RFC because I want to check one more issue
> (restore clock settings after software reset) and also I need to do Gen2
> regression testing. However, release early, I wanted to show you what I am
> hacking on here. A branch for testing (with Dirk's clock patches and DTS
> additions can be found here):
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/v8-sdhi-nodma
>
> Further testing much appreciated. It works fine on my Salvator using SD cards
> on both, SDHI0 and SDHI3. Simple testing, though, no stress testing yet.


Many thanks for working on this! I'll have a look to it, maybe next week.

Just fyi, some general remarks, what's my recent status:

First, regarding the clocks, if anybody from the experts could advise 
me how we'd like to interface dynamic clocks to the existing Gen3 
clock code, that would be really welcome:

http://marc.info/?l=linux-sh&m\x145302405811953


Second, I'm mainly interested in eMMC support for the Salvator-X. 
Therefore I picked (hopefully) all patches from the Renesas BSP to 
renesas-drivers-2016-01-13-v4.4

https://github.com/dirkbehme/linux-renesas-rcar-gen3/commits/dirk/gen3-latest-update

I compared the Renesas BSP code in drivers/mmc with that version, it's 
the same. However, this branch crashes more or less immediately after 
successfully detecting the eMMC in various core kernel parts. This 
happens as soon as I enable the eMMC in the device tree. It looks to 
me like a DMA issue, because I'd think the errors are in core kernel 
code which is fine, so I'd suspect some memory overwriting. But what 
confuses me is that the same code works fine on the the 4.2 based 
Renesas BSP. I have no idea regarding this, yet.

And third, from reading the r8a7795 manual I think the manual talks about

https://github.com/dirkbehme/linux-renesas-rcar-gen3/commit/f2a727c859916d59dca85dbb72c1b61da3fd6da0

But testing this it doesn't work. So either the manual is wrong, or I 
missed anything else.

Best regards

Dirk

Re: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

Hi Dirk,

> First, regarding the clocks, if anybody from the experts could advise me how
> we'd like to interface dynamic clocks to the existing Gen3 clock code, that
> would be really welcome:

I am not the clock expert, but I try to have a look next week.

> Second, I'm mainly interested in eMMC support for the Salvator-X. Therefore

OK, nice to know. I have eMMC running now, without DMA and HS200, of
course. My patches need some refactoring, though.

> I picked (hopefully) all patches from the Renesas BSP to
> renesas-drivers-2016-01-13-v4.4

Yes, that's where I picked your clock patches from :)

> so I'd suspect some memory overwriting. But what confuses me is that the
> same code works fine on the the 4.2 based Renesas BSP. I have no idea
> regarding this, yet.

I usually don't have high hopes that putting more than a trivial amount
of any BSP code on top of upstream will result in success ;)

My obviuos plan is to work incrementally. First basic support, then DMA,
then UHS-I/HS200. Review, refactor existing patches. Upstream first, etc
pp... You know all this, I guess.

> And third, from reading the r8a7795 manual I think the manual talks about
> 
> https://github.com/dirkbehme/linux-renesas-rcar-gen3/commit/f2a727c859916d59dca85dbb72c1b61da3fd6da0
> 
> But testing this it doesn't work. So either the manual is wrong, or I missed
> anything else.

I have seen this patch and my gut feeling is that it won't make a
difference? SCLKDIVEN is like CBUSY plus some more cycles AFAIU. But I
am not working on DMA issues now, this has to wait.

Kind regards,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Yoshihiro Shimoda]

Hi Dirk-san, Wolfram-san,

> > And third, from reading the r8a7795 manual I think the manual talks about
> >
> > https://github.com/dirkbehme/linux-renesas-rcar-gen3/commit/f2a727c859916d59dca85dbb72c1b61da3fd6da0
> >
> > But testing this it doesn't work. So either the manual is wrong, or I missed
> > anything else.
> 
> I have seen this patch and my gut feeling is that it won't make a
> difference? SCLKDIVEN is like CBUSY plus some more cycles AFAIU. But I
> am not working on DMA issues now, this has to wait.

I'm not sure we have to use CBSY bit instead of SCLKDIVEN on r8a7795.
However, I could use the CBSY bit if I used the following code.

	while (--timeout && (sd_ctrl_read16(host, CTL_STATUS2) & (1 << 14)))

If we use the CBSY bit, I think we have to wait while the CBSY bit is set to 1.
(In other words, the behavior of CBSY bit is different from the SCLKDIVEN bit if my understanding is correct.)

Best regards,
Yoshihiro Shimoda

Re: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Dirk Behme]

Hi Wolfram,

On 19.01.2016 17:20, Wolfram Sang wrote:
> So, I started working on the SDHI part. Since Dirk seems to be working on the
> clocks already (thanks!), I evaluated the patches for the mmc-subsystem and
> refactored the subset which gets the basic functionality run. A few cleanups
> were applied, too. The patches are RFC because I want to check one more issue
> (restore clock settings after software reset) and also I need to do Gen2
> regression testing. However, release early, I wanted to show you what I am
> hacking on here.


I've looked over it and from my limited knowledge point of view it looks 
good. Thanks!

I'd say that patches 2/6 and 4/6 are mainly independent on r8a7795 
support and could be sent without RFC.

I'm not sure if my knowledge is enough to give an Acked-by or 
Reviewed-by, though ;)

Best regards

Dirk

Re: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Dirk Behme]

On 22.01.2016 11:32, Yoshihiro Shimoda wrote:
> Hi Dirk-san, Wolfram-san,
>
>>> And third, from reading the r8a7795 manual I think the manual talks about
>>>
>>> https://github.com/dirkbehme/linux-renesas-rcar-gen3/commit/f2a727c859916d59dca85dbb72c1b61da3fd6da0
>>>
>>> But testing this it doesn't work. So either the manual is wrong, or I missed
>>> anything else.
>>
>> I have seen this patch and my gut feeling is that it won't make a
>> difference? SCLKDIVEN is like CBUSY plus some more cycles AFAIU. But I
>> am not working on DMA issues now, this has to wait.
>
> I'm not sure we have to use CBSY bit instead of SCLKDIVEN on r8a7795.


The r8a7795 manual I have has several

"Do / Do not xxx when the CBSY bit in SD_INFO2 is set to x"

It always talks about CBSY, not SCLKDIVEN.

Best regards

Dirk

Re: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Dirk Behme]

Hi Wolfram,

On 22.01.2016 09:54, Wolfram Sang wrote:
> Hi Dirk,
>
>> First, regarding the clocks, if anybody from the experts could advise me how
>> we'd like to interface dynamic clocks to the existing Gen3 clock code, that
>> would be really welcome:
>
> I am not the clock expert, but I try to have a look next week.


I'll try to post a proposal for the SD clock, soon.


>> Second, I'm mainly interested in eMMC support for the Salvator-X. Therefore
>
> OK, nice to know. I have eMMC running now, without DMA and HS200, of
> course. My patches need some refactoring, though.
>
>> I picked (hopefully) all patches from the Renesas BSP to
>> renesas-drivers-2016-01-13-v4.4
>
> Yes, that's where I picked your clock patches from :)
>
>> so I'd suspect some memory overwriting. But what confuses me is that the
>> same code works fine on the the 4.2 based Renesas BSP. I have no idea
>> regarding this, yet.
>
> I usually don't have high hopes that putting more than a trivial amount
> of any BSP code on top of upstream will result in success ;)


I was at least hoping that the differences between the 4.2 BSP and the 
recent 4.4 development head are not that large that it would be possible 
"to make it work" picking that patches.

You are right, upstreaming them is an other topic, then ;)

Best regards

Dirk

Re: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 217 bytes --]


> I'm not sure if my knowledge is enough to give an Acked-by or Reviewed-by,
> though ;)

What about Tested-by? :) However, I'll send out an improved series on
Monday, so it probably makes sense to wait for that...


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

RE: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Yoshihiro Shimoda]

> From: Dirk Behme
> Sent: Friday, January 22, 2016 8:31 PM
> 
> On 22.01.2016 11:32, Yoshihiro Shimoda wrote:
> > Hi Dirk-san, Wolfram-san,
> >
> >>> And third, from reading the r8a7795 manual I think the manual talks about
> >>>
> >>> https://github.com/dirkbehme/linux-renesas-rcar-gen3/commit/f2a727c859916d59dca85dbb72c1b61da3fd6da0
> >>>
> >>> But testing this it doesn't work. So either the manual is wrong, or I missed
> >>> anything else.
> >>
> >> I have seen this patch and my gut feeling is that it won't make a
> >> difference? SCLKDIVEN is like CBUSY plus some more cycles AFAIU. But I
> >> am not working on DMA issues now, this has to wait.
> >
> > I'm not sure we have to use CBSY bit instead of SCLKDIVEN on r8a7795.
> 
> 
> The r8a7795 manual I have has several
> 
> "Do / Do not xxx when the CBSY bit in SD_INFO2 is set to x"
> 
> It always talks about CBSY, not SCLKDIVEN.

Thank you for the detail. I agree with you about r8a7795.
However, on previous SoC, it doesn't have CBSY bit.
So, I guess we have to keep compatible for previous SoC somehow.

Best regards,
Yoshihiro Shimoda

> Best regards
> 
> Dirk

Re: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Dirk Behme]

On 25.01.2016 09:51, Yoshihiro Shimoda wrote:
>> From: Dirk Behme
>> Sent: Friday, January 22, 2016 8:31 PM
>>
>> On 22.01.2016 11:32, Yoshihiro Shimoda wrote:
>>> Hi Dirk-san, Wolfram-san,
>>>
>>>>> And third, from reading the r8a7795 manual I think the manual talks about
>>>>>
>>>>> https://github.com/dirkbehme/linux-renesas-rcar-gen3/commit/f2a727c859916d59dca85dbb72c1b61da3fd6da0
>>>>>
>>>>> But testing this it doesn't work. So either the manual is wrong, or I missed
>>>>> anything else.
>>>>
>>>> I have seen this patch and my gut feeling is that it won't make a
>>>> difference? SCLKDIVEN is like CBUSY plus some more cycles AFAIU. But I
>>>> am not working on DMA issues now, this has to wait.
>>>
>>> I'm not sure we have to use CBSY bit instead of SCLKDIVEN on r8a7795.
>>
>>
>> The r8a7795 manual I have has several
>>
>> "Do / Do not xxx when the CBSY bit in SD_INFO2 is set to x"
>>
>> It always talks about CBSY, not SCLKDIVEN.
>
> Thank you for the detail. I agree with you about r8a7795.
> However, on previous SoC, it doesn't have CBSY bit.
> So, I guess we have to keep compatible for previous SoC somehow.


Yes, ack.

I've been thinking about implementing a "delay callback", which waits 
for bit 13 on previous SoCs and for bit 14 for r8a7795.

But I haven't looked into the details, yet. Maybe there is an easier 
solution.

Best regards

Dirk

Re: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Dirk Behme]

On 25.01.2016 10:08, Dirk Behme wrote:
> On 25.01.2016 09:51, Yoshihiro Shimoda wrote:
>>> From: Dirk Behme
>>> Sent: Friday, January 22, 2016 8:31 PM
>>>
>>> On 22.01.2016 11:32, Yoshihiro Shimoda wrote:
>>>> Hi Dirk-san, Wolfram-san,
>>>>
>>>>>> And third, from reading the r8a7795 manual I think the manual
>>>>>> talks about
>>>>>>
>>>>>> https://github.com/dirkbehme/linux-renesas-rcar-gen3/commit/f2a727c859916d59dca85dbb72c1b61da3fd6da0
>>>>>>
>>>>>>
>>>>>> But testing this it doesn't work. So either the manual is wrong,
>>>>>> or I missed
>>>>>> anything else.
>>>>>
>>>>> I have seen this patch and my gut feeling is that it won't make a
>>>>> difference? SCLKDIVEN is like CBUSY plus some more cycles AFAIU.
>>>>> But I
>>>>> am not working on DMA issues now, this has to wait.
>>>>
>>>> I'm not sure we have to use CBSY bit instead of SCLKDIVEN on r8a7795.
>>>
>>>
>>> The r8a7795 manual I have has several
>>>
>>> "Do / Do not xxx when the CBSY bit in SD_INFO2 is set to x"
>>>
>>> It always talks about CBSY, not SCLKDIVEN.
>>
>> Thank you for the detail. I agree with you about r8a7795.
>> However, on previous SoC, it doesn't have CBSY bit.
>> So, I guess we have to keep compatible for previous SoC somehow.
>
>
> Yes, ack.
>
> I've been thinking about implementing a "delay callback", which waits
> for bit 13 on previous SoCs and for bit 14 for r8a7795.


Thinking about this, is there a runtime detection of r8a7795 vs. 
previous SoCs? Anything like a function or macro e.g. is_system_gen3() 
or similar?

Best regards

Dirk

Re: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 189 bytes --]


> I've been thinking about implementing a "delay callback", which waits for
> bit 13 on previous SoCs and for bit 14 for r8a7795.

Does it make a difference for you? I thought it didn't?


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Geert Uytterhoeven]

Hi Dirk,

On Mon, Jan 25, 2016 at 5:25 PM, Dirk Behme <dirk.behme@gmail.com> wrote:
>> I've been thinking about implementing a "delay callback", which waits
>> for bit 13 on previous SoCs and for bit 14 for r8a7795.
>
> Thinking about this, is there a runtime detection of r8a7795 vs. previous
> SoCs? Anything like a function or macro e.g. is_system_gen3() or similar?

The proper way to handle this is to make the driver match against
"renesas,sdhi-r8a7795", cfr. sh_mobile_sdhi_of_match[].

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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

Re: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Dirk Behme]

Hi Wolfram,

On 25.01.2016 20:24, Wolfram Sang wrote:
>
>> I've been thinking about implementing a "delay callback", which waits for
>> bit 13 on previous SoCs and for bit 14 for r8a7795.
>
> Does it make a difference for you? I thought it didn't?


Well, if the manual tells us to use CBSY (bit 14), I think it's a good 
idea to do so and not to use anything else.

Best regards

Dirk

Re: [RFC 0/6] mmc: sdhi: add basic r8a7795 support

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 151 bytes --]


> Well, if the manual tells us to use CBSY (bit 14), I think it's a good idea
> to do so and not to use anything else.

I'll try to find out more...


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]