Re: [linux-sunxi] Re: [PATCH 5/8] sunxi: Add clock support for DE2/HDMI/TCON on newer SoCs

['Ondřej Jirman' via linux-sunxi]

Hi,

Dne 14.3.2017 v 07:53 Jernej Škrabec napsal(a):
> Hi,
> 
> Dne ponedeljek, 13. marec 2017 ob 13:33:43 CET je Simon Glass napisal(a):
>> Hi,
>>
>> On 8 March 2017 at 16:34, Jernej Skrabec  wrote:
>>> This is needed for HDMI, which will be added later.
>>>
>>> Signed-off-by: Jernej Skrabec 
>>> ---
>>>
>>>  arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 54
>>>  +++ arch/arm/mach-sunxi/clock_sun6i.c   
>>>   | 40 +++- drivers/video/sunxi/lcdc.c   
>>>  |  4 ++
>>>  include/configs/sun50i.h  |  2 +
>>>  include/configs/sun8i.h   |  4 ++
>>>  scripts/config_whitelist.txt  |  1 +
>>>  6 files changed, 104 insertions(+), 1 deletion(-)
>>
>> Reviewed-by: Simon Glass 
>>
>> Please see below.
>>
>>> diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
>>> b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h index
>>> 1aefd5a64c..ebb642747b 100644
>>> --- a/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
>>> +++ b/arch/arm/include/asm/arch-sunxi/clock_sun6i.h
>>> @@ -67,13 +67,22 @@ struct sunxi_ccm_reg {
>>>
>>> u32 dram_pll_cfg;   /* 0xf8 PLL_DDR cfg register, A33 only */
>>> u32 mbus_reset; /* 0xfc MBUS reset control, A33 only */
>>> u32 dram_clk_gate;  /* 0x100 DRAM module gating */
>>>
>>> +#ifdef CONFIG_SUNXI_DE2
>>> +   u32 de_clk_cfg; /* 0x104 DE module clock */
>>> +#else
>>>
>>> u32 be0_clk_cfg;/* 0x104 BE0 module clock */
>>>
>>> +#endif
>>>
>>> u32 be1_clk_cfg;/* 0x108 BE1 module clock */
>>> u32 fe0_clk_cfg;/* 0x10c FE0 module clock */
>>> u32 fe1_clk_cfg;/* 0x110 FE1 module clock */
>>> u32 mp_clk_cfg; /* 0x114 MP module clock */
>>>
>>> +#ifdef CONFIG_SUNXI_DE2
>>> +   u32 lcd0_clk_cfg;   /* 0x118 LCD0 module clock */
>>> +   u32 lcd1_clk_cfg;   /* 0x11c LCD1 module clock */
>>> +#else
>>>
>>> u32 lcd0_ch0_clk_cfg;   /* 0x118 LCD0 CH0 module clock */
>>> u32 lcd1_ch0_clk_cfg;   /* 0x11c LCD1 CH0 module clock */
>>>
>>> +#endif
>>>
>>> u32 reserved14[3];
>>> u32 lcd0_ch1_clk_cfg;   /* 0x12c LCD0 CH1 module clock */
>>> u32 lcd1_ch1_clk_cfg;   /* 0x130 LCD1 CH1 module clock */
>>>
>>> @@ -85,7 +94,11 @@ struct sunxi_ccm_reg {
>>>
>>> u32 dmic_clk_cfg;   /* 0x148 Digital Mic module clock*/
>>> u32 reserved15;
>>> u32 hdmi_clk_cfg;   /* 0x150 HDMI module clock */
>>>
>>> +#ifdef CONFIG_SUNXI_DE2
>>> +   u32 hdmi_slow_clk_cfg;  /* 0x154 HDMI slow module clock */
>>> +#else
>>>
>>> u32 ps_clk_cfg; /* 0x154 PS module clock */
>>>
>>> +#endif
>>>
>>> u32 mtc_clk_cfg;/* 0x158 MTC module clock */
>>> u32 mbus0_clk_cfg;  /* 0x15c MBUS0 module clock */
>>> u32 mbus1_clk_cfg;  /* 0x160 MBUS1 module clock */
>>>
>>> @@ -193,6 +206,7 @@ struct sunxi_ccm_reg {
>>>
>>>  #define CCM_PLL3_CTRL_N_MASK   (0x7f << CCM_PLL3_CTRL_N_SHIFT)
>>>  #define CCM_PLL3_CTRL_N(n) n) - 1) & 0x7f) << 8)
>>>  #define CCM_PLL3_CTRL_INTEGER_MODE (0x1 << 24)
>>>
>>> +#define CCM_PLL3_CTRL_LOCK (0x1 << 28)
>>>
>>>  #define CCM_PLL3_CTRL_EN   (0x1 << 31)
>>>  
>>>  #define CCM_PLL5_CTRL_M(n) n) - 1) & 0x3) << 0)
>>>
>>> @@ -222,6 +236,16 @@ struct sunxi_ccm_reg {
>>>
>>>  #define CCM_MIPI_PLL_CTRL_LDO_EN   (0x3 << 22)
>>>  #define CCM_MIPI_PLL_CTRL_EN   (0x1 << 31)
>>>
>>> +#define CCM_PLL10_CTRL_M_SHIFT 0
>>> +#define CCM_PLL10_CTRL_M_MASK  (0xf << CCM_PLL10_CTRL_M_SHIFT)
>>> +#define CCM_PLL10_CTRL_M(n)n) - 1) & 0xf) << 0)
>>> +#define CCM_PLL10_CTRL_N_SHIFT 8
>>> +#define CCM_PLL10_CTRL_N_MASK  (0x7f << CCM_PLL10_CTRL_N_SHIFT)
>>> +#define CCM_PLL10_CTRL_N(n)n) - 1) & 0x7f) << 8)
>>> +#define CCM_PLL10_CTRL_INTEGER_MODE(0x1 << 24)
>>> +#define CCM_PLL10_CTRL_LOCK(0x1 << 28)
>>> +#define CCM_PLL10_CTRL_EN  (0x1 << 31)
>>> +
>>>
>>>  #define CCM_PLL11_CTRL_N(n)n) - 1) & 0x3f) << 8)
>>>  #define CCM_PLL11_CTRL_SIGMA_DELTA_EN  (0x1 << 24)
>>>  #define CCM_PLL11_CTRL_UPD (0x1 << 30)
>>>
>>> @@ -273,9 +297,15 @@ struct sunxi_ccm_reg {
>>>
>>>  #define AHB_GATE_OFFSET_DRC0   25
>>>  #define AHB_GATE_OFFSET_DE_FE0 14
>>>  #define AHB_GATE_OFFSET_DE_BE0 12
>>>
>>> +#define AHB_GATE_OFFSET_DE 12
>>>
>>>  #define AHB_GATE_OFFSET_HDMI   11
>>>
>>> +#ifndef CONFIG_SUNXI_DE2
>>>
>>>  #define AHB_GATE_OFFSET_LCD1   5
>>>  #define AHB_GATE_OFFSET_LCD0   4
>>>
>>> +#else
>>> +#define AHB_GATE_OFFSET_LCD1   4
>>> +#define AHB_GATE_OFFSET_LCD0   3
>>> +#endif
>>>
>>>  #define CCM_MMC_CTRL_M(x)  ((x) - 1)
>>>  

Re: [linux-sunxi] [PATCH v3 0/5] Add dual-role OTG support for Allwinner H3

[Ondřej Jirman]

Hi Icenowy,

when I was trying to add OTG support I found an issue with powercycling.
When I have USB cable connecting PC and the OTG port on the SBC, when
the board enables the vbus, it would become impossible to power cycle
the board after poweroff. The reason being that when vbus is enabled,
the board is powered from the OTG port even if you disconnect the barrel
plug.

Should kernel turn off the vbus before shutting down/restarting? What do
you think?

regards,
  o.

Dne 6.3.2017 v 23:34 Icenowy Zheng napsal(a):
> Allwinner H3 have a its USB PHY0 routed to two USB controllers: one is
> a MUSB controller, which can work in peripheral mode, but works badly in
> host mode (several hardware will fail on the MUSB controller, even connect
> one MUSB controller in peripheral mode to another one in host mode cannot
> work); the other is a pair of EHCI/OHCI controller, which can work only
> in host mode, but have better compatibillity. The route is controlled in
> a register, which we have set it to HCI only when we do not know about
> it well.
> 
> Add support to route to the best controller according to current USB mode
> (host/peripheral).
> 
> Note: Currently even if hardware only support hostmode, we should still
> enable the MUSB controller, as it controls the USB mode. (Some this kind
> of hardware can also work in peripheral mode by settings in the sysfs
> node of MUSB, then connect it to another host via a USB Type-A to Type-A
> cable.)
> 
> Patch 1 changes the device tree binding to include the "pmu0" for HCI pair.
> 
> Patch 2 adds support for auto routing of PHY0. It's currently only enabled
> on H3, but it's easy to extend it to other SoCs which feature this
> route control.
> 
> Patch 3 adds necessary device tree nodes to the H3 DTSI file. Note: The
> phy is not bind for OHCI/EHCI0, as OHCI/EHCI drivers will keep the VBUS
> on. Only MUSB driver can properly handle a dual-role PHY.
> 
> Patch 4 enables USB OTG functionality on Orange Pi One board, which is
> the only H3 board I have that have proper OTG function. It's easy to
> enable OTG on other boards with their schematics.
> 
> Patch 5 enables USB OTG functionality on Orange Pi Zero board, as the
> board cannot output power on Vbus, I only enabled peripheral mode by
> default.
> 
> The USB PHY on V3s/A64 SoCs also feature this capability, and it will
> be soon enabled on these SoCs after this patchset is merged.
> 
> Icenowy Zheng (5):
>   dt: bindings: add pmu0 regs for USB PHYs on Allwinner H3/V3s/A64
>   phy: sun4i-usb: support automatically switch PHY0 route to MUSB/HCI
>   ARM: dts: sun8i: h3: add usb_otg and OHCI/EHCI for usbc0 on H3
>   ARM: dts: sun8i: h3: enable USB OTG on Orange Pi One
>   ARM: dts: sun8i: h2+: enable USB OTG for Orange Pi Zero board
> 
>  .../devicetree/bindings/phy/sun4i-usb-phy.txt  |  1 +
>  arch/arm/boot/dts/sun8i-h2-plus-orangepi-zero.dts  | 14 ++
>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts| 22 +-
>  arch/arm/boot/dts/sun8i-h3.dtsi| 32 ++
>  drivers/phy/phy-sun4i-usb.c| 50 
> ++
>  5 files changed, 101 insertions(+), 18 deletions(-)
> 

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

Re: [linux-sunxi] [PATCH] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

[Ondřej Jirman]

Dne 18.1.2017 v 17:56 Maxime Ripard napsal(a):
>>> What's your current plan to fix that? I guess the easiest (and most
>>> likely to be reusable) would be to allow for clock tables, instead of
>>> using the generic approach. We might have some other clocks (like
>>> audio or video) that would need such a precise tuning in the future
>>> too.
>>
>> My proposed solution is this for M factor (H3 specific solution):
>>
>> https://github.com/megous/linux/commit/88be3d421e958579026135d8acec4b3983958738
> 
> This one is fine.
> 
>> and this for P factor:
>>
>> https://github.com/megous/linux/commit/d7f274ed0c13fa9b4099445cb6bf9b2f8f2cfa8a
>>
>> Perhaps it should be configurable if the P limitation is not universal
>> for all NKMP clocks. But I haven't read all the datasheets.
> 
> And this is exactly what I wanted to avoid, for the reason you're
> giving :)
> 
> This is some generic code, and yet you're putting a clock and SoC
> specific limit in there. You have two ways to deal with that. Either
> come up with some generic throttling mecanism to force a particular
> value above or below a given threshold, but that might be tedious to
> do, and require some significant rework.
> 
> Or you can use a table, which is generic and should be relatively
> easy. I really think this is the most straightforward solution, and
> even more so since we just want to support a limited number of
> frequencies in this case.

So I would add a pointer to a table to struct ccu_nkmp and define the
table itself in ccu-sun8i-h3.c?

If struct ccu_nkmp would have non-NULL pointer to a table, it would be
used instead of the math in ccu_nkmp.c.

Sounds ok?

regards,
  o.

> Maxime
> 

-- 
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 1/4] phy: sun4i-usb: support PHY0 on H3 in MUSB mode

[Ondřej Jirman]

Dne 16.1.2017 v 20:14 Icenowy Zheng napsal(a):
> The PHY0 on H3 can be wired either to MUSB controller or OHCI/EHCI
> controller.
> 
> The original driver wired it to OHCI/EHCI controller; however, as the
> code to use PHY0 as OHCI/EHCI is missing, it makes the PHY fully
> unusable.
> 
> Rename the register (according to its function and the name in BSP
> driver), and remove the code which wires the PHY0 to OHCI/EHCI, as MUSB
> can support both peripheral and host mode (although the host mode of
> MUSB is buggy).
> 
> The register that is renamed is now unused, as its initial value is just
> MUSB mode. However, when OHCI/EHCI mode support is added, the register
> can be used again.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/phy/phy-sun4i-usb.c | 25 +
>  1 file changed, 9 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index bf28a0fdd569..6b193a635c6b 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -49,7 +49,7 @@
>  #define REG_PHYBIST  0x08
>  #define REG_PHYTUNE  0x0c
>  #define REG_PHYCTL_A33   0x10
> -#define REG_PHY_UNK_H3   0x20
> +#define REG_PHY_OTGCTL   0x20

You have added REG_PHY_OTGCTL, but it is not used below.

regards,
  o.

>  #define REG_PMU_UNK1 0x10
>  
> @@ -269,23 +269,16 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   writel(val & ~2, phy->pmu + REG_PMU_UNK1);
>   }
>  
> - if (data->cfg->type == sun8i_h3_phy) {
> - if (phy->index == 0) {
> - val = readl(data->base + REG_PHY_UNK_H3);
> - writel(val & ~1, data->base + REG_PHY_UNK_H3);
> - }
> - } else {
> - /* Enable USB 45 Ohm resistor calibration */
> - if (phy->index == 0)
> - sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
> + /* Enable USB 45 Ohm resistor calibration */
> + if (phy->index == 0)
> + sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
>  
> - /* Adjust PHY's magnitude and rate */
> - sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
> + /* Adjust PHY's magnitude and rate */
> + sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
>  
> - /* Disconnect threshold adjustment */
> - sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> - data->cfg->disc_thresh, 2);
> - }
> + /* Disconnect threshold adjustment */
> + sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> + data->cfg->disc_thresh, 2);
>  
>   sun4i_usb_phy_passby(phy, 1);
>  
> 

-- 
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] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

[Ondřej Jirman]

Hi Maxime,

Dne 16.1.2017 v 17:43 Maxime Ripard napsal(a):
>> It does lock up quickly with mainline ccu_nkmp_find_best algorithm
>> for finding factors.
>>
>> Even with linux kernel, it breaks. It's just more difficult to hit the
>> right conditions. I got oops only right after boot when running cpuburn
>> to trigger thermal_zone issued OPP change, if I first run some cpupower
>> commands. That's why I wrote this program to stress test various CPU_PLL
>> change/factor selection algorithms independently of everything else, to
>> get more predictable and quicker testing results.
> 
> Understood. Do you have the code available somewhere?

It's a bit messy, but it's here:

https://github.com/megous/h3-firmware/blob/master/main.c

 What works is selecting NKMP factors so that M is always 1 and P is
 anything other than /1 only for frequencies under 288MHz. As mandated by
 the H3 datasheet. Mainline ccu_nkmp_find_best doesn't respect these
 conditions. With that I can change CPUX frequencies randomly 20x a
 second so far indefinitely without the main CPU ever locking up.

 Please drop or revert this patch. It is not a correct approach to the
 problem. I'd suggest dropping the entire clock notifier mechanism, too,
 unless it can be proven to work reliably.
>>>
>>> It has been proven to work reliably on a number of other SoCs.
>>
>> Unless it was stress tested like this with randomy changed settings, I
>> doubt you can call it reliable. It may just be very hard to hit the
>> issue on linux with particular OPP/thermal zone configuration. That's
>> because the issue is dependent on before and after NKMP values. People
>> may have just been lucky so far.
> 
> Yes, or maybe we just have OPPs that just don't trigger a low enough P
> factor.
> 
> There's no rush anyway, the H3 cpufreq support is not enabled at the
> moment, so that code basically does nothing for the moment.
> 
> What's your current plan to fix that? I guess the easiest (and most
> likely to be reusable) would be to allow for clock tables, instead of
> using the generic approach. We might have some other clocks (like
> audio or video) that would need such a precise tuning in the future
> too.

My proposed solution is this for M factor (H3 specific solution):

https://github.com/megous/linux/commit/88be3d421e958579026135d8acec4b3983958738

and this for P factor:

https://github.com/megous/linux/commit/d7f274ed0c13fa9b4099445cb6bf9b2f8f2cfa8a

Perhaps it should be configurable if the P limitation is not universal
for all NKMP clocks. But I haven't read all the datasheets.

It was verified with the above arisc firmware to work reliably, so it
should be enough. It is simpler and the factor table should not be
necessary in this case.

regards,
  o.

> Maxime
> 

-- 
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] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

[Ondřej Jirman]

Dne 9.1.2017 v 10:59 Maxime Ripard napsal(a):
> On Sat, Jan 07, 2017 at 04:49:18PM +0100, Ondřej Jirman wrote:
>> Maxime,
>>
>> Dne 25.11.2016 v 01:28 meg...@megous.com napsal(a):
>>> From: Ondrej Jirman <meg...@megous.com>
>>>
>>> When adjusting PLL_CPUX on H3, the PLL is temporarily driven
>>> too high, and the system becomes unstable (oopses or hangs).
>>>
>>> Add a notifier to avoid this situation by temporarily switching
>>> to a known stable 24 MHz oscillator.
>>
>> I have done more thorough testing on H3 and this approach with switching
>> to 24MHz oscillator does not work. Motivation being that my Orange Pi
>> One still gets lockups even with this patch under certain circumstances.
>>
>> So I have created a small test program for CPUS (additional OpenRISC CPU
>> on the SoC) which randomly changes PLL_CPUX settings while main CPU is
>> running a loop that sends messages to CPUS via msgbox.
>>
>> Assumption being that while CPUS is successfully receiving messages via
>> msgbox, the main CPU didn't lock up, yet.
>>
>> With this I am able to quickly and thoroughly test various PLL_CPUX
>> change and factor selection algorithms.
>>
>> Results are that bypassing CPUX clock by switching to 24 MHz oscillator
>> does not work at all. Main CPU locks up in about 1 second into the test.
>> Don't ask me why.
> 
> You mean that you are changing the frequency behind Linux' back? That
> won't work. There's more to cpufreq than just changing the frequency,
> but also adusting the number of loops per jiffy for the new frequency
> for example. I don't really expect that setup to work even on a
> perfectly stable system. CPUFreq *has* to be involved, otherwise, that
> alone might introduce bugs, and you cannot draw any conclusions
> anymore.

No, this has nothing to do with linux. I'm not running linux for this
test. I'm running a small program on CPUS (Open RISC CPU) on the SoC
loaded using FEL from USB.

The main cpu is just pushing messages into msgbox in a loop, so that
CPUS can determine that the main CPU is still running ok and give
feedback to me over UART. Not even DRAM is involved. The programs are
running from SRAM.

This is the most direct test of PLL change stability that can be done on
this SoC regardless of the OS. Not even CPU voltage switching is
involved. I just set the maximum voltage and fiddle with CPU_PLL
frequencies randomly, while waiting for the main CPU to lock up.

It does lock up quickly with mainline ccu_nkmp_find_best algorithm for
finding factors.

Even with linux kernel, it breaks. It's just more difficult to hit the
right conditions. I got oops only right after boot when running cpuburn
to trigger thermal_zone issued OPP change, if I first run some cpupower
commands. That's why I wrote this program to stress test various CPU_PLL
change/factor selection algorithms independently of everything else, to
get more predictable and quicker testing results.

>> What works is selecting NKMP factors so that M is always 1 and P is
>> anything other than /1 only for frequencies under 288MHz. As mandated by
>> the H3 datasheet. Mainline ccu_nkmp_find_best doesn't respect these
>> conditions. With that I can change CPUX frequencies randomly 20x a
>> second so far indefinitely without the main CPU ever locking up.
>>
>> Please drop or revert this patch. It is not a correct approach to the
>> problem. I'd suggest dropping the entire clock notifier mechanism, too,
>> unless it can be proven to work reliably.
> 
> It has been proven to work reliably on a number of other SoCs.

Unless it was stress tested like this with randomy changed settings, I
doubt you can call it reliable. It may just be very hard to hit the
issue on linux with particular OPP/thermal zone configuration. That's
because the issue is dependent on before and after NKMP values. People
may have just been lucky so far.

regards,
  o.

> Thanks!
> Maxime
> 

-- 
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] clk: sunxi-ng: fix PLL_CPUX adjusting on H3

[Ondřej Jirman]

Maxime,

Dne 25.11.2016 v 01:28 meg...@megous.com napsal(a):
> From: Ondrej Jirman 
> 
> When adjusting PLL_CPUX on H3, the PLL is temporarily driven
> too high, and the system becomes unstable (oopses or hangs).
> 
> Add a notifier to avoid this situation by temporarily switching
> to a known stable 24 MHz oscillator.

I have done more thorough testing on H3 and this approach with switching
to 24MHz oscillator does not work. Motivation being that my Orange Pi
One still gets lockups even with this patch under certain circumstances.

So I have created a small test program for CPUS (additional OpenRISC CPU
on the SoC) which randomly changes PLL_CPUX settings while main CPU is
running a loop that sends messages to CPUS via msgbox.

Assumption being that while CPUS is successfully receiving messages via
msgbox, the main CPU didn't lock up, yet.

With this I am able to quickly and thoroughly test various PLL_CPUX
change and factor selection algorithms.

Results are that bypassing CPUX clock by switching to 24 MHz oscillator
does not work at all. Main CPU locks up in about 1 second into the test.
Don't ask me why.

What works is selecting NKMP factors so that M is always 1 and P is
anything other than /1 only for frequencies under 288MHz. As mandated by
the H3 datasheet. Mainline ccu_nkmp_find_best doesn't respect these
conditions. With that I can change CPUX frequencies randomly 20x a
second so far indefinitely without the main CPU ever locking up.

Please drop or revert this patch. It is not a correct approach to the
problem. I'd suggest dropping the entire clock notifier mechanism, too,
unless it can be proven to work reliably. The bypass makes some
intuitive sense, but for some reason it doesn't work in practice (on H3
at least).

Aside from this, uboot also needs to be changed to set that it uses M
and P factors correctly.

Whatever else I try, I always hit lockups sooner or later with the test
program. I tried 24MHz bypass and staged application of multipliers and
dividers as discussed before.

I'll send a proper patch for nkmp clock driver and u-boot later.

regards,
  o.

> Signed-off-by: Ondrej Jirman 
> Tested-by: Lutz Sammer 
> ---
>  drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
> b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> index 614d47c..cf266c9 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> @@ -809,6 +809,13 @@ static const struct sunxi_ccu_desc sun8i_h3_ccu_desc = {
>   .num_resets = ARRAY_SIZE(sun8i_h3_ccu_resets),
>  };
>  
> +static struct ccu_mux_nb sun8i_h3_cpu_nb = {
> + .common = _clk.common,
> + .cm = _clk.mux,
> + .delay_us   = 1, /* > 8 clock cycles at 24 MHz */
> + .bypass_index   = 1, /* index of 24 MHz oscillator */
> +};
> +
>  static void __init sun8i_h3_ccu_setup(struct device_node *node)
>  {
>   void __iomem *reg;
> @@ -827,6 +834,9 @@ static void __init sun8i_h3_ccu_setup(struct device_node 
> *node)
>   writel(val | (3 << 16), reg + SUN8I_H3_PLL_AUDIO_REG);
>  
>   sunxi_ccu_probe(node, reg, _h3_ccu_desc);
> +
> + ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
> +   _h3_cpu_nb);
>  }
>  CLK_OF_DECLARE(sun8i_h3_ccu, "allwinner,sun8i-h3-ccu",
>  sun8i_h3_ccu_setup);
> 

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

Re: [linux-sunxi] [PATCH v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes

[Ondřej Jirman]

Dne 25.11.2016 v 06:27 Icenowy Zheng napsal(a):
> 
> 
> 20.11.2016, 20:07, "Jean-Francois Moine" :
>> Signed-off-by: Jean-Francois Moine 
>> ---
>>  arch/arm/boot/dts/sun8i-h3.dtsi | 51 
>> +
>>  1 file changed, 51 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 416b825..7c6b1d5 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -140,6 +140,16 @@
>>  #size-cells = <1>;
>>  ranges;
>>
>> + de: de-controller@0100 {
>> + compatible = "allwinner,sun8i-h3-display-engine";
>> + reg = <0x0100 0x40>;
>> + clocks = < CLK_BUS_DE>, < CLK_DE>;
>> + clock-names = "bus", "clock";
>> + resets = < RST_BUS_DE>;
>> + ports = <_p>;
>> + status = "disabled";
>> + };
>> +
>>  dma: dma-controller@01c02000 {
>>  compatible = "allwinner,sun8i-h3-dma";
>>  reg = <0x01c02000 0x1000>;
>> @@ -149,6 +159,23 @@
>>  #dma-cells = <1>;
>>  };
>>
>> + lcd0: lcd-controller@01c0c000 {
>> + compatible = "allwinner,sun8i-a83t-tcon";
>> + reg = <0x01c0c000 0x400>;
>> + clocks = < CLK_BUS_TCON0>, < CLK_TCON0>;
>> + clock-names = "bus", "clock";
>> + resets = < RST_BUS_TCON0>;
>> + interrupts = ;
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + lcd0_p: port {
>> + lcd0_hdmi: endpoint {
>> + remote-endpoint = <_lcd0>;
>> + };
>> + };
>> + };
>> +
>>  mmc0: mmc@01c0f000 {
>>  compatible = "allwinner,sun7i-a20-mmc";
>>  reg = <0x01c0f000 0x1000>;
>> @@ -314,6 +341,11 @@
>>  clock-names = "hosc", "losc";
>>  #clock-cells = <1>;
>>  #reset-cells = <1>;
>> +
>> + assigned-clocks = < CLK_PLL_DE>,
> 
> Cannot get the patch built on 4.9-rc, as CLK_PLL_DE is not an exported clock.
> 
> Only CLK_DE is exported.

Jean-Francois uses his own clk driver for h3. Check out this branch,
which contains his latest HDMI patches with necessary fixes for it to
work with sunxi-ng clk driver:

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

There are more issues, than just a missing CLK_DE macro. I'll probably
send the patches out soon.

regards,
  o.

>> + < CLK_DE>;
>> + assigned-clock-rates = <86400>,
>> + <43200>;
>>  };
>>
>>  pio: pinctrl@01c20800 {
>> @@ -564,6 +596,25 @@
>>  interrupts = > IRQ_TYPE_LEVEL_HIGH)>;
>>  };
>>
>> + hdmi: hdmi@01ee {
>> + compatible = "allwinner,sun8i-h3-hdmi";
>> + reg = <0x01ee 0x2>;
>> + clocks = < CLK_BUS_HDMI>, < CLK_HDMI>,
>> + < CLK_HDMI_DDC>;
>> + clock-names = "bus", "clock", "ddc-clock";
>> + resets = < RST_BUS_HDMI0>, < RST_BUS_HDMI1>;
>> + reset-names = "hdmi0", "hdmi1";
>> + status = "disabled";
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + port@0 { /* video */
>> + reg = <0>;
>> + hdmi_lcd0: endpoint {
>> + remote-endpoint = <_hdmi>;
>> + };
>> + };
>> + };
>> +
>>  rtc: rtc@01f0 {
>>  compatible = "allwinner,sun6i-a31-rtc";
>>  reg = <0x01f0 0x54>;
>> --
>> 2.10.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.
> 

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

Re: [linux-sunxi] [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support

[Ondřej Jirman]

Dne 21.11.2016 v 19:14 Jean-Francois Moine napsal(a):
> On Mon, 21 Nov 2016 01:54:53 +0100
> Ondřej Jirman <meg...@megous.com> wrote:
> 
>> Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
>>> This patchset series adds HDMI video support to the Allwinner
>>> sun8i SoCs which include the display engine 2 (DE2).
>>> The driver contains the code for the A83T and H3, but it could be
>>> used/extended for other SoCs as the A64, H2 and H5.
>>
>> Hi,
>>
>> I'm trying to test your patches on Orange Pi PC, and I've run into a few
>> issues: (I'm using sunxi-ng with the same patches as last time, to make
>> it work with your driver)
>>
>> 1] I just get pink output on the monitor - there's some signal, but it's
>> pink (or more like magenta).
>>
>> dmesg ouput indicates no error:
>>
>> [1.887823] [drm] Initialized
>> [1.888503] sun8i-de2 100.de-controller: bound
>> 1c0c000.lcd-controller (ops 0xc0a63894)
>> [2.057298] sun8i-de2 100.de-controller: bound 1ee.hdmi (ops
>> 0xc0a63b54)
>> [2.057304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [2.057307] [drm] No driver support for vblank timestamp query.
>> [2.690862] Console: switching to colour frame buffer device 240x67
>> [2.723059] sun8i-de2 100.de-controller: fb0:  frame buffer device
>   [snip]
> 
> My H3 boards work correctly, except the Orange PI 2 when it cannot read
> the EDID (but it is OK after reboot).
> 
> Did you check if the EDID was correctly read?

EDID is correctly read (I verified that it is the same as with the v5
version of the driver), but there's one difference I noted. v5 says dpms
is Off, while v6 says dpms is On.

> Which resolution do you expect?
> 

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

Re: [linux-sunxi] [PATCH v6 0/5] drm: sun8i: Add DE2 HDMI video support

[Ondřej Jirman]

Dne 20.11.2016 v 12:32 Jean-Francois Moine napsal(a):
> This patchset series adds HDMI video support to the Allwinner
> sun8i SoCs which include the display engine 2 (DE2).
> The driver contains the code for the A83T and H3, but it could be
> used/extended for other SoCs as the A64, H2 and H5.

Hi,

I'm trying to test your patches on Orange Pi PC, and I've run into a few
issues: (I'm using sunxi-ng with the same patches as last time, to make
it work with your driver)

1] I just get pink output on the monitor - there's some signal, but it's
pink (or more like magenta).

dmesg ouput indicates no error:

[1.887823] [drm] Initialized
[1.888503] sun8i-de2 100.de-controller: bound
1c0c000.lcd-controller (ops 0xc0a63894)
[2.057298] sun8i-de2 100.de-controller: bound 1ee.hdmi (ops
0xc0a63b54)
[2.057304] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[2.057307] [drm] No driver support for vblank timestamp query.
[2.690862] Console: switching to colour frame buffer device 240x67
[2.723059] sun8i-de2 100.de-controller: fb0:  frame buffer device

> 
> v6:
>   - remove audio support (other patchset to come)
>   - use DRM modeset data for HDMI configuration
>   (thanks to Jernej Škrabec)
>   - more meaningfull register names
>   - use a mutex for DE I/O protection
>   - merge DE and plane into one file
>   - don't activate the video hardware when video not started
>   (Maxime Ripard)
>   - remove 'type = "video" in DT graph ports
>   (Rob Herring)
>   - change the I/O accesses by #define instead of struct
>   (Maxime Ripard, André Przywara)
>   - remove pm functions (Maxime Ripard)
>   - set the pll-de/de clocks in the DT (Maxime Ripard)

This change triggers this dmesg output I suppose:

[0.00] bad: scheduling from the idle thread!
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.9.0-rc6-00045-g5347f96 #29
[0.00] Hardware name: Allwinner sun8i Family
[0.00] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[0.00] [] (show_stack) from []
(dump_stack+0x84/0x98)
[0.00] [] (dump_stack) from []
(dequeue_task_idle+0x34/0x40)
[0.00] [] (dequeue_task_idle) from []
(__schedule+0x244/0x52c)
[0.00] [] (__schedule) from []
(schedule+0x44/0x9c)
[0.00] [] (schedule) from []
(schedule_hrtimeout_range_clock+0xc4/0x138)
[0.00] [] (schedule_hrtimeout_range_clock) from
[] (schedule_hrtimeout_range+0x18/0x20)
[0.00] [] (schedule_hrtimeout_range) from []
(usleep_range+0x4c/0x54)
[0.00] [] (usleep_range) from []
(ccu_helper_wait_for_lock+0x58/0xc8)
[0.00] [] (ccu_helper_wait_for_lock) from []
(ccu_nm_set_rate+0x124/0x148)
[0.00] [] (ccu_nm_set_rate) from []
(clk_change_rate+0x194/0x248)
[0.00] [] (clk_change_rate) from []
(clk_core_set_rate_nolock+0x68/0xb0)
[0.00] [] (clk_core_set_rate_nolock) from []
(clk_set_rate+0x20/0x30)
[0.00] [] (clk_set_rate) from []
(of_clk_set_defaults+0x1fc/0x334)
[0.00] [] (of_clk_set_defaults) from []
(of_clk_add_hw_provider+0x74/0x9c)
[0.00] [] (of_clk_add_hw_provider) from []
(sunxi_ccu_probe+0xa8/0x130)
[0.00] [] (sunxi_ccu_probe) from []
(of_clk_init+0x15c/0x1e8)
[0.00] [] (of_clk_init) from []
(sun6i_timer_init+0xc/0x18)
[0.00] [] (sun6i_timer_init) from []
(start_kernel+0x248/0x398)
[0.00] [] (start_kernel) from [<4000807c>] (0x4000807c)
[0.00] arm_arch_timer: Architected cp15 timer(s) running at
24.00MHz (phys).
[0.00] clocksource: arch_sys_counter: mask: 0xff
max_cycles: 0x588fe9dc0, max_idle_ns: 440795202592 ns
[0.00] [ cut here ]
[0.00] WARNING: CPU: 0 PID: 0 at kernel/time/sched_clock.c:179
sched_clock_register+0x44/0x1dc
[0.00] CPU: 0 PID: 0 Comm: swapper/0 Not tainted
4.9.0-rc6-00045-g5347f96 #29
[0.00] Hardware name: Allwinner sun8i Family
[0.00] [] (unwind_backtrace) from []
(show_stack+0x10/0x14)
[0.00] [] (show_stack) from []
(dump_stack+0x84/0x98)
[0.00] [] (dump_stack) from []
(__warn+0xe0/0xfc)
[0.00] [] (__warn) from []
(warn_slowpath_null+0x20/0x28)
[0.00] [] (warn_slowpath_null) from []
(sched_clock_register+0x44/0x1dc)
[0.00] [] (sched_clock_register) from []
(arch_timer_common_init+0x204/0x22c)
[0.00] [] (arch_timer_common_init) from []
(arch_timer_of_init+0x2e4/0x310)
[0.00] [] (arch_timer_of_init) from []
(clocksource_probe+0x58/0xac)
[0.00] [] (clocksource_probe) from []
(start_kernel+0x248/0x398)
[0.00] [] (start_kernel) from [<4000807c>] (0x4000807c)
[0.00] ---[ end trace  ]---
[0.04] sched_clock: 56 bits at 24MHz, resolution 41ns, wraps
every 4398046511097ns
[0.10] Switching to timer-based delay loop, resolution 41ns
[0.000139] clocksource: timer: 

Re: [linux-sunxi] Mainline stability (overvolting/undervolting) etc. (u-boot/linux)

[Ondřej Jirman]

Dne 1.11.2016 v 00:55 Rune Petersen napsal(a):
> On 25/10/16 16:36, Olliver Schinagl wrote:
>> Hey all,
>>
>> as some of you are probably aware, some users occasionally experience
>> some
>> instability using the mainline components. I specifically only want to
>> focus on
>> mainline, as with the 3.4 stuff ... well lets just not even go there.
>>
>> [TL;DR] We should offer the user a stable u-boot/kernel combo. Playing
>> with
>> frequencies/voltages is up to the user (via overlay etc).
>>
>> So stability. First in case you haven't heard we released our product,
>> the
>> Ultimaker 3, which features an Olimex Lime2 board. During the past
>> development
>> year we noticed some stability issues but haven't pinpointed the exact
>> cause.
>>
>> For example, we noticed quite some stability problems with the ondemand
>> governor, especially as it was running on the medium ranges. Switching to
>> performance fixed this mostly for us, but we do very seldom still see
>> a crash.
>>
>> With olimex change request on the 11th of oktober to lower the memory
>> freq. [0],
>> we seem to have atleast some form of confirmation that there really is a
>> stability problem for others as well. With that request, they lowered
>> the DRAM
>> frequency of their A20 boards.
>>
>> Does that solve the stability? Or does that also reduce the failure
>> rate to be
>> less noticeable.
>>
>> Or are both a problem, cpu voltage/freq and dram freq.
>>
>> I think it is fair to say, before writing the next paragraph, that the
>> defaults
>> users get from mainline components should be rock solid and stable.
>> Playing with
>> settings is fine for a user to do, but the defaults should be solid.
>>
>> So one, is to investigate the memory claims of Olimex. Even lowering the
>> frequency to 384 MHz may not be as stable as some expect, but I'm sure
>> ssvb can
>> pitch in here :)
>>
>> Secondly, are our operating points sane and safe? For example this
>> patch [1]
>> from the banana-pi folks increased the voltages of the middle
>> frequencies. Now
>> this could have been because of two reasons, and unfortunately the
>> patch does
>> not mention this clearly. A larger user base found issues here and
>> changed it to
>> solve the issues. Or the banana-pi has a bad board design, where the
>> requested
>> voltage does not reach the SoC, and thus needs some compensation. If
>> the later
>> is the case, a comment in the dts should have been added and the
>> commit message
>> should have stated this.
>>
>> Since however, some people notice the same problem on other boards,
>> this may not
>> be a board routing issue. Anyway, we are just guessing in that regard
>> now.
>>
>> Digging a little deeper, what strikes me as odd, is that Allwinner
>> says in the
>> A20 datasheet, that 1.4V is the maximum recommended voltage for the
>> SoC, yet we
>> have 2 frequencies that operate on 1.4v. This, to me, indicates something
>> strange. Either 960 MHz is stable at 1.4 and thus the 912 Mhz voltage
>> should be
>> lower, or the 960 Mhz is slightly undervolted.
>>
>> We do not have reliable data from Allwinner, and we don't have the
>> resources to
>> properly test many boards to determine stable operating points. But by
>> going
>> with somewhat less reliable operating data from the Allwinner code
>> drop [2], we
>> see a different picture that is in the current dts.
>>
>> Here the voltage-frequencies match much closer to what bananapi is using.
>>
>> So what to do with our limited resources?
>>
>> Well over the next 2 weeks I will try to test as many lime2 boards
>> with various
>> settings and various benchmarks to get some more numbers here.
>> Depending on my
>> findings some changes will emerge. But even then, we'll have a small
>> sample size
>> as my resources and time is limited.
>>
>> For one, we know that 1.4 volt is the maximum voltage for the SoC. So
>> lets make
>> sure to not go over that. Further more, lowering the voltage on lower
>> frequencies is a power saving measure in our case. So having slightly
>> higher
>> voltages is not horrible.
>>
>> I think it is safe to say, that we should use the higher voltage for
>> the lower
>> frequencies between the Allwinner 3.4 reference code [2] and the
>> bananapi table
>> [1]. This should, in theory, yield a stable range of operating points.
>>
>> If someone has hard evidence that a large set of samples works
>> stability with
>> modified settings, we can always adopt this. But stability should be
>> our primary
>> concern.
>>
>> As for the DRAM frequencies, this is a little bit harder I think, but
>> even here,
>> we need to have fully stable settings, and not just 'lets just go a
>> bit lower
>> and it should be fine'.
>>
>> [0] https://patchwork.ozlabs.org/patch/680990/
>> [1]
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/sun7i-a20-bananapi.dts?id=a15b80fb0ad7ddab8d2668392cce3c12aff594bd
>>
>>
>> [2] http://linux-sunxi.org/A20#DVFS
>>
> 
> Some time ago I 

Re: [linux-sunxi] [PATCH 1/3] phy: sun4i: check PHY id when poking unknown bit of pmu

[Ondřej Jirman]

Dne 24.10.2016 v 05:59 Icenowy Zheng napsal(a):
> Allwinner SoC's PHY 0, when used as OTG controller, have no pmu part.
> The code that poke some unknown bit of PMU for H3/A64 didn't check
> the PHY, and will cause kernel oops when PHY 0 is used.
> 
> Fixes: b3e0d141ca9f (phy: sun4i: add support for A64 usb phy)
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  drivers/phy/phy-sun4i-usb.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index b9342a2..ff8e9dd 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -264,7 +264,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   return ret;
>   }
>  
> - if (data->cfg->enable_pmu_unk1) {
> + if (phy->index != 0 && data->cfg->enable_pmu_unk1) {

It might be better to check for phy->pmu directly.

regards,
  o.
>   val = readl(phy->pmu + REG_PMU_UNK1);
>   writel(val & ~2, phy->pmu + REG_PMU_UNK1);
>   }
> 



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

Re: [linux-sunxi] [PATCH v5 0/7] ARM: ASoC: drm: sun8i: Add DE2 HDMI audio and video

[Ondřej Jirman]

Dne 22.10.2016 v 15:28 Jean-Francois Moine napsal(a):
> This patchset series adds HDMI audio and video support to the Allwinner
> sun8i SoCs which include the display engine 2 (DE2).

Hi,

I've tested your patches on top of my 4.9-rc1 changes on Orange Pi PC,
and HDMI display output works well -- with some changes to sunxi-ng H3
clock driver. I've put those changes here:

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

When I run firefox, it feels faster and less laggy than armbian 3.4
desktop. Very nice!

The only issue that I've found, is that clk setup for ASoC driver fails
with EINVAL.

When I run pulseaudio, dmesg is filled with this:

[   29.951468] sun8i-audio 1c22800.i2s: ASoC: can't set 1c22800.i2s hw
params: -22
[   29.969184] Setting sysclk rate failed -22
[   29.982440] sun8i-audio 1c22800.i2s: ASoC: can't set 1c22800.i2s hw
params: -22
[   30.000148] Setting sysclk rate failed -22
[   30.013398] sun8i-audio 1c22800.i2s: ASoC: can't set 1c22800.i2s hw
params: -22
[   30.032790] Setting sysclk rate failed -22
[   30.044411] sun8i-audio 1c22800.i2s: ASoC: can't set 1c22800.i2s hw
params: -22
[   30.062252] Setting sysclk rate failed -22

What do you base your patches on? Do you have some patches for the
sunxi-ng H3 clock driver that are required for this to work?

thank you and regards,
  o.

> A first submission in January for video on the H3 could not enter into
> the mainline kernel due to the lack of license headers in Allwinner's
> sources.
> 
> Recently, an announce about Tina OS for the R series
>   https://www.youtube.com/watch?v=h7KD-6HblAU
> was followed by the upload of a new linux-3.4 source tree
>   https://github.com/tinalinux/linux-3.4
> with files containing GPL headers.
> 
> Well, I don't know if these sources are really from Allwinner, but
> anyway, this is the opportunity to propose a new version of my DRM
> HDMI driver.
> 
> v5:
>   - add overlay plane
>   - add audio support
>   - add support for the A83T
>   - add back the HDMI driver
>   - many bug fixes
> v4: 
>   - drivers/clk/sunxi/Makefile was missing (Emil Velikov)
> v3:
>   - add the hardware cursor
>   - simplify and fix the DE2 init sequences
>   - generation for all SUNXI SoCs (Andre Przywara)
> v2:
>   - remove the HDMI driver
>   - remarks from Chen-Yu Tsai and Russell King
>   - DT documentation added
> 
> Jean-Francois Moine (7):
>   drm: sunxi: Add a basic DRM driver for Allwinner DE2
>   ASoC: sunxi: Add a simple HDMI CODEC
>   drm: sunxi: add DE2 HDMI support
>   ASoC: sunxi: Add sun8i I2S driver
>   ARM: dts: sun8i-h3: add HDMI audio and video nodes
>   ARM: dts: sun8i-h3: Add HDMI audio and video to the Banana Pi M2+
>   ARM: dts: sun8i-h3: Add HDMI audio and video to the Orange PI 2
> 
>  .../devicetree/bindings/display/sunxi/hdmi.txt |  52 ++
>  .../bindings/display/sunxi/sunxi-de2.txt   |  83 ++
>  .../devicetree/bindings/sound/sun4i-i2s.txt|  38 +-
>  arch/arm/boot/dts/sun8i-h3-bananapi-m2-plus.dts|  17 +
>  arch/arm/boot/dts/sun8i-h3-orangepi-2.dts  |  17 +
>  arch/arm/boot/dts/sun8i-h3.dtsi|  67 ++
>  drivers/gpu/drm/Kconfig|   2 +
>  drivers/gpu/drm/Makefile   |   1 +
>  drivers/gpu/drm/sunxi/Kconfig  |  29 +
>  drivers/gpu/drm/sunxi/Makefile |   9 +
>  drivers/gpu/drm/sunxi/de2_crtc.c   | 475 +++
>  drivers/gpu/drm/sunxi/de2_crtc.h   |  63 ++
>  drivers/gpu/drm/sunxi/de2_de.c | 591 +
>  drivers/gpu/drm/sunxi/de2_drm.h|  47 ++
>  drivers/gpu/drm/sunxi/de2_drv.c| 378 +
>  drivers/gpu/drm/sunxi/de2_hdmi.c   | 396 +
>  drivers/gpu/drm/sunxi/de2_hdmi.h   |  40 +
>  drivers/gpu/drm/sunxi/de2_hdmi_io.c| 927 
> +
>  drivers/gpu/drm/sunxi/de2_hdmi_io.h|  25 +
>  drivers/gpu/drm/sunxi/de2_plane.c  | 119 +++
>  include/sound/sunxi_hdmi.h |  23 +
>  sound/soc/codecs/Kconfig   |   9 +
>  sound/soc/codecs/Makefile  |   2 +
>  sound/soc/codecs/sunxi-hdmi.c  | 106 +++
>  sound/soc/sunxi/Kconfig|   8 +
>  sound/soc/sunxi/Makefile   |   3 +
>  sound/soc/sunxi/sun8i-i2s.c| 700 
>  27 files changed, 4222 insertions(+), 5 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/display/sunxi/hdmi.txt
>  create mode 100644 
> Documentation/devicetree/bindings/display/sunxi/sunxi-de2.txt
>  create mode 100644 drivers/gpu/drm/sunxi/Kconfig
>  create mode 100644 drivers/gpu/drm/sunxi/Makefile
>  create mode 100644 drivers/gpu/drm/sunxi/de2_crtc.c
>  create mode 100644 

Re: [linux-sunxi] Help getting I2C to work on sun8i-h3 on linux 4.8

[Ondřej Jirman]

Hi,

I think you may be hitting this issue:

  https://lkml.org/lkml/2016/8/26/150

regards,
  Ondrej

Dne 27.8.2016 v 00:07 Paulo Costa napsal(a):
> Hello, folks.
> 
> It's my first time working with this, please let me know if this isn't
> the right mailing list or not the right way to ask for help. 
> 
> I'm using an Orange Pi PC (sun8i-h3), with a Linux 4.8-rc3.
> I'm trying to enable it's I2C ports, but I haven't had any success yet.
> 
> Martin Ayotte's patch
> (https://groups.google.com/forum/#!topic/linux-sunxi/gd7S3meEAZM) worked
> fine on 4.7.
> I'm trying to convert it to the linux 4.8
> (https://github.com/paulo-raca/linux/commit/d32f1687b3fc21ab30388862f1737c69daef6aff
> -- It mostly involved replacing clocks and resets with the
> new sun8i-h3-ccu).
> Although the I2C ports are registered, whenever I try to access them I
> get this error:
> 
> i2c i2c-2: mv64xxx: I2C bus locked, block: 1, time_left: 0
> 
> I've been stuck at it for a few days, but I've made no progress. Am I
> missing something? Any suggestions?
> 
> Thank you
> 
> -- 
> 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.

-- 
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: Changed: sunxi-ng clock code - NKMP clock implementation is wrong

[Ondřej Jirman]

Hi,

On 31.7.2016 12:31, Maxime Ripard wrote:
> Hi,
> 
> On Fri, Jul 29, 2016 at 12:01:09AM +0200, Ondřej Jirman wrote:
>> On 28.7.2016 23:00, Maxime Ripard wrote:
>>> Hi Ondrej,
>>>
>>> On Thu, Jul 28, 2016 at 01:27:05PM +0200, Ondřej Jirman wrote:
>>>> Hi Maxime,
>>>>
>>>> I don't have your sunxi-ng clock patches in my mailbox, so I'm replying
>>>> to this.
>>>
>>> You can find it in the clock maintainers tree:
>>> https://git.kernel.org/cgit/linux/kernel/git/clk/linux.git/log/?h=clk-sunxi-ng
>>>
>>>> On 26.7.2016 08:32, Maxime Ripard wrote:
>>>>> On Thu, Jul 21, 2016 at 11:52:15AM +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.
>>>>>>>
>>>>>>> That would have the benefit of being quite easy to document, not be a
>>>>>>> huge amount of code and it would work on all the CPUs PLLs we have so
>>>>>>> far, so still, a pretty big win. If it doesn't, of course, we don't
>>>>>>> really have the choice.
>>>>>>
>>>>>> It's probably more code though. It has to access different register from
>>>>>> the one that is already defined in dts, which would add a lot of code
>>>>>> and require dts changes. The original patch I sent is simpler than that.
>>>>>
>>>>> Why?
>>>>>
>>>>> You can use container_of to retrieve the parent structure of the clock
>>>>> notifier, and then you get a ccu_common structure pointer, with the
>>>>> CCU base address, the clock register, its lock, etc.
>>>>>
>>>>> Look at what is done in drivers/clk/meson/clk-cpu.c. It's like 20 LoC.
>>>>>
>>>>> I don't really get why anything should be changed in the DT, or why it
>>>>> would add a lot of code. Or maybe we're not talking about the same
>>>>> thing?
>>>>
>>>> I've looked at the new CCU code, particularly ccu_nkmp.c, and found that
>>>> it very liberally uses divider parameters, even in situations that are
>>>> out of spec compared to the current code in the kernel.
>>>>
>>>> In the current code and especially in the original vendor code, divider
>>>> parameters are used as last resort only. Presumably because, of the
>>>> inherent trouble in changing them, as I described to you in other email.
>>>>
>>>> The new ccu code uses dividers often and even at very high frequencies,
>>>> which goes against the spec.
>>>>
>>>> In the vendor code M is never anything else but 0, and P is used only
>>>> for frequencies below 288MHz, which matches the H3 datasheet, which says:
>>>
>>> In the vendor code, P is never used either. All the boards we had so
>>> far don't go that low, so we cannot make any of these assumptions,
>>> especially since the vendor code has had the bad habit of doing
>>> something wrong and / or useless in the past.
>>
>> P is used in the arisc firmware according to the spec for the lower
>> frequencies.
> 
> Yes, but has anyone actually tested those frequencies? Judging from
> the FEX files I could gather, cpufreq never actually goes lower than
> 480 MHz.
> 

I tested it. It works well down to 60MHz. You can even run on 24MHz if
you run directly from 24mhz osc. It's terribly slow, but it works ok.

I've rebased my working branch over the mainline kernel, which now
contains the sunxi-ng, and tested it. Cpufreq seems to work on orange pi
pc without any changes discussed in this thread. I didn't do any
extensive testing though. But it doesn't hang on boot or cpufreq config
changes.

You can see it here:

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

>>> However, 

[linux-sunxi] Re: Changed: sunxi-ng clock code - NKMP clock implementation is wrong

[Ondřej Jirman]

On 28.7.2016 23:00, Maxime Ripard wrote:
> Hi Ondrej,
> 
> On Thu, Jul 28, 2016 at 01:27:05PM +0200, Ondřej Jirman wrote:
>> Hi Maxime,
>>
>> I don't have your sunxi-ng clock patches in my mailbox, so I'm replying
>> to this.
> 
> You can find it in the clock maintainers tree:
> https://git.kernel.org/cgit/linux/kernel/git/clk/linux.git/log/?h=clk-sunxi-ng
> 
>> On 26.7.2016 08:32, Maxime Ripard wrote:
>>> On Thu, Jul 21, 2016 at 11:52:15AM +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.
>>>>>
>>>>> That would have the benefit of being quite easy to document, not be a
>>>>> huge amount of code and it would work on all the CPUs PLLs we have so
>>>>> far, so still, a pretty big win. If it doesn't, of course, we don't
>>>>> really have the choice.
>>>>
>>>> It's probably more code though. It has to access different register from
>>>> the one that is already defined in dts, which would add a lot of code
>>>> and require dts changes. The original patch I sent is simpler than that.
>>>
>>> Why?
>>>
>>> You can use container_of to retrieve the parent structure of the clock
>>> notifier, and then you get a ccu_common structure pointer, with the
>>> CCU base address, the clock register, its lock, etc.
>>>
>>> Look at what is done in drivers/clk/meson/clk-cpu.c. It's like 20 LoC.
>>>
>>> I don't really get why anything should be changed in the DT, or why it
>>> would add a lot of code. Or maybe we're not talking about the same
>>> thing?
>>
>> I've looked at the new CCU code, particularly ccu_nkmp.c, and found that
>> it very liberally uses divider parameters, even in situations that are
>> out of spec compared to the current code in the kernel.
>>
>> In the current code and especially in the original vendor code, divider
>> parameters are used as last resort only. Presumably because, of the
>> inherent trouble in changing them, as I described to you in other email.
>>
>> The new ccu code uses dividers often and even at very high frequencies,
>> which goes against the spec.
>>
>> In the vendor code M is never anything else but 0, and P is used only
>> for frequencies below 288MHz, which matches the H3 datasheet, which says:
> 
> In the vendor code, P is never used either. All the boards we had so
> far don't go that low, so we cannot make any of these assumptions,
> especially since the vendor code has had the bad habit of doing
> something wrong and / or useless in the past.

P is used in the arisc firmware according to the spec for the lower
frequencies.

> However, this implementation is a new thing, and it was using the H3
> precisely because of its early stage of support to use it as a testbed
> for the more established.
> 
> If you feel like we should use a different formula to favour the
> multipliers over the dividers (or want to change the class of the CPU
> PLL to an NKM or something else, this is totally doable.

I think the original formula that's currently in the mainline kernel is
better and avoids fiddling with dividers too much.

>> "The P factor only use in the condition that PLL output less than 288
>> MHz."
> 
> And the datasheet also had some issues, either misleading or wrong
> comments in the past. Don't get me wrong, I'm not saying that this is
> wrong, just that we should not follow it religiously, and that we
> should trust more the experiments than the datasheet.

I can believe that. :) Regardless, I think the reasons given for
avoiding dividers are quite reasonable. It's based on how PLL block
works, not what manual says.

>> Also other datasheets of similar socs from Allwinner state that M should
>> not be used in production code.
> 
> Which ones specifically?

A83T for example. You can search for "only for test" phrase.

https://github.com/allwinner-zh/documents/blob/master/A83T/A83T_U

[linux-sunxi] Re: Changed: sunxi-ng clock code - NKMP clock implementation is wrong

[Ondřej Jirman]

Hi Maxime,

I don't have your sunxi-ng clock patches in my mailbox, so I'm replying
to this.

On 26.7.2016 08:32, Maxime Ripard wrote:
> On Thu, Jul 21, 2016 at 11:52:15AM +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.
>>>
>>> That would have the benefit of being quite easy to document, not be a
>>> huge amount of code and it would work on all the CPUs PLLs we have so
>>> far, so still, a pretty big win. If it doesn't, of course, we don't
>>> really have the choice.
>>
>> It's probably more code though. It has to access different register from
>> the one that is already defined in dts, which would add a lot of code
>> and require dts changes. The original patch I sent is simpler than that.
> 
> Why?
> 
> You can use container_of to retrieve the parent structure of the clock
> notifier, and then you get a ccu_common structure pointer, with the
> CCU base address, the clock register, its lock, etc.
> 
> Look at what is done in drivers/clk/meson/clk-cpu.c. It's like 20 LoC.
> 
> I don't really get why anything should be changed in the DT, or why it
> would add a lot of code. Or maybe we're not talking about the same
> thing?

I've looked at the new CCU code, particularly ccu_nkmp.c, and found that
it very liberally uses divider parameters, even in situations that are
out of spec compared to the current code in the kernel.

In the current code and especially in the original vendor code, divider
parameters are used as last resort only. Presumably because, of the
inherent trouble in changing them, as I described to you in other email.

The new ccu code uses dividers often and even at very high frequencies,
which goes against the spec.

In the vendor code M is never anything else but 0, and P is used only
for frequencies below 288MHz, which matches the H3 datasheet, which says:

"The P factor only use in the condition that PLL output less than 288
MHz."

Also other datasheets of similar socs from Allwinner state that M should
not be used in production code. So it may be that they either forgot to
state it in the H3 datasheet, or it can be used. In any case, they never
use M in their code, so it may be wise to keep to that.

When I boot with the new CCU code I get this:

PLL_CPUX = 0x1B21 : M = 2, K = 3, N = 28, P = 1, EN = 0
PLL_CPUX : freq = 1008MHz

Mathematically it works, but it is against the spec.

Also, this:

analyzing CPU 0:
  driver: cpufreq-dt
  CPUs which run at the same hardware frequency: 0 1 2 3
  CPUs which need to have their frequency coordinated by software: 0 1 2 3
  maximum transition latency: 1.74 ms
  hardware limits: 120 MHz - 1.37 GHz
  available frequency steps:  120 MHz, 240 MHz, 480 MHz, 648 MHz, 816
MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.22
GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.37 GHz
  available cpufreq governors: conservative ondemand userspace powersave
performance
  current policy: frequency should be within 240 MHz and 240 MHz.
  The governor "performance" may decide which speed to use
  within this range.
  current CPU frequency: 24.0 MHz (asserted by call to hardware)


Somehow, the new CCU code sets the CPUX to 24MHz no matter what.

I'm using your pen/clk-rework branch without any other patches that were
later sent to the mailing list.

regards,
  Ondrej

> 
> Maxime
> 

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

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

[Ondřej Jirman]

On 26.7.2016 08:32, Maxime Ripard wrote:
> On Thu, Jul 21, 2016 at 11:52:15AM +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.
>>>
>>> That would have the benefit of being quite easy to document, not be a
>>> huge amount of code and it would work on all the CPUs PLLs we have so
>>> far, so still, a pretty big win. If it doesn't, of course, we don't
>>> really have the choice.
>>
>> It's probably more code though. It has to access different register from
>> the one that is already defined in dts, which would add a lot of code
>> and require dts changes. The original patch I sent is simpler than that.
> 
> Why?

Because I don't understand internals of clk subsystem that much. :) So
my guess might be wrong.

Wens send patches implementing clock source switching in the new CCU
code, so hopefully it will work. Ultimately it's a hack. Some internal
parts of the soc may still get into out of the bounds operating state
even if they are gated off from other parts of the SoC, via clock
multiplexing, by improper factors change procedure.

So it doesn't really matter which is more concise in code. As long as
one solution is wrong and other is proper.

Anyway, I'll try with wens's patches, later and see if I trigger some
instability or not.

> You can use container_of to retrieve the parent structure of the clock
> notifier, and then you get a ccu_common structure pointer, with the
> CCU base address, the clock register, its lock, etc.
> 
> Look at what is done in drivers/clk/meson/clk-cpu.c. It's like 20 LoC.
> 
> I don't really get why anything should be changed in the DT, or why it
> would add a lot of code. Or maybe we're not talking about the same
> thing?
> 
> Maxime
> 

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

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

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Ondřej Jirman]

On 25.6.2016 09:02, Maxime Ripard wrote:
> On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
>> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman <meg...@megous.com> wrote:
>>> Hello,
>>>
>>> comments below.
>>>
>>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>>>> On Fri, Jun 24, 2016 at 3:20 AM,  <meg...@megous.com> wrote:
>>>>> From: Ondrej Jirman <meg...@megous.com>
>>>>>
>>>>> Add label to the first cpu so that it can be referenced
>>>>> from derived dts files.
>>>>>
>>>>> Signed-off-by: Ondrej Jirman <meg...@megous.com>
>>>>> ---
>>>>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>>>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> index 9938972..82faefc 100644
>>>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> @@ -52,7 +52,7 @@
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>>
>>>>> -   cpu@0 {
>>>>> +   cpu0: cpu@0 {
>>>>> compatible = "arm,cortex-a7";
>>>>> device_type = "cpu";
>>>>> reg = <0>;
>>>>
>>>> Can you also set the cpu clock here? It is part of the SoC
>>>> and does not belong in the board DTS files.
>>>
>>> Do you mean operating-points, or something else? Different SBCs will
>>> probably require different combinations of operating points just for
>>> safety's sake, because they have different regulators and [some have
>>> botched] thermal designs, so it might make sense to customize it for
>>> differnt boards, and I don't feel adventurous enough setting it for all
>>> H3 boards out there.
>>
>> I meant clocks = <...> and clock-latency = <...>.
>>
>> These 2 are part of the SoC.
>>
>> The OPP can stay in the board files. It's a pity there's no standard
>> OPP table for H3 though. :(
> 
> This has never been the case, and we always had some deviation in the
> FEX files for all the SoCs.
> 
> If we could come up with standard OPPs that work for every one,
> there's no reason it can't happen here.
> 
> I don't really see why the thermal design should change anything. If a
> boards heats faster, it will throttle down to a lower OPP faster, but
> those OPPs are not going to change.

So I tried, and found out that it will not be so easy. Different boards
have different regulators, and linux doesn't deal well with voltages
that are not supported by the regulator.

So even if the board can run at certain frequency if you round the
voltage to the next higher voltage supported by the regulator, opp
implementation doesn't do the rounding and just drops the operating
points that have no support in the voltage regulator.

We have boards that have 1.1/1.3V switching, only 1.3V, fine tuned
voltage regulation and every such board will need it's own set of
operating points.

I'd leave the OPP definitions in the board files for now.

cpu cpu0: _opp_add: OPP not supported by regulators (136800)
core: _opp_supported_by_regulators: OPP minuV: 134 maxuV: 134,
not supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (134400)
core: _opp_supported_by_regulators: OPP minuV: 134 maxuV: 134,
not supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (129600)
core: _opp_supported_by_regulators: OPP minuV: 120 maxuV: 120,
not supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (110400)
core: _opp_supported_by_regulators: OPP minuV: 114 maxuV: 114,
not supported by regulator
cpu cpu0: _opp_add: OPP not supported by regulators (100800)

regards,
  o.

> Maxime
> 

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

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

[Ondřej Jirman]

On 15.7.2016 16:22, Michal Suchanek wrote:
> Hello,
> 
> On 15 July 2016 at 15:48, Ondřej Jirman <meg...@megous.com> wrote:
>>
>>
>> On 15.7.2016 15:27, Jean-Francois Moine wrote:
>>> On Fri, 15 Jul 2016 12:38:54 +0200
>>> Ondřej Jirman <meg...@megous.com> 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!
>>
>> PLL lock time is around 10-20us, I'd guess based on the number of loops
>> in the PLL lock wait loop. So unless you'll be switching frequencies
>> many times per second, this should be barely noticeable.
>>
>> But I'd like a different solution too.
> 
> Do you have a patch to test this?
> 
> For me changing CPU frequency on Orange Pi One always locks up the
> system. I keep running it on the u-boot setup 1.08GHz at 1.1V

Not anymore. But it's quite simple to hack it into the
drivers/clk/sunxi/clk-factors.c:clk_factors_set_rate()

You can look at u-boot arch/arm/mach-sunxi/clock_sun6i.c:clock_set_pll1
for how to change the CPU clock source.

> 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 v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

On 15.7.2016 15:27, Jean-Francois Moine wrote:
> On Fri, 15 Jul 2016 12:38:54 +0200
> Ondřej Jirman <meg...@megous.com> 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!

PLL lock time is around 10-20us, I'd guess based on the number of loops
in the PLL lock wait loop. So unless you'll be switching frequencies
many times per second, this should be barely noticeable.

But I'd like a different solution too.

> BTW, Ondřej, in my BPi M2+, I tried to change the CPU clock with your
> code at kernel start time from 792MHz to 1008MHz, but the hardware
> (arisc?) set an other value, and the system speed was lower than before
> (the PLL-CPUx register is 0x90031521 on boot, I want to set it to
> 1410 and I read 0x91031f33 - sorry, I did not have a look at the
> CPU SD pattern). Do you know why?

No idea. Arisc shouldn't do anything, unless you load some firmware into
it, and release its reset line.

-- 
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 v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

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)


... snip ...
{ .n = 9, .k = 0, .m = 0, .p = 2 }, // 60 => 60 MHz
{ .n = 10, .k = 0, .m = 0, .p = 2 }, // 66 => 66 MHz
{ .n = 11, .k = 0, .m = 0, .p = 2 }, // 72 => 72 MHz
{ .n = 12, .k = 0, .m = 0, .p = 2 }, // 78 => 78 MHz
{ .n = 13, .k = 0, .m = 0, .p = 2 }, // 84 => 84 MHz
{ .n = 14, .k = 0, .m = 0, .p = 2 }, // 90 => 90 MHz
{ .n = 15, .k = 0, .m = 0, .p = 2 }, // 96 => 96 MHz
{ .n = 16, .k = 0, .m = 0, .p = 2 }, // 102 => 102 MHz
{ .n = 17, .k = 0, .m = 0, .p = 2 }, // 108 => 108 MHz
{ .n = 18, .k = 0, .m = 0, .p = 2 }, // 114 => 114 MHz
{ .n = 9, .k = 0, .m = 0, .p = 1 }, // 120 => 120 MHz
{ .n = 10, .k = 0, .m = 0, .p = 1 }, // 126 => 132 MHz
{ .n = 10, .k = 0, .m = 0, .p = 1 }, // 132 => 132 MHz
{ .n = 11, .k = 0, .m = 0, .p = 1 }, // 138 => 144 MHz
{ .n = 11, .k = 0, .m = 0, .p = 1 }, // 144 => 144 MHz
{ .n = 12, .k = 0, .m = 0, .p = 1 }, // 150 => 156 MHz
{ .n = 12, .k = 0, .m = 0, .p = 1 }, // 156 => 156 MHz
{ .n = 13, .k = 0, .m = 0, .p = 1 }, // 162 => 168 MHz
{ .n = 13, .k = 0, .m = 0, .p = 1 }, // 168 => 168 MHz
{ .n = 14, .k = 0, .m = 0, .p = 1 }, // 174 => 180 MHz
{ .n = 14, .k = 0, .m = 0, .p = 1 }, // 180 => 180 MHz
{ .n = 15, .k = 0, .m = 0, .p = 1 }, // 186 => 192 MHz
{ .n = 15, .k = 0, .m = 0, .p = 1 }, // 192 => 192 MHz
{ .n = 16, .k = 0, .m = 0, .p = 1 }, // 198 => 204 MHz
{ .n = 16, .k = 0, .m = 0, .p = 1 }, // 204 => 204 MHz
{ .n = 17, .k = 0, .m = 0, .p = 1 }, // 210 => 216 MHz
{ .n = 17, .k = 0, .m = 0, .p = 1 }, // 216 => 216 MHz
{ .n = 18, .k = 0, .m = 0, .p = 1 }, // 222 => 228 MHz
{ .n = 18, .k = 0, .m = 0, .p = 1 }, // 228 => 228 MHz
{ .n = 9, .k = 0, .m = 0, .p = 0 }, // 234 => 240 MHz
{ .n = 9, .k = 0, .m = 0, .p = 0 }, // 240 => 240 MHz
{ .n = 10, .k = 0, .m = 0, .p = 0 }, // 246 => 264 MHz
{ .n = 10, .k = 0, .m = 0, .p = 0 }, // 252 => 264 MHz
{ .n = 10, .k = 0, .m = 0, .p = 0 }, // 258 => 264 MHz
{ .n = 10, .k = 0, .m = 0, .p = 0 }, // 264 => 264 MHz
{ .n = 11, .k = 0, .m = 0, .p = 0 }, // 270 => 288 MHz
{ .n = 11, .k = 0, .m = 0, .p = 0 }, // 276 => 288 MHz
... snip ...


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

Re: [linux-sunxi] Re: USB OTG on Orange Pi PC

[Ondřej Jirman]

On 1.7.2016 13:19, Michal Suchanek wrote:
> On 1 July 2016 at 13:02, Michal Suchanek <hramr...@gmail.com> wrote:
>> On 30 June 2016 at 22:30, Ondřej Jirman <m...@xff.cz> wrote:
>>> On 30.6.2016 20:21, Michal Suchanek wrote:
>>>> On 30 June 2016 at 20:06, Michal Suchanek <hramr...@gmail.com> wrote:
>>>>> Hello,
>>>>>
>>>>> On 30 June 2016 at 16:44, Ondřej Jirman <m...@xff.cz> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> hopefuly, it was the NPE that I fixed. It was specifically in the H3 usb
>>>>>> phy code path for phy0. So I believe it was untested,
>>>>>> because I didn't find any dts file that would use phy0.
>>>>>>
>>>>>
>>>>> This WorksForMe(TM).
>>>>
>>>> There is still small problem left. When I boot with the USB cable
>>>> connected I have to disconnect and reconnect the cable to get the
>>>> gadget working.
>>>>
>>>
>>> Good to know, I'll test this case. It will probably be something around
>>> the iddet handling during phy0 initialization, which leads to the
>>> connected cable being treated as OTG, which would turn the usb port into
>>> host mode. You can verify that by looking into sysfs where there's an
>>> attribute that tells the current mode (peripheral / host). I don't
>>> rember where exactly it could be found.
>>>
>>
>> This is interesting. The USB gadget works (from the start without 
>> reconnecting)
>> with one PC + hub and fails with other PC + hub. Both pretty much 100%
>>
>> Ironically the broken hub provides sound voltage above 5.1V and the working
>> one should give about 4.75V given its 0.2V drop from the board power level.
> 
> For the record
> 
> /sys/devices/platform/soc/1c19000.usb/musb-hdrc.1.auto/mode is
> b_idle when gadget is broken
> b_peripherial when gadget is working

Hi, you may try adding printks to sun4i_usb_phy0_id_vbus_det_scan in
phy-sun4i-usb.c inside the if (id_notify) and if (vbus_notify), and try
if you can observe any differences between the two hubs in dmesg output.

Or first, I'd suggest to add unconditional "return true" to
sun4i_usb_phy0_poll, if that fixes anything. This will enable polling on
the iddet gpio. (Perhaps gpio interrupts are not very reliable?)

regards,
  Ondrej

> 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 v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

On 1.7.2016 07:37, Jean-Francois Moine wrote:
> On Fri, 1 Jul 2016 02:50:57 +0200
> Ondřej Jirman <meg...@megous.com> wrote:
> 
>>> Since this is really specific, I guess you could simply make the
>>> clk_ops for the nkmp clocks public, and just re-implement set_rate
>>> using that logic.
>>
>> I would argue that this may be necessary for other PLL clocks too, if
>> you can get out of bounds output frequency, by changing the dividers too
>> early or too late. So perhaps this code should be generalized for other
>> PLL clocks too, instead.
> 
> The documentation says that only the CPU and DDR PLLs can be dynamically
> changed after boot.

The question is what exactly is meant by after boot. :) Anyway, if the
kernel has no business changing some other PLLs, if there's code for
changing them, should it be dropped?

regards,
  Ondrej

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

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

[Ondřej Jirman]

On 30.6.2016 16:23, Siarhei Siamashka wrote:
> On Thu, 30 Jun 2016 13:13:48 +0200
> 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?
> 
> Maybe try the Allwinner's original DVFS table instead of these
> undervolted values and see if it helps?
> 
> https://linux-sunxi.org/index.php?title=Xunlong_Orange_Pi_PC=17753#CPU_clock_speed_limit

Thanks, I'll use these. I'm not sure what will happen if regulator is
not capable of providing the exact voltages specified in the operating
points, though. Will it do the sane thing? :)

Also LV6+ in the table is bellow specified minimum voltage in the
datasheet. But then Orange Pi works at much lower voltages for me.

Conversly LV1 is the absolute maximum. Recommended maximum is 1.4V So I
would not use that.

It might be nice to have something like that dram clock test, but for
cpux freq/voltage, and collect some statistics.

regards,
  Ondrej

> While undervolting is tempting because it helps to decrease the SoC
> temperature and avoid throttling, different units may have different
> tolerances and one needs to be very careful when picking defaults
> that are intended to work correctly on all boards. Some safety
> headroom exists there for a reason.
> 
> If I remember correctly, some people pushed for undervolting experiments
> at least twice in the past (on the Banana Pi and C.H.I.P.). In both
> cases this did not end up well and had to be fixed later to solve
> reliability problems.
> 
> In order to allow individual per-unit tuning, a concept of "speed
> grading" may be probably introduced later. So that the board is tested
> for reliability and then the speed grade rating is stored somewhere on
> the non-removable storage (EEPROM, SPI flash, eFUSE, ...). Some SoC
> manufacturers, such as Samsung, are already doing this with their chips.
> 

-- 
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 v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

On 30.6.2016 22:40, Maxime Ripard wrote:
> Hi,
> 
> On Sat, Jun 25, 2016 at 05:45:03AM +0200, meg...@megous.com wrote:
>> From: Ondrej Jirman 
>>
>> PLL1 on H3 requires special factors application algorithm,
>> when the rate is changed. This algorithm was extracted
>> from the arisc code that handles frequency scaling
>> in the BSP kernel.
>>
>> This commit adds optional apply function to
>> struct factors_data, that can implement non-trivial
>> factors application method, when necessary.
>>
>> Also struct clk_factors_config is extended with position
>> of the PLL lock flag.
> 
> Have you tested the current implementation, and found that it was not
> working, or did you duplicate the arisc code directly?

Also of note is that similar code probably doesn't crash in u-boot,
because there, before changing the PLL1 clock, the cpu is switched to
24MHz osc, so it is not overclocked, even if factors align in such a way
that you'd get the behavior I described in the other email.

>>  /**
>> + * 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.
> 
>> +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.
> 
>> +
>> +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);
>> +}
>> +
>> +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);
>> +}
> 
> However, this is kind of weird, why would you need to re-apply the
> dividers? Nothing really changes. Have you tried without that part?
> 
> Since this is really specific, I guess you could simply make the
> clk_ops for the nkmp clocks public, and just re-implement set_rate
> using that logic.
> 
> You might also need to set an upper limit on P, since the last value
> (4) is not a valid one.
> 
> I guess you could do that by adding a max field in the __ccu_div
> structure.
> 
> Maxime
> 

-- 
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 v2 06/14] ARM: sun8i: clk: Add clk-factor rate application method

[Ondřej Jirman]

Hi,

On 30.6.2016 22:40, Maxime Ripard wrote:
> Hi,
> 
> On Sat, Jun 25, 2016 at 05:45:03AM +0200, meg...@megous.com wrote:
>> From: Ondrej Jirman 
>>
>> PLL1 on H3 requires special factors application algorithm,
>> when the rate is changed. This algorithm was extracted
>> from the arisc code that handles frequency scaling
>> in the BSP kernel.
>>
>> This commit adds optional apply function to
>> struct factors_data, that can implement non-trivial
>> factors application method, when necessary.
>>
>> Also struct clk_factors_config is extended with position
>> of the PLL lock flag.
> 
> Have you tested the current implementation, and found that it was not
> working, or did you duplicate the arisc code directly?

I have tested the current implementation, and it was not working. It
depended on some other factors, like the initial setup done by u-boot.
It didn't work reliably.

Then I reverse engineered arisc, in an effort to see what's the
difference, between mainline and BSP code.

>>  /**
>> + * 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.

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

>> +
>> +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);
>> +}
>> +
>> +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);
>> +}
> 
> However, this is kind of weird, why would you need to re-apply the
> dividers? Nothing really changes. Have you tried without that part?

See above, we either increase before PLL change, or reduce dividers
after the change. Nothing is re-applied.

> Since this is really specific, I guess you could simply make the
> clk_ops for the nkmp clocks public, and just re-implement set_rate
> using that logic.

I would argue that this may be necessary for other PLL clocks too, if
you can 

Re: [linux-sunxi] Re: USB OTG on Orange Pi PC

[Ondřej Jirman]

On 30.6.2016 20:21, Michal Suchanek wrote:
> On 30 June 2016 at 20:06, Michal Suchanek <hramr...@gmail.com> wrote:
>> Hello,
>>
>> On 30 June 2016 at 16:44, Ondřej Jirman <m...@xff.cz> wrote:
>>> Hi,
>>>
>>> hopefuly, it was the NPE that I fixed. It was specifically in the H3 usb
>>> phy code path for phy0. So I believe it was untested,
>>> because I didn't find any dts file that would use phy0.
>>>
>>
>> This WorksForMe(TM).
> 
> There is still small problem left. When I boot with the USB cable
> connected I have to disconnect and reconnect the cable to get the
> gadget working.
> 

Good to know, I'll test this case. It will probably be something around
the iddet handling during phy0 initialization, which leads to the
connected cable being treated as OTG, which would turn the usb port into
host mode. You can verify that by looking into sysfs where there's an
attribute that tells the current mode (peripheral / host). I don't
rember where exactly it could be found.

Or you can force the mode to peripheral in the dts. That may be a
workaround for now.

regards,
  o.

>>
>>>
>>> On 30.6.2016 07:17, boob...@gmail.com wrote:
>>>> Nice work.
>>>> Sure i will try your path, last time i tried otg i had kernel exception 
>>>> when loading musb driver.
>>>> I would like setup usb otg in device mode as g_ether or cdrom drive 
>>>> emulation to loading bootable iso with gpio sw for iso selection yes i 
>>>> dream :)
> 
> Actually, the cdrom drive emulation is not out of question. You will
> need to tune the linux mass storage gadget to identify as CD-rom
> rather than USB stick. I wanted this for IDE CD-rom. The systems that
> boot from USB CD-rom usually can do USB stick too.
> 
> 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

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

[Ondřej Jirman]

On 30.6.2016 17:50, Michal Suchanek wrote:
> On 30 June 2016 at 17:16, Michal Suchanek <hramr...@gmail.com> wrote:
>> On 30 June 2016 at 16:19, Ondřej Jirman <meg...@megous.com> wrote:
>>> Hello,
>>>
>>> On 30.6.2016 13:13, Michal Suchanek wrote:
>>>> Hello,
>>>>
>>>> On 25 June 2016 at 05:45,  <meg...@megous.com> wrote:
>>>>> From: Ondrej Jirman <meg...@megous.com>
>>>>>
>>>>> Use Xulong Orange Pi One GPIO based regulator for
>>>>> passive cooling and thermal management.
>>>>>
>>>>> Signed-off-by: Ondrej Jirman <meg...@megous.com>
>>>>> ---
>>>>>  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?
>>>
>>> Just to verify, did you test with the entire series applied? (especially
>>> the PLL1 clk application changes)
>>
>> Yes, I applied the whole series.
>>
>>>
>>> You may try dropping the highest operating point, it's probably overly
>>> optimistic for Orange Pi One.
>>>
>>> Is the power supply/cable you're using hard enough?
>>
>> I use a 7 port hub to power the board. It worked with some other small
>> devboards.
>>
>> The cable is some random Chinese USB to power jack adaptor with an
>> extra adaptor to fit the Pi socket. It looks ok but I did not test
>> this particular combination thoroughly.
>>
>>>
>>> Where during the boot process does it lock up?
>>
>> Usually sometime around enabling cpufreq  before getty starts.
>> Different runs and settings give slightly different results. In
>> particular adding the 1008000 point seems to make it go further.
>>
>> Removing all traces of the regulator, cpufreq and thermal I can boot
>> pretty much 100% to login prompt.
>>
>> I don't think the difference between 1GHz and 1.3GHz frequency on the
>> core would put much additional stress on the supply but I can try with
>> 35W PSU and some alternative cabling to be sure.
>>
>> I did some more tests and it seems 1008000@1.1V is fine but switching
>> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
>> there is need for some delay somewhere for the regulator to get
>> stable?
>>
> 
> Hm, the AW table shows 1008000@1.3V as supported state and it indeed
> works. So the voltage switching works or does nothing. Can I measure
> the regulator output somewhere? Clocking the chip higher does not
> work.

Regulator output is TP1 on the bottom of the board, next ot the CSI
connector.

regards,
  Ondrej

> I will try with another PSU later.
> 
> 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

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

[Ondřej Jirman]

On 30.6.2016 17:16, Michal Suchanek wrote:
> On 30 June 2016 at 16:19, Ondřej Jirman <meg...@megous.com> wrote:
>> Hello,
>>
>> On 30.6.2016 13:13, Michal Suchanek wrote:
>>> Hello,
>>>
>>> On 25 June 2016 at 05:45,  <meg...@megous.com> wrote:
>>>> From: Ondrej Jirman <meg...@megous.com>
>>>>
>>>> Use Xulong Orange Pi One GPIO based regulator for
>>>> passive cooling and thermal management.
>>>>
>>>> Signed-off-by: Ondrej Jirman <meg...@megous.com>
>>>> ---
>>>>  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?
>>
>> Just to verify, did you test with the entire series applied? (especially
>> the PLL1 clk application changes)
> 
> Yes, I applied the whole series.
> 
>>
>> You may try dropping the highest operating point, it's probably overly
>> optimistic for Orange Pi One.
>>
>> Is the power supply/cable you're using hard enough?
> 
> I use a 7 port hub to power the board. It worked with some other small
> devboards.
> 
> The cable is some random Chinese USB to power jack adaptor with an
> extra adaptor to fit the Pi socket. It looks ok but I did not test
> this particular combination thoroughly.
> 
>>
>> Where during the boot process does it lock up?
> 
> Usually sometime around enabling cpufreq  before getty starts.
> Different runs and settings give slightly different results. In
> particular adding the 1008000 point seems to make it go further.
> 
> Removing all traces of the regulator, cpufreq and thermal I can boot
> pretty much 100% to login prompt.
> 
> I don't think the difference between 1GHz and 1.3GHz frequency on the
> core would put much additional stress on the supply but I can try with
> 35W PSU and some alternative cabling to be sure.
> 
> I did some more tests and it seems 1008000@1.1V is fine but switching
> to 1.3V crashes the board. Even with only the first 1.3V state. Maybe
> there is need for some delay somewhere for the regulator to get
> stable?

Please try adding:

  regulator-ramp-delay = <10>

to the gpio regulator.

which will allow 100ms per 1V change, which should b enough for
determining, if this is the cause.

regards,
  Ondrej

> 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: USB OTG on Orange Pi PC

[Ondřej Jirman]

Hi,

hopefuly, it was the NPE that I fixed. It was specifically in the H3 usb
phy code path for phy0. So I believe it was untested,
because I didn't find any dts file that would use phy0.

Good luck with the audio driver.

regards,
  o.



On 30.6.2016 07:17, boob...@gmail.com wrote:
> Nice work.
> Sure i will try your path, last time i tried otg i had kernel exception when 
> loading musb driver.
> I would like setup usb otg in device mode as g_ether or cdrom drive emulation 
> to loading bootable iso with gpio sw for iso selection yes i dream :)
> 
> But for now I try to translate audio codec driver from kernel 3.4,,,removing 
> lot of config from fex file, remove undocumented R-PRCM (0x01f01400) 
> read/Write (seem to be configuration area for current setting to restore 
> after a reboot, not vital..), setup PLL2 (audio_pll) directly in driver since 
> there isn't no clk driver PLL2 for now (I think it's related to I2S driver, 
> and it's a complex clock with multi factor to adjust PLL frequency). For now 
> i just configure it at 24.57Mhz/22.57Mhz and i have succes to have something 
> in /sys/class/device/sunxi_codec/ and /sunxi-pcm-codec/, no kernel exception 
> but no sound card available :(
> When i see in sun4i audio driver, there is lot of new code to create card in 
> /dev/snd/... 
> It's seem I'm lost deeply in nowhere for now, but I will try your work for 
> sure (just one source of kernel opps at the same time!).
> 

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

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

[Ondřej Jirman]

Hello,

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?

Just to verify, did you test with the entire series applied? (especially
the PLL1 clk application changes)

You may try dropping the highest operating point, it's probably overly
optimistic for Orange Pi One.

Is the power supply/cable you're using hard enough?

Where during the boot process does it lock up?

regards,
  Ondrej

> 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 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Ondřej Jirman]

On 29.6.2016 22:45, Maxime Ripard wrote:
> Hi,
> 
> On Sat, Jun 25, 2016 at 04:50:24PM +0200, Ondřej Jirman wrote:
>> On 25.6.2016 09:02, Maxime Ripard wrote:
>>> On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
>>>> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman <meg...@megous.com> wrote:
>>>>> Hello,
>>>>>
>>>>> comments below.
>>>>>
>>>>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>>>>>> On Fri, Jun 24, 2016 at 3:20 AM,  <meg...@megous.com> wrote:
>>>>>>> From: Ondrej Jirman <meg...@megous.com>
>>>>>>>
>>>>>>> Add label to the first cpu so that it can be referenced
>>>>>>> from derived dts files.
>>>>>>>
>>>>>>> Signed-off-by: Ondrej Jirman <meg...@megous.com>
>>>>>>> ---
>>>>>>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>>>>>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>>>> index 9938972..82faefc 100644
>>>>>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>>>> @@ -52,7 +52,7 @@
>>>>>>> #address-cells = <1>;
>>>>>>> #size-cells = <0>;
>>>>>>>
>>>>>>> -   cpu@0 {
>>>>>>> +   cpu0: cpu@0 {
>>>>>>> compatible = "arm,cortex-a7";
>>>>>>> device_type = "cpu";
>>>>>>> reg = <0>;
>>>>>>
>>>>>> Can you also set the cpu clock here? It is part of the SoC
>>>>>> and does not belong in the board DTS files.
>>>>>
>>>>> Do you mean operating-points, or something else? Different SBCs will
>>>>> probably require different combinations of operating points just for
>>>>> safety's sake, because they have different regulators and [some have
>>>>> botched] thermal designs, so it might make sense to customize it for
>>>>> differnt boards, and I don't feel adventurous enough setting it for all
>>>>> H3 boards out there.
>>>>
>>>> I meant clocks = <...> and clock-latency = <...>.
>>>>
>>>> These 2 are part of the SoC.
>>>>
>>>> The OPP can stay in the board files. It's a pity there's no standard
>>>> OPP table for H3 though. :(
>>>
>>> This has never been the case, and we always had some deviation in the
>>> FEX files for all the SoCs.
>>>
>>> If we could come up with standard OPPs that work for every one,
>>> there's no reason it can't happen here.
>>>
>>> I don't really see why the thermal design should change anything. If a
>>> boards heats faster, it will throttle down to a lower OPP faster, but
>>> those OPPs are not going to change.
>>
>> I've no way to test, but I've been told some Sinovoip boards are really
>> bad in this regard (SoC is not even well thermally connected to the
>> PCB/PCB not having copper layer to spread the heat). Thermal sensor
>> readings happen at fixed intervals, so the question is if you can heat
>> up the soc from say 80°C (first trip point) to over 110°C in less than
>> that period (330ms currently).
>>
>> I say it shouldn't be a problem, if that small thing is drawing say 2W
>> at max load. It will burn or trigger a second trip point before the
>> first one has a chance to trigger and the kernel will shut down. I
>> remember tkaiser saying that he has to run that board at 240MHz max. But
>> perhaps I'm misremembering.
>>
>> I'm just speculating.
> 
> Yes, but that's just poor thermal design. What I was saying is that
> even if we really need to throttle the SoC to 240 MHz on that board
> because it heats too much, the couple of the frequency and the voltage
> will likely be the same across all boards. It's just the amount of
> time we'll spend using it that will differ.
> 
> But that's just my understanding, I might be speaking non-sense :)
> 
> Maxime
> 

You're probably right. Operating points should be part of h3.dtsi, and
if some board is particularly bad, and can't handle being above certain
frequency safely, due to thermal design issues, we can override
operating points in its dts file.

regards,
  Ondrej

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

Re: [linux-sunxi] [PATCH 1/3] clk: sunxi: Add a driver for the CCU

[Ondřej Jirman]

On 28.6.2016 17:37, Jean-Francois Moine wrote:
> Most of the clocks in the Allwinner's SoCs are configured in the CCU
> (Clock Configuration Unit).
> 
> The PLL clocks are driven from the main clock. Their rates are controlled
> by a set of multiply and divide factors, named from the Allwinner's
> documentation:
> - multipliers: 'n' and 'k'
> - dividers: 'd1', 'd2', 'm' and 'p'
> 
> The peripheral clocks may receive their inputs from one or more parents,
> thanks to a mux. Their rates are controlled by a set of divide factors
> only, named 'm' and 'p'.
> 
> This driver also handles:
> - fixed clocks,
> - the phase delays for the MMCs,
> - the clock gates,
> - the bus gates,
> - and the resets.
> 
> Signed-off-by: Jean-Francois Moine 
> ---
>  drivers/clk/sunxi/Makefile |   2 +
>  drivers/clk/sunxi/ccu.c| 980 
> +
>  drivers/clk/sunxi/ccu.h| 153 +++
>  3 files changed, 1135 insertions(+)
>  create mode 100644 drivers/clk/sunxi/ccu.c
>  create mode 100644 drivers/clk/sunxi/ccu.h
> 
> diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> index 39d2044..b8ca3e2 100644
> --- a/drivers/clk/sunxi/Makefile
> +++ b/drivers/clk/sunxi/Makefile
> @@ -26,3 +26,5 @@ obj-$(CONFIG_MACH_SUN9I) += clk-sun9i-cpus.o
>  obj-$(CONFIG_MFD_SUN6I_PRCM) += \
>   clk-sun6i-ar100.o clk-sun6i-apb0.o clk-sun6i-apb0-gates.o \
>   clk-sun8i-apb0.o
> +
> +obj-y += ccu.o
> diff --git a/drivers/clk/sunxi/ccu.c b/drivers/clk/sunxi/ccu.c
> new file mode 100644
> index 000..5749f9c
> --- /dev/null
> +++ b/drivers/clk/sunxi/ccu.c
> @@ -0,0 +1,980 @@
> +/*
> + * Allwinner system CCU
> + *
> + * Copyright (C) 2016 Jean-Francois Moine 
> + * Rewrite from 'sunxi-ng':
> + * Copyright (C) 2016 Maxime Ripard 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "ccu.h"
> +
> +#define CCU_DEBUG 0
> +
> +#define CCU_MASK(shift, width) (((1 << width) - 1) << shift)
> +

You may use macros from:

http://lxr.free-electrons.com/source/include/linux/bitops.h

At least as a basis for the CCU_MASK macro.

> +/*
> + * factors:
> + *   n: multiplier (PLL)
> + *   d1, d2: boolean dividers by 2 (d2 is p with 1 bit width - PLL)
> + *   k: multiplier (PLL)
> + *   m: divider
> + *   p: divider by power of 2
> + */
> +struct values {
> + int n, d1, k, m, p;
> +};
> +
> +static DEFINE_SPINLOCK(ccu_lock);
> +
> +void ccu_set_clock(struct ccu *ccu, int reg, u32 mask, u32 val)
> +{
> +
> +#if CCU_DEBUG
> + pr_info("** ccu %s set %03x %08x\n",
> + clk_hw_get_name(>hw), reg,
> + (readl(ccu->base + reg) & ~mask) | val);
> +#endif
> + spin_lock(_lock);
> + writel((readl(ccu->base + reg) & ~mask) | val, ccu->base + reg);
> + spin_unlock(_lock);
> +}
> +
> +/* --- prepare / enable --- */
> +int ccu_prepare(struct clk_hw *hw)
> +{
> + struct ccu *ccu = hw2ccu(hw);
> +
> + if (!ccu->reset_reg && !ccu->bus_reg)
> + return 0;
> +
> +#if CCU_DEBUG
> + pr_info("** ccu %s prepare\n", clk_hw_get_name(>hw));
> +#endif
> + spin_lock(_lock);
> + if (ccu->reset_reg)
> + writel(readl(ccu->base + ccu->reset_reg) |
> + BIT(ccu->reset_bit),
> + ccu->base + ccu->reset_reg);
> + if (ccu->bus_reg)
> + writel(readl(ccu->base + ccu->bus_reg) | BIT(ccu->bus_bit),
> + ccu->base + ccu->bus_reg);
> + spin_unlock(_lock);
> +
> + return 0;
> +}
> +
> +void ccu_unprepare(struct clk_hw *hw)
> +{
> + struct ccu *ccu = hw2ccu(hw);
> +
> + if (!ccu->reset_reg && !ccu->bus_reg)
> + return;
> +
> +#if CCU_DEBUG
> + pr_info("** ccu %s unprepare\n", clk_hw_get_name(>hw));
> +#endif
> + spin_lock(_lock);
> + if (ccu->bus_reg)
> + writel(readl(ccu->base + ccu->bus_reg) & ~BIT(ccu->bus_bit),
> + ccu->base + ccu->bus_reg);
> + if (ccu->reset_reg)
> + writel(readl(ccu->base + ccu->reset_reg) &
> + ~BIT(ccu->reset_bit),
> + ccu->base + ccu->reset_reg);
> + spin_unlock(_lock);
> +}
> +
> +int ccu_enable(struct clk_hw *hw)
> +{
> + struct ccu *ccu = hw2ccu(hw);
> +
> + if (!ccu->has_gate)
> + return 0;
> +
> +#if CCU_DEBUG
> + pr_info("** ccu %s enable\n", clk_hw_get_name(>hw));
> +#endif
> + spin_lock(_lock);
> + writel(readl(ccu->base + ccu->reg) | BIT(ccu->gate_bit),
> + ccu->base + ccu->reg);
> + 

[linux-sunxi] USB OTG on Orange Pi PC

[Ondřej Jirman]

Hi,

if anyone wants to play with the OTG port support on Orange Pi PC, you
can try these patches:

https://files.megous.com/orange-pi-dvfs/linux-4.7-OrangePI/usb-otg/

I don't have much time to test it extensively, but it seems to work.

I'm not yet submitting them "formally". This is just a heads up that I'm
doing some work on configuring this and making it work on this SBC.

Early testing is very welcome. :)

regards,
  Ondrej Jirman

-- 
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 v2 04/14] regulator: SY8106A regulator driver

[Ondřej Jirman]

On 27.6.2016 16:54, Mark Brown wrote:
> On Sun, Jun 26, 2016 at 05:07:16PM +0200, Ondřej Jirman wrote:
>> On 26.6.2016 13:26, Mark Brown wrote:
> 
>>> I'm missing almost all of this series, I've just got this and another
>>> patch which look like a standalone driver so it's hard to see any
>>> dependencies.  What's going on here?
> 
>> Sorry, it's this series:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/438981.html
> 
>> And here's v1 intro letter:
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/438794.html
> 
> These aren't really enlightening I'm afraid, there's nothing in there
> about why these are a single series and no dependency information.
> Indeed it looks like something is really confused as the thread is
> missing at least patches 2 and 3.
> 

You're right there's not much about the regulator there. Xulong Orange
Pi PC is ARM SBC, that uses Allwinner H3 Soc, to which this regulator is
connected via I2C bus, to regulate the main CPU supply voltage. It is
used on some other SBC's from Xulong.

It is fairly simple single output, fixed I2C address voltage regulator.
It has just 3 registers, which allow for: slew rate control (not used in
this driver), setting and reading out the voltage, switching between
voltage set via I2C and via external resistor divider and
enabling/disabling output. It also has status reporting for
over-tempertature and over-current conditions. That's all the features
it has.

The patch series uses it to provide dynamic vltage scaling of the ARM
cores in the SoC to be able to achieve higher CPU frequency.

Datasheet is here:

https://01916271185794791722.googlegroups.com/attach/93415fbd5402/SY8106A_datasheet.pdf?part=0.1=ANaJVrHMej8w8XRfd-7A3XoyiryMDDhrHU2SS-tYyHCpOIXRqIaICOIlZTWAUV74vToesmic457zPvODDuvrNnRpomPOPbtV8bMMFV65VX5aYb5NciMkh8E

I'll also include this information in the revised patch.

thank you and regards,
  Ondrej Jirman

-- 
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 v2 05/14] dt-bindings: document SY8106A regulator driver

[Ondřej Jirman]

On 26.6.2016 13:27, Mark Brown wrote:
> On Sat, Jun 25, 2016 at 05:45:02AM +0200, meg...@megous.com wrote:
>> From: Ondrej Jirman 
>>
>> This patch adds the binding documentation for the
>> sy8106a regulator driver.
> 
> Please submit patches using subject lines reflecting the style for the
> subsystem.  This makes it easier for people to identify relevant
> patches.
> 

Hello, I assume that means "regulator: dt-bindings: ..." in this case.
I'll keep that in mind in the future. Thank you.

-- 
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 04/14] regulator: SY8106A regulator driver

[Ondřej Jirman]

On 26.6.2016 13:26, Mark Brown wrote:
> On Sat, Jun 25, 2016 at 05:45:01AM +0200, meg...@megous.com wrote:
>> From: Ondrej Jirman 
>>
>> SY8106A is I2C attached single output voltage regulator
>> made by Silergy.
> 
> I'm missing almost all of this series, I've just got this and another
> patch which look like a standalone driver so it's hard to see any
> dependencies.  What's going on here?
> 

Sorry, it's this series:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/438981.html

And here's v1 intro letter:
http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/438794.html

regards,
  Ondrej Jirman

-- 
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 01/14] ARM: clk: sunxi: Add driver for the H3 THS clock

[Ondřej Jirman]

Hi Maxime,

I try to base everything on the torvalds's kernel.

I did notice the patches. Is there some main git tree/branch where this
work is tracked in? I'd gladly use it.

Also there's a PLL1 rate application patch, that would need to be ported
to the new CCU code, in the case I would use it as a base for this work.
Given that the new CCU code is your work and it's fresh in your mind, do
you have suggestion how to approach it?

It is [PATCH v2 06/14] in this series.

regards,
  o.

On 25.6.2016 09:13, Maxime Ripard wrote:
> Hi,
> 
> On Sat, Jun 25, 2016 at 05:44:58AM +0200, meg...@megous.com wrote:
>> From: Josef Gajdusek 
>>
>> This patch adds a driver for the THS clock which is present on the
>> Allwinner H3.
>>
>> Signed-off-by: Josef Gajdusek 
> 
> You might not have noticed, but we are currently rewriting the whole
> clock support for the Allwinner SoCs, targetting the H3 as the first
> SoC to use it.
> 
> There's already some support for the H3 THS clock, so please use that
> instead.
> 
> Thanks!
> Maxime
> 

-- 
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 02/14] thermal: sun8i_ths: Add support for the thermal sensor on Allwinner H3

[Ondřej Jirman]

On 25.6.2016 09:10, Maxime Ripard wrote:
> On Sat, Jun 25, 2016 at 05:44:59AM +0200, meg...@megous.com wrote:
>> From: Ondrej Jirman <meg...@megous.com>
>>
>> This patch adds support for the sun8i thermal sensor on
>> Allwinner H3 SoC.
>>
>> Signed-off-by: Ondřej Jirman <meg...@megous.com>
>> ---
>> v2:
>> - removed incorrect use of SID driver in sun8i_ths
>> - read calibration data directly from iomem  
>> - better explanation for the thermal sensor driver
>> - dt documentation fixes
>> - dropped unncecessary macros and init code reorganization
>> - moved resource aquisition from init to probe function
>> - deassert reset after clock rate is set, not before
>> - enable irq after all other registers are configured
>> ---
>>  drivers/thermal/Kconfig |   7 ++
>>  drivers/thermal/Makefile|   1 +
>>  drivers/thermal/sun8i_ths.c | 260 
>> 
>>  3 files changed, 268 insertions(+)
>>  create mode 100644 drivers/thermal/sun8i_ths.c
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 2d702ca..d3209d9 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -351,6 +351,13 @@ config MTK_THERMAL
>>Enable this option if you want to have support for thermal management
>>controller present in Mediatek SoCs
>>  
>> +config SUN8I_THS
>> +tristate "Thermal sensor driver for Allwinner H3"
>> +depends on MACH_SUN8I
>> +depends on OF
>> +help
>> +  Enable this to support thermal reporting on some newer Allwinner SoCs.
>> +
>>  menu "Texas Instruments thermal drivers"
>>  depends on ARCH_HAS_BANDGAP || COMPILE_TEST
>>  depends on HAS_IOMEM
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 10b07c1..7261ee8 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -51,3 +51,4 @@ obj-$(CONFIG_TEGRA_SOCTHERM)   += tegra/
>>  obj-$(CONFIG_HISI_THERMAL) += hisi_thermal.o
>>  obj-$(CONFIG_MTK_THERMAL)   += mtk_thermal.o
>>  obj-$(CONFIG_GENERIC_ADC_THERMAL)   += thermal-generic-adc.o
>> +obj-$(CONFIG_SUN8I_THS) += sun8i_ths.o
>> diff --git a/drivers/thermal/sun8i_ths.c b/drivers/thermal/sun8i_ths.c
>> new file mode 100644
>> index 000..9ba0f96
>> --- /dev/null
>> +++ b/drivers/thermal/sun8i_ths.c
>> @@ -0,0 +1,260 @@
>> +/*
>> + * Thermal sensor driver for Allwinner H3 SoC
>> + *
>> + * Copyright (C) 2016 Ondřej Jirman
>> + * Based on the work of Josef Gajdusek <a...@atx.name>
>> + *
>> + * This software is licensed under the terms of the GNU General Public
>> + * License version 2, as published by the Free Software Foundation, and
>> + * may be copied, distributed, and modified under those terms.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define THS_H3_CTRL00x00
>> +#define THS_H3_CTRL20x40
>> +#define THS_H3_INT_CTRL 0x44
>> +#define THS_H3_STAT 0x48
>> +#define THS_H3_FILTER   0x70
>> +#define THS_H3_CDATA0x74
>> +#define THS_H3_DATA 0x80
>> +
>> +#define THS_H3_CTRL0_SENSOR_ACQ0(x) (x)
>> +#define THS_H3_CTRL2_SENSE_EN   BIT(0)
>> +#define THS_H3_CTRL2_SENSOR_ACQ1(x) ((x) << 16)
>> +#define THS_H3_INT_CTRL_DATA_IRQ_EN BIT(8)
>> +#define THS_H3_INT_CTRL_THERMAL_PER(x)  ((x) << 12)
>> +#define THS_H3_STAT_DATA_IRQ_STSBIT(8)
>> +#define THS_H3_FILTER_TYPE(x)   ((x) << 0)
>> +#define THS_H3_FILTER_ENBIT(2)
>> +
>> +#define THS_H3_CLK_IN 4000  /* Hz */
>> +#define THS_H3_DATA_PERIOD 330  /* ms */
>> +
>> +#define THS_H3_FILTER_TYPE_VALUE2  /* average over 2^(n+1) 
>> samples */
>> +#define THS_H3_FILTER_DIV   (1 << (THS_H3_FILTER_TYPE_VALUE 
>> + 1))
>> +#define THS_H3_INT_CTRL_THERMAL_PER_VALUE \
>> +(THS_H3_DATA_PERIOD * (THS_H3_CLK_IN / 1

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Ondřej Jirman]

On 25.6.2016 09:02, Maxime Ripard wrote:
> On Sat, Jun 25, 2016 at 09:02:48AM +0800, Chen-Yu Tsai wrote:
>> On Sat, Jun 25, 2016 at 6:51 AM, Ondřej Jirman <meg...@megous.com> wrote:
>>> Hello,
>>>
>>> comments below.
>>>
>>> On 24.6.2016 05:48, Chen-Yu Tsai wrote:
>>>> On Fri, Jun 24, 2016 at 3:20 AM,  <meg...@megous.com> wrote:
>>>>> From: Ondrej Jirman <meg...@megous.com>
>>>>>
>>>>> Add label to the first cpu so that it can be referenced
>>>>> from derived dts files.
>>>>>
>>>>> Signed-off-by: Ondrej Jirman <meg...@megous.com>
>>>>> ---
>>>>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>>>>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> index 9938972..82faefc 100644
>>>>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>>>>> @@ -52,7 +52,7 @@
>>>>> #address-cells = <1>;
>>>>> #size-cells = <0>;
>>>>>
>>>>> -   cpu@0 {
>>>>> +   cpu0: cpu@0 {
>>>>> compatible = "arm,cortex-a7";
>>>>> device_type = "cpu";
>>>>> reg = <0>;
>>>>
>>>> Can you also set the cpu clock here? It is part of the SoC
>>>> and does not belong in the board DTS files.
>>>
>>> Do you mean operating-points, or something else? Different SBCs will
>>> probably require different combinations of operating points just for
>>> safety's sake, because they have different regulators and [some have
>>> botched] thermal designs, so it might make sense to customize it for
>>> differnt boards, and I don't feel adventurous enough setting it for all
>>> H3 boards out there.
>>
>> I meant clocks = <...> and clock-latency = <...>.
>>
>> These 2 are part of the SoC.
>>
>> The OPP can stay in the board files. It's a pity there's no standard
>> OPP table for H3 though. :(
> 
> This has never been the case, and we always had some deviation in the
> FEX files for all the SoCs.
> 
> If we could come up with standard OPPs that work for every one,
> there's no reason it can't happen here.
> 
> I don't really see why the thermal design should change anything. If a
> boards heats faster, it will throttle down to a lower OPP faster, but
> those OPPs are not going to change.

I've no way to test, but I've been told some Sinovoip boards are really
bad in this regard (SoC is not even well thermally connected to the
PCB/PCB not having copper layer to spread the heat). Thermal sensor
readings happen at fixed intervals, so the question is if you can heat
up the soc from say 80°C (first trip point) to over 110°C in less than
that period (330ms currently).

I say it shouldn't be a problem, if that small thing is drawing say 2W
at max load. It will burn or trigger a second trip point before the
first one has a chance to trigger and the kernel will shut down. I
remember tkaiser saying that he has to run that board at 240MHz max. But
perhaps I'm misremembering.

I'm just speculating.

regards,
  Ondrej



> Maxime
> 

-- 
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 03/14] thermal: Add support for sun8i THS on Allwinner H3

[Ondřej Jirman]

On 25.6.2016 02:54, Chen-Yu Tsai wrote:
> On Sat, Jun 25, 2016 at 8:35 AM, Ondřej Jirman <meg...@megous.com> wrote:
>> On 24.6.2016 05:09, Chen-Yu Tsai wrote:
>>>> +static int sun8i_ths_h3_init(struct platform_device *pdev,
>>>> +struct sun8i_ths_data *data)
>>>> +{
>>>> +   int ret;
>>>> +   size_t callen;
>>>> +   s32 *caldata;
>>>> +
>>>> +   data->busclk = devm_clk_get(>dev, "ahb");
>>>> +   if (IS_ERR(data->busclk)) {
>>>> +   ret = PTR_ERR(data->busclk);
>>>> +   dev_err(>dev, "failed to get ahb clk: %d\n", ret);
>>>> +   return ret;
>>>> +   }
>>>> +
>>>> +   data->clk = devm_clk_get(>dev, "ths");
>>>> +   if (IS_ERR(data->clk)) {
>>>> +   ret = PTR_ERR(data->clk);
>>>> +   dev_err(>dev, "failed to get ths clk: %d\n", ret);
>>>> +   return ret;
>>>> +   }
>>>> +
>>>> +   data->reset = devm_reset_control_get(>dev, "ahb");
>>>
>>> IIRC with the new shared reset control stuff merged, you are supposed
>>> to specify whether you want a shared or exclusive one when you ask for
>>> it.
>>
>> Here devm_reset_control_get will get the exclusive reference. So this
>> should be ok.
> 
> See https://patchwork.kernel.org/patch/9158691/
> 
> The generic ones might be removed later on. I remember in another thread
> it was asked that new users should use the explicit API, and avoid having
> to be converted.

I see, thank you, I'll change that.

regards,
  Ondrej

> ChenYu
> 
>>
>> regards,
>>   Ondrej
>>
>>>
>>> Regards
>>> ChenYu
>>>
>>>> +MODULE_LICENSE("GPL v2");
>>>> --
>>>> 2.9.0
>>>>
>>

-- 
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 03/14] thermal: Add support for sun8i THS on Allwinner H3

[Ondřej Jirman]

On 24.6.2016 05:09, Chen-Yu Tsai wrote:
>> +static int sun8i_ths_h3_init(struct platform_device *pdev,
>> +struct sun8i_ths_data *data)
>> +{
>> +   int ret;
>> +   size_t callen;
>> +   s32 *caldata;
>> +
>> +   data->busclk = devm_clk_get(>dev, "ahb");
>> +   if (IS_ERR(data->busclk)) {
>> +   ret = PTR_ERR(data->busclk);
>> +   dev_err(>dev, "failed to get ahb clk: %d\n", ret);
>> +   return ret;
>> +   }
>> +
>> +   data->clk = devm_clk_get(>dev, "ths");
>> +   if (IS_ERR(data->clk)) {
>> +   ret = PTR_ERR(data->clk);
>> +   dev_err(>dev, "failed to get ths clk: %d\n", ret);
>> +   return ret;
>> +   }
>> +
>> +   data->reset = devm_reset_control_get(>dev, "ahb");
> 
> IIRC with the new shared reset control stuff merged, you are supposed
> to specify whether you want a shared or exclusive one when you ask for
> it.

Here devm_reset_control_get will get the exclusive reference. So this
should be ok.

regards,
  Ondrej

> 
> Regards
> ChenYu
> 
>> +MODULE_LICENSE("GPL v2");
>> --
>> 2.9.0
>>

-- 
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 07/14] regulator: SY8106A regulator driver

[Ondřej Jirman]

Hi,

thank you for the review. I've resolved most of the issues. Some more
comments below.

On 24.6.2016 05:41, Chen-Yu Tsai wrote:
> On Fri, Jun 24, 2016 at 3:20 AM,  <meg...@megous.com> wrote:
>> From: Ondrej Jirman <meg...@megous.com>
>>
>> SY8106A is I2C attached single output voltage regulator
>> made by Silergy.
>>
>> Signed-off-by: Ondrej Jirman <meg...@megous.com>
>> ---
>>  drivers/regulator/Kconfig |   8 +-
>>  drivers/regulator/Makefile|   2 +-
>>  drivers/regulator/sy8106a-regulator.c | 153 
>> ++
>>  3 files changed, 161 insertions(+), 2 deletions(-)
>>  create mode 100644 drivers/regulator/sy8106a-regulator.c
>>
>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>> index 144cbf5..fc3fae2 100644
>> --- a/drivers/regulator/Kconfig
>> +++ b/drivers/regulator/Kconfig
>> @@ -860,5 +860,11 @@ config REGULATOR_WM8994
>>   This driver provides support for the voltage regulators on the
>>   WM8994 CODEC.
>>
>> -endif
>> +config REGULATOR_SY8106A
>> +   tristate "Silergy SY8106A"
>> +   depends on I2C
> 
> Maybe you should also depend on OF since the driver is going to crippled
> without any constraints set, or (OF || COMPILE_TEST) if you want some
> compile test coverage.
> 
>> +   select REGMAP_I2C
>> +   help
>> + This driver provides support for the voltage regulator SY8106A.
>>
>> +endif
>> diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
>> index 85a1d44..f382095 100644
>> --- a/drivers/regulator/Makefile
>> +++ b/drivers/regulator/Makefile
>> @@ -110,6 +110,6 @@ obj-$(CONFIG_REGULATOR_WM831X) += wm831x-ldo.o
>>  obj-$(CONFIG_REGULATOR_WM8350) += wm8350-regulator.o
>>  obj-$(CONFIG_REGULATOR_WM8400) += wm8400-regulator.o
>>  obj-$(CONFIG_REGULATOR_WM8994) += wm8994-regulator.o
>> -
>> +obj-$(CONFIG_REGULATOR_SY8106A) += sy8106a-regulator.o
> 
> Follow the existing ordering in the Makefile.
> 
>>
>>  ccflags-$(CONFIG_REGULATOR_DEBUG) += -DDEBUG
>> diff --git a/drivers/regulator/sy8106a-regulator.c 
>> b/drivers/regulator/sy8106a-regulator.c
>> new file mode 100644
>> index 000..34bd69c
>> --- /dev/null
>> +++ b/drivers/regulator/sy8106a-regulator.c
>> @@ -0,0 +1,153 @@
>> +/*
>> + * sy8106a-regulator.c - Regulator device driver for SY8106A
>> + *
>> + * Copyright (C) 2016  Ondřej Jirman <meg...@megous.com>
>> + *
>> + * This library is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Library General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2 of the License, or (at your option) any later version.
>> + *
>> + * This library is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Library General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Library General Public
>> + * License along with this library; if not, write to the
>> + * Free Software Foundation, Inc., 51 Franklin St, Fifth Floor,
>> + * Boston, MA  02110-1301, USA.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> 
> Do you need this one?
> 
>> +#include 
>> +#include 
> 
> And this one?
> 
>> +#include 
>> +#include 
> 
> Sort alphabetically please.
> 
>> +
>> +#define SY8106A_REG_VOUT1_SEL  0x01
>> +#define SY8106A_REG_VOUT_COM   0x02
>> +#define SY8106A_REG_VOUT1_SEL_MASK 0x7f
>> +#define SY8106A_DISABLE_REG0x01
> 
> BIT(0) would be clearer.
> 
>> +
>> +struct sy8106a {
>> +   struct regulator_dev *rdev;
>> +   struct regmap *regmap;
>> +};
>> +
>> +static const struct regmap_config sy8106a_regmap_config = {
>> +   .reg_bits = 8,
>> +   .val_bits = 8,
>> +};
>> +
>> +static int sy8106a_set_voltage_sel(struct regulator_dev *rdev, unsigned sel)
>> +{
>> +   return regmap_update_bits(rdev->regmap, rdev->desc->vsel_reg,
>> + 0xff, sel | 0x80);
> 
> Can you use .apply_bit / .apply_reg with regulator_set_voltage_sel_regmap?

I understand the code savings, but I'd rather avoid that, because it
would involve 2 needless readouts a

[linux-sunxi] Re: [PATCH 06/14] ARM: dts: sun8i: Add cpu0 label to sun8i-h3.dtsi

[Ondřej Jirman]

Hello,

comments below.

On 24.6.2016 05:48, Chen-Yu Tsai wrote:
> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>> From: Ondrej Jirman 
>>
>> Add label to the first cpu so that it can be referenced
>> from derived dts files.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3.dtsi | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 9938972..82faefc 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -52,7 +52,7 @@
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> -   cpu@0 {
>> +   cpu0: cpu@0 {
>> compatible = "arm,cortex-a7";
>> device_type = "cpu";
>> reg = <0>;
> 
> Can you also set the cpu clock here? It is part of the SoC
> and does not belong in the board DTS files.

Do you mean operating-points, or something else? Different SBCs will
probably require different combinations of operating points just for
safety's sake, because they have different regulators and [some have
botched] thermal designs, so it might make sense to customize it for
differnt boards, and I don't feel adventurous enough setting it for all
H3 boards out there.

Or is this comment related to the missing cpu clock rate message I see
on every boot?

[0.058912] /cpus/cpu@0 missing clock-frequency property

regards,
  Ondrej

> Otherwise this one looks good.
> 
> ChenYu
> 
>> --
>> 2.9.0
>>

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

Re: [linux-sunxi] [PATCH 13/14] ARM: dts: sun8i: Add gpio-regulator used on Orange Pi One

[Ondřej Jirman]

Hi Julian,

thank you for the review. You're right. I added the pinctrl client
nodes. Also the patches were split incorrectly, so I fixed that too.

regards,
  Ondrej

On 24.6.2016 04:51, Julian Calaby wrote:
> Hi Ondrej,
> 
> On Fri, Jun 24, 2016 at 5:21 AM,   wrote:
>> From: Ondrej Jirman 
>>
>> Xulong Orange Pi One uses GPIO based regulator that
>> switches between two voltages: 1.1V and 1.3V. The
>> regulator is controlled from the PL6 pin.
>>
>> Signed-off-by: Ondrej Jirman 
>> ---
>>  arch/arm/boot/dts/sun8i-h3-orangepi-one.dts | 26 ++
>>  1 file changed, 26 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts 
>> b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> index 0adf932..ce4ba91 100644
>> --- a/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> +++ b/arch/arm/boot/dts/sun8i-h3-orangepi-one.dts
>> @@ -88,6 +88,25 @@
>> gpios = <_pio 0 3 GPIO_ACTIVE_LOW>;
>> };
>> };
>> +
>> +   vdd_soc: gpio-regulator {
>> +   compatible = "regulator-gpio";
>> +
>> +   regulator-name = "soc-vdd-supply";
>> +   regulator-min-microvolt = <110>;
>> +   regulator-max-microvolt = <130>;
>> +   regulator-boot-on;
>> +   regulator-type = "voltage";
>> +
>> +   gpios = <_pio 0 6 GPIO_ACTIVE_HIGH>;
>> +   states = <110 0x0
>> + 130 0x1>;
>> +
>> +   startup-delay-us = <10>;
>> +   enable-active-high;
> 
> Don't you need to reference the new pinctl node in this one?
> 
> Thanks,
> 

-- 
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 01/14] ARM: dts: sun8i: Add SID node

[Ondřej Jirman]

Hello,

thank you for the review.

On 24.6.2016 04:41, Chen-Yu Tsai wrote:
> On Fri, Jun 24, 2016 at 3:20 AM,   wrote:
>> From: Josef Gajdusek 
>>
>> Add a node describing the Security ID memory to the Allwinner H3 .dtsi file.
>>
>> Signed-off-by: Josef Gajdusek 
>> ---
>>  arch/arm/boot/dts/sun8i-h3.dtsi | 7 +++
>>  1 file changed, 7 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi 
>> b/arch/arm/boot/dts/sun8i-h3.dtsi
>> index 4a4926b..172576d 100644
>> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
>> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
>> @@ -389,6 +389,13 @@
>> #size-cells = <0>;
>> };
>>
>> +   sid: eeprom@01c14000 {
>> +   compatible = "allwinner,sun4i-a10-sid";
> 
> This has been discussed before. The hardware is not compatible.
> The write control registers are at different offsets.

I'm not sure what you mean by write control registers. Code in
sunxi_sid.c implements only read access to the nvram. Can you pelase
elaborate?

  Ondrej

> 
> ChenYu
> 
>> +   reg = <0x01c14000 0x400>;
>> +   #address-cells = <1>;
>> +   #size-cells = <1>;
>> +   };
>> +
>> usbphy: phy@01c19400 {
>> compatible = "allwinner,sun8i-h3-usb-phy";
>> reg = <0x01c19400 0x2c>,
>> --
>> 2.9.0
>>

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