* Re: [PATCH 3/9] dt-bindings: crypto: Add DT bindings documentation for sun8i-ce Crypto Engine
From: Maxime Ripard @ 2019-09-12 9:37 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, devicetree, herbert, linux-sunxi, linux,
linux-kernel, wens, robh+dt, linux-crypto, davem,
linux-arm-kernel
In-Reply-To: <20190911183158.GA8264@Red>
[-- Attachment #1.1: Type: text/plain, Size: 2452 bytes --]
Hi Corentin,
On Wed, Sep 11, 2019 at 08:31:58PM +0200, Corentin Labbe wrote:
> On Sat, Sep 07, 2019 at 07:01:16AM +0300, Maxime Ripard wrote:
> > On Fri, Sep 06, 2019 at 08:45:45PM +0200, Corentin Labbe wrote:
> > > This patch adds documentation for Device-Tree bindings for the
> > > Crypto Engine cryptographic accelerator driver.
> > >
> > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > ---
> > > .../bindings/crypto/allwinner,sun8i-ce.yaml | 84 +++++++++++++++++++
> > > 1 file changed, 84 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
> [...]
> > > +else:
> > > + clocks:
> > > + items:
> > > + - description: Bus clock
> > > + - description: Module clock
> > > +
> > > + clock-names:
> > > + items:
> > > + - const: ahb
> > > + - const: mod
> > > +
> > > + resets:
> > > + maxItems: 1
> > > +
> > > + reset-names:
> > > + const: ahb
> >
> > This prevents the usage of the additionalProperties property, which
> > you should really use.
> >
> > What you can do instead is moving the clocks and clock-names
> > description under properties, with a minItems of 2 and a maxItems of
> > 3. Then you can restrict the length of that property to either 2 or 3
> > depending on the case here.
> >
>
> Hello
>
> I fail to do this.
> I do the following (keeped only clock stuff)
> properties:
>
> clocks:
> items:
> - description: Bus clock
> - description: Module clock
> - description: MBus clock
Add minItems: 2 and maxItems: 3 at the same level than items
>
> clock-names:
> items:
> - const: ahb
> - const: mod
> - const: mbus
And here as well
Something I missed earlier though was that we've tried to unify as
much as possible the ahb / apb / axi clocks around the bus name, it
would be great if you could do it.
>
> if:
> properties:
> compatible:
> items:
> const: allwinner,sun50i-h6-crypto
> then:
> properties:
> clocks:
> minItems: 3
> maxItems: 3
> clock-names:
> minItems: 3
> maxItems: 3
You don't need to duplicate the min and maxItems here
Maxime
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: FYI: imx-sdma firmware is not compatible with SLUB slab allocator
From: Jurgen Lambrecht @ 2019-09-12 9:45 UTC (permalink / raw)
To: Robin Gong, Leonard Crestez, Fabio Estevam
Cc: Aisheng Dong, dl-linux-imx, linux-arm-kernel@lists.infradead.org,
u.kleine-koenig@pengutronix.de
In-Reply-To: <VE1PR04MB66385122B55060CE7919014D89B00@VE1PR04MB6638.eurprd04.prod.outlook.com>
On 9/12/19 4:06 AM, Robin Gong wrote:
> On 2019-9-3 22:32 Jurgen Lambrecht <J.Lambrecht@TELEVIC.com> wrote
>> On 9/3/19 7:57 AM, Robin Gong wrote:
>>
>>> On 2019-8-29 14:24, Jurgen Lambrecht wrote:
>>>> On 8/28/19 4:05 PM, Robin Gong wrote:
>>>>> Could you help check if below commit in your side?
>>>>> commit ebb853b1bd5f659b92c71dc6a9de44cfc37c78c0
>>>>> Author: Lucas Stach<l.stach@pengutronix.de>
>>>>> Date: Tue Nov 6 03:40:28 2018 +0000
>>>> yes, it's in.
>>>>
>>>> Also the 2 follow-up commits of Lucas Stach:
>>>> 9063f5a99ea76f85935e3e453422d15e7be89b9e and
>>>> 374f384bc66f7a928f11eb20c0518f0f3fc1ffd6.
>> I had also already cherry picked your commit
>> 3f5de4c7e16164a344a905649f08e8a90a68ff9f "dmaengine: imx-sdma:
>> remove BD_INTR for channel0".
>>
>> But also then kernel hangs at loading sdma FW.
>>
>> (this looked the most interesting commit)
> I identified this issue which caused by SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
> (41)exceed the structure sdma_script_start_addrs(40) so that illegal memory
> touch, such as slob block header, thus kernel trap into while() loop forever
> in slob_free(). Please see the below code piece in sdma_add_scripts().
> for (i = 0; i < sdma->script_number; i++)
> if (addr_arr[i] > 0)
> saddr_arr[i] = addr_arr[i];
> That issue was brought by commit a572460be9cf (dmaengine: imx-sdma:
> Add support for version 3 firmware) because the SDMA_SCRIPT_ADDRS_ARRAY_SIZE_V3
> (38->41 3 scripts added) not align with script number added in
> sdma_script_start_addrs(2 scripts). Please have a try with
> the below patch:
> diff --git a/include/linux/platform_data/dma-imx-sdma.h b/include/linux/platform_data/dma-imx-sdma.h
> index 6eaa53c..30e676b 100644
> --- a/include/linux/platform_data/dma-imx-sdma.h
> +++ b/include/linux/platform_data/dma-imx-sdma.h
> @@ -51,7 +51,10 @@ struct sdma_script_start_addrs {
> /* End of v2 array */
> s32 zcanfd_2_mcu_addr;
> s32 zqspi_2_mcu_addr;
> + s32 mcu_2_ecspi_addr;
> /* End of v3 array */
> + s32 mcu_2_zqspi_addr;
> + /* End of v4 array */
> };
>
Yes, this patch solves it! I can now use SLOB slab allocator. I tried
several reboots and power cycles.
I tried with different dts (without earlycon, without sdma on uart and
ecspi).
I did not try other kernels, only 4.19.66+fscl with our patches and sdma
v3.5 built-in.
Thanks and also thanks Uwe for analyzing the assembly,
Jürgen
_______________________________________________
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/4] Cleanup arm64 driver dependencies
From: Mark Brown @ 2019-09-12 9:46 UTC (permalink / raw)
To: Amit Kucheria
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, linux-pm, linux-clk, linux-kernel, linux-pci,
Kishon Vijay Abraham I, Bartosz Golaszewski, arm, linux-gpio,
Sebastian Reichel, Will Deacon, Michael Turquette,
linux-arm-kernel
In-Reply-To: <cover.1568239378.git.amit.kucheria@linaro.org>
[-- Attachment #1.1: Type: text/plain, Size: 645 bytes --]
On Thu, Sep 12, 2019 at 03:48:44AM +0530, Amit Kucheria wrote:
> I was using initcall_debugging on a QCOM platform and ran across a bunch of
> driver initcalls that are enabled even if their SoC support is disabled.
What exactly is the problem you're trying to fix here? For the
drivers I looked at these were bog standard register the driver
with the subsystem type initcalls on optional drivers so not
doing anything particularly disruptive or anything like that.
For any given system that's going to be an issue for the
overwhelming majority of drivers on the tree, including those
that aren't associated with any particular architecture.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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 0/4] Cleanup arm64 driver dependencies
From: Amit Kucheria @ 2019-09-12 9:47 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, Linux PM list, linux-clk,
linux-kernel@vger.kernel.org, linux-pci, Kishon Vijay Abraham I,
Bartosz Golaszewski, arm-soc, Mark Brown,
open list:GPIO SUBSYSTEM, Sebastian Reichel, Will Deacon,
Michael Turquette, Linux ARM
In-Reply-To: <CAK8P3a2zGJx7SCA4LUHPGTybN8GU16Ah3H0FbaOEwR3H7uGCnA@mail.gmail.com>
Hi Arnd,
On Thu, Sep 12, 2019 at 2:59 PM Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Thu, Sep 12, 2019 at 12:18 AM Amit Kucheria <amit.kucheria@linaro.org> wrote:
> >
> > I was using initcall_debugging on a QCOM platform and ran across a bunch of
> > driver initcalls that are enabled even if their SoC support is disabled.
> >
> > Here are some fixups for a subset of them.
>
> The idea seems reasonable, disabling a platform may just turn off
> all the drivers that are not useful elsewhere, but there are mistakes
> in a lot of your changes, so I'm certainly not applying these for 5.4.
OK, thanks for confirming that you have no objections to such changes, per-se.
I'll spend some more time ensuring COMPILE_TEST coverage for these
cleanups. I only focused on quickly cleaning up my initcall_debug
output for now.
> Generally speaking, the way that works best is
>
> config SUBSYS_DRIVER_FOO
> tristate "SUBSYS support for FOO platform"
> depends on ARCH_FOO || COMPILE_TEST
> depends on SUBSYS
> default "m" if ARCH_FOO
>
> This means it's enabled as a loadable module by default (use
> default "y" instead where necessary) as long as the platform
> is enabled, but an x86 allmodconfig build also includes it
> because of COMPILE_TEST, while any configuration without
> ARCH_FOO that is not compile-testing cannot enable it.
How would you like to handle defconfigs which list a driver
explicitly? Should we add ARCH_FOO to those defconfigs or remove
DRIVER_FOO from them?
Regards,
Amit
_______________________________________________
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] gpio: iproc-gpio: Fix incorrect pinconf configurations
From: Linus Walleij @ 2019-09-12 9:57 UTC (permalink / raw)
To: Ray Jui
Cc: Scott Branden, Ray Jui, linux-kernel@vger.kernel.org,
Srinath Mannam, Li Jin, bcm-kernel-feedback-list, Linux ARM
In-Reply-To: <535f7569-70d0-1a7c-e15d-b77301867629@broadcom.com>
On Wed, Sep 11, 2019 at 5:55 PM Ray Jui <ray.jui@broadcom.com> wrote:
> These patches were actually all internally reviewed by Broadcom
> maintainers before sending out to the mailing list.
>
> Obviously you wouldn't know about that, :)
>
> One of us should have explicitly given our ACK, sorry...
It's fine, the process is not perfect.
Thanks!
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: [PATCH v2] arm: dts: imx6qdl: add gpio expander pca9535
From: Gilles Doffe @ 2019-09-12 10:01 UTC (permalink / raw)
To: Marco Felsch
Cc: mark rutland, devicetree, shawnguo, s hauer, rennes, linux-kernel,
robh+dt, linux-imx, kernel, Jérome Oufella, festevam,
linux-arm-kernel
In-Reply-To: <20190722075341.e4ve45rneusiogtk@pengutronix.de>
Hi Marco,
Thanks for your reply and sorry about the delay.
----- Le 22 Juil 19, à 9:53, Marco Felsch m.felsch@pengutronix.de a écrit :
> Hi Gilles,
>
> can you adapt the patch title, I assumed that the base dtsi is adding a
> gpio-expander which makes no sense.
My first intent was to add the gpio-expander pca9535 into the imx6q-rex-pro.dts and in a future imx6qp-rex-ultra.dts
However I noticed that the sgtl5000 was already in the dtsi.
It is maybe due to the fact that like the pca9535, the sgtl5000 is present on the baseboard not on the SOM.
Thus I guess that baseboard stuff common to all rex SOM should be in imx6qdl-rex.dtsi and not in the dts.
Does-it seem correct to you ?
>
> On 19-07-19 12:46, Gilles DOFFE wrote:
>> The pca9535 gpio expander is present on the Rex baseboard, but missing
>> from the dtsi.
>>
>> Add the new gpio controller and the associated interrupt line
>> MX6QDL_PAD_NANDF_CS3__GPIO6_IO16.
>>
>> Signed-off-by: Gilles DOFFE <gilles.doffe@savoirfairelinux.com>
>> ---
>
> Having a changelog would be nice too.
>
>> arch/arm/boot/dts/imx6qdl-rex.dtsi | 19 +++++++++++++++++++
>> 1 file changed, 19 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/imx6qdl-rex.dtsi
>> b/arch/arm/boot/dts/imx6qdl-rex.dtsi
>> index 97f1659144ea..b517efb22fcb 100644
>> --- a/arch/arm/boot/dts/imx6qdl-rex.dtsi
>> +++ b/arch/arm/boot/dts/imx6qdl-rex.dtsi
>> @@ -136,6 +136,19 @@
>> compatible = "atmel,24c02";
>> reg = <0x57>;
>> };
>> +
>> + pca9535: gpio8@27 {
>> + compatible = "nxp,pca9535";
>> + reg = <0x27>;
>
> The i2c devices are orderd by their i2c-addresses starting from the
> lowest.
>
Ack.
>> + gpio-controller;
>> + #gpio-cells = <2>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&pinctrl_pca9535>;
>> + interrupt-parent = <&gpio6>;
>> + interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
>> + interrupt-controller;
>> + #interrupt-cells = <2>;
>> + };
>> };
>>
>> &i2c3 {
>> @@ -237,6 +250,12 @@
>> >;
>> };
>>
>> + pinctrl_pca9535: pca9535 {
>> + fsl,pins = <
>> + MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x00017059
>
> The pinmux below don't use the leading zero's if you are the first I
> would drop that.
>
> Regards,
> Marco
>
Ack.
Regards,
Gilles
_______________________________________________
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/4] Cleanup arm64 driver dependencies
From: Mark Brown @ 2019-09-12 10:03 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, Linux PM list, linux-clk,
linux-kernel@vger.kernel.org, Amit Kucheria,
Kishon Vijay Abraham I, Bartosz Golaszewski, linux-pci, arm-soc,
open list:GPIO SUBSYSTEM, Sebastian Reichel, Will Deacon,
Michael Turquette, Linux ARM
In-Reply-To: <CAK8P3a2zGJx7SCA4LUHPGTybN8GU16Ah3H0FbaOEwR3H7uGCnA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 698 bytes --]
On Thu, Sep 12, 2019 at 11:29:00AM +0200, Arnd Bergmann wrote:
> Generally speaking, the way that works best is
> config SUBSYS_DRIVER_FOO
> tristate "SUBSYS support for FOO platform"
> depends on ARCH_FOO || COMPILE_TEST
> depends on SUBSYS
> default "m" if ARCH_FOO
> This means it's enabled as a loadable module by default (use
> default "y" instead where necessary) as long as the platform
> is enabled, but an x86 allmodconfig build also includes it
> because of COMPILE_TEST, while any configuration without
> ARCH_FOO that is not compile-testing cannot enable it.
Indeed, though we shouldn't be adding any default m/y to things
that don't already default on.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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 0/4] Cleanup arm64 driver dependencies
From: Amit Kucheria @ 2019-09-12 10:03 UTC (permalink / raw)
To: Mark Brown
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, Linux PM list, linux-clk,
Linux Kernel Mailing List, linux-pci, Kishon Vijay Abraham I,
Bartosz Golaszewski, arm-soc, open list:GPIO SUBSYSTEM,
Sebastian Reichel, Will Deacon, Michael Turquette, Lists LAKML
In-Reply-To: <20190912094651.GH2036@sirena.org.uk>
On Thu, Sep 12, 2019 at 3:17 PM Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Sep 12, 2019 at 03:48:44AM +0530, Amit Kucheria wrote:
>
> > I was using initcall_debugging on a QCOM platform and ran across a bunch of
> > driver initcalls that are enabled even if their SoC support is disabled.
>
> What exactly is the problem you're trying to fix here? For the
> drivers I looked at these were bog standard register the driver
> with the subsystem type initcalls on optional drivers so not
> doing anything particularly disruptive or anything like that.
I was trying to prune the defconfig only to drivers that make sense on
the SoC. e.g. Why should I see a brcmstb_soc_device_early_init() call
on a QCOM system when I've disabled ARCH_BRCMSTB?
I came across this while trying to figure out how to make thermal and
cpufreq frameworks initialise as early as possible.
> For any given system that's going to be an issue for the
> overwhelming majority of drivers on the tree, including those
> that aren't associated with any particular architecture.
Indeed. From a quick check, MFD and GPIO has a bunch of 'generic'
drivers that aren't SoC-specific. I'm sure there are several such
drivers in regulator framework too. They don't need to be 'fixed'.
I was just trying to ring-fence obvious SoC-specific drivers behind a
ARCH_FOO dependency since they seemed like low-hanging fruit. Let me
know if it isn't a good use of everyone's time.
Regards,
Amit
_______________________________________________
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 RFC] gpio: define gpio-init nodes to initialize pins similar to hogs
From: Uwe Kleine-König @ 2019-09-12 10:06 UTC (permalink / raw)
To: Linus Walleij
Cc: Mark Rutland, devicetree, Pawel Moll, open list:GPIO SUBSYSTEM,
Ian Campbell, Bartosz Golaszewski, Rob Herring, Sascha Hauer,
Kumar Gala, Linux ARM
In-Reply-To: <CACRpkdZTzYtxjmiEnbvSn0-WQtxADLrxJGb_Q83gtRFhcShRiQ@mail.gmail.com>
On Thu, Sep 12, 2019 at 10:05:23AM +0100, Linus Walleij wrote:
> On Mon, Sep 9, 2019 at 11:59 AM Uwe Kleine-König
> <u.kleine-koenig@pengutronix.de> wrote:
>
> > Sometimes it is handy to be able to easily define a "safe" state for a
> > GPIO. This might for example be used to ensure that an ethernet phy is
> > properly reset during startup or just that all pins have a defined state
> > to minimize leakage current. As such a pin must be requestable (and
> > changable) by a device driver, a gpio-hog cannot be used.
> >
> > So define a GPIO initializer with a syntax identical to a GPIO hog just
> > using "gpio-init" as identifier instead of "gpio-hog".
> >
> > The usage I have in mind (and also implemented in a custom patch stack
> > on top of barebox already) is targeting the bootloader and not
> > necessarily Linux as such an boot-up initialisation should be done as
> > early as possible.
> >
> > Not-yet-signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> > ---
> > Hello,
> >
> > maybe it also makes sense to use "gpio-safe"? Maybe it (then) makes
> > sense to reset the gpio in the indicated state after it is released?
> >
> > Also it might be beneficial to make the wording more explicit in the
> > description and for example tell that only one of gpio-hog and gpio-init
> > must be provided.
>
> It's no secret that I am in favor of this approach, as I like consistency
> with the hogs.
>
> The DT people have been against, as they prefer something like an
> initial array of values akin to gpio-names IIRC. But this is a good
> time for them to speak up.
To be fair, I added them to Cc:. For the new readers: The diff I
suggested looks as follows (probably whitespace broken as I cut-n-pasted):
> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
> index a8895d339bfe..5b7883f5520f 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> @@ -182,13 +182,16 @@ gpio-controller@00000000 {
> "poweroff", "reset";
> }
>
> -The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
> -providing automatic GPIO request and configuration as part of the
> -gpio-controller's driver probe function.
> +The GPIO chip may contain GPIO hog and init definitions. GPIO hogging is a
> +mechanism providing automatic GPIO request and configuration as part of the
> +gpio-controller's driver probe function. An GPIO initializer is similar but
> +doesn't prevent later requesting and reconfiguration.
>
> Each GPIO hog definition is represented as a child node of the GPIO controller.
> Required properties:
> - gpio-hog: A property specifying that this child node represents a GPIO hog.
> +- gpio-init: A property specifying that this child node represents a GPIO
> + initializer.
> - gpios: Store the GPIO information (id, flags, ...) for each GPIO to
> affect. Shall contain an integer multiple of the number of cells
> specified in its parent node (GPIO controller node).
How would this alternate approach look like? Something like:
gpio-controler@123450 {
compatible = "..";
gpio-controller;
#gpio-cells = <2>;
init = "", "output-high", "", "input", "", "", "output-low";
};
? Compared to the solution I suggested (and hogs) this differs as you cannot
pass flags like GPIO_ACTIVE_LOW.
(Sidenode: As
mygpio {
gpio-hog;
gpios = <5 GPIO_ACTIVE_LOW>;
output-low;
};
makes AFAIK the output high it would be less surprising if the binding
supported "output-active" and "output-inactive".)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
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] arm: dts: imx6qdl: add gpio expander pca9535
From: Marco Felsch @ 2019-09-12 10:12 UTC (permalink / raw)
To: Gilles Doffe
Cc: mark rutland, devicetree, shawnguo, s hauer, rennes, linux-kernel,
robh+dt, linux-imx, kernel, Jérome Oufella, festevam,
linux-arm-kernel
In-Reply-To: <978100557.7721358.1568282514403.JavaMail.zimbra@savoirfairelinux.com>
Hi Gilles,
On 19-09-12 06:01, Gilles Doffe wrote:
> Hi Marco,
>
> Thanks for your reply and sorry about the delay.
No worries ;)
> ----- Le 22 Juil 19, à 9:53, Marco Felsch m.felsch@pengutronix.de a écrit :
>
> > Hi Gilles,
> >
> > can you adapt the patch title, I assumed that the base dtsi is adding a
> > gpio-expander which makes no sense.
>
> My first intent was to add the gpio-expander pca9535 into the imx6q-rex-pro.dts and in a future imx6qp-rex-ultra.dts
> However I noticed that the sgtl5000 was already in the dtsi.
> It is maybe due to the fact that like the pca9535, the sgtl5000 is present on the baseboard not on the SOM.
> Thus I guess that baseboard stuff common to all rex SOM should be in imx6qdl-rex.dtsi and not in the dts.
> Does-it seem correct to you ?
Yes this is correct what Shawn and I mean is that you should adapt the
commit title. Shawn already give you an example.
> >
> > On 19-07-19 12:46, Gilles DOFFE wrote:
> >> The pca9535 gpio expander is present on the Rex baseboard, but missing
> >> from the dtsi.
> >>
> >> Add the new gpio controller and the associated interrupt line
> >> MX6QDL_PAD_NANDF_CS3__GPIO6_IO16.
> >>
> >> Signed-off-by: Gilles DOFFE <gilles.doffe@savoirfairelinux.com>
> >> ---
> >
> > Having a changelog would be nice too.
> >
> >> arch/arm/boot/dts/imx6qdl-rex.dtsi | 19 +++++++++++++++++++
> >> 1 file changed, 19 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/imx6qdl-rex.dtsi
> >> b/arch/arm/boot/dts/imx6qdl-rex.dtsi
> >> index 97f1659144ea..b517efb22fcb 100644
> >> --- a/arch/arm/boot/dts/imx6qdl-rex.dtsi
> >> +++ b/arch/arm/boot/dts/imx6qdl-rex.dtsi
> >> @@ -136,6 +136,19 @@
> >> compatible = "atmel,24c02";
> >> reg = <0x57>;
> >> };
> >> +
> >> + pca9535: gpio8@27 {
> >> + compatible = "nxp,pca9535";
> >> + reg = <0x27>;
> >
> > The i2c devices are orderd by their i2c-addresses starting from the
> > lowest.
> >
>
> Ack.
>
> >> + gpio-controller;
> >> + #gpio-cells = <2>;
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&pinctrl_pca9535>;
> >> + interrupt-parent = <&gpio6>;
> >> + interrupts = <16 IRQ_TYPE_LEVEL_LOW>;
> >> + interrupt-controller;
> >> + #interrupt-cells = <2>;
As you pointed out above this device isn't available on the
imx6dl-rex-basic? You should add: 'status = "disabled";' if this is the
case.
Regards,
Marco
> >> + };
> >> };
> >>
> >> &i2c3 {
> >> @@ -237,6 +250,12 @@
> >> >;
> >> };
> >>
> >> + pinctrl_pca9535: pca9535 {
> >> + fsl,pins = <
> >> + MX6QDL_PAD_NANDF_CS3__GPIO6_IO16 0x00017059
> >
> > The pinmux below don't use the leading zero's if you are the first I
> > would drop that.
> >
> > Regards,
> > Marco
> >
>
> Ack.
>
> Regards,
> Gilles
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
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 v9 0/8] stg mail -e --version=v9 \
From: Kirill A. Shutemov @ 2019-09-12 10:24 UTC (permalink / raw)
To: Michal Hocko
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev,
David Hildenbrand, Matthew Wilcox, Wang, Wei W, Mel Gorman,
ying.huang, Rik van Riel, Vlastimil Babka, Dan Williams,
linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal,
Konrad Rzeszutek Wilk, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190912091925.GM4023@dhcp22.suse.cz>
On Thu, Sep 12, 2019 at 11:19:25AM +0200, Michal Hocko wrote:
> On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> wrote:
> > >
> > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > [...]
> > > > We don't put any limitations on the allocator other then that it needs to
> > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > that is in the process of being reported since we pulled it from the
> > > > free_list. If the page is a "Reported" page then it decrements the
> > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > "Boundary" since it is pulling the page.
> > >
> > > This is still a non-trivial limitation on the page allocation from an
> > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > the free list might matter (well except for page shuffling which uses it
> > > to make physical memory pattern allocation more random) but the
> > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > whole interface has been developed around a very particular and single
> > > purpose optimization.
> >
> > How is this any different then the code that moves a page that will
> > likely be merged to the tail though?
>
> I guess you are referring to the page shuffling. If that is the case
> then this is an integral part of the allocator for a reason and it is
> very well obvious in the code including the consequences. I do not
> really like an idea of hiding similar constrains behind a generic
> looking feature which is completely detached from the allocator and so
> any future change of the allocator might subtly break it.
I don't necessary follow why shuffling is more integral to page allocator
than reporting would be. It's next to shutffle.c under mm/ and integrated
in a simillar way.
--
Kirill A. Shutemov
_______________________________________________
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 pinctrl/fixes] pinctrl: aspeed: Fix spurious mux failures on the AST2500
From: Andrew Jeffery @ 2019-09-12 10:26 UTC (permalink / raw)
To: Linus Walleij
Cc: linux-aspeed, OpenBMC Maillist, linux-kernel@vger.kernel.org,
open list:GPIO SUBSYSTEM, Joel Stanley, Linux ARM, John Wang
In-Reply-To: <CACRpkdYW_PX7npB+b1YJ4pfFQNLVOsMx2hpKtntBeHg=C1j-Cg@mail.gmail.com>
On Thu, 12 Sep 2019, at 17:53, Linus Walleij wrote:
> On Thu, Aug 29, 2019 at 8:17 AM Andrew Jeffery <andrew@aj.id.au> wrote:
>
> > Commit 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
> > was determined to be a partial fix to the problem of acquiring the LPC
> > Host Controller and GFX regmaps: The AST2500 pin controller may need to
> > fetch syscon regmaps during expression evaluation as well as when
> > setting mux state. For example, this case is hit by attempting to export
> > pins exposing the LPC Host Controller as GPIOs.
> >
> > An optional eval() hook is added to the Aspeed pinmux operation struct
> > and called from aspeed_sig_expr_eval() if the pointer is set by the
> > SoC-specific driver. This enables the AST2500 to perform the custom
> > action of acquiring its regmap dependencies as required.
> >
> > John Wang tested the fix on an Inspur FP5280G2 machine (AST2500-based)
> > where the issue was found, and I've booted the fix on Witherspoon
> > (AST2500) and Palmetto (AST2400) machines, and poked at relevant pins
> > under QEMU by forcing mux configurations via devmem before exporting
> > GPIOs to exercise the driver.
> >
> > Fixes: 7d29ed88acbb ("pinctrl: aspeed: Read and write bits in LPC and GFX controllers")
> > Fixes: 674fa8daa8c9 ("pinctrl: aspeed-g5: Delay acquisition of regmaps")
> > Reported-by: John Wang <wangzqbj@inspur.com>
> > Tested-by: John Wang <wangzqbj@inspur.com>
> > Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
>
> Applied for fixes already yesterday!
Thanks! Hoping to avoid such late fixes in the future...
Andrew
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] net: stmmac: socfpga: re-use the `interface` parameter from platform data
From: Alexandru Ardelean @ 2019-09-12 13:28 UTC (permalink / raw)
To: netdev, linux-stm32, linux-arm-kernel, linux-kernel
Cc: alexandre.torgue, joabreu, mcoquelin.stm32, peppe.cavallaro,
Alexandru Ardelean, davem
The socfpga sub-driver defines an `interface` field in the `socfpga_dwmac`
struct and parses it on init.
The shared `stmmac_probe_config_dt()` function also parses this from the
device-tree and makes it available on the returned `plat_data` (which is
the same data available via `netdev_priv()`).
All that's needed now is to dig that information out, via some
`dev_get_drvdata()` && `netdev_priv()` calls and re-use it.
Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
---
Changelog v1 -> v2:
* initially, this patch was developed on a 4.14 kernel, and adapted (badly)
to `net-next`, so it did not build ; the v2 has been fixed and adapted
correctly
.../net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 15 ++++++++++-----
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
index c141fe783e87..5b6213207c43 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c
@@ -46,7 +46,6 @@ struct socfpga_dwmac_ops {
};
struct socfpga_dwmac {
- int interface;
u32 reg_offset;
u32 reg_shift;
struct device *dev;
@@ -110,8 +109,6 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
struct resource res_tse_pcs;
struct resource res_sgmii_adapter;
- dwmac->interface = of_get_phy_mode(np);
-
sys_mgr_base_addr =
altr_sysmgr_regmap_lookup_by_phandle(np, "altr,sysmgr-syscon");
if (IS_ERR(sys_mgr_base_addr)) {
@@ -231,6 +228,14 @@ static int socfpga_dwmac_parse_data(struct socfpga_dwmac *dwmac, struct device *
return ret;
}
+static inline int socfpga_get_plat_phymode(struct socfpga_dwmac *dwmac)
+{
+ struct net_device *ndev = dev_get_drvdata(dwmac->dev);
+ struct stmmac_priv *priv = netdev_priv(ndev);
+
+ return priv->plat->interface;
+}
+
static int socfpga_set_phy_mode_common(int phymode, u32 *val)
{
switch (phymode) {
@@ -255,7 +260,7 @@ static int socfpga_set_phy_mode_common(int phymode, u32 *val)
static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
{
struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
- int phymode = dwmac->interface;
+ int phymode = socfpga_get_plat_phymode(dwmac);
u32 reg_offset = dwmac->reg_offset;
u32 reg_shift = dwmac->reg_shift;
u32 ctrl, val, module;
@@ -314,7 +319,7 @@ static int socfpga_gen5_set_phy_mode(struct socfpga_dwmac *dwmac)
static int socfpga_gen10_set_phy_mode(struct socfpga_dwmac *dwmac)
{
struct regmap *sys_mgr_base_addr = dwmac->sys_mgr_base_addr;
- int phymode = dwmac->interface;
+ int phymode = socfpga_get_plat_phymode(dwmac);
u32 reg_offset = dwmac->reg_offset;
u32 reg_shift = dwmac->reg_shift;
u32 ctrl, val, module;
--
2.20.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 1/3] iommu/io-pgtable-arm: Correct Mali attributes
From: Steven Price @ 2019-09-12 10:41 UTC (permalink / raw)
To: Robin Murphy, will, joro
Cc: robh, iommu, linux-arm-kernel, tomeu.vizoso, narmstrong
In-Reply-To: <8b9515e86053910196cbc90b71af97be8928585c.1568211045.git.robin.murphy@arm.com>
On 11/09/2019 15:42, Robin Murphy wrote:
> Whilst Midgard's MEMATTR follows a similar principle to the VMSA MAIR,
> the actual attribute values differ, so although it currently appears to
> work to some degree, we probably shouldn't be using our standard stage 1
> MAIR for that. Instead, generate a reasonable MEMATTR with attribute
> values borrowed from the kbase driver; at this point we'll be overriding
> or ignoring pretty much all of the LPAE config, so just implement these
> Mali details in a dedicated allocator instead of pretending to subclass
> the standard VMSA format.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
The Midgard MMU "uses concepts" from LPAE but really isn't LPAE, so this
seems like a good tidy up.
Reviewed-by: Steven Price <steven.price@arm.com>
Steve
> ---
> drivers/iommu/io-pgtable-arm.c | 53 +++++++++++++++++++++++++---------
> 1 file changed, 40 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 161a7d56264d..9e35cd991f06 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -167,6 +167,9 @@
> #define ARM_MALI_LPAE_TTBR_READ_INNER BIT(2)
> #define ARM_MALI_LPAE_TTBR_SHARE_OUTER BIT(4)
>
> +#define ARM_MALI_LPAE_MEMATTR_IMP_DEF 0x88ULL
> +#define ARM_MALI_LPAE_MEMATTR_WRITE_ALLOC 0x8DULL
> +
> /* IOPTE accessors */
> #define iopte_deref(pte,d) __va(iopte_to_paddr(pte, d))
>
> @@ -1013,27 +1016,51 @@ arm_32_lpae_alloc_pgtable_s2(struct io_pgtable_cfg *cfg, void *cookie)
> static struct io_pgtable *
> arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
> {
> - struct io_pgtable *iop;
> + struct arm_lpae_io_pgtable *data;
> +
> + /* No quirks for Mali (hopefully) */
> + if (cfg->quirks)
> + return NULL;
>
> if (cfg->ias != 48 || cfg->oas > 40)
> return NULL;
>
> cfg->pgsize_bitmap &= (SZ_4K | SZ_2M | SZ_1G);
> - iop = arm_64_lpae_alloc_pgtable_s1(cfg, cookie);
> - if (iop) {
> - u64 mair, ttbr;
>
> - /* Copy values as union fields overlap */
> - mair = cfg->arm_lpae_s1_cfg.mair[0];
> - ttbr = cfg->arm_lpae_s1_cfg.ttbr[0];
> + data = arm_lpae_alloc_pgtable(cfg);
> + if (!data)
> + return NULL;
>
> - cfg->arm_mali_lpae_cfg.memattr = mair;
> - cfg->arm_mali_lpae_cfg.transtab = ttbr |
> - ARM_MALI_LPAE_TTBR_READ_INNER |
> - ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
> - }
> + /*
> + * MEMATTR: Mali has no actual notion of a non-cacheable type, so the
> + * best we can do is mimic the out-of-tree driver and hope that the
> + * "implementation-defined caching policy" is good enough. Similarly,
> + * we'll use it for the sake of a valid attribute for our 'device'
> + * index, although callers should never request that in practice.
> + */
> + cfg->arm_mali_lpae_cfg.memattr =
> + (ARM_MALI_LPAE_MEMATTR_IMP_DEF
> + << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_NC)) |
> + (ARM_MALI_LPAE_MEMATTR_WRITE_ALLOC
> + << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_CACHE)) |
> + (ARM_MALI_LPAE_MEMATTR_IMP_DEF
> + << ARM_LPAE_MAIR_ATTR_SHIFT(ARM_LPAE_MAIR_ATTR_IDX_DEV));
>
> - return iop;
> + data->pgd = __arm_lpae_alloc_pages(data->pgd_size, GFP_KERNEL, cfg);
> + if (!data->pgd)
> + goto out_free_data;
> +
> + /* Ensure the empty pgd is visible before TRANSTAB can be written */
> + wmb();
> +
> + cfg->arm_mali_lpae_cfg.transtab = virt_to_phys(data->pgd) |
> + ARM_MALI_LPAE_TTBR_READ_INNER |
> + ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
> + return &data->iop;
> +
> +out_free_data:
> + kfree(data);
> + return NULL;
> }
>
> struct io_pgtable_init_fns io_pgtable_arm_64_lpae_s1_init_fns = {
>
_______________________________________________
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/3] iommu/io-pgtable-arm: Support more Mali configurations
From: Steven Price @ 2019-09-12 10:47 UTC (permalink / raw)
To: Robin Murphy, will, joro
Cc: robh, iommu, linux-arm-kernel, tomeu.vizoso, narmstrong
In-Reply-To: <69c934789ad2bf486b03682563ea2262ea6d9301.1568211045.git.robin.murphy@arm.com>
On 11/09/2019 15:42, Robin Murphy wrote:
> In principle, Midgard GPUs supporting smaller VA sizes should only
> require 3-level pagetables, since the address bits resolved at level 0
> (47:40) will never change. However, the kbase driver does not appear to
> have any notion of a variable start level, and empirically T720 and T820
> rapidly blow up with translation faults unless given a full 4-level
> table, despite only supporting a 33-bit VA size.
Midgard 'LPAE' isn't really LPAE and does indeed always require all
levels of page tables. The 33-bit VA size is really only limiting the
storage of virtual addresses in the GPU and not affecting the MMU.
> The 'real' IAS value is still valuable in terms of validating addresses
> on map/unmap, so tweak the allocator to allow smaller values while still
> forcing the resultant tables to the full 4 levels.
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Steve
> ---
> drivers/iommu/io-pgtable-arm.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 9e35cd991f06..77f41c9dd9be 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -1022,7 +1022,7 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
> if (cfg->quirks)
> return NULL;
>
> - if (cfg->ias != 48 || cfg->oas > 40)
> + if (cfg->ias > 48 || cfg->oas > 40)
> return NULL;
>
> cfg->pgsize_bitmap &= (SZ_4K | SZ_2M | SZ_1G);
> @@ -1031,6 +1031,11 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
> if (!data)
> return NULL;
>
> + /* Mali seems to need a full 4-level table regardless of IAS */
> + if (data->levels < ARM_LPAE_MAX_LEVELS) {
> + data->levels = ARM_LPAE_MAX_LEVELS;
> + data->pgd_size = sizeof(arm_lpae_iopte);
> + }
> /*
> * MEMATTR: Mali has no actual notion of a non-cacheable type, so the
> * best we can do is mimic the out-of-tree driver and hope that the
>
_______________________________________________
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/4] Cleanup arm64 driver dependencies
From: Mark Brown @ 2019-09-12 10:53 UTC (permalink / raw)
To: Amit Kucheria
Cc: Lorenzo Pieralisi, Liam Girdwood, Stephen Boyd, Catalin Marinas,
Linus Walleij, Linux PM list, linux-clk,
Linux Kernel Mailing List, linux-pci, Kishon Vijay Abraham I,
Bartosz Golaszewski, arm-soc, open list:GPIO SUBSYSTEM,
Sebastian Reichel, Will Deacon, Michael Turquette, Lists LAKML
In-Reply-To: <CAP245DXBwwtcbjRQV_bCdYK5SZH9C9oxZJ2rFraJpbd5L0sHvw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1241 bytes --]
On Thu, Sep 12, 2019 at 03:33:20PM +0530, Amit Kucheria wrote:
> On Thu, Sep 12, 2019 at 3:17 PM Mark Brown <broonie@kernel.org> wrote:
> > > I was using initcall_debugging on a QCOM platform and ran across a bunch of
> > > driver initcalls that are enabled even if their SoC support is disabled.
> > What exactly is the problem you're trying to fix here? For the
> > drivers I looked at these were bog standard register the driver
> > with the subsystem type initcalls on optional drivers so not
> > doing anything particularly disruptive or anything like that.
> I was trying to prune the defconfig only to drivers that make sense on
> the SoC. e.g. Why should I see a brcmstb_soc_device_early_init() call
> on a QCOM system when I've disabled ARCH_BRCMSTB?
So this is really just the standard make Kconfig easier to use by
filtering out noise thing. It'd be clearer if you said that in
the changelog, and like the review comments have been saying you
need to leave in an || COMPILE_TEST in there otherwise it's
actively harmful.
> I came across this while trying to figure out how to make thermal and
> cpufreq frameworks initialise as early as possible.
AFAICT you'd also have been happy if you just built these drivers
modular?
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 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 3/3] iommu/io-pgtable-arm: Allow coherent walks for Mali
From: Steven Price @ 2019-09-12 10:53 UTC (permalink / raw)
To: Robin Murphy, will, joro
Cc: robh, iommu, linux-arm-kernel, tomeu.vizoso, narmstrong
In-Reply-To: <8eb563978e7e872ddde45c0413e1a3f30b792658.1568211045.git.robin.murphy@arm.com>
On 11/09/2019 15:42, Robin Murphy wrote:
> Midgard GPUs have ACE-Lite master interfaces which allows systems to
> integrate them in an I/O-coherent manner. It seems that from the GPU's
> viewpoint, the rest of the system is its outer shareable domain, and it
> will only emit snoop signals for outer shareable accesses. As such,
> setting the TTBR_SHARE_OUTER bit does indeed get coherent pagetable
> walks working nicely.
>
> Making data accesses coherent seems to be more of a challenge...
>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Steven Price <steven.price@arm.com>
Note the terminology in the GPU is *very* confusing here. Midgard refers
to the system's inner shareable domain as "outer shareable", and uses
"inner shareable" to mean purely within the GPU.
For data access kbase sets up a different default MEMATTR if ACE is
available:
/* Set to implementation defined, outer caching */
#define AS_MEMATTR_LPAE_OUTER_IMPL_DEF 0x88ull
[...]
#define AS_MEMATTR_INDEX_DEFAULT_ACE 3
[...]
/* Outer coherent, inner implementation defined policy */
#define AS_MEMATTR_INDEX_OUTER_IMPL_DEF 3
Steve
> ---
> drivers/iommu/io-pgtable-arm.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
> index 77f41c9dd9be..2794d4661339 100644
> --- a/drivers/iommu/io-pgtable-arm.c
> +++ b/drivers/iommu/io-pgtable-arm.c
> @@ -1061,6 +1061,9 @@ arm_mali_lpae_alloc_pgtable(struct io_pgtable_cfg *cfg, void *cookie)
> cfg->arm_mali_lpae_cfg.transtab = virt_to_phys(data->pgd) |
> ARM_MALI_LPAE_TTBR_READ_INNER |
> ARM_MALI_LPAE_TTBR_ADRMODE_TABLE;
> + if (cfg->coherent_walk)
> + cfg->arm_mali_lpae_cfg.transtab |= ARM_MALI_LPAE_TTBR_SHARE_OUTER;
> +
> return &data->iop;
>
> out_free_data:
>
_______________________________________________
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 2/2] mm/pgtable/debug: Add test validating architecture page table helpers
From: Kirill A. Shutemov @ 2019-09-12 11:00 UTC (permalink / raw)
To: Anshuman Khandual
Cc: Mark Rutland, linux-ia64, linux-sh, Peter Zijlstra, James Hogan,
Tetsuo Handa, Heiko Carstens, Michal Hocko, linux-mm, Dave Hansen,
Paul Mackerras, sparclinux, Thomas Gleixner, linux-s390,
Michael Ellerman, x86, Russell King - ARM Linux, Matthew Wilcox,
Steven Price, Jason Gunthorpe, Gerald Schaefer, linux-snps-arc,
linux-arm-kernel, Kees Cook, Masahiro Yamada, Mark Brown,
Dan Williams, Vlastimil Babka, Christophe Leroy,
Sri Krishna chowdary, Ard Biesheuvel, Greg Kroah-Hartman,
linux-mips, Ralf Baechle, linux-kernel, Paul Burton,
Mike Rapoport, Vineet Gupta, Martin Schwidefsky, Andrew Morton,
linuxppc-dev, David S. Miller
In-Reply-To: <1568268173-31302-3-git-send-email-anshuman.khandual@arm.com>
On Thu, Sep 12, 2019 at 11:32:53AM +0530, Anshuman Khandual wrote:
> +MODULE_LICENSE("GPL v2");
> +MODULE_AUTHOR("Anshuman Khandual <anshuman.khandual@arm.com>");
> +MODULE_DESCRIPTION("Test architecture page table helpers");
It's not module. Why?
BTW, I think we should make all code here __init (or it's variants) so it
can be discarded on boot. It has not use after that.
--
Kirill A. Shutemov
_______________________________________________
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 v9 0/8] stg mail -e --version=v9 \
From: Michal Hocko @ 2019-09-12 11:11 UTC (permalink / raw)
To: Kirill A. Shutemov
Cc: Yang Zhang, Pankaj Gupta, kvm list, Michael S. Tsirkin,
Catalin Marinas, Alexander Duyck, lcapitulino, linux-mm,
Alexander Duyck, will, Andrea Arcangeli, virtio-dev,
David Hildenbrand, Matthew Wilcox, Wang, Wei W, Mel Gorman,
ying.huang, Rik van Riel, Vlastimil Babka, Dan Williams,
linux-arm-kernel, Oscar Salvador, Nitesh Narayan Lal,
Konrad Rzeszutek Wilk, Dave Hansen, LKML, Paolo Bonzini,
Andrew Morton, Fengguang Wu, Kirill A. Shutemov
In-Reply-To: <20190912102425.wzhhe6ygfgg64sma@box>
On Thu 12-09-19 13:24:25, Kirill A. Shutemov wrote:
> On Thu, Sep 12, 2019 at 11:19:25AM +0200, Michal Hocko wrote:
> > On Wed 11-09-19 08:12:03, Alexander Duyck wrote:
> > > On Wed, Sep 11, 2019 at 4:36 AM Michal Hocko <mhocko@kernel.org> wrote:
> > > >
> > > > On Tue 10-09-19 14:23:40, Alexander Duyck wrote:
> > > > [...]
> > > > > We don't put any limitations on the allocator other then that it needs to
> > > > > clean up the metadata on allocation, and that it cannot allocate a page
> > > > > that is in the process of being reported since we pulled it from the
> > > > > free_list. If the page is a "Reported" page then it decrements the
> > > > > reported_pages count for the free_area and makes sure the page doesn't
> > > > > exist in the "Boundary" array pointer value, if it does it moves the
> > > > > "Boundary" since it is pulling the page.
> > > >
> > > > This is still a non-trivial limitation on the page allocation from an
> > > > external code IMHO. I cannot give any explicit reason why an ordering on
> > > > the free list might matter (well except for page shuffling which uses it
> > > > to make physical memory pattern allocation more random) but the
> > > > architecture seems hacky and dubious to be honest. It shoulds like the
> > > > whole interface has been developed around a very particular and single
> > > > purpose optimization.
> > >
> > > How is this any different then the code that moves a page that will
> > > likely be merged to the tail though?
> >
> > I guess you are referring to the page shuffling. If that is the case
> > then this is an integral part of the allocator for a reason and it is
> > very well obvious in the code including the consequences. I do not
> > really like an idea of hiding similar constrains behind a generic
> > looking feature which is completely detached from the allocator and so
> > any future change of the allocator might subtly break it.
>
> I don't necessary follow why shuffling is more integral to page allocator
> than reporting would be. It's next to shutffle.c under mm/ and integrated
> in a simillar way.
The main difference from my understanding is that the page reporting is
a more generic looking feature which might grow different users over
time yet there is a hardcoded set of restrictions to the allocator. Page
shuffling is an integral part of the allocator without any other
visibility outside.
--
Michal Hocko
SUSE Labs
_______________________________________________
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: Alexander Dahl @ 2019-09-12 11:06 UTC (permalink / raw)
To: linux-arm-kernel
Cc: alexandre.belloni, sboyd, mturquette, linux-kernel, Eugen.Hristev,
linux-clk
In-Reply-To: <1568183622-7858-1-git-send-email-eugen.hristev@microchip.com>
Hello,
out of curiosity: The SAMA5D27-SOM1-EK board has a 24 MHz crystal, that is
also what /sys/kernel/debug/clk/clk_summary says and the board runs without
obvious problems. What is this change improving in real practice then?
Greets
Alex
Am Mittwoch, 11. September 2019, 06:39:20 CEST schrieb
Eugen.Hristev@microchip.com:
> 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>
> ---
> drivers/clk/at91/sama5d2.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
> index 6509d09..0de1108 100644
> --- a/drivers/clk/at91/sama5d2.c
> +++ b/drivers/clk/at91/sama5d2.c
> @@ -21,7 +21,7 @@ static const struct clk_range plla_outputs[] = {
> };
>
> static const struct clk_pll_characteristics plla_characteristics = {
> - .input = { .min = 12000000, .max = 12000000 },
> + .input = { .min = 12000000, .max = 24000000 },
> .num_output = ARRAY_SIZE(plla_outputs),
> .output = plla_outputs,
> .icpll = plla_icpll,
_______________________________________________
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 08/11] PCI: layerscape: Modify the MSIX to the doorbell mode
From: Gustavo Pimentel @ 2019-09-12 11:24 UTC (permalink / raw)
To: Andrew Murray, Xiaowei Bao
Cc: mark.rutland@arm.com, roy.zang@nxp.com, lorenzo.pieralisi@arm.com,
arnd@arndb.de, devicetree@vger.kernel.org, jingoohan1@gmail.com,
zhiqiang.hou@nxp.com, linuxppc-dev@lists.ozlabs.org,
linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
kishon@ti.com, minghuan.Lian@nxp.com, robh+dt@kernel.org,
gregkh@linuxfoundation.org, linux-arm-kernel@lists.infradead.org,
gustavo.pimentel@synopsys.com, leoyang.li@nxp.com,
shawnguo@kernel.org, mingkai.hu@nxp.com
In-Reply-To: <20190902120147.GH9720@e119886-lin.cambridge.arm.com>
Hi,
Sorry for the delay I was in parental leave and I'm still trying not to
drown in the mailing list emails... 😊
On Mon, Sep 2, 2019 at 13:1:47, Andrew Murray <andrew.murray@arm.com>
wrote:
> On Mon, Sep 02, 2019 at 11:17:13AM +0800, Xiaowei Bao wrote:
> > dw_pcie_ep_raise_msix_irq was never called in the exisitng driver
> > before, because the ls1046a platform don't support the MSIX feature
> > and msix_capable was always set to false.
> > Now that add the ls1088a platform with MSIX support, but the existing
> > dw_pcie_ep_raise_msix_irq doesn't work, so use the doorbell method to
> > support the MSIX feature.
Hum... the implementation of msix implementation did work on my use case,
however, at the time the setup used for developing and testing the
implementation only had one PF (by default 0). Perhaps this could was is
causing the different behavior between our setups.
You have more than one PF, right?
If I remember correctly, msix feature support entered on kernel 4.19
version and it worked quite well at the time, but I didn't test since
there (I've to manage time to be able to retest it again), I'm didn't
seen any patch that could interfere with this.
Regards,
Gustavo
> >
> > Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
>
> Reviewed-by: Andrew Murray <andrew.murray@arm.com>
>
> > ---
> > v2:
> > - No change
> > v3:
> > - Modify the commit message make it clearly.
> >
> > drivers/pci/controller/dwc/pci-layerscape-ep.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > index 1e07287..5f0cb99 100644
> > --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> > @@ -79,7 +79,8 @@ static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> > case PCI_EPC_IRQ_MSI:
> > return dw_pcie_ep_raise_msi_irq(ep, func_no, interrupt_num);
> > case PCI_EPC_IRQ_MSIX:
> > - return dw_pcie_ep_raise_msix_irq(ep, func_no, interrupt_num);
> > + return dw_pcie_ep_raise_msix_irq_doorbell(ep, func_no,
> > + interrupt_num);
> > default:
> > dev_err(pci->dev, "UNKNOWN IRQ type\n");
> > return -EINVAL;
> > --
> > 2.9.5
> >
_______________________________________________
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: Eugen.Hristev @ 2019-09-12 11:28 UTC (permalink / raw)
To: ada, linux-arm-kernel
Cc: sboyd, linux-kernel, mturquette, alexandre.belloni, linux-clk
In-Reply-To: <30755021.BkS3ObC0RA@ada>
On 12.09.2019 14:06, Alexander Dahl wrote:
>
> Hello,
>
> out of curiosity: The SAMA5D27-SOM1-EK board has a 24 MHz crystal, that is
> also what /sys/kernel/debug/clk/clk_summary says and the board runs without
> obvious problems. What is this change improving in real practice then?
>
The board works, but, the characteristics of the PLL are incorrect.
This can lead to unwanted behavior, like calculating wrong minimum
values for multipliers, or other issues
In this code here in clk-pll.c for example
if (parent_rate > characteristics->input.max) {
tmpdiv = DIV_ROUND_UP(parent_rate,
characteristics->input.max);
if (tmpdiv > PLL_DIV_MAX)
return -ERANGE;
if (tmpdiv > mindiv)
mindiv = tmpdiv;
}
The divisor is capped by checks, but at another possible requested
parent rate, this may lead to something wrong, like here, the minimum
divisor might be greater than what is the real possible one. So in some
cases it can happen that unwanted results occur.
We may consider at some points to rely on these values more, so, it's
obvious that they should be correct in the characteristics
So short answer: no improve in your case , where the rates required are
around 492 Mhz cpu/132 mhz bus (IIRC), but the characteristics need to
be correct to cover all possible cases.
Eugen
> Greets
> Alex
>
> Am Mittwoch, 11. September 2019, 06:39:20 CEST schrieb
> Eugen.Hristev@microchip.com:
>> 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>
>> ---
>> drivers/clk/at91/sama5d2.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/at91/sama5d2.c b/drivers/clk/at91/sama5d2.c
>> index 6509d09..0de1108 100644
>> --- a/drivers/clk/at91/sama5d2.c
>> +++ b/drivers/clk/at91/sama5d2.c
>> @@ -21,7 +21,7 @@ static const struct clk_range plla_outputs[] = {
>> };
>>
>> static const struct clk_pll_characteristics plla_characteristics = {
>> - .input = { .min = 12000000, .max = 12000000 },
>> + .input = { .min = 12000000, .max = 24000000 },
>> .num_output = ARRAY_SIZE(plla_outputs),
>> .output = plla_outputs,
>> .icpll = plla_icpll,
>
>
>
>
_______________________________________________
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 04/13] KVM: Drop kvm_arch_create_memslot()
From: Janosch Frank @ 2019-09-12 11:31 UTC (permalink / raw)
To: Sean Christopherson, James Hogan, Paul Mackerras,
Christian Borntraeger, Paolo Bonzini, Radim Krčmář,
Marc Zyngier
Cc: Julien Thierry, Wanpeng Li, kvm, David Hildenbrand, Joerg Roedel,
Cornelia Huck, linux-mips, kvm-ppc, linux-kernel, James Morse,
linux-arm-kernel, Vitaly Kuznetsov, kvmarm, Suzuki K Pouloze,
Jim Mattson
In-Reply-To: <20190911185038.24341-5-sean.j.christopherson@intel.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 941 bytes --]
On 9/11/19 8:50 PM, Sean Christopherson wrote:
> Remove kvm_arch_create_memslot() now that all arch implementations are
> effectively nops. Explicitly free an allocated-but-unused dirty bitmap
> instead of relying on kvm_free_memslot() now that setting a memslot can
> no longer fail after arch code has allocated memory. In practice
> this was already true, e.g. architectures that allocated memory via
> kvm_arch_create_memslot() never failed kvm_arch_prepare_memory_region()
> and vice versa, but removing kvm_arch_create_memslot() eliminates the
> potential for future code to stealthily change behavior.
>
> Eliminating the error path's reliance on kvm_free_memslot() paves the
> way for simplify kvm_free_memslot(), i.e. dropping its @dont param.
>
> Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
Please either split or adopt the patch title to include the freeing.
I'd go for splitting.
[-- Attachment #1.2: OpenPGP digital signature --]
[-- 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
* [PATCHv5 00/10] soc: ti: add OMAP PRM driver (for reset)
From: Tero Kristo @ 2019-09-12 11:39 UTC (permalink / raw)
To: linux-omap, ssantosh, p.zabel, robh+dt, tony, s-anna
Cc: devicetree, linux-arm-kernel
Hi,
V5 of the series, re-sent the whole series as one patch was dropped.
Changes compared to v3/v4:
- removed dependency towards clock driver (patch #5 was completely
dropped compared to v3/v4)
- dropped clocks property from dt binding
- re-added the pdata patch which was accidentally dropped out (it has
dependency towards this series.)
The new implementation (without clock driver dependency) relies on the
bus driver to sequence events properly, otherwise some timeouts will
occur either at clock driver or reset driver end.
-Tero
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCHv5 03/10] soc: ti: omap-prm: poll for reset complete during de-assert
From: Tero Kristo @ 2019-09-12 11:39 UTC (permalink / raw)
To: linux-omap, ssantosh, p.zabel, robh+dt, tony, s-anna
Cc: devicetree, linux-arm-kernel
In-Reply-To: <20190912113916.20093-1-t-kristo@ti.com>
Poll for reset completion status during de-assertion of reset, otherwise
the IP in question might be accessed before it has left reset properly.
Signed-off-by: Tero Kristo <t-kristo@ti.com>
---
drivers/soc/ti/omap_prm.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/soc/ti/omap_prm.c b/drivers/soc/ti/omap_prm.c
index ab0b66ad715d..96fa2aad9b93 100644
--- a/drivers/soc/ti/omap_prm.c
+++ b/drivers/soc/ti/omap_prm.c
@@ -153,6 +153,18 @@ static int omap_reset_deassert(struct reset_controller_dev *rcdev,
writel_relaxed(v, reset->prm->base + reset->prm->data->rstctrl);
spin_unlock_irqrestore(&reset->lock, flags);
+ if (!has_rstst)
+ return 0;
+
+ /* wait for the status to be set */
+ ret = readl_relaxed_poll_timeout(reset->prm->base +
+ reset->prm->data->rstst,
+ v, v & BIT(st_bit), 1,
+ OMAP_RESET_MAX_WAIT);
+ if (ret)
+ pr_err("%s: timedout waiting for %s:%lu\n", __func__,
+ reset->prm->data->name, id);
+
return 0;
}
--
2.17.1
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
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