* Re: [PATCH] media: stm32-dcmi: Set minimum cpufreq requirement
From: Valentin Schneider @ 2020-06-02 9:31 UTC (permalink / raw)
To: Benjamin Gaignard
Cc: alexandre.torgue, rjw, linux-kernel, mcoquelin.stm32,
hugues.fruchet, mchehab, linux-stm32, linux-arm-kernel,
linux-media
In-Reply-To: <20200527151613.16083-1-benjamin.gaignard@st.com>
Hi Benjamin,
On 27/05/20 16:16, Benjamin Gaignard wrote:
> Before start streaming set cpufreq minimum frequency requirement.
> The cpufreq governor will adapt the frequencies and we will have
> no latency for handling interrupts.
>
Few comments below from someone oblivious to your platform, they may not
be all that relevant but I figured I'd pitch in anyway.
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> drivers/media/platform/stm32/stm32-dcmi.c | 29 ++++++++++++++++++++++++++++-
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> index b8931490b83b..97c342351569 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -13,6 +13,7 @@
>
> #include <linux/clk.h>
> #include <linux/completion.h>
> +#include <linux/cpufreq.h>
> #include <linux/delay.h>
> #include <linux/dmaengine.h>
> #include <linux/init.h>
> @@ -99,6 +100,8 @@ enum state {
>
> #define OVERRUN_ERROR_THRESHOLD 3
>
> +#define DCMI_MIN_FREQ 650000 /* in KHz */
> +
This assumes the handling part is guaranteed to always run on the same CPU
with the same performance profile (regardless of the platform). If that's
not guaranteed, it feels like you'd want this to be configurable in some
way.
> struct dcmi_graph_entity {
> struct v4l2_async_subdev asd;
>
[...]
> @@ -2020,6 +2042,8 @@ static int dcmi_probe(struct platform_device *pdev)
> goto err_cleanup;
> }
>
> + dcmi->policy = cpufreq_cpu_get(0);
> +
Ideally you'd want to fetch the policy of the CPU your IRQ (and handling
thread) is affined to; The only compatible DTS I found describes a single
A7, which is somewhat limited in the affinity area...
> dev_info(&pdev->dev, "Probe done\n");
>
> platform_set_drvdata(pdev, dcmi);
> @@ -2049,6 +2073,9 @@ static int dcmi_remove(struct platform_device *pdev)
>
> pm_runtime_disable(&pdev->dev);
>
> + if (dcmi->policy)
> + cpufreq_cpu_put(dcmi->policy);
> +
> v4l2_async_notifier_unregister(&dcmi->notifier);
> v4l2_async_notifier_cleanup(&dcmi->notifier);
> media_entity_cleanup(&dcmi->vdev->entity);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: davinci: fix build failure without I2C
From: Peter Ujfalusi @ 2020-06-02 9:19 UTC (permalink / raw)
To: Sekhar Nori, Arnd Bergmann
Cc: Arnd Bergmann, Russell King, linux-kernel, Bartosz Golaszewski,
soc, Bin Liu, linux-arm-kernel
In-Reply-To: <20200527133746.643895-1-arnd@arndb.de>
Hi Arnd,
On Wednesday, 27 May 2020 16.37.34 EEST Arnd Bergmann wrote:
> The two supplies are referenced outside of #ifdef CONFIG_I2C but
> defined inside, which breaks the build if that is not built-in:
>
> mach-davinci/board-dm644x-evm.c:861:21: error: use of undeclared identifier 'fixed_supplies_1_8v'
> ARRAY_SIZE(fixed_supplies_1_8v), 1800000);
> ^
> mach-davinci/board-dm644x-evm.c:861:21: error: use of undeclared identifier 'fixed_supplies_1_8v'
> mach-davinci/board-dm644x-evm.c:861:21: error: use of undeclared identifier 'fixed_supplies_1_8v'
> mach-davinci/board-dm644x-evm.c:860:49: error: use of undeclared identifier 'fixed_supplies_1_8v'
> regulator_register_always_on(0, "fixed-dummy", fixed_supplies_1_8v,
>
> I don't know if the regulators are used anywhere without I2C, but
> always registering them seems to be the safe choice here.
Thanks for fixing this,
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
> On a related note, it might be best to also deal with CONFIG_I2C=m
> across the file, unless this is going to be moved to DT and removed
> really soon anyway.
>
> Fixes: 5e06d19694a4 ("ARM: davinci: dm644x-evm: Add Fixed regulators needed for tlv320aic33")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
> arch/arm/mach-davinci/board-dm644x-evm.c | 26 ++++++++++++------------
> 1 file changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c b/arch/arm/mach-davinci/board-dm644x-evm.c
> index 3461d12bbfc0..a5d3708fedf6 100644
> --- a/arch/arm/mach-davinci/board-dm644x-evm.c
> +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
> @@ -655,19 +655,6 @@ static struct i2c_board_info __initdata i2c_info[] = {
> },
> };
>
> -/* Fixed regulator support */
> -static struct regulator_consumer_supply fixed_supplies_3_3v[] = {
> - /* Baseboard 3.3V: 5V -> TPS54310PWP -> 3.3V */
> - REGULATOR_SUPPLY("AVDD", "1-001b"),
> - REGULATOR_SUPPLY("DRVDD", "1-001b"),
> -};
> -
> -static struct regulator_consumer_supply fixed_supplies_1_8v[] = {
> - /* Baseboard 1.8V: 5V -> TPS54310PWP -> 1.8V */
> - REGULATOR_SUPPLY("IOVDD", "1-001b"),
> - REGULATOR_SUPPLY("DVDD", "1-001b"),
> -};
> -
> #define DM644X_I2C_SDA_PIN GPIO_TO_PIN(2, 12)
> #define DM644X_I2C_SCL_PIN GPIO_TO_PIN(2, 11)
>
> @@ -700,6 +687,19 @@ static void __init evm_init_i2c(void)
> }
> #endif
>
> +/* Fixed regulator support */
> +static struct regulator_consumer_supply fixed_supplies_3_3v[] = {
> + /* Baseboard 3.3V: 5V -> TPS54310PWP -> 3.3V */
> + REGULATOR_SUPPLY("AVDD", "1-001b"),
> + REGULATOR_SUPPLY("DRVDD", "1-001b"),
> +};
> +
> +static struct regulator_consumer_supply fixed_supplies_1_8v[] = {
> + /* Baseboard 1.8V: 5V -> TPS54310PWP -> 1.8V */
> + REGULATOR_SUPPLY("IOVDD", "1-001b"),
> + REGULATOR_SUPPLY("DVDD", "1-001b"),
> +};
> +
> #define VENC_STD_ALL (V4L2_STD_NTSC | V4L2_STD_PAL)
>
> /* venc standard timings */
>
- Péter
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
* Re: [PATCH 05/14] dt-bindings: arm: sparx5: Add documentation for Microchip Sparx5 SoC
From: Lars Povlsen @ 2020-06-02 9:10 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Alexandre Belloni, Arnd Bergmann, linux-gpio,
Stephen Boyd, Steen Hegelund, linux-clk, linux-kernel,
Microchip Linux Driver Support, Michael Turquette, SoC Team,
linux-arm-kernel, Olof Johansson, Linus Walleij, Lars Povlsen
In-Reply-To: <20200528021137.GA3214411@bogus>
Rob Herring writes:
> On Wed, May 13, 2020 at 02:55:23PM +0200, Lars Povlsen wrote:
>> This adds the main Sparx5 SoC DT documentation file, with information
>> abut the supported board types.
>>
>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>> ---
>> .../bindings/arm/microchip,sparx5.yaml | 87 +++++++++++++++++++
>> 1 file changed, 87 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml b/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
>> new file mode 100644
>> index 0000000000000..83b36d1217988
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/microchip,sparx5.yaml
>> @@ -0,0 +1,87 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/arm/microchip,sparx5.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip Sparx5 Boards Device Tree Bindings
>> +
>> +maintainers:
>> + - Lars Povlsen <lars.povlsen@microchip.com>
>> +
>> +description: |+
>> + The Microchip Sparx5 SoC is a ARMv8-based used in a family of
>> + gigabit TSN-capable gigabit switches.
>> +
>> + The SparX-5 Ethernet switch family provides a rich set of switching
>> + features such as advanced TCAM-based VLAN and QoS processing
>> + enabling delivery of differentiated services, and security through
>> + TCAM-based frame processing using versatile content aware processor
>> + (VCAP)
>> +
>> +properties:
>> + $nodename:
>> + const: '/'
>> + compatible:
>> + oneOf:
>> + - description: The Sparx5 pcb125 board is a modular board,
>> + which has both spi-nor and eMMC storage. The modular design
>> + allows for connection of different network ports.
>> + items:
>> + - const: microchip,sparx5-pcb125
>> + - const: microchip,sparx5
>> +
>> + - description: The Sparx5 pcb134 is a pizzabox form factor
>> + gigabit switch with 20 SFP ports. It features spi-nor and
>> + either spi-nand or eMMC storage (mount option).
>> + items:
>> + - const: microchip,sparx5-pcb134
>> + - const: microchip,sparx5
>> +
>> + - description: The Sparx5 pcb135 is a pizzabox form factor
>> + gigabit switch with 48+4 Cu ports. It features spi-nor and
>> + either spi-nand or eMMC storage (mount option).
>> + items:
>> + - const: microchip,sparx5-pcb135
>> + - const: microchip,sparx5
>> +
>> + axi@600000000:
>> + type: object
>> + description: the root node in the Sparx5 platforms must contain
>> + an axi bus child node. They are always at physical address
>> + 0x600000000 in all the Sparx5 variants.
>> + properties:
>> + compatible:
>> + items:
>> + - const: simple-bus
>> + reg:
>> + maxItems: 1
>
> simple-bus doesn't have 'reg'. If there's bus registers, then it's not
> simple.
>
Ooops, that's a leftover. I'll remove.
>> +
>> + required:
>> + - compatible
>> + - reg
>> +
>> +patternProperties:
>> + "^syscon@[0-9a-f]+$":
>
> This should be under a bus node.
I thought it was? But anyway, with the change below I guess the entire
block goes away.
>
>> + description: All Sparx5 boards must provide a system controller,
>> + typically under the axi bus node. It contain reset registers and
>> + other system control.
>> + type: object
>> + properties:
>> + compatible:
>> + items:
>> + - const: microchip,sparx5-cpu-syscon
>> + - const: syscon
>
> This probably should be in its own document. If really this simple,
> there's already syscon.yaml you can add to.
Good suggestion, I'll add it to mfd/syscon.yaml then.
>
>> + reg:
>> + maxItems: 1
>> +
>> + required:
>> + - compatible
>> + - reg
>> +
>> +required:
>> + - compatible
>> + - axi@600000000
>> + - syscon@600000000
>> +
>> +...
>> --
>> 2.26.2
--
Lars Povlsen,
Microchip
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH 2/4] firmware: imx: add resource management api
From: Aisheng Dong @ 2020-06-02 9:07 UTC (permalink / raw)
To: Peng Fan, shawnguo@kernel.org, s.hauer@pengutronix.de
Cc: festevam@gmail.com, Joakim Zhang, linux@rempel-privat.de,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de,
Leonard Crestez, Daniel Baluta, linux-kernel@vger.kernel.org,
dl-linux-imx
In-Reply-To: <DB6PR0402MB27607F1DD473BE02FC494E9C888B0@DB6PR0402MB2760.eurprd04.prod.outlook.com>
> From: Peng Fan <peng.fan@nxp.com>
> Sent: Tuesday, June 2, 2020 3:48 PM
> >
> > > From: Peng Fan <peng.fan@nxp.com>
> > > Sent: Tuesday, June 2, 2020 12:51 PM
> > > >
> > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > Sent: Monday, June 1, 2020 8:40 PM
> > > > > >
> > > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > > > Sent: Friday, April 24, 2020 9:12 AM
> > > > > > > >
> > > > > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > > > > > Sent: Thursday, April 23, 2020 6:57 PM
> > > > > > > > > > > From: Peng Fan <peng.fan@nxp.com>
> > > > > > > > > > > Sent: Thursday, April 23, 2020 3:00 PM
> > > > > > > > > > >
> > > > > > > > > > > Add resource management API, when we have multiple
> > > > > > > > > > > partition running together, resources not owned to
> > > > > > > > > > > current partition should not be
> > > > > > > > used.
> > > > > > > > > > >
> > > > > > > > > > > Reviewed-by: Leonard Crestez
> > > > > > > > > > > <leonard.crestez@nxp.com>
> > > > > > > > > > > Signed-off-by: Peng Fan <peng.fan@nxp.com>
> > > > > > > > > >
> > > > > > > > > > Right now I'm still not quite understand if we really need this.
> > > > > > > > > > As current resource is bound to power domains, if it's
> > > > > > > > > > not owned by one specific SW execution environment,
> > > > > > > > > > power on will also
> > > > > fail.
> > > > > > > > > > Can you clarify if any exceptions?
> > > > > > > > >
> > > > > > > > > There will be lots of failures when boot Linux domu if no check.
> > > > > > > > >
> > > > > > > >
> > > > > > > > What kind of features did you mean?
> > > > > > > > Could you clarify a bit more? I'd like to understand this
> > > > > > > > issue
> > better.
> > > > > > >
> > > > > > > When supporting hypervisor with dual Linux running, 1st
> > > > > > > Linux and the 2nd Linux will have their own dedicated resources.
> > > > > > >
> > > > > > > If no resource check, that means 1st/2nd Linux will register
> > > > > > > all the resources, then both will see fail logs when
> > > > > > > register resources not owned to
> > > > > > itself.
> > > > > > >
> > > > > > > Same to partitioned m4 case.
> > > > > > >
> > > > > > > Would it be better without the failure log?
> > > > > > >
> > > > > >
> > > > > > Is it power up failure?
> > > > > > If yes, it's expected because we actually use power up to
> > > > > > check if resources are owned by this partition. It functions
> > > > > > the same as calling resource check API.
> > > > > > That's current design.
> > > > > >
> > > > > > Or it's other failures? Log?
> > > > > Sorry for long late reply.
> > > > >
> > > > > Part of my XEN DomU log, there are lots of failure log. I think
> > > > > better not have such logs by add a resource own check.
> > > >
> > > > Those error logs are intended.
> > > > Resource owner check actually behaves the same as power up.
> > >
> > > If resource is not owned, it will not register the power domain.
> > >
> > > Without resource own check, it will continue register the power
> > > domain and hook it into genpd list.
> > >
> >
> > That's the intended behavior to save the resource owner checking as
> > it's very time cost to send SCU cmd for each domain during booting
> > which benefits nothing except not exposing them in genpd list.
> >
> > > I prefer we not expose the power domain not owned to current
> > > partition and keep the err msg for people to easy see where it goes wrong.
> >
> > If we really want to to do, I wonder probably another better approach
> > is trying to re-use the partition Information built by bootloader as
> > uboot already did that one time, not necessary to re-do It again for kernel as
> it's time cost.
> > e.g. introduce a resource partition property in dt and initialized and
> > passed by bootloarder to kernel to use later.
>
> This will not work for hypervisor based VM runtime partition create and
> resource assignment.
>
For VM case, can't we define them in DT if it's statically defined?
> > Then we can still save those huge number of resource owner check CMDs.
>
> So we have to live with them even I only need one SDHC for a VM? With so
> many clk-scu entries and power domain entries there.
No, clk-scu register will fail automatically if not owned by this partition.
Regards
Aisheng
>
> Thanks,
> Peng.
>
> >
> > Regards
> > Aisheng
> >
> > >
> > > Regards,
> > > Peng.
> > > > So not quite necessary to add a double check.
> > > > If we're concerning about the error log, we can change it to dev_dbg().
> > > >
> > > > BTW, as resource management will be needed by seco drivers later,
> > > > So I will continue to review the patch.
> > > >
> > > > Regards
> > > > Aisheng
> > > >
> > > > >
> > > > > [ 2.034774] imx6q-pcie 5f000000.pcie: IO
> > 0x6ff80000..0x6ff8ffff
> > > ->
> > > > > 0x00000000
> > > > > [ 2.034801] imx6q-pcie 5f000000.pcie: MEM
> > > 0x60000000..0x6fefffff
> > > > ->
> > > > > 0x60000000
> > > > > [ 2.035072] sdhc1: failed to power up resource 249 ret -13
> > > > > [ 2.035619] sdhc2: failed to power up resource 250 ret -13
> > > > > [ 2.036126] enet0: failed to power up resource 251 ret -13
> > > > > [ 2.036584] enet1: failed to power up resource 252 ret -13
> > > > > [ 2.037040] mlb0: failed to power up resource 253 ret -13
> > > > > [ 2.037495] nand: failed to power up resource 265 ret -13
> > > > > [ 2.037951] nand: failed to power up resource 265 ret -13
> > > > > [ 2.038416] pwm0: failed to power up resource 191 ret -13
> > > > > [ 2.038868] pwm1: failed to power up resource 192 ret -13
> > > > > [ 2.039320] pwm2: failed to power up resource 193 ret -13
> > > > > [ 2.039786] pwm3: failed to power up resource 194 ret -13
> > > > > [ 2.040239] pwm4: failed to power up resource 195 ret -13
> > > > > [ 2.040692] pwm5: failed to power up resource 196 ret -13
> > > > > [ 2.041142] pwm6: failed to power up resource 197 ret -13
> > > > > [ 2.041596] pwm7: failed to power up resource 198 ret -13
> > > > > [ 2.042073] amix: failed to power up resource 458 ret -13
> > > > > [ 2.042558] lpspi0: failed to power up resource 53 ret -13
> > > > > [ 2.043033] lpspi1: failed to power up resource 54 ret -13
> > > > > [ 2.043501] lpspi2: failed to power up resource 55 ret -13
> > > > > [ 2.043992] lpspi3: failed to power up resource 56 ret -13
> > > > > [ 2.044460] lpuart0: failed to power up resource 57 ret -13
> > > > > [ 2.044935] lpuart2: failed to power up resource 59 ret -13
> > > > > [ 2.045409] lpuart3: failed to power up resource 60 ret -13
> > > > > [ 2.055014] sim0: failed to power up resource 62 ret -13
> > > > > [ 2.055510] adc0: failed to power up resource 101 ret -13
> > > > > [ 2.056467] lpi2c0: failed to power up resource 96 ret -13
> > > > > [ 2.056946] lpi2c1: failed to power up resource 97 ret -13
> > > > > [ 2.057424] lpi2c2: failed to power up resource 98 ret -13
> > > > > [ 2.057898] lpi2c3: failed to power up resource 99 ret -13
> > > > > [ 2.058371] can0: failed to power up resource 105 ret -13
> > > > > [ 2.059289] can1: failed to power up resource 106 ret -13
> > > > > [ 2.059801] can2: failed to power up resource 107 ret -13
> > > > > [ 2.060281] nand: failed to power up resource 265 ret -13
> > > > > [ 2.062764] dpu-core 56180000.dpu: driver probed
> > > > >
> > > > > Thanks,
> > > > > Peng.
> > > > >
> > > > > >
> > > > > > Regards
> > > > > > Aisheng
> > > > > >
> > > > > > > Thanks,
> > > > > > > Peng.
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Regards
> > > > > > > > Aisheng
> > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Peng.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Regards
> > > > > > > > > > Aisheng
> > > > > > > > > >
> > > > > > > > > > > ---
> > > > > > > > > > > drivers/firmware/imx/Makefile | 2 +-
> > > > > > > > > > > drivers/firmware/imx/rm.c | 40
> > > > > > > > +++++++++++++++++++++
> > > > > > > > > > > include/linux/firmware/imx/sci.h | 1 +
> > > > > > > > > > > include/linux/firmware/imx/svc/rm.h | 69
> > > > > > > > > > > +++++++++++++++++++++++++++++++++++++
> > > > > > > > > > > 4 files changed, 111 insertions(+), 1 deletion(-)
> > > > > > > > > > > create mode
> > > > > > > > > > > 100644 drivers/firmware/imx/rm.c create mode 100644
> > > > > > > > > > > include/linux/firmware/imx/svc/rm.h
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/firmware/imx/Makefile
> > > > > > > > > > > b/drivers/firmware/imx/Makefile index
> > > > > > > > > > > 08bc9ddfbdfb..17ea3613e142
> > > > > > > > > > > 100644
> > > > > > > > > > > --- a/drivers/firmware/imx/Makefile
> > > > > > > > > > > +++ b/drivers/firmware/imx/Makefile
> > > > > > > > > > > @@ -1,4 +1,4 @@
> > > > > > > > > > > # SPDX-License-Identifier: GPL-2.0
> > > > > > > > > > > obj-$(CONFIG_IMX_DSP) += imx-dsp.o
> > > > > > > > > > > -obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o
> > > imx-scu-irq.o
> > > > > > > > > > > +obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o
> > > > imx-scu-irq.o
> > > > > > rm.o
> > > > > > > > > > > obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o
> > > > > > > > > > > diff --git a/drivers/firmware/imx/rm.c
> > > > > > > > > > > b/drivers/firmware/imx/rm.c new file mode 100644
> > > > > > > > > > > index
> > > > > > > > > > > 000000000000..7b0334de5486
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/drivers/firmware/imx/rm.c
> > > > > > > > > > > @@ -0,0 +1,40 @@
> > > > > > > > > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > > > > > > > > +/*
> > > > > > > > > > > + * Copyright 2020 NXP
> > > > > > > > > > > + *
> > > > > > > > > > > + * File containing client-side RPC functions for
> > > > > > > > > > > +the RM
> > service.
> > > > > > > > > > > +These
> > > > > > > > > > > + * function are ported to clients that communicate to the SC.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/firmware/imx/svc/rm.h>
> > > > > > > > > > > +
> > > > > > > > > > > +struct imx_sc_msg_rm_rsrc_owned {
> > > > > > > > > > > + struct imx_sc_rpc_msg hdr;
> > > > > > > > > > > + u16 resource;
> > > > > > > > > > > +} __packed __aligned(4);
> > > > > > > > > > > +
> > > > > > > > > > > +/*
> > > > > > > > > > > + * This function check @resource is owned by
> > > > > > > > > > > +current partition or not
> > > > > > > > > > > + *
> > > > > > > > > > > + * @param[in] ipc IPC handle
> > > > > > > > > > > + * @param[in] resource resource the control is
> > > > > > associated
> > > > > > > > with
> > > > > > > > > > > + *
> > > > > > > > > > > + * @return Returns 0 for success and < 0 for errors.
> > > > > > > > > > > + */
> > > > > > > > > > > +bool imx_sc_rm_is_resource_owned(struct imx_sc_ipc
> > > > > > > > > > > +*ipc,
> > > > > > > > > > > +u16
> > > > > > > > > > > +resource) {
> > > > > > > > > > > + struct imx_sc_msg_rm_rsrc_owned msg;
> > > > > > > > > > > + struct imx_sc_rpc_msg *hdr = &msg.hdr;
> > > > > > > > > > > +
> > > > > > > > > > > + hdr->ver = IMX_SC_RPC_VERSION;
> > > > > > > > > > > + hdr->svc = IMX_SC_RPC_SVC_RM;
> > > > > > > > > > > + hdr->func = IMX_SC_RM_FUNC_IS_RESOURCE_OWNED;
> > > > > > > > > > > + hdr->size = 2;
> > > > > > > > > > > +
> > > > > > > > > > > + msg.resource = resource;
> > > > > > > > > > > +
> > > > > > > > > > > + imx_scu_call_rpc(ipc, &msg, true);
> > > > > > > > > > > +
> > > > > > > > > > > + return hdr->func;
> > > > > > > > > > > +}
> > > > > > > > > > > +EXPORT_SYMBOL(imx_sc_rm_is_resource_owned);
> > > > > > > > > > > diff --git a/include/linux/firmware/imx/sci.h
> > > > > > > > > > > b/include/linux/firmware/imx/sci.h
> > > > > > > > > > > index 17ba4e405129..b5c5a56f29be 100644
> > > > > > > > > > > --- a/include/linux/firmware/imx/sci.h
> > > > > > > > > > > +++ b/include/linux/firmware/imx/sci.h
> > > > > > > > > > > @@ -15,6 +15,7 @@
> > > > > > > > > > >
> > > > > > > > > > > #include <linux/firmware/imx/svc/misc.h> #include
> > > > > > > > > > > <linux/firmware/imx/svc/pm.h>
> > > > > > > > > > > +#include <linux/firmware/imx/svc/rm.h>
> > > > > > > > > > >
> > > > > > > > > > > int imx_scu_enable_general_irq_channel(struct
> > > > > > > > > > > device *dev); int
> > > > > > > > > > > imx_scu_irq_register_notifier(struct
> > > > > > > > > > > notifier_block *nb); diff --git
> > > > > > > > > > > a/include/linux/firmware/imx/svc/rm.h
> > > > > > > > > > > b/include/linux/firmware/imx/svc/rm.h
> > > > > > > > > > > new file mode 100644 index
> > > > > > > > > > > 000000000000..fc6ea62d9d0e
> > > > > > > > > > > --- /dev/null
> > > > > > > > > > > +++ b/include/linux/firmware/imx/svc/rm.h
> > > > > > > > > > > @@ -0,0 +1,69 @@
> > > > > > > > > > > +/* SPDX-License-Identifier: GPL-2.0+ */
> > > > > > > > > > > +/*
> > > > > > > > > > > + * Copyright (C) 2016 Freescale Semiconductor, Inc.
> > > > > > > > > > > + * Copyright 2017-2019 NXP
> > > > > > > > > > > + *
> > > > > > > > > > > + * Header file containing the public API for the
> > > > > > > > > > > +System Controller
> > > > > > > > > > > +(SC)
> > > > > > > > > > > + * Power Management (PM) function. This includes
> > > > > > > > > > > +functions for power state
> > > > > > > > > > > + * control, clock control, reset control, and
> > > > > > > > > > > +wake-up event
> > > > control.
> > > > > > > > > > > + *
> > > > > > > > > > > + * RM_SVC (SVC) Resource Management Service
> > > > > > > > > > > + *
> > > > > > > > > > > + * Module for the Resource Management (RM) service.
> > > > > > > > > > > + */
> > > > > > > > > > > +
> > > > > > > > > > > +#ifndef _SC_RM_API_H #define _SC_RM_API_H
> > > > > > > > > > > +
> > > > > > > > > > > +#include <linux/firmware/imx/sci.h>
> > > > > > > > > > > +
> > > > > > > > > > > +/*
> > > > > > > > > > > + * This type is used to indicate RPC RM function calls.
> > > > > > > > > > > + */
> > > > > > > > > > > +enum imx_sc_rm_func {
> > > > > > > > > > > + IMX_SC_RM_FUNC_UNKNOWN = 0,
> > > > > > > > > > > + IMX_SC_RM_FUNC_PARTITION_ALLOC = 1,
> > > > > > > > > > > + IMX_SC_RM_FUNC_SET_CONFIDENTIAL = 31,
> > > > > > > > > > > + IMX_SC_RM_FUNC_PARTITION_FREE = 2,
> > > > > > > > > > > + IMX_SC_RM_FUNC_GET_DID = 26,
> > > > > > > > > > > + IMX_SC_RM_FUNC_PARTITION_STATIC = 3,
> > > > > > > > > > > + IMX_SC_RM_FUNC_PARTITION_LOCK = 4,
> > > > > > > > > > > + IMX_SC_RM_FUNC_GET_PARTITION = 5,
> > > > > > > > > > > + IMX_SC_RM_FUNC_SET_PARENT = 6,
> > > > > > > > > > > + IMX_SC_RM_FUNC_MOVE_ALL = 7,
> > > > > > > > > > > + IMX_SC_RM_FUNC_ASSIGN_RESOURCE = 8,
> > > > > > > > > > > + IMX_SC_RM_FUNC_SET_RESOURCE_MOVABLE = 9,
> > > > > > > > > > > + IMX_SC_RM_FUNC_SET_SUBSYS_RSRC_MOVABLE = 28,
> > > > > > > > > > > + IMX_SC_RM_FUNC_SET_MASTER_ATTRIBUTES = 10,
> > > > > > > > > > > + IMX_SC_RM_FUNC_SET_MASTER_SID = 11,
> > > > > > > > > > > + IMX_SC_RM_FUNC_SET_PERIPHERAL_PERMISSIONS =
> > 12,
> > > > > > > > > > > + IMX_SC_RM_FUNC_IS_RESOURCE_OWNED = 13,
> > > > > > > > > > > + IMX_SC_RM_FUNC_GET_RESOURCE_OWNER = 33,
> > > > > > > > > > > + IMX_SC_RM_FUNC_IS_RESOURCE_MASTER = 14,
> > > > > > > > > > > + IMX_SC_RM_FUNC_IS_RESOURCE_PERIPHERAL = 15,
> > > > > > > > > > > + IMX_SC_RM_FUNC_GET_RESOURCE_INFO = 16,
> > > > > > > > > > > + IMX_SC_RM_FUNC_MEMREG_ALLOC = 17,
> > > > > > > > > > > + IMX_SC_RM_FUNC_MEMREG_SPLIT = 29,
> > > > > > > > > > > + IMX_SC_RM_FUNC_MEMREG_FRAG = 32,
> > > > > > > > > > > + IMX_SC_RM_FUNC_MEMREG_FREE = 18,
> > > > > > > > > > > + IMX_SC_RM_FUNC_FIND_MEMREG = 30,
> > > > > > > > > > > + IMX_SC_RM_FUNC_ASSIGN_MEMREG = 19,
> > > > > > > > > > > + IMX_SC_RM_FUNC_SET_MEMREG_PERMISSIONS = 20,
> > > > > > > > > > > + IMX_SC_RM_FUNC_IS_MEMREG_OWNED = 21,
> > > > > > > > > > > + IMX_SC_RM_FUNC_GET_MEMREG_INFO = 22,
> > > > > > > > > > > + IMX_SC_RM_FUNC_ASSIGN_PAD = 23,
> > > > > > > > > > > + IMX_SC_RM_FUNC_SET_PAD_MOVABLE = 24,
> > > > > > > > > > > + IMX_SC_RM_FUNC_IS_PAD_OWNED = 25,
> > > > > > > > > > > + IMX_SC_RM_FUNC_DUMP = 27, };
> > > > > > > > > > > +
> > > > > > > > > > > +#if IS_ENABLED(CONFIG_IMX_SCU) bool
> > > > > > > > > > > +imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc,
> > > > > > > > > > > +u16 resource); #else static inline bool
> > > > > > > > > > > +imx_sc_rm_is_resource_owned(struct imx_sc_ipc *ipc,
> > > > > > > > > > > +u16
> > > > > > resource) {
> > > > > > > > > > > + return true;
> > > > > > > > > > > +}
> > > > > > > > > > > +#endif
> > > > > > > > > > > +#endif
> > > > > > > > > > > --
> > > > > > > > > > > 2.16.4
_______________________________________________
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 5/5] PCI: uniphier: Add error message when failed to get phy
From: Kunihiko Hayashi @ 2020-06-02 9:07 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Lorenzo Pieralisi, Masami Hiramatsu, Jassi Brar,
Jingoo Han, linux-kernel, Masahiro Yamada, linux-pci,
Bjorn Helgaas, Gustavo Pimentel, linux-arm-kernel
In-Reply-To: <20200601214302.GA1538223@bogus>
Hi Rob,
On 2020/06/02 6:43, Rob Herring wrote:
> On Fri, May 15, 2020 at 06:59:03PM +0900, Kunihiko Hayashi wrote:
>> Even if phy driver doesn't probe, the error message can't be distinguished
>> from other errors. This displays error message caused by the phy driver
>> explicitly.
>>
>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>> ---
>> drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++--
>> 1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
>> index 493f105..7ae9688 100644
>> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
>> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
>> @@ -468,8 +468,11 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
>> return PTR_ERR(priv->rst);
>>
>> priv->phy = devm_phy_optional_get(dev, "pcie-phy");
>> - if (IS_ERR(priv->phy))
>> - return PTR_ERR(priv->phy);
>> + if (IS_ERR(priv->phy)) {
>> + ret = PTR_ERR(priv->phy);
>> + dev_err(dev, "Failed to get phy (%d)\n", ret);
>
> This will print an error on EPROBE_DEFERRED which isn't an error.
Thanks for pointing out.
Surely this message should be suppressed when returning EPROBE_DEFERRED.
Thank you,
---
Best Regards
Kunihiko Hayashi
_______________________________________________
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 4/5] PCI: uniphier: Add iATU register support
From: Kunihiko Hayashi @ 2020-06-02 9:07 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Lorenzo Pieralisi, Masami Hiramatsu, Jassi Brar,
Jingoo Han, linux-kernel, Masahiro Yamada, linux-pci,
Bjorn Helgaas, Gustavo Pimentel, linux-arm-kernel
In-Reply-To: <20200601213215.GA1521885@bogus>
Hi Rob,
On 2020/06/02 6:32, Rob Herring wrote:
> On Fri, May 15, 2020 at 06:59:02PM +0900, Kunihiko Hayashi wrote:
>> This gets iATU register area from reg property. In Synopsis DWC version
>> 4.80 or later, since iATU register area is separated from core register
>> area, this area is necessary to get from DT independently.
>>
>> Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
>> ---
>> drivers/pci/controller/dwc/pcie-uniphier.c | 7 +++++++
>> 1 file changed, 7 insertions(+)
>>
>> diff --git a/drivers/pci/controller/dwc/pcie-uniphier.c b/drivers/pci/controller/dwc/pcie-uniphier.c
>> index a8dda39..493f105 100644
>> --- a/drivers/pci/controller/dwc/pcie-uniphier.c
>> +++ b/drivers/pci/controller/dwc/pcie-uniphier.c
>> @@ -447,6 +447,13 @@ static int uniphier_pcie_probe(struct platform_device *pdev)
>> if (IS_ERR(priv->pci.dbi_base))
>> return PTR_ERR(priv->pci.dbi_base);
>>
>> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "atu");
>> + if (res) {
>> + priv->pci.atu_base = devm_pci_remap_cfg_resource(dev, res);
>
> This isn't config space, so this function shouldn't be used.
>
> Use devm_platform_ioremap_resource_byname().
Indeed. I'll replace with it.
>> + if (IS_ERR(priv->pci.atu_base))
>> + priv->pci.atu_base = NULL;
>> + }
>> +
>> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "link");
>> priv->base = devm_ioremap_resource(dev, res);
>
> Feel free to convert this one too.
This should be replaced as well.
Thank you,
---
Best Regards
Kunihiko Hayashi
_______________________________________________
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 3/3] iio: remove iio_triggered_buffer_postenable()/iio_triggered_buffer_predisable()
From: Jonathan Cameron @ 2020-06-02 8:54 UTC (permalink / raw)
To: Ardelean, Alexandru
Cc: lars@metafoo.de, alexandre.torgue@st.com,
linux-iio@vger.kernel.org, s.hauer@pengutronix.de,
linux-kernel@vger.kernel.org, songqiang1304521@gmail.com,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org, mcoquelin.stm32@gmail.com,
lorenzo.bianconi83@gmail.com, shawnguo@kernel.org,
linus.walleij@linaro.org, jic23@kernel.org
In-Reply-To: <a0253d719a4390f65668789e5fc182ec19355f17.camel@analog.com>
On Tue, 2 Jun 2020 07:50:23 +0000
"Ardelean, Alexandru" <alexandru.Ardelean@analog.com> wrote:
> On Sun, 2020-05-31 at 16:40 +0100, Jonathan Cameron wrote:
> > On Mon, 25 May 2020 14:38:55 +0300
> > Alexandru Ardelean <alexandru.ardelean@analog.com> wrote:
> >
> > > From: Lars-Peter Clausen <lars@metafoo.de>
> > >
> > > This patch should be squashed into the first one, as the first one is
> > > breaking the build (intentionally) to make the IIO core files easier to
> > > review.
> > >
> > > Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
> > > Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> > > ---
> >
> > Friend poke. Version log?
>
> Version log is in the first patch.
> I was wondering if I omitted it.
> Seems, this time I didn't. But I admit, it probably would have been better
> here.
Ah fair enough. That works fine if there is a cover letter but not
so much just putting things in the first patch!
>
> >
> > Other than the wistful comment below (which I'm not expecting you to
> > do anything about btw!) whole series looks good to me.
> >
> > These are obviously no functional changes (I think) so it's only really
> > patch 2 that
> > could do with more eyes and acks.
> >
> > Far as I can tell that case is fine as well because of the protections
> > on being in the right mode, but more eyes on that would be great.
> >
> > So assuming that's fine, what commit message do you want me to use for
> > the fused single patch?
>
> Commit message-wise: I think the message in the first commit would be
> mostly sufficient.
> No idea what other description would be needed.
>
> So, maybe something like:
>
> ----------------------------------------------------------------------
> All devices using a triggered buffer need to attach and detach the trigger
> to the device in order to properly work. Instead of doing this in each and
> every driver by hand move this into the core.
>
> At this point in time, all drivers should have been resolved to
> attach/detach the poll-function in the same order.
>
> This patch removes all explicit calls of iio_triggered_buffer_postenable()
> & iio_triggered_buffer_predisable() in all drivers, since the core handles
> now the pollfunc attach/detach.
>
> The more peculiar change is for the 'at91-sama5d2_adc' driver, since it's
> not obvious that removing the hooks doesn't break anything**
> ----------------------------------------------------------------------
>
Looks good.
> ** for the comment about 'at91-sama5d2_adc', we really do need to get some
> testing; otherwise this risks breaking it.
Agreed.
>
>
> >
> > Thanks,
> >
> > Jonathan
> >
> > > static const struct iio_trigger_ops atlas_interrupt_trigger_ops = {
> > > diff --git a/drivers/iio/dummy/iio_simple_dummy_buffer.c
> > > b/drivers/iio/dummy/iio_simple_dummy_buffer.c
> > > index 17606eca42b4..8e13c53d4360 100644
> > > --- a/drivers/iio/dummy/iio_simple_dummy_buffer.c
> > > +++ b/drivers/iio/dummy/iio_simple_dummy_buffer.c
> > > @@ -99,20 +99,6 @@ static irqreturn_t iio_simple_dummy_trigger_h(int
> > > irq, void *p)
> > > }
> > >
> > > static const struct iio_buffer_setup_ops
> > > iio_simple_dummy_buffer_setup_ops = {
> > > - /*
> > > - * iio_triggered_buffer_postenable:
> > > - * Generic function that simply attaches the pollfunc to the
> > > trigger.
> > > - * Replace this to mess with hardware state before we attach the
> > > - * trigger.
> > > - */
> > > - .postenable = &iio_triggered_buffer_postenable,
> > > - /*
> > > - * iio_triggered_buffer_predisable:
> > > - * Generic function that simple detaches the pollfunc from the
> > > trigger.
> > > - * Replace this to put hardware state back again after the trigger
> > > is
> > > - * detached but before userspace knows we have disabled the ring.
> > > - */
> > > - .predisable = &iio_triggered_buffer_predisable,
> > > };
> > >
> > Hmm. Guess we should probably 'invent' a reason to illustrate the bufer
> > ops in the dummy example. Anyone feeling creative?
> _______________________________________________
> 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 v4 1/4] KEYS: trusted: Add generic trusted keys framework
From: Sumit Garg @ 2020-06-02 8:40 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: tee-dev @ lists . linaro . org, Daniel Thompson, op-tee,
Jonathan Corbet, James Bottomley, Janne Karhunen,
Linux Doc Mailing List, James Morris, Mimi Zohar,
Linux Kernel Mailing List, dhowells, linux-security-module,
open list:ASYMMETRIC KEYS, Markus Wamser, Casey Schaufler,
linux-integrity, Jens Wiklander, linux-arm-kernel,
Serge E. Hallyn
In-Reply-To: <20200602071407.GB16602@linux.intel.com>
On Tue, 2 Jun 2020 at 12:44, Jarkko Sakkinen
<jarkko.sakkinen@linux.intel.com> wrote:
>
> On Mon, Jun 01, 2020 at 02:41:55PM +0530, Sumit Garg wrote:
> > > This, I think is wrong. You should have a compile time flag for TPM e.g.
> > > CONFIG_TRUSTED_TPM, not this dynamic mess.
> > >
> >
> > The whole idea to have it dynamic was to have a common trusted keys
> > module which could support both TPM and TEE implementation depending
> > on hardware. I guess it may be useful in scenarios where a particular
> > hardware supports a TPM chip while other doesn't but both need to run
> > a common kernel image.
>
> For now it should only scale to what is needed. No problems refining
> it later when there is something to enable.
>
Fair enough, will switch to compile time mode then.
-Sumit
> /Jarkko
_______________________________________________
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 10/14] dt-bindings: clock: sparx5: Add Sparx5 SoC DPLL clock
From: Lars Povlsen @ 2020-06-02 8:39 UTC (permalink / raw)
To: Rob Herring
Cc: devicetree, Alexandre Belloni, Arnd Bergmann, linux-gpio,
Stephen Boyd, Steen Hegelund, linux-clk, linux-kernel,
Microchip Linux Driver Support, Michael Turquette, SoC Team,
linux-arm-kernel, Olof Johansson, Linus Walleij, Lars Povlsen
In-Reply-To: <20200528021826.GA3221035@bogus>
Rob Herring writes:
> On Wed, May 13, 2020 at 02:55:28PM +0200, Lars Povlsen wrote:
>> This add the DT bindings documentation for the Sparx5 SoC DPLL clock
>>
>> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
>> Signed-off-by: Lars Povlsen <lars.povlsen@microchip.com>
>> ---
>> .../bindings/clock/microchip,sparx5-dpll.yaml | 46 +++++++++++++++++++
>> 1 file changed, 46 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
>>
>> diff --git a/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml b/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
>> new file mode 100644
>> index 0000000000000..594007d8fc59a
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/microchip,sparx5-dpll.yaml
>> @@ -0,0 +1,46 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/microchip,sparx5-dpll.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Microchip Sparx5 DPLL Clock
>> +
>> +maintainers:
>> + - Lars Povlsen <lars.povlsen@microchip.com>
>> +
>> +description: |
>> + The Sparx5 DPLL clock controller generates and supplies clock to
>> + various peripherals within the SoC.
>> +
>> + This binding uses common clock bindings
>> + [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
>> +
>> +properties:
>> + compatible:
>> + const: microchip,sparx5-dpll
>> +
>> + reg:
>> + items:
>> + - description: dpll registers
>
> For a single entry, just:
>
> maxItems: 1
Ok.
>
>> +
>> + '#clock-cells':
>> + const: 1
>> +
>> +required:
>> + - compatible
>> + - reg
>> + - '#clock-cells'
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + # Clock provider for eMMC:
>> + - |
>> + clks: clks@61110000c {
>
> clock-controller@1110000c {
>
Got that.
>> + compatible = "microchip,sparx5-dpll";
>> + #clock-cells = <1>;
>> + reg = <0x1110000c 0x24>;
>
> Looks like this is a sub-block in some other h/w block. What's the
> parent device? That should be described and this should be part of it
> either as a single node or a child node. Without a complete view of what
> this block has I can't provide any guidance.
No, as Alex noted to a similar comment in the temp. sensor driver, the
chip is using packed register spaces predominantly. So don't put too
much into the register offsets.
---Lars
>
> Rob
--
Lars Povlsen,
Microchip
_______________________________________________
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/6] mfd: add support for the Khadas System control Microcontroller
From: Lee Jones @ 2020-06-02 8:33 UTC (permalink / raw)
To: Neil Armstrong; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, linux-pm
In-Reply-To: <8837fa43-bf46-fdd1-472e-e5f0159dab2c@baylibre.com>
On Tue, 02 Jun 2020, Neil Armstrong wrote:
> On 20/05/2020 11:01, Lee Jones wrote:
> > On Tue, 12 May 2020, Neil Armstrong wrote:
> >
> >> This Microcontroller is present on the Khadas VIM1, VIM2, VIM3 and Edge
> >> boards.
> >>
> >> It has multiple boot control features like password check, power-on
> >> options, power-off control and system FAN control on recent boards.
> >>
> >> This implements a very basic MFD driver with the fan control and User
> >> NVMEM cells.
> >>
> >> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> >> ---
> >> drivers/mfd/Kconfig | 14 ++++
> >> drivers/mfd/Makefile | 1 +
> >> drivers/mfd/khadas-mcu.c | 143 +++++++++++++++++++++++++++++++++
> >> include/linux/mfd/khadas-mcu.h | 91 +++++++++++++++++++++
> >> 4 files changed, 249 insertions(+)
> >> create mode 100644 drivers/mfd/khadas-mcu.c
> >> create mode 100644 include/linux/mfd/khadas-mcu.h
> >>
> >> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> >> index 0a59249198d3..b95091397052 100644
> >> --- a/drivers/mfd/Kconfig
> >> +++ b/drivers/mfd/Kconfig
> >> @@ -2003,6 +2003,20 @@ config MFD_WCD934X
> >> This driver provides common support WCD934x audio codec and its
> >> associated Pin Controller, Soundwire Controller and Audio codec.
> >>
> >> +config MFD_KHADAS_MCU
> >> + tristate "Support for Khadas System control Microcontroller"
> >> + depends on I2C
> >> + depends on OF || COMPILE_TEST
> >> + select MFD_CORE
> >> + select REGMAP_I2C
> >> + help
> >> + Support for the Khadas System control Microcontroller interface present
> >> + on their VIM and Edge boards.
> >> +
> >> + This driver provides common support for accessing the device,
> >> + additional drivers must be enabled in order to use the functionality
> >> + of the device.
> >
> > It would be good to describe the device here.
>
> Ok
If you agree with all review comments, there really is no need to
reply. It's a waste of your time and anyone else who cares enough to
search through looking for replies (as I just did).
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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] media: stm32-dcmi: Set minimum cpufreq requirement
From: Hugues FRUCHET @ 2020-06-02 8:29 UTC (permalink / raw)
To: Benjamin GAIGNARD, mchehab@kernel.org, mcoquelin.stm32@gmail.com,
Alexandre TORGUE
Cc: rjw@rjwysocki.net, linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
valentin.schneider@arm.com, linux-arm-kernel@lists.infradead.org,
linux-media@vger.kernel.org
In-Reply-To: <20200527151613.16083-1-benjamin.gaignard@st.com>
Acked-by: Hugues Fruchet <hugues.fruchet@st.com>
On 5/27/20 5:16 PM, Benjamin Gaignard wrote:
> Before start streaming set cpufreq minimum frequency requirement.
> The cpufreq governor will adapt the frequencies and we will have
> no latency for handling interrupts.
>
> Signed-off-by: Benjamin Gaignard <benjamin.gaignard@st.com>
> ---
> drivers/media/platform/stm32/stm32-dcmi.c | 29 ++++++++++++++++++++++++++++-
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/stm32/stm32-dcmi.c b/drivers/media/platform/stm32/stm32-dcmi.c
> index b8931490b83b..97c342351569 100644
> --- a/drivers/media/platform/stm32/stm32-dcmi.c
> +++ b/drivers/media/platform/stm32/stm32-dcmi.c
> @@ -13,6 +13,7 @@
>
> #include <linux/clk.h>
> #include <linux/completion.h>
> +#include <linux/cpufreq.h>
> #include <linux/delay.h>
> #include <linux/dmaengine.h>
> #include <linux/init.h>
> @@ -99,6 +100,8 @@ enum state {
>
> #define OVERRUN_ERROR_THRESHOLD 3
>
> +#define DCMI_MIN_FREQ 650000 /* in KHz */
> +
> struct dcmi_graph_entity {
> struct v4l2_async_subdev asd;
>
> @@ -173,6 +176,10 @@ struct stm32_dcmi {
> struct media_device mdev;
> struct media_pad vid_cap_pad;
> struct media_pipeline pipeline;
> +
> + /* CPU freq contraint */
> + struct cpufreq_policy *policy;
> + struct freq_qos_request qos_req;
> };
>
> static inline struct stm32_dcmi *notifier_to_dcmi(struct v4l2_async_notifier *n)
> @@ -736,11 +743,20 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
> goto err_release_buffers;
> }
>
> + if (dcmi->policy) {
> + ret = freq_qos_add_request(&dcmi->policy->constraints,
> + &dcmi->qos_req, FREQ_QOS_MIN,
> + DCMI_MIN_FREQ);
> +
> + if (ret < 0)
> + goto err_pm_put;
> + }
> +
> ret = media_pipeline_start(&dcmi->vdev->entity, &dcmi->pipeline);
> if (ret < 0) {
> dev_err(dcmi->dev, "%s: Failed to start streaming, media pipeline start error (%d)\n",
> __func__, ret);
> - goto err_pm_put;
> + goto err_drop_qos;
> }
>
> ret = dcmi_pipeline_start(dcmi);
> @@ -835,6 +851,9 @@ static int dcmi_start_streaming(struct vb2_queue *vq, unsigned int count)
> err_media_pipeline_stop:
> media_pipeline_stop(&dcmi->vdev->entity);
>
> +err_drop_qos:
> + if (dcmi->policy)
> + freq_qos_remove_request(&dcmi->qos_req);
> err_pm_put:
> pm_runtime_put(dcmi->dev);
>
> @@ -863,6 +882,9 @@ static void dcmi_stop_streaming(struct vb2_queue *vq)
>
> media_pipeline_stop(&dcmi->vdev->entity);
>
> + if (dcmi->policy)
> + freq_qos_remove_request(&dcmi->qos_req);
> +
> spin_lock_irq(&dcmi->irqlock);
>
> /* Disable interruptions */
> @@ -2020,6 +2042,8 @@ static int dcmi_probe(struct platform_device *pdev)
> goto err_cleanup;
> }
>
> + dcmi->policy = cpufreq_cpu_get(0);
> +
> dev_info(&pdev->dev, "Probe done\n");
>
> platform_set_drvdata(pdev, dcmi);
> @@ -2049,6 +2073,9 @@ static int dcmi_remove(struct platform_device *pdev)
>
> pm_runtime_disable(&pdev->dev);
>
> + if (dcmi->policy)
> + cpufreq_cpu_put(dcmi->policy);
> +
> v4l2_async_notifier_unregister(&dcmi->notifier);
> v4l2_async_notifier_cleanup(&dcmi->notifier);
> media_entity_cleanup(&dcmi->vdev->entity);
>
_______________________________________________
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 4/6] nvmem: add support for the Khadas MCU Programmable User Memory
From: Neil Armstrong @ 2020-06-02 8:29 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: linux-amlogic, linux-kernel, linux-arm-kernel, linux-pm
In-Reply-To: <5f24e094-088b-5787-f1be-158ab9412812@linaro.org>
On 15/05/2020 12:55, Srinivas Kandagatla wrote:
>
>
> On 13/05/2020 13:33, Neil Armstrong wrote:
>> On 13/05/2020 12:34, Srinivas Kandagatla wrote:
>>>
>>>
>>> On 12/05/2020 14:26, Neil Armstrong wrote:
>>>> The new Khadas VIM2, VIM3 and Edge boards embeds an on-board microcontroller
>>>> offering a 56bytes User Programmable NVMEM array.
>>>>
>>>> This array needs a password to be writable, thus a password sysfs file
>>>> has been added on the device node to unlock the NVMEM.
>>>
>>> Is this one time programmable? Or does it need to be unlocked for every read/write?
>>
>> It can be rewritten, and needs the password to read & write.
>>
>>>
>>> How can you make sure that the memory is unlocked before making attempt to read/write?
>>
>> The only way to know it's unlock is reading back the password when unlocked.
>
>
> Current code has no such checks for every read/write?
> and looks very disconnected w.r.t to password and read/writes.
>
> If user attempts to read/write he will not be aware that he should program the password first!
>
> Also if the password is static or un-changed then why not just statically program this from the driver rather than providing sysfs file?
The passworsd can be changed, how should this be taken in account ?
>
> I dont see how kernel nvmem read/write interface can make sure that memory is unlocked?
Not sure how to be sure, if locked all the user memory and password is read as 0xff
>
> Who is the real consumer for this provider?
well, it's more user-space, indeed without the in-kernel password unlock, kernel won't be able
to make great use of the data.
I'll drop for next serie until we have a clearer view.
Neil
>
> --srini
>
>
>>
>>>
>>>>
>>>> The default 6bytes password id: "Khadas"
>>>>
>>>> This implements the user NVMEM devices as cell of the Khadas MCU MFD driver.
>>>>
>>>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>>>> ---
>>>> drivers/nvmem/Kconfig | 8 ++
>>>> drivers/nvmem/Makefile | 2 +
>>>> drivers/nvmem/khadas-mcu-user-mem.c | 128 ++++++++++++++++++++++++++++
>>>> 3 files changed, 138 insertions(+)
>>>> create mode 100644 drivers/nvmem/khadas-mcu-user-mem.c
>>>>
>>>> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
>>>> index d7b7f6d688e7..92cd4f6aa931 100644
>>>> --- a/drivers/nvmem/Kconfig
>>>> +++ b/drivers/nvmem/Kconfig
>>>> @@ -67,6 +67,14 @@ config JZ4780_EFUSE
>>>> To compile this driver as a module, choose M here: the module
>>>> will be called nvmem_jz4780_efuse.
>>>> +config NVMEM_KHADAS_MCU_USER_MEM
>>>> + tristate "Khadas MCU User programmable memory support"
>>>> + depends on MFD_KHADAS_MCU
>>>> + depends on REGMAP
>>>> + help
>>>> + This is a driver for the MCU User programmable memory
>>>> + available on the Khadas VIM and Edge boards.
>>>> +
>>>> config NVMEM_LPC18XX_EEPROM
>>>> tristate "NXP LPC18XX EEPROM Memory Support"
>>>> depends on ARCH_LPC18XX || COMPILE_TEST
>>>> diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
>>>> index a7c377218341..0516a309542d 100644
>>>> --- a/drivers/nvmem/Makefile
>>>> +++ b/drivers/nvmem/Makefile
>>>> @@ -17,6 +17,8 @@ obj-$(CONFIG_NVMEM_IMX_OCOTP_SCU) += nvmem-imx-ocotp-scu.o
>>>> nvmem-imx-ocotp-scu-y := imx-ocotp-scu.o
>>>> obj-$(CONFIG_JZ4780_EFUSE) += nvmem_jz4780_efuse.o
>>>> nvmem_jz4780_efuse-y := jz4780-efuse.o
>>>> +obj-$(CONFIG_NVMEM_KHADAS_MCU_USER_MEM) += nvmem-khadas-mcu-user-mem.o
>>>> +nvmem-khadas-mcu-user-mem-y := khadas-mcu-user-mem.o
>>>> obj-$(CONFIG_NVMEM_LPC18XX_EEPROM) += nvmem_lpc18xx_eeprom.o
>>>> nvmem_lpc18xx_eeprom-y := lpc18xx_eeprom.o
>>>> obj-$(CONFIG_NVMEM_LPC18XX_OTP) += nvmem_lpc18xx_otp.o
>>>> diff --git a/drivers/nvmem/khadas-mcu-user-mem.c b/drivers/nvmem/khadas-mcu-user-mem.c
>>>> new file mode 100644
>>>> index 000000000000..a1d5ae9a030c
>>>> --- /dev/null
>>>> +++ b/drivers/nvmem/khadas-mcu-user-mem.c
>>>> @@ -0,0 +1,128 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * Driver for Khadas MCU User programmable Memory
>>>> + *
>>>> + * Copyright (C) 2020 BayLibre SAS
>>>> + * Author(s): Neil Armstrong <narmstrong@baylibre.com>
>>>> + */
>>>> +
>>>> +#include <linux/clk.h>
>>>
>>> Why do we need this header?
>>
>> Will drop
>>
>>>
>>>> +#include <linux/module.h>
>>>> +#include <linux/nvmem-provider.h>
>>>> +#include <linux/mfd/khadas-mcu.h>
>>>> +#include <linux/regmap.h>
>>>> +#include <linux/of.h>
>>>> +#include <linux/platform_device.h>
>>>> +
>>>> +static int khadas_mcu_user_mem_read(void *context, unsigned int offset,
>>>> + void *val, size_t bytes)
>>>> +{
>>>> + struct khadas_mcu *khadas_mcu = context;
>>>> +
>>>> + return regmap_bulk_read(khadas_mcu->map,
>>>> + KHADAS_MCU_USER_DATA_0_REG + offset,
>>>> + val, bytes);
>>>> +}
>>>> +
>>>> +static int khadas_mcu_user_mem_write(void *context, unsigned int offset,
>>>> + void *val, size_t bytes)
>>>> +{
>>>> + struct khadas_mcu *khadas_mcu = context;
>>>> +
>>>> + return regmap_bulk_write(khadas_mcu->map,
>>>> + KHADAS_MCU_USER_DATA_0_REG + offset,
>>>> + val, bytes);
>>>> +}
>>>> +
>>>> +static ssize_t password_store(struct device *dev, struct device_attribute *attr,
>>>> + const char *buf, size_t count)
>>>> +{
>>>> + struct khadas_mcu *khadas_mcu = dev_get_drvdata(dev);
>>>> + int i, ret;
>>>> +
>>>> + if (count < 6)
>>>> + return -EINVAL;
>>>
>>> Possibly this magic 6 value needs proper define. An additional check here for > 6 would be better as well.
>>
>> Ok
>>
>>>
>>>> +
>>>> + ret = regmap_write(khadas_mcu->map, KHADAS_MCU_PASSWD_START_REG, 1);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + for (i = 0 ; i < 6 ; ++i) {
>>>> + ret = regmap_write(khadas_mcu->map,
>>>> + KHADAS_MCU_CHECK_USER_PASSWD_REG,
>>>> + buf[i]);
>>>> + if (ret)
>>>> + goto out;
>>>> + }
>>>> +
>>>> + ret = regmap_write(khadas_mcu->map, KHADAS_MCU_PASSWD_START_REG, 0);
>>>> + if (ret)
>>>> + return ret;
>>>> +
>>>> + return count;
>>>> +out:
>>>> + regmap_write(khadas_mcu->map, KHADAS_MCU_PASSWD_START_REG, 0);
>>>> +
>>>> + return ret;
>>>> +}
>>>> +
>>>> +static DEVICE_ATTR_WO(password);
>>>> +
>>>> +static struct attribute *khadas_mcu_user_mem_sysfs_attributes[] = {
>>>> + &dev_attr_password.attr,
>>>> + NULL,
>>>> +};
>>>> +
>>>> +static const struct attribute_group khadas_mcu_user_mem_sysfs_attr_group = {
>>>> + .attrs = khadas_mcu_user_mem_sysfs_attributes,
>>>> +};
>>>> +
>>>> +static int khadas_mcu_user_mem_probe(struct platform_device *pdev)
>>>> +{
>>>> + struct khadas_mcu *khadas_mcu = dev_get_drvdata(pdev->dev.parent);
>>>
>>> You could probably get away with dependency of this structure and the header itself by directly getting hold of regmap from parent device.
>>
>> Ok
>>
>>>
>>>
>>>> + struct device *dev = &pdev->dev;
>>>> + struct nvmem_device *nvmem;
>>>> + struct nvmem_config *econfig;
>>>> +
>>>> + econfig = devm_kzalloc(dev, sizeof(*econfig), GFP_KERNEL);
>>>> + if (!econfig)
>>>> + return -ENOMEM;
>>>> +
>>>> + econfig->dev = pdev->dev.parent;
>>>> + econfig->name = dev_name(pdev->dev.parent);
>>>> + econfig->stride = 1;
>>>> + econfig->word_size = 1;
>>>> + econfig->reg_read = khadas_mcu_user_mem_read;
>>>> + econfig->reg_write = khadas_mcu_user_mem_write;
>>>> + econfig->size = 56;
>>> define 56 to make it more readable!
>>
>> Ok
>>
>>>
>>>> + econfig->priv = khadas_mcu;
>>>> +
>>>> + platform_set_drvdata(pdev, khadas_mcu);
>>>> +
>>>> + nvmem = devm_nvmem_register(&pdev->dev, econfig);
>>>> + if (IS_ERR(nvmem))
>>>> + return PTR_ERR(nvmem);
>>>> +
>>>> + return sysfs_create_group(&pdev->dev.kobj,
>>>> + &khadas_mcu_user_mem_sysfs_attr_group);
>>>> +}
>>>> +
>>>> +static const struct platform_device_id khadas_mcu_user_mem_id_table[] = {
>>>> + { .name = "khadas-mcu-user-mem", },
>>>> + {},
>>>> +};
>>>> +MODULE_DEVICE_TABLE(platform, khadas_mcu_user_mem_id_table);
>>>> +
>>>> +static struct platform_driver khadas_mcu_user_mem_driver = {
>>>> + .probe = khadas_mcu_user_mem_probe,
>>>> + .driver = {
>>>> + .name = "khadas-mcu-user-mem",
>>>> + },
>>>> + .id_table = khadas_mcu_user_mem_id_table,
>>>> +};
>>>> +
>>>> +module_platform_driver(khadas_mcu_user_mem_driver);
>>>> +
>>>> +MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
>>>> +MODULE_DESCRIPTION("Khadas MCU User MEM driver");
>>>> +MODULE_LICENSE("GPL v2");
>>>>
>>
>> Thanks for the review.
>>
>> Neil
>>
_______________________________________________
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 v10] mfd: mt6360: add pmic mt6360 driver
From: Lee Jones @ 2020-06-02 8:28 UTC (permalink / raw)
To: Gene Chen
Cc: gene_chen, linux-kernel, cy_huang, linux-mediatek, matthias.bgg,
Wilma.Wu, linux-arm-kernel, shufan_lee
In-Reply-To: <1591070142-7653-1-git-send-email-gene.chen.richtek@gmail.com>
On Tue, 02 Jun 2020, Gene Chen wrote:
> From: Gene Chen <gene_chen@richtek.com>
>
> Add MFD driver for mt6360 pmic chip include Battery Charger/
> USB_PD/Flash, LED/RGB and LED/LDO/Buck
>
> Signed-off-by: Gene Chen <gene_chen@richtek.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
I did not sign this off.
> ---
> drivers/mfd/Kconfig | 12 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/mt6360-core.c | 424 +++++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/mt6360.h | 240 +++++++++++++++++++++++++
> 4 files changed, 677 insertions(+)
> create mode 100644 drivers/mfd/mt6360-core.c
> create mode 100644 include/linux/mfd/mt6360.h
>
> changelogs between v1 & v2
> - include missing header file
>
> changelogs between v2 & v3
> - add changelogs
>
> changelogs between v3 & v4
> - fix Kconfig description
> - replace mt6360_pmu_info with mt6360_pmu_data
> - replace probe with probe_new
> - remove unnecessary irq_chip variable
> - remove annotation
> - replace MT6360_MFD_CELL with OF_MFD_CELL
>
> changelogs between v4 & v5
> - remove unnecessary parse dt function
> - use devm_i2c_new_dummy_device
> - add base-commit message
>
> changelogs between v5 & v6
> - review return value
> - remove i2c id_table
> - use GPL license v2
>
> changelogs between v6 & v7
> - add author description
> - replace MT6360_REGMAP_IRQ_REG by REGMAP_IRQ_REG_LINE
> - remove mt6360-private.h
>
> changelogs between v7 & v8
> - fix kbuild auto reboot by include interrupt header
>
> changelogs between v8 & v9
> - fix GPL license out of date
> - add commit message about Acked-for-MFD-by
>
> changelogs between v9 & v10
v9 of this patch is already applied.
You cannot send a v10.
> - fix duplicate define of kbuild test reboot initializer-overrides
I fixed this already.
https://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git/commit/?h=for-mfd-next&id=098c4adf249c198519a4abebe482b1e6b8c50e47
> - sync commit message format
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
_______________________________________________
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 3/6] thermal: add support for the MCU controlled FAN on Khadas boards
From: Neil Armstrong @ 2020-06-02 8:26 UTC (permalink / raw)
To: Amit Kucheria
Cc: Linux PM list, Daniel Lezcano, LKML, Srini Kandagatla,
linux-amlogic, Zhang Rui, lakml
In-Reply-To: <CAHLCerPiC3QS5u5CGX20q_5aUk4sN5knF4043_=WjtbhDDGuUg@mail.gmail.com>
On 15/05/2020 08:41, Amit Kucheria wrote:
> On Tue, May 12, 2020 at 6:56 PM Neil Armstrong <narmstrong@baylibre.com> wrote:
>>
>> The new Khadas VIM2 and VIM3 boards controls the cooling fan via the
>> on-board microcontroller.
>>
>> This implements the FAN control as thermal devices and as cell of the Khadas
>> MCU MFD driver.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> drivers/thermal/Kconfig | 10 ++
>> drivers/thermal/Makefile | 1 +
>> drivers/thermal/khadas_mcu_fan.c | 174 +++++++++++++++++++++++++++++++
>> 3 files changed, 185 insertions(+)
>> create mode 100644 drivers/thermal/khadas_mcu_fan.c
>>
>> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
>> index 91af271e9bb0..72b3960cc5ac 100644
>> --- a/drivers/thermal/Kconfig
>> +++ b/drivers/thermal/Kconfig
>> @@ -490,4 +490,14 @@ config SPRD_THERMAL
>> help
>> Support for the Spreadtrum thermal sensor driver in the Linux thermal
>> framework.
>> +
>> +config KHADAS_MCU_FAN_THERMAL
>> + tristate "Khadas MCU controller FAN cooling support"
>> + depends on OF || COMPILE_TEST
>
> Could you add a depends on the some board/SoC Kconfig option here so
> this doesn't show up for non-Amlogic/non-Khadas boards?
Ok
>
> Looks OK otherwise.
>
>> + select MFD_CORE
>> + select REGMAP
>> + help
>> + If you say yes here you get support for the FAN controlled
>> + by the Microcontroller found on the Khadas VIM boards.
>> +
>> endif
>> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
>> index 8c8ed7b79915..460428c2122c 100644
>> --- a/drivers/thermal/Makefile
>> +++ b/drivers/thermal/Makefile
>> @@ -60,3 +60,4 @@ obj-$(CONFIG_ZX2967_THERMAL) += zx2967_thermal.o
>> obj-$(CONFIG_UNIPHIER_THERMAL) += uniphier_thermal.o
>> obj-$(CONFIG_AMLOGIC_THERMAL) += amlogic_thermal.o
>> obj-$(CONFIG_SPRD_THERMAL) += sprd_thermal.o
>> +obj-$(CONFIG_KHADAS_MCU_FAN_THERMAL) += khadas_mcu_fan.o
>> diff --git a/drivers/thermal/khadas_mcu_fan.c b/drivers/thermal/khadas_mcu_fan.c
>> new file mode 100644
>> index 000000000000..044d4aba8be2
>> --- /dev/null
>> +++ b/drivers/thermal/khadas_mcu_fan.c
>> @@ -0,0 +1,174 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * Khadas MCU Controlled FAN driver
>> + *
>> + * Copyright (C) 2020 BayLibre SAS
>> + * Author(s): Neil Armstrong <narmstrong@baylibre.com>
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/mfd/khadas-mcu.h>
>> +#include <linux/regmap.h>
>> +#include <linux/sysfs.h>
>> +#include <linux/thermal.h>
>> +
>> +#define MAX_LEVEL 3
>> +
>> +struct khadas_mcu_fan_ctx {
>> + struct khadas_mcu *mcu;
>> + unsigned int level;
>> + struct thermal_cooling_device *cdev;
>> +};
>> +
>> +static int khadas_mcu_fan_set_level(struct khadas_mcu_fan_ctx *ctx,
>> + unsigned int level)
>> +{
>> + int ret;
>> +
>> + ret = regmap_write(ctx->mcu->map, KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
>> + level);
>> + if (ret)
>> + return ret;
>> +
>> + ctx->level = level;
>> +
>> + return 0;
>> +}
>> +
>> +static int khadas_mcu_fan_get_max_state(struct thermal_cooling_device *cdev,
>> + unsigned long *state)
>> +{
>> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>> +
>> + if (!ctx)
>> + return -EINVAL;
>> +
>> + *state = MAX_LEVEL;
>> +
>> + return 0;
>> +}
>> +
>> +static int khadas_mcu_fan_get_cur_state(struct thermal_cooling_device *cdev,
>> + unsigned long *state)
>> +{
>> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>> +
>> + if (!ctx)
>> + return -EINVAL;
>> +
>> + *state = ctx->level;
>> +
>> + return 0;
>> +}
>> +
>> +static int
>> +khadas_mcu_fan_set_cur_state(struct thermal_cooling_device *cdev,
>> + unsigned long state)
>> +{
>> + struct khadas_mcu_fan_ctx *ctx = cdev->devdata;
>> +
>> + if (!ctx || (state > MAX_LEVEL))
>> + return -EINVAL;
>> +
>> + if (state == ctx->level)
>> + return 0;
>> +
>> + return khadas_mcu_fan_set_level(ctx, state);
>> +}
>> +
>> +static const struct thermal_cooling_device_ops khadas_mcu_fan_cooling_ops = {
>> + .get_max_state = khadas_mcu_fan_get_max_state,
>> + .get_cur_state = khadas_mcu_fan_get_cur_state,
>> + .set_cur_state = khadas_mcu_fan_set_cur_state,
>> +};
>> +
>> +static int khadas_mcu_fan_probe(struct platform_device *pdev)
>> +{
>> + struct khadas_mcu *mcu = dev_get_drvdata(pdev->dev.parent);
>> + struct thermal_cooling_device *cdev;
>> + struct device *dev = &pdev->dev;
>> + struct khadas_mcu_fan_ctx *ctx;
>> + int ret;
>> +
>> + ctx = devm_kzalloc(dev, sizeof(*ctx), GFP_KERNEL);
>> + if (!ctx)
>> + return -ENOMEM;
>> + ctx->mcu = mcu;
>> + platform_set_drvdata(pdev, ctx);
>> +
>> + cdev = devm_thermal_of_cooling_device_register(dev->parent,
>> + dev->parent->of_node, "khadas-mcu-fan", ctx,
>> + &khadas_mcu_fan_cooling_ops);
>> + if (IS_ERR(cdev)) {
>> + ret = PTR_ERR(cdev);
>> + dev_err(dev,
>> + "Failed to register khadas-mcu-fan as cooling device: %d\n",
>> + ret);
>> + return ret;
>> + }
>> + ctx->cdev = cdev;
>> + thermal_cdev_update(cdev);
>> +
>> + return 0;
>> +}
>> +
>> +static int khadas_mcu_fan_disable(struct device *dev)
>> +{
>> + struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
>> + unsigned int level_save = ctx->level;
>> + int ret;
>> +
>> + ret = khadas_mcu_fan_set_level(ctx, 0);
>> + if (ret)
>> + return ret;
>> +
>> + ctx->level = level_save;
>> +
>> + return 0;
>> +}
>> +
>> +static void khadas_mcu_fan_shutdown(struct platform_device *pdev)
>> +{
>> + khadas_mcu_fan_disable(&pdev->dev);
>> +}
>> +
>> +#ifdef CONFIG_PM_SLEEP
>> +static int khadas_mcu_fan_suspend(struct device *dev)
>> +{
>> + return khadas_mcu_fan_disable(dev);
>> +}
>> +
>> +static int khadas_mcu_fan_resume(struct device *dev)
>> +{
>> + struct khadas_mcu_fan_ctx *ctx = dev_get_drvdata(dev);
>> +
>> + return khadas_mcu_fan_set_level(ctx, ctx->level);
>> +}
>> +#endif
>> +
>> +static SIMPLE_DEV_PM_OPS(khadas_mcu_fan_pm, khadas_mcu_fan_suspend,
>> + khadas_mcu_fan_resume);
>> +
>> +static const struct platform_device_id khadas_mcu_fan_id_table[] = {
>> + { .name = "khadas-mcu-fan-ctrl", },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(platform, khadas_mcu_fan_id_table);
>> +
>> +static struct platform_driver khadas_mcu_fan_driver = {
>> + .probe = khadas_mcu_fan_probe,
>> + .shutdown = khadas_mcu_fan_shutdown,
>> + .driver = {
>> + .name = "khadas-mcu-fan-ctrl",
>> + .pm = &khadas_mcu_fan_pm,
>> + },
>> + .id_table = khadas_mcu_fan_id_table,
>> +};
>> +
>> +module_platform_driver(khadas_mcu_fan_driver);
>> +
>> +MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
>> +MODULE_DESCRIPTION("Khadas MCU FAN driver");
>> +MODULE_LICENSE("GPL");
>> --
>> 2.22.0
>>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2 2/6] mfd: add support for the Khadas System control Microcontroller
From: Neil Armstrong @ 2020-06-02 8:26 UTC (permalink / raw)
To: Lee Jones; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, linux-pm
In-Reply-To: <20200520090101.GE271301@dell>
On 20/05/2020 11:01, Lee Jones wrote:
> On Tue, 12 May 2020, Neil Armstrong wrote:
>
>> This Microcontroller is present on the Khadas VIM1, VIM2, VIM3 and Edge
>> boards.
>>
>> It has multiple boot control features like password check, power-on
>> options, power-off control and system FAN control on recent boards.
>>
>> This implements a very basic MFD driver with the fan control and User
>> NVMEM cells.
>>
>> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
>> ---
>> drivers/mfd/Kconfig | 14 ++++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/khadas-mcu.c | 143 +++++++++++++++++++++++++++++++++
>> include/linux/mfd/khadas-mcu.h | 91 +++++++++++++++++++++
>> 4 files changed, 249 insertions(+)
>> create mode 100644 drivers/mfd/khadas-mcu.c
>> create mode 100644 include/linux/mfd/khadas-mcu.h
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 0a59249198d3..b95091397052 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -2003,6 +2003,20 @@ config MFD_WCD934X
>> This driver provides common support WCD934x audio codec and its
>> associated Pin Controller, Soundwire Controller and Audio codec.
>>
>> +config MFD_KHADAS_MCU
>> + tristate "Support for Khadas System control Microcontroller"
>> + depends on I2C
>> + depends on OF || COMPILE_TEST
>> + select MFD_CORE
>> + select REGMAP_I2C
>> + help
>> + Support for the Khadas System control Microcontroller interface present
>> + on their VIM and Edge boards.
>> +
>> + This driver provides common support for accessing the device,
>> + additional drivers must be enabled in order to use the functionality
>> + of the device.
>
> It would be good to describe the device here.
Ok
>
>> menu "Multimedia Capabilities Port drivers"
>> depends on ARCH_SA1100
>>
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index f935d10cbf0f..0f1633b096bb 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -257,5 +257,6 @@ obj-$(CONFIG_MFD_ROHM_BD70528) += rohm-bd70528.o
>> obj-$(CONFIG_MFD_ROHM_BD71828) += rohm-bd71828.o
>> obj-$(CONFIG_MFD_ROHM_BD718XX) += rohm-bd718x7.o
>> obj-$(CONFIG_MFD_STMFX) += stmfx.o
>> +obj-$(CONFIG_MFD_KHADAS_MCU) += khadas-mcu.o
>>
>> obj-$(CONFIG_SGI_MFD_IOC3) += ioc3.o
>> diff --git a/drivers/mfd/khadas-mcu.c b/drivers/mfd/khadas-mcu.c
>> new file mode 100644
>> index 000000000000..6d08fa2e373a
>> --- /dev/null
>> +++ b/drivers/mfd/khadas-mcu.c
>> @@ -0,0 +1,143 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Driver for Khadas System control Microcontroller
>> + *
>> + * Copyright (C) 2020 BayLibre SAS
>
> Nit: '\n' here please.
Ok
>
>> + * Author(s): Neil Armstrong <narmstrong@baylibre.com>
>> + */
>> +#include <linux/bitfield.h>
>> +#include <linux/i2c.h>
>> +#include <linux/mfd/khadas-mcu.h>
>> +#include <linux/regmap.h>
>> +#include <linux/mfd/core.h>
>> +#include <linux/module.h>
>
> Alphabetical.
Ok
>
>> +static bool khadas_mcu_reg_volatile(struct device *dev, unsigned int reg)
>> +{
>> + if (reg >= KHADAS_MCU_USER_DATA_0_REG &&
>> + reg < KHADAS_MCU_PWR_OFF_CMD_REG)
>> + return true;
>> +
>> + switch (reg) {
>> + case KHADAS_MCU_PWR_OFF_CMD_REG:
>> + case KHADAS_MCU_PASSWD_START_REG:
>> + case KHADAS_MCU_CHECK_VEN_PASSWD_REG:
>> + case KHADAS_MCU_CHECK_USER_PASSWD_REG:
>> + case KHADAS_MCU_WOL_INIT_START_REG:
>> + case KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG:
>> + return true;
>> + default:
>> + return false;
>> + }
>> +}
>> +
>> +static bool khadas_mcu_reg_writeable(struct device *dev, unsigned int reg)
>> +{
>> + switch (reg) {
>> + case KHADAS_MCU_PASSWD_VEN_0_REG:
>> + case KHADAS_MCU_PASSWD_VEN_1_REG:
>> + case KHADAS_MCU_PASSWD_VEN_2_REG:
>> + case KHADAS_MCU_PASSWD_VEN_3_REG:
>> + case KHADAS_MCU_PASSWD_VEN_4_REG:
>> + case KHADAS_MCU_PASSWD_VEN_5_REG:
>> + case KHADAS_MCU_MAC_0_REG:
>> + case KHADAS_MCU_MAC_1_REG:
>> + case KHADAS_MCU_MAC_2_REG:
>> + case KHADAS_MCU_MAC_3_REG:
>> + case KHADAS_MCU_MAC_4_REG:
>> + case KHADAS_MCU_MAC_5_REG:
>> + case KHADAS_MCU_USID_0_REG:
>> + case KHADAS_MCU_USID_1_REG:
>> + case KHADAS_MCU_USID_2_REG:
>> + case KHADAS_MCU_USID_3_REG:
>> + case KHADAS_MCU_USID_4_REG:
>> + case KHADAS_MCU_USID_5_REG:
>> + case KHADAS_MCU_VERSION_0_REG:
>> + case KHADAS_MCU_VERSION_1_REG:
>> + case KHADAS_MCU_DEVICE_NO_0_REG:
>> + case KHADAS_MCU_DEVICE_NO_1_REG:
>> + case KHADAS_MCU_FACTORY_TEST_REG:
>> + case KHADAS_MCU_SHUTDOWN_NORMAL_STATUS_REG:
>> + return false;
>> + default:
>> + return true;
>> + }
>> +}
>> +
>> +static const struct regmap_config khadas_mcu_regmap_config = {
>> + .reg_bits = 8,
>> + .reg_stride = 1,
>> + .val_bits = 8,
>> + .max_register = KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
>> + .volatile_reg = khadas_mcu_reg_volatile,
>> + .writeable_reg = khadas_mcu_reg_writeable,
>> + .cache_type = REGCACHE_RBTREE,
>> +};
>> +
>> +static struct mfd_cell khadas_mcu_fan_cells[] = {
>> + /* Feature supported only on VIM1/2 Rev13+ and VIM3 */
>
> Doesn't read great.
>
> Consider reversing or make the sentence more succinct.
>
> "VIM1/2 Rev13+ and VIM3 only"
Ok
>
>> + { .name = "khadas-mcu-fan-ctrl", },
>> +};
>> +
>> +static struct mfd_cell khadas_mcu_cells[] = {
>> + /* Features supported on all board revisions */
>
> I think we can omit this.
Ok
>
>> + { .name = "khadas-mcu-user-mem", },
>> +};
>> +
>> +static int khadas_mcu_probe(struct i2c_client *client,
>> + const struct i2c_device_id *id)
>> +{
>> + struct device *dev = &client->dev;
>> + struct khadas_mcu *khadas_mcu;
>
> Prefer a rename to 'ddata'.
Ok
>
>> + int ret;
>> +
>> + khadas_mcu = devm_kzalloc(dev, sizeof(*khadas_mcu), GFP_KERNEL);
>> + if (!khadas_mcu)
>> + return -ENOMEM;
>> +
>> + i2c_set_clientdata(client, khadas_mcu);
>> +
>> + khadas_mcu->dev = dev;
>> +
>> + khadas_mcu->map = devm_regmap_init_i2c(client,
>> + &khadas_mcu_regmap_config);
>
Ok
> Prefer a rename to 'regmap'.
>
>> + if (IS_ERR(khadas_mcu->map)) {
>> + ret = PTR_ERR(khadas_mcu->map);
>> + dev_err(dev, "Failed to allocate register map: %d\n", ret);
>> + return ret;
>> + }
>> +
>> + ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
>> + khadas_mcu_cells,
>> + ARRAY_SIZE(khadas_mcu_cells),
>> + NULL, 0, NULL);
>> + if (ret)
>> + return ret;
>> +
>> + if (of_find_property(dev->of_node, "#cooling-cells", NULL))
>> + return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
>> + khadas_mcu_fan_cells,
>> + ARRAY_SIZE(khadas_mcu_fan_cells),
>> + NULL, 0, NULL);
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id khadas_mcu_of_match[] = {
>> + { .compatible = "khadas,mcu", },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, khadas_mcu_of_match);
>> +
>> +static struct i2c_driver khadas_mcu_driver = {
>> + .driver = {
>> + .name = "khadas-mcu-core",
>> + .of_match_table = of_match_ptr(khadas_mcu_of_match),
>> + },
>> + .probe = khadas_mcu_probe,
>> +};
>> +module_i2c_driver(khadas_mcu_driver);
>> +
>> +MODULE_DESCRIPTION("Khadas MCU core driver");
>> +MODULE_AUTHOR("Neil Armstrong <narmstrong@baylibre.com>");
>> +MODULE_LICENSE("GPL v2");
>> diff --git a/include/linux/mfd/khadas-mcu.h b/include/linux/mfd/khadas-mcu.h
>> new file mode 100644
>> index 000000000000..2e68af21735c
>> --- /dev/null
>> +++ b/include/linux/mfd/khadas-mcu.h
>> @@ -0,0 +1,91 @@
>> +/* SPDX-License-Identifier: GPL-2.0 */
>> +/*
>> + * Khadas System control Microcontroller Register map
>> + *
>> + * Copyright (C) 2020 BayLibre SAS
>
> Nit: '\n'
Ok
>
>> + * Author(s): Neil Armstrong <narmstrong@baylibre.com>
>> + */
>> +
>> +#ifndef MFD_KHADAS_MCU_H
>> +#define MFD_KHADAS_MCU_H
>> +
>> +#define KHADAS_MCU_PASSWD_VEN_0_REG 0x0 /* RO */
>
> Nit: Can you pad these please?
Ok
>
>> +#define KHADAS_MCU_PASSWD_VEN_1_REG 0x1 /* RO */
>> +#define KHADAS_MCU_PASSWD_VEN_2_REG 0x2 /* RO */
>> +#define KHADAS_MCU_PASSWD_VEN_3_REG 0x3 /* RO */
>> +#define KHADAS_MCU_PASSWD_VEN_4_REG 0x4 /* RO */
>> +#define KHADAS_MCU_PASSWD_VEN_5_REG 0x5 /* RO */
>> +#define KHADAS_MCU_MAC_0_REG 0x6 /* RO */
>> +#define KHADAS_MCU_MAC_1_REG 0x7 /* RO */
>> +#define KHADAS_MCU_MAC_2_REG 0x8 /* RO */
>> +#define KHADAS_MCU_MAC_3_REG 0x9 /* RO */
>> +#define KHADAS_MCU_MAC_4_REG 0xa /* RO */
>> +#define KHADAS_MCU_MAC_5_REG 0xb /* RO */
>> +#define KHADAS_MCU_USID_0_REG 0xc /* RO */
>> +#define KHADAS_MCU_USID_1_REG 0xd /* RO */
>> +#define KHADAS_MCU_USID_2_REG 0xe /* RO */
>> +#define KHADAS_MCU_USID_3_REG 0xf /* RO */
>> +#define KHADAS_MCU_USID_4_REG 0x10 /* RO */
>> +#define KHADAS_MCU_USID_5_REG 0x11 /* RO */
>> +#define KHADAS_MCU_VERSION_0_REG 0x12 /* RO */
>> +#define KHADAS_MCU_VERSION_1_REG 0x13 /* RO */
>> +#define KHADAS_MCU_DEVICE_NO_0_REG 0x14 /* RO */
>> +#define KHADAS_MCU_DEVICE_NO_1_REG 0x15 /* RO */
>> +#define KHADAS_MCU_FACTORY_TEST_REG 0x16 /* R */
>> +#define KHADAS_MCU_BOOT_MODE_REG 0x20 /* RW */
>> +#define KHADAS_MCU_BOOT_EN_WOL_REG 0x21 /* RW */
>> +#define KHADAS_MCU_BOOT_EN_RTC_REG 0x22 /* RW */
>> +#define KHADAS_MCU_BOOT_EN_EXP_REG 0x23 /* RW */
>> +#define KHADAS_MCU_BOOT_EN_IR_REG 0x24 /* RW */
>> +#define KHADAS_MCU_BOOT_EN_DCIN_REG 0x25 /* RW */
>> +#define KHADAS_MCU_BOOT_EN_KEY_REG 0x26 /* RW */
>> +#define KHADAS_MCU_KEY_MODE_REG 0x27 /* RW */
>> +#define KHADAS_MCU_LED_MODE_ON_REG 0x28 /* RW */
>> +#define KHADAS_MCU_LED_MODE_OFF_REG 0x29 /* RW */
>> +#define KHADAS_MCU_SHUTDOWN_NORMAL_REG 0x2c /* RW */
>> +#define KHADAS_MCU_MAC_SWITCH_REG 0x2d /* RW */
>> +#define KHADAS_MCU_MCU_SLEEP_MODE_REG 0x2e /* RW */
>> +#define KHADAS_MCU_IR_CODE1_0_REG 0x2f /* RW */
>> +#define KHADAS_MCU_IR_CODE1_1_REG 0x30 /* RW */
>> +#define KHADAS_MCU_IR_CODE1_2_REG 0x31 /* RW */
>> +#define KHADAS_MCU_IR_CODE1_3_REG 0x32 /* RW */
>> +#define KHADAS_MCU_USB_PCIE_SWITCH_REG 0x33 /* RW */
>> +#define KHADAS_MCU_IR_CODE2_0_REG 0x34 /* RW */
>> +#define KHADAS_MCU_IR_CODE2_1_REG 0x35 /* RW */
>> +#define KHADAS_MCU_IR_CODE2_2_REG 0x36 /* RW */
>> +#define KHADAS_MCU_IR_CODE2_3_REG 0x37 /* RW */
>> +#define KHADAS_MCU_PASSWD_USER_0_REG 0x40 /* RW */
>> +#define KHADAS_MCU_PASSWD_USER_1_REG 0x41 /* RW */
>> +#define KHADAS_MCU_PASSWD_USER_2_REG 0x42 /* RW */
>> +#define KHADAS_MCU_PASSWD_USER_3_REG 0x43 /* RW */
>> +#define KHADAS_MCU_PASSWD_USER_4_REG 0x44 /* RW */
>> +#define KHADAS_MCU_PASSWD_USER_5_REG 0x45 /* RW */
>> +#define KHADAS_MCU_USER_DATA_0_REG 0x46 /* RW 56 bytes */
>> +#define KHADAS_MCU_PWR_OFF_CMD_REG 0x80 /* WO */
>> +#define KHADAS_MCU_PASSWD_START_REG 0x81 /* WO */
>> +#define KHADAS_MCU_CHECK_VEN_PASSWD_REG 0x82 /* WO */
>> +#define KHADAS_MCU_CHECK_USER_PASSWD_REG 0x83 /* WO */
>> +#define KHADAS_MCU_SHUTDOWN_NORMAL_STATUS_REG 0x86 /* RO */
>> +#define KHADAS_MCU_WOL_INIT_START_REG 0x87 /* WO */
>> +#define KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG 0x88 /* WO */
>> +
>> +/* Boards */
>
> I think the names make this superfluous.
Ok
>
>> +enum {
>> + KHADAS_BOARD_VIM1 = 0x1,
>> + KHADAS_BOARD_VIM2,
>> + KHADAS_BOARD_VIM3,
>> + KHADAS_BOARD_EDGE = 0x11,
>> + KHADAS_BOARD_EDGE_V,
>> +};
>> +
>> +/**
>> + * struct khadas_mcu_data - Khadas MCU MFD structure
>
> Doesn't match the struct name>
> Prefer you drop the 'MFD' part.
Ok
>
>> + * @device: device reference used for logs
>> + * @map: register map
>> + */
>> +struct khadas_mcu {
>> + struct device *dev;
>> + struct regmap *map;
>> +};
>> +
>> +#endif /* MFD_KHADAS_MCU_H */
>
Thanks for the review.
Neil
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 2/2] hwrng: add sec-rng driver
From: Neal Liu @ 2020-06-02 8:14 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu, Rob Herring, Matthias Brugger,
Sean Wang, Arnd Bergmann, Greg Kroah-Hartman
Cc: devicetree, wsd_upstream, lkml, Crystal Guo, linux-mediatek,
linux-crypto, Neal Liu, linux-arm-kernel
In-Reply-To: <1591085678-22764-1-git-send-email-neal.liu@mediatek.com>
For security awareness SoCs on ARMv8 with TrustZone enabled,
peripherals like entropy sources is not accessible from normal world
(linux) and rather accessible from secure world (HYP/ATF/TEE) only.
This driver aims to provide a generic interface to Arm Trusted
Firmware or Hypervisor rng service.
Signed-off-by: Neal Liu <neal.liu@mediatek.com>
---
drivers/char/hw_random/Kconfig | 13 ++++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/sec-rng.c | 155 ++++++++++++++++++++++++++++++++++++++
3 files changed, 169 insertions(+)
create mode 100644 drivers/char/hw_random/sec-rng.c
diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 9bc46da..cb9c8a9 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -474,6 +474,19 @@ config HW_RANDOM_KEYSTONE
help
This option enables Keystone's hardware random generator.
+config HW_RANDOM_SECURE
+ tristate "Arm Security Random Number Generator support"
+ depends on HAVE_ARM_SMCCC || COMPILE_TEST
+ default HW_RANDOM
+ help
+ This driver provides kernel-side support for the Arm Security
+ Random Number Generator.
+
+ To compile this driver as a module, choose M here. the
+ module will be called sec-rng.
+
+ If unsure, say Y.
+
endif # HW_RANDOM
config UML_RANDOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index a7801b4..04533d1 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -41,3 +41,4 @@ obj-$(CONFIG_HW_RANDOM_S390) += s390-trng.o
obj-$(CONFIG_HW_RANDOM_KEYSTONE) += ks-sa-rng.o
obj-$(CONFIG_HW_RANDOM_OPTEE) += optee-rng.o
obj-$(CONFIG_HW_RANDOM_NPCM) += npcm-rng.o
+obj-$(CONFIG_HW_RANDOM_SECURE) += sec-rng.o
diff --git a/drivers/char/hw_random/sec-rng.c b/drivers/char/hw_random/sec-rng.c
new file mode 100644
index 0000000..c6d3872
--- /dev/null
+++ b/drivers/char/hw_random/sec-rng.c
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 MediaTek Inc.
+ */
+
+#include <linux/arm-smccc.h>
+#include <linux/hw_random.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+
+#define SMC_RET_NUM 4
+#define SEC_RND_SIZE (sizeof(u32) * SMC_RET_NUM)
+
+#define HWRNG_SMC_FAST_CALL_VAL(func_num) \
+ ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_32, \
+ ARM_SMCCC_OWNER_SIP, (func_num))
+
+#define to_sec_rng(p) container_of(p, struct sec_rng_priv, rng)
+
+typedef void (sec_rng_fn)(unsigned long, unsigned long, unsigned long,
+ unsigned long, unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ struct arm_smccc_res *);
+
+struct sec_rng_priv {
+ u16 func_num;
+ sec_rng_fn *rng_fn;
+ struct hwrng rng;
+};
+
+/* Simple wrapper functions to be able to use a function pointer */
+static void sec_rng_smc(unsigned long a0, unsigned long a1,
+ unsigned long a2, unsigned long a3,
+ unsigned long a4, unsigned long a5,
+ unsigned long a6, unsigned long a7,
+ struct arm_smccc_res *res)
+{
+ arm_smccc_smc(a0, a1, a2, a3, a4, a5, a6, a7, res);
+}
+
+static void sec_rng_hvc(unsigned long a0, unsigned long a1,
+ unsigned long a2, unsigned long a3,
+ unsigned long a4, unsigned long a5,
+ unsigned long a6, unsigned long a7,
+ struct arm_smccc_res *res)
+{
+ arm_smccc_hvc(a0, a1, a2, a3, a4, a5, a6, a7, res);
+}
+
+static bool __sec_get_rnd(struct sec_rng_priv *priv, uint32_t *val)
+{
+ struct arm_smccc_res res;
+
+ priv->rng_fn(HWRNG_SMC_FAST_CALL_VAL(priv->func_num),
+ 0, 0, 0, 0, 0, 0, 0, &res);
+
+ if (!res.a0 && !res.a1 && !res.a2 && !res.a3)
+ return false;
+
+ val[0] = res.a0;
+ val[1] = res.a1;
+ val[2] = res.a2;
+ val[3] = res.a3;
+
+ return true;
+}
+
+static int sec_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+ struct sec_rng_priv *priv = to_sec_rng(rng);
+ u32 val[4] = {0};
+ int retval = 0;
+ int i;
+
+ while (max >= SEC_RND_SIZE) {
+ if (!__sec_get_rnd(priv, val))
+ return retval;
+
+ for (i = 0; i < SMC_RET_NUM; i++) {
+ *(u32 *)buf = val[i];
+ buf += sizeof(u32);
+ }
+
+ retval += SEC_RND_SIZE;
+ max -= SEC_RND_SIZE;
+ }
+
+ return retval;
+}
+
+static int sec_rng_probe(struct platform_device *pdev)
+{
+ struct sec_rng_priv *priv;
+ const char *method;
+ int ret;
+
+ priv = devm_kzalloc(&pdev->dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ if (of_property_read_string(pdev->dev.of_node, "method", &method))
+ return -ENXIO;
+
+ if (!strncmp("smc", method, strlen("smc")))
+ priv->rng_fn = sec_rng_smc;
+ else if (!strncmp("hvc", method, strlen("hvc")))
+ priv->rng_fn = sec_rng_hvc;
+
+ if (IS_ERR(priv->rng_fn)) {
+ dev_err(&pdev->dev, "method %s is not supported\n", method);
+ return -EINVAL;
+ }
+
+ if (of_property_read_u16(pdev->dev.of_node, "method-fid",
+ &priv->func_num))
+ return -ENXIO;
+
+ if (of_property_read_u16(pdev->dev.of_node, "quality",
+ &priv->rng.quality))
+ return -ENXIO;
+
+ priv->rng.name = pdev->name;
+ priv->rng.read = sec_rng_read;
+ priv->rng.priv = (unsigned long)&pdev->dev;
+
+ ret = devm_hwrng_register(&pdev->dev, &priv->rng);
+ if (ret) {
+ dev_err(&pdev->dev, "failed to register rng device: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static const struct of_device_id sec_rng_match[] = {
+ { .compatible = "arm,sec-rng", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, sec_rng_match);
+
+static struct platform_driver sec_rng_driver = {
+ .probe = sec_rng_probe,
+ .driver = {
+ .name = KBUILD_MODNAME,
+ .owner = THIS_MODULE,
+ .of_match_table = sec_rng_match,
+ },
+};
+
+module_platform_driver(sec_rng_driver);
+
+MODULE_DESCRIPTION("Security Random Number Generator Driver");
+MODULE_AUTHOR("Neal Liu <neal.liu@mediatek.com>");
+MODULE_LICENSE("GPL");
--
1.7.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 related
* Security Random Number Generator support
From: Neal Liu @ 2020-06-02 8:14 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu, Rob Herring, Matthias Brugger,
Sean Wang, Arnd Bergmann, Greg Kroah-Hartman
Cc: devicetree, wsd_upstream, lkml, Crystal Guo, linux-mediatek,
linux-crypto, Neal Liu, linux-arm-kernel
These patch series introduce a security random number generator
which provides a generic interface to get hardware rnd from Secure
state. The Secure state can be Arm Trusted Firmware(ATF), Trusted
Execution Environment(TEE), or even EL2 hypervisor.
Patch #1..2 adds sec-rng kernel driver for Trustzone based SoCs.
For security awareness SoCs on ARMv8 with TrustZone enabled,
peripherals like entropy sources is not accessible from normal world
(linux) and rather accessible from secure world (HYP/ATF/TEE) only.
This driver aims to provide a generic interface to Arm Trusted
Firmware or Hypervisor rng service.
changes since v1:
- rename mt67xx-rng to mtk-sec-rng since all MediaTek ARMv8 SoCs can reuse
this driver.
- refine coding style and unnecessary check.
changes since v2:
- remove unused comments.
- remove redundant variable.
changes since v3:
- add dt-bindings for MediaTek rng with TrustZone enabled.
- revise HWRNG SMC call fid.
changes since v4:
- move bindings to the arm/firmware directory.
- revise driver init flow to check more property.
changes since v5:
- refactor to more generic security rng driver which
is not platform specific.
*** BLURB HERE ***
Neal Liu (2):
dt-bindings: rng: add bindings for sec-rng
hwrng: add sec-rng driver
.../devicetree/bindings/rng/sec-rng.yaml | 53 ++++++
drivers/char/hw_random/Kconfig | 13 ++
drivers/char/hw_random/Makefile | 1 +
drivers/char/hw_random/sec-rng.c | 155 ++++++++++++++++++
4 files changed, 222 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/sec-rng.yaml
create mode 100644 drivers/char/hw_random/sec-rng.c
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/10] spi: Adding support for Microchip Sparx5 SoC
From: Serge Semin @ 2020-06-02 8:21 UTC (permalink / raw)
To: Lars Povlsen
Cc: devicetree, linux-kernel, linux-spi, Serge Semin, SoC Team,
Mark Brown, Microchip Linux Driver Support, linux-arm-kernel
In-Reply-To: <87img9q3sb.fsf@soft-dev15.microsemi.net>
On Tue, Jun 02, 2020 at 10:18:28AM +0200, Lars Povlsen wrote:
>
> Serge Semin writes:
>
> > Hello Lars,
> >
> > On Wed, May 13, 2020 at 04:00:21PM +0200, Lars Povlsen wrote:
> >> This is an add-on series to the main SoC Sparx5 series
> >> (Message-ID: <20200513125532.24585-1-lars.povlsen@microchip.com>).
> >>
> >> The series add support for Sparx5 on top of the existing
> >> ocelot/jaguar2 spi driver.
> >>
> >> It spins off the existing support for the MSCC platforms into a
> >> separate driver, as adding new platforms from the MSCC/Microchip
> >> product lines will further complicate (clutter) the original driver.
> >>
> >> New YAML dt-bindings are provided for the resulting driver.
> >>
> >> It is expected that the DT patches are to be taken directly by the arm-soc
> >> maintainers.
> >
> > Regarding our cooperation. It can be implemented as follows. Since your patchset
> > is less cumbersome than mine and is more ready to be integrated into the generic DW
> > APB SSI code, it would be better to first make it through Mark', Andy' and my reviews
> > to be further merged into the kernel version of the driver. After that I'll have
> > my code altered so it could be applied on top of your patches. When everything
> > is done we'll have a more comprehensive DW APB SSI driver with poll-based
> > PIO operations support, new features like rx-delay, etc.
> >
>
> Hi Serge!
>
> I think I would be able to work on the SPI patches this week. Should I
> base it on the current spi-next or 5.7? Then address the comments and
> send out a new revision?
>
> Thanks for reaching out.
Sorry for a delay. I had to finish urgent tasks first. I'll give my review comments
shortly today.
-Sergey
>
> ---Lars
>
> > Thank you one more time for the series you've shared with us. Let's see what can
> > be done to improve it...
> >
> > -Sergey
> >
> >>
> >> Lars Povlsen (10):
> >> spi: dw: Add support for polled operation via no IRQ specified in DT
> >> spi: dw: Add support for RX sample delay register
> >> spi: dw: Add support for client driver memory operations
> >> dt-bindings: spi: Add bindings for spi-dw-mchp
> >> spi: spi-dw-mmio: Spin off MSCC platforms into spi-dw-mchp
> >> dt-bindings: spi: spi-dw-mchp: Add Sparx5 support
> >> spi: spi-dw-mchp: Add Sparx5 support
> >> arm64: dts: sparx5: Add SPI controller
> >> arm64: dts: sparx5: Add spi-nor support
> >> arm64: dts: sparx5: Add spi-nand devices
> >>
> >> .../bindings/spi/mscc,ocelot-spi.yaml | 89 ++++
> >> .../bindings/spi/snps,dw-apb-ssi.txt | 7 +-
> >> MAINTAINERS | 2 +
> >> arch/arm64/boot/dts/microchip/sparx5.dtsi | 37 ++
> >> .../boot/dts/microchip/sparx5_pcb125.dts | 16 +
> >> .../boot/dts/microchip/sparx5_pcb134.dts | 22 +
> >> .../dts/microchip/sparx5_pcb134_board.dtsi | 9 +
> >> .../boot/dts/microchip/sparx5_pcb135.dts | 23 +
> >> .../dts/microchip/sparx5_pcb135_board.dtsi | 9 +
> >> arch/mips/configs/generic/board-ocelot.config | 2 +-
> >> drivers/spi/Kconfig | 7 +
> >> drivers/spi/Makefile | 1 +
> >> drivers/spi/spi-dw-mchp.c | 399 ++++++++++++++++++
> >> drivers/spi/spi-dw-mmio.c | 93 ----
> >> drivers/spi/spi-dw.c | 31 +-
> >> drivers/spi/spi-dw.h | 4 +
> >> 16 files changed, 644 insertions(+), 107 deletions(-)
> >> create mode 100644 Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
> >> create mode 100644 drivers/spi/spi-dw-mchp.c
> >>
> >> --
> >> 2.26.2
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel@lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> --
> Lars Povlsen,
> Microchip
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH v5 2/6] interconnect: Add generic interconnect driver for Exynos SoCs
From: Krzysztof Kozlowski @ 2020-06-02 8:21 UTC (permalink / raw)
To: Sylwester Nawrocki
Cc: linux-samsung-soc, b.zolnierkie, sw0312.kim, a.swigon, dri-devel,
linux-kernel, inki.dae, cw00.choi, myungjoo.ham, georgi.djakov,
linux-arm-kernel, m.szyprowski
In-Reply-To: <20200529163200.18031-3-s.nawrocki@samsung.com>
On Fri, May 29, 2020 at 06:31:56PM +0200, Sylwester Nawrocki wrote:
> This patch adds a generic interconnect driver for Exynos SoCs in order
> to provide interconnect functionality for each "samsung,exynos-bus"
> compatible device.
>
> The SoC topology is a graph (or more specifically, a tree) and its
> edges are specified using the 'samsung,interconnect-parent' in the
> DT. Due to unspecified relative probing order, -EPROBE_DEFER may be
> propagated to ensure that the parent is probed before its children.
>
> Each bus is now an interconnect provider and an interconnect node as
> well (cf. Documentation/interconnect/interconnect.rst), i.e. every bus
> registers itself as a node. Node IDs are not hardcoded but rather
> assigned dynamically at runtime. This approach allows for using this
> driver with various Exynos SoCs.
>
> Frequencies requested via the interconnect API for a given node are
> propagated to devfreq using dev_pm_qos_update_request(). Please note
> that it is not an error when CONFIG_INTERCONNECT is 'n', in which
> case all interconnect API functions are no-op.
>
> Signed-off-by: Artur Świgoń <a.swigon@samsung.com>
> Signed-off-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
>
> Changes for v5:
> - adjust to renamed exynos,interconnect-parent-node property,
> - use automatically generated platform device id as the interconect
> node id instead of a now unavailable devfreq->id field,
> - add icc_ prefix to some variables to make the code more self-commenting,
> - use icc_nodes_remove() instead of icc_node_del() + icc_node_destroy(),
> - adjust to exynos,interconnect-parent-node property rename to
> samsung,interconnect-parent,
> - converted to a separate platform driver in drivers/interconnect.
> ---
> drivers/interconnect/Kconfig | 1 +
> drivers/interconnect/Makefile | 1 +
> drivers/interconnect/exynos/Kconfig | 6 ++
> drivers/interconnect/exynos/Makefile | 4 +
> drivers/interconnect/exynos/exynos.c | 185 +++++++++++++++++++++++++++++++++++
> 5 files changed, 197 insertions(+)
> create mode 100644 drivers/interconnect/exynos/Kconfig
> create mode 100644 drivers/interconnect/exynos/Makefile
> create mode 100644 drivers/interconnect/exynos/exynos.c
>
> diff --git a/drivers/interconnect/Kconfig b/drivers/interconnect/Kconfig
> index 5b7204e..eca6eda 100644
> --- a/drivers/interconnect/Kconfig
> +++ b/drivers/interconnect/Kconfig
> @@ -11,6 +11,7 @@ menuconfig INTERCONNECT
>
> if INTERCONNECT
>
> +source "drivers/interconnect/exynos/Kconfig"
> source "drivers/interconnect/imx/Kconfig"
> source "drivers/interconnect/qcom/Kconfig"
>
> diff --git a/drivers/interconnect/Makefile b/drivers/interconnect/Makefile
> index 4825c28..2ba1de6 100644
> --- a/drivers/interconnect/Makefile
> +++ b/drivers/interconnect/Makefile
> @@ -4,5 +4,6 @@ CFLAGS_core.o := -I$(src)
> icc-core-objs := core.o
>
> obj-$(CONFIG_INTERCONNECT) += icc-core.o
> +obj-$(CONFIG_INTERCONNECT_EXYNOS) += exynos/
> obj-$(CONFIG_INTERCONNECT_IMX) += imx/
> obj-$(CONFIG_INTERCONNECT_QCOM) += qcom/
> diff --git a/drivers/interconnect/exynos/Kconfig b/drivers/interconnect/exynos/Kconfig
> new file mode 100644
> index 0000000..e51e52e
> --- /dev/null
> +++ b/drivers/interconnect/exynos/Kconfig
> @@ -0,0 +1,6 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +config INTERCONNECT_EXYNOS
> + tristate "Exynos generic interconnect driver"
> + depends on ARCH_EXYNOS || COMPILE_TEST
> + help
> + Generic interconnect driver for Exynos SoCs.
> diff --git a/drivers/interconnect/exynos/Makefile b/drivers/interconnect/exynos/Makefile
> new file mode 100644
> index 0000000..e19d1df
> --- /dev/null
> +++ b/drivers/interconnect/exynos/Makefile
> @@ -0,0 +1,4 @@
> +# SPDX-License-Identifier: GPL-2.0
> +exynos-interconnect-objs := exynos.o
> +
> +obj-$(CONFIG_INTERCONNECT_EXYNOS) += exynos-interconnect.o
> diff --git a/drivers/interconnect/exynos/exynos.c b/drivers/interconnect/exynos/exynos.c
> new file mode 100644
> index 0000000..8278194
> --- /dev/null
> +++ b/drivers/interconnect/exynos/exynos.c
> @@ -0,0 +1,185 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Exynos generic interconnect provider driver
> + *
> + * Copyright (c) 2020 Samsung Electronics Co., Ltd.
> + *
> + * Authors: Artur Świgoń <a.swigon@samsung.com>
> + * Sylwester Nawrocki <s.nawrocki@samsung.com>
> + */
> +#include <linux/device.h>
> +#include <linux/interconnect-provider.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_qos.h>
> +
> +#define kbps_to_khz(x) ((x) / 8)
> +
> +struct exynos_icc_priv {
> + struct device *dev;
> +
> + /* One interconnect node per provider */
> + struct icc_provider provider;
> + struct icc_node *node;
> +
> + struct dev_pm_qos_request qos_req;
> +};
> +
> +static struct icc_node *exynos_icc_get_parent(struct device_node *np)
> +{
> + struct of_phandle_args args;
> + int num, ret;
> +
> + num = of_count_phandle_with_args(np, "samsung,interconnect-parent",
> + "#interconnect-cells");
> + if (num != 1)
> + return NULL; /* parent nodes are optional */
> +
> + ret = of_parse_phandle_with_args(np, "samsung,interconnect-parent",
> + "#interconnect-cells", 0, &args);
> + if (ret < 0)
> + return ERR_PTR(ret);
> +
> + of_node_put(args.np);
> +
> + return of_icc_get_from_provider(&args);
I think of_node_put() should happen after of_icc_get_from_provider().
Best regards,
Krzysztof
_______________________________________________
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 00/10] spi: Adding support for Microchip Sparx5 SoC
From: Lars Povlsen @ 2020-06-02 8:18 UTC (permalink / raw)
To: Serge Semin
Cc: devicetree, linux-kernel, Serge Semin, linux-spi, SoC Team,
Mark Brown, linux-arm-kernel, Microchip Linux Driver Support,
Lars Povlsen
In-Reply-To: <20200529162130.hsjcde27xhohl6jl@mobilestation>
Serge Semin writes:
> Hello Lars,
>
> On Wed, May 13, 2020 at 04:00:21PM +0200, Lars Povlsen wrote:
>> This is an add-on series to the main SoC Sparx5 series
>> (Message-ID: <20200513125532.24585-1-lars.povlsen@microchip.com>).
>>
>> The series add support for Sparx5 on top of the existing
>> ocelot/jaguar2 spi driver.
>>
>> It spins off the existing support for the MSCC platforms into a
>> separate driver, as adding new platforms from the MSCC/Microchip
>> product lines will further complicate (clutter) the original driver.
>>
>> New YAML dt-bindings are provided for the resulting driver.
>>
>> It is expected that the DT patches are to be taken directly by the arm-soc
>> maintainers.
>
> Regarding our cooperation. It can be implemented as follows. Since your patchset
> is less cumbersome than mine and is more ready to be integrated into the generic DW
> APB SSI code, it would be better to first make it through Mark', Andy' and my reviews
> to be further merged into the kernel version of the driver. After that I'll have
> my code altered so it could be applied on top of your patches. When everything
> is done we'll have a more comprehensive DW APB SSI driver with poll-based
> PIO operations support, new features like rx-delay, etc.
>
Hi Serge!
I think I would be able to work on the SPI patches this week. Should I
base it on the current spi-next or 5.7? Then address the comments and
send out a new revision?
Thanks for reaching out.
---Lars
> Thank you one more time for the series you've shared with us. Let's see what can
> be done to improve it...
>
> -Sergey
>
>>
>> Lars Povlsen (10):
>> spi: dw: Add support for polled operation via no IRQ specified in DT
>> spi: dw: Add support for RX sample delay register
>> spi: dw: Add support for client driver memory operations
>> dt-bindings: spi: Add bindings for spi-dw-mchp
>> spi: spi-dw-mmio: Spin off MSCC platforms into spi-dw-mchp
>> dt-bindings: spi: spi-dw-mchp: Add Sparx5 support
>> spi: spi-dw-mchp: Add Sparx5 support
>> arm64: dts: sparx5: Add SPI controller
>> arm64: dts: sparx5: Add spi-nor support
>> arm64: dts: sparx5: Add spi-nand devices
>>
>> .../bindings/spi/mscc,ocelot-spi.yaml | 89 ++++
>> .../bindings/spi/snps,dw-apb-ssi.txt | 7 +-
>> MAINTAINERS | 2 +
>> arch/arm64/boot/dts/microchip/sparx5.dtsi | 37 ++
>> .../boot/dts/microchip/sparx5_pcb125.dts | 16 +
>> .../boot/dts/microchip/sparx5_pcb134.dts | 22 +
>> .../dts/microchip/sparx5_pcb134_board.dtsi | 9 +
>> .../boot/dts/microchip/sparx5_pcb135.dts | 23 +
>> .../dts/microchip/sparx5_pcb135_board.dtsi | 9 +
>> arch/mips/configs/generic/board-ocelot.config | 2 +-
>> drivers/spi/Kconfig | 7 +
>> drivers/spi/Makefile | 1 +
>> drivers/spi/spi-dw-mchp.c | 399 ++++++++++++++++++
>> drivers/spi/spi-dw-mmio.c | 93 ----
>> drivers/spi/spi-dw.c | 31 +-
>> drivers/spi/spi-dw.h | 4 +
>> 16 files changed, 644 insertions(+), 107 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/spi/mscc,ocelot-spi.yaml
>> create mode 100644 drivers/spi/spi-dw-mchp.c
>>
>> --
>> 2.26.2
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Lars Povlsen,
Microchip
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 1/2] dt-bindings: rng: add bindings for sec-rng
From: Neal Liu @ 2020-06-02 8:14 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu, Rob Herring, Matthias Brugger,
Sean Wang, Arnd Bergmann, Greg Kroah-Hartman
Cc: devicetree, wsd_upstream, lkml, Crystal Guo, linux-mediatek,
linux-crypto, Neal Liu, linux-arm-kernel
In-Reply-To: <1591085678-22764-1-git-send-email-neal.liu@mediatek.com>
Add bindings for ARM TrustZone based Security Random
Number Generator.
Signed-off-by: Neal Liu <neal.liu@mediatek.com>
---
Documentation/devicetree/bindings/rng/sec-rng.yaml | 53 ++++++++++++++++++++
1 file changed, 53 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/sec-rng.yaml
diff --git a/Documentation/devicetree/bindings/rng/sec-rng.yaml b/Documentation/devicetree/bindings/rng/sec-rng.yaml
new file mode 100644
index 0000000..7f4ae50
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/sec-rng.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+# # Copyright 2020 MediaTek Inc.
+%YAML 1.2
+---
+$id: "http://devicetree.org/schemas/rng/sec-rng.yaml#"
+$schema: "http://devicetree.org/meta-schemas/core.yaml#"
+
+title: Security Random Number Generator
+
+description: |
+ sec-rng is a security random number generator which provides a generic
+ interface to get hardware rnd from Secure state. The Secure state can be
+ Arm Trusted Firmware(ATF), Trusted Execution Environment(TEE), or even
+ EL2 hypervisor.
+
+maintainer:
+ - Neal Liu <neal.liu@mediatek.com>
+
+properties:
+ compatible:
+ enum:
+ - arm,sec-rng
+
+ method:
+ description: The method of calling to Secure state
+ enum:
+ - smc
+ - hvc
+
+ method-fid:
+ description: The function number within the SMC and HVC function identifier
+ maxItems: 1
+
+ quality:
+ description: Estimation of true entropy in RNG's bitstream per 1024 bits
+ maxItems: 1
+
+required:
+ - compatible
+ - methods
+ - method-fid
+ - quality
+
+additionalProperties: false
+
+examples:
+ - |
+ hwrng: hwrng {
+ compatible = "arm,sec-rng";
+ method = "smc";
+ method-fid = /bits/ 16 <0x26a>;
+ quality = /bits/ 16 <900>;
+ };
--
1.7.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 related
* Re: [PATCH resend 0/2] dts: keystone-k2g-evm: Display support
From: Tomi Valkeinen @ 2020-06-02 8:13 UTC (permalink / raw)
To: santosh.shilimkar, Jyri Sarha, dri-devel, ssantosh,
linux-arm-kernel, devicetree
Cc: mark.rutland, praneeth, robh+dt, peter.ujfalusi, tomi.valkeinen,
laurent.pinchart
In-Reply-To: <6749076a-cbc1-d8e2-bc35-2e2a9ad80a6d@oracle.com>
Hi Santosh,
On 14/02/2020 19:40, santosh.shilimkar@oracle.com wrote:
> On 2/14/20 1:22 AM, Jyri Sarha wrote:
>> Resend because the earlier recipient list was wrong.
>>
>> Now that drm/tidss is queued for mainline, lets add display support for
>> k2g-evm. There is no hurry since tidss is out only in v5.7, but it
>> should not harm to have the dts changes in place before that.
>>
>> Jyri Sarha (2):
>> ARM: dts: keystone-k2g: Add DSS node
>> ARM: dts: keystone-k2g-evm: add HDMI video support
>>
>> arch/arm/boot/dts/keystone-k2g-evm.dts | 101 +++++++++++++++++++++++++
>> arch/arm/boot/dts/keystone-k2g.dtsi | 22 ++++++
>> 2 files changed, 123 insertions(+)
>>
> Ok. Will add this to the next queue.
What happened with this one? It used to be in linux-next, but now I don't see it anymore.
Tomi
--
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
* [PATCH v4 2/2] dt-bindings: clocks: rk3288: add rk3288w compatible
From: Mylène Josserand @ 2020-06-02 8:06 UTC (permalink / raw)
To: mturquette, sboyd, heiko, robh+dt
Cc: devicetree, mylene.josserand, linux-kernel, linux-rockchip,
kernel, linux-clk, linux-arm-kernel
In-Reply-To: <20200602080644.11333-1-mylene.josserand@collabora.com>
Add the possible compatible "rockchip,rk3288w-cru" that handles
the difference between the rk3288 and the new revision rk3288w.
This compatible will be added by bootloaders.
Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com>
---
.../devicetree/bindings/clock/rockchip,rk3288-cru.txt | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt
index 8cb47c39ba53..bf3a9ec19241 100644
--- a/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt
+++ b/Documentation/devicetree/bindings/clock/rockchip,rk3288-cru.txt
@@ -4,9 +4,15 @@ The RK3288 clock controller generates and supplies clock to various
controllers within the SoC and also implements a reset controller for SoC
peripherals.
+A revision of this SoC is available: rk3288w. The clock tree is a bit
+different so another dt-compatible is available. Noticed that it is only
+setting the difference but there is no automatic revision detection. This
+should be performed by bootloaders.
+
Required Properties:
-- compatible: should be "rockchip,rk3288-cru"
+- compatible: should be "rockchip,rk3288-cru" or "rockchip,rk3288w-cru" in
+ case of this revision of Rockchip rk3288.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 1/2] clk: rockchip: rk3288: Handle clock tree for rk3288w
From: Mylène Josserand @ 2020-06-02 8:06 UTC (permalink / raw)
To: mturquette, sboyd, heiko, robh+dt
Cc: devicetree, mylene.josserand, linux-kernel, linux-rockchip,
kernel, linux-clk, linux-arm-kernel
In-Reply-To: <20200602080644.11333-1-mylene.josserand@collabora.com>
The revision rk3288w has a different clock tree about "hclk_vio"
clock, according to the BSP kernel code.
This patch handles this difference by detecting which device-tree
we are using. If it is a "rockchip,rk3288-cru", let's register
the clock tree as it was before. If the device-tree node is
"rockchip,rk3288w-cru", we will apply the difference with this
version of this SoC.
Noticed that this new device-tree compatible must be handled in
bootloader such as u-boot.
Signed-off-by: Mylène Josserand <mylene.josserand@collabora.com>
---
drivers/clk/rockchip/clk-rk3288.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c
index cc2a177bbdbf..204976e2d0cb 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -425,8 +425,6 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
COMPOSITE(0, "aclk_vio0", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(31), 6, 2, MFLAGS, 0, 5, DFLAGS,
RK3288_CLKGATE_CON(3), 0, GFLAGS),
- DIV(0, "hclk_vio", "aclk_vio0", 0,
- RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
COMPOSITE(0, "aclk_vio1", mux_pll_src_cpll_gpll_usb480m_p, CLK_IGNORE_UNUSED,
RK3288_CLKSEL_CON(31), 14, 2, MFLAGS, 8, 5, DFLAGS,
RK3288_CLKGATE_CON(3), 2, GFLAGS),
@@ -819,6 +817,16 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
INVERTER(0, "pclk_isp", "pclk_isp_in", RK3288_CLKSEL_CON(29), 3, IFLAGS),
};
+static struct rockchip_clk_branch rk3288w_hclkvio_branch[] __initdata = {
+ DIV(0, "hclk_vio", "aclk_vio1", 0,
+ RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
+};
+
+static struct rockchip_clk_branch rk3288_hclkvio_branch[] __initdata = {
+ DIV(0, "hclk_vio", "aclk_vio0", 0,
+ RK3288_CLKSEL_CON(28), 8, 5, DFLAGS),
+};
+
static const char *const rk3288_critical_clocks[] __initconst = {
"aclk_cpu",
"aclk_peri",
@@ -936,6 +944,14 @@ static void __init rk3288_clk_init(struct device_node *np)
RK3288_GRF_SOC_STATUS1);
rockchip_clk_register_branches(ctx, rk3288_clk_branches,
ARRAY_SIZE(rk3288_clk_branches));
+
+ if (of_device_is_compatible(np, "rockchip,rk3288w-cru"))
+ rockchip_clk_register_branches(ctx, rk3288w_hclkvio_branch,
+ ARRAY_SIZE(rk3288w_hclkvio_branch));
+ else
+ rockchip_clk_register_branches(ctx, rk3288_hclkvio_branch,
+ ARRAY_SIZE(rk3288_hclkvio_branch));
+
rockchip_clk_protect_critical(rk3288_critical_clocks,
ARRAY_SIZE(rk3288_critical_clocks));
--
2.26.2
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v4 0/2] ARM: Add Rockchip rk3288w support
From: Mylène Josserand @ 2020-06-02 8:06 UTC (permalink / raw)
To: mturquette, sboyd, heiko, robh+dt
Cc: devicetree, mylene.josserand, linux-kernel, linux-rockchip,
kernel, linux-clk, linux-arm-kernel
Hello everyone,
Context
-------
Here is my V4 of my patches that add the support for the Rockchip
RK3288w which is a revision of the RK3288. It is mostly the same SOC
except for, at least, one clock tree which is different.
This difference is only known by looking at the BSP kernel [1].
Currently, the mainline kernel will not hang on rk3288w but it is
probably by "chance" because we got an issue on a lower kernel version.
According to Rockchip's U-Boot [2], the rk3288w can be detected using
the HDMI revision number (= 0x1A) in this version of the SOC.
Changelog
---------
This V4 is pretty much the same than the V3. Added the dt-bindings
documentation in clock-controller dt-bindings and fixed some typos
according to Heiko's reviews.
Changes since v3:
- Updated clock-controller's dt-bindings
- Fixed indentation
Best regards,
Mylène Josserand
[1] https://github.com/rockchip-linux/kernel/blob/develop-4.4/drivers/clk/rockchip/clk-rk3288.c#L960..L964
[2] https://github.com/rockchip-linux/u-boot/blob/next-dev/arch/arm/mach-rockchip/rk3288/rk3288.c#L378..L388
Mylène Josserand (2):
clk: rockchip: rk3288: Handle clock tree for rk3288w
dt-bindings: clocks: rk3288: add possible rk3288w
.../bindings/clock/rockchip,rk3288-cru.txt | 8 +++++++-
drivers/clk/rockchip/clk-rk3288.c | 20 +++++++++++++++++--
2 files changed, 25 insertions(+), 3 deletions(-)
--
2.26.2
_______________________________________________
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