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

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

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

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

Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC

Allwinner are also referring to A64 as AW1689, which makes some sense because it is the chip id number that is accessible for runtime identification via reading the SRAM_VER_REG hardware register: http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG So would it be a good idea to use "aw1689" as a compatible property in the DT instead of "a64"? Or maybe have "aw1689-a64" and "aw1689-h64", which would be similar to the existing "sun5i-a13" and "sun5i-a10s" naming convention? -- Best regards, Siarhei Siamashka

Re: [linux-sunxi] Re: [PATCH 05/11] drivers: pinctrl: add driver for Allwinner A64 SoC

HTPC box is using Allwinner H64. The bootloader sources from Allwinner are also referring to A64 as AW1689, which makes some sense because it is the chip id number that is accessible for runtime identification via reading the SRAM_VER_REG hardware register: http://linux-sunxi.org/SRAM_Controller_Register_Guide#SRAM_VER_REG So would it be a good idea to use "aw1689" as a compatible property in the DT instead of "a64"? Or maybe have "aw1689-a64" and "aw1689-h64", which would be similar to the existing "sun5i-a13" and "sun5i-a10s" naming convention? -- Best regards, Siarhei Siamashka

Re: [linux-sunxi] [PATCH] thermal: Add support for Sunxi THS on the Allwinner H3

and explains how these parameters should be calculated (they depend on the THS clock frequency). No magic involved. Currently the H3 manual is available from Orange Pi people and OLIMEX. There is also an open request about releasing it "officially": https://github.com/allwinner-zh/d

Re: [linux-sunxi] [PATCH] thermal: Add support for Sunxi THS on the Allwinner H3

me nice description of these registers and explains how these parameters should be calculated (they depend on the THS clock frequency). No magic involved. Currently the H3 manual is available from Orange Pi people and OLIMEX. There is also an open request about releasing it "officially":

Re: [PATCH v4 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet

gineers, but in fact connecting both LRADC and UBOOT_SEL to tablet buttons is a part of the standard Allwinner's reference schematics. One can search for "a20_pad_std_v1_1.pdf", "a13-sch.pdf", "A31_PAD_STD_V1_90_130225.pdf" documents on the Internet to find this informat

Re: [PATCH v4 4/4] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet

ever appears that it was not just some sane decision made by MSI engineers, but in fact connecting both LRADC and UBOOT_SEL to tablet buttons is a part of the standard Allwinner's reference schematics. One can search for "a20_pad_std_v1_1.pdf", "a13-sch.pdf", "A31_PAD_STD_V1_

Re: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

On Wed, 2 Sep 2015 00:28:28 + "Pinski, Andrew" wrote: > > On Sep 2, 2015, at 3:13 AM, Siarhei Siamashka > > wrote: > > > > On Wed, 2 Sep 2015 01:58:56 +0800 > > pins...@gmail.com wrote: > > > >>> On Sep 2, 2015, at 1:30 AM, Mark

Re: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

On Wed, 2 Sep 2015 00:28:28 + "Pinski, Andrew" <andrew.pin...@caviumnetworks.com> wrote: > > On Sep 2, 2015, at 3:13 AM, Siarhei Siamashka <siarhei.siamas...@gmail.com> > > wrote: > > > > On Wed, 2 Sep 2015 01:58:56 +0800 > > pins...@gm

Re: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

upports() builtins, which rely on reading sysfs entries (with a fallback to /proc/cpuinfo parsing on old kernels) and the getcpu() syscall for the reasonably accurate core type runtime identification on big.LITTLE systems. On the applications/libraries side (including, but not limited to glibc) it means:

Re: [PATCHv2] ARM64: Add AT_ARM64_MIDR to the aux vector

_cpu_supports() builtins, which rely on reading sysfs entries (with a fallback to /proc/cpuinfo parsing on old kernels) and the getcpu() syscall for the reasonably accurate core type runtime identification on big.LITTLE systems. On the applications/libraries side (including, but not

Re: [PATCH 1/2] drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}

ree/hw/xfree86/fbdevhw/fbdevhw.c?id=xorg-server-1.15.99.903#n571 > > return 0; > } Basically, this patch breaks the xf86-video-fbdev ddx and some users are already unhappy. -- Best regards, Siarhei Siamashka -- To unsubscribe from this list: send the line "unsubscribe li

Re: [PATCH 1/2] drm/exynos/fbdev: don't set fix.smem/mmio_{start,len}

are already unhappy. -- Best regards, Siarhei Siamashka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup

On Fri, 28 Jun 2013 12:26:10 +0200 (CEST) Thomas Gleixner wrote: > On Fri, 28 Jun 2013, Siarhei Siamashka wrote: > > On Fri, 28 Jun 2013 09:43:37 +0800 > > 张猛 wrote: > > > > > > The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ > > &

Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup

On Fri, 28 Jun 2013 12:26:10 +0200 (CEST) Thomas Gleixner t...@linutronix.de wrote: On Fri, 28 Jun 2013, Siarhei Siamashka wrote: On Fri, 28 Jun 2013 09:43:37 +0800 张猛 ke...@allwinnertech.com wrote: The A10 manual from http://free-electrons.com/~maxime/pub/datasheet/ does not seem

Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup

In the case of 1, we probably can get away without using any spinlocks? -- Best regards, Siarhei Siamashka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel

Re: [linux-sunxi] [PATCH 2/8] clocksource: sun4i: Add clocksource and sched clock drivers

On Thu, 27 Jun 2013 19:02:28 +0200 Maxime Ripard wrote: > Hi Siarhei, > > On Thu, Jun 27, 2013 at 01:17:29PM +0300, Siarhei Siamashka wrote: > > On Wed, 26 Jun 2013 23:16:55 +0200 > > Maxime Ripard wrote: > > > > > The A10 and the A13 has a 64 bits

Re: [linux-sunxi] [PATCH 2/8] clocksource: sun4i: Add clocksource and sched clock drivers

node->name, > + clk_get_rate(clk), 300, 32, > + sun4i_timer_clksrc_read); > + > writel(rate / (TIMER_SCAL * HZ), > timer_base + TIMER_INTVAL_REG(0)); > -- Best regards, Siarhei Siamashka -- To unsubscribe fro

Re: [linux-sunxi] [PATCH 2/8] clocksource: sun4i: Add clocksource and sched clock drivers

/ (TIMER_SCAL * HZ), timer_base + TIMER_INTVAL_REG(0)); -- Best regards, Siarhei Siamashka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] [PATCH 2/8] clocksource: sun4i: Add clocksource and sched clock drivers

On Thu, 27 Jun 2013 19:02:28 +0200 Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi Siarhei, On Thu, Jun 27, 2013 at 01:17:29PM +0300, Siarhei Siamashka wrote: On Wed, 26 Jun 2013 23:16:55 +0200 Maxime Ripard maxime.rip...@free-electrons.com wrote: The A10 and the A13 has

Re: [linux-sunxi] [PATCH 0/8] clocksource: sunxi: Timer fixes and cleanup

probably can get away without using any spinlocks? -- Best regards, Siarhei Siamashka -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ