Re: [linux-sunxi] [PATCH v2 14/14] ARM: dts: sun8i: Enable DVFS on Orange Pi One

[Ondřej Jirman]

Hello Michal,

On 30.6.2016 13:13, Michal Suchanek wrote:
> Hello,
> 
> On 25 June 2016 at 05:45,   wrote:
>> From: Ondrej Jirman 
>>
>> Use Xulong Orange Pi One GPIO based regulator for
>> passive cooling and thermal management.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 39 
>> +
>>  1 file changed, 39 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> index b1bd6b0..a38d871 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> @@ -109,6 +109,45 @@
>> };
>>  };
>>
>> + {
>> +   operating-points = <
>> +   /* kHzuV */
>> +   1296000 130
>> +   120 130
> 
> First problem is that the board boots at 1008000 which is not listed
> and the kernel complains.
> 
> Second problem is that the board locks up during boot with this enabled.
> 
> Do you have some suggestion for alternate configuration to test?

I've identified the problem as incorrectly set up gpio-regulator. During
boot, when it was probed, it would be initiualized with 1.1V for a
moment. This caused random non-specific lockups/crashes afterwards.

Fixed patches are in my branch on github, if you want to try again.

  https://github.com/megous/linux/commits/orange-pi-4.7

regards,
  o.

> Thanks
> 
> Michal
> 

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

[linux-sunxi] Re: [PATCH v6] ARM: sun4i: spi: Allow transfers larger than FIFO size

[Mark Brown]

On Thu, Jul 21, 2016 at 07:27:12PM +0200, Michael Weiser wrote:
> On Thu, Jul 21, 2016 at 05:31:53PM +0100, Mark Brown wrote:

> > > What is keeping the patch from being merged (i.e. into mainline)?
> > Someone needs to address whatever review comments there were on the last
> > version and submit it.

> That's my point: There don't seem to be any.

> v6 was resend with fixes to checkpatch niggles on v5:
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/363073.html

I can't tell if that was even submitted, it's got a subject line of
"ARM: sun4i" so there's every chance that even if it was sent to me it
got deleted unread.  Whatever was going on it needs to be submited.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH v6] ARM: sun4i: spi: Allow transfers larger than FIFO size

[Mark Brown]

On Thu, Jul 21, 2016 at 08:03:16PM +0200, Olliver Schinagl wrote:
> As i recall, some claimed it was needed as we have dma now, but i think this 
> patch still scratches the same itch ...

Please don't top post, reply in line with needed context.  This allows
readers to readily follow the flow of conversation and understand what
you are talking about and also helps ensure that everything in the
discussion is being addressed.

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH v6] ARM: sun4i: spi: Allow transfers larger than FIFO size

[Olliver Schinagl]

As i recall, some claimed it was needed as we have dma now, but i think this 
patch still scratches the same itch ...

On July 21, 2016 7:27:12 PM CEST, Michael Weiser  wrote:
>Hi Mark,
>
>On Thu, Jul 21, 2016 at 05:31:53PM +0100, Mark Brown wrote:
>
>> > What is keeping the patch from being merged (i.e. into mainline)?
>> Someone needs to address whatever review comments there were on the
>last
>> version and submit it.
>
>That's my point: There don't seem to be any.
>
>v6 was resend with fixes to checkpatch niggles on v5:
>http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/363073.html
>
>v5 addressed comments by Maxime on v4:
>http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/244305.html
>http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/243995.html
>
>I can't find any comments on v5 or v6.
>-- 
>Thanks,
>Michael

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v6] ARM: sun4i: spi: Allow transfers larger than FIFO size

[Michael Weiser]

Hi Mark,

On Thu, Jul 21, 2016 at 05:31:53PM +0100, Mark Brown wrote:

> > What is keeping the patch from being merged (i.e. into mainline)?
> Someone needs to address whatever review comments there were on the last
> version and submit it.

That's my point: There don't seem to be any.

v6 was resend with fixes to checkpatch niggles on v5:
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-August/363073.html

v5 addressed comments by Maxime on v4:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-April/244305.html
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-March/243995.html

I can't find any comments on v5 or v6.
-- 
Thanks,
Michael

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Luke laptop is out

[Benjamin Henrion]

Luke laptop is out:

https://www.crowdsupply.com/eoma68/micro-desktop

--
Benjamin Henrion 
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v6] ARM: sun4i: spi: Allow transfers larger than FIFO size

[Mark Brown]

On Thu, Jul 21, 2016 at 01:27:01PM +0200, Michael Weiser wrote:

> What is keeping the patch from being merged (i.e. into mainline)?

Someone needs to address whatever review comments there were on the last
version and submit it.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH v6] ARM: sun4i: spi: Allow transfers larger than FIFO size

[Michael Weiser]

Hi all,

On Sat, Aug 08, 2015 at 09:41:51PM +0200, Olliver Schinagl wrote:

> Alexandru sent this patch over a year and a half ago, and I believe several
> tree's have been carrying it since. We've been using this patch on an
> Olimex OLinuxIno Lime1 and Lime2 using the mmc-spi driver to access SD cards
> without problems. So bumping this and adding my

I also have a need for this addition since it makes an ENC28J60 SPI
ethernet controller work on the Cubieboard2. I've successfully tested it
with 4.6.3 where it still applies cleanly.

(There's is a very minor conflict when applying against current Linus
master (EINVAL was changed to EMSGSIZE). I can supply a rebased version
if so desired.)

What is keeping the patch from being merged (i.e. into mainline)?

Thanks!
Michael

> Tested-by: Olliver Schinagl 

Tested-by: Michael Weiser 

> Changes from v5as warned by checkpatch. No functional changes.
>  * Added some newlines to make checkpatch happy. No functional changes.

> Changes from v4:
>  * use min3() instead of two if statements in sun4i_spi_fill_fifo()
>  * fix trivial whitespace issue in if statement in sun4i_spi_handler()
>  * use consistent style in assigning 'reg' in the added functions.

> Alexandru Gagniuc (1):
>   ARM: sun4i: spi: Allow transfers larger than FIFO size

>  drivers/spi/spi-sun4i.c | 76 
> +++--
>  1 file changed, 67 insertions(+), 9 deletions(-)
-- 
Thanks,
Michael

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

On 21.7.2016 11:48, Maxime Ripard wrote:
> On Fri, Jul 15, 2016 at 12:38:54PM +0200, Ondřej Jirman wrote:
>> On 15.7.2016 10:53, Maxime Ripard wrote:
>>> On Fri, Jul 01, 2016 at 02:50:57AM +0200, Ondřej Jirman wrote:
>>  /**
>> + * sun8i_h3_apply_pll1_factors() - applies n, k, m, p factors to the
>> + * register using an algorithm that tries to reserve the PLL lock
>> + */
>> +
>> +static void sun8i_h3_apply_pll1_factors(struct clk_factors *factors, 
>> struct factors_request *req)
>> +{
>> +const struct clk_factors_config *config = factors->config;
>> +u32 reg;
>> +
>> +/* Fetch the register value */
>> +reg = readl(factors->reg);
>> +
>> +if (FACTOR_GET(config->pshift, config->pwidth, reg) < req->p) {
>> +reg = FACTOR_SET(config->pshift, config->pwidth, reg, 
>> req->p);
>> +
>> +writel(reg, factors->reg);
>> +__delay(2000);
>> +}
>
> So there was some doubts about the fact that P was being used, or at
> least that it was useful.

 p is necessary to reduce frequencies below 288 MHz according to the
 datasheet.
>>>
>>> Yes, but you could reach those frequencies without P, too, and it's
>>> not part of any OPP provided by Allwinner.
>>
>> The arisc firmware for H3 contains table of factors for frequences from
>> 0 to 2GHz and, P is used below 240MHz. M is never used, BTW. (other
>> datasheets specify M as for testing use only, whatever that means - not
>> H3, but it seems it's the same PLL block)
> 
> Interesting. Which SoCs in particular?
> 
>> +if (FACTOR_GET(config->mshift, config->mwidth, reg) < req->m) {
>> +reg = FACTOR_SET(config->mshift, config->mwidth, reg, 
>> req->m);
>> +
>> +writel(reg, factors->reg);
>> +__delay(2000);
>> +}
>> +
>> +reg = FACTOR_SET(config->nshift, config->nwidth, reg, req->n);
>> +reg = FACTOR_SET(config->kshift, config->kwidth, reg, req->k);
>> +
>> +writel(reg, factors->reg);
>> +__delay(20);
>> +
>> +while (!(readl(factors->reg) & (1 << config->lock)));
>
> So, they are applying the dividers first, and then applying the
> multipliers, and then wait for the PLL to stabilize.

 Not exactly, first we are increasing dividers if the new dividers are
 higher that that what's already set. This ensures that because
 application of dividers is immediate by the design of the PLL, the
 application of multipliers isn't. So the VCO would still run at the same
 frequency for a while gradually rising to a new value for example,
 while the dividers would be reduced immediately. Leading to crash.

 PLL
 --
 PRE DIV(f0) -> VCO(f1) -> POST DIV(f2)
P K,N   M

 Example: (we set all factors at once, reducing dividers and multipliers
 at the same time at 0ms - this should lead to no change in the output
 frequency, but...)

 -1ms: f0 = 24MHz, f1 = 2GHz,   f2 = 1GHz
  0ms: f0 = 24MHz, f1 = 2GHz,   f2 = 2GHz   - boom
  1ms: f0 = 24MHz, f1 = 1.5GHz, f2 = 1.5GHz
  2ms: f0 = 24MHz, f1 = 1GHz,   f2 = 1GHz

 The current code crashes exactly at boom, you don't get any more
 instructions to execute.

 See.

 So this patch first increases dividers (only if necessary), changes
 multipliers and waits for change to happen (takes around 2000 cycles),
 and then decreases dividers (only if necessary).

 So we get:

 -1ms: f0 = 24MHz, f1 = 2GHz,   f2 = 1GHz
  0ms: f0 = 24MHz, f1 = 2GHz,   f2 = 1GHz   - no boom, multiplier
  reduced
  1ms: f0 = 24MHz, f1 = 1.5GHz, f2 = 0.75GHz
 1.9ms: f0 = 24MHz, f1 = 1GHz,   f2 = 0.5GHz - we got PLL sync
  2ms: f0 = 24MHz, f1 = 1GHz,   f2 = 1GHz   - and here we reduce divider
 at last
>>>
>>> Awesome explanation, thanks!
>>>
>>> So I guess it really all boils down to the fact that the CPU is
>>> clocked way outside of it's operating frequency while the PLL
>>> stabilizes, right?
>>
>> It may be, depending on the factors before and after change. I haven't
>> tested what factors the mainline kernel calculates for each frequency.
>> The arisc never uses M, and only uses P at frequencies that would not
>> allow for this behavior.
>>
>> I created a test program for arisc that runs a loop on the main CPU
>> using msgbox to send pings to the arisc CPU, and the vary the PLL1
>> randomly from the arisc, and haven't been able to lockup the main CPU
>> yet with either method.
>>
>> There's also AXI clock, that depends on PLL1. Arisc firmware uses the
>> same method to change it while changing CPUX clock. If the clock would
>> rise above certain frequency, AXI 

[linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Maxime Ripard]

On Fri, Jul 15, 2016 at 03:27:56PM +0200, Jean-Francois Moine wrote:
> On Fri, 15 Jul 2016 12:38:54 +0200
> Ondřej Jirman  wrote:
> 
> > > If so, then yes, trying to switch to the 24MHz oscillator before
> > > applying the factors, and then switching back when the PLL is stable
> > > would be a nice solution.
> > > 
> > > I just checked, and all the SoCs we've had so far have that
> > > possibility, so if it works, for now, I'd like to stick to that.
> > 
> > It would need to be tested. U-boot does the change only once, while the
> > kernel would be doing it all the time and between various frequencies
> > and PLL settings. So the issues may show up with this solution too.
> 
> I don't think this is a good idea: the CPU clock may be changed at any
> time with the CPUFreq governor. I don't see the system moving from
> 1008MHz to 24MHz and then to 1200MHz when some computation is needed!

It wouldn't happen that often. The sampling rate for the governor is
1000 times the latency, so, at most, 0.1% of the time would be spent
at 24MHz.

And if you're really concerned about performances, you won't enable
cpufreq anyway.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Maxime Ripard]

On Fri, Jul 15, 2016 at 12:38:54PM +0200, Ondřej Jirman wrote:
> On 15.7.2016 10:53, Maxime Ripard wrote:
> > On Fri, Jul 01, 2016 at 02:50:57AM +0200, Ondřej Jirman wrote:
>   /**
>  + * sun8i_h3_apply_pll1_factors() - applies n, k, m, p factors to the
>  + * register using an algorithm that tries to reserve the PLL lock
>  + */
>  +
>  +static void sun8i_h3_apply_pll1_factors(struct clk_factors *factors, 
>  struct factors_request *req)
>  +{
>  +const struct clk_factors_config *config = factors->config;
>  +u32 reg;
>  +
>  +/* Fetch the register value */
>  +reg = readl(factors->reg);
>  +
>  +if (FACTOR_GET(config->pshift, config->pwidth, reg) < req->p) {
>  +reg = FACTOR_SET(config->pshift, config->pwidth, reg, 
>  req->p);
>  +
>  +writel(reg, factors->reg);
>  +__delay(2000);
>  +}
> >>>
> >>> So there was some doubts about the fact that P was being used, or at
> >>> least that it was useful.
> >>
> >> p is necessary to reduce frequencies below 288 MHz according to the
> >> datasheet.
> > 
> > Yes, but you could reach those frequencies without P, too, and it's
> > not part of any OPP provided by Allwinner.
> 
> The arisc firmware for H3 contains table of factors for frequences from
> 0 to 2GHz and, P is used below 240MHz. M is never used, BTW. (other
> datasheets specify M as for testing use only, whatever that means - not
> H3, but it seems it's the same PLL block)

Interesting. Which SoCs in particular?

>  +if (FACTOR_GET(config->mshift, config->mwidth, reg) < req->m) {
>  +reg = FACTOR_SET(config->mshift, config->mwidth, reg, 
>  req->m);
>  +
>  +writel(reg, factors->reg);
>  +__delay(2000);
>  +}
>  +
>  +reg = FACTOR_SET(config->nshift, config->nwidth, reg, req->n);
>  +reg = FACTOR_SET(config->kshift, config->kwidth, reg, req->k);
>  +
>  +writel(reg, factors->reg);
>  +__delay(20);
>  +
>  +while (!(readl(factors->reg) & (1 << config->lock)));
> >>>
> >>> So, they are applying the dividers first, and then applying the
> >>> multipliers, and then wait for the PLL to stabilize.
> >>
> >> Not exactly, first we are increasing dividers if the new dividers are
> >> higher that that what's already set. This ensures that because
> >> application of dividers is immediate by the design of the PLL, the
> >> application of multipliers isn't. So the VCO would still run at the same
> >> frequency for a while gradually rising to a new value for example,
> >> while the dividers would be reduced immediately. Leading to crash.
> >>
> >> PLL
> >> --
> >> PRE DIV(f0) -> VCO(f1) -> POST DIV(f2)
> >>P K,N   M
> >>
> >> Example: (we set all factors at once, reducing dividers and multipliers
> >> at the same time at 0ms - this should lead to no change in the output
> >> frequency, but...)
> >>
> >> -1ms: f0 = 24MHz, f1 = 2GHz,   f2 = 1GHz
> >>  0ms: f0 = 24MHz, f1 = 2GHz,   f2 = 2GHz   - boom
> >>  1ms: f0 = 24MHz, f1 = 1.5GHz, f2 = 1.5GHz
> >>  2ms: f0 = 24MHz, f1 = 1GHz,   f2 = 1GHz
> >>
> >> The current code crashes exactly at boom, you don't get any more
> >> instructions to execute.
> >>
> >> See.
> >>
> >> So this patch first increases dividers (only if necessary), changes
> >> multipliers and waits for change to happen (takes around 2000 cycles),
> >> and then decreases dividers (only if necessary).
> >>
> >> So we get:
> >>
> >> -1ms: f0 = 24MHz, f1 = 2GHz,   f2 = 1GHz
> >>  0ms: f0 = 24MHz, f1 = 2GHz,   f2 = 1GHz   - no boom, multiplier
> >>  reduced
> >>  1ms: f0 = 24MHz, f1 = 1.5GHz, f2 = 0.75GHz
> >> 1.9ms: f0 = 24MHz, f1 = 1GHz,   f2 = 0.5GHz - we got PLL sync
> >>  2ms: f0 = 24MHz, f1 = 1GHz,   f2 = 1GHz   - and here we reduce divider
> >> at last
> > 
> > Awesome explanation, thanks!
> > 
> > So I guess it really all boils down to the fact that the CPU is
> > clocked way outside of it's operating frequency while the PLL
> > stabilizes, right?
> 
> It may be, depending on the factors before and after change. I haven't
> tested what factors the mainline kernel calculates for each frequency.
> The arisc never uses M, and only uses P at frequencies that would not
> allow for this behavior.
> 
> I created a test program for arisc that runs a loop on the main CPU
> using msgbox to send pings to the arisc CPU, and the vary the PLL1
> randomly from the arisc, and haven't been able to lockup the main CPU
> yet with either method.
> 
> There's also AXI clock, that depends on PLL1. Arisc firmware uses the
> same method to change it while changing CPUX clock. If the clock would
> rise above certain frequency, AXI divider is increased before the PLL1
> change. If it would fall 

[linux-sunxi] Re: [PATCH 2/3] mmc: sunxi: Set the 'New Timing' register for 8 bits DDR transfers

[Jean-Francois Moine]

On Thu, 21 Jul 2016 10:56:15 +0200
Maxime Ripard  wrote:

> On Wed, Jul 20, 2016 at 08:16:28PM +0200, Jean-Francois Moine wrote:
> > The 'new timing mode' with 8 bits DDR works correctly when the NewTiming
> > register is set.
> 
> What does that mode brings to the table?

>From my tests, the eMMC of the Banana Pi M3 (A83T) cannot work when the
new mode is not used.

> > 
> > Signed-off-by: Jean-Francois Moine 
> > ---
> > Note about the 'new timing mode'.
> > 
> > This patch assumes that, when the new mode is used, the clock driver
> > sets the mode select in the MMC clock and multiplies the clock rate
> > by 2:
> > - MMC side:
> >   - with a timing 8 bits DDR at 50MHz, the MMC driver calls
> > clk_set_rate() with a rate 50*2 = 100MHz,
> > - clock side:
> >   - the clock driver sets the hardware MMC clock to 100*2 = 200MHz,
> >   - setting the 'mode select' of the hardware MMC clock divides the
> > rate by 2,
> > - MMC side:
> >   - setting the MMC clock divider register to 1 divides the rate by 2.
> > So, the final rate is 50MHz.
> 
> What happens if you actually want to set it to 100MHz?

There is no SDXC_CLK_100M in the mainline driver, and 100MHz is asked
only for 8 bits DDR at 50MHz.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 3/3] mmc: sunxi: Add support to the Allwinner A83T

[Jean-Francois Moine]

On Thu, 21 Jul 2016 10:58:38 +0200
Maxime Ripard  wrote:

> On Wed, Jul 20, 2016 at 08:28:47PM +0200, Jean-Francois Moine wrote:
> > The rate of the PLL-PERIPH clock is usually set to 1.2GHz in the A83T.
> 
> Uh? The datasheet says to set it to 600MHz.

Right. But the driver of the SDK for the Banana Pi M3 (A83T) sets it
to 1.2GHz.

> > This patch sets the phase delays of the output and sample clocks
> > accordingly.
> > 
> > Signed-off-by: Jean-Francois Moine 
> > ---
> > Note: The impacted phase delays are only for 50MHz.
> > The phase delays are not used in 50MHz 8 bits DDR (new timing mode).
> 
> Actually, they seem to be, in the new timing mode register.

In the SDK driver, nothing is set in the new timing mode register.
Anyway, the eMMC works fine in both the Banana Pis M2+ and M3
with no delay.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 3/3] mmc: sunxi: Add support to the Allwinner A83T

[Maxime Ripard]

Maxime

On Wed, Jul 20, 2016 at 08:28:47PM +0200, Jean-Francois Moine wrote:
> The rate of the PLL-PERIPH clock is usually set to 1.2GHz in the A83T.

Uh? The datasheet says to set it to 600MHz.

> This patch sets the phase delays of the output and sample clocks
> accordingly.
> 
> Signed-off-by: Jean-Francois Moine 
> ---
> Note: The impacted phase delays are only for 50MHz.
> The phase delays are not used in 50MHz 8 bits DDR (new timing mode).

Actually, they seem to be, in the new timing mode register.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 2/3] mmc: sunxi: Set the 'New Timing' register for 8 bits DDR transfers

[Maxime Ripard]

Hi,

On Wed, Jul 20, 2016 at 08:16:28PM +0200, Jean-Francois Moine wrote:
> The 'new timing mode' with 8 bits DDR works correctly when the NewTiming
> register is set.

What does that mode brings to the table?

> 
> Signed-off-by: Jean-Francois Moine 
> ---
> Note about the 'new timing mode'.
> 
> This patch assumes that, when the new mode is used, the clock driver
> sets the mode select in the MMC clock and multiplies the clock rate
> by 2:
> - MMC side:
>   - with a timing 8 bits DDR at 50MHz, the MMC driver calls
> clk_set_rate() with a rate 50*2 = 100MHz,
> - clock side:
>   - the clock driver sets the hardware MMC clock to 100*2 = 200MHz,
>   - setting the 'mode select' of the hardware MMC clock divides the
> rate by 2,
> - MMC side:
>   - setting the MMC clock divider register to 1 divides the rate by 2.
> So, the final rate is 50MHz.

What happens if you actually want to set it to 100MHz?

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 1/3] mmc: sunxi: Check the value returned by clk_round_rate

[Maxime Ripard]

On Wed, Jul 20, 2016 at 08:01:47PM +0200, Jean-Francois Moine wrote:
> clk_round_rate() may return an error. Check it.
> 
> Signed-off-by: Jean-Francois Moine 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] [PATCH 2/3] mmc: sunxi: Set the 'New Timing' register for 8 bits DDR transfers

[Jean-Francois Moine]

The 'new timing mode' with 8 bits DDR works correctly when the NewTiming
register is set.

Signed-off-by: Jean-Francois Moine 
---
Note about the 'new timing mode'.

This patch assumes that, when the new mode is used, the clock driver
sets the mode select in the MMC clock and multiplies the clock rate
by 2:
- MMC side:
  - with a timing 8 bits DDR at 50MHz, the MMC driver calls
clk_set_rate() with a rate 50*2 = 100MHz,
- clock side:
  - the clock driver sets the hardware MMC clock to 100*2 = 200MHz,
  - setting the 'mode select' of the hardware MMC clock divides the
rate by 2,
- MMC side:
  - setting the MMC clock divider register to 1 divides the rate by 2.
So, the final rate is 50MHz.

For this to work, the clock driver must know when the 'mode select'
is used.
Instead of using a new special clock function, in my driver, the
'mode select' capable clocks are declared as such with an associated
rate (actually, mmc2 in A83T, and mmc{1,2} in H3).
When this rate is asked for (100MHz), the mode select is set.
This works without change in the MMC driver. If a 100MHz rate would be
used without 'mode select' for such clocks, an other mechanism should
be found (information in the low bits of the rate?).
---
 drivers/mmc/host/sunxi-mmc.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index ba647b7..7f9c31a 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -64,6 +64,7 @@
 #define SDXC_REG_CBCR  (0x48) /* SMC CIU Byte Count Register */
 #define SDXC_REG_BBCR  (0x4C) /* SMC BIU Byte Count Register */
 #define SDXC_REG_DBGC  (0x50) /* SMC Debug Enable Register */
+#define SDXC_REG_NTSR  (0x5c) /* SMC NewTiming Set Register */
 #define SDXC_REG_HWRST (0x78) /* SMC Card Hardware Reset for Register */
 #define SDXC_REG_DMAC  (0x80) /* SMC IDMAC Control Register */
 #define SDXC_REG_DLBA  (0x84) /* SMC IDMAC Descriptor List Base Addre */
@@ -171,6 +172,9 @@
 #define SDXC_SEND_AUTO_STOPCCSDBIT(9)
 #define SDXC_CEATA_DEV_IRQ_ENABLE  BIT(10)
 
+/* NewTiming Set Register */
+#define SDXC_NEWMODE_ENABLEBIT(31)
+
 /* IDMA controller bus mod bit field */
 #define SDXC_IDMAC_SOFT_RESET  BIT(0)
 #define SDXC_IDMAC_FIX_BURST   BIT(1)
@@ -661,10 +665,20 @@ static int sunxi_mmc_clk_set_rate(struct sunxi_mmc_host 
*host,
u32 clock = ios->clock;
int ret;
 
-   /* 8 bit DDR requires a higher module clock */
-   if (ios->timing == MMC_TIMING_MMC_DDR52 &&
-   ios->bus_width == MMC_BUS_WIDTH_8)
-   clock <<= 1;
+   /*
+* 8 bit DDR requires a higher module clock
+* and the 'new mode'
+*/
+   if (ios->bus_width == MMC_BUS_WIDTH_8) {/* eMMC */
+   rval = mmc_readl(host, REG_NTSR);
+   if (ios->timing == MMC_TIMING_MMC_DDR52) {
+   clock <<= 1;
+   rval |= SDXC_NEWMODE_ENABLE;
+   } else {
+   rval &= ~SDXC_NEWMODE_ENABLE;
+   }
+   mmc_writel(host, REG_NTSR, rval);
+   }
 
rate = clk_round_rate(host->clk_mmc, clock);
if (rate < 0) {
-- 
2.9.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] [PATCH 3/3] mmc: sunxi: Add support to the Allwinner A83T

[Jean-Francois Moine]

The rate of the PLL-PERIPH clock is usually set to 1.2GHz in the A83T.
This patch sets the phase delays of the output and sample clocks
accordingly.

Signed-off-by: Jean-Francois Moine 
---
Note: The impacted phase delays are only for 50MHz.
The phase delays are not used in 50MHz 8 bits DDR (new timing mode).
---
 drivers/mmc/host/sunxi-mmc.c | 11 +++
 1 file changed, 11 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 7f9c31a..e161a64 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -961,6 +961,7 @@ static int sunxi_mmc_card_busy(struct mmc_host *mmc)
 static const struct of_device_id sunxi_mmc_of_match[] = {
{ .compatible = "allwinner,sun4i-a10-mmc", },
{ .compatible = "allwinner,sun5i-a13-mmc", },
+   { .compatible = "allwinner,sun8i-a83t-mmc", },
{ .compatible = "allwinner,sun9i-a80-mmc", },
{ /* sentinel */ }
 };
@@ -986,6 +987,14 @@ static const struct sunxi_mmc_clk_delay 
sunxi_mmc_clk_delays[] = {
[SDXC_CLK_50M_DDR_8BIT] = { .output =  90, .sample = 180 },
 };
 
+static const struct sunxi_mmc_clk_delay sun8i_a83t_mmc_clk_delays[] = {
+   [SDXC_CLK_400K] = { .output = 180, .sample = 180 },
+   [SDXC_CLK_25M]  = { .output = 180, .sample =  75 },
+   [SDXC_CLK_50M]  = { .output =  90, .sample = 105 },
+   [SDXC_CLK_50M_DDR]  = { .output =  60, .sample = 120 },
+   [SDXC_CLK_50M_DDR_8BIT] = { .output =  180, .sample = 180 },
+};
+
 static const struct sunxi_mmc_clk_delay sun9i_mmc_clk_delays[] = {
[SDXC_CLK_400K] = { .output = 180, .sample = 180 },
[SDXC_CLK_25M]  = { .output = 180, .sample =  75 },
@@ -1007,6 +1016,8 @@ static int sunxi_mmc_resource_request(struct 
sunxi_mmc_host *host,
 
if (of_device_is_compatible(np, "allwinner,sun9i-a80-mmc"))
host->clk_delays = sun9i_mmc_clk_delays;
+   else if (of_device_is_compatible(np, "allwinner,sun8i-a83t-mmc"))
+   host->clk_delays = sun8i_a83t_mmc_clk_delays;
else
host->clk_delays = sunxi_mmc_clk_delays;
 
-- 
2.9.2

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 3/5] ARM: sun8i: dt: Add DT bindings documentation for Allwinner sun8i-emac

[Maxime Ripard]

Hi,

On Wed, Jul 20, 2016 at 10:03:18AM +0200, LABBE Corentin wrote:
> This patch adds documentation for Device-Tree bindings for the
> Allwinner sun8i-emac driver.
> 
> Signed-off-by: LABBE Corentin 
> ---
>  .../bindings/net/allwinner,sun8i-emac.txt  | 65 
> ++
>  1 file changed, 65 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
> 
> diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt 
> b/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
> new file mode 100644
> index 000..4bf4e53
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-emac.txt
> @@ -0,0 +1,65 @@
> +* Allwinner sun8i EMAC ethernet controller
> +
> +Required properties:
> +- compatible: "allwinner,sun8i-a83t-emac", "allwinner,sun8i-h3-emac",
> + or "allwinner,sun50i-a64-emac"
> +- reg: address and length of the register sets for the device.
> +- reg-names: should be "emac" and "syscon", matching the register sets

Blindly mapping a register of some other device on the SoC doesn't
look very reasonable.

> +- interrupts: interrupt for the device
> +- clocks: A phandle to the reference clock for this device
> +- clock-names: should be "ahb"
> +- resets: A phandle to the reset control for this device
> +- reset-names: should be "ahb"
> +- phy-mode: See ethernet.txt
> +- phy or phy-handle: See ethernet.txt
> +- #address-cells: shall be 1
> +- #size-cells: shall be 0
> +
> +"allwinner,sun8i-h3-emac" also requires:
> +- clocks: an extra phandle to the reference clock for the EPHY
> +- clock-names: an extra "ephy" entry matching the clocks property
> +- resets: an extra phandle to the reset control for the EPHY
> +- resets-names: an extra "ephy" entry matching the resets property

Shouldn't that be attached to the phy itself?

> +See ethernet.txt in the same directory for generic bindings for ethernet
> +controllers.
> +
> +The device node referenced by "phy" or "phy-handle" should be a child node
> +of this node. See phy.txt for the generic PHY bindings.
> +
> +Optional properties:
> +- phy-supply: phandle to a regulator if the PHY needs one
> +- phy-io-supply: phandle to a regulator if the PHY needs a another one for 
> I/O.
> +  This is sometimes found with RGMII PHYs, which use a second
> +  regulator for the lower I/O voltage.
> +- allwinner,tx-delay: The setting of the TX clock delay chain
> +- allwinner,rx-delay: The setting of the RX clock delay chain

In which unit? What is the default value?

> +
> +The TX/RX clock delay chain settings are board specific.
> +
> +Optional properties for "allwinner,sun8i-h3-emac":
> +- allwinner,use-internal-phy: Use the H3 SoC's internal E(thernet) PHY

Can't that be derived from the presence of the phy property?

> +- allwinner,leds-active-low: EPHY LEDs are active low

That also seems PHY related. Overall, I feel like we really need a phy
node for the internal phy.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature