Hi Wolfram,
On Fri, Apr 15, 2016 at 10:41 PM, 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 need MSTP clocks
On Sun, Apr 17, 2016 at 2:49 PM, Wolfram Sang wrote:
> 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
>> > >
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 need MSTP clocks which do not use
> > 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
> > 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
On Fri, Apr 1, 2016 at 5:44 PM, Wolfram Sang wrote:
> From: Ben Hutchings
>
> Currently tmio_mmc assumes that the input clock frequency is fixed and
> only its own clock divider can be changed. This is not true in the
> case of sh_mobile_sdhi;
From: Ben Hutchings
Currently tmio_mmc assumes that the input clock frequency is fixed and
only its own clock divider can be changed. This is not true in the
case of sh_mobile_sdhi; we can use the clock API to change it.
In tmio_mmc:
- Delegate setting of f_min