* Re: [PATCH v5 2/3] iommu/io-pgtable-arm-v7s: Request DMA32 memory, and improve debugging
From: Vlastimil Babka @ 2018-12-07 15:01 UTC (permalink / raw)
To: Nicolas Boichat, Will Deacon
Cc: Michal Hocko, Levin Alexander, linux-mm, Christoph Lameter,
Huaisheng Ye, Joerg Roedel, Matthew Wilcox, hch, linux-arm-kernel,
David Rientjes, yingjoe.chen, Tomasz Figa, Mike Rapoport,
Matthias Brugger, Joonsoo Kim, Yong Wu, Robin Murphy,
linux-kernel, Pekka Enberg, iommu, Andrew Morton, Mel Gorman
In-Reply-To: <20181207061620.107881-3-drinkcat@chromium.org>
On 12/7/18 7:16 AM, Nicolas Boichat wrote:
> IOMMUs using ARMv7 short-descriptor format require page tables
> (level 1 and 2) to be allocated within the first 4GB of RAM, even
> on 64-bit systems.
>
> For level 1/2 pages, ensure GFP_DMA32 is used if CONFIG_ZONE_DMA32
> is defined (e.g. on arm64 platforms).
>
> For level 2 pages, allocate a slab cache in SLAB_CACHE_DMA32. Note
> that we do not explicitly pass GFP_DMA[32] to kmem_cache_zalloc,
> as this is not strictly necessary, and would cause a warning
> in mm/sl*b.c, as we did not update GFP_SLAB_BUG_MASK.
>
> Also, print an error when the physical address does not fit in
> 32-bit, to make debugging easier in the future.
>
> Fixes: ad67f5a6545f ("arm64: replace ZONE_DMA with ZONE_DMA32")
Also, CC stable?
> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: qcom: msm8998: correct xo clock name
From: Jeffrey Hugo @ 2018-12-07 14:58 UTC (permalink / raw)
To: Marc Gonzalez, Stephen Boyd, Andy Gross
Cc: MSM, Georgi Djakov, Linux ARM, Bjorn Andersson
In-Reply-To: <00756abc-6e60-41cb-66bf-a7c9770dc2c9@free.fr>
On 12/7/2018 2:03 AM, Marc Gonzalez wrote:
> On 06/12/2018 19:34, Stephen Boyd wrote:
>> Quoting Jeffrey Hugo (2018-12-05 15:04:01)
>>> On 12/5/2018 2:42 PM, Stephen Boyd wrote:
>>>> Quoting Jeffrey Hugo (2018-12-05 13:20:07)
>>>>> On 12/5/2018 2:04 PM, Stephen Boyd wrote:
>>>>>> Quoting Jeffrey Hugo (2018-12-05 09:03:54)
>>>>>>
>>>>>> I don't quite understand the patch in general. The xo_board clk should
>>>>>> always exist in DT and the fixed factor clk in GCC is there until the
>>>>>> rpm clk driver can control the XO clk state vote for the kernel.
>>>>>
>>>>> Sorry, this wasn't apparent. It doesn't seem like this "requirement" is
>>>>> captured anywhere.
>>>>
>>>> Agreed!
>>>>
>>>>>
>>>>> As far as the SD clocks are concerned, they are defined in GCC, and
>>>>> eventually have a root parent called "xo". "xo" isn't defined anywhere,
>>>>> so the SD clocks can't really be used, and the hardware doesn't come up.
>>>>> This patch "fixed" that, but I missed the link to the rpm driver that
>>>>> Marc pointed out.
>>>>
>>>> Hmm ok. The SD DT node should just point to the xo_board clk for now and
>>>> later on it can be changed to use the rpm clk when the rpm node is
>>>> created.
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> If anything, change the DT node to be named xo-board instead of xo_board
>>>>>> because that matches DT naming schemes and then add a clock-output-names
>>>>>> = "xo_board" property to it so that we keep the underscore.
>>>>>
>>>>> I see this now, and I agree with it, but then SD goes back to a broken
>>>>> state because there is "xo" clock for GCC. Its not quite clear to me
>>>>> how to make GCC (and thus SD) happy again with this change reverted/fixed.
>>>>>
>>>>> Bjorn mentioned offline he is going to take a look, but he has a few
>>>>> other things on his plate first.
>>>>>
>>>>
>>>> There is an XO clk created in drivers/clk/qcom/gcc-msm8996.c, we should
>>>> do the same here until rpm can handle this. I'll pack this patch up and
>>>> merge it to clk-next soon.
>>>
>>> Thanks. I pulled in the below change into my tree, and fixed up the DT
>>> based on the discussion we had. SD works, and things look sane to me
>>> per clk_summary in debugfs.
>>>
>>> Feel free to throw my tested-by on if you want.
>>
>> Thanks. I did so and merged it up to clk-next.
>
> @Andy, don't you still need to revert 634da3307b083ee83eb9b377081fdfd6416a148a
> ("arm64: dts: qcom: msm8998: correct xo clock name") in for-next?
Yes, and no. The SD changes kind of depend on that, so those would need
to get sorted as well.
I still haven't heard from Andy, but I guess I'll go ahead and create a
fixup patch.
--
Jeffrey Hugo
Qualcomm Datacenter Technologies as an affiliate of Qualcomm
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] drm/rockchip: dw-mipi-dsi: Support MIPI_DSI_DCS_READ
From: Heiko Stuebner @ 2018-12-07 14:58 UTC (permalink / raw)
To: Richard Röjfors
Cc: linux-rockchip, linux-arm-kernel, Richard Röjfors
In-Reply-To: <20181205130243.5810-1-richard@puffinpack.se>
Hi Richard,
Am Mittwoch, 5. Dezember 2018, 14:02:43 CET schrieb Richard Röjfors:
> There is sometimes a need to be able to read from the other
> end for instance to identify panels.
>
> Signed-off-by: Richard Röjfors <richard@puffinpack.se>
The Rockchip dsi driver got converted to use the generic dw-mipi-dsi
bridge - will be part of 4.21. And there the different methods seem to
be implemented already.
So this patch does not seem to be relevant anymore. Please wait for 4.21-rc1
or check linux-next, if there is still functionality missing.
Also as a general note, please check scripts/get_maintainer.pl when
sending patches, as that should have also listed the dri-devel list, which
missing here.
Thanks
Heiko
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 16/19] arm64: dts: tegra210-p2371-2180: enable DFLL clock
From: Jon Hunter @ 2018-12-07 14:57 UTC (permalink / raw)
To: Joseph Lo, Thierry Reding, Peter De Schrijver
Cc: linux-tegra, linux-clk, linux-arm-kernel
In-Reply-To: <20181204092548.3038-17-josephl@nvidia.com>
On 04/12/2018 09:25, Joseph Lo wrote:
> Enable DFLL clock for Jetson TX1 platform.
>
> Signed-off-by: Joseph Lo <josephl@nvidia.com>
> ---
> .../boot/dts/nvidia/tegra210-p2371-2180.dts | 20 +++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts b/arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts
> index 37e3c46e753f..53f497c2b3ff 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts
> +++ b/arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts
> @@ -78,4 +78,24 @@
> };
> };
> };
> +
> + clock@70110000 {
> + status = "okay";
> + nvidia,pwm-to-pmic;
> + nvidia,init-uv = <1000000>;
> + nvidia,align-offset-uv = <708000>;
> + nvidia,align-step-uv = <19200>;
> + nvidia,sample-rate = <25000>;
> + nvidia,droop-ctrl = <0x00000f00>;
> + nvidia,force-mode = <1>;
> + nvidia,cf = <6>;
> + nvidia,ci = <0>;
> + nvidia,cg = <2>;
> + nvidia,idle-override;
> + nvidia,one-shot-calibrate;
I don't see any Documentation for or usage of the above two properties.
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Moving ARM dts files
From: Rob Herring @ 2018-12-07 14:57 UTC (permalink / raw)
To: Mark Brown
Cc: Andrew Lunn, Alexandre Belloni, Tony Lindgren, Linus Walleij,
Liviu Dudau, Michal Simek, Masahiro Yamada, Thierry Reding,
Tom Rini, Florian Fainelli, Kevin Hilman, Gregory CLEMENT,
Alexander Graf, Krzysztof Kozlowski, ARM-SoC Maintainers,
Joel Stanley, Andy Gross, devicetree, Architecture Mailman List,
Jason Cooper, Simon Horman,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
Grant Likely, Maxime Coquelin, Shawn Guo, Andreas Färber,
Daniel Mack
In-Reply-To: <20181206200652.GB3084@sirena.org.uk>
On Thu, Dec 6, 2018 at 2:07 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Dec 06, 2018 at 01:06:43PM -0600, Rob Herring wrote:
> > On Thu, Dec 6, 2018 at 7:32 AM Andreas Färber <afaerber@suse.de> wrote:
>
> > > I'd be okay with distinguishing source vs. install location. Due to the
> > > issue I mention below (and more) we can't use install_dtbs for openSUSE
> > > and had to reimplement it, which we'd need to (and can) adjust.
>
> > What would be needed for dtbs_install to work? arm64 needs to support
> > a flat install? If it doesn't work for Debian or openSUSE, I'm not
> > sure why we have it. So I'd like to make it work.
>
> Correct me if I'm wrong but as far as the flat vs directory thing goes
> isn't the issue that this winds up being a rename for an existing 32 bit
> system? If you just install the dtbs in the default location then a
> bootloader or whatever that is hard coded to look for foo-bar.dtb won't
> see the new foo/foo-bar.dtb (or whatever) and will continue to use the
> old binary. It's not the fact that that it's in a directory, it's the
> fact that the bootloader sees the name it needs to look for change (if
> it's looking on a filesystem at all).
Correct.
> This isn't a problem for arm64 as
> the location isn't changing, it's used directories from day one.
The kernel may have used directories, but that's not what the distros
did according to Andreas:
> We already had that discussion for arm64 because Debian chose to ignore
> the kernel-installed subdirectories and installed .dtb files into a flat
> directory, which collided with openSUSE sticking to the kernel choice.
So are the distros different or who changed to align? That's not clear
from this thread.
> The issues with the existing install_dtbs sounded unrelated to this.
Maybe, what are the issues? We can't change the source layout
transparently if dtbs_install is not being used.
My question here is whether a flat install is useful on arm64. We can
either have a kconfig variable that arm32 sets to do flat installs or
it could be some command line make variable and then any user can pick
what they want for any arch.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 15/19] arm64: dts: tegra210-p2597: add pinmux for PWM-based DFLL support
From: Jon Hunter @ 2018-12-07 14:55 UTC (permalink / raw)
To: Joseph Lo, Thierry Reding, Peter De Schrijver
Cc: linux-tegra, linux-clk, linux-arm-kernel
In-Reply-To: <20181204092548.3038-16-josephl@nvidia.com>
On 04/12/2018 09:25, Joseph Lo wrote:
> Add pinmux for PWM-based DFLL support.
>
> Signed-off-by: Joseph Lo <josephl@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
> index 365726ddd418..db5dc0ad466d 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra210-p2597.dtsi
> @@ -1278,6 +1278,20 @@
> nvidia,open-drain = <TEGRA_PIN_DISABLE>;
> };
> };
> +
> + dvfs_pwm_active_state: dvfs_pwm_active {
> + dvfs_pwm_pbb1 {
> + nvidia,pins = "dvfs_pwm_pbb1";
> + nvidia,tristate = <TEGRA_PIN_DISABLE>;
> + };
> + };
> +
> + dvfs_pwm_inactive_state: dvfs_pwm_inactive {
> + dvfs_pwm_pbb1 {
> + nvidia,pins = "dvfs_pwm_pbb1";
> + nvidia,tristate = <TEGRA_PIN_ENABLE>;
> + };
> + };
> };
>
> pwm@7000a000 {
>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 14/19] arm64: dts: tegra210: add CPU clocks
From: Jon Hunter @ 2018-12-07 14:54 UTC (permalink / raw)
To: Joseph Lo, Thierry Reding, Peter De Schrijver
Cc: linux-tegra, linux-clk, linux-arm-kernel
In-Reply-To: <20181204092548.3038-15-josephl@nvidia.com>
On 04/12/2018 09:25, Joseph Lo wrote:
> Add CPU clocks for Tegra210.
>
> Signed-off-by: Joseph Lo <josephl@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> index a6db62157442..e2baf52fe1af 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> @@ -1304,6 +1304,12 @@
> device_type = "cpu";
> compatible = "arm,cortex-a57";
> reg = <0>;
> + clocks = <&tegra_car TEGRA210_CLK_CCLK_G>,
> + <&tegra_car TEGRA210_CLK_PLL_X>,
> + <&tegra_car TEGRA210_CLK_PLL_P_OUT4>,
> + <&dfll>;
> + clock-names = "cpu_g", "pll_x", "pll_p", "dfll";
> + clock-latency = <300000>;
> };
>
> cpu@1 {
>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 13/19] arm64: dts: tegra210: add DFLL clock
From: Jon Hunter @ 2018-12-07 14:54 UTC (permalink / raw)
To: Joseph Lo, Thierry Reding, Peter De Schrijver
Cc: linux-tegra, linux-clk, linux-arm-kernel
In-Reply-To: <20181204092548.3038-14-josephl@nvidia.com>
On 04/12/2018 09:25, Joseph Lo wrote:
> Add essential DFLL clock properties for Tegra210.
>
> Signed-off-by: Joseph Lo <josephl@nvidia.com>
> ---
> arch/arm64/boot/dts/nvidia/tegra210.dtsi | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/nvidia/tegra210.dtsi b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> index 2205d66b0443..a6db62157442 100644
> --- a/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> +++ b/arch/arm64/boot/dts/nvidia/tegra210.dtsi
> @@ -4,6 +4,7 @@
> #include <dt-bindings/memory/tegra210-mc.h>
> #include <dt-bindings/pinctrl/pinctrl-tegra.h>
> #include <dt-bindings/pinctrl/pinctrl-tegra-io-pad.h>
> +#include <dt-bindings/reset/tegra210-car.h>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/thermal/tegra124-soctherm.h>
>
> @@ -1131,6 +1132,24 @@
> #nvidia,mipi-calibrate-cells = <1>;
> };
>
> + dfll: clock@70110000 {
> + compatible = "nvidia,tegra210-dfll";
> + reg = <0 0x70110000 0 0x100>, /* DFLL control */
> + <0 0x70110000 0 0x100>, /* I2C output control */
> + <0 0x70110100 0 0x100>, /* Integrated I2C controller */
> + <0 0x70110200 0 0x100>; /* Look-up table RAM */
> + interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&tegra_car TEGRA210_CLK_DFLL_SOC>,
> + <&tegra_car TEGRA210_CLK_DFLL_REF>,
> + <&tegra_car TEGRA210_CLK_I2C5>;
> + clock-names = "soc", "ref", "i2c";
> + resets = <&tegra_car TEGRA210_RST_DFLL_DVCO>;
> + reset-names = "dvco";
> + #clock-cells = <0>;
> + clock-output-names = "dfllCPU_out";
> + status = "disabled";
> + };
> +
> aconnect@702c0000 {
> compatible = "nvidia,tegra210-aconnect";
> clocks = <&tegra_car TEGRA210_CLK_APE>,
>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Allwinner H3/H5 changes for 4.21
From: Maxime Ripard @ 2018-12-07 14:54 UTC (permalink / raw)
To: arm; +Cc: Maxime Ripard, Chen-Yu Tsai, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 2679 bytes --]
Hi Arnd, Kevin, Olof,
Please pull the following changes for the next merge window.
Thanks!
Maxime
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-h3-h5-for-4.21
for you to fetch changes up to 8be5b161bb3d07bc5a119dfe0285ec05d28202c9:
arm64: dts: allwinner: h5: Add Video Engine node (2018-12-05 12:03:06 +0100)
----------------------------------------------------------------
Allwinner H3/H5 changes for 4.21
Our usual pull request with the changes shared between the H3 and H5 SoCs.
The major changes for this release are:
- Addition of the video engine for the H5
- H3 Camera support
- New board: Emlid Neutis N5, Mapleboard MP130
----------------------------------------------------------------
Aleksandr Aleksandrov (2):
dt-bindings: vendor-prefix: new vendor - Emlid
arm64: dts: allwinner: new board - Emlid Neutis N5
Jonathan McDowell (1):
ARM: dts: sun8i-h3: Add dts for the Mapleboard MP130
Jorik Jonker (1):
ARM: dts: sun8i-h3: add sy8106a to orange pi plus
Mylène Josserand (1):
ARM: dts: sun8i: Add the H3/H5 CSI controller
Paul Kocialkowski (4):
ARM: dts: sun8i: h3: Fix the system-control register range
arm64: dts: allwinner: h5: Add system-control node with SRAM C1
ARM/arm64: dts: allwinner: Move H3/H5 syscon label over to soc-specific nodes
arm64: dts: allwinner: h5: Add Video Engine node
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-h3-mapleboard-mp130.dts | 153 +++++++++++++++++++++
arch/arm/boot/dts/sun8i-h3-orangepi-plus.dts | 20 +++
arch/arm/boot/dts/sun8i-h3.dtsi | 4 +-
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 28 +++-
arch/arm64/boot/dts/allwinner/Makefile | 1 +
.../sun50i-h5-emlid-neutis-n5-devboard.dts | 149 ++++++++++++++++++++
.../dts/allwinner/sun50i-h5-emlid-neutis-n5.dtsi | 61 ++++++++
arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 33 +++++
10 files changed, 443 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/boot/dts/sun8i-h3-mapleboard-mp130.dts
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-emlid-neutis-n5-devboard.dts
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-emlid-neutis-n5.dtsi
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 4/9] drm/rockchip/rockchip_drm_gem.c: Convert to use vm_insert_range
From: Robin Murphy @ 2018-12-07 14:50 UTC (permalink / raw)
To: Souptick Joarder, akpm, willy, mhocko, hjc, heiko, airlied
Cc: linux-arm-kernel, linux-mm, linux-kernel, dri-devel,
linux-rockchip
In-Reply-To: <20181206184227.GA28656@jordon-HP-15-Notebook-PC>
On 06/12/2018 18:42, Souptick Joarder wrote:
> Convert to use vm_insert_range() to map range of kernel
> memory to user vma.
>
> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> Tested-by: Heiko Stuebner <heiko@sntech.de>
> Acked-by: Heiko Stuebner <heiko@sntech.de>
> ---
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 20 ++------------------
> 1 file changed, 2 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> index a8db758..2cb83bb 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> @@ -221,26 +221,10 @@ static int rockchip_drm_gem_object_mmap_iommu(struct drm_gem_object *obj,
> struct vm_area_struct *vma)
> {
> struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
> - unsigned int i, count = obj->size >> PAGE_SHIFT;
> unsigned long user_count = vma_pages(vma);
> - unsigned long uaddr = vma->vm_start;
> - unsigned long offset = vma->vm_pgoff;
> - unsigned long end = user_count + offset;
> - int ret;
> -
> - if (user_count == 0)
> - return -ENXIO;
> - if (end > count)
> - return -ENXIO;
>
> - for (i = offset; i < end; i++) {
> - ret = vm_insert_page(vma, uaddr, rk_obj->pages[i]);
> - if (ret)
> - return ret;
> - uaddr += PAGE_SIZE;
> - }
> -
> - return 0;
> + return vm_insert_range(vma, vma->vm_start, rk_obj->pages,
> + user_count);
We're losing vm_pgoff handling here, which given the implication in
57de50af162b, may well be a regression for at least some combination of
GPU and userspace driver (I assume that commit was in the context of
some version of the Arm Mali driver, possibly on RK3288).
Robin.
> }
>
> static int rockchip_drm_gem_object_mmap_dma(struct drm_gem_object *obj,
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 12/19] cpufreq: tegra124: extend to support Tegra210
From: Jon Hunter @ 2018-12-07 14:50 UTC (permalink / raw)
To: Joseph Lo, Thierry Reding, Peter De Schrijver
Cc: linux-tegra, Viresh Kumar, linux-clk, linux-arm-kernel, linux-pm
In-Reply-To: <20181204092548.3038-13-josephl@nvidia.com>
On 04/12/2018 09:25, Joseph Lo wrote:
> Tegra210 uses the same methodology as Tegra124 for CPUFreq controlling
> that based on DFLL clock. So extending this driver to support Tegra210.
>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: linux-pm@vger.kernel.org
> Signed-off-by: Joseph Lo <josephl@nvidia.com>
> ---
> drivers/cpufreq/tegra124-cpufreq.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/tegra124-cpufreq.c b/drivers/cpufreq/tegra124-cpufreq.c
> index 448d00763d00..1af955fb715c 100644
> --- a/drivers/cpufreq/tegra124-cpufreq.c
> +++ b/drivers/cpufreq/tegra124-cpufreq.c
> @@ -159,7 +159,8 @@ static int __init tegra_cpufreq_init(void)
> int ret;
> struct platform_device *pdev;
>
> - if (!of_machine_is_compatible("nvidia,tegra124"))
> + if (!(of_machine_is_compatible("nvidia,tegra124") ||
> + of_machine_is_compatible("nvidia,tegra210")))
> return -ENODEV;
>
> /*>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 11/19] cpufreq: tegra124: do not handle the CPU rail
From: Jon Hunter @ 2018-12-07 14:49 UTC (permalink / raw)
To: Joseph Lo, Thierry Reding, Peter De Schrijver
Cc: linux-tegra, Viresh Kumar, linux-clk, linux-arm-kernel, linux-pm
In-Reply-To: <20181204092548.3038-12-josephl@nvidia.com>
On 04/12/2018 09:25, Joseph Lo wrote:
> The Tegra124 cpufreq driver has no information to handle the Vdd-CPU
> rail. So the driver shouldn't handle for the CPU clock switching from
> DFLL to other PLL clocks. It was designed to work on DFLL clock only,
> which handle the frequency/voltage scaling in the background. This
> patch removes the driver dependency of the CPU rail.
>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: linux-pm@vger.kernel.org
> Signed-off-by: Joseph Lo <josephl@nvidia.com>
> ---
> drivers/cpufreq/Kconfig.arm | 2 +-
> drivers/cpufreq/tegra124-cpufreq.c | 26 ++------------------------
> 2 files changed, 3 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
> index 4e1131ef85ae..a609f8820c47 100644
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -262,7 +262,7 @@ config ARM_TEGRA20_CPUFREQ
>
> config ARM_TEGRA124_CPUFREQ
> tristate "Tegra124 CPUFreq support"
> - depends on ARCH_TEGRA && CPUFREQ_DT && REGULATOR
> + depends on ARCH_TEGRA && CPUFREQ_DT
> default y
> help
> This adds the CPUFreq driver support for Tegra124 SOCs.
> diff --git a/drivers/cpufreq/tegra124-cpufreq.c b/drivers/cpufreq/tegra124-cpufreq.c
> index 43530254201a..448d00763d00 100644
> --- a/drivers/cpufreq/tegra124-cpufreq.c
> +++ b/drivers/cpufreq/tegra124-cpufreq.c
> @@ -22,11 +22,9 @@
> #include <linux/of.h>
> #include <linux/platform_device.h>
> #include <linux/pm_opp.h>
> -#include <linux/regulator/consumer.h>
> #include <linux/types.h>
>
> struct tegra124_cpufreq_priv {
> - struct regulator *vdd_cpu_reg;
> struct clk *cpu_clk;
> struct clk *pllp_clk;
> struct clk *pllx_clk;
> @@ -60,14 +58,6 @@ static int tegra124_cpu_switch_to_dfll(struct tegra124_cpufreq_priv *priv)
> return ret;
> }
>
> -static void tegra124_cpu_switch_to_pllx(struct tegra124_cpufreq_priv *priv)
> -{
> - clk_set_parent(priv->cpu_clk, priv->pllp_clk);
> - clk_disable_unprepare(priv->dfll_clk);
> - regulator_sync_voltage(priv->vdd_cpu_reg);
> - clk_set_parent(priv->cpu_clk, priv->pllx_clk);
> -}
> -
> static int tegra124_cpufreq_probe(struct platform_device *pdev)
> {
> struct tegra124_cpufreq_priv *priv;
> @@ -88,16 +78,10 @@ static int tegra124_cpufreq_probe(struct platform_device *pdev)
> if (!np)
> return -ENODEV;
>
> - priv->vdd_cpu_reg = regulator_get(cpu_dev, "vdd-cpu");
> - if (IS_ERR(priv->vdd_cpu_reg)) {
> - ret = PTR_ERR(priv->vdd_cpu_reg);
> - goto out_put_np;
> - }
> -
> priv->cpu_clk = of_clk_get_by_name(np, "cpu_g");
> if (IS_ERR(priv->cpu_clk)) {
> ret = PTR_ERR(priv->cpu_clk);
> - goto out_put_vdd_cpu_reg;
> + goto out_put_np;
> }
>
> priv->dfll_clk = of_clk_get_by_name(np, "dfll");
> @@ -129,15 +113,13 @@ static int tegra124_cpufreq_probe(struct platform_device *pdev)
> platform_device_register_full(&cpufreq_dt_devinfo);
> if (IS_ERR(priv->cpufreq_dt_pdev)) {
> ret = PTR_ERR(priv->cpufreq_dt_pdev);
> - goto out_switch_to_pllx;
> + goto out_put_pllp_clk;
> }
>
> platform_set_drvdata(pdev, priv);
>
> return 0;
>
> -out_switch_to_pllx:
> - tegra124_cpu_switch_to_pllx(priv);
> out_put_pllp_clk:
> clk_put(priv->pllp_clk);
> out_put_pllx_clk:
> @@ -146,8 +128,6 @@ static int tegra124_cpufreq_probe(struct platform_device *pdev)
> clk_put(priv->dfll_clk);
> out_put_cpu_clk:
> clk_put(priv->cpu_clk);
> -out_put_vdd_cpu_reg:
> - regulator_put(priv->vdd_cpu_reg);
> out_put_np:
> of_node_put(np);
>
> @@ -159,13 +139,11 @@ static int tegra124_cpufreq_remove(struct platform_device *pdev)
> struct tegra124_cpufreq_priv *priv = platform_get_drvdata(pdev);
>
> platform_device_unregister(priv->cpufreq_dt_pdev);
> - tegra124_cpu_switch_to_pllx(priv);
>
> clk_put(priv->pllp_clk);
> clk_put(priv->pllx_clk);
> clk_put(priv->dfll_clk);
> clk_put(priv->cpu_clk);
> - regulator_put(priv->vdd_cpu_reg);
I see what you are saying and while this does appear to be broken, it
also does not seem right that if we load and unload this driver the CPU
clock parent will remain as the DFLL clock. Can't we query the voltage
of the vdd-cpu regulator before we switch and then restore it before we
switch back?
I am just trying to understand if there is no way to switch back? If not
then maybe we should not allow this driver to be built as a module and
remove the removal function altogether.
Cheers
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] kvm/arm: return 0 when the number of objects is not less than min
From: Steven Price @ 2018-12-07 14:49 UTC (permalink / raw)
To: Andrew Jones, Peng Hao
Cc: marc.zyngier, linux-kernel, linux-arm-kernel, kvmarm
In-Reply-To: <20181205083236.5tzhnxfhi4h4nknn@kamzik.brq.redhat.com>
On 05/12/2018 08:32, Andrew Jones wrote:
> On Wed, Dec 05, 2018 at 09:15:51AM +0800, Peng Hao wrote:
>> Return 0 when there is enough kvm_mmu_memory_cache object.
>>
>> Signed-off-by: Peng Hao <peng.hao2@zte.com.cn>
>> ---
>> virt/kvm/arm/mmu.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/virt/kvm/arm/mmu.c b/virt/kvm/arm/mmu.c
>> index ed162a6..fcda0ce 100644
>> --- a/virt/kvm/arm/mmu.c
>> +++ b/virt/kvm/arm/mmu.c
>> @@ -127,7 +127,7 @@ static int mmu_topup_memory_cache(struct kvm_mmu_memory_cache *cache,
>> while (cache->nobjs < max) {
>> page = (void *)__get_free_page(PGALLOC_GFP);
>> if (!page)
>> - return -ENOMEM;
>> + return cache->nobjs >= min ? 0 : -ENOMEM;
>
> This condition will never be true here, as the exact same condition is
> already checked above, and if it had been true, then we wouldn't be here.
The condition can be true if the loop is executed at least once. This
change would appear to allow the call to succeed in the case where the
cache can be topped up to at least "min", but not as far as "max".
It would be good to know in what situation this has actually been hit
though (and indeed whether this has actually been seen) - the system
must be very short on memory to need this, and I'd be surprised if
further failures didn't happen later on.
> What problem are you attempting to solve?
>
>> cache->objects[cache->nobjs++] = page;
>> }
>> return 0;
>> --
>> 1.8.3.1
>>
>> _______________________________________________
>> kvmarm mailing list
>> kvmarm@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
> _______________________________________________
> kvmarm mailing list
> kvmarm@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v3 1/9] mm: Introduce new vm_insert_range API
From: Mauro Carvalho Chehab @ 2018-12-07 14:47 UTC (permalink / raw)
To: Souptick Joarder
Cc: mhocko, heiko, peterz, dri-devel, linux-kernel, linux-mm,
linux1394-devel, m.szyprowski, sfr, oleksandr_andrushchenko, joro,
linux, willy, airlied, linux-arm-kernel, linux-rockchip, treding,
linux-media, keescook, pawel, riel, iommu, rppt, boris.ostrovsky,
iamjoonsoo.kim, vbabka, jgross, hjc, xen-devel, kyungmin.park,
stefanr, akpm, robin.murphy, kirill.shutemov
In-Reply-To: <20181206183945.GA20932@jordon-HP-15-Notebook-PC>
Em Fri, 7 Dec 2018 00:09:45 +0530
Souptick Joarder <jrdr.linux@gmail.com> escreveu:
> Previouly drivers have their own way of mapping range of
> kernel pages/memory into user vma and this was done by
> invoking vm_insert_page() within a loop.
>
> As this pattern is common across different drivers, it can
> be generalized by creating a new function and use it across
> the drivers.
>
> vm_insert_range is the new API which will be used to map a
> range of kernel memory/pages to user vma.
>
> This API is tested by Heiko for Rockchip drm driver, on rk3188,
> rk3288, rk3328 and rk3399 with graphics.
>
> Signed-off-by: Souptick Joarder <jrdr.linux@gmail.com>
> Reviewed-by: Matthew Wilcox <willy@infradead.org>
> Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
> Tested-by: Heiko Stuebner <heiko@sntech.de>
Looks good to me.
Reviewed-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
> ---
> include/linux/mm.h | 2 ++
> mm/memory.c | 38 ++++++++++++++++++++++++++++++++++++++
> mm/nommu.c | 7 +++++++
> 3 files changed, 47 insertions(+)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index fcf9cc9..2bc399f 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -2506,6 +2506,8 @@ unsigned long change_prot_numa(struct vm_area_struct *vma,
> int remap_pfn_range(struct vm_area_struct *, unsigned long addr,
> unsigned long pfn, unsigned long size, pgprot_t);
> int vm_insert_page(struct vm_area_struct *, unsigned long addr, struct page *);
> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> + struct page **pages, unsigned long page_count);
> vm_fault_t vmf_insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> unsigned long pfn);
> vm_fault_t vmf_insert_pfn_prot(struct vm_area_struct *vma, unsigned long addr,
> diff --git a/mm/memory.c b/mm/memory.c
> index 15c417e..84ea46c 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -1478,6 +1478,44 @@ static int insert_page(struct vm_area_struct *vma, unsigned long addr,
> }
>
> /**
> + * vm_insert_range - insert range of kernel pages into user vma
> + * @vma: user vma to map to
> + * @addr: target user address of this page
> + * @pages: pointer to array of source kernel pages
> + * @page_count: number of pages need to insert into user vma
> + *
> + * This allows drivers to insert range of kernel pages they've allocated
> + * into a user vma. This is a generic function which drivers can use
> + * rather than using their own way of mapping range of kernel pages into
> + * user vma.
> + *
> + * If we fail to insert any page into the vma, the function will return
> + * immediately leaving any previously-inserted pages present. Callers
> + * from the mmap handler may immediately return the error as their caller
> + * will destroy the vma, removing any successfully-inserted pages. Other
> + * callers should make their own arrangements for calling unmap_region().
> + *
> + * Context: Process context. Called by mmap handlers.
> + * Return: 0 on success and error code otherwise
> + */
> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> + struct page **pages, unsigned long page_count)
> +{
> + unsigned long uaddr = addr;
> + int ret = 0, i;
> +
> + for (i = 0; i < page_count; i++) {
> + ret = vm_insert_page(vma, uaddr, pages[i]);
> + if (ret < 0)
> + return ret;
> + uaddr += PAGE_SIZE;
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(vm_insert_range);
> +
> +/**
> * vm_insert_page - insert single page into user vma
> * @vma: user vma to map to
> * @addr: target user address of this page
> diff --git a/mm/nommu.c b/mm/nommu.c
> index 749276b..d6ef5c7 100644
> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -473,6 +473,13 @@ int vm_insert_page(struct vm_area_struct *vma, unsigned long addr,
> }
> EXPORT_SYMBOL(vm_insert_page);
>
> +int vm_insert_range(struct vm_area_struct *vma, unsigned long addr,
> + struct page **pages, unsigned long page_count)
> +{
> + return -EINVAL;
> +}
> +EXPORT_SYMBOL(vm_insert_range);
> +
> /*
> * sys_brk() for the most part doesn't need the global kernel
> * lock, except when an application is doing something nasty
Thanks,
Mauro
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Allwinner arm64 DT changes for 4.21
From: Maxime Ripard @ 2018-12-07 14:44 UTC (permalink / raw)
To: arm; +Cc: Maxime Ripard, Chen-Yu Tsai, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 4280 bytes --]
Hi Arnd, Kevin, Olof,
Please pull the following changes for the next merge window.
ThankS!
Maxime
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt64-for-4.21
for you to fetch changes up to 44ff3cafcd7f413e7710a58ac40cfdc3a9380097:
arm64: dts: allwinner: a64: Fix up RTC device node and clock references (2018-12-07 10:23:39 +0800)
----------------------------------------------------------------
Allwinner arm64 DT changes for 4.21
Our usual set of arm64 DT changes, with the biggest additions being:
- Support for the video decoding engine in the A64
- Support for the audio codec in the A64
- USB Support in the H6
- HDMI Support in the H6
- EMAC Support in the H6
- New board: Orange Pi Lite2
----------------------------------------------------------------
Chen-Yu Tsai (5):
arm64: dts: allwinner: h6: orangepi: Add board-wide 5V regulator
arm64: dts: allwinner: h6: orangepi: Enable USB 2.0 host and OTG ports
arm64: dts: allwinner: h6: orangepi: Add device nodes for LEDs
arm64: dts: allwinner: a64: bananapi-m64: Enable audio codec
arm64: dts: allwinner: a64: Fix up RTC device node and clock references
Icenowy Zheng (7):
dt-binding: dwmac-sun8i: add H6 compatible string (w/ A64 fallback)
arm64: allwinner: h6: add EMAC device nodes
arm64: allwinner: h6: add support for the Ethernet on Pine H64
arm64: dts: allwinner: h6: add USB2-related device nodes
arm64: dts: allwinner: h6: add USB Vbus regulator for Pine H64
arm64: dts: allwinner: h6: enable USB2 on Pine H64
arm64: dts: allwinner: h6: fix EMAC compatible string sequence
Jagan Teki (4):
arm64: allwinner: h6: Add common orangepi nodes into dtsi
arm64: allwinner: h6: Add OrangePi Lite2 initial support
dt-bindings: gpu: mali-utgard: Add compatible for A64 Mali
arm64: dts: allwinner: a64: Add device node for Mali-400 GPU
Jernej Skrabec (2):
arm64: dts: allwinner: h6: Add HDMI pipeline
arm64: dts: allwinner: h6: Enable HDMI output on Pine H64 board
Oskari Lemmela (2):
arm64: dts: allwinner: axp803: add AC and battery power supplies
arm64: dts: allwinner: a64: sopine-baseboard: enable power supplies
Paul Kocialkowski (2):
arm64: dts: allwinner: a64: Add support for the SRAM C1 section
arm64: dts: allwinner: a64: Add Video Engine node
Vasily Khoruzhick (5):
arm64: dts: allwinner: add backlight regulator for Pinebook
arm64: dts: allwinner: a64: add nodes necessary for analog sound support
arm64: dts: allwinner: a64: enable sound on Pine64 and SoPine
arm64: dts: allwinner: a64: enable sound on Pinebook
arm64: dts: allwinner: a64: pinebook: enable power supplies
.../devicetree/bindings/gpu/arm,mali-utgard.txt | 5 +
.../devicetree/bindings/net/dwmac-sun8i.txt | 1 +
arch/arm64/boot/dts/allwinner/Makefile | 1 +
arch/arm64/boot/dts/allwinner/axp803.dtsi | 33 +++
.../boot/dts/allwinner/sun50i-a64-bananapi-m64.dts | 29 ++
.../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 27 ++
.../boot/dts/allwinner/sun50i-a64-pinebook.dts | 67 +++++
.../dts/allwinner/sun50i-a64-sopine-baseboard.dts | 34 +++
.../boot/dts/allwinner/sun50i-a64-sopine.dtsi | 4 +
arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 123 +++++++-
.../dts/allwinner/sun50i-h6-orangepi-lite2.dts | 11 +
.../dts/allwinner/sun50i-h6-orangepi-one-plus.dts | 140 +---------
.../boot/dts/allwinner/sun50i-h6-orangepi.dtsi | 210 ++++++++++++++
.../boot/dts/allwinner/sun50i-h6-pine-h64.dts | 82 ++++++
arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi | 311 +++++++++++++++++++++
15 files changed, 924 insertions(+), 154 deletions(-)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-lite2.dts
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi.dtsi
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] arm64: hyperv: Add support for Hyper-V as a hypervisor
From: Marc Zyngier @ 2018-12-07 14:43 UTC (permalink / raw)
To: kys, will.deacon, catalin.marinas, mark.rutland, linux-arm-kernel,
gregkh, linux-kernel, devel, olaf, apw, jasowang, sthemmin,
Michael.H.Kelley, vkuznets
Cc: Michael Kelley
In-Reply-To: <20181122031059.16338-2-kys@linuxonhyperv.com>
On 22/11/2018 03:10, kys@linuxonhyperv.com wrote:
> From: Michael Kelley <mikelley@microsoft.com>
>
> Add ARM64-specific code to enable Hyper-V. This code includes:
> * Detecting Hyper-V and initializing the guest/Hyper-V interface
> * Setting up Hyper-V's synthetic clocks
> * Making hypercalls using the HVC instruction
> * Setting up VMbus and stimer0 interrupts
> * Setting up kexec and crash handlers
This commit message is a clear indication that this should be split in
at least 5 different patches.
> This code is architecture dependent code and is mostly driven by
> architecture independent code in the VMbus driver in drivers/hv/hv.c
> and drivers/hv/vmbus_drv.c.
>
> This code is built only when CONFIG_HYPERV is enabled.
>
> Signed-off-by: Michael Kelley <mikelley@microsoft.com>
> Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
> ---
> MAINTAINERS | 1 +
> arch/arm64/Makefile | 1 +
> arch/arm64/hyperv/Makefile | 2 +
> arch/arm64/hyperv/hv_hvc.S | 54 +++++
> arch/arm64/hyperv/hv_init.c | 441 +++++++++++++++++++++++++++++++++++
> arch/arm64/hyperv/mshyperv.c | 178 ++++++++++++++
> 6 files changed, 677 insertions(+)
> create mode 100644 arch/arm64/hyperv/Makefile
> create mode 100644 arch/arm64/hyperv/hv_hvc.S
> create mode 100644 arch/arm64/hyperv/hv_init.c
> create mode 100644 arch/arm64/hyperv/mshyperv.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 72f19cef4c48..326eeb32a0cd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6837,6 +6837,7 @@ F: arch/x86/kernel/cpu/mshyperv.c
> F: arch/x86/hyperv
> F: arch/arm64/include/asm/hyperv-tlfs.h
> F: arch/arm64/include/asm/mshyperv.h
> +F: arch/arm64/hyperv
> F: drivers/hid/hid-hyperv.c
> F: drivers/hv/
> F: drivers/input/serio/hyperv-keyboard.c
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 6cb9fc7e9382..ad9ec0579553 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -106,6 +106,7 @@ core-y += arch/arm64/kernel/ arch/arm64/mm/
> core-$(CONFIG_NET) += arch/arm64/net/
> core-$(CONFIG_KVM) += arch/arm64/kvm/
> core-$(CONFIG_XEN) += arch/arm64/xen/
> +core-$(CONFIG_HYPERV) += arch/arm64/hyperv/
> core-$(CONFIG_CRYPTO) += arch/arm64/crypto/
> libs-y := arch/arm64/lib/ $(libs-y)
> core-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
> diff --git a/arch/arm64/hyperv/Makefile b/arch/arm64/hyperv/Makefile
> new file mode 100644
> index 000000000000..988eda55330c
> --- /dev/null
> +++ b/arch/arm64/hyperv/Makefile
> @@ -0,0 +1,2 @@
> +# SPDX-License-Identifier: GPL-2.0
> +obj-y := hv_init.o hv_hvc.o mshyperv.o
> diff --git a/arch/arm64/hyperv/hv_hvc.S b/arch/arm64/hyperv/hv_hvc.S
> new file mode 100644
> index 000000000000..82636969b4f2
> --- /dev/null
> +++ b/arch/arm64/hyperv/hv_hvc.S
> @@ -0,0 +1,54 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +/*
> + * Microsoft Hyper-V hypervisor invocation routines
> + *
> + * Copyright (C) 2018, Microsoft, Inc.
> + *
> + * Author : Michael Kelley <mikelley@microsoft.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> + * by the Free Software Foundation.
> + *
> + * 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, GOOD TITLE or
> + * NON INFRINGEMENT. See the GNU General Public License for more
> + * details.
> + */
> +
> +#include <linux/linkage.h>
> +
> + .text
> +/*
> + * Do the HVC instruction. For Hyper-V the argument is always 1.
> + * x0 contains the hypercall control value, while additional registers
> + * vary depending on the hypercall, and whether the hypercall arguments
> + * are in memory or in registers (a "fast" hypercall per the Hyper-V
> + * TLFS). When the arguments are in memory x1 is the guest physical
> + * address of the input arguments, and x2 is the guest physical
> + * address of the output arguments. When the arguments are in
> + * registers, the register values depends on the hypercall. Note
> + * that this version cannot return any values in registers.
> + */
> +ENTRY(hv_do_hvc)
> + hvc #1
> + ret
> +ENDPROC(hv_do_hvc)
> +
> +/*
> + * This variant of HVC invocation is for hv_get_vpreg and
> + * hv_get_vpreg_128. The input parameters are passed in registers
> + * along with a pointer in x4 to where the output result should
> + * be stored. The output is returned in x15 and x16. x18 is used as
> + * scratch space to avoid buildng a stack frame, as Hyper-V does
> + * not preserve registers x0-x17.
> + */
> +ENTRY(hv_do_hvc_fast_get)
> + mov x18, x4
> + hvc #1
> + str x15,[x18]
> + str x16,[x18,#8]
> + ret
> +ENDPROC(hv_do_hvc_fast_get)
As Will said, this isn't a viable option. Please follow SMCCC 1.1.
> diff --git a/arch/arm64/hyperv/hv_init.c b/arch/arm64/hyperv/hv_init.c
> new file mode 100644
> index 000000000000..aa1a8c09d989
> --- /dev/null
> +++ b/arch/arm64/hyperv/hv_init.c
> @@ -0,0 +1,441 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Initialization of the interface with Microsoft's Hyper-V hypervisor,
> + * and various low level utility routines for interacting with Hyper-V.
> + *
> + * Copyright (C) 2018, Microsoft, Inc.
> + *
> + * Author : Michael Kelley <mikelley@microsoft.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> + * by the Free Software Foundation.
> + *
> + * 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, GOOD TITLE or
> + * NON INFRINGEMENT. See the GNU General Public License for more
> + * details.
> + */
> +
> +
> +#include <linux/types.h>
> +#include <linux/version.h>
> +#include <linux/export.h>
> +#include <linux/vmalloc.h>
> +#include <linux/mm.h>
> +#include <linux/clocksource.h>
> +#include <linux/sched_clock.h>
> +#include <linux/acpi.h>
> +#include <linux/module.h>
> +#include <linux/hyperv.h>
> +#include <linux/slab.h>
> +#include <linux/cpuhotplug.h>
> +#include <linux/psci.h>
> +#include <asm-generic/bug.h>
> +#include <asm/hypervisor.h>
> +#include <asm/hyperv-tlfs.h>
> +#include <asm/mshyperv.h>
> +#include <asm/sysreg.h>
> +#include <clocksource/arm_arch_timer.h>
> +
> +static bool hyperv_initialized;
> +struct ms_hyperv_info ms_hyperv;
> +EXPORT_SYMBOL_GPL(ms_hyperv);
Who are the users of this structure? Should they go via accessors instead?
> +
> +static struct ms_hyperv_tsc_page *tsc_pg;
> +
> +struct ms_hyperv_tsc_page *hv_get_tsc_page(void)
> +{
> + return tsc_pg;
> +}
> +EXPORT_SYMBOL_GPL(hv_get_tsc_page);
> +
> +static u64 read_hv_sched_clock_tsc(void)
> +{
> + u64 current_tick = hv_read_tsc_page(tsc_pg);
> +
> + if (current_tick == U64_MAX)
> + current_tick = hv_get_vpreg(HV_REGISTER_TIME_REFCOUNT);
> +
> + return current_tick;
> +}
> +
> +static u64 read_hv_clock_tsc(struct clocksource *arg)
> +{
> + u64 current_tick = hv_read_tsc_page(tsc_pg);
> +
> + if (current_tick == U64_MAX)
> + current_tick = hv_get_vpreg(HV_REGISTER_TIME_REFCOUNT);
> +
> + return current_tick;
> +}
Can't you define one function in terms of the other?
> +
> +static struct clocksource hyperv_cs_tsc = {
> + .name = "hyperv_clocksource_tsc_page",
> + .rating = 400,
> + .read = read_hv_clock_tsc,
> + .mask = CLOCKSOURCE_MASK(64),
> + .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> +};
> +
> +static u64 read_hv_sched_clock_msr(void)
> +{
> + return hv_get_vpreg(HV_REGISTER_TIME_REFCOUNT);
> +}
> +
> +static u64 read_hv_clock_msr(struct clocksource *arg)
> +{
> + return hv_get_vpreg(HV_REGISTER_TIME_REFCOUNT);
> +}
> +
> +static struct clocksource hyperv_cs_msr = {
> + .name = "hyperv_clocksource_msr",
> + .rating = 400,
> + .read = read_hv_clock_msr,
> + .mask = CLOCKSOURCE_MASK(64),
> + .flags = CLOCK_SOURCE_IS_CONTINUOUS,
> +};
> +
> +struct clocksource *hyperv_cs;
> +EXPORT_SYMBOL_GPL(hyperv_cs);
Why? Who needs to poke this?
> +
> +u32 *hv_vp_index;
> +EXPORT_SYMBOL_GPL(hv_vp_index);
> +
> +u32 hv_max_vp_index;
Same thing.
> +
> +static int hv_cpu_init(unsigned int cpu)
> +{
> + u64 msr_vp_index;
> +
> + hv_get_vp_index(msr_vp_index);
> +
> + hv_vp_index[smp_processor_id()] = msr_vp_index;
> +
> + if (msr_vp_index > hv_max_vp_index)
> + hv_max_vp_index = msr_vp_index;
> +
> + return 0;
> +}
Is that some new way to describe a CPU topology? If so, why isn't that
exposed via the ACPI tables that the kernel already parses?
> +
> +/*
> + * This function is invoked via the ACPI clocksource probe mechanism. We
> + * don't actually use any values from the ACPI GTDT table, but we set up
This doesn't feel like a good idea at all. Piggy-backing on an existing
mechanism and use it for something completely different is not exactly
future-proof.
Also, if this is supposed to be a clocksource, why isn't that a
clocksource driver on its own right?
> + * the Hyper-V synthetic clocksource and do other initialization for
> + * interacting with Hyper-V the first time. Using early_initcall to invoke
> + * this function is too late because interrupts are already enabled at that
> + * point, and sched_clock_register must run before interrupts are enabled.
> + *
> + * 1. Setup the guest ID.
> + * 2. Get features and hints info from Hyper-V
> + * 3. Setup per-cpu VP indices.
> + * 4. Register Hyper-V specific clocksource.
> + * 5. Register the scheduler clock.
> + */
> +
> +static int __init hyperv_init(struct acpi_table_header *table)
> +{
> + struct hv_get_vp_register_output result;
> + u32 a, b, c, d;
> + u64 guest_id;
> + int i;
> +
> + /*
> + * If we're in a VM on Hyper-V, the ACPI hypervisor_id field will
> + * have the string "MsHyperV".
> + */
> + if (strncmp((char *)&acpi_gbl_FADT.hypervisor_id, "MsHyperV", 8))
> + return 1;
> +
> + /* Setup the guest ID */
> + guest_id = generate_guest_id(0, LINUX_VERSION_CODE, 0);
> + hv_set_vpreg(HV_REGISTER_GUEST_OSID, guest_id);
> +
> + /* Get the features and hints from Hyper-V */
> + hv_get_vpreg_128(HV_REGISTER_PRIVILEGES_AND_FEATURES, &result);
> + ms_hyperv.features = lower_32_bits(result.registervaluelow);
> + ms_hyperv.misc_features = upper_32_bits(result.registervaluehigh);
> +
> + hv_get_vpreg_128(HV_REGISTER_FEATURES, &result);
> + ms_hyperv.hints = lower_32_bits(result.registervaluelow);
> +
> + pr_info("Hyper-V: Features 0x%x, hints 0x%x\n",
> + ms_hyperv.features, ms_hyperv.hints);
> +
> + /*
> + * Direct mode is the only option for STIMERs provided Hyper-V
> + * on ARM64, so Hyper-V doesn't actually set the flag. But add the
> + * flag so the architecture independent code in drivers/hv/hv.c
> + * will correctly use that mode.
> + */
> + ms_hyperv.misc_features |= HV_STIMER_DIRECT_MODE_AVAILABLE;
> +
> + /*
> + * Hyper-V on ARM64 doesn't support AutoEOI. Add the hint
> + * that tells architecture independent code not to use this
> + * feature.
> + */
> + ms_hyperv.hints |= HV_DEPRECATING_AEOI_RECOMMENDED;
> +
> + /* Get information about the Hyper-V host version */
> + hv_get_vpreg_128(HV_REGISTER_HYPERVISOR_VERSION, &result);
> + a = lower_32_bits(result.registervaluelow);
> + b = upper_32_bits(result.registervaluelow);
> + c = lower_32_bits(result.registervaluehigh);
> + d = upper_32_bits(result.registervaluehigh);
> + pr_info("Hyper-V: Host Build %d.%d.%d.%d-%d-%d\n",
> + b >> 16, b & 0xFFFF, a, d & 0xFFFFFF, c, d >> 24);
> +
> + /* Allocate percpu VP index */
> + hv_vp_index = kmalloc_array(num_possible_cpus(), sizeof(*hv_vp_index),
> + GFP_KERNEL);
Why isn't this a percpu variable?
> + if (!hv_vp_index)
> + return 1;
> +
> + for (i = 0; i < num_possible_cpus(); i++)
> + hv_vp_index[i] = VP_INVAL;
> +
> + if (cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "arm64/hyperv_init:online",
> + hv_cpu_init, NULL) < 0)
> + goto free_vp_index;
> +
> + /*
> + * Try to set up what Hyper-V calls the "TSC reference page", which
> + * uses the ARM Generic Timer virtual counter with some scaling
> + * information to provide a fast and stable guest VM clocksource.
> + * If the TSC reference page can't be set up, fall back to reading
> + * the guest clock provided by Hyper-V's synthetic reference time
> + * register.
> + */
> + if (ms_hyperv.features & HV_MSR_REFERENCE_TSC_AVAILABLE) {
> +
> + u64 tsc_msr;
> + phys_addr_t phys_addr;
> +
> + tsc_pg = __vmalloc(HV_HYP_PAGE_SIZE, GFP_KERNEL, PAGE_KERNEL);
And why not vmalloc?
> + if (tsc_pg) {
> + phys_addr = page_to_phys(vmalloc_to_page(tsc_pg));
> + tsc_msr = hv_get_vpreg(HV_REGISTER_REFERENCE_TSC);
> + tsc_msr &= GENMASK_ULL(11, 0);
Magic.
> + tsc_msr = tsc_msr | 0x1 | (u64)phys_addr;
> + hv_set_vpreg(HV_REGISTER_REFERENCE_TSC, tsc_msr);
> + hyperv_cs = &hyperv_cs_tsc;
> + sched_clock_register(read_hv_sched_clock_tsc,
> + 64, HV_CLOCK_HZ);
> + }
> + }
> +
> + if (!hyperv_cs &&
> + (ms_hyperv.features & HV_MSR_TIME_REF_COUNT_AVAILABLE)) {
> + hyperv_cs = &hyperv_cs_msr;
> + sched_clock_register(read_hv_sched_clock_msr,
> + 64, HV_CLOCK_HZ);
> + }
> +
> + if (hyperv_cs) {
> + hyperv_cs->archdata.vdso_direct = false;
> + clocksource_register_hz(hyperv_cs, HV_CLOCK_HZ);
> + }
> +
> + hyperv_initialized = true;
> + return 0;
> +
> +free_vp_index:
> + kfree(hv_vp_index);
> + hv_vp_index = NULL;
> + return 1;
????
> +}
> +TIMER_ACPI_DECLARE(hyperv, ACPI_SIG_GTDT, hyperv_init);
> +
> +/*
> + * This routine is called before kexec/kdump, it does the required cleanup.
> + */
> +void hyperv_cleanup(void)
> +{
> + /* Reset our OS id */
> + hv_set_vpreg(HV_REGISTER_GUEST_OSID, 0);
> +
> +}
> +EXPORT_SYMBOL_GPL(hyperv_cleanup);
> +
> +/*
> + * hv_do_hypercall- Invoke the specified hypercall
> + */
> +u64 hv_do_hypercall(u64 control, void *input, void *output)
> +{
> + u64 input_address;
> + u64 output_address;
> +
> + input_address = input ? virt_to_phys(input) : 0;
> + output_address = output ? virt_to_phys(output) : 0;
> + return hv_do_hvc(control, input_address, output_address);
> +}
> +EXPORT_SYMBOL_GPL(hv_do_hypercall);
> +
> +/*
> + * hv_do_fast_hypercall8 -- Invoke the specified hypercall
> + * with arguments in registers instead of physical memory.
> + * Avoids the overhead of virt_to_phys for simple hypercalls.
> + */
> +
> +u64 hv_do_fast_hypercall8(u16 code, u64 input)
> +{
> + u64 control;
> +
> + control = (u64)code | HV_HYPERCALL_FAST_BIT;
> + return hv_do_hvc(control, input);
> +}
> +EXPORT_SYMBOL_GPL(hv_do_fast_hypercall8);
> +
> +
> +/*
> + * Set a single VP register to a 64-bit value.
> + */
> +void hv_set_vpreg(u32 msr, u64 value)
> +{
> + union hv_hypercall_status status;
> +
> + status.as_uint64 = hv_do_hvc(
> + HVCALL_SET_VP_REGISTERS | HV_HYPERCALL_FAST_BIT |
> + HV_HYPERCALL_REP_COUNT_1,
> + HV_PARTITION_ID_SELF,
> + HV_VP_INDEX_SELF,
> + msr,
> + 0,
> + value,
> + 0);
> +
> + /*
> + * Something is fundamentally broken in the hypervisor if
> + * setting a VP register fails. There's really no way to
> + * continue as a guest VM, so panic.
> + */
> + BUG_ON(status.status != HV_STATUS_SUCCESS);
> +}
> +EXPORT_SYMBOL_GPL(hv_set_vpreg);
> +
> +
> +/*
> + * Get the value of a single VP register, and only the low order 64 bits.
> + */
> +u64 hv_get_vpreg(u32 msr)
> +{
> + union hv_hypercall_status status;
> + struct hv_get_vp_register_output output;
> +
> + status.as_uint64 = hv_do_hvc_fast_get(
> + HVCALL_GET_VP_REGISTERS | HV_HYPERCALL_FAST_BIT |
> + HV_HYPERCALL_REP_COUNT_1,
> + HV_PARTITION_ID_SELF,
> + HV_VP_INDEX_SELF,
> + msr,
> + &output);
> +
> + /*
> + * Something is fundamentally broken in the hypervisor if
> + * getting a VP register fails. There's really no way to
> + * continue as a guest VM, so panic.
> + */
> + BUG_ON(status.status != HV_STATUS_SUCCESS);
> +
> + return output.registervaluelow;
> +}
> +EXPORT_SYMBOL_GPL(hv_get_vpreg);
> +
> +/*
> + * Get the value of a single VP register that is 128 bits in size. This is a
> + * separate call in order to avoid complicating the calling sequence for
> + * the much more frequently used 64-bit version.
> + */
> +void hv_get_vpreg_128(u32 msr, struct hv_get_vp_register_output *result)
> +{
> + union hv_hypercall_status status;
> +
> + status.as_uint64 = hv_do_hvc_fast_get(
> + HVCALL_GET_VP_REGISTERS | HV_HYPERCALL_FAST_BIT |
> + HV_HYPERCALL_REP_COUNT_1,
> + HV_PARTITION_ID_SELF,
> + HV_VP_INDEX_SELF,
> + msr,
> + result);
> +
> + /*
> + * Something is fundamentally broken in the hypervisor if
> + * getting a VP register fails. There's really no way to
> + * continue as a guest VM, so panic.
> + */
> + BUG_ON(status.status != HV_STATUS_SUCCESS);
> +
> + return;
> +
> +}
> +EXPORT_SYMBOL_GPL(hv_get_vpreg_128);
> +
> +void hyperv_report_panic(struct pt_regs *regs, long err)
> +{
> + static bool panic_reported;
> + u64 guest_id;
> +
> + /*
> + * We prefer to report panic on 'die' chain as we have proper
> + * registers to report, but if we miss it (e.g. on BUG()) we need
> + * to report it on 'panic'.
> + */
> + if (panic_reported)
> + return;
> + panic_reported = true;
> +
> + guest_id = hv_get_vpreg(HV_REGISTER_GUEST_OSID);
> +
> + /*
> + * Hyper-V provides the ability to store only 5 values.
> + * Pick the passed in error value, the guest_id, and the PC.
> + * The first two general registers are added arbitrarily.
> + */
> + hv_set_vpreg(HV_REGISTER_CRASH_P0, err);
> + hv_set_vpreg(HV_REGISTER_CRASH_P1, guest_id);
> + hv_set_vpreg(HV_REGISTER_CRASH_P2, regs->pc);
> + hv_set_vpreg(HV_REGISTER_CRASH_P3, regs->regs[0]);
> + hv_set_vpreg(HV_REGISTER_CRASH_P4, regs->regs[1]);
> +
> + /*
> + * Let Hyper-V know there is crash data available
> + */
> + hv_set_vpreg(HV_REGISTER_CRASH_CTL, HV_CRASH_CTL_CRASH_NOTIFY);
> +}
> +EXPORT_SYMBOL_GPL(hyperv_report_panic);
> +
> +/*
> + * hyperv_report_panic_msg - report panic message to Hyper-V
> + * @pa: physical address of the panic page containing the message
> + * @size: size of the message in the page
> + */
> +void hyperv_report_panic_msg(phys_addr_t pa, size_t size)
> +{
> + /*
> + * P3 to contain the physical address of the panic page & P4 to
> + * contain the size of the panic data in that page. Rest of the
> + * registers are no-op when the NOTIFY_MSG flag is set.
> + */
> + hv_set_vpreg(HV_REGISTER_CRASH_P0, 0);
> + hv_set_vpreg(HV_REGISTER_CRASH_P1, 0);
> + hv_set_vpreg(HV_REGISTER_CRASH_P2, 0);
> + hv_set_vpreg(HV_REGISTER_CRASH_P3, pa);
> + hv_set_vpreg(HV_REGISTER_CRASH_P4, size);
> +
> + /*
> + * Let Hyper-V know there is crash data available along with
> + * the panic message.
> + */
> + hv_set_vpreg(HV_REGISTER_CRASH_CTL,
> + (HV_CRASH_CTL_CRASH_NOTIFY | HV_CRASH_CTL_CRASH_NOTIFY_MSG));
> +}
> +EXPORT_SYMBOL_GPL(hyperv_report_panic_msg);
> +
> +bool hv_is_hyperv_initialized(void)
> +{
> + return hyperv_initialized;
> +}
> +EXPORT_SYMBOL_GPL(hv_is_hyperv_initialized);
> diff --git a/arch/arm64/hyperv/mshyperv.c b/arch/arm64/hyperv/mshyperv.c
> new file mode 100644
> index 000000000000..3ef055599412
> --- /dev/null
> +++ b/arch/arm64/hyperv/mshyperv.c
> @@ -0,0 +1,178 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Core routines for interacting with Microsoft's Hyper-V hypervisor,
> + * including setting up VMbus and STIMER interrupts, and handling
> + * crashes and kexecs. These interactions are through a set of
> + * static "handler" variables set by the architecture independent
> + * VMbus and STIMER drivers. This design is used to meet x86/x64
> + * requirements for avoiding direct linkages and allowing the VMbus
> + * and STIMER drivers to be unloaded and reloaded.
> + *
> + * Copyright (C) 2018, Microsoft, Inc.
> + *
> + * Author : Michael Kelley <mikelley@microsoft.com>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License version 2 as published
> + * by the Free Software Foundation.
> + *
> + * 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, GOOD TITLE or
> + * NON INFRINGEMENT. See the GNU General Public License for more
> + * details.
> + */
> +
> +#include <linux/types.h>
> +#include <linux/export.h>
> +#include <linux/interrupt.h>
> +#include <linux/kexec.h>
> +#include <linux/acpi.h>
> +#include <linux/ptrace.h>
> +#include <asm/hyperv-tlfs.h>
> +#include <asm/mshyperv.h>
> +
> +static void (*vmbus_handler)(void);
> +static void (*hv_stimer0_handler)(void);
> +static void (*hv_kexec_handler)(void);
> +static void (*hv_crash_handler)(struct pt_regs *regs);
> +
> +static int vmbus_irq;
> +static long __percpu *vmbus_evt;
> +static long __percpu *stimer0_evt;
> +
> +irqreturn_t hyperv_vector_handler(int irq, void *dev_id)
> +{
> + if (vmbus_handler)
> + vmbus_handler();
In which circumstances can this be NULL?
> + return IRQ_HANDLED;
> +}
> +
> +/* Must be done just once */
> +void hv_setup_vmbus_irq(void (*handler)(void))
> +{
> + int result;
> +
> + vmbus_handler = handler;
If thismust only be done once, maybe you could check that it hasn't been
done already?
> + vmbus_irq = acpi_register_gsi(NULL, HYPERVISOR_CALLBACK_VECTOR,
> + ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_HIGH);
> + if (vmbus_irq <= 0) {
> + pr_err("Can't register Hyper-V VMBus GSI. Error %d",
> + vmbus_irq);
> + vmbus_irq = 0;
> + return;
> + }
> + vmbus_evt = alloc_percpu(long);
> + result = request_percpu_irq(vmbus_irq, hyperv_vector_handler,
> + "Hyper-V VMbus", vmbus_evt);
If this is a per-cpu interrupt, why isn't it signalled as a PPI, in an
architecture compliant way?
> + if (result) {
> + pr_err("Can't request Hyper-V VMBus IRQ %d. Error %d",
> + vmbus_irq, result);
> + free_percpu(vmbus_evt);
> + acpi_unregister_gsi(vmbus_irq);
> + vmbus_irq = 0;
> + }
> +}
> +EXPORT_SYMBOL_GPL(hv_setup_vmbus_irq);
> +
> +/* Must be done just once */
> +void hv_remove_vmbus_irq(void)
> +{
> + if (vmbus_irq) {
> + free_percpu_irq(vmbus_irq, vmbus_evt);
> + free_percpu(vmbus_evt);
> + acpi_unregister_gsi(vmbus_irq);
> + }
> +}
> +EXPORT_SYMBOL_GPL(hv_remove_vmbus_irq);
> +
> +/* Must be done by each CPU */
> +void hv_enable_vmbus_irq(void)
> +{
> + enable_percpu_irq(vmbus_irq, 0);
> +}
> +EXPORT_SYMBOL_GPL(hv_enable_vmbus_irq);
> +
> +/* Must be done by each CPU */
> +void hv_disable_vmbus_irq(void)
> +{
> + disable_percpu_irq(vmbus_irq);
> +}
> +EXPORT_SYMBOL_GPL(hv_disable_vmbus_irq);
> +
> +/* Routines to do per-architecture handling of STIMER0 when in Direct Mode */
> +
> +static irqreturn_t hv_stimer0_vector_handler(int irq, void *dev_id)
> +{
> + if (hv_stimer0_handler)
> + hv_stimer0_handler();
> + return IRQ_HANDLED;
> +}
> +
> +int hv_setup_stimer0_irq(int *irq, int *vector, void (*handler)(void))
> +{
> + int localirq;
> + int result;
> +
> + localirq = acpi_register_gsi(NULL, HV_STIMER0_IRQNR,
> + ACPI_LEVEL_SENSITIVE, ACPI_ACTIVE_HIGH);
> + if (localirq <= 0) {
> + pr_err("Can't register Hyper-V stimer0 GSI. Error %d",
> + localirq);
> + *irq = 0;
> + return -1;
> + }
> + stimer0_evt = alloc_percpu(long);
> + result = request_percpu_irq(localirq, hv_stimer0_vector_handler,
> + "Hyper-V stimer0", stimer0_evt);
> + if (result) {
> + pr_err("Can't request Hyper-V stimer0 IRQ %d. Error %d",
> + localirq, result);
> + free_percpu(stimer0_evt);
> + acpi_unregister_gsi(localirq);
> + *irq = 0;
> + return -1;
> + }
> +
> + hv_stimer0_handler = handler;
> + *vector = HV_STIMER0_IRQNR;
> + *irq = localirq;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(hv_setup_stimer0_irq);
> +
> +void hv_remove_stimer0_irq(int irq)
> +{
> + hv_stimer0_handler = NULL;
> + if (irq) {
> + free_percpu_irq(irq, stimer0_evt);
> + free_percpu(stimer0_evt);
> + acpi_unregister_gsi(irq);
> + }
> +}
> +EXPORT_SYMBOL_GPL(hv_remove_stimer0_irq);
> +
> +void hv_setup_kexec_handler(void (*handler)(void))
> +{
> + hv_kexec_handler = handler;
> +}
> +EXPORT_SYMBOL_GPL(hv_setup_kexec_handler);
> +
> +void hv_remove_kexec_handler(void)
> +{
> + hv_kexec_handler = NULL;
> +}
> +EXPORT_SYMBOL_GPL(hv_remove_kexec_handler);
> +
> +void hv_setup_crash_handler(void (*handler)(struct pt_regs *regs))
> +{
> + hv_crash_handler = handler;
> +}
> +EXPORT_SYMBOL_GPL(hv_setup_crash_handler);
> +
> +void hv_remove_crash_handler(void)
> +{
> + hv_crash_handler = NULL;
> +}
> +EXPORT_SYMBOL_GPL(hv_remove_crash_handler);
>
Overall, this patch needs a massive split up, clean up, and a good dose
of documentation so that we can understand what you are trying to achieve.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 3/3] Input: atmel_mxt_ts: Document optional voltage regulators
From: Paweł Chmiel @ 2018-12-07 14:28 UTC (permalink / raw)
To: nick
Cc: mark.rutland, devicetree, alexandre.belloni, dmitry.torokhov,
linux-kernel, robh+dt, linux-input, linux-arm-kernel,
Paweł Chmiel
In-Reply-To: <20181207142857.15818-1-pawel.mikolaj.chmiel@gmail.com>
Document new optional voltage regulators, which can be used
to power down/up touchscreen.
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes from v1:
- Added reviewed-by
---
.../devicetree/bindings/input/atmel,maxtouch.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
index c88919480d37..17930ecadad3 100644
--- a/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
+++ b/Documentation/devicetree/bindings/input/atmel,maxtouch.txt
@@ -31,6 +31,12 @@ Optional properties for main touchpad device:
- reset-gpios: GPIO specifier for the touchscreen's reset pin (active low)
+- avdd-supply: Analog power supply. It powers up the analog channel block
+ of the controller to detect the touches.
+
+- vdd-supply: Digital power supply. It powers up the digital block
+ of the controller to enable i2c communication.
+
Example:
touch@4b {
@@ -38,4 +44,6 @@ Example:
reg = <0x4b>;
interrupt-parent = <&gpio>;
interrupts = <TEGRA_GPIO(W, 3) IRQ_TYPE_LEVEL_LOW>;
+ avdd-supply = <&atsp_reg>;
+ vdd-supply = <&tsp_reg>;
};
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 10/19] clk: tegra: dfll: build clk-dfll.c for Tegra124 and Tegra210
From: Jon Hunter @ 2018-12-07 14:40 UTC (permalink / raw)
To: Joseph Lo, Thierry Reding, Peter De Schrijver
Cc: linux-tegra, linux-clk, linux-arm-kernel
In-Reply-To: <20181204092548.3038-11-josephl@nvidia.com>
On 04/12/2018 09:25, Joseph Lo wrote:
> From: Peter De Schrijver <pdeschrijver@nvidia.com>
>
> Tegra210 has a DFLL as well and can share the majority of the code with
> the Tegra124 implementation. So build the same code for both platforms.
>
> Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
> Signed-off-by: Joseph Lo <josephl@nvidia.com>
> ---
> drivers/clk/tegra/Kconfig | 5 +++++
> drivers/clk/tegra/Makefile | 2 +-
> 2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/tegra/Kconfig b/drivers/clk/tegra/Kconfig
> index 7ddacae5d0b1..57902ab43f4a 100644
> --- a/drivers/clk/tegra/Kconfig
> +++ b/drivers/clk/tegra/Kconfig
> @@ -5,3 +5,8 @@ config TEGRA_CLK_EMC
> config CLK_TEGRA_BPMP
> def_bool y
> depends on TEGRA_BPMP
> +
> +config TEGRA_CLK_DFLL
> + depends on (ARCH_TEGRA_124_SOC || ARCH_TEGRA_210_SOC)
> + select PM_OPP
> + def_bool y
> diff --git a/drivers/clk/tegra/Makefile b/drivers/clk/tegra/Makefile
> index 6507acc843c7..4812e45c2214 100644
> --- a/drivers/clk/tegra/Makefile
> +++ b/drivers/clk/tegra/Makefile
> @@ -20,7 +20,7 @@ obj-$(CONFIG_ARCH_TEGRA_2x_SOC) += clk-tegra20.o
> obj-$(CONFIG_ARCH_TEGRA_3x_SOC) += clk-tegra30.o
> obj-$(CONFIG_ARCH_TEGRA_114_SOC) += clk-tegra114.o
> obj-$(CONFIG_ARCH_TEGRA_124_SOC) += clk-tegra124.o
> -obj-$(CONFIG_ARCH_TEGRA_124_SOC) += clk-tegra124-dfll-fcpu.o
> +obj-$(CONFIG_TEGRA_CLK_DFLL) += clk-tegra124-dfll-fcpu.o
> obj-$(CONFIG_ARCH_TEGRA_132_SOC) += clk-tegra124.o
> obj-y += cvb.o
> obj-$(CONFIG_ARCH_TEGRA_210_SOC) += clk-tegra210.o
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Cheers
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 09/19] clk: tegra: dfll: add CVB tables for Tegra210
From: Jon Hunter @ 2018-12-07 14:39 UTC (permalink / raw)
To: Joseph Lo, Thierry Reding, Peter De Schrijver
Cc: linux-tegra, linux-clk, linux-arm-kernel
In-Reply-To: <20181204092548.3038-10-josephl@nvidia.com>
On 04/12/2018 09:25, Joseph Lo wrote:
> Add CVB tables with different chip characterization, so that we can
> generate the customize OPP table that suitable for different chips with
> different SKUs.
>
> Signed-off-by: Joseph Lo <josephl@nvidia.com>
> ---
> drivers/clk/tegra/clk-tegra124-dfll-fcpu.c | 426 +++++++++++++++++++++
> drivers/clk/tegra/cvb.h | 1 +
> 2 files changed, 427 insertions(+)
>
> diff --git a/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c b/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
> index 071a5c674832..bc1358d8084b 100644
> --- a/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
> +++ b/drivers/clk/tegra/clk-tegra124-dfll-fcpu.c
> @@ -88,6 +88,421 @@ static const struct cvb_table tegra124_cpu_cvb_tables[] = {
> },
> };
>
> +static const unsigned long tegra210_cpu_max_freq_table[] = {
> + [0] = 1912500000UL,
> + [1] = 1912500000UL,
> + [2] = 2218500000UL,
> + [3] = 1785000000UL,
> + [4] = 1632000000UL,
> + [5] = 1912500000UL,
> + [6] = 2014500000UL,
> + [7] = 1734000000UL,
> + [8] = 1683000000UL,
> + [9] = 1555500000UL,
> + [10] = 1504500000UL,
> +};
> +
> +#define CPU_CVB_TABLE \
> + .speedo_scale = 100, \
> + .voltage_scale = 1000, \
> + .entries = { \
> + { 204000000UL, { 1007452, -23865, 370 } }, \
> + { 306000000UL, { 1052709, -24875, 370 } }, \
> + { 408000000UL, { 1099069, -25895, 370 } }, \
> + { 510000000UL, { 1146534, -26905, 370 } }, \
> + { 612000000UL, { 1195102, -27915, 370 } }, \
> + { 714000000UL, { 1244773, -28925, 370 } }, \
> + { 816000000UL, { 1295549, -29935, 370 } }, \
> + { 918000000UL, { 1347428, -30955, 370 } }, \
> + { 1020000000UL, { 1400411, -31965, 370 } }, \
> + { 1122000000UL, { 1454497, -32975, 370 } }, \
> + { 1224000000UL, { 1509687, -33985, 370 } }, \
> + { 1326000000UL, { 1565981, -35005, 370 } }, \
> + { 1428000000UL, { 1623379, -36015, 370 } }, \
> + { 1530000000UL, { 1681880, -37025, 370 } }, \
> + { 1632000000UL, { 1741485, -38035, 370 } }, \
> + { 1734000000UL, { 1802194, -39055, 370 } }, \
> + { 1836000000UL, { 1864006, -40065, 370 } }, \
> + { 1912500000UL, { 1910780, -40815, 370 } }, \
> + { 2014500000UL, { 1227000, 0, 0 } }, \
> + { 2218500000UL, { 1227000, 0, 0 } }, \
> + { 0UL, { 0, 0, 0 } }, \
> + }
> +
> +#define CPU_CVB_TABLE_XA \
> + .speedo_scale = 100, \
> + .voltage_scale = 1000, \
> + .entries = { \
> + { 204000000UL, { 1250024, -39785, 565 } }, \
> + { 306000000UL, { 1297556, -41145, 565 } }, \
> + { 408000000UL, { 1346718, -42505, 565 } }, \
> + { 510000000UL, { 1397511, -43855, 565 } }, \
> + { 612000000UL, { 1449933, -45215, 565 } }, \
> + { 714000000UL, { 1503986, -46575, 565 } }, \
> + { 816000000UL, { 1559669, -47935, 565 } }, \
> + { 918000000UL, { 1616982, -49295, 565 } }, \
> + { 1020000000UL, { 1675926, -50645, 565 } }, \
> + { 1122000000UL, { 1736500, -52005, 565 } }, \
> + { 1224000000UL, { 1798704, -53365, 565 } }, \
> + { 1326000000UL, { 1862538, -54725, 565 } }, \
> + { 1428000000UL, { 1928003, -56085, 565 } }, \
> + { 1530000000UL, { 1995097, -57435, 565 } }, \
> + { 1606500000UL, { 2046149, -58445, 565 } }, \
> + { 1632000000UL, { 2063822, -58795, 565 } }, \
> + { 0UL, { 0, 0, 0 } }, \
> + }
> +
> +#define CPU_CVB_TABLE_EUCM1 \
> + .speedo_scale = 100, \
> + .voltage_scale = 1000, \
> + .entries = { \
> + { 204000000UL, { 734429, 0, 0 } }, \
> + { 306000000UL, { 768191, 0, 0 } }, \
> + { 408000000UL, { 801953, 0, 0 } }, \
> + { 510000000UL, { 835715, 0, 0 } }, \
> + { 612000000UL, { 869477, 0, 0 } }, \
> + { 714000000UL, { 903239, 0, 0 } }, \
> + { 816000000UL, { 937001, 0, 0 } }, \
> + { 918000000UL, { 970763, 0, 0 } }, \
> + { 1020000000UL, { 1004525, 0, 0 } }, \
> + { 1122000000UL, { 1038287, 0, 0 } }, \
> + { 1224000000UL, { 1072049, 0, 0 } }, \
> + { 1326000000UL, { 1105811, 0, 0 } }, \
> + { 1428000000UL, { 1130000, 0, 0 } }, \
> + { 1555500000UL, { 1130000, 0, 0 } }, \
> + { 1632000000UL, { 1170000, 0, 0 } }, \
> + { 1734000000UL, { 1227500, 0, 0 } }, \
> + { 0UL, { 0, 0, 0 } }, \
> + }
> +
> +#define CPU_CVB_TABLE_EUCM2 \
> + .speedo_scale = 100, \
> + .voltage_scale = 1000, \
> + .entries = { \
> + { 204000000UL, { 742283, 0, 0 } }, \
> + { 306000000UL, { 776249, 0, 0 } }, \
> + { 408000000UL, { 810215, 0, 0 } }, \
> + { 510000000UL, { 844181, 0, 0 } }, \
> + { 612000000UL, { 878147, 0, 0 } }, \
> + { 714000000UL, { 912113, 0, 0 } }, \
> + { 816000000UL, { 946079, 0, 0 } }, \
> + { 918000000UL, { 980045, 0, 0 } }, \
> + { 1020000000UL, { 1014011, 0, 0 } }, \
> + { 1122000000UL, { 1047977, 0, 0 } }, \
> + { 1224000000UL, { 1081943, 0, 0 } }, \
> + { 1326000000UL, { 1090000, 0, 0 } }, \
> + { 1479000000UL, { 1090000, 0, 0 } }, \
> + { 1555500000UL, { 1162000, 0, 0 } }, \
> + { 1683000000UL, { 1195000, 0, 0 } }, \
> + { 0UL, { 0, 0, 0 } }, \
> + }
> +
> +#define CPU_CVB_TABLE_EUCM2_JOINT_RAIL \
> + .speedo_scale = 100, \
> + .voltage_scale = 1000, \
> + .entries = { \
> + { 204000000UL, { 742283, 0, 0 } }, \
> + { 306000000UL, { 776249, 0, 0 } }, \
> + { 408000000UL, { 810215, 0, 0 } }, \
> + { 510000000UL, { 844181, 0, 0 } }, \
> + { 612000000UL, { 878147, 0, 0 } }, \
> + { 714000000UL, { 912113, 0, 0 } }, \
> + { 816000000UL, { 946079, 0, 0 } }, \
> + { 918000000UL, { 980045, 0, 0 } }, \
> + { 1020000000UL, { 1014011, 0, 0 } }, \
> + { 1122000000UL, { 1047977, 0, 0 } }, \
> + { 1224000000UL, { 1081943, 0, 0 } }, \
> + { 1326000000UL, { 1090000, 0, 0 } }, \
> + { 1479000000UL, { 1090000, 0, 0 } }, \
> + { 1504500000UL, { 1120000, 0, 0 } }, \
> + { 0UL, { 0, 0, 0 } }, \
> + }
> +
> +#define CPU_CVB_TABLE_ODN \
> + .speedo_scale = 100, \
> + .voltage_scale = 1000, \
> + .entries = { \
> + { 204000000UL, { 721094, 0, 0 } }, \
> + { 306000000UL, { 754040, 0, 0 } }, \
> + { 408000000UL, { 786986, 0, 0 } }, \
> + { 510000000UL, { 819932, 0, 0 } }, \
> + { 612000000UL, { 852878, 0, 0 } }, \
> + { 714000000UL, { 885824, 0, 0 } }, \
> + { 816000000UL, { 918770, 0, 0 } }, \
> + { 918000000UL, { 915716, 0, 0 } }, \
> + { 1020000000UL, { 984662, 0, 0 } }, \
> + { 1122000000UL, { 1017608, 0, 0 } }, \
> + { 1224000000UL, { 1050554, 0, 0 } }, \
> + { 1326000000UL, { 1083500, 0, 0 } }, \
> + { 1428000000UL, { 1116446, 0, 0 } }, \
> + { 1581000000UL, { 1130000, 0, 0 } }, \
> + { 1683000000UL, { 1168000, 0, 0 } }, \
> + { 1785000000UL, { 1227500, 0, 0 } }, \
> + { 0UL, { 0, 0, 0 } }, \
> + }
> +
> +struct cvb_table tegra210_cpu_cvb_tables[] = {
> + {
> + .speedo_id = 10,
> + .process_id = 0,
> + .min_millivolts = 840,
> + .max_millivolts = 1120,
> + CPU_CVB_TABLE_EUCM2_JOINT_RAIL,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + .tune_high_min_millivolts = 864,
> + }
> + },
> + {
> + .speedo_id = 10,
> + .process_id = 1,
> + .min_millivolts = 840,
> + .max_millivolts = 1120,
> + CPU_CVB_TABLE_EUCM2_JOINT_RAIL,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + .tune_high_min_millivolts = 864,
> + }
> + },
> + {
> + .speedo_id = 9,
> + .process_id = 0,
> + .min_millivolts = 900,
> + .max_millivolts = 1162,
> + CPU_CVB_TABLE_EUCM2,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + }
> + },
> + {
> + .speedo_id = 9,
> + .process_id = 1,
> + .min_millivolts = 900,
> + .max_millivolts = 1162,
> + CPU_CVB_TABLE_EUCM2,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + }
> + },
> + {
> + .speedo_id = 8,
> + .process_id = 0,
> + .min_millivolts = 900,
> + .max_millivolts = 1195,
> + CPU_CVB_TABLE_EUCM2,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + }
> + },
> + {
> + .speedo_id = 8,
> + .process_id = 1,
> + .min_millivolts = 900,
> + .max_millivolts = 1195,
> + CPU_CVB_TABLE_EUCM2,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + }
> + },
> + {
> + .speedo_id = 7,
> + .process_id = 0,
> + .min_millivolts = 841,
> + .max_millivolts = 1227,
> + CPU_CVB_TABLE_EUCM1,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + .tune_high_min_millivolts = 864,
> + }
> + },
> + {
> + .speedo_id = 7,
> + .process_id = 1,
> + .min_millivolts = 841,
> + .max_millivolts = 1227,
> + CPU_CVB_TABLE_EUCM1,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + .tune_high_min_millivolts = 864,
> + }
> + },
> + {
> + .speedo_id = 6,
> + .process_id = 0,
> + .min_millivolts = 870,
> + .max_millivolts = 1150,
> + CPU_CVB_TABLE,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + }
> + },
> + {
> + .speedo_id = 6,
> + .process_id = 1,
> + .min_millivolts = 870,
> + .max_millivolts = 1150,
> + CPU_CVB_TABLE,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune1 = 0x25501d0,
> + }
> + },
> + {
> + .speedo_id = 5,
> + .process_id = 0,
> + .min_millivolts = 818,
> + .max_millivolts = 1227,
> + CPU_CVB_TABLE,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + .tune_high_min_millivolts = 864,
> + }
> + },
> + {
> + .speedo_id = 5,
> + .process_id = 1,
> + .min_millivolts = 818,
> + .max_millivolts = 1227,
> + CPU_CVB_TABLE,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x25501d0,
> + .tune_high_min_millivolts = 864,
> + }
> + },
> + {
> + .speedo_id = 4,
> + .process_id = -1,
> + .min_millivolts = 918,
> + .max_millivolts = 1113,
> + CPU_CVB_TABLE_XA,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune1 = 0x17711BD,
> + }
> + },
> + {
> + .speedo_id = 3,
> + .process_id = 0,
> + .min_millivolts = 825,
> + .max_millivolts = 1227,
> + CPU_CVB_TABLE_ODN,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + .tune_high_min_millivolts = 864,
> + }
> + },
> + {
> + .speedo_id = 3,
> + .process_id = 1,
> + .min_millivolts = 825,
> + .max_millivolts = 1227,
> + CPU_CVB_TABLE_ODN,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x25501d0,
> + .tune_high_min_millivolts = 864,
> + }
> + },
> + {
> + .speedo_id = 2,
> + .process_id = 0,
> + .min_millivolts = 870,
> + .max_millivolts = 1227,
> + CPU_CVB_TABLE,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + }
> + },
> + {
> + .speedo_id = 2,
> + .process_id = 1,
> + .min_millivolts = 870,
> + .max_millivolts = 1227,
> + CPU_CVB_TABLE,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune1 = 0x25501d0,
> + }
> + },
> + {
> + .speedo_id = 1,
> + .process_id = 0,
> + .min_millivolts = 837,
> + .max_millivolts = 1227,
> + CPU_CVB_TABLE,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + .tune_high_min_millivolts = 864,
> + }
> + },
> + {
> + .speedo_id = 1,
> + .process_id = 1,
> + .min_millivolts = 837,
> + .max_millivolts = 1227,
> + CPU_CVB_TABLE,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x25501d0,
> + .tune_high_min_millivolts = 864,
> + }
> + },
> + {
> + .speedo_id = 0,
> + .process_id = 0,
> + .min_millivolts = 850,
> + .max_millivolts = 1170,
> + CPU_CVB_TABLE,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x20091d9,
> + .tune_high_min_millivolts = 864,
> + }
> + },
> + {
> + .speedo_id = 0,
> + .process_id = 1,
> + .min_millivolts = 850,
> + .max_millivolts = 1170,
> + CPU_CVB_TABLE,
> + .cpu_dfll_data = {
> + .tune0_low = 0xffead0ff,
> + .tune0_high = 0xffead0ff,
> + .tune1 = 0x25501d0,
> + .tune_high_min_millivolts = 864,
> + }
> + },
> +};
> +
> static const struct dfll_fcpu_data tegra124_dfll_fcpu_data = {
> .cpu_max_freq_table = tegra124_cpu_max_freq_table,
> .cpu_max_freq_table_size = ARRAY_SIZE(tegra124_cpu_max_freq_table),
> @@ -95,11 +510,22 @@ static const struct dfll_fcpu_data tegra124_dfll_fcpu_data = {
> .cpu_cvb_tables_size = ARRAY_SIZE(tegra124_cpu_cvb_tables)
> };
>
> +static const struct dfll_fcpu_data tegra210_dfll_fcpu_data = {
> + .cpu_max_freq_table = tegra210_cpu_max_freq_table,
> + .cpu_max_freq_table_size = ARRAY_SIZE(tegra210_cpu_max_freq_table),
> + .cpu_cvb_tables = tegra210_cpu_cvb_tables,
> + .cpu_cvb_tables_size = ARRAY_SIZE(tegra210_cpu_cvb_tables),
> +};
> +
> static const struct of_device_id tegra124_dfll_fcpu_of_match[] = {
> {
> .compatible = "nvidia,tegra124-dfll",
> .data = &tegra124_dfll_fcpu_data,
> },
> + {
> + .compatible = "nvidia,tegra210-dfll",
> + .data = &tegra210_dfll_fcpu_data
> + },
> { },
> };
>
> diff --git a/drivers/clk/tegra/cvb.h b/drivers/clk/tegra/cvb.h
> index bcf15a089b93..91a1941c21ef 100644
> --- a/drivers/clk/tegra/cvb.h
> +++ b/drivers/clk/tegra/cvb.h
> @@ -41,6 +41,7 @@ struct cvb_cpu_dfll_data {
> u32 tune0_low;
> u32 tune0_high;
> u32 tune1;
> + unsigned int tune_high_min_millivolts;
Where is this actually used?
Cheers
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Allwinner DT changes for 4.21
From: Maxime Ripard @ 2018-12-07 14:38 UTC (permalink / raw)
To: arm; +Cc: Maxime Ripard, Chen-Yu Tsai, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 13528 bytes --]
Hi Arnd, Kevin, Olof,
Please pull the following changes for the next merge window.
Thanks!
Maxime
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-dt-for-4.21
for you to fetch changes up to 5719ac19fc32d892434939c1756c2f9a8322e6ef:
ARM: dts: sunxi: Fix PMU compatible strings (2018-12-07 15:34:24 +0100)
----------------------------------------------------------------
Allwinner DT changes for 4.21
This is a quite big pull request this time, with a huge number of changes
(and patches) due to us fixing the vast majority of the DTC warnings our DT
had.
We also have a bunch of other good, more meaningful, changes:
- Support for the new Allwinner T3 (rebranded R40) and f1c100s (armv5)
SoCs
- AXP803 PMIC AC Power supply support
- Rework of the oscillators tree
- Two new boards: the t3-cqa3t-bv3 and Lichee Pi Nano
Plus a few enhancements here and there.
----------------------------------------------------------------
Chen-Yu Tsai (6):
ARM: dts: sun8i: a33: Drop audio codec oversampling rate to 128 fs
ARM: dts: sunxi: h3/h5: Add clock accuracy for external oscillators
ARM: dts: sun8i: r40: Add clock accuracy for external oscillators
ARM: dts: sun8i: a23/a33: Fix up RTC device node
ARM: dts: sunxi: h3/h5: Fix up RTC device node and clock references
ARM: dts: sun8i: r40: Add RTC device node
Hao Zhang (2):
Documentation: ARM: sunxi: Add Allwinner SoC T3.
ARM: dts: sun8i: Add board dts file for t3-cqa3t-bv3.
Maxime Ripard (67):
ARM: dts: sun4i: Fix gpio-keys warning
ARM: dts: sun4i: Fix HDMI output DTC warning
ARM: dts: sun5i: Change framebuffer node names to avoid warnings
ARM: dts: sun5i: Change clock node names to avoid warnings
ARM: dts: sun5i: Remove skeleton to avoid warnings
ARM: dts: sun5i: Remove SoC node unit-name to avoid warnings
ARM: dts: sun5i: Remove redundant interrupt-controller
ARM: dts: sun5i: Change LRADC node names to avoid warnings
ARM: dts: sun5i: Remove all useless pinctrl nodes
ARM: dts: sun5i: Remove card detect pull-up
ARM: dts: sun5i: Change pinctrl nodes to avoid warning
ARM: dts: sun5i: a10s: Fix HDMI output DTC warning
ARM: dts: sunxi: Change default CMA pool node name
ARM: dts: sunxi: Remove the CMA node label
ARM: dts: sun5i: Remove underscores from nodes names
ARM: dts: sunxi: Change LRADC node names to avoid warnings
ARM: dts: sun5i: A10s: Remove empty SRAM node
ARM: dts: sun5i: Provide default muxing for relevant controllers
ARM: dts: sun6i: Remove skeleton and memory to avoid warnings
ARM: dts: sun6i: Change framebuffer node names to avoid warnings
ARM: dts: sun6i: Change clock node names to avoid warnings
ARM: dts: sun6i: Remove SoC node unit-name to avoid warnings
ARM: dts: sun6i: Change LRADC node names to avoid warnings
ARM: dts: sun6i: Remove all useless pinctrl nodes
ARM: dts: sun6i: Remove card detect pull-up
ARM: dts: sun6i: Remove redundant MMC pinmux tuning
ARM: dts: sun6i: Change pinctrl nodes to avoid warning
ARM: dts: sun6i: Remove underscores from nodes names
ARM: dts: sun6i: colombus: Change i2c node name to avoid warnings
ARM: dts: sun6i: Provide default muxing for relevant controllers
ARM: dts: sun7i: Remove skeleton and memory to avoid warnings
ARM: dts: sun7i: Remove SoC node unit-name to avoid warnings
ARM: dts: sun7i: Change clock node names to avoid warnings
ARM: dts: sun7i: Change framebuffer node names to avoid warnings
ARM: dts: sun7i: Remove all useless pinctrl nodes
ARM: dts: sun7i: Remove card detect pull-up
ARM: dts: sun7i: Change LRADC node names to avoid warnings
ARM: dts: sun7i: Remove gpio-keys warnings
ARM: dts: sun7i: Change pinctrl nodes to avoid warning
ARM: dts: sun7i: Split the RTS and CTS pins out of the UART nodes
ARM: dts: sun7i: som204: Use the UART3 TX and RX pin group
ARM: dts: sun7i: Remove underscores from nodes names
ARM: dts: sun7i: Fix HDMI output DTC warning
ARM: dts: sun7i: Provide default muxing for relevant controllers
ARM: dts: sun7i: Remove redundant MMC pinmux tuning
ARM: dts: sun7i: lamobo-r1: Remove unused address-cells/size-cells
ARM: dts: sun8i: a23/a33: Remove skeleton and memory to avoid warnings
ARM: dts: sun8i: a23/a33: Remove SoC node unit-name to avoid warnings
ARM: dts: sun8i: a23/a33: Fix OPP DTC warnings
ARM: dts: sun8i: a23/a33: Remove unused address-cells/size-cells
ARM: dts: sun8i: a23/a33: Remove leading zeros from unit-addresses
ARM: dts: sun8i: a23/a33: Change framebuffer node names to avoid warnings
ARM: dts: sun8i: a23/a33: Remove redundant MMC pinmux tuning
ARM: dts: sun8i: a23/a33: Remove all useless pinctrl nodes
ARM: dts: sun8i: a23/a33: Change LRADC node names to avoid warnings
ARM: dts: sun8i: a23/a33: Reorder the pin groups
ARM: dts: sun8i: a23/a33: Remove card detect pull-up
ARM: dts: sun8i: a23/a33: Change pinctrl nodes to avoid warning
ARM: dts: sun8i: a23/a33: Remove underscores from nodes names
ARM: dts: sunxi: reference: Move the muxing back to the common DTSI
ARM: dts: sun8i: a23/a33: Provide default muxing for relevant controllers
ARM: dts: sun8i: BPI-M2M: Remove i2c nodes
ARM: dts: sun8i: h3: Remove leading zeros from unit-addresses
ARM: dts: sun8i: v3s: Change LRADC node names to avoid warnings
ARM: dts: sun8i: v3s: Change pinctrl nodes to avoid warning
ARM: dts: sun8i: v3s: Provide default muxing for relevant controllers
ARM: dts: sun8i: v3s: Remove skeleton and memory to avoid warnings
Mesih Kilinc (2):
ARM: dts: suniv: add initial DTSI file for F1C100s
ARM: dts: suniv: Add device tree for Lichee Pi Nano
Olliver Schinagl (1):
ARM: dts: sun7i: set proper lradc vref on OLinuXino Lime2
Ondrej Jirman (1):
ARM: dts: sun8i-a83t-tbs-a711: Change MMC0 bus-width to 4
Oskari Lemmela (1):
ARM: dts: axp81x: add AC power supply subnode
Paul Kocialkowski (2):
ARM: dts: sun8i: a33: Remove unnecessary reserved memory node
ARM: dts: sun8i: h3: Remove unnecessary reserved memory node
Rob Herring (1):
ARM: dts: sunxi: Fix PMU compatible strings
Viresh Kumar (1):
ARM: dts: sunxi: Add all CPUs in cooling maps
Documentation/devicetree/bindings/arm/sunxi.txt | 3 +-
Documentation/devicetree/bindings/media/cedrus.txt | 2 +-
arch/arm/boot/dts/Makefile | 3 +
arch/arm/boot/dts/axp81x.dtsi | 5 +
arch/arm/boot/dts/sun4i-a10-inet9f-rev03.dts | 2 -
arch/arm/boot/dts/sun4i-a10-pcduino.dts | 2 -
arch/arm/boot/dts/sun4i-a10.dtsi | 2 -
arch/arm/boot/dts/sun5i-a10s-auxtek-t003.dts | 14 +-
arch/arm/boot/dts/sun5i-a10s-auxtek-t004.dts | 25 +--
arch/arm/boot/dts/sun5i-a10s-mk802.dts | 29 +--
arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 54 ++---
arch/arm/boot/dts/sun5i-a10s-r7-tv-dongle.dts | 20 +-
arch/arm/boot/dts/sun5i-a10s-wobo-i5.dts | 30 +--
arch/arm/boot/dts/sun5i-a10s.dtsi | 30 ++-
.../boot/dts/sun5i-a13-empire-electronix-d709.dts | 24 +--
arch/arm/boot/dts/sun5i-a13-hsg-h702.dts | 29 +--
arch/arm/boot/dts/sun5i-a13-licheepi-one.dts | 14 +-
arch/arm/boot/dts/sun5i-a13-olinuxino-micro.dts | 34 +---
arch/arm/boot/dts/sun5i-a13-olinuxino.dts | 38 +---
arch/arm/boot/dts/sun5i-a13-utoo-p66.dts | 14 +-
arch/arm/boot/dts/sun5i-a13.dtsi | 6 +-
arch/arm/boot/dts/sun5i-gr8-chip-pro.dts | 34 +---
arch/arm/boot/dts/sun5i-gr8-evb.dts | 59 ++----
arch/arm/boot/dts/sun5i-gr8.dtsi | 12 +-
arch/arm/boot/dts/sun5i-r8-chip.dts | 40 +---
.../boot/dts/sun5i-reference-design-tablet.dtsi | 35 +---
arch/arm/boot/dts/sun5i.dtsi | 68 ++++---
arch/arm/boot/dts/sun6i-a31-app4-evb1.dts | 10 +-
arch/arm/boot/dts/sun6i-a31-colombus.dts | 33 +--
arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 39 +---
arch/arm/boot/dts/sun6i-a31-i7.dts | 32 +--
arch/arm/boot/dts/sun6i-a31-m9.dts | 30 +--
arch/arm/boot/dts/sun6i-a31-mele-a1000g-quad.dts | 30 +--
arch/arm/boot/dts/sun6i-a31.dtsi | 79 +++----
arch/arm/boot/dts/sun6i-a31s-colorfly-e708-q1.dts | 2 +-
arch/arm/boot/dts/sun6i-a31s-cs908.dts | 6 +-
arch/arm/boot/dts/sun6i-a31s-inet-q972.dts | 8 +-
arch/arm/boot/dts/sun6i-a31s-primo81.dts | 27 +--
arch/arm/boot/dts/sun6i-a31s-sina31s-core.dtsi | 2 +-
arch/arm/boot/dts/sun6i-a31s-sina31s.dts | 27 +--
arch/arm/boot/dts/sun6i-a31s-sinovoip-bpi-m2.dts | 47 +----
.../dts/sun6i-a31s-yones-toptech-bs1078-v2.dts | 20 +-
.../boot/dts/sun6i-reference-design-tablet.dtsi | 10 +-
arch/arm/boot/dts/sun7i-a20-bananapi-m1-plus.dts | 46 +----
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 44 +---
arch/arm/boot/dts/sun7i-a20-bananapro.dts | 65 +-----
arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 21 +-
arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 64 +-----
arch/arm/boot/dts/sun7i-a20-hummingbird.dts | 60 +-----
arch/arm/boot/dts/sun7i-a20-i12-tvbox.dts | 47 +----
arch/arm/boot/dts/sun7i-a20-icnova-swac.dts | 10 +-
arch/arm/boot/dts/sun7i-a20-itead-ibox.dts | 10 +-
arch/arm/boot/dts/sun7i-a20-lamobo-r1.dts | 48 +----
arch/arm/boot/dts/sun7i-a20-m3.dts | 21 +-
arch/arm/boot/dts/sun7i-a20-mk808c.dts | 26 +--
.../arm/boot/dts/sun7i-a20-olimex-som-evb-emmc.dts | 2 -
arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 68 ++-----
.../boot/dts/sun7i-a20-olimex-som204-evb-emmc.dts | 2 -
arch/arm/boot/dts/sun7i-a20-olimex-som204-evb.dts | 36 ++--
arch/arm/boot/dts/sun7i-a20-olinuxino-lime.dts | 22 +-
.../boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts | 11 -
arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 32 +--
.../boot/dts/sun7i-a20-olinuxino-micro-emmc.dts | 2 -
arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 54 ++---
arch/arm/boot/dts/sun7i-a20-orangepi-mini.dts | 52 +----
arch/arm/boot/dts/sun7i-a20-orangepi.dts | 44 +---
arch/arm/boot/dts/sun7i-a20-pcduino3-nano.dts | 31 +--
arch/arm/boot/dts/sun7i-a20-pcduino3.dts | 39 +---
arch/arm/boot/dts/sun7i-a20-wexler-tab7200.dts | 39 +---
arch/arm/boot/dts/sun7i-a20-wits-pro-a20-dkt.dts | 23 +--
arch/arm/boot/dts/sun7i-a20.dtsi | 159 ++++++++-------
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 88 ++++----
arch/arm/boot/dts/sun8i-a23-evb.dts | 20 +-
arch/arm/boot/dts/sun8i-a23-gt90h-v4.dts | 2 +-
.../boot/dts/sun8i-a23-polaroid-mid2407pxe03.dts | 15 +-
.../boot/dts/sun8i-a23-polaroid-mid2809pxe04.dts | 15 +-
arch/arm/boot/dts/sun8i-a23.dtsi | 6 +-
arch/arm/boot/dts/sun8i-a33-ga10h-v1.1.dts | 4 +-
arch/arm/boot/dts/sun8i-a33-inet-d978-rev2.dts | 12 +-
arch/arm/boot/dts/sun8i-a33-olinuxino.dts | 4 +-
arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 20 +-
arch/arm/boot/dts/sun8i-a33.dtsi | 43 ++--
arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 1 +
arch/arm/boot/dts/sun8i-a83t.dtsi | 5 -
arch/arm/boot/dts/sun8i-h3.dtsi | 26 +--
arch/arm/boot/dts/sun8i-q8-common.dtsi | 8 +-
arch/arm/boot/dts/sun8i-r16-bananapi-m2m.dts | 33 +--
.../boot/dts/sun8i-r16-nintendo-nes-classic.dts | 2 +-
arch/arm/boot/dts/sun8i-r16-parrot.dts | 42 +---
arch/arm/boot/dts/sun8i-r40.dtsi | 18 +-
.../boot/dts/sun8i-reference-design-tablet.dtsi | 17 +-
arch/arm/boot/dts/sun8i-t3-cqa3t-bv3.dts | 226 +++++++++++++++++++++
arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dts | 8 +-
arch/arm/boot/dts/sun8i-v3s-licheepi-zero.dts | 4 +-
arch/arm/boot/dts/sun8i-v3s.dtsi | 12 +-
arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts | 26 +++
arch/arm/boot/dts/suniv-f1c100s.dtsi | 147 ++++++++++++++
arch/arm/boot/dts/sunxi-h3-h5.dtsi | 28 ++-
arch/arm/boot/dts/sunxi-itead-core-common.dtsi | 2 +-
.../boot/dts/sunxi-reference-design-tablet.dtsi | 10 +-
arch/arm64/boot/dts/allwinner/sun50i-h5.dtsi | 4 +
101 files changed, 1033 insertions(+), 1923 deletions(-)
create mode 100644 arch/arm/boot/dts/sun8i-t3-cqa3t-bv3.dts
create mode 100644 arch/arm/boot/dts/suniv-f1c100s-licheepi-nano.dts
create mode 100644 arch/arm/boot/dts/suniv-f1c100s.dtsi
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] Allwinner drivers changes for 4.21
From: Maxime Ripard @ 2018-12-07 14:30 UTC (permalink / raw)
To: arm; +Cc: Maxime Ripard, Chen-Yu Tsai, linux-arm-kernel
[-- Attachment #1.1: Type: text/plain, Size: 1614 bytes --]
Hi Arnd, Kevin, Olof,
Please pull the following changes for the next merge window.
Thanks!
Maxime
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git tags/sunxi-drivers-for-4.21
for you to fetch changes up to d44d37cb27df5501de0693fb03803e244653713c:
dt-bindings: sram: sunxi: Add compatible for the A64 SRAM C1 (2018-12-05 12:03:47 +0100)
----------------------------------------------------------------
Allwinner drivers changes for 4.21
Those patches are all about our SRAM driver, to enable new SoCs: the
F1c100s, the H5 and the A64 C1 SRAM, that is used by the video decoding
engine.
----------------------------------------------------------------
Mesih Kilinc (1):
dt-bindings: sram: Add Allwinner suniv F1C100s
Paul Kocialkowski (4):
soc: sunxi: sram: Enable EMAC clock access for H3 variant
soc: sunxi: sram: Add support for the H5 SoC system control
dt-bindings: sram: sunxi: Add bindings for the H5 with SRAM C1
dt-bindings: sram: sunxi: Add compatible for the A64 SRAM C1
Yangtao Li (1):
soc: sunxi: Change to use DEFINE_SHOW_ATTRIBUTE macro
.../devicetree/bindings/sram/sunxi-sram.txt | 9 +++++++++
drivers/soc/sunxi/sunxi_sram.c | 22 ++++++++++------------
2 files changed, 19 insertions(+), 12 deletions(-)
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 08/19] clk: tegra: dfll: round down voltages based on alignment
From: Jon Hunter @ 2018-12-07 14:34 UTC (permalink / raw)
To: Joseph Lo, Thierry Reding, Peter De Schrijver
Cc: linux-tegra, linux-clk, linux-arm-kernel
In-Reply-To: <20181204092548.3038-9-josephl@nvidia.com>
On 04/12/2018 09:25, Joseph Lo wrote:
> When generating the OPP table, the voltages are round down with the
> alignment from the regulator. The alignment should be applied for
> voltages look up as well.
>
> Based on the work of Penny Chiu <pchiu@nvidia.com>.
>
> Signed-off-by: Joseph Lo <josephl@nvidia.com>
> ---
> drivers/clk/tegra/clk-dfll.c | 26 +++++++++++++++-----------
> 1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/clk/tegra/clk-dfll.c b/drivers/clk/tegra/clk-dfll.c
> index c294a2989f31..4a943c136d4d 100644
> --- a/drivers/clk/tegra/clk-dfll.c
> +++ b/drivers/clk/tegra/clk-dfll.c
> @@ -804,17 +804,17 @@ static void dfll_init_out_if(struct tegra_dfll *td)
> static int find_lut_index_for_rate(struct tegra_dfll *td, unsigned long rate)
> {
> struct dev_pm_opp *opp;
> - int i, uv;
> + int i, align_volt;
>
> opp = dev_pm_opp_find_freq_ceil(td->soc->dev, &rate);
> if (IS_ERR(opp))
> return PTR_ERR(opp);
>
> - uv = dev_pm_opp_get_voltage(opp);
This returns an unsigned long.
> + align_volt = dev_pm_opp_get_voltage(opp) / td->soc->alignment.step_uv;
Nit-pick, the 'align_volt' variable does not contain an actual voltage
but a step index. So maybe consider renaming this 'align_step'. And the
same for other places in this change.
Cheers
Jon
--
nvpublic
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v4 2/3] Input: atmel_mxt_ts: Wait for device be ready for communication
From: Paweł Chmiel @ 2018-12-07 14:28 UTC (permalink / raw)
To: nick
Cc: mark.rutland, devicetree, alexandre.belloni, dmitry.torokhov,
linux-kernel, robh+dt, linux-input, linux-arm-kernel,
Paweł Chmiel
In-Reply-To: <20181207142857.15818-1-pawel.mikolaj.chmiel@gmail.com>
According to documentation, device isn't ready for communication,
until firmware asserts the CHG line. Add missing wait for this.
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
---
Changes from v3:
- Fix checkpatch issues
---
drivers/input/touchscreen/atmel_mxt_ts.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index 1dc8ad0da5af..3f956d07d09e 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -202,6 +202,7 @@ enum t100_type {
#define MXT_CRC_TIMEOUT 1000 /* msec */
#define MXT_FW_RESET_TIME 3000 /* msec */
#define MXT_FW_CHG_TIMEOUT 300 /* msec */
+#define MXT_POWERON_DELAY 150 /* msec */
/* Command to unlock bootloader */
#define MXT_UNLOCK_CMD_MSB 0xaa
@@ -3068,6 +3069,16 @@ static int mxt_regulator_enable(struct mxt_data *data)
msleep(MXT_REGULATOR_DELAY);
gpiod_set_value(data->reset_gpio, 1);
msleep(MXT_RESET_INVALID_CHG);
+
+retry_wait:
+ reinit_completion(&data->bl_completion);
+ data->in_bootloader = true;
+ error = mxt_wait_for_completion(data, &data->bl_completion,
+ MXT_POWERON_DELAY);
+ if (error == -EINTR)
+ goto retry_wait;
+
+ data->in_bootloader = false;
}
return 0;
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 1/3] Input: atmel_mxt_ts: Add support for optional regulators
From: Paweł Chmiel @ 2018-12-07 14:28 UTC (permalink / raw)
To: nick
Cc: mark.rutland, devicetree, alexandre.belloni, dmitry.torokhov,
linux-kernel, robh+dt, linux-input, linux-arm-kernel,
Paweł Chmiel
In-Reply-To: <20181207142857.15818-1-pawel.mikolaj.chmiel@gmail.com>
This patch adds optional regulators, which can be used to power
up touchscreen. After enabling regulators, we need to wait 150msec.
This value is taken from official driver.
It was tested on Samsung Galaxy i9000 (based on Samsung S5PV210 SOC).
Signed-off-by: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
---
Changes from v3:
- Fix checkpatch issues
- Drop sentence punctuation from subject of one of patches
Changes from v2:
- Move code enabling regulators into separate method,
to make code more readable.
Changes from v1:
- Enable regulators only if reset_gpio is present.
- Switch from devm_regulator_get_optional to devm_regulator_get
---
drivers/input/touchscreen/atmel_mxt_ts.c | 65 +++++++++++++++++++++---
1 file changed, 59 insertions(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index d3aacd534e9c..1dc8ad0da5af 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -27,6 +27,7 @@
#include <linux/interrupt.h>
#include <linux/of.h>
#include <linux/property.h>
+#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/gpio/consumer.h>
#include <asm/unaligned.h>
@@ -194,10 +195,10 @@ enum t100_type {
/* Delay times */
#define MXT_BACKUP_TIME 50 /* msec */
-#define MXT_RESET_GPIO_TIME 20 /* msec */
#define MXT_RESET_INVALID_CHG 100 /* msec */
#define MXT_RESET_TIME 200 /* msec */
#define MXT_RESET_TIMEOUT 3000 /* msec */
+#define MXT_REGULATOR_DELAY 150 /* msec */
#define MXT_CRC_TIMEOUT 1000 /* msec */
#define MXT_FW_RESET_TIME 3000 /* msec */
#define MXT_FW_CHG_TIMEOUT 300 /* msec */
@@ -323,6 +324,8 @@ struct mxt_data {
struct t7_config t7_cfg;
struct mxt_dbg dbg;
struct gpio_desc *reset_gpio;
+ struct regulator *vdd_reg;
+ struct regulator *avdd_reg;
/* Cached parameters from object table */
u16 T5_address;
@@ -3038,6 +3041,38 @@ static const struct dmi_system_id chromebook_T9_suspend_dmi[] = {
{ }
};
+static int mxt_regulator_enable(struct mxt_data *data)
+{
+ int error;
+
+ if (data->reset_gpio) {
+ error = regulator_enable(data->vdd_reg);
+ if (error) {
+ dev_err(&data->client->dev,
+ "Failed to enable vdd regulator: %d\n", error);
+ return error;
+ }
+
+ error = regulator_enable(data->avdd_reg);
+ if (error) {
+ dev_err(&data->client->dev,
+ "Failed to enable avdd regulator: %d\n", error);
+ return error;
+ }
+
+ /*
+ * According to maXTouch power sequencing specification,
+ * RESET line must be kept low until some time
+ * after regulators come up to voltage
+ */
+ msleep(MXT_REGULATOR_DELAY);
+ gpiod_set_value(data->reset_gpio, 1);
+ msleep(MXT_RESET_INVALID_CHG);
+ }
+
+ return 0;
+}
+
static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
struct mxt_data *data;
@@ -3098,6 +3133,22 @@ static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
return error;
}
+ data->vdd_reg = devm_regulator_get(&client->dev, "vdd");
+ if (IS_ERR(data->vdd_reg)) {
+ error = PTR_ERR(data->vdd_reg);
+ dev_err(&client->dev, "Failed to get vdd regulator: %d\n",
+ error);
+ return error;
+ }
+
+ data->avdd_reg = devm_regulator_get(&client->dev, "avdd");
+ if (IS_ERR(data->avdd_reg)) {
+ error = PTR_ERR(data->avdd_reg);
+ dev_err(&client->dev, "Failed to get avdd regulator: %d\n",
+ error);
+ return error;
+ }
+
error = devm_request_threaded_irq(&client->dev, client->irq,
NULL, mxt_interrupt, IRQF_ONESHOT,
client->name, data);
@@ -3108,11 +3159,9 @@ static int mxt_probe(struct i2c_client *client, const struct i2c_device_id *id)
disable_irq(client->irq);
- if (data->reset_gpio) {
- msleep(MXT_RESET_GPIO_TIME);
- gpiod_set_value(data->reset_gpio, 1);
- msleep(MXT_RESET_INVALID_CHG);
- }
+ error = mxt_regulator_enable(data);
+ if (error)
+ return error;
error = mxt_initialize(data);
if (error)
@@ -3138,6 +3187,10 @@ static int mxt_remove(struct i2c_client *client)
struct mxt_data *data = i2c_get_clientdata(client);
disable_irq(data->irq);
+ if (data->reset_gpio) {
+ regulator_disable(data->avdd_reg);
+ regulator_disable(data->vdd_reg);
+ }
sysfs_remove_group(&client->dev.kobj, &mxt_attr_group);
mxt_free_input_device(data);
mxt_free_object_table(data);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 0/3] Input: atmel_mxt_ts: Add support for optional regulators
From: Paweł Chmiel @ 2018-12-07 14:28 UTC (permalink / raw)
To: nick
Cc: mark.rutland, devicetree, alexandre.belloni, dmitry.torokhov,
linux-kernel, robh+dt, linux-input, linux-arm-kernel,
Paweł Chmiel
This patch series adds optional regulator support to atmel_mxt_ts.
First patch adds regulators to driver.
Second patch ensures that device is ready for communication.
Third patch updates documentation.
Changes from v3:
- Checkpatch fixes
- Drop punctuation from subject of one of patches
Changes from v2:
- Add reviewed-by to one patch
- Move code for enabling regulators into separate method,
to make code more readable.
- Add wait code, to ensure that device is ready for communication.
Changes from v1:
- Enable regulators only if reset_gpio is present.
- Switch from devm_regulator_get_optional to devm_regulator_get.
Paweł Chmiel (3):
Input: atmel_mxt_ts: Add support for optional regulators
Input: atmel_mxt_ts: Wait for device be ready for communication
Input: atmel_mxt_ts: Document optional voltage regulators
.../bindings/input/atmel,maxtouch.txt | 8 ++
drivers/input/touchscreen/atmel_mxt_ts.c | 76 +++++++++++++++++--
2 files changed, 78 insertions(+), 6 deletions(-)
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox