* Re: [PATCHv5] drivers/amba: add reset control to amba bus probe
From: Philipp Zabel @ 2019-08-26 15:51 UTC (permalink / raw)
To: Dinh Nguyen, linux-kernel
Cc: devicetree, daniel.thompson, tony.luck, manivannan.sadhasivam,
keescook, robh, linus.walleij, anton, linux, ccross, frowand.list,
linux-arm-kernel
In-Reply-To: <20190826154252.22952-1-dinguyen@kernel.org>
On Mon, 2019-08-26 at 10:42 -0500, Dinh Nguyen wrote:
> The primecell controller on some SoCs, i.e. SoCFPGA, is held in reset by
> default. Until recently, the DMA controller was brought out of reset by the
> bootloader(i.e. U-Boot). But a recent change in U-Boot, the peripherals
> that are not used are held in reset and are left to Linux to bring them
> out of reset.
>
> Add a mechanism for getting the reset property and de-assert the primecell
> module from reset if found. This is a not a hard fail if the reset properti
> is not present in the device tree node, so the driver will continue to
> probe.
>
> Because there are different variants of the controller that may have
> multiple reset signals, the code will find all reset(s) specified and
> de-assert them.
>
> Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> v5: use of_reset_control_array_get_optional_shared()
> v4: cleaned up indentation in loop
> fix up a few checkpatch warnings
> add Reviewed-by:
> v3: add a reset_control_put()
> add error handling
> v2: move reset control to bus code
> find all reset properties and de-assert them
> ---
> drivers/amba/bus.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index 100e798a5c82..f8a7cb74c3cf 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -18,6 +18,7 @@
> #include <linux/limits.h>
> #include <linux/clk/clk-conf.h>
> #include <linux/platform_device.h>
> +#include <linux/reset.h>
>
> #include <asm/irq.h>
>
> @@ -401,6 +402,24 @@ static int amba_device_try_add(struct amba_device *dev, struct resource *parent)
> ret = amba_get_enable_pclk(dev);
> if (ret == 0) {
> u32 pid, cid;
> + int count;
> + struct reset_control *rstc;
> +
> + /*
> + * Find reset control(s) of the amba bus and de-assert them.
> + */
> + count = reset_control_get_count(&dev->dev);
> + while (count > 0) {
> + rstc = of_reset_control_array_get_optional_shared(dev->dev.of_node);
You can drop the loop, the rstc returned by of_reset_control_array_get()
already controls all resets together.
regards
Philipp
_______________________________________________
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] ARM: omap2: move platform-specific asm-offset.h to arch/arm/mach-omap2
From: Tony Lindgren @ 2019-08-26 16:20 UTC (permalink / raw)
To: Masahiro Yamada; +Cc: linux-omap, Russell King, linux-arm-kernel, linux-kernel
In-Reply-To: <20190823025808.11875-1-yamada.masahiro@socionext.com>
* Masahiro Yamada <yamada.masahiro@socionext.com> [190822 19:59]:
> <generated/ti-pm-asm-offsets.h> is only generated and included by
> arch/arm/mach-omap2/, so it does not need to reside in the globally
> visible include/generated/.
>
> I renamed it to arch/arm/mach-omap2/pm-asm-offsets.h since the prefix
> 'ti-' is just redundant in mach-omap2/.
>
> My main motivation of this change is to avoid the race condition for
> the parallel build (-j) when CONFIG_IKHEADERS is enabled.
>
> When it is enabled, all the headers under include/ are archived into
> kernel/kheaders_data.tar.xz and exposed in the sysfs.
>
> In the parallel build, we have no idea in which order files are built.
>
> - If ti-pm-asm-offsets.h is built before kheaders_data.tar.xz,
> the header will be included in the archive. Probably nobody will
> use it, but it is harmless except that it will increase the archive
> size needlessly.
>
> - If kheaders_data.tar.xz is built before ti-pm-asm-offsets.h,
> the header will not be included in the archive. However, in the next
> build, the archive will be re-generated to include the newly-found
> ti-pm-asm-offsets.h. This is not nice from the build system point
> of view.
>
> - If ti-pm-asm-offsets.h and kheaders_data.tar.xz are built at the
> same time, the corrupted header might be included in the archive,
> which does not look nice either.
>
> This commit fixes the race.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> Tested-by: Keerthy <j-keerthy@ti.com>
Applying into omap-for-v5.4/soc thanks. The commit is on top of
v5.3-rc1 so it can be merged into other branches if needed after
it's been sitting in Linux next for few days with no issues.
Regards,
Tony
_______________________________________________
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] ARM: OMAP2+: Delete an unnecessary kfree() call in omap_hsmmc_pdata_init()
From: Tony Lindgren @ 2019-08-26 16:20 UTC (permalink / raw)
To: Markus Elfring
Cc: Paul Walmsley, Balaji T K, Kishore Kadiyala, kernel-janitors,
Russell King, LKML, linux-omap, linux-arm-kernel, Benoit Cousson
In-Reply-To: <69025c8c-8d84-6686-138b-cde59467b802@web.de>
* Markus Elfring <Markus.Elfring@web.de> [190826 06:31]:
> From: Markus Elfring <elfring@users.sourceforge.net>
> Date: Mon, 26 Aug 2019 15:05:31 +0200
>
> A null pointer would be passed to a call of the function "kfree" directly
> after a call of the function "kzalloc" failed at one place.
> Remove this superfluous function call.
>
> This issue was detected by using the Coccinelle software.
Applying into omap-for-v5.4/soc thanks.
Tony
_______________________________________________
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 00/15] Improvements and fixes for mxsfb DRM driver
From: Guido Günther @ 2019-08-26 16:34 UTC (permalink / raw)
To: Stefan Agner
Cc: Marek Vasut, Mark Rutland, Pengutronix Kernel Team, devicetree,
David Airlie, Fabio Estevam, Sascha Hauer, linux-kernel,
dri-devel, Rob Herring, NXP Linux Team, Daniel Vetter,
Robert Chiras, Shawn Guo, linux-arm-kernel
In-Reply-To: <3bd35686e046048d35cd4987567a13cf@agner.ch>
Hi,
On Mon, Aug 26, 2019 at 04:35:10PM +0200, Stefan Agner wrote:
> On 2019-08-26 14:05, Guido Günther wrote:
> > Hi,
> > On Wed, Aug 21, 2019 at 01:15:40PM +0300, Robert Chiras wrote:
> >> This patch-set improves the use of eLCDIF block on iMX 8 SoCs (like 8MQ, 8MM
> >> and 8QXP). Following, are the new features added and fixes from this
> >> patch-set:
> >
> > I've applied this whole series on top of my NWL work and it looks good
> > with a DSI panel. Applying the whole series also fixes an issue where
> > after unblank the output was sometimes shifted about half a screen width
> > to the right (which didn't happen with DCSS). So at least from the parts
> > I could test:
> >
> > Tested-by: Guido Günther <agx@sigxcpu.org>
> >
> > for the whole thing.
>
> Thanks for testing! What SoC did you use? I think it would be good to
> also give this a try on i.MX 7 or i.MX 6ULL before merging.
This was on i.MX8MQ. I don't have hardware to test mxsfb on anything
else over here atm.
Cheers,
-- Guido
>
> --
> Stefan
>
>
> > Cheers,
> > -- Guido
> >>
> >> 1. Add support for drm_bridge
> >> On 8MQ and 8MM, the LCDIF block is not directly connected to a parallel
> >> display connector, where an LCD panel can be attached, but instead it is
> >> connected to DSI controller. Since this DSI stands between the display
> >> controller (eLCDIF) and the physical connector, the DSI can be implemented
> >> as a DRM bridge. So, in order to be able to connect the mxsfb driver to
> >> the DSI driver, the support for a drm_bridge was needed in mxsfb DRM
> >> driver (the actual driver for the eLCDIF block).
> >>
> >> 2. Add support for additional pixel formats
> >> Some of the pixel formats needed by Android were not implemented in this
> >> driver, but they were actually supported. So, add support for them.
> >>
> >> 3. Add support for horizontal stride
> >> Having support for horizontal stride allows the use of eLCDIF with a GPU
> >> (for example) that can only output resolution sizes multiple of a power of
> >> 8. For example, 1080 is not a power of 16, so in order to support 1920x1080
> >> output from GPUs that can produce linear buffers only in sizes multiple to 16,
> >> this feature is needed.
> >>
> >> 3. Few minor features and bug-fixing
> >> The addition of max-res DT property was actually needed in order to limit
> >> the bandwidth usage of the eLCDIF block. This is need on systems where
> >> multiple display controllers are presend and the memory bandwidth is not
> >> enough to handle all of them at maximum capacity (like it is the case on
> >> 8MQ, where there are two display controllers: DCSS and eLCDIF).
> >> The rest of the patches are bug-fixes.
> >>
> >> v3:
> >> - Removed the max-res property patches and added support for
> >> max-memory-bandwidth property, as it is also implemented in other drivers
> >> - Removed unnecessary drm_vblank_off in probe
> >>
> >> v2:
> >> - Collected Tested-by from Guido
> >> - Split the first patch, which added more than one feature into relevant
> >> patches, explaining each feature added
> >> - Also split the second patch into more patches, to differentiate between
> >> the feature itself (additional pixel formats support) and the cleanup
> >> of the register definitions for a better representation (guido)
> >> - Included a patch submitted by Guido, while he was testing my patch-set
> >>
> >> Guido Günther (1):
> >> drm/mxsfb: Read bus flags from bridge if present
> >>
> >> Mirela Rabulea (1):
> >> drm/mxsfb: Signal mode changed when bpp changed
> >>
> >> Robert Chiras (13):
> >> drm/mxsfb: Update mxsfb to support a bridge
> >> drm/mxsfb: Add defines for the rest of registers
> >> drm/mxsfb: Reset vital registers for a proper initialization
> >> drm/mxsfb: Update register definitions using bit manipulation defines
> >> drm/mxsfb: Update mxsfb with additional pixel formats
> >> drm/mxsfb: Fix the vblank events
> >> drm/mxsfb: Add max-memory-bandwidth property for MXSFB
> >> dt-bindings: display: Add max-memory-bandwidth property for mxsfb
> >> drm/mxsfb: Update mxsfb to support LCD reset
> >> drm/mxsfb: Improve the axi clock usage
> >> drm/mxsfb: Clear OUTSTANDING_REQS bits
> >> drm/mxsfb: Add support for horizontal stride
> >> drm/mxsfb: Add support for live pixel format change
> >>
> >> .../devicetree/bindings/display/mxsfb.txt | 5 +
> >> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 287 ++++++++++++++++++---
> >> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 203 +++++++++++++--
> >> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 12 +-
> >> drivers/gpu/drm/mxsfb/mxsfb_out.c | 26 +-
> >> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 193 +++++++++-----
> >> 6 files changed, 589 insertions(+), 137 deletions(-)
> >>
> >> --
> >> 2.7.4
> >>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] kvm/arm/vgic: fix potential deadlock when ap_list is long
From: Heyi Guo @ 2019-08-26 16:39 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm, linux-kernel
Cc: Suzuki K Poulose, Marc Zyngier, Zenghui Yu, James Morse, Heyi Guo,
wanghaibin.wang, Julien Thierry
If ap_list is longer than 256, merge_final() in sort_list() will call
comparison function with the same element just as below:
do {
/*
* If the merge is highly unbalanced (e.g. the input is
* already sorted), this loop may run many iterations.
* Continue callbacks to the client even though no
* element comparison is needed, so the client's cmp()
* routine can invoke cond_resched() periodically.
*/
if (unlikely(!++count))
cmp(priv, b, b);
This will definitely cause deadlock in vgic_irq_cmp() and the call trace
is:
[ 2667.130283] Call trace:
[ 2667.130284] queued_spin_lock_slowpath+0x64/0x2a8
[ 2667.130284] vgic_irq_cmp+0xfc/0x130
[ 2667.130284] list_sort.part.0+0x1c0/0x268
[ 2667.130285] list_sort+0x18/0x28
[ 2667.130285] vgic_flush_lr_state+0x158/0x518
[ 2667.130285] kvm_vgic_flush_hwstate+0x70/0x108
[ 2667.130286] kvm_arch_vcpu_ioctl_run+0x114/0xa50
[ 2667.130286] kvm_vcpu_ioctl+0x490/0x8c8
[ 2667.130286] do_vfs_ioctl+0xc4/0x8c0
[ 2667.130287] ksys_ioctl+0x8c/0xa0
[ 2667.130287] __arm64_sys_ioctl+0x28/0x38
[ 2667.130287] el0_svc_common+0x78/0x130
[ 2667.130288] el0_svc_handler+0x38/0x78
[ 2667.130288] el0_svc+0x8/0xc
So return 0 immediately when a==b.
Signed-off-by: Zenghui Yu <yuzenghui@huawei.com>
Signed-off-by: Heyi Guo <guoheyi@huawei.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Julien Thierry <julien.thierry.kdev@gmail.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
---
virt/kvm/arm/vgic/vgic.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/virt/kvm/arm/vgic/vgic.c b/virt/kvm/arm/vgic/vgic.c
index 13d4b38..64ed0dc 100644
--- a/virt/kvm/arm/vgic/vgic.c
+++ b/virt/kvm/arm/vgic/vgic.c
@@ -254,6 +254,13 @@ static int vgic_irq_cmp(void *priv, struct list_head *a, struct list_head *b)
bool penda, pendb;
int ret;
+ /*
+ * list_sort may call this function with the same element when the list
+ * is farely long.
+ */
+ if (unlikely(a == b))
+ return 0;
+
raw_spin_lock(&irqa->irq_lock);
raw_spin_lock_nested(&irqb->irq_lock, SINGLE_DEPTH_NESTING);
--
1.8.3.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 v4 00/13] Support CPU frequency scaling on QCS404
From: Jorge Ramirez @ 2019-08-26 16:49 UTC (permalink / raw)
To: bjorn.andersson, sboyd, david.brown, jassisinghbrar, mark.rutland,
mturquette, robh+dt, will.deacon, arnd, horms+renesas, heiko,
sibis, enric.balletbo, jagan, olof
Cc: devicetree, linux-arm-msm, khasim.mohammed, linux-kernel,
amit.kucheria, linux-clk, vkoul, niklas.cassel, georgi.djakov,
linux-arm-kernel
In-Reply-To: <f34a75d0-c479-267d-b4a1-c2418d4efb22@linaro.org>
On 8/26/19 08:54, Jorge Ramirez wrote:
> On 7/31/19 22:29, Jorge Ramirez-Ortiz wrote:
>> The following patchset enables CPU frequency scaling support on the
>> QCS404 (with dynamic voltage scaling).
>>
>> It is important to notice that this functionality will be superseded
>> by Core Power Reduction (CPR), a more accurate form of AVS found on
>> certain Qualcomm SoCs.
>>
>> Some of the changes required to support CPR do conflict with the
>> configuration required for CPUFreq.
>>
>> In particular, the following commit for CPR - already merged - will
>> need to be reverted in order to enable CPUFreq.
>>
>> Author: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@linaro.org>
>> Date: Thu Jul 25 12:41:36 2019 +0200
>> cpufreq: Add qcs404 to cpufreq-dt-platdev blacklist
>>
>> Patch 8 "clk: qcom: hfpll: CLK_IGNORE_UNUSED" is a bit controversial;
>> in this platform, this PLL provides the clock signal to a CPU
>> core. But in others it might not.
>>
>> We opted for the minimal ammount of changes without affecting the
>> default functionality: simply bypassing the COMMON_CLK_DISABLE_UNUSED
>> framework and letting the firwmare chose whether to enable or disable
>> the clock at boot. However maybe a DT property and marking the clock
>> as critical would be more appropriate for this PLL. we'd appreciate the
>> maintainer's input on this topic.
>>
>> v2:
>> - dts: ms8916: apcs mux/divider: new bindings
>> (the driver can still support the old bindings)
>>
>> - qcs404.dtsi
>> fix apcs-hfpll definition
>> fix cpu_opp_table definition
>>
>> - GPLL0_AO_OUT operating frequency
>> define new alpha_pll_fixed_ops to limit the operating frequency
>>
>> v3:
>> - qcom-apcs-ipc-mailbox
>> replace goto to ease readability
>>
>> - apcs-msm8916.c
>> rework patch to use of_clk_parent_fill
>>
>> - hfpll.c
>> add relevant comments to the code
>>
>> - qcs404.dtsi
>> add voltage scaling support
>>
>> v4:
>> - squash OPP definition and DVFS enablement in dts
>> (patches 10 and 13 in previous version)
>>
>> - qcom-apcs-ipc-mailbox
>> replace return condition for readability
>>
>> - answer one question on CLK_IGNORE_UNUSED in mailing list
>>
>> Jorge Ramirez-Ortiz, Niklas Cassel (13):
>> clk: qcom: gcc: limit GPLL0_AO_OUT operating frequency
>> mbox: qcom: add APCS child device for QCS404
>> mbox: qcom: replace integer with valid macro
>> dt-bindings: mailbox: qcom: Add clock-name optional property
>> clk: qcom: apcs-msm8916: get parent clock names from DT
>> clk: qcom: hfpll: get parent clock names from DT
>> clk: qcom: hfpll: register as clock provider
>> clk: qcom: hfpll: CLK_IGNORE_UNUSED
>> arm64: dts: qcom: msm8916: Add the clocks for the APCS mux/divider
>> arm64: dts: qcom: qcs404: Add HFPLL node
>> arm64: dts: qcom: qcs404: Add the clocks for APCS mux/divider
>> arm64: dts: qcom: qcs404: Add DVFS support
>> arm64: defconfig: Enable HFPLL
>>
>> .../mailbox/qcom,apcs-kpss-global.txt | 24 +++++++++--
>> arch/arm64/boot/dts/qcom/msm8916.dtsi | 3 +-
>> arch/arm64/boot/dts/qcom/qcs404.dtsi | 43 +++++++++++++++++++
>> arch/arm64/configs/defconfig | 1 +
>> drivers/clk/qcom/apcs-msm8916.c | 23 ++++++++--
>> drivers/clk/qcom/clk-alpha-pll.c | 8 ++++
>> drivers/clk/qcom/clk-alpha-pll.h | 1 +
>> drivers/clk/qcom/gcc-qcs404.c | 2 +-
>> drivers/clk/qcom/hfpll.c | 25 ++++++++++-
>> drivers/mailbox/qcom-apcs-ipc-mailbox.c | 11 +++--
>> 10 files changed, 128 insertions(+), 13 deletions(-)
>>
>
> any feedback on this set?
>
> TIA
>
trying to ease the maintainers task, I have resent the series split in
three individual sets:
- device tree
- clk
- mbox
for full functionality obviously all of them are required
please let me know if there is anything else I can do.
_______________________________________________
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/16] arm64: prefer __section from compiler_attributes.h
From: Nick Desaulniers @ 2019-08-26 17:03 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Song Liu, Catalin Marinas, Alexei Starovoitov, Will Deacon,
Daniel Borkmann, clang-built-linux, Allison Randal, Yonghong Song,
Masayoshi Mizuma, Suzuki K Poulose, Andrey Konovalov,
Shaokun Zhang, Alexios Zavras, Josh Poimboeuf, Sedat Dilek,
Thomas Gleixner, bpf, Linux ARM, Greg Kroah-Hartman, linux-kernel,
Network Development, Andrew Morton, Enrico Weigelt,
Martin KaFai Lau
In-Reply-To: <CANiq72mcSniCzMzW6AX_5tG5W2edjEmZ=Rf=jo-Mw3H-9RVJqw@mail.gmail.com>
On Sat, Aug 24, 2019 at 5:48 AM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Sat, Aug 24, 2019 at 1:25 PM Will Deacon <will@kernel.org> wrote:
> >
> > Which bit are you pinging about? This patch (12/16) has been in -next for a
> > while and is queued in the arm64 tree for 5.4. The Oops/boot issue is
> > addressed in patch 14 which probably needs to be sent as a separate patch
> > (with a commit message) if it's targetting 5.3 and, I assume, routed via
> > somebody like akpm.
>
> I was pinging about the bit I was quoting, i.e. whether the Oops in
> the cover letter was #14 indeed. Also, since Nick said he wanted to
> get this ASAP through compiler-attributes, I assumed he wanted it to
> be in 5.3, but I have not seen the independent patch.
>
> Since he seems busy, I will write a better commit message myself and
> send it to Linus next week.
Sorry, very hectic week here last week. I'll try to get the import
bit split off, collect the acks/reviewed-by tags, and resend a v2 of
the series this week.
--
Thanks,
~Nick Desaulniers
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: CPUfreq fail on rk3399-firefly
From: Kevin Hilman @ 2019-08-26 17:09 UTC (permalink / raw)
To: Kever Yang, Heiko Stuebner
Cc: kernel-build-reports, linux-rockchip, linux-next,
闫孝军, 张晴, linux-arm-kernel
In-Reply-To: <db7af16f-d8cc-fbcb-726d-2aeba5563076@rock-chips.com>
Hi Kever,
Kever Yang <kever.yang@rock-chips.com> writes:
> Hi Kevin,
>
> I want to have a test with my board, I can get the Image and dtb
> from the link for the job,
>
> but how can I get the randisk which is named initrd-SDbyy2.cpio.gz?
The ramdisk images are here:
https://storage.kernelci.org/images/rootfs/buildroot/kci-2019.02/arm64/base/
in the kernelCI logs the ramdisk is slightly modified because the kernel
modules have been inserted into the cpio archive.
However, for the purposes of this test, you can just test with the
unmodified rootfs.cpio.gz above.
Kevin
> Thanks,
>
> - Kever
>
> On 2019/8/24 上午1:03, Kevin Hilman wrote:
>> Kevin Hilman <khilman@baylibre.com> writes:
>>
>>> Kever Yang <kever.yang@rock-chips.com> writes:
>>>
>>>> Hi Kevin, Heiko,
>>>>
>>>> On 2019/8/22 上午2:59, Kevin Hilman wrote:
>>>>> Hi Heiko,
>>>>>
>>>>> Heiko Stuebner <heiko@sntech.de> writes:
>>>>>
>>>>>> Am Dienstag, 13. August 2019, 19:35:31 CEST schrieb Kevin Hilman:
>>>>>>> [ resent with correct addr for linux-rockchip list ]
>>>>>>>
>>>>>>> Mark Brown <broonie@kernel.org> writes:
>>>>>>>
>>>>>>>> On Thu, Jul 18, 2019 at 04:28:08AM -0700, kernelci.org bot wrote:
>>>>>>>>
>>>>>>>> Today's -next started failing to boot defconfig on rk3399-firefly:
>>>>>>>>
>>>>>>>>> arm64:
>>>>>>>>> defconfig:
>>>>>>>>> gcc-8:
>>>>>>>>> rk3399-firefly: 1 failed lab
>>>>>>>> It hits a BUG() trying to set up cpufreq:
>>>>>>>>
>>>>>>>> [ 87.381606] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 200000 KHz
>>>>>>>> [ 87.393244] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 408000 KHz
>>>>>>>> [ 87.469777] cpufreq: cpufreq_online: CPU4: Running at unlisted freq: 12000 KHz
>>>>>>>> [ 87.488595] cpu cpu4: _generic_set_opp_clk_only: failed to set clock rate: -22
>>>>>>>> [ 87.491881] cpufreq: __target_index: Failed to change cpu frequency: -22
>>>>>>>> [ 87.495335] ------------[ cut here ]------------
>>>>>>>> [ 87.496821] kernel BUG at drivers/cpufreq/cpufreq.c:1438!
>>>>>>>> [ 87.498462] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
>>>>>>>>
>>>>>>>> I'm struggling to see anything relevant in the diff from yesterday, the
>>>>>>>> unlisted frequency warnings were there in the logs yesterday but no oops
>>>>>>>> and I'm not seeing any changes in cpufreq, clk or anything relevant
>>>>>>>> looking.
>>>>>>>>
>>>>>>>> Full bootlog and other info can be found here:
>>>>>>>>
>>>>>>>> https://kernelci.org/boot/id/5d302d8359b51498d049e983/
>>>>>>> I confirm that disabling CPUfreq in the defconfig (CONFIG_CPU_FREQ=n)
>>>>>>> makes the firefly board start working again.
>>>>>>>
>>>>>>> Note that the default defconfig enables the "performance" CPUfreq
>>>>>>> governor as the default governor, so during kernel boot, it will always
>>>>>>> switch to the max frequency.
>>>>>>>
>>>>>>> For fun, I set the default governor to "userspace" so the kernel
>>>>>>> wouldn't make any OPP changes, and that leads to a slightly more
>>>>>>> informative splat[1]
>>>>>>>
>>>>>>> There is still an OPP change happening because the detected OPP is not
>>>>>>> one that's listed in the table, so it tries to change to a listed OPP
>>>>>>> and fails in the bowels of clk_set_rate()
>>>>>> Though I think that might only be a symptom as well.
>>>>>> Both the PLL setting code as well as the actual cpu-clock implementation
>>>>>> is unchanged since 2017 (and runs just fine on all boards in my farm).
>>>>>>
>>>>>> One source for these issues is often the regulator supplying the cpu
>>>>>> going haywire - aka the voltage not matching the opp.
>>>>>>
>>>>>> As in this error-case it's CPU4 being set, this would mean it might
>>>>>> be the big cluster supplied by the external syr825 (fan5355 clone)
>>>>>> that might act up. In the Firefly-rk3399 case this is even stranger.
>>>>>>
>>>>>> There is a discrepancy between the "fcs,suspend-voltage-selector"
>>>>>> between different bootloader versions (how the selection-pin is set up),
>>>>>> so the kernel might actually write his requested voltage to the wrong
>>>>>> register (not the one for actual voltage, but the second set used for
>>>>>> the suspend voltage).
>>>>>>
>>>>>> Did you by chance swap bootloaders at some point in recent past?
>>>>> No, haven't touched bootloader since I initially setup the board.
>>>> The CPU voltage does not affect by bootloader for kernel should have its
>>>> own opp-table,
>>>>
>>>> the bootloader may only affect the center/logic power supply.
>>>>
>>>>>> I'd assume [2] might actually be the same issue last year, though
>>>>>> the CI-logs are not available anymore it seems.
>>>>>>
>>>>>> Could you try to set the vdd_cpu_b regulator to disabled, so that
>>>>>> cpufreq for this cluster defers and see what happens?
>>>>> Yes, this change[1] definitely makes things boot reliably again, so
>>>>> there's defintiely something a bit unstable with this regulator, at
>>>>> least on this firefly.
>>>> Is it possible to target which patch introduce this bug? This board
>>>> should have work correctly for a long time with upstream source code.
>>> Unfortunately, it seems to be a regular, but intermittent failure, so
>>> bisection is not producing anything reliable.
>>>
>>> You can see that both in mainline[1] and in linux-next[2] there are
>>> periodic failures, but it's hard to see any patterns.
>> Even worse, I (re)tested mainline for versions that were previously
>> passing (v5.2, v5.3-rc5) and they are also failing now.
>>
>> They work again if I disable that regulator as suggested by Heiko.
>>
>> So this is increasingly pointing to failing hardware.
>>
>> Kevin
>>
>>
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Changing default kernel load address
From: Noam Camus @ 2019-08-26 17:12 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I wish to change an arm64 machine kernel load address and I hope this
forum can assist.
In my current setup the KERNEL_START macro (_text) equals 128.5MB:
KIMAGE_VADDR=128MB
TEXT_OFFSET=512KB
I wish to change kernel load address to reside on my internal RAM
which locates beyond 4GB.
Since CONFIG_RANDOMIZE_BASE uses only 16 bit I find it not helpful.
Can someone tell what changes I need to do so kernel load address will
be above 4GB.
Note: I use FIT image to provide U-Boot the kernel Load address.
Regards,
Noam
_______________________________________________
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/2] coresight: Add barrier packet when moving offset forward
From: Yabin Cui @ 2019-08-26 17:24 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, leo.yan
Cc: alexander.shishkin, Yabin Cui, linux-arm-kernel, mike.leach,
linux-kernel
In-Reply-To: <20190822220915.8876-3-mathieu.poirier@linaro.org>
Tested-by: Yabin Cui <yabinc@google.com>
_______________________________________________
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] ARM: dts: vf610-zii-dev-rev-b: Drop redundant I2C properties
From: Andrey Smirnov @ 2019-08-26 18:03 UTC (permalink / raw)
To: Shawn Guo; +Cc: Fabio Estevam, Chris Healy, linux-arm-kernel, linux-kernel
In-Reply-To: <20190824191148.GD16308@X250.getinternet.no>
On Sat, Aug 24, 2019 at 12:12 PM Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Mon, Aug 19, 2019 at 08:19:52PM -0700, Andrey Smirnov wrote:
> > Drop redundant I2C properties that are already specified in
> > vf610-zii-dev.dtsi
> >
> > Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> > Cc: Shawn Guo <shawnguo@kernel.org>
> > Cc: Chris Healy <cphealy@gmail.com>
> > Cc: Fabio Estevam <festevam@gmail.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: linux-kernel@vger.kernel.org
> > ---
> > arch/arm/boot/dts/vf610-zii-dev-rev-b.dts | 10 ----------
> > 1 file changed, 10 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> > index 48086c5e8549..e500911ce0a5 100644
> > --- a/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> > +++ b/arch/arm/boot/dts/vf610-zii-dev-rev-b.dts
> > @@ -323,11 +323,6 @@
> > };
> >
> > &i2c0 {
> > - clock-frequency = <100000>;
> > - pinctrl-names = "default";
> > - pinctrl-0 = <&pinctrl_i2c0>;
>
> pinctrl for i2c0 is not same as what vf610-zii-dev.dtsi has.
The only difference I can see is in pinctrl-names so I am assuming
that's what you mean. Not configuring I2C recovery on Rev B board was
not intentional. I'll update commit log in v2.
Thanks,
Andrey Smirnov
_______________________________________________
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] ARM: dts: vf610-zii-scu4-aib: Drop "rs485-rts-delay" property
From: Andrey Smirnov @ 2019-08-26 18:05 UTC (permalink / raw)
To: Shawn Guo; +Cc: Fabio Estevam, Chris Healy, linux-arm-kernel, linux-kernel
In-Reply-To: <20190824190903.GC16308@X250.getinternet.no>
On Sat, Aug 24, 2019 at 12:09 PM Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Mon, Aug 19, 2019 at 08:13:01PM -0700, Andrey Smirnov wrote:
> > LPUART driver does not support specifying "rs485-rts-delay"
> > property. Drop it.
>
> If so, we need to fix bindings/serial/fsl-lpuart.txt in the meantime?
>
Yeah, good point. Will submit a separate patch for that.
Thanks,
Andrey Smirnov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 0/3] ASoC: sun4i-i2s: Updates to the driver
From: codekipper @ 2019-08-26 18:07 UTC (permalink / raw)
To: mripard, wens, linux-sunxi
Cc: alsa-devel, Marcus Cooper, lgirdwood, linux-kernel, be17068,
broonie, linux-arm-kernel
From: Marcus Cooper <codekipper@gmail.com>
Hi All,
here is a patch series to add some improvements to the sun4i-i2s driver
which is enough to get HDMI audio working on the A83T, A64, H3 and
H5 platforms.
I've dropped a lot of the functionality that was presented earlier in favour
of getting initial HDMI audio delivered. H6 and multi-channel HDMI will
follow shortly.
My test branch for this can be found at
https://github.com/codekipper/linux-sunxi/commits/upstream-i2s , I've been
using a Pine64 to test with; validating the new SoC block with HDMI audio
and ensuring that I've not broken the old block by making sure that the audio
codec still works.
BR,
CK
---
v6 changes compared to v5 are:
- removed patches for multi-channel and H6 HDMI audio.
- removed patch for 20, 24 and 32 bit (will push support for just 20 and 24bit)
- ditched tdm patches as support has already been added.
- added fix for A83T reg map.
v5 changes compared to v4 are:
- removed delivered patches.
- Added more details to commit messages.
- replaced some reg fields with function calls.
- Added DSP_A and DSP_B support for H3 and later SoCs.
- Added support for the Allwinner H6.
v4 changes compared to v3 are:
- Moved patches around so that the more controversial of patches are
at the top of the stack.
- Added more details to commit messages.
- Fixed 20bit audio PCM format to use 4 bytes.
- Reduced number of flags used to indicate a new SoC.
v3 changes compared to v2 are:
- added back slave mode changes
- added back the use of tdm properties
- changes to regmap and caching
- removed loopback functionality
- fixes to the channel offset mask
v2 changes compared to v1 are:
- removed slave mode changes which didn't set mclk and bclk div.
- removed use of tdm and now use a dedicated property.
- fix commit message to better explain reason for sign extending
- add divider calculations for newer SoCs.
- add support for multi-lane i2s data output.
- add support for 20, 24 and 32 bit samples.
- add loopback property so blocks can be tested without a codec.
---
Marcus Cooper (3):
ASoC: sun4i-i2s: incorrect regmap for A83T
ASoC: sun4i-i2s: Add regmap field to sign extend sample
ASoC: sun4i-i2s: Adjust LRCLK width
sound/soc/sunxi/sun4i-i2s.c | 24 ++++++++++++++++++++++--
1 file changed, 22 insertions(+), 2 deletions(-)
--
2.23.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 1/3] ASoC: sun4i-i2s: incorrect regmap for A83T
From: codekipper @ 2019-08-26 18:07 UTC (permalink / raw)
To: mripard, wens, linux-sunxi
Cc: alsa-devel, Marcus Cooper, lgirdwood, linux-kernel, be17068,
broonie, linux-arm-kernel
In-Reply-To: <20190826180734.15801-1-codekipper@gmail.com>
From: Marcus Cooper <codekipper@gmail.com>
The regmap configuration is set up for the legacy block on the
A83T whereas it uses the new block with a larger register map.
Fixes: 21faaea1343f ("ASoC: sun4i-i2s: Add support for A83T")
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
sound/soc/sunxi/sun4i-i2s.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 57bf2a33753e..34575a8aa9f6 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -1100,7 +1100,7 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.has_reset = true,
.reg_offset_txdata = SUN8I_I2S_FIFO_TX_REG,
- .sun4i_i2s_regmap = &sun4i_i2s_regmap_config,
+ .sun4i_i2s_regmap = &sun8i_i2s_regmap_config,
.field_clkdiv_mclk_en = REG_FIELD(SUN4I_I2S_CLK_DIV_REG, 8, 8),
.field_fmt_wss = REG_FIELD(SUN4I_I2S_FMT0_REG, 0, 2),
.field_fmt_sr = REG_FIELD(SUN4I_I2S_FMT0_REG, 4, 6),
--
2.23.0
_______________________________________________
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 v6 2/3] ASoC: sun4i-i2s: Add regmap field to sign extend sample
From: codekipper @ 2019-08-26 18:07 UTC (permalink / raw)
To: mripard, wens, linux-sunxi
Cc: alsa-devel, Marcus Cooper, lgirdwood, linux-kernel, be17068,
broonie, linux-arm-kernel
In-Reply-To: <20190826180734.15801-1-codekipper@gmail.com>
From: Marcus Cooper <codekipper@gmail.com>
On the newer SoCs such as the H3 and A64 this is set by default
to transfer a 0 after each sample in each slot. However the A10
and A20 SoCs that this driver was developed on had a default
setting where it padded the audio gain with zeros.
This isn't a problem whilst we have only support for 16bit audio
but with larger sample resolution rates in the pipeline then SEXT
bits should be cleared so that they also pad at the LSB. Without
this the audio gets distorted.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
sound/soc/sunxi/sun4i-i2s.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 34575a8aa9f6..056a299c03fb 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -135,6 +135,7 @@ struct sun4i_i2s;
* @field_clkdiv_mclk_en: regmap field to enable mclk output.
* @field_fmt_wss: regmap field to set word select size.
* @field_fmt_sr: regmap field to set sample resolution.
+ * @field_fmt_sext: regmap field to set the sign extension.
*/
struct sun4i_i2s_quirks {
bool has_reset;
@@ -145,6 +146,7 @@ struct sun4i_i2s_quirks {
struct reg_field field_clkdiv_mclk_en;
struct reg_field field_fmt_wss;
struct reg_field field_fmt_sr;
+ struct reg_field field_fmt_sext;
const struct sun4i_i2s_clk_div *bclk_dividers;
unsigned int num_bclk_dividers;
@@ -177,6 +179,7 @@ struct sun4i_i2s {
struct regmap_field *field_clkdiv_mclk_en;
struct regmap_field *field_fmt_wss;
struct regmap_field *field_fmt_sr;
+ struct regmap_field *field_fmt_sext;
const struct sun4i_i2s_quirks *variant;
};
@@ -354,6 +357,10 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_dai *dai,
regmap_field_write(i2s->field_clkdiv_mclk_en, 1);
+
+ /* Set sign extension to pad out LSB with 0 */
+ regmap_field_write(i2s->field_fmt_sext, 0);
+
return 0;
}
@@ -1073,6 +1080,7 @@ static const struct sun4i_i2s_quirks sun4i_a10_i2s_quirks = {
.mclk_dividers = sun4i_i2s_mclk_div,
.num_mclk_dividers = ARRAY_SIZE(sun4i_i2s_mclk_div),
.get_bclk_parent_rate = sun4i_i2s_get_bclk_parent_rate,
+ .field_fmt_sext = REG_FIELD(SUN4I_I2S_FMT1_REG, 8, 8),
.get_sr = sun4i_i2s_get_sr,
.get_wss = sun4i_i2s_get_wss,
.set_chan_cfg = sun4i_i2s_set_chan_cfg,
@@ -1091,6 +1099,7 @@ static const struct sun4i_i2s_quirks sun6i_a31_i2s_quirks = {
.mclk_dividers = sun4i_i2s_mclk_div,
.num_mclk_dividers = ARRAY_SIZE(sun4i_i2s_mclk_div),
.get_bclk_parent_rate = sun4i_i2s_get_bclk_parent_rate,
+ .field_fmt_sext = REG_FIELD(SUN4I_I2S_FMT1_REG, 8, 8),
.get_sr = sun4i_i2s_get_sr,
.get_wss = sun4i_i2s_get_wss,
.set_chan_cfg = sun4i_i2s_set_chan_cfg,
@@ -1109,6 +1118,7 @@ static const struct sun4i_i2s_quirks sun8i_a83t_i2s_quirks = {
.mclk_dividers = sun8i_i2s_clk_div,
.num_mclk_dividers = ARRAY_SIZE(sun8i_i2s_clk_div),
.get_bclk_parent_rate = sun8i_i2s_get_bclk_parent_rate,
+ .field_fmt_sext = REG_FIELD(SUN4I_I2S_FMT1_REG, 4, 5),
.get_sr = sun8i_i2s_get_sr_wss,
.get_wss = sun8i_i2s_get_sr_wss,
.set_chan_cfg = sun8i_i2s_set_chan_cfg,
@@ -1127,6 +1137,7 @@ static const struct sun4i_i2s_quirks sun50i_a64_codec_i2s_quirks = {
.mclk_dividers = sun4i_i2s_mclk_div,
.num_mclk_dividers = ARRAY_SIZE(sun4i_i2s_mclk_div),
.get_bclk_parent_rate = sun4i_i2s_get_bclk_parent_rate,
+ .field_fmt_sext = REG_FIELD(SUN4I_I2S_FMT1_REG, 8, 8),
.get_sr = sun4i_i2s_get_sr,
.get_wss = sun4i_i2s_get_wss,
.set_chan_cfg = sun4i_i2s_set_chan_cfg,
@@ -1154,6 +1165,12 @@ static int sun4i_i2s_init_regmap_fields(struct device *dev,
if (IS_ERR(i2s->field_fmt_sr))
return PTR_ERR(i2s->field_fmt_sr);
+ i2s->field_fmt_sext =
+ devm_regmap_field_alloc(dev, i2s->regmap,
+ i2s->variant->field_fmt_sext);
+ if (IS_ERR(i2s->field_fmt_sext))
+ return PTR_ERR(i2s->field_fmt_sext);
+
return 0;
}
--
2.23.0
_______________________________________________
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 v6 3/3] ASoC: sun4i-i2s: Adjust LRCLK width
From: codekipper @ 2019-08-26 18:07 UTC (permalink / raw)
To: mripard, wens, linux-sunxi
Cc: alsa-devel, Marcus Cooper, lgirdwood, linux-kernel, be17068,
broonie, linux-arm-kernel
In-Reply-To: <20190826180734.15801-1-codekipper@gmail.com>
From: Marcus Cooper <codekipper@gmail.com>
Some codecs such as i2s based HDMI audio and the Pine64 DAC require
a different amount of bit clocks per frame than what is calculated
by the sample width. Use the values obtained by the tdm slot bindings
to adjust the LRCLK width accordingly.
Signed-off-by: Marcus Cooper <codekipper@gmail.com>
---
sound/soc/sunxi/sun4i-i2s.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c
index 056a299c03fb..0965a97c96e5 100644
--- a/sound/soc/sunxi/sun4i-i2s.c
+++ b/sound/soc/sunxi/sun4i-i2s.c
@@ -455,7 +455,10 @@ static int sun8i_i2s_set_chan_cfg(const struct sun4i_i2s *i2s,
break;
case SND_SOC_DAIFMT_I2S:
- lrck_period = params_physical_width(params);
+ if (i2s->slot_width)
+ lrck_period = i2s->slot_width;
+ else
+ lrck_period = params_physical_width(params);
break;
default:
--
2.23.0
_______________________________________________
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] ARM: imx: Drop imx_anatop_init()
From: Andrey Smirnov @ 2019-08-26 18:08 UTC (permalink / raw)
To: Shawn Guo
Cc: Aisheng Dong, Peter Chen, linux-kernel@vger.kernel.org,
dl-linux-imx, Leonard Crestez, Fabio Estevam, Chris Healy,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190824183108.GA14936@X250>
On Sat, Aug 24, 2019 at 11:31 AM Shawn Guo <shawnguo@kernel.org> wrote:
>
> On Thu, Aug 22, 2019 at 05:33:13PM +0000, Leonard Crestez wrote:
> > On 31.07.2019 21:01, Andrey Smirnov wrote:
> > > With commit b5bbe2235361 ("usb: phy: mxs: Disable external charger
> > > detect in mxs_phy_hw_init()") in tree all of the necessary charger
> > > setup is done by the USB PHY driver which covers all of the affected
> > > i.MX6 SoCs.
> > >
> > > NOTE: Imx_anatop_init() was also called for i.MX7D, but looking at its
> > > datasheet it appears to have a different USB PHY IP block, so
> > > executing i.MX6 charger disable configuration seems unnecessary.
> > >
> > > -void __init imx_anatop_init(void)
> > > -{
> > > - anatop = syscon_regmap_lookup_by_compatible("fsl,imx6q-anatop");
> > > - if (IS_ERR(anatop)) {
> > > - pr_err("%s: failed to find imx6q-anatop regmap!\n", __func__);
> > > - return;
> > > - }
> >
> > This patch breaks suspend on imx6 in linux-next because the "anatop"
> > regmap is no longer initialized. This was found via bisect but
> > no_console_suspend prints a helpful stack anyway:
> >
> > (regmap_read) from [<c01226e4>] (imx_anatop_enable_weak2p5+0x28/0x70)
> > (imx_anatop_enable_weak2p5) from [<c0122744>]
> > (imx_anatop_pre_suspend+0x18/0x64)
> > (imx_anatop_pre_suspend) from [<c0124434>] (imx6q_pm_enter+0x60/0x16c)
> > (imx6q_pm_enter) from [<c018c8a4>] (suspend_devices_and_enter+0x7d4/0xcbc)
> > (suspend_devices_and_enter) from [<c018d544>] (pm_suspend+0x7b8/0x904)
> > (pm_suspend) from [<c018b1b4>] (state_store+0x68/0xc8)
>
> I dropped it from my branch for now. Thanks for reporting!
>
OK, it sounds like I can submit a v2 that only removes
imx_anatop_usb_chrg_detect_disable() and keeps imx_anatop_init()
intact.
Thanks,
Andrey Smirnov
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* qcom: build issue in Linux 5.3-rc6 with CONFIG_XEN=y
From: Stefan Wahren @ 2019-08-26 18:08 UTC (permalink / raw)
To: Bjorn Andersson, Avaneesh Kumar Dwivedi, Andy Gross
Cc: linux-arm-msm, linux-arm-kernel
Hi,
i tried to cross compile arm/multi_v7_defconfig with CONFIG_XEN=y with Linux 5.3-rc6 and i'm getting this:
drivers/firmware/qcom_scm.c: In function ‘qcom_scm_assign_mem’:
drivers/firmware/qcom_scm.c:460:47: error: passing argument 3 of ‘dma_alloc_coherent’ from incompatible pointer type [-Werror=incompatible-pointer-types]
ptr = dma_alloc_coherent(__scm->dev, ptr_sz, &ptr_phys, GFP_KERNEL);
^
In file included from drivers/firmware/qcom_scm.c:12:0:
./include/linux/dma-mapping.h:636:21: note: expected ‘dma_addr_t * {aka long long unsigned int *}’ but argument is of type ‘phys_addr_t * {aka unsigned int *}’
static inline void *dma_alloc_coherent(struct device *dev, size_t size,
^~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
scripts/Makefile.build:280: die Regel für Ziel „drivers/firmware/qcom_scm.o“ scheiterte
make[2]: *** [drivers/firmware/qcom_scm.o] Fehler 1
scripts/Makefile.build:497: die Regel für Ziel „drivers/firmware“ scheiterte
Luckily there is already a patch to fix this in linux-next:
firmware: qcom_scm: Use proper types for dma mappings
I hope someone can take care of this.
Regards
Stefan
_______________________________________________
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 5/8] media: cedrus: Detect first slice of a frame
From: Boris Brezillon @ 2019-08-26 18:28 UTC (permalink / raw)
To: Jernej Skrabec
Cc: devel, acourbot, pawel, jonas, gregkh, wens, mripard, tfiga,
paul.kocialkowski, kyungmin.park, linux-media, linux-arm-kernel,
hverkuil-cisco, mchehab, ezequiel, linux-kernel, m.szyprowski
In-Reply-To: <20190822194500.2071-6-jernej.skrabec@siol.net>
Hi Jernej,
On Thu, 22 Aug 2019 21:44:57 +0200
Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> When codec supports multiple slices in one frame, VPU has to know when
> first slice of each frame is being processed, presumably to correctly
> clear/set data in auxiliary buffers.
>
> Add first_slice field to cedrus_run structure and set it according to
> timestamps of capture and output buffers. If timestamps are different,
> it's first slice and viceversa.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> ---
> drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h b/drivers/staging/media/sunxi/cedrus/cedrus.h
> index 2f017a651848..32cb38e541c6 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> @@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
> struct cedrus_run {
> struct vb2_v4l2_buffer *src;
> struct vb2_v4l2_buffer *dst;
> + bool first_slice;
>
> union {
> struct cedrus_h264_run h264;
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> index 56ca4c9ad01c..d7b54accfe83 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> @@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
>
> run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> + run.first_slice =
> + run.src->vb2_buf.timestamp != run.dst->vb2_buf.timestamp;
Can't we use slice->first_mb_in_slice to determine if a slice is the
first? I'd expect ->first_mb_in_slice to be 0 (unless we decide to
support ASO).
>
> /* Apply request(s) controls if needed. */
> src_req = run.src->vb2_buf.req_obj.req;
_______________________________________________
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/8] videodev2.h: add V4L2_DEC_CMD_FLUSH
From: Boris Brezillon @ 2019-08-26 18:30 UTC (permalink / raw)
To: Jernej Skrabec
Cc: devel, acourbot, pawel, jonas, gregkh, wens, mripard, tfiga,
paul.kocialkowski, kyungmin.park, linux-media, linux-arm-kernel,
hverkuil-cisco, mchehab, ezequiel, linux-kernel, m.szyprowski
In-Reply-To: <20190822194500.2071-3-jernej.skrabec@siol.net>
On Thu, 22 Aug 2019 21:44:54 +0200
Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> From: Hans Verkuil <hverkuil-cisco@xs4all.nl>
>
> Add this new V4L2_DEC_CMD_FLUSH decoder command and document it.
>
> Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst | 11 ++++++++++-
> Documentation/media/videodev2.h.rst.exceptions | 1 +
> include/uapi/linux/videodev2.h | 1 +
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> index 57f0066f4cff..0bffef6058f7 100644
> --- a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> +++ b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
> @@ -208,7 +208,16 @@ introduced in Linux 3.3. They are, however, mandatory for stateful mem2mem decod
> been started yet, the driver will return an ``EPERM`` error code. When
> the decoder is already running, this command does nothing. No
> flags are defined for this command.
> -
> + * - ``V4L2_DEC_CMD_FLUSH``
> + - 4
> + - Flush any held capture buffers. Only valid for stateless decoders,
> + and only if ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` was set.
> + This command is typically used when the application reached the
> + end of the stream and the last output buffer had the
> + ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag set. This would prevent
> + dequeueing the last capture buffer containing the last decoded frame.
> + So this command can be used to explicitly flush that last decoded
> + frame.
>
> Return Value
> ============
> diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
> index adeb6b7a15cb..a79028e4d929 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -434,6 +434,7 @@ replace define V4L2_DEC_CMD_START decoder-cmds
> replace define V4L2_DEC_CMD_STOP decoder-cmds
> replace define V4L2_DEC_CMD_PAUSE decoder-cmds
> replace define V4L2_DEC_CMD_RESUME decoder-cmds
> +replace define V4L2_DEC_CMD_FLUSH decoder-cmds
>
> replace define V4L2_DEC_CMD_START_MUTE_AUDIO decoder-cmds
> replace define V4L2_DEC_CMD_PAUSE_TO_BLACK decoder-cmds
> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> index 4fa9f543742d..91a79e16089c 100644
> --- a/include/uapi/linux/videodev2.h
> +++ b/include/uapi/linux/videodev2.h
> @@ -1978,6 +1978,7 @@ struct v4l2_encoder_cmd {
> #define V4L2_DEC_CMD_STOP (1)
> #define V4L2_DEC_CMD_PAUSE (2)
> #define V4L2_DEC_CMD_RESUME (3)
> +#define V4L2_DEC_CMD_FLUSH (4)
>
> /* Flags for V4L2_DEC_CMD_START */
> #define V4L2_DEC_CMD_START_MUTE_AUDIO (1 << 0)
_______________________________________________
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 7/8] media: cedrus: Add support for holding capture buffer
From: Boris Brezillon @ 2019-08-26 18:38 UTC (permalink / raw)
To: Jernej Skrabec
Cc: devel, acourbot, pawel, jonas, gregkh, wens, mripard, tfiga,
paul.kocialkowski, kyungmin.park, linux-media, linux-arm-kernel,
hverkuil-cisco, mchehab, ezequiel, linux-kernel, m.szyprowski
In-Reply-To: <20190822194500.2071-8-jernej.skrabec@siol.net>
On Thu, 22 Aug 2019 21:44:59 +0200
Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> When frame contains multiple slices and driver works in slice mode, it's
> more efficient to hold capture buffer in queue until all slices of a
> same frame are decoded.
>
> Add support for that to Cedrus driver by exposing and implementing
> V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 9 +++++++++
> drivers/staging/media/sunxi/cedrus/cedrus_hw.c | 8 +++++---
> drivers/staging/media/sunxi/cedrus/cedrus_video.c | 1 +
> 3 files changed, 15 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> index d7b54accfe83..68462b99750e 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> @@ -31,6 +31,14 @@ void cedrus_device_run(void *priv)
>
> run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> +
> + if (v4l2_m2m_release_capture_buf(run.src, run.dst)) {
> + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_buf_done(run.dst, VB2_BUF_STATE_DONE);
> + run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> + }
> + run.dst->is_held = run.src->flags & V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
> +
> run.first_slice =
> run.src->vb2_buf.timestamp != run.dst->vb2_buf.timestamp;
>
> @@ -46,6 +54,7 @@ void cedrus_device_run(void *priv)
> V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
> run.mpeg2.quantization = cedrus_find_control_data(ctx,
> V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
> + run.dst->is_held = false;
> break;
>
> case V4L2_PIX_FMT_H264_SLICE:
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> index a942cd9bed57..99fedec80224 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
> @@ -122,7 +122,7 @@ static irqreturn_t cedrus_irq(int irq, void *data)
> dev->dec_ops[ctx->current_codec]->irq_clear(ctx);
>
> src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> - dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> + dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
>
> if (!src_buf || !dst_buf) {
> v4l2_err(&dev->v4l2_dev,
> @@ -136,8 +136,10 @@ static irqreturn_t cedrus_irq(int irq, void *data)
> state = VB2_BUF_STATE_DONE;
>
> v4l2_m2m_buf_done(src_buf, state);
> - v4l2_m2m_buf_done(dst_buf, state);
> -
> + if (!dst_buf->is_held) {
> + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_buf_done(dst_buf, state);
> + }
> v4l2_m2m_job_finish(ctx->dev->m2m_dev, ctx->fh.m2m_ctx);
>
> return IRQ_HANDLED;
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> index eeee3efd247b..5153b2bba21e 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> @@ -515,6 +515,7 @@ int cedrus_queue_init(void *priv, struct vb2_queue *src_vq,
> src_vq->type = V4L2_BUF_TYPE_VIDEO_OUTPUT;
> src_vq->io_modes = VB2_MMAP | VB2_DMABUF;
> src_vq->drv_priv = ctx;
> + src_vq->subsystem_flags = VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF;
> src_vq->buf_struct_size = sizeof(struct cedrus_buffer);
> src_vq->min_buffers_needed = 1;
> src_vq->ops = &cedrus_qops;
_______________________________________________
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 5/8] media: cedrus: Detect first slice of a frame
From: Jernej Škrabec @ 2019-08-26 18:47 UTC (permalink / raw)
To: Boris Brezillon
Cc: devel, acourbot, pawel, jonas, gregkh, wens, mripard, tfiga,
paul.kocialkowski, kyungmin.park, linux-media, linux-arm-kernel,
hverkuil-cisco, mchehab, ezequiel, linux-kernel, m.szyprowski
In-Reply-To: <20190826202831.311c7c20@collabora.com>
Dne ponedeljek, 26. avgust 2019 ob 20:28:31 CEST je Boris Brezillon
napisal(a):
> Hi Jernej,
>
> On Thu, 22 Aug 2019 21:44:57 +0200
>
> Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> > When codec supports multiple slices in one frame, VPU has to know when
> > first slice of each frame is being processed, presumably to correctly
> > clear/set data in auxiliary buffers.
> >
> > Add first_slice field to cedrus_run structure and set it according to
> > timestamps of capture and output buffers. If timestamps are different,
> > it's first slice and viceversa.
> >
> > Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
> > ---
> >
> > drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
> > drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
> > 2 files changed, 3 insertions(+)
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > b/drivers/staging/media/sunxi/cedrus/cedrus.h index
> > 2f017a651848..32cb38e541c6 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus.h
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
> > @@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
> >
> > struct cedrus_run {
> >
> > struct vb2_v4l2_buffer *src;
> > struct vb2_v4l2_buffer *dst;
> >
> > + bool first_slice;
> >
> > union {
> >
> > struct cedrus_h264_run h264;
> >
> > diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c index
> > 56ca4c9ad01c..d7b54accfe83 100644
> > --- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > +++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
> > @@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
> >
> > run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
> > run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
> >
> > + run.first_slice =
> > + run.src->vb2_buf.timestamp != run.dst-
>vb2_buf.timestamp;
>
> Can't we use slice->first_mb_in_slice to determine if a slice is the
> first? I'd expect ->first_mb_in_slice to be 0 (unless we decide to
> support ASO).
I'm not sure if that is always the case, I would have to check the standard.
Anyway, this method of comparing timestamps was suggested to me a while ago
when we were discussing details on a way forward for multi-slice decoding. I
highly doubt someone would decode slices in mixed order (from different frames)
in same instance.
I can change that in next version if ->first_mb_in_slice == 0 is always true
for the first slice.
Best regards,
Jernej
>
> > /* Apply request(s) controls if needed. */
> > src_req = run.src->vb2_buf.req_obj.req;
_______________________________________________
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 0/2] coresight: Add barrier packet when moving offset forward
From: Yabin Cui @ 2019-08-26 18:52 UTC (permalink / raw)
To: Mathieu Poirier, Suzuki K Poulose, leo.yan
Cc: alexander.shishkin, Yabin Cui, linux-arm-kernel, mike.leach,
linux-kernel
In-Reply-To: <CANLsYkxC-4UZcVKoTQiJ2PsDxwuriFoAwqdbM39EC1G3nwwAHg@mail.gmail.com>
> Can I add your Tested-by ?
Yes. I just sent a tested-by reply, but not sure if it works. I am not very familar
with linux kernel review system.
_______________________________________________
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 8/8] media: cedrus: Add support for V4L2_DEC_CMD_FLUSH
From: Boris Brezillon @ 2019-08-26 18:55 UTC (permalink / raw)
To: Jernej Skrabec
Cc: devel, acourbot, pawel, jonas, gregkh, wens, mripard, tfiga,
paul.kocialkowski, kyungmin.park, linux-media, linux-arm-kernel,
hverkuil-cisco, mchehab, ezequiel, linux-kernel, m.szyprowski
In-Reply-To: <20190822194500.2071-9-jernej.skrabec@siol.net>
On Thu, 22 Aug 2019 21:45:00 +0200
Jernej Skrabec <jernej.skrabec@siol.net> wrote:
> This command is useful for explicitly flushing last decoded frame.
>
> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
> ---
> .../staging/media/sunxi/cedrus/cedrus_video.c | 34 +++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> index 5153b2bba21e..9eae69d5741c 100644
> --- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> +++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
> @@ -331,6 +331,37 @@ static int cedrus_s_fmt_vid_out(struct file *file, void *priv,
> return 0;
> }
>
> +static int cedrus_try_decoder_cmd(struct file *file, void *fh,
> + struct v4l2_decoder_cmd *dc)
> +{
> + if (dc->cmd != V4L2_DEC_CMD_FLUSH)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int cedrus_decoder_cmd(struct file *file, void *fh,
> + struct v4l2_decoder_cmd *dc)
> +{
> + struct cedrus_ctx *ctx = cedrus_file2ctx(file);
> + struct vb2_v4l2_buffer *out_vb, *cap_vb;
> + int ret;
> +
> + ret = cedrus_try_decoder_cmd(file, fh, dc);
> + if (ret < 0)
> + return ret;
Not directly related to this patch, but it seems most drivers
implementing ->vdioc_decoder_cmd() call ->vidioc_try_decoder_cmd()
internally to make sure the cmd is supported. Maybe something
we could automate at the v4l2-ioctl.c level.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v1 0/6] Allow kexec reboot for GICv3 and device tree
From: Pavel Tatashin @ 2019-08-26 19:00 UTC (permalink / raw)
To: pasha.tatashin, jmorris, sashal, kexec, linux-kernel,
linux-arm-kernel, marc.zyngier, james.morse, vladimir.murzin,
mark.rutland
Marc Zyngier added the support for kexec and GICv3 for EFI based systems.
However, it is still not possible todo on systems with device trees.
Here is EFI fixes from Marc:
https://lore.kernel.org/lkml/20180921195954.21574-1-marc.zyngier@arm.com
For Device Tree variant: lets allow reserve a memory region in interrupt
controller node, and use this property to allocate interrupt tables.
This way we are safe during kexec, as these page tables are going to stay
the same after kexec.
Pavel Tatashin (6):
rqchip/gic-v3-its: reset prop table outside of allocation
rqchip/gic-v3-its: use temporary va / pa variables
rqchip/gic-v3-its: add reset pending table function
rqchip/gic-v3-its: move reset pending table outside of allocator
rqchip/gic-v3-its: move reset pending table outside of allocator
dt-bindings: interrupt-controller: add optional memory-region
.../interrupt-controller/arm,gic-v3.yaml | 7 +
drivers/irqchip/irq-gic-v3-its.c | 121 +++++++++++++-----
2 files changed, 96 insertions(+), 32 deletions(-)
--
2.23.0
_______________________________________________
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