* Re: [PATCH V4 03/11] clk: imx: scu: add two cells binding support
From: Stephen Boyd @ 2019-09-16 18:44 UTC (permalink / raw)
To: Dong Aisheng
Cc: Dong Aisheng, Michael Turquette, dl-linux-imx, Sascha Hauer,
Fabio Estevam, Shawn Guo, linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAA+hA=QoZFFb_EVfxcDuJB-9VobVd-1-RyhWeNTSePxW50P8Eg@mail.gmail.com>
Quoting Dong Aisheng (2019-09-09 03:23:25)
> Hi Stephen,
>
> Thanks for the review.
>
> On Sat, Sep 7, 2019 at 5:29 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Quoting Dong Aisheng (2019-08-20 04:13:17)
> > > diff --git a/drivers/clk/imx/clk-imx8qxp.c b/drivers/clk/imx/clk-imx8qxp.c
> > > index 5e2903e..1ad3f2a 100644
> > > --- a/drivers/clk/imx/clk-imx8qxp.c
> > > +++ b/drivers/clk/imx/clk-imx8qxp.c
> > > @@ -134,7 +134,12 @@ static int imx8qxp_clk_probe(struct platform_device *pdev)
> > > i, PTR_ERR(clks[i]));
> > > }
> > >
> > > - return of_clk_add_hw_provider(ccm_node, of_clk_hw_onecell_get, clk_data);
> > > + if (clock_cells == 2)
> >
> > Can you just read this from the DT node again instead of having a global
> > variable called "clock_cells" for this?
> >
>
> I tried thinking about it.
> One problem is that we also need this information in the exist clk
> registration API to
> keep the backwards compatibility:
> e.g.
> static inline struct clk_hw *imx_clk_scu(const char *name, u32 rsrc_id,
> u8 clk_type)
> {
> - return __imx_clk_scu(name, NULL, 0, rsrc_id, clk_type);
> + if (clock_cells == 2)
> + return imx_clk_scu_alloc_dev(name, NULL, 0, rsrc_id, clk_type);
> + else
> + return __imx_clk_scu(name, NULL, 0, rsrc_id, clk_type);
> }
>
> Parsing it for all clocks seems not good.
Can you parse it once for the clock controller and then pass it to the
registration function as the number of cells? I dislike the global and
the name of the global.
>
> In the future, i planned to totally remove the legacy binding support which
> is a premature one and missing continued support.
> Then we will also remove this unneeded clock_cells.
Ok sure.
_______________________________________________
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 V4 08/11] clk: imx: imx8qxp-lpcg: add parsing clocks from device tree
From: Stephen Boyd @ 2019-09-16 18:45 UTC (permalink / raw)
To: Dong Aisheng
Cc: Dong Aisheng, Michael Turquette, dl-linux-imx, Sascha Hauer,
Fabio Estevam, Shawn Guo, linux-clk,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE
In-Reply-To: <CAA+hA=QJwfHsRA+G2oT2awLxx659qXLPsiECV6VYcJ181c6D8w@mail.gmail.com>
Quoting Dong Aisheng (2019-09-09 04:23:14)
> ]On Sat, Sep 7, 2019 at 5:35 PM Stephen Boyd <sboyd@kernel.org> wrote:
> >
> > Quoting Dong Aisheng (2019-08-20 04:13:22)
> > > Add parsing clocks from device tree.
> >
> > Please describe some more here.
>
> Will improve.
>
> > > + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > > + base = devm_ioremap_resource(&pdev->dev, res);
> > > + if (IS_ERR(base))
> > > + return PTR_ERR(base);
> > > +
> > > + count = of_property_count_u32_elems(np, "clock-indices");
> > > + if (count < 0) {
> > > + dev_err(&pdev->dev, "failed to count clocks\n");
> > > + return -EINVAL;
> > > + }
> >
> > Is 'count' expected to be equal to IMX_LPCG_MAX_CLKS? Because later on
> > in this function we set the num of clks to the MAX instead of the count
> > from clock-indices.
> >
>
> No. Here is a tricky to ease the clk getting.
> For example, one LPCG supports up to 8 clock outputs which each of them
> is fixed to 4 bits. Then we can easily use the bit-offset/clk-indices
> parsed from DT
> to fetch the corresponding clock by hws[clkspec->args[0] / 4].
> And the cost is very limited with only a few pointers.
Ok. Can you add a comment into the code to explain this?
_______________________________________________
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 v5 0/4] Raspberry Pi 4 DMA addressing support
From: Stefan Wahren @ 2019-09-16 19:19 UTC (permalink / raw)
To: Matthias Brugger, Matthias Brugger, robh+dt, linux-arm-kernel,
Nicolas Saenz Julienne
Cc: f.fainelli, phil, linux-rpi-kernel, linux-kernel
In-Reply-To: <a5073e16-c017-216c-72b4-0e861102c4e8@gmail.com>
Hi Matthias,
[drop uninvolved receiver]
Am 13.09.19 um 12:39 schrieb Matthias Brugger:
>
>>>>> If you talk about the
>>>>> downstream kernel, I suppose you mean we should change this in the FW DT blob
>>>>> and in the downstream kernel. That would work for me.
>>>>>
>>>>> Did I understand you correctly?
>>>> Yes
>>>>
>>>> So i suggest to add the upstream compatibles into the repo mentioned above.
>>>>
>>>> Sorry, but in case you decided as a U-Boot developer to be compatible
>>>> with a unreviewed DT, we also need to make U-Boot compatible with
>>>> upstream and downstream DT blobs.
>>>>
>>> Well RPi3 is working with the DT blob provided by the FW, as I mentioned earlier
>>> if we can use this DTB we can work towards one binary that can boot both RPi3
>>> and RPi4. On the other hand we can rely on the FW to detect the amount of memory
>>> our RPi4 has.
>>>
>>> That said, I agree that we should make sure that U-Boot can boot with both DTBs,
>>> the upstream one and the downstream. Now the question is how to get to this. I'm
>>> a bit puzzled that by talking about "unreviewed DT" you insinuate that bcm2711
>>> compatible is already reviewed and can't be changed. From what I can see none of
>>> these compatibles got merged for now, so we are still at time to change them.
>> Stephen Boyd was okay with clk changes except of a small nit. So i fixed
>> this is as he suggested in a separate series. Unfortunately this hasn't
>> be applied yet [1].
>>
>> The i2c, pinctrl and the sdhci changes has been applied yet.
>>
>> In my opinion it isn't the job of the mainline kernel to adapt to a
>> vendor device tree. It's the vendor device tree which needs to be fixed.
>>
> I agree with that. But if we can make this easier by choosing a compatible which
> fits downstream without violating upstream and it makes sense with the naming
> scheme of the RPi, I think that's a good argument.
i spend a lot of my spare time to prepare these patch series in order to
get a clean solution.
Either mixing bcm2711/bcm2838 or changing everything to bcm2838 in the
upstream tree has the following drawbacks:
- additional review time and delay of the Raspberry Pi 4 support
- harder to understand for developer/reviewer without RPi knowledge
Btw currently u-boot only uses bcm2711, so it would be nice to keep that.
So my suggestion is to add bcm2711 compatibles in the downstream tree.
Best regards
Stefan
>
>> Sorry, but this is my holiday. I will back after the weekend.
>>
> Sure, enjoy. I'll be on travel for the next two weeks but will try to keep up
> with emails.
>
> Regards,
> Matthias
>
>> Best regards
>> Stefan
>>
>> [1] - https://www.spinics.net/lists/linux-clk/msg40534.html
>>
>>> Apart from the point Florian made, to stay consistent with the RPi SoC naming,
>>> it will save us work, both in the kernel and in U-Boot, as we would need to add
>>> both compatibles to the code-base.
>>>
>>> Regards,
>>> Matthias
>>>
>>>>>>> Regards,
>>>>>>> Matthias
>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Matthias
>>>>>>>>
>>>>>>>>> Are there any config.txt tweaks necessary?
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> linux-arm-kernel mailing list
>>>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> linux-arm-kernel mailing list
>>>>>>> linux-arm-kernel@lists.infradead.org
>>>>>>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
_______________________________________________
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] iommu/arm-smmu: Axe a useless test in 'arm_smmu_master_alloc_smes()'
From: Christophe JAILLET @ 2019-09-16 19:43 UTC (permalink / raw)
To: Robin Murphy, will, joro
Cc: iommu, kernel-janitors, linux-kernel, linux-arm-kernel
In-Reply-To: <de9ee628-9efb-3078-590c-6852be61c7d2@arm.com>
Le 16/09/2019 à 12:46, Robin Murphy a écrit :
> On 15/09/2019 20:34, Christophe JAILLET wrote:
>> 'ommu_group_get_for_dev()' never returns NULL, so this test can be
>> removed.
>
> Nit: typo in the function name.
>
> Otherwise, there definitely used to be some path where a NULL return
> could leak out, so I would have had that in mind at the time I wrote
> this, but apparently I never noticed that that had already been
> cleaned up by the time this got merged.
>
Hi,
Maybe fixed by 72dcac633475 ("iommu: Warn once when device_group
callback returns NULL")
CJ
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
>
> Thanks,
> Robin.
>
>> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
>> ---
>> drivers/iommu/arm-smmu.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index c3ef0cc8f764..6fae8cdbe985 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -1038,8 +1038,6 @@ static int arm_smmu_master_alloc_smes(struct
>> device *dev)
>> }
>> group = iommu_group_get_for_dev(dev);
>> - if (!group)
>> - group = ERR_PTR(-ENOMEM);
>> if (IS_ERR(group)) {
>> ret = PTR_ERR(group);
>> goto out_err;
>>
>
_______________________________________________
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] clk: at91: allow 24 Mhz clock as input for PLL
From: Stephen Boyd @ 2019-09-16 19:52 UTC (permalink / raw)
To: Eugen.Hristev, alexandre.belloni, linux-arm-kernel, linux-clk,
linux-kernel, mturquette
Cc: Eugen.Hristev
In-Reply-To: <1568183622-7858-1-git-send-email-eugen.hristev@microchip.com>
Quoting Eugen.Hristev@microchip.com (2019-09-10 23:39:20)
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> The PLL input range needs to be able to allow 24 Mhz crystal as input
> Update the range accordingly in plla characteristics struct
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> ---
Is there a Fixes: tag for this? Seems like it was always wrong?
_______________________________________________
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] coresight: etm4x: Add support for ThunderX2
From: Mathieu Poirier @ 2019-09-16 19:58 UTC (permalink / raw)
To: Tanmay Vilas Kumar Jagdale
Cc: Tomasz Nowicki, Jayachandran Chandrasekharan Nair,
Ganapatrao Kulkarni, linux-arm-kernel@lists.infradead.org,
suzuki.poulose@arm.com
In-Reply-To: <1568096664-13252-1-git-send-email-tanmay@marvell.com>
On Tue, Sep 10, 2019 at 06:25:02AM +0000, Tanmay Vilas Kumar Jagdale wrote:
> Add ETMv4 periperhal ID for Marvell's ThunderX2 chip.
> This chip contains ETMv4.1 version.
>
> Signed-off-by: Tanmay Jagdale <tanmay@marvell.com>
mpoirier@xps15:~/work/coresight/kernel-maint$ ./scripts/checkpatch.pl 0001-coresight-etm4x-Add-support-for-ThunderX2.patch
WARNING: Missing Signed-off-by: line by nominal patch author 'Tanmay Vilas Kumar Jagdale <tanmay@marvell.com>'
total: 0 errors, 1 warnings, 7 lines checked
NOTE: For some of the reported defects, checkpatch may be able to
mechanically convert to the typical style using --fix or --fix-inplace.
0001-coresight-etm4x-Add-support-for-ThunderX2.patch has style problems, please review.
NOTE: If any of the errors are false positives, please report
them to the maintainer, see CHECKPATCH in MAINTAINERS
> ---
> Changes since v1:
> - Updated commit message.
> - Use UCI to identify ETMv4.
> - Remove addition of ETMv4.1 version checks.
>
> drivers/hwtracing/coresight/coresight-etm4x.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm4x.c b/drivers/hwtracing/coresight/coresight-etm4x.c
> index a128b5063f46..47839b4a8bc0 100644
> --- a/drivers/hwtracing/coresight/coresight-etm4x.c
> +++ b/drivers/hwtracing/coresight/coresight-etm4x.c
> @@ -1211,6 +1211,7 @@ static const struct amba_id etm4_ids[] = {
> CS_AMBA_UCI_ID(0x000f0211, uci_id_etm4),/* Qualcomm Kryo */
> CS_AMBA_ID(0x000bb802), /* Qualcomm Kryo 385 Cortex-A55 */
> CS_AMBA_ID(0x000bb803), /* Qualcomm Kryo 385 Cortex-A75 */
> + CS_AMBA_UCI_ID(0x000cc0af, uci_id_etm4),/* Marvell ThunderX2 */
> {},
> };
>
> --
> 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
* Re: [PATCH 1/2] clk: at91: fix update bit maps on CFG_MOR write
From: Stephen Boyd @ 2019-09-16 20:15 UTC (permalink / raw)
To: Eugen.Hristev, alexandre.belloni, linux-arm-kernel, linux-clk,
linux-kernel, mturquette
Cc: Eugen.Hristev, Ludovic.Desroches
In-Reply-To: <1568042692-11784-1-git-send-email-eugen.hristev@microchip.com>
Quoting Eugen.Hristev@microchip.com (2019-09-09 08:30:31)
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> The regmap update bits call was not selecting the proper mask, considering
> the bits which was updating.
> Update the mask from call to also include OSCBYPASS.
> Removed MOSCEN which was not updated.
>
> Fixes: 1bdf02326b71 ("clk: at91: make use of syscon/regmap internally")
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> ---
Applied to clk-next
_______________________________________________
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] clk: at91: select parent if main oscillator or bypass is enabled
From: Stephen Boyd @ 2019-09-16 20:15 UTC (permalink / raw)
To: Eugen.Hristev, alexandre.belloni, linux-arm-kernel, linux-clk,
linux-kernel, mturquette
Cc: Eugen.Hristev, Ludovic.Desroches
In-Reply-To: <1568042692-11784-2-git-send-email-eugen.hristev@microchip.com>
Quoting Eugen.Hristev@microchip.com (2019-09-09 08:30:34)
> From: Eugen Hristev <eugen.hristev@microchip.com>
>
> Selecting the right parent for the main clock is done using only
> main oscillator enabled bit.
> In case we have this oscillator bypassed by an external signal (no driving
> on the XOUT line), we still use external clock, but with BYPASS bit set.
> So, in this case we must select the same parent as before.
> Create a macro that will select the right parent considering both bits from
> the MOR register.
> Use this macro when looking for the right parent.
>
> Signed-off-by: Eugen Hristev <eugen.hristev@microchip.com>
> ---
Applied to clk-next
_______________________________________________
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/6] ARM, arm64: Remove arm_pm_restart()
From: Thierry Reding @ 2019-09-16 20:28 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Linux ARM, linux-kernel@vger.kernel.org, Guenter Roeck
In-Reply-To: <CAK8P3a1EZi5apOm90B6YW2GzFXsirz5wk-D66daR20oj_TLXNg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3276 bytes --]
On Mon, Sep 16, 2019 at 06:29:30PM +0200, Arnd Bergmann wrote:
> On Mon, Sep 16, 2019 at 5:50 PM Thierry Reding <thierry.reding@gmail.com> wrote:
> > On Mon, Sep 16, 2019 at 08:43:36AM -0700, Guenter Roeck wrote:
> > > On Mon, Sep 16, 2019 at 03:49:20PM +0200, Thierry Reding wrote:
> > > > On Mon, Sep 16, 2019 at 06:17:01AM -0700, Guenter Roeck wrote:
> > > > > On 9/16/19 12:49 AM, Arnd Bergmann wrote:
> > > > > > On Sat, Sep 14, 2019 at 5:26 PM Guenter Roeck <linux@roeck-us.net> wrote:
> > > > > > > On Mon, Jan 30, 2017 at 12:05:06PM +0100, Thierry Reding wrote:
> > > > > > > > From: Thierry Reding <treding@nvidia.com>
> > > > > > > >
> > > > > > > > Hi everyone,
> > > > > > > >
> > > > > > > > This small series is preparatory work for a series that I'm working on
> > > > > > > > which attempts to establish a formal framework for system restart and
> > > > > > > > power off.
> > > > > > > >
> > > > > > > > Guenter has done a lot of good work in this area, but it never got
> > > > > > > > merged. I think this set is a valuable addition to the kernel because
> > > > > > > > it converts all odd providers to the established mechanism for restart.
> > > > > > > >
> > > > > > > > Since this is stretched across both 32-bit and 64-bit ARM, as well as
> > > > > > > > PSCI, and given the SoC/board level of functionality, I think it might
> > > > > > > > make sense to take this through the ARM SoC tree in order to simplify
> > > > > > > > the interdependencies. But it should also be possible to take patches
> > > > > > > > 1-4 via their respective trees this cycle and patches 5-6 through the
> > > > > > > > ARM and arm64 trees for the next cycle, if that's preferred.
> > > > > > > >
> > > > > > >
> > > > > > > We tried this twice now, and it seems to go nowhere. What does it take
> > > > > > > to get it applied ?
> > > > > >
> > > > > > Can you send a pull request to soc@kernel.org after the merge window,
> > > > > > with everyone else on Cc? If nobody objects, I'll merge it through
> > > > > > the soc tree.
> > > > > >
> > > > >
> > > > > Sure, I'll rebase and do that.
> > > >
> > > > I've uploaded a rebased tree here:
> > > >
> > > > https://github.com/thierryreding/linux/tree/for-5.5/system-power-reset
> > > >
> > > > The first 6 patches in that tree correspond to this series. There were a
> > > > couple of conflicts I had to resolve and I haven't fully tested the
> > > > series yet, but if you haven't done any of the rebasing, the above may
> > > > be useful to you.
> > > >
> > >
> > > Maybe Arnd can just use your branch (or rather part of it if you would
> > > split it off) since you already did the work ?
>
> The branch needs to be rebased once more as it is currently
> based on linux-next.
Yeah, I usually do that once -rc1 is out.
> > Yeah, I can just send the pull request for the 6 patches after -rc1.
>
> Ok, sounds good. I'm also happy to take the remaining patches
> in that branch, for the other architectures.
All of the patches beyond the 6 in this set rely on the system reset and
power "framework". I don't think there was broad concensus on that idea
yet. If you think it's worth another try I'm happy to send the patches
out again.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 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 v2 1/7] clk: imx8m: Set CLK_GET_RATE_NOCACHE on dram_alt/apb
From: Stephen Boyd @ 2019-09-16 20:33 UTC (permalink / raw)
To: Chanwoo Choi, Leonard Crestez, MyungJoo Ham, Rob Herring,
Shawn Guo
Cc: Mark Rutland, Artur Świgoń, Abel Vesa, Saravana Kannan,
Anson Huang, linux-arm-kernel, Viresh Kumar, Michael Turquette,
linux-pm, linux-imx, Krzysztof Kozlowski, linux-clk,
Kyungmin Park, Alexandre Bailon, kernel, Dong Aisheng,
Fabio Estevam, Georgi Djakov, devicetree, Jacky Bai
In-Reply-To: <90bfeebcb76e76d286ed7f022ea9e0d9a569ebe2.1566315740.git.leonard.crestez@nxp.com>
Quoting Leonard Crestez (2019-08-20 08:45:06)
> Dram frequency changes required modifying these clocks outside the
> control of clk framework. Mark them as CLK_GET_RATE_NOCACHE so that
> rates are always read back from registers.
Why can't we control the clks from the clk framework? Please add that
information in the commit text here.
>
> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
> ---
> drivers/clk/imx/clk-imx8mm.c | 6 ++++--
> drivers/clk/imx/clk-imx8mn.c | 6 ++++--
> drivers/clk/imx/clk-imx8mq.c | 7 ++++---
> 3 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
> index 4ead3ea2713c..6cac80550f43 100644
> --- a/drivers/clk/imx/clk-imx8mm.c
> +++ b/drivers/clk/imx/clk-imx8mm.c
> @@ -526,12 +526,14 @@ static int imx8mm_clocks_probe(struct platform_device *pdev)
> /* IPG */
> clks[IMX8MM_CLK_IPG_ROOT] = imx_clk_divider2("ipg_root", "ahb", base + 0x9080, 0, 1);
> clks[IMX8MM_CLK_IPG_AUDIO_ROOT] = imx_clk_divider2("ipg_audio_root", "audio_ahb", base + 0x9180, 0, 1);
>
> /* IP */
> - clks[IMX8MM_CLK_DRAM_ALT] = imx8m_clk_composite("dram_alt", imx8mm_dram_alt_sels, base + 0xa000);
> - clks[IMX8MM_CLK_DRAM_APB] = imx8m_clk_composite_critical("dram_apb", imx8mm_dram_apb_sels, base + 0xa080);
> + clks[IMX8MM_CLK_DRAM_ALT] = __imx8m_clk_composite("dram_alt", imx8mm_dram_alt_sels, base + 0xa000,
> + CLK_GET_RATE_NOCACHE);
> + clks[IMX8MM_CLK_DRAM_APB] = __imx8m_clk_composite("dram_apb", imx8mm_dram_apb_sels, base + 0xa080,
> + CLK_IS_CRITICAL | CLK_GET_RATE_NOCACHE);
Also, add a comment to this effect about why it can't be done from the
clk framework wherever the CLK_GET_RATE_NOCACHE flag is set. Basically
this flag is a hack and is an example of something that we need to fix.
> clks[IMX8MM_CLK_VPU_G1] = imx8m_clk_composite("vpu_g1", imx8mm_vpu_g1_sels, base + 0xa100);
> clks[IMX8MM_CLK_VPU_G2] = imx8m_clk_composite("vpu_g2", imx8mm_vpu_g2_sels, base + 0xa180);
> clks[IMX8MM_CLK_DISP_DTRC] = imx8m_clk_composite("disp_dtrc", imx8mm_disp_dtrc_sels, base + 0xa200);
> clks[IMX8MM_CLK_DISP_DC8000] = imx8m_clk_composite("disp_dc8000", imx8mm_disp_dc8000_sels, base + 0xa280);
> clks[IMX8MM_CLK_PCIE1_CTRL] = imx8m_clk_composite("pcie1_ctrl", imx8mm_pcie1_ctrl_sels, base + 0xa300);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v3 10/26] stmmac: pci: Loop using PCI_STD_NUM_BARS
From: Denis Efremov @ 2019-09-16 20:41 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Alexandre Torgue, linux-pci, linux-kernel, Denis Efremov,
Giuseppe Cavallaro, Andrew Murray, linux-arm-kernel
In-Reply-To: <20190916204158.6889-1-efremov@linux.com>
Refactor loops to use idiomatic C style and avoid the fencepost error
of using "i < PCI_STD_RESOURCE_END" when "i <= PCI_STD_RESOURCE_END"
is required, e.g., commit 2f686f1d9bee ("PCI: Correct PCI_STD_RESOURCE_END
usage").
To iterate through all possible BARs, loop conditions changed to the
*number* of BARs "i < PCI_STD_NUM_BARS", instead of the index of the last
valid BAR "i <= PCI_STD_RESOURCE_END".
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Signed-off-by: Denis Efremov <efremov@linux.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 86f9c07a38cf..cfe496cdd78b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
@@ -258,7 +258,7 @@ static int stmmac_pci_probe(struct pci_dev *pdev,
}
/* Get the base address of device */
- for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
if (pci_resource_len(pdev, i) == 0)
continue;
ret = pcim_iomap_regions(pdev, BIT(i), pci_name(pdev));
@@ -296,7 +296,7 @@ static void stmmac_pci_remove(struct pci_dev *pdev)
stmmac_dvr_remove(&pdev->dev);
- for (i = 0; i <= PCI_STD_RESOURCE_END; i++) {
+ for (i = 0; i < PCI_STD_NUM_BARS; i++) {
if (pci_resource_len(pdev, i) == 0)
continue;
pcim_iounmap_regions(pdev, BIT(i));
--
2.21.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] iommu/arm-smmu: Report USF more clearly
From: Robin Murphy @ 2019-09-16 21:42 UTC (permalink / raw)
To: Doug Anderson, Will Deacon; +Cc: iommu, Joerg Roedel, Linux ARM
In-Reply-To: <CAD=FV=Wx7zSqGSABfnG9B0yAcZvimub+hMcPRfUoFxr-FJeFew@mail.gmail.com>
On 2019-09-16 7:19 pm, Doug Anderson wrote:
[...]
>>> 1. "By firmware" might be a bit misleading. In most cases I'm aware
>>> of the problem is in the device tree that was bundled together with
>>> the kernel. If there are actually cases where firmware has baked in a
>>> device tree and it got this wrong then we might want to spend time
>>> figuring out what to do about it.
>>
>> I thought that was usually the way UEFI systems worked, where the kernel
>> is updated independently of the device-tree? Either way, that should be
>> what we're aiming for, even if many platforms require the two to be tied
>> together.
>
> It's my opinion that until there is a place in the kernel to "fixup"
> broken device trees that were baked in firmware that it's a bad idea
> to ship device trees separate from the kernel except if the device
> trees are exceedingly simple. We'll run into too many problems
> otherwise, either because the kernel the device tree was written for
> had downstream patches or someone just made a mistake in them and
> nobody noticed. I know device trees are supposed to be ABI, but
> people make mistakes and we need a way to fix them up.
>
> ...but that's getting pretty far afield from Robin's patch.
Let's not get too hung up on devicetree - you can go out and buy certain
ACPI-only platforms today that also fall foul of this, for which AFAIK
the necessary firmware update is in the SoC vendor's hands.
>>> 2. Presumably booting with "arm-smmu.disable_bypass=0" is in most
>>> cases the least desirable option available. I always consider kernel
>>> command line parameters as something of a last resort for
>>> configuration and would only be something that and end user might do
>>> if they were given a kernel compiled by someone else (like if someone
>>> where taking a prebuilt Linux distro and trying to install it onto a
>>> generic PC). Are you seeing cases where this is happening? If people
>>> are compiling their own kernel I'd argue that telling them to set
>>> "CONFIG_ARM_SMMU_DISABLE_BYPASS_BY_DEFAULT" to "no" is much better
>>> than trying to jam a command line option on. Command line options
>>> don't scale well.
>>
>> Hmm. Recompiling seems like even more of a last resort to me!
>
> Depends on what you're doing. If you're not in the habit of compiling
> a kernel and you're just trying to make one work then the command line
> is great. If you're trying to manage configuration for a whole bunch
> of different hardware products then the command line is a terrible
> place to store config.
>
> ...but I guess the summary is that we wouldn't want someone to
> actually ship a kernel with this option on anyway. ;-)
FWIW the meta here is really "oops, you've just installed a new kernel
and now your machine is unusable - you need to take it up with whoever
supports your platform, but in the meantime this is the minimal thing
you can do to get things back working as before."
Personally I'm less concerned about folks maintaining "hardware
products", as I'd like to assume they would hit this in QA and have a
relatively short loop back to kernel people who know what's up (or at
least know enough to join the dots to punt it to my inbox). My main
concern is end users of SBSA-ish platforms who are free to pick and
choose distros - and/or kernel packages within their distro - and thus
may bugger up their machine inadvertently if the distro package happens
to have picked this option up from defconfig (from a quick look at least
my preferred one has).
>>> 3. Any chance you could make it more obvious that this change is
>>> undesirable and a last resort? AKA:
>>>
>>> "Stream ID x blocked for security reasons; allow anyway by booting
>>> with arm-smmu.disable_bypass=0"
>>
>> How about:
>>
>> "Blocked transaction from unknown Stream ID x; boot with
>> \"arm-smmu.disable_bypass=0\" to allow these transactions, although this
>> may have security implications."
>
> Fine with me if it's not too long for an error message.
Sounds good, I'll respin with a slight abbreviation of that (and minus
the embarrassingly stupid thinko) tomorrow.
Cheers,
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL 1/5] ARM: SoC platform updates for v5.4
From: Linus Torvalds @ 2019-09-16 22:51 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: SoC Team, Linux ARM
In-Reply-To: <CAK8P3a1twq1+RxS9uE7LQWAbg4tf72R2df4Q20fXUR_4+7B26A@mail.gmail.com>
On Mon, Sep 16, 2019 at 9:32 AM Arnd Bergmann <arnd@arndb.de> wrote:
>
> ARM: SoC platform updates for v5.4
Hmm.
You now build iop-adma.c on other platforms, but that then causes this:
drivers/dma/iop-adma.c: In function ‘__iop_adma_slot_cleanup’:
drivers/dma/iop-adma.c:118:12: warning: format ‘%x’ expects argument
of type ‘unsigned int’, but argument 6 has type ‘dma_addr_t’ {aka
‘long long unsigned int’} [-Wformat=]
118 | pr_debug("\tcookie: %d slot: %d busy: %d "
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/dma/iop-adma.c:119:18: note: format string is defined here
119 | "this_desc: %#x next_desc: %#llx ack: %d\n",
| ~~^
| |
| unsigned int
| %#llx
and the lpc32xx_udc driver has this:
drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_pop_fifo’:
drivers/usb/gadget/udc/lpc32xx_udc.c:1156:11: warning: cast from
pointer to integer of different size [-Wpointer-to-int-cast]
1156 | switch (((u32) data) & 0x3) {
| ^
drivers/usb/gadget/udc/lpc32xx_udc.c: In function ‘udc_stuff_fifo’:
drivers/usb/gadget/udc/lpc32xx_udc.c:1257:11: warning: cast from
pointer to integer of different size [-Wpointer-to-int-cast]
1257 | switch (((u32) data) & 0x3) {
| ^
so I will be marking them both arm-specific again because I don't want
to see the build warnings.
Linus
_______________________________________________
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 v4 2/7] dt-bindings: mmc: Add Actions Semi SD/MMC/SDIO controller binding
From: Linus Walleij @ 2019-09-16 22:57 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Ulf Hansson, Stephen Boyd, linux-actions, linux-mmc,
linux-kernel@vger.kernel.org, Thomas C. Liau, linux-clk,
Rob Herring, Andreas Färber, Linux ARM
In-Reply-To: <20190916154546.24982-3-manivannan.sadhasivam@linaro.org>
On Mon, Sep 16, 2019 at 5:46 PM Manivannan Sadhasivam
<manivannan.sadhasivam@linaro.org> wrote:
> Add devicetree YAML binding for Actions Semi Owl SoC's SD/MMC/SDIO
> controller.
>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Neat use of yaml!
Yours,
Linus Walleij
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [REGRESSION] sdhci no longer detects SD cards on LX2160A
From: Russell King - ARM Linux admin @ 2019-09-16 22:57 UTC (permalink / raw)
To: Adrian Hunter, linux-mmc, linux-arm-kernel
In-Reply-To: <20190916171509.GG25745@shell.armlinux.org.uk>
The problem below seems to be sporadic with v5.3, which makes finding
its cause quite difficult - and makes bisecting useless. I'd describe
it as "likely" to affect either mmc0 or mmc1 on v5.3. I haven't seen
it at all with v5.2.
I'll see whether I can pin anything down tomorrow.
On Mon, Sep 16, 2019 at 06:15:10PM +0100, Russell King - ARM Linux admin wrote:
> Hi,
>
> It seems that somewhere between v5.2 and v5.3, sdhci fails to detect
> SD cards on the NXP LX2160A, but continues to work with eMMC.
> This uses the sdhci-esdhc driver.
>
> v5.2:
>
> sdhci: Secure Digital Host Controller Interface driver
> sdhci: Copyright(c) Pierre Ossman
> sdhci-pltfm: SDHCI platform and OF driver helper
> mmc0: SDHCI controller on 2140000.esdhc [2140000.esdhc] using ADMA 64-bit
> mmc1: SDHCI controller on 2150000.esdhc [2150000.esdhc] using ADMA 64-bit
> mmc0: new high speed SDHC card at address aaaa
> mmcblk0: mmc0:aaaa SU04G 3.69 GiB
> mmc1: new HS400 MMC card at address 0001
> mmcblk1: mmc1:0001 DF4064 58.2 GiB
> mmcblk1boot0: mmc1:0001 DF4064 partition 1 4.00 MiB
> mmcblk1boot1: mmc1:0001 DF4064 partition 2 4.00 MiB
> mmcblk1rpmb: mmc1:0001 DF4064 partition 3 4.00 MiB, chardev (247:0)
> mmcblk1: p1
>
> v5.3:
>
> sdhci: Secure Digital Host Controller Interface driver
> sdhci: Copyright(c) Pierre Ossman
> sdhci-pltfm: SDHCI platform and OF driver helper
> mmc0: SDHCI controller on 2140000.esdhc [2140000.esdhc] using ADMA 64-bit
> mmc1: SDHCI controller on 2150000.esdhc [2150000.esdhc] using ADMA 64-bit
> mmc0: ADMA error
> mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00002202
> mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
> mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> mmc0: sdhci: Present: 0x01f50008 | Host ctl: 0x00000038
> mmc0: sdhci: Power: 0x00000003 | Blk gap: 0x00000000
> mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x000040d8
> mmc0: sdhci: Timeout: 0x00000003 | Int stat: 0x00000001
> mmc0: sdhci: Int enab: 0x037f108f | Sig enab: 0x037f108b
> mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002202
> mmc0: sdhci: Caps: 0x35fa0000 | Caps_1: 0x0000af00
> mmc0: sdhci: Cmd: 0x0000333a | Max curr: 0x00000000
> mmc0: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x001d8a33
> mmc0: sdhci: Resp[2]: 0x325b5900 | Resp[3]: 0x3f400e00
> mmc0: sdhci: Host ctl2: 0x00000000
> mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236d43820c
> mmc0: sdhci: ============================================
> mmc0: error -5 whilst initialising SD card
> mmc0: ADMA error
> mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00002202
> mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
> mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> mmc0: sdhci: Present: 0x01f50008 | Host ctl: 0x00000038
> mmc0: sdhci: Power: 0x00000003 | Blk gap: 0x00000000
> mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x00008098
> mmc0: sdhci: Timeout: 0x00000002 | Int stat: 0x00000001
> mmc0: sdhci: Int enab: 0x037f108f | Sig enab: 0x037f108b
> mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002202
> mmc0: sdhci: Caps: 0x35fa0000 | Caps_1: 0x0000af00
> mmc0: sdhci: Cmd: 0x0000333a | Max curr: 0x00000000
> mmc0: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x001d8a33
> mmc0: sdhci: Resp[2]: 0x325b5900 | Resp[3]: 0x3f400e00
> mmc0: sdhci: Host ctl2: 0x00000000
> mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236d43820c
> mmc0: sdhci: ============================================
> mmc0: error -5 whilst initialising SD card
> mmc1: new HS400 MMC card at address 0001
> mmcblk1: mmc1:0001 DF4064 58.2 GiB
> mmcblk1boot0: mmc1:0001 DF4064 partition 1 4.00 MiB
> mmcblk1boot1: mmc1:0001 DF4064 partition 2 4.00 MiB
> mmcblk1rpmb: mmc1:0001 DF4064 partition 3 4.00 MiB, chardev (247:0)
> mmcblk1: p1
> mmc0: ADMA error
> mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00002202
> mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
> mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> mmc0: sdhci: Present: 0x01f50008 | Host ctl: 0x00000038
> mmc0: sdhci: Power: 0x00000003 | Blk gap: 0x00000000
> mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x000080d8
> mmc0: sdhci: Timeout: 0x00000002 | Int stat: 0x00000001
> mmc0: sdhci: Int enab: 0x037f108f | Sig enab: 0x037f108b
> mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002202
> mmc0: sdhci: Caps: 0x35fa0000 | Caps_1: 0x0000af00
> mmc0: sdhci: Cmd: 0x0000333a | Max curr: 0x00000000
> mmc0: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x001d8a33
> mmc0: sdhci: Resp[2]: 0x325b5900 | Resp[3]: 0x3f400e00
> mmc0: sdhci: Host ctl2: 0x00000000
> mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236d43820c
> mmc0: sdhci: ============================================
> mmc0: error -5 whilst initialising SD card
> mmc0: ADMA error
> mmc0: sdhci: ============ SDHCI REGISTER DUMP ===========
> mmc0: sdhci: Sys addr: 0x00000000 | Version: 0x00002202
> mmc0: sdhci: Blk size: 0x00000008 | Blk cnt: 0x00000001
> mmc0: sdhci: Argument: 0x00000000 | Trn mode: 0x00000013
> mmc0: sdhci: Present: 0x01f50008 | Host ctl: 0x00000038
> mmc0: sdhci: Power: 0x00000003 | Blk gap: 0x00000000
> mmc0: sdhci: Wake-up: 0x00000000 | Clock: 0x000080f8
> mmc0: sdhci: Timeout: 0x00000002 | Int stat: 0x00000001
> mmc0: sdhci: Int enab: 0x037f108f | Sig enab: 0x037f108b
> mmc0: sdhci: ACmd stat: 0x00000000 | Slot int: 0x00002202
> mmc0: sdhci: Caps: 0x35fa0000 | Caps_1: 0x0000af00
> mmc0: sdhci: Cmd: 0x0000333a | Max curr: 0x00000000
> mmc0: sdhci: Resp[0]: 0x00000920 | Resp[1]: 0x001d8a33
> mmc0: sdhci: Resp[2]: 0x325b5900 | Resp[3]: 0x3f400e00
> mmc0: sdhci: Host ctl2: 0x00000000
> mmc0: sdhci: ADMA Err: 0x00000009 | ADMA Ptr: 0x000000236d43820c
> mmc0: sdhci: ============================================
> mmc0: error -5 whilst initialising SD card
>
> The platform has an iommu, which is in pass-through mode, via
> arm_smmu.disable_bypass=0.
>
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
> According to speedtest.net: 11.9Mbps down 500kbps up
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
_______________________________________________
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/7] clk: imx8m: Set CLK_GET_RATE_NOCACHE on dram_alt/apb
From: Leonard Crestez @ 2019-09-16 23:03 UTC (permalink / raw)
To: Stephen Boyd, Shawn Guo
Cc: Mark Rutland, Artur Świgoń, Jacky Bai, Viresh Kumar,
Michael Turquette, Alexandre Bailon, linux-clk@vger.kernel.org,
Abel Vesa, Saravana Kannan, Krzysztof Kozlowski, Chanwoo Choi,
MyungJoo Ham, dl-linux-imx, devicetree@vger.kernel.org,
linux-pm@vger.kernel.org, Rob Herring,
linux-arm-kernel@lists.infradead.org, Aisheng Dong, Anson Huang,
Kyungmin Park, kernel@pengutronix.de, Fabio Estevam,
Georgi Djakov
In-Reply-To: <20190916203312.CF8D02067B@mail.kernel.org>
On 2019-09-16 11:33 PM, Stephen Boyd wrote:
> Quoting Leonard Crestez (2019-08-20 08:45:06)
>> Dram frequency changes required modifying these clocks outside the
>> control of clk framework. Mark them as CLK_GET_RATE_NOCACHE so that
>> rates are always read back from registers.
>
> Why can't we control the clks from the clk framework? Please add that
> information in the commit text here.
OK, I will update commit message and comments
These clocks are only modified for DRAM frequency switches during which
DRAM is briefly inaccessible. The switch is performed with a SMC call to
by TF-A which runs from a SRAM area. Upon returning to linux several
clocks bits are modified and we need to update them.
For rate bits an easy solution is to just mark with
CLK_GET_RATE_NOCACHE, muxes are handled explicitly.
Linux code performing the SMC call is also part of this series:
https://patchwork.kernel.org/patch/11104145/
>> Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
>> ---
>> drivers/clk/imx/clk-imx8mm.c | 6 ++++--
>> drivers/clk/imx/clk-imx8mn.c | 6 ++++--
>> drivers/clk/imx/clk-imx8mq.c | 7 ++++---
>> 3 files changed, 12 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/clk/imx/clk-imx8mm.c b/drivers/clk/imx/clk-imx8mm.c
>> index 4ead3ea2713c..6cac80550f43 100644
>> --- a/drivers/clk/imx/clk-imx8mm.c
>> +++ b/drivers/clk/imx/clk-imx8mm.c
>> @@ -526,12 +526,14 @@ static int imx8mm_clocks_probe(struct platform_device *pdev)
>> /* IPG */
>> clks[IMX8MM_CLK_IPG_ROOT] = imx_clk_divider2("ipg_root", "ahb", base + 0x9080, 0, 1);
>> clks[IMX8MM_CLK_IPG_AUDIO_ROOT] = imx_clk_divider2("ipg_audio_root", "audio_ahb", base + 0x9180, 0, 1);
>>
>> /* IP */
>> - clks[IMX8MM_CLK_DRAM_ALT] = imx8m_clk_composite("dram_alt", imx8mm_dram_alt_sels, base + 0xa000);
>> - clks[IMX8MM_CLK_DRAM_APB] = imx8m_clk_composite_critical("dram_apb", imx8mm_dram_apb_sels, base + 0xa080);
>> + clks[IMX8MM_CLK_DRAM_ALT] = __imx8m_clk_composite("dram_alt", imx8mm_dram_alt_sels, base + 0xa000,
>> + CLK_GET_RATE_NOCACHE);
>> + clks[IMX8MM_CLK_DRAM_APB] = __imx8m_clk_composite("dram_apb", imx8mm_dram_apb_sels, base + 0xa080,
>> + CLK_IS_CRITICAL | CLK_GET_RATE_NOCACHE);
>
> Also, add a comment to this effect about why it can't be done from the
> clk framework wherever the CLK_GET_RATE_NOCACHE flag is set. Basically
> this flag is a hack and is an example of something that we need to fix.
DRAM freq switch requires multiple clk changes to be performed
atomically while DRAM itself is not accessible so it's not something to
"fix".
--
Regards,
Leonard
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [GIT PULL] arm64 updates for 5.4
From: pr-tracker-bot @ 2019-09-16 23:05 UTC (permalink / raw)
To: Will Deacon; +Cc: catalin.marinas, torvalds, linux-kernel, linux-arm-kernel
In-Reply-To: <20190913102014.vi4cwe6mifbsmrri@willie-the-truck>
The pull request you sent on Fri, 13 Sep 2019 11:20:15 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-upstream
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e77fafe9afb53b7f4d8176c5cd5c10c43a905bc8
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
_______________________________________________
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] input: keyboard: snvs_pwrkey: Send key events for i.MX6 S, DL and Q
From: Dmitry Torokhov @ 2019-09-16 23:37 UTC (permalink / raw)
To: Robin Gong
Cc: robin, Marco Felsch, linux-kernel @ vger . kernel . org,
Pengutronix Kernel Team, linux-input @ vger . kernel . org,
Adam Ford, Shawn Guo, linux-arm-kernel @ lists . infradead . org
In-Reply-To: <VE1PR04MB663896B94C68B5EF9AE0BE36898C0@VE1PR04MB6638.eurprd04.prod.outlook.com>
On Mon, Sep 16, 2019 at 07:45:37AM +0000, Robin Gong wrote:
> On 2019/9/13 15:31 robin <robin@protonic.nl> wrote:>
> > Hi Dmitry,
> >
> > On 2019-09-12 22:13, Dmitry Torokhov wrote:
> > > Hi Robin,
> > >
> > > On Wed, Sep 04, 2019 at 06:23:29AM +0000, Robin van der Gracht wrote:
> > >> The first generation i.MX6 processors does not send an interrupt when
> > >> the power key is pressed. It sends a power down request interrupt if
> > >> the key is released before a hard shutdown (5 second press). This
> > >> should allow software to bring down the SoC safely.
> > >>
> > >> For this driver to work as a regular power key with the older SoCs,
> > >> we need to send a keypress AND release when we get the power down
> > >> request irq.
> > >>
> > >> Signed-off-by: Robin van der Gracht <robin@protonic.nl>
> > >> ---
> > >> @@ -67,13 +83,17 @@ static irqreturn_t imx_snvs_pwrkey_interrupt(int
> > >> irq, void *dev_id) {
> > >> struct platform_device *pdev = dev_id;
> > >> struct pwrkey_drv_data *pdata = platform_get_drvdata(pdev);
> > >> + unsigned long expire = jiffies;
> > >> u32 lp_status;
> > >>
> > >> pm_wakeup_event(pdata->input->dev.parent, 0);
> > >>
> > >> regmap_read(pdata->snvs, SNVS_LPSR_REG, &lp_status);
> > >> - if (lp_status & SNVS_LPSR_SPO)
> > >> - mod_timer(&pdata->check_timer, jiffies +
> > >> msecs_to_jiffies(DEBOUNCE_TIME));
> > >> + if (lp_status & SNVS_LPSR_SPO) {
> > >> + if (pdata->minor_rev > 0)
> > >> + expire = jiffies + msecs_to_jiffies(DEBOUNCE_TIME);
> > >> + mod_timer(&pdata->check_timer, expire);
> > >
> > > Why do we even need to fire the timer in case of the first generation
> > > hardware? Just send press and release events directly from the ISR.
> That timer looks like a software debounce to prevent unexpected and
> meaningless interrupt/event caused by quick press/release.
Right, but in case of the first generation hardware we schedule the
timer immediately (expire == 0) and do not check state of the hardware
in the timer handler, but rather simply emit down/up events, so we do
not really get any benefit from the timer (again, I am talking about
first generation hardware only).
Thanks.
--
Dmitry
_______________________________________________
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 V4 2/5] input: keyboard: imx_sc: Add i.MX system controller key support
From: Dmitry Torokhov @ 2019-09-16 23:53 UTC (permalink / raw)
To: Anson Huang
Cc: mark.rutland, ulf.hansson, ping.bai, catalin.marinas, peng.fan,
stefan, bjorn.andersson, leonard.crestez, will, festevam,
yuehaibing, marcin.juszkiewicz, cw00.choi, jagan, linux-input,
ronald, Linux-imx, devicetree, arnd, s.hauer, mripard, m.felsch,
enric.balletbo, robh+dt, andriy.shevchenko, daniel.baluta,
linux-arm-kernel, aisheng.dong, fugang.duan, linux-kernel,
dinguyen, kernel, olof, shawnguo
In-Reply-To: <1568602373-14164-2-git-send-email-Anson.Huang@nxp.com>
On Mon, Sep 16, 2019 at 10:52:50AM +0800, Anson Huang wrote:
> i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> inside, the system controller is in charge of controlling power,
> clock and scu key etc..
>
> Adds i.MX system controller key driver support, Linux kernel has
> to communicate with system controller via MU (message unit) IPC
> to get scu key's status.
>
> Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> ---
> Changes since V3:
> - switch the debounce and repeat interval time for delay work schdule;
> - add .remove to handle group irq and notify etc..
> ---
> drivers/input/keyboard/Kconfig | 7 ++
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/imx_sc_key.c | 190 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 198 insertions(+)
> create mode 100644 drivers/input/keyboard/imx_sc_key.c
>
> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
> index 8911bc2..00f8428 100644
> --- a/drivers/input/keyboard/Kconfig
> +++ b/drivers/input/keyboard/Kconfig
> @@ -469,6 +469,13 @@ config KEYBOARD_IMX
> To compile this driver as a module, choose M here: the
> module will be called imx_keypad.
>
> +config KEYBOARD_IMX_SC_KEY
> + tristate "IMX SCU Key Driver"
> + depends on IMX_SCU
> + help
> + This is the system controller key driver for NXP i.MX SoCs with
> + system controller inside.
> +
> config KEYBOARD_NEWTON
> tristate "Newton keyboard"
> select SERIO
> diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
> index 9510325..f5b1752 100644
> --- a/drivers/input/keyboard/Makefile
> +++ b/drivers/input/keyboard/Makefile
> @@ -29,6 +29,7 @@ obj-$(CONFIG_KEYBOARD_HIL) += hil_kbd.o
> obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
> obj-$(CONFIG_KEYBOARD_IPAQ_MICRO) += ipaq-micro-keys.o
> obj-$(CONFIG_KEYBOARD_IMX) += imx_keypad.o
> +obj-$(CONFIG_KEYBOARD_IMX_SC_KEY) += imx_sc_key.o
> obj-$(CONFIG_KEYBOARD_HP6XX) += jornada680_kbd.o
> obj-$(CONFIG_KEYBOARD_HP7XX) += jornada720_kbd.o
> obj-$(CONFIG_KEYBOARD_LKKBD) += lkkbd.o
> diff --git a/drivers/input/keyboard/imx_sc_key.c b/drivers/input/keyboard/imx_sc_key.c
> new file mode 100644
> index 0000000..59c68fa
> --- /dev/null
> +++ b/drivers/input/keyboard/imx_sc_key.c
> @@ -0,0 +1,190 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2019 NXP.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/firmware/imx/sci.h>
> +#include <linux/init.h>
> +#include <linux/input.h>
> +#include <linux/interrupt.h>
> +#include <linux/jiffies.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/platform_device.h>
> +
> +#define DEBOUNCE_TIME 100
> +#define REPEAT_INTERVAL 60
> +
> +#define SC_IRQ_BUTTON 1
> +#define SC_IRQ_GROUP_WAKE 3
> +#define IMX_SC_MISC_FUNC_GET_BUTTON_STATUS 18
> +
> +struct imx_key_drv_data {
> + int keycode;
> + bool keystate; /* 1: pressed, 0: release */
> + bool delay_check;
> + struct delayed_work check_work;
> + struct input_dev *input;
> + struct imx_sc_ipc *key_ipc_handle;
> + struct notifier_block key_notifier;
> +};
> +
> +struct imx_sc_msg_key {
> + struct imx_sc_rpc_msg hdr;
> + u8 state;
> +};
> +
> +static int imx_sc_key_notify(struct notifier_block *nb,
> + unsigned long event, void *group)
> +{
> + struct imx_key_drv_data *priv =
> + container_of(nb,
> + struct imx_key_drv_data,
> + key_notifier);
> +
> + if ((event & SC_IRQ_BUTTON) && (*(u8 *)group == SC_IRQ_GROUP_WAKE)
> + && !priv->delay_check) {
> + priv->delay_check = 1;
> + schedule_delayed_work(&priv->check_work,
> + msecs_to_jiffies(DEBOUNCE_TIME));
If I am reading this right, you are trying to avoid scheduling the work
again if it is already scheduled. You do not need to do that, as
schedule_delayed_work() will take care of that (if you want to make sure
the work is re-scheduled with updated expiration, you need to use
mod_delayed_work).
> + }
> +
> + return 0;
> +}
> +
> +static void imx_sc_check_for_events(struct work_struct *work)
> +{
> + struct imx_key_drv_data *priv =
> + container_of(work,
> + struct imx_key_drv_data,
> + check_work.work);
> + struct input_dev *input = priv->input;
> + struct imx_sc_msg_key msg;
> + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> + bool state;
> + int ret;
> +
> + hdr->ver = IMX_SC_RPC_VERSION;
> + hdr->svc = IMX_SC_RPC_SVC_MISC;
> + hdr->func = IMX_SC_MISC_FUNC_GET_BUTTON_STATUS;
> + hdr->size = 1;
> +
> + ret = imx_scu_call_rpc(priv->key_ipc_handle, &msg, true);
> + if (ret) {
> + dev_err(&input->dev, "read imx sc key failed, ret %d\n", ret);
> + return;
> + }
> +
> + state = (bool)msg.state;
> +
> + if (!state && !priv->keystate)
> + state = true;
This needs an explanation please.
> +
> + if (state ^ priv->keystate) {
> + pm_wakeup_event(input->dev.parent, 0);
I'd expect this happening in imx_sc_key_notify() so that the device
would have a change to run this work.
> + priv->keystate = state;
> + input_event(input, EV_KEY, priv->keycode, state);
> + input_sync(input);
> + if (!state)
> + priv->delay_check = 0;
> + pm_relax(priv->input->dev.parent);
Are you sure you want to call pm_relax() unconditionally, and not when
state == false (i.e. button released)?
> + }
> +
> + if (state)
> + schedule_delayed_work(&priv->check_work,
> + msecs_to_jiffies(REPEAT_INTERVAL));
> +}
> +
> +static int imx_sc_key_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + static struct imx_key_drv_data *priv;
> + struct input_dev *input;
> + int ret;
> +
> + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + ret = imx_scu_get_handle(&priv->key_ipc_handle);
> + if (ret)
> + return ret;
> +
> + if (of_property_read_u32(np, "linux,keycode", &priv->keycode)) {
> + dev_err(&pdev->dev, "missing KEY_POWER in DT\n");
> + return -EINVAL;
> + }
> +
> + INIT_DELAYED_WORK(&priv->check_work, imx_sc_check_for_events);
> +
> + input = devm_input_allocate_device(&pdev->dev);
> + if (!input) {
> + dev_err(&pdev->dev, "failed to allocate the input device\n");
> + return -ENOMEM;
> + }
> +
> + input->name = pdev->name;
> + input->phys = "imx-sc-key/input0";
> + input->id.bustype = BUS_HOST;
> +
> + input_set_capability(input, EV_KEY, priv->keycode);
> +
> + ret = input_register_device(input);
> + if (ret) {
Could you please rename this (and elsewhere) from 'ret' to 'error'?
> + dev_err(&pdev->dev, "failed to register input device\n");
> + return ret;
> + }
> +
> + priv->input = input;
> + platform_set_drvdata(pdev, priv);
> +
> + ret = imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE, SC_IRQ_BUTTON, true);
> + if (ret) {
> + dev_warn(&pdev->dev, "enable scu group irq failed\n");
> + return ret;
> + }
> +
> + priv->key_notifier.notifier_call = imx_sc_key_notify;
> + ret = imx_scu_irq_register_notifier(&priv->key_notifier);
> + if (ret) {
> + imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE, SC_IRQ_BUTTON, false);
> + dev_warn(&pdev->dev, "register scu notifier failed\n");
return error;
> + }
> +
> + return ret;
return 0;
> +}
> +
> +static int imx_sc_key_remove(struct platform_device *pdev)
> +{
> + struct imx_key_drv_data *priv = platform_get_drvdata(pdev);
> +
> + imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE, SC_IRQ_BUTTON, false);
> + imx_scu_irq_unregister_notifier(&priv->key_notifier);
> + cancel_delayed_work_sync(&priv->check_work);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id imx_sc_key_ids[] = {
> + { .compatible = "fsl,imx-sc-key" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, imx_sc_key_ids);
> +
> +static struct platform_driver imx_sc_key_driver = {
> + .driver = {
> + .name = "imx-sc-key",
> + .of_match_table = imx_sc_key_ids,
> + },
> + .probe = imx_sc_key_probe,
> + .remove = imx_sc_key_remove,
> +};
> +module_platform_driver(imx_sc_key_driver);
> +
> +MODULE_AUTHOR("Anson Huang <Anson.Huang@nxp.com>");
> +MODULE_DESCRIPTION("i.MX System Controller Key Driver");
> +MODULE_LICENSE("GPL v2");
> --
> 2.7.4
>
Thanks.
--
Dmitry
_______________________________________________
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/6] ARM, arm64: Remove arm_pm_restart()
From: Alexandre Belloni @ 2019-09-17 0:41 UTC (permalink / raw)
To: Thierry Reding
Cc: Guenter Roeck, Linux ARM, Arnd Bergmann,
linux-kernel@vger.kernel.org
In-Reply-To: <20190916202809.GA42800@mithrandir>
Hi Thierry,
On 16/09/2019 22:28:09+0200, Thierry Reding wrote:
> > > Yeah, I can just send the pull request for the 6 patches after -rc1.
> >
> > Ok, sounds good. I'm also happy to take the remaining patches
> > in that branch, for the other architectures.
>
> All of the patches beyond the 6 in this set rely on the system reset and
> power "framework". I don't think there was broad concensus on that idea
> yet. If you think it's worth another try I'm happy to send the patches
> out again.
>
Could you consider converting the RTC drivers too? The ones used for
poweroff are:
drivers/rtc/rtc-ds1685.c
drivers/rtc/rtc-jz4740.c
drivers/rtc/rtc-omap.c
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.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: page_alloc.shuffle=1 + CONFIG_PROVE_LOCKING=y = arm64 hang
From: Sergey Senozhatsky @ 2019-09-17 0:53 UTC (permalink / raw)
To: Steven Rostedt
Cc: Petr Mladek, Theodore Ts'o, Sergey Senozhatsky, Arnd Bergmann,
Peter Zijlstra, Catalin Marinas, linux-kernel, linux-mm, Qian Cai,
Greg Kroah-Hartman, Waiman Long, Dan Williams, Will Deacon,
Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20190916104239.124fc2e5@gandalf.local.home>
On (09/16/19 10:42), Steven Rostedt wrote:
[..]
> >
> > This will also fix the hang.
> >
> > Sergey, do you plan to submit this Ted?
>
> Perhaps for a quick fix (and a comment that says this needs to be fixed
> properly).
I guess it would make sense, since LTS and -stable kernels won't get new
printk().
-ss
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [breakage] panic() does not halt arm64 systems under certain conditions
From: Xogium @ 2019-09-17 1:35 UTC (permalink / raw)
To: linux-arm-kernel; +Cc: Will Deacon
On arm64 in some situations userspace will continue running even after a panic. This means any userspace watchdog daemon will continue pinging, that service
managers will keep running and displaying messages in certain cases, and that it is possible to enter via ssh in the now unstable system and to do almost
anything except reboot/power off and etc. If CONFIG_PREEMPT=n is set in the kernel's configuration, the issue is fixed. I have reproduced the very same behavior
with linux 4.19, 5.2 and 5.3. On x86/x86_64 the issue does not seem to be present at all. Also, kernels without commit 8341f2f222d729688014ce8306727fdb9798d37e
don't trigger a broken panic using 'echo c > /proc/sysrq-trigger', instead they call die() through the memory manager which works as intended, because it causes
an oops which ends in a panic, and don't call the panic() function directly. By patching the poweroff sysrq-trigger to panic i can confirm the issue is
definitely present in kernel 4.19 on qemu. On actual hardware I used a marvell ESPRESSOBin with linux 5.2.14. The issue seemed to be quite random at first, but
it can be triggered 100% of the time by adding nosmp on the kernel command line. Also if e.g: panic=30 is added on the kernel command line, the problem is also
worked around and disappears entirely, using nosmp or not.
The easiest way to reproduce this is using qemu and this initramfs containing busybox and the following init script:
#!/bin/sh
busybox mkdir /proc
busybox mount -t proc none /proc
# Launch some programs to run in the background
while true; do echo "Ping 1!"; busybox sleep 1; done >/dev/console&
while true; do echo "Ping 2!"; busybox sleep 2; done >/dev/console&
echo c > /proc/sysrq-trigger
# Nothing should be running from here on out
echo "Running a shell now!"
exec busybox sh
A copy of the initramfs and a 5.2 arm64 defconfig kernel can be found at:
http://novena.jookia.org/arm64bug/mycpio
http://novena.jookia.org/arm64bug/Image
You can run it in qemu using:
qemu-system-aarch64 -machine virt-4.0 -cpu cortex-a53 -m 256 -kernel Image -initrd mycpio -nographic
As an example, running it with linux 5.2.15 with the arm64 defconfig in qemu gives this:
[ 1.841502] Run /init as init process
[ 1.970386] sysrq: Trigger a crash
[ 1.970967] Kernel panic - not syncing: sysrq triggered crash
[ 1.971693] CPU: 0 PID: 1 Comm: init Not tainted 5.2.15 #1
[ 1.972096] Hardware name: linux,dummy-virt (DT)
[ 1.972661] Call trace:
[ 1.972919] dump_backtrace+0x0/0x148
[ 1.973271] show_stack+0x14/0x20
[ 1.973472] dump_stack+0xa0/0xc4
[ 1.973699] panic+0x140/0x32c
[ 1.973897] sysrq_handle_reboot+0x0/0x20
[ 1.974161] __handle_sysrq+0x124/0x190
[ 1.974422] write_sysrq_trigger+0x64/0x88
[ 1.974715] proc_reg_write+0x60/0xa8
[ 1.974973] __vfs_write+0x18/0x40
[ 1.975224] vfs_write+0xa4/0x1b8
[ 1.975474] ksys_write+0x64/0xf0
[ 1.975739] __arm64_sys_write+0x14/0x20
[ 1.976021] el0_svc_common.constprop.0+0xb0/0x168
[ 1.976375] el0_svc_handler+0x28/0x78
[ 1.976661] el0_svc+0x8/0xc
[ 1.977383] Kernel Offset: disabled
[ 1.977895] CPU features: 0x0002,24002004
[ 1.978241] Memory Limit: none
[ 1.979169] ---[ end Kernel panic - not syncing: sysrq triggered crash ]---
Ping 2!
Ping 1!
Ping 1!
Ping 2!
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Question-GIC-v4.1] Plan on GIC-v4.1 driver development
From: Shaokun Zhang @ 2019-09-17 2:15 UTC (permalink / raw)
To: linux-arm-kernel, kvmarm; +Cc: Marc Zyngier, Tangnianyao (ICT)
Hi Marc,
This is from Nianyao Tang.
I'm planning to do some verification on our GIC-v4.1 implement. I would like some
information about linux GIC-v4.1 driver. When will linux support GIC-v4.1 or what's
the plan on developing GIC-v4.1 driver?
Thanks,
Nianyao.
_______________________________________________
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 v6 1/3] PM: wakeup: Add routine to help fetch wakeup source object.
From: Ran Wang @ 2019-09-17 2:33 UTC (permalink / raw)
To: Rafael J . Wysocki, Leo Li, Rob Herring, Mark Rutland,
Pavel Machek
Cc: Biwen Li, Len Brown, Greg Kroah-Hartman, linux-pm@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
Ran Wang, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <20190821031537.46824-1-ran.wang_1@nxp.com>
Hi Rafael,
On Wednesday, August 21, 2019 11:16, Ran Wang wrote:
>
> Some user might want to go through all registered wakeup sources and doing
> things accordingly. For example, SoC PM driver might need to do HW
> programming to prevent powering down specific IP which wakeup source
> depending on. So add this API to help walk through all registered wakeup source
> objects on that list and return them one by one.
>
> Signed-off-by: Ran Wang <ran.wang_1@nxp.com>
> ---
> Change in v6:
> - Add wakeup_source_get_star() and wakeup_source_get_stop() to
> aligned
> with wakeup_sources_stats_seq_start/nex/stop.
How about this version, could you please give any comment? Thanks.
Regards,
Ran
<snip>
_______________________________________________
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 V4 2/5] input: keyboard: imx_sc: Add i.MX system controller key support
From: Anson Huang @ 2019-09-17 2:42 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: mark.rutland@arm.com, ulf.hansson@linaro.org, Jacky Bai,
catalin.marinas@arm.com, Peng Fan, stefan@agner.ch,
bjorn.andersson@linaro.org, Leonard Crestez, will@kernel.org,
festevam@gmail.com, yuehaibing@huawei.com,
marcin.juszkiewicz@linaro.org, cw00.choi@samsung.com,
jagan@amarulasolutions.com, linux-input@vger.kernel.org,
ronald@innovation.ch, dl-linux-imx, devicetree@vger.kernel.org,
arnd@arndb.de, s.hauer@pengutronix.de, mripard@kernel.org,
m.felsch@pengutronix.de, enric.balletbo@collabora.com,
robh+dt@kernel.org, andriy.shevchenko@linux.intel.com,
Daniel Baluta, linux-arm-kernel@lists.infradead.org, Aisheng Dong,
Andy Duan, linux-kernel@vger.kernel.org, dinguyen@kernel.org,
kernel@pengutronix.de, olof@lixom.net, shawnguo@kernel.org
In-Reply-To: <20190916235330.GI237523@dtor-ws>
Hi, Dmitry
> On Mon, Sep 16, 2019 at 10:52:50AM +0800, Anson Huang wrote:
> > i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> > inside, the system controller is in charge of controlling power, clock
> > and scu key etc..
> >
> > Adds i.MX system controller key driver support, Linux kernel has to
> > communicate with system controller via MU (message unit) IPC to get
> > scu key's status.
> >
> > Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
> > ---
> > Changes since V3:
> > - switch the debounce and repeat interval time for delay work
> schdule;
> > - add .remove to handle group irq and notify etc..
> > ---
> > drivers/input/keyboard/Kconfig | 7 ++
> > drivers/input/keyboard/Makefile | 1 +
> > drivers/input/keyboard/imx_sc_key.c | 190
> > ++++++++++++++++++++++++++++++++++++
> > 3 files changed, 198 insertions(+)
> > create mode 100644 drivers/input/keyboard/imx_sc_key.c
> >
> > diff --git a/drivers/input/keyboard/Kconfig
> > b/drivers/input/keyboard/Kconfig index 8911bc2..00f8428 100644
> > --- a/drivers/input/keyboard/Kconfig
> > +++ b/drivers/input/keyboard/Kconfig
> > @@ -469,6 +469,13 @@ config KEYBOARD_IMX
> > To compile this driver as a module, choose M here: the
> > module will be called imx_keypad.
> >
> > +config KEYBOARD_IMX_SC_KEY
> > + tristate "IMX SCU Key Driver"
> > + depends on IMX_SCU
> > + help
> > + This is the system controller key driver for NXP i.MX SoCs with
> > + system controller inside.
> > +
> > config KEYBOARD_NEWTON
> > tristate "Newton keyboard"
> > select SERIO
> > diff --git a/drivers/input/keyboard/Makefile
> > b/drivers/input/keyboard/Makefile index 9510325..f5b1752 100644
> > --- a/drivers/input/keyboard/Makefile
> > +++ b/drivers/input/keyboard/Makefile
> > @@ -29,6 +29,7 @@ obj-$(CONFIG_KEYBOARD_HIL) += hil_kbd.o
> > obj-$(CONFIG_KEYBOARD_HIL_OLD) += hilkbd.o
> > obj-$(CONFIG_KEYBOARD_IPAQ_MICRO) += ipaq-micro-keys.o
> > obj-$(CONFIG_KEYBOARD_IMX) += imx_keypad.o
> > +obj-$(CONFIG_KEYBOARD_IMX_SC_KEY) += imx_sc_key.o
> > obj-$(CONFIG_KEYBOARD_HP6XX) += jornada680_kbd.o
> > obj-$(CONFIG_KEYBOARD_HP7XX) += jornada720_kbd.o
> > obj-$(CONFIG_KEYBOARD_LKKBD) += lkkbd.o
> > diff --git a/drivers/input/keyboard/imx_sc_key.c
> > b/drivers/input/keyboard/imx_sc_key.c
> > new file mode 100644
> > index 0000000..59c68fa
> > --- /dev/null
> > +++ b/drivers/input/keyboard/imx_sc_key.c
> > @@ -0,0 +1,190 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright 2019 NXP.
> > + */
> > +
> > +#include <linux/device.h>
> > +#include <linux/err.h>
> > +#include <linux/firmware/imx/sci.h>
> > +#include <linux/init.h>
> > +#include <linux/input.h>
> > +#include <linux/interrupt.h>
> > +#include <linux/jiffies.h>
> > +#include <linux/kernel.h>
> > +#include <linux/module.h>
> > +#include <linux/of.h>
> > +#include <linux/of_address.h>
> > +#include <linux/platform_device.h>
> > +
> > +#define DEBOUNCE_TIME 100
> > +#define REPEAT_INTERVAL 60
> > +
> > +#define SC_IRQ_BUTTON 1
> > +#define SC_IRQ_GROUP_WAKE 3
> > +#define IMX_SC_MISC_FUNC_GET_BUTTON_STATUS 18
> > +
> > +struct imx_key_drv_data {
> > + int keycode;
> > + bool keystate; /* 1: pressed, 0: release */
> > + bool delay_check;
> > + struct delayed_work check_work;
> > + struct input_dev *input;
> > + struct imx_sc_ipc *key_ipc_handle;
> > + struct notifier_block key_notifier;
> > +};
> > +
> > +struct imx_sc_msg_key {
> > + struct imx_sc_rpc_msg hdr;
> > + u8 state;
> > +};
> > +
> > +static int imx_sc_key_notify(struct notifier_block *nb,
> > + unsigned long event, void *group) {
> > + struct imx_key_drv_data *priv =
> > + container_of(nb,
> > + struct imx_key_drv_data,
> > + key_notifier);
> > +
> > + if ((event & SC_IRQ_BUTTON) && (*(u8 *)group ==
> SC_IRQ_GROUP_WAKE)
> > + && !priv->delay_check) {
> > + priv->delay_check = 1;
> > + schedule_delayed_work(&priv->check_work,
> > + msecs_to_jiffies(DEBOUNCE_TIME));
>
> If I am reading this right, you are trying to avoid scheduling the work again if
> it is already scheduled. You do not need to do that, as
> schedule_delayed_work() will take care of that (if you want to make sure the
> work is re-scheduled with updated expiration, you need to use
> mod_delayed_work).
The original code here is to skip the event of button release, try to ONLY handle the press interrupt, the release
event is handled by busy loop check, but I double check the SCU FW's behavior, it does NOT send out interrupt
for button release event at all, so it is NOT needed any more, I will remove the priv->delay_check completely in this driver.
>
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void imx_sc_check_for_events(struct work_struct *work) {
> > + struct imx_key_drv_data *priv =
> > + container_of(work,
> > + struct imx_key_drv_data,
> > + check_work.work);
> > + struct input_dev *input = priv->input;
> > + struct imx_sc_msg_key msg;
> > + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> > + bool state;
> > + int ret;
> > +
> > + hdr->ver = IMX_SC_RPC_VERSION;
> > + hdr->svc = IMX_SC_RPC_SVC_MISC;
> > + hdr->func = IMX_SC_MISC_FUNC_GET_BUTTON_STATUS;
> > + hdr->size = 1;
> > +
> > + ret = imx_scu_call_rpc(priv->key_ipc_handle, &msg, true);
> > + if (ret) {
> > + dev_err(&input->dev, "read imx sc key failed, ret %d\n", ret);
> > + return;
> > + }
> > +
> > + state = (bool)msg.state;
> > +
> > + if (!state && !priv->keystate)
> > + state = true;
>
> This needs an explanation please.
This is to handle the quick press of button, e.g., when button is pressed and released very quickly,
when the delay work is scheduled, the button state read from SCU FW is actually a release state (0),
the press state is (1), so the quick press/release will be ignored.
However, after double check and test, I think this should be handled by debounce time, if the button is pressed/release
very quickly, the event should be ignored, I will remove it and reduce the debounce time to 30mS, previous 100mS
is too long, using 30mS as debounce time, I did NOT see similar issue no matter how quick I press/release the button.
>
> > +
> > + if (state ^ priv->keystate) {
> > + pm_wakeup_event(input->dev.parent, 0);
>
> I'd expect this happening in imx_sc_key_notify() so that the device would
> have a change to run this work.
Agreed, will move it to the imx_sc_key_notify().
>
> > + priv->keystate = state;
> > + input_event(input, EV_KEY, priv->keycode, state);
> > + input_sync(input);
> > + if (!state)
> > + priv->delay_check = 0;
> > + pm_relax(priv->input->dev.parent);
>
> Are you sure you want to call pm_relax() unconditionally, and not when state
> == false (i.e. button released)?
Agreed, will make sure ONLY call it when button is released which indicates the event
is finished.
>
> > + }
> > +
> > + if (state)
> > + schedule_delayed_work(&priv->check_work,
> > + msecs_to_jiffies(REPEAT_INTERVAL));
> > +}
> > +
> > +static int imx_sc_key_probe(struct platform_device *pdev) {
> > + struct device_node *np = pdev->dev.of_node;
> > + static struct imx_key_drv_data *priv;
> > + struct input_dev *input;
> > + int ret;
> > +
> > + priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + ret = imx_scu_get_handle(&priv->key_ipc_handle);
> > + if (ret)
> > + return ret;
> > +
> > + if (of_property_read_u32(np, "linux,keycode", &priv->keycode)) {
> > + dev_err(&pdev->dev, "missing KEY_POWER in DT\n");
> > + return -EINVAL;
> > + }
> > +
> > + INIT_DELAYED_WORK(&priv->check_work,
> imx_sc_check_for_events);
> > +
> > + input = devm_input_allocate_device(&pdev->dev);
> > + if (!input) {
> > + dev_err(&pdev->dev, "failed to allocate the input device\n");
> > + return -ENOMEM;
> > + }
> > +
> > + input->name = pdev->name;
> > + input->phys = "imx-sc-key/input0";
> > + input->id.bustype = BUS_HOST;
> > +
> > + input_set_capability(input, EV_KEY, priv->keycode);
> > +
> > + ret = input_register_device(input);
> > + if (ret) {
>
> Could you please rename this (and elsewhere) from 'ret' to 'error'?
OK.
>
> > + dev_err(&pdev->dev, "failed to register input device\n");
> > + return ret;
> > + }
> > +
> > + priv->input = input;
> > + platform_set_drvdata(pdev, priv);
> > +
> > + ret = imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE,
> SC_IRQ_BUTTON, true);
> > + if (ret) {
> > + dev_warn(&pdev->dev, "enable scu group irq failed\n");
> > + return ret;
> > + }
> > +
> > + priv->key_notifier.notifier_call = imx_sc_key_notify;
> > + ret = imx_scu_irq_register_notifier(&priv->key_notifier);
> > + if (ret) {
> > + imx_scu_irq_group_enable(SC_IRQ_GROUP_WAKE,
> SC_IRQ_BUTTON, false);
> > + dev_warn(&pdev->dev, "register scu notifier failed\n");
>
> return error;
> > + }
> > +
> > + return ret;
>
> return 0;
OK.
Thanks,
Anson.
_______________________________________________
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