> 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
Hi Wolfram,
On Tuesday, January 17, 2017, Wolfram Sang wrote:
> > I have no idea if the SDHI driver disables the module clock when it is
> > idle, but shouldn't the card detect clock be running all the time when
> > the driver is bound to the device?
>
> Yes, it should. And for all instances with
Hi Wolfram,
On Tuesday, January 17, 2017, Wolfram Sang wrote:
> > I have no idea if the SDHI driver disables the module clock when it is
> > idle, but shouldn't the card detect clock be running all the time when
> > the driver is bound to the device?
>
> Yes, it should. And for all instances with
Hi Wolfram,
On Tue, Jan 17, 2017 at 10:57 AM, Wolfram Sang wrote:
>> 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
> 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 to
Hi Wolfram,
On Tue, Jan 17, 2017 at 10:45 AM, Wolfram Sang wrote:
>> I have no idea if the SDHI driver disables the module clock when it is
>> idle, but shouldn't the card detect clock be running all the time when the
>> driver is bound to the device?
>
> Yes, it should. And for all instances wit
> I have no idea if the SDHI driver disables the module clock when it is
> idle, but shouldn't the card detect clock be running all the time when the
> driver is bound to the device?
Yes, it should. And for all instances with just one clock, this means
this main clock must be running. So, en-/dis
Hi Wolfram,
On Tue, Jan 17, 2017 at 9:21 AM, Wolfram Sang wrote:
>> 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
> 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 clock
Hi Wolfram and Geert,
On Monday, January 16, 2017, Wolfram Sang:
> > > and then in the code do:
> > >
> > > struct *cd_clk;
> > > cd_clk = devm_clk_get(&pdev->dev, "cd");
> > > if (cd_clk) {
> > > clk_prepare_enable(cd_clk);
> > > }
> > >
> > > (th
> > and then in the code do:
> >
> > struct *cd_clk;
> > cd_clk = devm_clk_get(&pdev->dev, "cd");
> > if (cd_clk) {
> > clk_prepare_enable(cd_clk);
> > }
> >
> > (this simple 1-line fix patch is getting a lot more complicated)
>
> Disclaimer: I do
Hi Chris,
CC Woflram
On Fri, Jan 13, 2017 at 6:56 PM, Chris Brandt wrote:
> On Friday, January 13, 2017, Geert Uytterhoeven wrote:
>> > In sh_mobile_sdhi.c, can we change sh_mobile_sdhi_probe() so that if
>> > there are 2 clocks specified (in DT or platform data), it
>> > automatically enables t
Hi Geert,
On Friday, January 13, 2017, Geert Uytterhoeven wrote:
> > In sh_mobile_sdhi.c, can we change sh_mobile_sdhi_probe() so that if
> > there are 2 clocks specified (in DT or platform data), it
> > automatically enables the 2nd clock (forever) and just uses the 1st
> clock as the on/off cloc
Hi Chris,
On Fri, Jan 13, 2017 at 6:16 PM, Chris Brandt wrote:
>> > But...that would make me think on boot it would be set to '01' (setting
>> > prohibited).
>>
>> Yeah, running with enabled SDHI core and disabled card detect sounds silly.
>
> I just did some testing and with only 1 clock enable
Hi Geert,
> > But...that would make me think on boot it would be set to '01' (setting
> > prohibited).
>
> Yeah, running with enabled SDHI core and disabled card detect sounds silly.
I just did some testing and with only 1 clock enabled ('01'), the core works but
card detect doesn't work. If y
Hi Chris,
On Fri, Jan 13, 2017 at 3:44 PM, Chris Brandt wrote:
> On Thursday, January 12, 2017, Geert Uytterhoeven wrote:
>> This is strange. There are two SDHI channels, but the STBCR12
>> documentation (all versions up to rev. 3.00) says the register has MSTP
>> bits for four SD host interfaces
Hi Geert,
On Thursday, January 12, 2017, Geert Uytterhoeven wrote:
> This is strange. There are two SDHI channels, but the STBCR12
> documentation (all versions up to rev. 3.00) says the register has MSTP
> bits for four SD host interfaces?
>
> Can you please enlighten me? Thanks!
If you look in
On Thu, Jan 12, 2017 at 08:34:26PM +, Chris Brandt wrote:
> Hi Geert,
>
> On Thursday, January 12, 2017, Geert Uytterhoeven wrote:
> > This is strange. There are two SDHI channels, but the STBCR12
> > documentation (all versions up to rev. 3.00) says the register has MSTP
> > bits for four SD
Hi Geert,
On Thursday, January 12, 2017, Geert Uytterhoeven wrote:
> This is strange. There are two SDHI channels, but the STBCR12
> documentation (all versions up to rev. 3.00) says the register has MSTP
> bits for four SD host interfaces?
>
> Can you please enlighten me? Thanks!
Ya, I saw that
Hi Chris,
On Thu, Jan 12, 2017 at 7:11 PM, Chris Brandt wrote:
> Now that all the clocks in the boot loader are disabled before booting
> the kernel, and the mstp driver has been fixed for RZ/A1, here is a typo
> that was missed during original testing.
>
> Fixes: 7c8522b7047c ("ARM: dts: r7s7210
20 matches
Mail list logo