[linux-sunxi] Final discussion on a dedicated thermal sensor driver for Allwinner H3/A64/H5/A83T/R40

2017-05-09 Thread icenowy 

Hi everyone,
I think we still need to discuss on a thermal sensor driver on some
Allwinner SoCs (specially, H3/A64/H5/A83T/R40).

These SoCs seem to have already a stable design of thermal sensor,
which can easily add or remove several thermal channels (H3 has
only one thermal channel, H5 2, other SoCs 3). Note: older SoCs'
GPADC or thermal sensor has never more than 1 thermal channel.

Maxime has already said to reject a dedicated driver, however
I still think it more appropriate to have a dedicated driver,
because:
1. Current driver is an IIO-based driver that registers a thermal zone,
   which is a mixture of two different driver architectures. They are
   acceptable for a real general purpose ADC that contains thermal part,
   but not acceptable for a real thermal-only sensor.
   See [1]. For a thermal zone-based thermal driver, a thermal zone for
   it is necessary; however, here Maxime considered it a IIO driver and
   assumes that "The thermal zone itself shouldn't even be in this
   patch", but without this thermal zone defined the thermal zone part
   will directly refuse to probe.
2. The newer generation SoCs really have already stable design, that
   has not changed in already 5 SoC designs. (And the still unknown
   SUN8IW10 design (B288?) also uses this version of thermal sensor,
   so this number should be at least 6)
3. The designs have changed a lot so that the initialization code could
   be hardly shared. See [2], which has more than a half of
   initialization code rewritten.
4. Newer designs have the capability to have multiple sensor channels,
   which could not be dealed with current drivers now, and will be a
   rewrite disaster if we keep the IIO & thermal two framework design,
   which will make the code fragemented and difficult to maintain
   (it will give people a feeling that we forced two drivers with some
   similar functionalities to be a driver).
5. In the situation of R40, a old-style GPADC(RTP?) and a new-style
   thermal sensor co-exists. That could indicate that they're different
   designs and the new-style thermal sensor is better than the
   integrated thermal sensor in the GPADC.

So I think a dedicated driver is still better, which will be placed at
drivers/thermal and be shared among new-generation thermal sensor,
even if the thermal sensor seems to be a modified version of old design.
It's changed enough to have a dedicated driver.

That will largely reduce the maintaince difficulty of both drivers.
We are not sharing code for sharing code, we are sharing code for easier
maintaince. The share of code between two kinds of THS is much smaller
than the burden brought by the code sharing, and with a dedicated 
driver,

the MFD and IIO maintainers can see less code that should originally
go to thermal framework.

P.S. Maybe the A33 thermal sensor also shouldn't go into IIO framework,
for the first reason mentioned above.

Thanks,
Icenowy

[1] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/498758.html
[2] 
http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/498694.html


--
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.

Re: [linux-sunxi] [PATCH v6 11/13] ARM: dts: sun8i: add DE2 nodes for V3s SoC

2017-05-09 Thread Maxime Ripard 
1;4601;0c
On Fri, May 05, 2017 at 08:34:16PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2017年5月5日 GMT+08:00 下午8:30:35, Maxime Ripard 
>  写到:
> >On Fri, May 05, 2017 at 04:53:43PM +0800, icen...@aosc.io wrote:
> >> > > +   de2_clocks: clock@100 {
> >> > > +   compatible =
> >"allwinner,sun50i-h5-de2-clk";
> >> > 
> >> > I am a bit skeptical about this. Since the V3S only has one mixer,
> >do
> >> > the clocks
> >> > for the second one even exist?
> >> 
> >> It's described in the de_clock.c in the BSP source code, and in
> >hardware
> >> these bits can be really set (although without clock output).
> >> 
> >> So I use this compatible which has still the extra clocks.
> >
> >If it's not usable, then it shouldn't be in the code, it's basically
> >dead code.
> 
> Thus should we have one more DE2 CCU compatible without mixer1
> clocks for V3s?

If those clocks don't exist on v3s, then yes.

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 v6 08/13] drm/sun4i: add support for Allwinner DE2 mixers

2017-05-09 Thread Maxime Ripard 
On Fri, May 05, 2017 at 08:39:31PM +0800, Icenowy Zheng wrote:
> >> > > +  /* Set base coordinates */
> >> > > +  DRM_DEBUG_DRIVER("Layer coordinates X: %d Y: %d\n",
> >> > > +   state->crtc_x, state->crtc_y);
> >> > > +  regmap_write(mixer->engine.regs,
> >> > > +   SUN8I_MIXER_CHAN_UI_LAYER_COORD(chan, layer),
> >> > > +   SUN8I_MIXER_COORD(state->crtc_x, state->crtc_y));
> >> > 
> >> > X and Y are fixed point numbers. You want to keep only the higher
> >16
> >> > bits there.
> >> 
> >> Do you mean "lower 16 bits"? Thus should I (x & 0x) or ((u16)x) ?
> >
> >Nevermind, I got confused with src_x and src_y.
> >
> >> P.S. The negative coordinates are broken, how should I deal with it?
> >or
> >> is the coordinates promised to be not negative?
> >
> >Adjust the buffer base address, and use a shorter line. You have such
> >an example in the sun4i code.
> 
> Are they these two lines:
> ```
> paddr += (state->src_x >> 16) * bpp;
> paddr += (state->src_y >> 16) * fb->pitches[0];
> ```
> 
> I think I copied them here, so I don't need to mind this problem any
> more, right?

Hmmm, yes, probably. That's pretty easy to test anyway, you just need
to set up a plane with a negative base coordinate.

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 11/12] sunxi: add LPDDR3 timing from stock boot0

2017-05-09 Thread Icenowy Zheng 


于 2017年5月10日 GMT+08:00 上午7:44:21, "André Przywara"  写到:
>On 26/04/17 15:50, Icenowy Zheng wrote:
>> From: Icenowy Zheng 
>> 
>> As we added LPDDR3 support in the former patch, we need a set of
>timing
>> info to really enable it.
>> 
>> Add the timing info used by stock boot0.
>
>When I checked the disassembly/decompile for the Pine64 libdram, I
>found
>some more registers differing when DRAM type is 7 (LPDDR3), mostly in
>mctl_channel_init(). I can send patches on top of this series to set
>those bits.
>Does it work reliably for you with this series?

Yes, tested on a SoPine w/ baseboard and a Pinebook.

>
>More below ...
>
>> Signed-off-by: Icenowy Zheng 
>> ---
>>  arch/arm/mach-sunxi/dram_timings/Makefile   |  1 +
>>  arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c | 84
>+
>>  board/sunxi/Kconfig |  7 +++
>>  3 files changed, 92 insertions(+)
>>  create mode 100644 arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c
>> 
>> diff --git a/arch/arm/mach-sunxi/dram_timings/Makefile
>b/arch/arm/mach-sunxi/dram_timings/Makefile
>> index a4c9dc556c..278a8a14cc 100644
>> --- a/arch/arm/mach-sunxi/dram_timings/Makefile
>> +++ b/arch/arm/mach-sunxi/dram_timings/Makefile
>> @@ -1,2 +1,3 @@
>>  obj-$(CONFIG_SUNXI_DRAM_DDR3_1333)  += ddr3_1333.o
>> +obj-$(CONFIG_SUNXI_DRAM_LPDDR3_STOCK)   += lpddr3_stock.o
>>  obj-$(CONFIG_SUNXI_DRAM_DDR2_V3S)   += ddr2_v3s.o
>> diff --git a/arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c
>b/arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c
>> new file mode 100644
>> index 00..1085efe48e
>> --- /dev/null
>> +++ b/arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c
>> @@ -0,0 +1,84 @@
>> +#include 
>> +#include 
>> +#include 
>> +
>> +void mctl_set_timing_params(uint16_t socid, struct dram_para *para)
>> +{
>> +struct sunxi_mctl_ctl_reg * const mctl_ctl =
>> +(struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
>> +
>> +u8 tccd = 2;
>> +u8 tfaw = max(ns_to_t(50), 4);
>> +u8 trrd = max(ns_to_t(10), 2);
>> +u8 trcd = max(ns_to_t(24), 2);
>> +u8 trc  = ns_to_t(70);
>> +u8 txp  = max(ns_to_t(8), 2);
>> +u8 twtr = max(ns_to_t(8), 2);
>> +u8 trtp = max(ns_to_t(8), 2);
>> +u8 twr  = max(ns_to_t(15), 3);
>> +u8 trp  = max(ns_to_t(27), 2);
>> +u8 tras = ns_to_t(42);
>> +u16 trefi   = ns_to_t(3900) / 32;
>> +u16 trfc= ns_to_t(210);
>
>Where do those values come from?
>
>> +
>> +u8 tmrw = 5;
>> +u8 tmrd = 5;
>> +u8 tmod = 12;
>> +u8 tcke = 3;
>> +u8 tcksrx   = 5;
>> +u8 tcksre   = 5;
>> +u8 tckesr   = 5;
>> +u8 trasmax  = 24;
>> +
>> +u8 tcl  = 6; /* CL 12 */
>> +u8 tcwl = 3; /* CWL 6 */
>> +u8 t_rdata_en   = 5;
>> +u8 wr_latency   = 2;
>> +
>> +u32 tdinit0 = (200 * CONFIG_DRAM_CLK) + 1;  /* 200us */
>> +u32 tdinit1 = (100 * CONFIG_DRAM_CLK) / 1000 + 1;   /* 100ns */
>> +u32 tdinit2 = (11 * CONFIG_DRAM_CLK) + 1;   /* 11us */
>> +u32 tdinit3 = (1 * CONFIG_DRAM_CLK) + 1;/* 1us */
>> +
>> +u8 twtp = tcwl + 4 + twr + 1;
>> +u8 twr2rd   = tcwl + 4 + 1 + twtr;
>> +u8 trd2wr   = tcl + 4 + 5 - tcwl + 1;
>> +
>> +/* set mode register */
>
>I found explanations for the mode registers in the datasheet for the
>PineBook DRAM, so:
>
>> +writel(0, _ctl->mr[0]);
>
>According to the datasheet (and generic LPDDR3 docs) this register is
>read-only, so we don't need to write this at all.
>
>> +writel(0xc3, _ctl->mr[1]);
>
>Can you add: /* nWR=8, BL8 */ to document the magic value?
>
>> +writel(0xa, _ctl->mr[2]);  /* CWL=6 */
>
>Can you change this comment to: /* RL=12, WL=6 */ ?
>Also according to the datasheet for 533 MHz we can go with RL=8 and
>WL=4, which would encode as "0x6". Maybe worth experimenting with, or
>adding as a TODO.
>
>> +writel(0x2, _ctl->mr[3]);
>
>Can you add: /* 40 Ohms PD/PU */ ?
>
>> +
>> +/* set DRAM timing */
>> +writel(DRAMTMG0_TWTP(twtp) | DRAMTMG0_TFAW(tfaw) |
>> +   DRAMTMG0_TRAS_MAX(trasmax) | DRAMTMG0_TRAS(tras),
>> +   _ctl->dramtmg[0]);
>> +writel(DRAMTMG1_TXP(txp) | DRAMTMG1_TRTP(trtp) | DRAMTMG1_TRC(trc),
>> +   _ctl->dramtmg[1]);
>> +writel(DRAMTMG2_TCWL(tcwl) | DRAMTMG2_TCL(tcl) |
>> +   DRAMTMG2_TRD2WR(trd2wr) | DRAMTMG2_TWR2RD(twr2rd),
>> +   _ctl->dramtmg[2]);
>> +writel(DRAMTMG3_TMRW(tmrw) | DRAMTMG3_TMRD(tmrd) |
>DRAMTMG3_TMOD(tmod),
>> +   _ctl->dramtmg[3]);
>> +writel(DRAMTMG4_TRCD(trcd) | DRAMTMG4_TCCD(tccd) |
>DRAMTMG4_TRRD(trrd) |
>> +   DRAMTMG4_TRP(trp), _ctl->dramtmg[4]);
>> +writel(DRAMTMG5_TCKSRX(tcksrx) | DRAMTMG5_TCKSRE(tcksre) |
>> +

[linux-sunxi] Re: [PATCH 11/12] sunxi: add LPDDR3 timing from stock boot0

2017-05-09 Thread André Przywara 
On 26/04/17 15:50, Icenowy Zheng wrote:
> From: Icenowy Zheng 
> 
> As we added LPDDR3 support in the former patch, we need a set of timing
> info to really enable it.
> 
> Add the timing info used by stock boot0.

When I checked the disassembly/decompile for the Pine64 libdram, I found
some more registers differing when DRAM type is 7 (LPDDR3), mostly in
mctl_channel_init(). I can send patches on top of this series to set
those bits.
Does it work reliably for you with this series?

More below ...

> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/mach-sunxi/dram_timings/Makefile   |  1 +
>  arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c | 84 
> +
>  board/sunxi/Kconfig |  7 +++
>  3 files changed, 92 insertions(+)
>  create mode 100644 arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c
> 
> diff --git a/arch/arm/mach-sunxi/dram_timings/Makefile 
> b/arch/arm/mach-sunxi/dram_timings/Makefile
> index a4c9dc556c..278a8a14cc 100644
> --- a/arch/arm/mach-sunxi/dram_timings/Makefile
> +++ b/arch/arm/mach-sunxi/dram_timings/Makefile
> @@ -1,2 +1,3 @@
>  obj-$(CONFIG_SUNXI_DRAM_DDR3_1333)   += ddr3_1333.o
> +obj-$(CONFIG_SUNXI_DRAM_LPDDR3_STOCK)+= lpddr3_stock.o
>  obj-$(CONFIG_SUNXI_DRAM_DDR2_V3S)+= ddr2_v3s.o
> diff --git a/arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c 
> b/arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c
> new file mode 100644
> index 00..1085efe48e
> --- /dev/null
> +++ b/arch/arm/mach-sunxi/dram_timings/lpddr3_stock.c
> @@ -0,0 +1,84 @@
> +#include 
> +#include 
> +#include 
> +
> +void mctl_set_timing_params(uint16_t socid, struct dram_para *para)
> +{
> + struct sunxi_mctl_ctl_reg * const mctl_ctl =
> + (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
> +
> + u8 tccd = 2;
> + u8 tfaw = max(ns_to_t(50), 4);
> + u8 trrd = max(ns_to_t(10), 2);
> + u8 trcd = max(ns_to_t(24), 2);
> + u8 trc  = ns_to_t(70);
> + u8 txp  = max(ns_to_t(8), 2);
> + u8 twtr = max(ns_to_t(8), 2);
> + u8 trtp = max(ns_to_t(8), 2);
> + u8 twr  = max(ns_to_t(15), 3);
> + u8 trp  = max(ns_to_t(27), 2);
> + u8 tras = ns_to_t(42);
> + u16 trefi   = ns_to_t(3900) / 32;
> + u16 trfc= ns_to_t(210);

Where do those values come from?

> +
> + u8 tmrw = 5;
> + u8 tmrd = 5;
> + u8 tmod = 12;
> + u8 tcke = 3;
> + u8 tcksrx   = 5;
> + u8 tcksre   = 5;
> + u8 tckesr   = 5;
> + u8 trasmax  = 24;
> +
> + u8 tcl  = 6; /* CL 12 */
> + u8 tcwl = 3; /* CWL 6 */
> + u8 t_rdata_en   = 5;
> + u8 wr_latency   = 2;
> +
> + u32 tdinit0 = (200 * CONFIG_DRAM_CLK) + 1;  /* 200us */
> + u32 tdinit1 = (100 * CONFIG_DRAM_CLK) / 1000 + 1;   /* 100ns */
> + u32 tdinit2 = (11 * CONFIG_DRAM_CLK) + 1;   /* 11us */
> + u32 tdinit3 = (1 * CONFIG_DRAM_CLK) + 1;/* 1us */
> +
> + u8 twtp = tcwl + 4 + twr + 1;
> + u8 twr2rd   = tcwl + 4 + 1 + twtr;
> + u8 trd2wr   = tcl + 4 + 5 - tcwl + 1;
> +
> + /* set mode register */

I found explanations for the mode registers in the datasheet for the
PineBook DRAM, so:

> + writel(0, _ctl->mr[0]);

According to the datasheet (and generic LPDDR3 docs) this register is
read-only, so we don't need to write this at all.

> + writel(0xc3, _ctl->mr[1]);

Can you add: /* nWR=8, BL8 */ to document the magic value?

> + writel(0xa, _ctl->mr[2]);  /* CWL=6 */

Can you change this comment to: /* RL=12, WL=6 */ ?
Also according to the datasheet for 533 MHz we can go with RL=8 and
WL=4, which would encode as "0x6". Maybe worth experimenting with, or
adding as a TODO.

> + writel(0x2, _ctl->mr[3]);

Can you add: /* 40 Ohms PD/PU */ ?

> +
> + /* set DRAM timing */
> + writel(DRAMTMG0_TWTP(twtp) | DRAMTMG0_TFAW(tfaw) |
> +DRAMTMG0_TRAS_MAX(trasmax) | DRAMTMG0_TRAS(tras),
> +_ctl->dramtmg[0]);
> + writel(DRAMTMG1_TXP(txp) | DRAMTMG1_TRTP(trtp) | DRAMTMG1_TRC(trc),
> +_ctl->dramtmg[1]);
> + writel(DRAMTMG2_TCWL(tcwl) | DRAMTMG2_TCL(tcl) |
> +DRAMTMG2_TRD2WR(trd2wr) | DRAMTMG2_TWR2RD(twr2rd),
> +_ctl->dramtmg[2]);
> + writel(DRAMTMG3_TMRW(tmrw) | DRAMTMG3_TMRD(tmrd) | DRAMTMG3_TMOD(tmod),
> +_ctl->dramtmg[3]);
> + writel(DRAMTMG4_TRCD(trcd) | DRAMTMG4_TCCD(tccd) | DRAMTMG4_TRRD(trrd) |
> +DRAMTMG4_TRP(trp), _ctl->dramtmg[4]);
> + writel(DRAMTMG5_TCKSRX(tcksrx) | DRAMTMG5_TCKSRE(tcksre) |
> +DRAMTMG5_TCKESR(tckesr) | DRAMTMG5_TCKE(tcke),
> +_ctl->dramtmg[5]);

As this block is the same as for DDR3, I wonder if it's worth factoring
this out. But this may be part of a future rework.

Cheers,
Andre

> +

[linux-sunxi] Re: [PATCH 05/12] sunxi: Add selective DRAM type and timing

2017-05-09 Thread André Przywara 
On 26/04/17 15:50, Icenowy Zheng wrote:
> From: Icenowy Zheng 
> 
> DRAM chip varies, and one code cannot satisfy all DRAMs.
> 
> Add options to select a timing set.
> 
> Currently only DDR3-1333 (the original set) is added into it.

Confirmed that this just moves the code, no changes in the actual
parameters. Given that the code doesn't change upstream meanwhile:

> Signed-off-by: Icenowy Zheng 

Reviewed-by: Andre Przywara 

Thanks!
Andre

> ---
>  arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h |  30 ++
>  arch/arm/mach-sunxi/Makefile|   1 +
>  arch/arm/mach-sunxi/dram_sunxi_dw.c | 119 
> ++--
>  arch/arm/mach-sunxi/dram_timings/Makefile   |   1 +
>  arch/arm/mach-sunxi/dram_timings/ddr3_1333.c|  87 +
>  board/sunxi/Kconfig |  18 
>  6 files changed, 143 insertions(+), 113 deletions(-)
>  create mode 100644 arch/arm/mach-sunxi/dram_timings/Makefile
>  create mode 100644 arch/arm/mach-sunxi/dram_timings/ddr3_1333.c
> 
> diff --git a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h 
> b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> index d301ac95c3..03fd46b724 100644
> --- a/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> +++ b/arch/arm/include/asm/arch-sunxi/dram_sunxi_dw.h
> @@ -205,4 +205,34 @@ struct sunxi_mctl_ctl_reg {
>  #define DXBDLR_WRITE_DELAY(x)((x) << 8)
>  #define DXBDLR_READ_DELAY(x) ((x) << 0)
>  
> +/*
> + * The delay parameters below allow to allegedly specify delay times of some
> + * unknown unit for each individual bit trace in each of the four data bytes
> + * the 32-bit wide access consists of. Also three control signals can be
> + * adjusted individually.
> + */
> +#define BITS_PER_BYTE8
> +#define NR_OF_BYTE_LANES (32 / BITS_PER_BYTE)
> +/* The eight data lines (DQn) plus DM, DQS and DQSN */
> +#define LINES_PER_BYTE_LANE  (BITS_PER_BYTE + 3)
> +struct dram_para {
> + u16 page_size;
> + u8 bus_full_width;
> + u8 dual_rank;
> + u8 row_bits;
> + u8 bank_bits;
> + const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
> + const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
> + const u8 ac_delays[31];
> +};
> +
> +static inline int ns_to_t(int nanoseconds)
> +{
> + const unsigned int ctrl_freq = CONFIG_DRAM_CLK / 2;
> +
> + return DIV_ROUND_UP(ctrl_freq * nanoseconds, 1000);
> +}
> +
> +void mctl_set_timing_params(uint16_t socid, struct dram_para *para);
> +
>  #endif /* _SUNXI_DRAM_SUN8I_H3_H */
> diff --git a/arch/arm/mach-sunxi/Makefile b/arch/arm/mach-sunxi/Makefile
> index 41cee26765..2a3c379b72 100644
> --- a/arch/arm/mach-sunxi/Makefile
> +++ b/arch/arm/mach-sunxi/Makefile
> @@ -49,5 +49,6 @@ obj-$(CONFIG_MACH_SUN8I_A23)+= dram_sun8i_a23.o
>  obj-$(CONFIG_MACH_SUN8I_A33) += dram_sun8i_a33.o
>  obj-$(CONFIG_MACH_SUN8I_A83T)+= dram_sun8i_a83t.o
>  obj-$(CONFIG_SUNXI_DRAM_DW)  += dram_sunxi_dw.o
> +obj-$(CONFIG_SUNXI_DRAM_DW)  += dram_timings/
>  obj-$(CONFIG_MACH_SUN9I) += dram_sun9i.o
>  endif
> diff --git a/arch/arm/mach-sunxi/dram_sunxi_dw.c 
> b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> index 3f54c8ee09..a5706423cb 100644
> --- a/arch/arm/mach-sunxi/dram_sunxi_dw.c
> +++ b/arch/arm/mach-sunxi/dram_sunxi_dw.c
> @@ -16,34 +16,6 @@
>  #include 
>  #include 
>  
> -/*
> - * The delay parameters below allow to allegedly specify delay times of some
> - * unknown unit for each individual bit trace in each of the four data bytes
> - * the 32-bit wide access consists of. Also three control signals can be
> - * adjusted individually.
> - */
> -#define BITS_PER_BYTE8
> -#define NR_OF_BYTE_LANES (32 / BITS_PER_BYTE)
> -/* The eight data lines (DQn) plus DM, DQS and DQSN */
> -#define LINES_PER_BYTE_LANE  (BITS_PER_BYTE + 3)
> -struct dram_para {
> - u16 page_size;
> - u8 bus_full_width;
> - u8 dual_rank;
> - u8 row_bits;
> - u8 bank_bits;
> - const u8 dx_read_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
> - const u8 dx_write_delays[NR_OF_BYTE_LANES][LINES_PER_BYTE_LANE];
> - const u8 ac_delays[31];
> -};
> -
> -static inline int ns_to_t(int nanoseconds)
> -{
> - const unsigned int ctrl_freq = CONFIG_DRAM_CLK / 2;
> -
> - return DIV_ROUND_UP(ctrl_freq * nanoseconds, 1000);
> -}
> -
>  static void mctl_phy_init(u32 val)
>  {
>   struct sunxi_mctl_ctl_reg * const mctl_ctl =
> @@ -269,90 +241,6 @@ static void mctl_set_master_priority(uint16_t socid)
>   }
>  }
>  
> -static void mctl_set_timing_params(uint16_t socid, struct dram_para *para)
> -{
> - struct sunxi_mctl_ctl_reg * const mctl_ctl =
> - (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
> -
> - u8 tccd = 2;
> - u8 tfaw = ns_to_t(50);
> - u8 trrd = max(ns_to_t(10), 4);
> - u8 trcd = ns_to_t(15);
> - u8 trc