* [PATCH v18 0/5] Add support for mt8183 SCP.
From: Pi-Hsun Shih @ 2019-09-05 4:44 UTC (permalink / raw)
Cc: open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:REMOTE PROCESSOR REMOTEPROC SUBSYSTEM, open list,
moderated list:ARM/Mediatek SoC support, Pi-Hsun Shih,
moderated list:ARM/Mediatek SoC support
Add support for controlling and communicating with mt8183's system
control processor (SCP), using the remoteproc & rpmsg framework.
And also add a cros_ec driver for CrOS EC host command over rpmsg.
The overall structure of the series is:
* remoteproc/mtk_scp.c: Control the start / stop of SCP (Patch 2, 3).
* remoteproc/mtk_scp_ipi.c: Communicates to SCP using inter-processor
interrupt (IPI) and shared memory (Patch 2, 3).
* rpmsg/mtk_rpmsg.c: Wrapper to wrap the IPI communication into a rpmsg
device. Supports name service for SCP firmware to
announce channels (Patch 4).
* add scp dts node to mt8183 platform (Patch 5).
Changes from v17:
- Fix mixture use of __iomem found by sparse.
- Change the ipi handler to take a u32 instead of enum scp_ipi_id.
- Mark mtk_rpmsg_{prepare,unprepare,stop} as static.
Changes from v16:
- Change the desc_lock mutex to be a per-id lock.
- Put the execution of handler inside the per-id lock, to prevent race
between scp_ipi_unregister and handler being run.
- Move the initialization of mutex to before scp_ipi_register.
Changes from v15:
- Fix a bug on incorrect usage of wait_event_timeout return value.
Changes from v14:
- Fix a typo on variable in DEBUG section.
Changes from v13:
- Move include/linux/platform_data/mtk_scp.h to
include/linux/remoteproc/mtk_scp.h.
- Rename scp_get_reserve_* to scp_get_reserved_*.
- Add lock for access of scp->ipi_desc.
- Lock the whole ipi_send function.
- Move more setting of cache size from SCP firmware to kernel driver,
to prevent problem while loading firmware onto DRAM.
- Minor fixes addressing comment.
Changes from v12:
- Initialize cache before firmware load, to avoid problem while loading
large firmware.
- Disable watchdog before stopping SCP, to avoid extra warning message.
- Fix new warnings by checkpatch.
Changes from v11:
- Fixed a bug that mtk_rpmsg_endpoint is not properly cleaned up if
rproc_boot fails.
- Add missing documentation in comment.
Changes from v10:
- Drop applied cros_ec_rpmsg patches.
- Add clock reset before loading SCP firmware.
- Fix some type mismatch warnings when printing debug messages.
Changes from v9:
- Remove reserve-memory-vpu_share node.
- Remove change to cros_ec_commands.h (That is already in
https://lore.kernel.org/lkml/20190518063949.GY4319@dell/T/)
Changes from v8:
- Rebased onto https://patchwork.kernel.org/cover/10962385/.
- Drop merged cros_ec_rpmsg patch, and add scp dts node patch.
- Add more reserved memory region.
Changes from v7:
- Rebase onto https://lore.kernel.org/patchwork/patch/1059196/.
- Fix clock enable/disable timing for SCP driver.
- Add more SCP IPI ID.
Changes from v6:
- Decouple mtk_rpmsg from mtk_scp.
- Change data of EC response to be aligned to 4 bytes.
Changes from v5:
- Add device tree binding document for cros_ec_rpmsg.
- Better document in comments for cros_ec_rpmsg.
- Remove dependency on CONFIG_ in binding tree document.
Changes from v4:
- Merge patch 6 (Load ELF firmware) into patch 2, so the driver loads
ELF firmware by default, and no longer accept plain binary.
- rpmsg_device listed in device tree (as a child of the SCP node) would
have it's device tree node mapped to the rpmsg_device, so the rpmsg
driver can use the properties on device tree.
Changes from v3:
- Make writing to SCP SRAM aligned.
- Add a new patch (Patch 6) to load ELF instead of bin firmware.
- Add host event support for EC driver.
- Fix some bugs found in testing (missing spin_lock_init,
rproc_subdev_unprepare to rproc_subdev_stop).
- Fix some coding style issue found by checkpatch.pl.
Changes from v2:
- Fold patch 3 into patch 2 in v2.
- Move IPI id around to support cross-testing for old and new firmware.
- Finish more TODO items.
Changes from v1:
- Extract functions and rename variables in mtk_scp.c.
- Do cleanup properly in mtk_rpmsg.c, which also removes the problem of
short-lived work items.
- Code format fix based on feedback for cros_ec_rpmsg.c.
- Extract feature detection for SCP into separate patch (Patch 6).
Eddie Huang (1):
arm64: dts: mt8183: add scp node
Erin Lo (3):
dt-bindings: Add a binding for Mediatek SCP
remoteproc/mediatek: add SCP support for mt8183
remoteproc: mt8183: add reserved memory manager API
Pi-Hsun Shih (1):
rpmsg: add rpmsg support for mt8183 SCP.
.../bindings/remoteproc/mtk,scp.txt | 36 +
arch/arm64/boot/dts/mediatek/mt8183-evb.dts | 11 +
arch/arm64/boot/dts/mediatek/mt8183.dtsi | 12 +
drivers/remoteproc/Kconfig | 10 +
drivers/remoteproc/Makefile | 1 +
drivers/remoteproc/mtk_common.h | 94 +++
drivers/remoteproc/mtk_scp.c | 723 ++++++++++++++++++
drivers/remoteproc/mtk_scp_ipi.c | 176 +++++
drivers/rpmsg/Kconfig | 9 +
drivers/rpmsg/Makefile | 1 +
drivers/rpmsg/mtk_rpmsg.c | 414 ++++++++++
include/linux/remoteproc/mtk_scp.h | 168 ++++
include/linux/rpmsg/mtk_rpmsg.h | 38 +
13 files changed, 1693 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
create mode 100644 drivers/remoteproc/mtk_common.h
create mode 100644 drivers/remoteproc/mtk_scp.c
create mode 100644 drivers/remoteproc/mtk_scp_ipi.c
create mode 100644 drivers/rpmsg/mtk_rpmsg.c
create mode 100644 include/linux/remoteproc/mtk_scp.h
create mode 100644 include/linux/rpmsg/mtk_rpmsg.h
--
2.23.0.187.g17f5b7556c-goog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v18 1/5] dt-bindings: Add a binding for Mediatek SCP
From: Pi-Hsun Shih @ 2019-09-05 4:44 UTC (permalink / raw)
Cc: Ohad Ben-Cohen, Rob Herring,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
Erin Lo, open list:REMOTE PROCESSOR REMOTEPROC SUBSYSTEM,
open list, Bjorn Andersson, Rob Herring,
moderated list:ARM/Mediatek SoC support, Pi-Hsun Shih,
Matthias Brugger, Mark Rutland,
moderated list:ARM/Mediatek SoC support
In-Reply-To: <20190905044432.150131-1-pihsun@chromium.org>
From: Erin Lo <erin.lo@mediatek.com>
Add a DT binding documentation of SCP for the
MT8183 SoC from Mediatek.
Signed-off-by: Erin Lo <erin.lo@mediatek.com>
Signed-off-by: Pi-Hsun Shih <pihsun@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes from v17, v16, v15, v14, v13, v12, v11, v10, v9, v8, v7, v6:
- No change.
Changes from v5:
- Remove dependency on CONFIG_RPMSG_MTK_SCP.
Changes from v4:
- Add detail of more properties.
- Document the usage of mtk,rpmsg-name in subnode from the new design.
Changes from v3:
- No change.
Changes from v2:
- No change. I realized that for this patch series, there's no need to
add anything under the mt8183-scp node (neither the mt8183-rpmsg or
the cros-ec-rpmsg) for them to work, since mt8183-rpmsg is added
directly as a rproc_subdev by code, and cros-ec-rpmsg is dynamically
created by SCP name service.
Changes from v1:
- No change.
---
.../bindings/remoteproc/mtk,scp.txt | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
create mode 100644 Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
new file mode 100644
index 000000000000..3ba668bab14b
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.txt
@@ -0,0 +1,36 @@
+Mediatek SCP Bindings
+----------------------------------------
+
+This binding provides support for ARM Cortex M4 Co-processor found on some
+Mediatek SoCs.
+
+Required properties:
+- compatible Should be "mediatek,mt8183-scp"
+- reg Should contain the address ranges for the two memory
+ regions, SRAM and CFG.
+- reg-names Contains the corresponding names for the two memory
+ regions. These should be named "sram" & "cfg".
+- clocks Clock for co-processor (See: ../clock/clock-bindings.txt)
+- clock-names Contains the corresponding name for the clock. This
+ should be named "main".
+
+Subnodes
+--------
+
+Subnodes of the SCP represent rpmsg devices. The names of the devices are not
+important. The properties of these nodes are defined by the individual bindings
+for the rpmsg devices - but must contain the following property:
+
+- mtk,rpmsg-name Contains the name for the rpmsg device. Used to match
+ the subnode to rpmsg device announced by SCP.
+
+Example:
+
+ scp: scp@10500000 {
+ compatible = "mediatek,mt8183-scp";
+ reg = <0 0x10500000 0 0x80000>,
+ <0 0x105c0000 0 0x5000>;
+ reg-names = "sram", "cfg";
+ clocks = <&infracfg CLK_INFRA_SCPSYS>;
+ clock-names = "main";
+ };
--
2.23.0.187.g17f5b7556c-goog
_______________________________________________
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] ACPI: support for NXP i2c controller
From: Biwen Li @ 2019-09-05 4:33 UTC (permalink / raw)
To: 'andy.shevchenko@gmail.com', 'rafael@kernel.org',
Leo Li, Meenakshi Aggarwal, Udit Kumar,
'wsa@the-dreams.de', 'rjw@rjwysocki.net'
Cc: 's.hauer@pengutronix.de',
'linux-kernel@vger.kernel.org',
'linux-acpi@vger.kernel.org',
'linux-i2c@vger.kernel.org', Chuanhua Han,
'shawnguo@kernel.org',
'linux-arm-kernel@lists.infradead.org'
In-Reply-To: <AM7PR04MB6885DB03C6B96C7932DDA74B8EB90@AM7PR04MB6885.eurprd04.prod.outlook.com>
> Hi,
>
> On 02.09.19 23:16, Andy Shevchenko wrote:
> > On Mon, Sep 2, 2019 at 11:58 PM Rafael J. Wysocki <rafael@kernel.org>
> wrote:
> >>
> >> On Thu, Jul 11, 2019 at 12:35 PM Chuanhua Han <chuanhua.han@nxp.com>
> wrote:
> >>>
> >>> Enable NXP i2c controller to boot with ACPI
> >>>
> >>> Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>
> >>> Signed-off-by: Udit Kumar <udit.kumar@nxp.com>
> >>> Signed-off-by: Chuanhua Han <chuanhua.han@nxp.com>
> >>
> >> Wolfram, any objections to this from the i2c side?
> >
> > May I propose amendment(s)?
> >
> >>> @@ -44,6 +44,7 @@
> >>> #include <linux/pm_runtime.h>
> >>> #include <linux/sched.h>
> >>> #include <linux/slab.h>
> >
> >>> +#include <linux/acpi.h>
> >
> > If it's kept in order, better to go with it. (Yes, it is as I have
> > checked) However, property.h should be included instead, see below.
> >
> >>> const struct of_device_id *of_id =
> of_match_device(i2c_imx_dt_ids,
> >>>
> >>> &pdev->dev);
> >>> + const struct acpi_device_id *acpi_id =
> >>> + acpi_match_device(i2c_imx_acpi_ids,
> >>> + &pdev->dev);
> >
> >
> >>> if (of_id)
> >>> i2c_imx->hwdata = of_id->data;
> >>> + else if (acpi_id)
> >>> + i2c_imx->hwdata = (struct imx_i2c_hwdata *)
> >>> + acpi_id->driver_data;
> >
> >
> > The above altogher may be replaced with
> >
> > const struct imx_i2c_hwdata *match;
> > ...
> > match = device_get_match_data(&pdev->dev);
> > if (match)
> > i2c_imx->hwdata = match;
> > else
> > ...
>
> Instead of "may be replaced", I would say: it should be replaced :)
>
> >>> + .acpi_match_table = ACPI_PTR(i2c_imx_acpi_ids),
> >
> > Since there is no #ifdef guard no need to use ACPI_PTR().
> >
>
> What iMX/(other NXP?) SoCs are with ACPI support? Where I can get one? I
> would like to know more about it.
- Nxp has variety Socs, include i.MX, Layerscape, etc.
- You can get one from here https://www.nxp.com/design/qoriq-developer-resources/qoriq-lx2160a-development-board:LX2160A-RDB
>
> Kind regards,
> Oleksij Rempel
>
> --
> Pengutronix e.K. |
> |
> Industrial Linux Solutions |
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pe
> ngutronix.de%2F&data=02%7C01%7Cmeenakshi.aggarwal%40nxp.com%
> 7C640eb015a91f4959d3b508d7303168fb%7C686ea1d3bc2b4c6fa92cd99c5c
> 301635%7C0%7C0%7C637030861076879938&sdata=sPWtkVtHHDvoRR
> ZmWJuipCO%2BEwG%2BcupgZvcIV1%2BrlEY%3D&reserved=0 |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0
> |
> Amtsgericht Hildesheim, HRA 2686 | Fax:
> +49-5121-206917-5555 |
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH V7 1/3] mm/hotplug: Reorder memblock_[free|remove]() calls in try_remove_memory()
From: Anshuman Khandual @ 2019-09-05 4:27 UTC (permalink / raw)
To: David Hildenbrand, linux-mm, linux-kernel, linux-arm-kernel, akpm,
catalin.marinas, will
Cc: mark.rutland, mhocko, steve.capper, ira.weiny, suzuki.poulose,
mgorman, steven.price, broonie, cai, ard.biesheuvel, cpandya,
arunks, dan.j.williams, Robin.Murphy, logang, valentin.schneider,
osalvador
In-Reply-To: <e98f2950-bef9-3672-81a8-f9593354fffe@redhat.com>
On 09/04/2019 01:46 PM, David Hildenbrand wrote:
> On 03.09.19 11:45, Anshuman Khandual wrote:
>> Memory hot remove uses get_nid_for_pfn() while tearing down linked sysfs
>> entries between memory block and node. It first checks pfn validity with
>> pfn_valid_within() before fetching nid. With CONFIG_HOLES_IN_ZONE config
>> (arm64 has this enabled) pfn_valid_within() calls pfn_valid().
>>
>> pfn_valid() is an arch implementation on arm64 (CONFIG_HAVE_ARCH_PFN_VALID)
>> which scans all mapped memblock regions with memblock_is_map_memory(). This
>> creates a problem in memory hot remove path which has already removed given
>> memory range from memory block with memblock_[remove|free] before arriving
>> at unregister_mem_sect_under_nodes(). Hence get_nid_for_pfn() returns -1
>> skipping subsequent sysfs_remove_link() calls leaving node <-> memory block
>> sysfs entries as is. Subsequent memory add operation hits BUG_ON() because
>> of existing sysfs entries.
> Since
>
> commit 60bb462fc7adb06ebee3beb5a4af6c7e6182e248
> Author: David Hildenbrand <david@redhat.com>
> Date: Wed Aug 28 13:57:15 2019 +1000
>
> drivers/base/node.c: simplify unregister_memory_block_under_nodes()
>
> that problem should be gone. There is no get_nid_for_pfn() call anymore.
Yes, the problem is gone. The above commit is still not present on arm64
tree against which this series was rebased and tested while posting.
>
> So this patch should no longer be necessary - but as I said during
> earlier versions of this patch, the re-ordering might still make sense
> for consistency (removing stuff in the reverse order they were added).
> You'll have to rephrase the description then.
Sure will reword the commit message on these lines.
_______________________________________________
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/4] gpio: dt-bindings: Update documentation with ast2600 controllers
From: Andrew Jeffery @ 2019-09-05 3:59 UTC (permalink / raw)
To: Rashmica Gupta, Linus Walleij
Cc: Mark Rutland, devicetree, linux-aspeed, linux-gpio, linux-kernel,
Bartosz Golaszewski, Rob Herring, Joel Stanley, linux-arm-kernel
In-Reply-To: <20190905011800.16156-1-rashmica.g@gmail.com>
On Thu, 5 Sep 2019, at 10:48, Rashmica Gupta wrote:
> The ast2600 is a new generation of SoC from ASPEED. Similarly to the
> ast2400 and ast2500, it has a GPIO controller for it's 3.6V GPIO pins.
> Additionally, it has a GPIO controller for 36 1.8V GPIO pins. These
> voltages are fixed and cannot be configured via pinconf, so we have two
> separate drivers for them.
See 3/4 for discussion about the commit message.
>
> Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
> ---
> Documentation/devicetree/bindings/gpio/gpio-aspeed.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
> b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
> index 7e9b586770b0..cd388797e07c 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
> @@ -2,7 +2,8 @@ Aspeed GPIO controller Device Tree Bindings
> -------------------------------------------
>
> Required properties:
> -- compatible : Either "aspeed,ast2400-gpio" or "aspeed,ast2500-gpio"
> +- compatible : Either "aspeed,ast2400-gpio", "aspeed,ast2500-gpio",
> + "aspeed,ast2600-gpio", or "aspeed,ast2600-1-8v-gpio"
See the discussion on patch 3/4 about how we might eliminate the
aspeed,ast2600-1-8v-gpio compatible string.
Also, this patch should be the first in the series and start the subject with
"dt-bindings: gpio: aspeed: ..."
Cheers,
Andrew
_______________________________________________
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/4] gpio: Add in ast2600 details to Aspeed driver
From: Andrew Jeffery @ 2019-09-05 3:57 UTC (permalink / raw)
To: Rashmica Gupta, Linus Walleij
Cc: linux-aspeed, linux-gpio, linux-kernel, Bartosz Golaszewski,
Joel Stanley, linux-arm-kernel
In-Reply-To: <20190905011732.16059-1-rashmica.g@gmail.com>
On Thu, 5 Sep 2019, at 10:47, Rashmica Gupta wrote:
> The ast2600 is a new generation of SoC from ASPEED. Similarly to the
> ast2400 and ast2500, it has a GPIO controller for it's 3.6V GPIO pins.
> Additionally, it has a GPIO controller for 36 1.8V GPIO pins. These
> voltages are fixed and cannot be configured via pinconf, so we need two
> separate drivers for them.
Working backwards, we don't really have multiple drivers, just different
configurations for the same driver. So I think this should be reworded.
Also it's not really the voltage differences that are driving the different
configurations but rather that there are two separate sets of registers
in the 2600 with overlapping bank names (they happen to be split into
3.3V and 1.8V groups). The key point being that there aren't just more
GPIO registers tacked on the end of the original 3.3V group.
>
> Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
> ---
> drivers/gpio/gpio-aspeed.c | 30 ++++++++++++++++++++++++++++--
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
> index 16c6eaf70857..4723b8780a8c 100644
> --- a/drivers/gpio/gpio-aspeed.c
> +++ b/drivers/gpio/gpio-aspeed.c
> @@ -662,12 +662,14 @@ static void aspeed_gpio_irq_handler(struct irq_desc *desc)
> struct gpio_chip *gc = irq_desc_get_handler_data(desc);
> struct irq_chip *ic = irq_desc_get_chip(desc);
> struct aspeed_gpio *data = gpiochip_get_data(gc);
> - unsigned int i, p, girq;
> + unsigned int i, p, girq, banks;
> unsigned long reg;
> + struct aspeed_gpio *gpio = gpiochip_get_data(gc);
>
> chained_irq_enter(ic, desc);
>
> - for (i = 0; i < ARRAY_SIZE(aspeed_gpio_banks); i++) {
> + banks = DIV_ROUND_UP(gpio->config->nr_gpios, 32);
> + for (i = 0; i < banks; i++) {
> const struct aspeed_gpio_bank *bank = &aspeed_gpio_banks[i];
>
> reg = ioread32(bank_reg(data, bank, reg_irq_status));
> @@ -1108,9 +1110,33 @@ static const struct aspeed_gpio_config ast2500_config =
> /* 232 for simplicity, actual number is 228 (4-GPIO hole in GPIOAB) */
> { .nr_gpios = 232, .props = ast2500_bank_props, };
>
> +static const struct aspeed_bank_props ast2600_bank_props[] = {
> + /* input output */
> + {5, 0xffffffff, 0x0000ffff}, /* U/V/W/X */
> + {6, 0xffff0000, 0x0fff0000}, /* Y/Z */
> + { },
> +};
> +
> +static const struct aspeed_gpio_config ast2600_config =
> + /* 208 3.6V GPIOs */
> + { .nr_gpios = 208, .props = ast2600_bank_props, };
> +
> +static const struct aspeed_bank_props ast2600_1_8v_bank_props[] = {
> + /* input output */
> + {1, 0x0000000f, 0x0000000f}, /* E */
If there are 36 GPIOs then this configuration is suggesting that all of them
are capable of input and output. A handy observation here is that the first
36 GPIOs of the 3.3V GPIO controller in the 2600 also have both capabilities,
so we can re-use the 3.3V configuration if we can limit the number of GPIOs
somehow.
The devicetree binding already describes an `ngpios` property so perhaps
we could make use of this to use the same properties struct instance for both
controllers in the 2600: Require that the property be present for 2600-
compatible devicetree nodes and test for its presence in probe(), then fall
back to the hard-coded value in the config struct if it is not (this keeps
devicetree compatibility for the 2400 and 2500 drivers).
This way we can eliminate the aspeed,ast2600-1-8v-gpio compatible string
below (we just use aspeed,ast2600-gpio for both controllers).
Thoughts?
Andrew
> + { },
> +};
> +
> +static const struct aspeed_gpio_config ast2600_1_8v_config =
> + /* 36 1.8V GPIOs */
> + { .nr_gpios = 36, .props = ast2600_1_8v_bank_props, };
> +
> static const struct of_device_id aspeed_gpio_of_table[] = {
> { .compatible = "aspeed,ast2400-gpio", .data = &ast2400_config, },
> { .compatible = "aspeed,ast2500-gpio", .data = &ast2500_config, },
> + { .compatible = "aspeed,ast2600-gpio", .data = &ast2600_config, },
> + { .compatible = "aspeed,ast2600-1-8v-gpio",
> + .data = &ast2600_1_8v_config, },
> {}
> };
> MODULE_DEVICE_TABLE(of, aspeed_gpio_of_table);
> --
> 2.20.1
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] irqchip: uniphier-aidet: use devm_platform_ioremap_resource()
From: Masahiro Yamada @ 2019-09-05 3:49 UTC (permalink / raw)
To: Marc Zyngier, Thomas Gleixner, Jason Cooper
Cc: Masahiro Yamada, linux-kernel, linux-arm-kernel
Replace the chain of platform_get_resource() and devm_ioremap_resource()
with devm_platform_ioremap_resource().
This allows to remove the local variable for (struct resource *), and
have one function call less.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/irqchip/irq-uniphier-aidet.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-uniphier-aidet.c b/drivers/irqchip/irq-uniphier-aidet.c
index ed7b4f47ff3f..89121b39be26 100644
--- a/drivers/irqchip/irq-uniphier-aidet.c
+++ b/drivers/irqchip/irq-uniphier-aidet.c
@@ -166,7 +166,6 @@ static int uniphier_aidet_probe(struct platform_device *pdev)
struct device_node *parent_np;
struct irq_domain *parent_domain;
struct uniphier_aidet_priv *priv;
- struct resource *res;
parent_np = of_irq_find_parent(dev->of_node);
if (!parent_np)
@@ -181,8 +180,7 @@ static int uniphier_aidet_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->reg_base = devm_ioremap_resource(dev, res);
+ priv->reg_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->reg_base))
return PTR_ERR(priv->reg_base);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH v2 1/4] gpio/aspeed: Fix incorrect number of banks
From: Andrew Jeffery @ 2019-09-05 3:47 UTC (permalink / raw)
To: Rashmica Gupta, Linus Walleij
Cc: linux-aspeed, linux-gpio, linux-kernel, Bartosz Golaszewski,
Joel Stanley, linux-arm-kernel
In-Reply-To: <20190905011635.15902-1-rashmica.g@gmail.com>
On Thu, 5 Sep 2019, at 10:46, Rashmica Gupta wrote:
> The current calculation for the number of GPIO banks is only correct if
> the number of GPIOs is a multiple of 32 (if there were 31 GPIOs we would
> currently say there are 0 banks, which is incorrect).
>
> Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver')
>
> Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
> ---
> drivers/gpio/gpio-aspeed.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
> index 9defe25d4721..b83e23aecd18 100644
> --- a/drivers/gpio/gpio-aspeed.c
> +++ b/drivers/gpio/gpio-aspeed.c
> @@ -1165,7 +1165,7 @@ static int __init aspeed_gpio_probe(struct
> platform_device *pdev)
> gpio->chip.base = -1;
>
> /* Allocate a cache of the output registers */
> - banks = gpio->config->nr_gpios >> 5;
> + banks = DIV_ROUND_UP(gpio->config->nr_gpios, 32);
> gpio->dcache = devm_kcalloc(&pdev->dev,
> banks, sizeof(u32), GFP_KERNEL);
> if (!gpio->dcache)
> --
> 2.20.1
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] i2c: uniphier(-f): use devm_platform_ioremap_resource()
From: Masahiro Yamada @ 2019-09-05 3:45 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c; +Cc: Masahiro Yamada, linux-kernel, linux-arm-kernel
Replace the chain of platform_get_resource() and devm_ioremap_resource()
with devm_platform_ioremap_resource().
This allows to remove the local variable for (struct resource *), and
have one function call less.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/i2c/busses/i2c-uniphier-f.c | 4 +---
drivers/i2c/busses/i2c-uniphier.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-uniphier-f.c b/drivers/i2c/busses/i2c-uniphier-f.c
index 7acca2599f04..fc5354845ffa 100644
--- a/drivers/i2c/busses/i2c-uniphier-f.c
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -538,7 +538,6 @@ static int uniphier_fi2c_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct uniphier_fi2c_priv *priv;
- struct resource *regs;
u32 bus_speed;
unsigned long clk_rate;
int irq, ret;
@@ -547,8 +546,7 @@ static int uniphier_fi2c_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
- regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->membase = devm_ioremap_resource(dev, regs);
+ priv->membase = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->membase))
return PTR_ERR(priv->membase);
diff --git a/drivers/i2c/busses/i2c-uniphier.c b/drivers/i2c/busses/i2c-uniphier.c
index 0173840c32af..a6d7a3709051 100644
--- a/drivers/i2c/busses/i2c-uniphier.c
+++ b/drivers/i2c/busses/i2c-uniphier.c
@@ -326,7 +326,6 @@ static int uniphier_i2c_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct uniphier_i2c_priv *priv;
- struct resource *regs;
u32 bus_speed;
unsigned long clk_rate;
int irq, ret;
@@ -335,8 +334,7 @@ static int uniphier_i2c_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
- regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->membase = devm_ioremap_resource(dev, regs);
+ priv->membase = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->membase))
return PTR_ERR(priv->membase);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* linux-next: manual merge of the net-next tree with the arm-soc tree
From: Stephen Rothwell @ 2019-09-05 3:42 UTC (permalink / raw)
To: David Miller, Networking, Olof Johansson, Arnd Bergmann, ARM
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Stephen Boyd
[-- Attachment #1.1: Type: text/plain, Size: 760 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in:
drivers/net/ethernet/nuvoton/w90p910_ether.c
between commit:
00d2fbf73d55 ("net: remove w90p910-ether driver")
from the arm-soc tree and commit:
d1a55841ab24 ("net: Remove dev_err() usage after platform_get_irq()")
from the net-next tree.
I fixed it up (I removed the file) and can carry the fix as necessary.
This is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH] dmaengine: uniphier-mdmac: use devm_platform_ioremap_resource()
From: Masahiro Yamada @ 2019-09-05 3:41 UTC (permalink / raw)
To: Vinod Koul, dmaengine
Cc: Masahiro Yamada, Dan Williams, linux-kernel, linux-arm-kernel
Replace the chain of platform_get_resource() and devm_ioremap_resource()
with devm_platform_ioremap_resource().
This allows to remove the local variable for (struct resource *), and
have one function call less.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/dma/uniphier-mdmac.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/dma/uniphier-mdmac.c b/drivers/dma/uniphier-mdmac.c
index ec65a7430dc4..e42f2312b7a1 100644
--- a/drivers/dma/uniphier-mdmac.c
+++ b/drivers/dma/uniphier-mdmac.c
@@ -385,7 +385,6 @@ static int uniphier_mdmac_probe(struct platform_device *pdev)
struct device *dev = &pdev->dev;
struct uniphier_mdmac_device *mdev;
struct dma_device *ddev;
- struct resource *res;
int nr_chans, ret, i;
nr_chans = platform_irq_count(pdev);
@@ -401,8 +400,7 @@ static int uniphier_mdmac_probe(struct platform_device *pdev)
if (!mdev)
return -ENOMEM;
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- mdev->reg_base = devm_ioremap_resource(dev, res);
+ mdev->reg_base = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(mdev->reg_base))
return PTR_ERR(mdev->reg_base);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH] bus: uniphier-system-bus: use devm_platform_ioremap_resource()
From: Masahiro Yamada @ 2019-09-05 3:21 UTC (permalink / raw)
To: arm, Olof Johansson, Arnd Bergmann
Cc: Masahiro Yamada, soc, linux-kernel, linux-arm-kernel
Replace the chain of platform_get_resource() and devm_ioremap_resource()
with devm_platform_ioremap_resource().
This allows to remove the local variable for (struct resource *), and
have one function call less.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
drivers/bus/uniphier-system-bus.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/bus/uniphier-system-bus.c b/drivers/bus/uniphier-system-bus.c
index e845c1a93f21..f70dedace20b 100644
--- a/drivers/bus/uniphier-system-bus.c
+++ b/drivers/bus/uniphier-system-bus.c
@@ -176,7 +176,6 @@ static int uniphier_system_bus_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct uniphier_system_bus_priv *priv;
- struct resource *regs;
const __be32 *ranges;
u32 cells, addr, size;
u64 paddr;
@@ -186,8 +185,7 @@ static int uniphier_system_bus_probe(struct platform_device *pdev)
if (!priv)
return -ENOMEM;
- regs = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- priv->membase = devm_ioremap_resource(dev, regs);
+ priv->membase = devm_platform_ioremap_resource(pdev, 0);
if (IS_ERR(priv->membase))
return PTR_ERR(priv->membase);
--
2.17.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* Re: [PATCH 2/2] mmc: block: add CMD13 polling for ioctl() cmd with R1B response
From: Chaotian Jing @ 2019-09-05 2:55 UTC (permalink / raw)
To: Avri Altman
Cc: Jens Axboe, Ulf Hansson, Chris Boot, srv_heupstream@mediatek.com,
linux-mmc@vger.kernel.org, Zachary Hays, YueHaibing,
linux-kernel@vger.kernel.org, Ming Lei, Wolfram Sang,
linux-mediatek@lists.infradead.org, Hannes Reinecke,
Matthias Brugger, linux-arm-kernel@lists.infradead.org
In-Reply-To: <MN2PR04MB6991F51F6DDCA28FC23D02FEFCB80@MN2PR04MB6991.namprd04.prod.outlook.com>
On Wed, 2019-09-04 at 14:11 +0000, Avri Altman wrote:
> > static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct
> > mmc_blk_data *md,
> > struct mmc_blk_ioc_data *idata)
> > {
> > @@ -623,6 +675,9 @@ static int __mmc_blk_ioctl_cmd(struct mmc_card
> > *card, struct mmc_blk_data *md,
> > __func__, status, err);
> > }
> >
> > + if (!err && (cmd.flags & MMC_RSP_R1B))
> > + err = card_busy_detect(card, MMC_BLK_TIMEOUT_MS, NULL);
> > +
> > return err;
> > }
> You have both the R1B flag check, and status poll (for rpmb) few line above.
> Maybe you could re-use it.
> It will both simplify this patch, and save the tad optimization of your first patch.
>
> Thanks,
> Avri
So that we can drop the ioctl_rpmb_card_status_poll() as it do almost
the same thing with card_busy_detect().
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 0/7] Support dsi for mt8183
From: CK Hu @ 2019-09-05 2:41 UTC (permalink / raw)
To: Jitao Shi
Cc: Mark Rutland, devicetree, David Airlie, stonea168, dri-devel,
yingjoe.chen, Ajay Kumar, Vincent Palatin, cawa.cheng,
bibby.hsieh, Russell King, Thierry Reding, linux-pwm,
Sascha Hauer, Pawel Moll, Ian Campbell, Inki Dae, Rob Herring,
linux-mediatek, Andy Yan, Matthias Brugger, eddie.huang,
linux-arm-kernel, Rahul Sharma, srv_heupstream, linux-kernel,
Philipp Zabel, Sean Paul
In-Reply-To: <20190811104008.53372-1-jitao.shi@mediatek.com>
Hi, Jitao:
For this series, applied to mediatek-drm-next-5.5 [1], and I break
"[v6,2/7] drm/mediatek: fixes CMDQ reg address of mt8173 is different
with mt2701" into two patches, thanks.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.5
Regards,
CK
On Sun, 2019-08-11 at 18:40 +0800, Jitao Shi wrote:
> Change since v5:
> - fine tune dphy timing.
>
> Change since v4:
> - move mipi_dsi_host_unregiter() to .remove()
> - fine tune add frame size control coding style
> - change the data type of data_rate as u32, and add DIV_ROUND_UP_ULL
> - use div_u64 when 8000000000ULL / dsi->data_rate.
>
> Changes since v3
> - add one more 'tab' for bitwise define.
> - add Tested-by: Ryan Case <ryandcase@chromium.org>
> and Reviewed-by: CK Hu <ck.hu@mediatek.com>.
> - remove compare da_hs_zero to da_hs_prepare.
>
> Changes since v2:
> - change the video timing calc method
> - fine the dsi and mipitx init sequence
> - fine tune commit msg
>
> Changes since v1:
> - separate frame size and reg commit control independent patches.
> - fix some return values in probe
> - remove DSI_CMDW0 in "CMDQ reg address of mt8173 is different with mt2701"
>
> Jitao Shi (7):
> drm/mediatek: move mipi_dsi_host_register to probe
> drm/mediatek: fixes CMDQ reg address of mt8173 is different with
> mt2701
> drm/mediatek: add dsi reg commit disable control
> drm/mediatek: add frame size control
> drm/mediatek: add mt8183 dsi driver support
> drm/mediatek: change the dsi phytiming calculate method
> drm: mediatek: adjust dsi and mipi_tx probe sequence
>
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_dsi.c | 224 ++++++++++++++++++-------
> 2 files changed, 161 insertions(+), 65 deletions(-)
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 0/3] Support mipitx for mt8183
From: CK Hu @ 2019-09-05 2:38 UTC (permalink / raw)
To: Jitao Shi
Cc: Mark Rutland, devicetree, David Airlie, stonea168, dri-devel,
yingjoe.chen, Ajay Kumar, Vincent Palatin, cawa.cheng,
bibby.hsieh, Russell King, Thierry Reding, linux-pwm,
Sascha Hauer, Pawel Moll, Ian Campbell, Inki Dae, Rob Herring,
linux-mediatek, Andy Yan, Matthias Brugger, eddie.huang,
linux-arm-kernel, Rahul Sharma, srv_heupstream, linux-kernel,
Philipp Zabel, Sean Paul
In-Reply-To: <20190807084645.63738-1-jitao.shi@mediatek.com>
Hi, Jitao:
For this series, applied to mediatek-drm-next-5.5 [1], thanks.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-next-5.5
Regards,
CK
On Wed, 2019-08-07 at 16:46 +0800, Jitao Shi wrote:
> Change since v5:
> - remove mipi_tx->ref_clk
> - remove mt8183 pll prepare unprepare
>
> Change since v4:
> - fine tune the mipi_tx->ref_clk and mipi_tx->pll sequence
> 1. Prepare mipi_tx->ref_clk
> 2. Prepare mipi_tx->pll
> 3. Enable mipi_tx->ref_clk
> 4. Enable mipi_tx->pll
>
> Changes since v3:
> - turn off PLL before setting PLL parameters.
>
> Changes since v2:
> - update Acked-by: Rob Herring <robh@kernel.org>
> - update mt8183 max bit rate support
>
> Changes since v1:
> - update dt-bindings document for mt8183 mipitx.
> - remove mtk_mipitx_clk_get_ops and assign clk_ops in probe.
> - fix the lincence
> - remove txdiv1 from mtk_mipi_tx_pll_prepare
>
> Jitao Shi (3):
> dt-bindings: display: mediatek: update dsi supported chips
> drm/mediatek: separate mipi_tx to different file
> drm/mediatek: add mipi_tx driver for mt8183
>
> .../display/mediatek/mediatek,dsi.txt | 4 +-
> drivers/gpu/drm/mediatek/Makefile | 2 +
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 338 ++----------------
> drivers/gpu/drm/mediatek/mtk_mipi_tx.h | 49 +++
> drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c | 289 +++++++++++++++
> drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c | 150 ++++++++
> 6 files changed, 515 insertions(+), 317 deletions(-)
> create mode 100644 drivers/gpu/drm/mediatek/mtk_mipi_tx.h
> create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8173_mipi_tx.c
> create mode 100644 drivers/gpu/drm/mediatek/mtk_mt8183_mipi_tx.c
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/2] mm/kasan: dump alloc/free stack for page allocator
From: Walter Wu @ 2019-09-05 1:54 UTC (permalink / raw)
To: Qian Cai
Cc: wsd_upstream, Arnd Bergmann, Linux Memory Management List, LKML,
kasan-dev, Martin Schwidefsky, linux-mediatek, Linux ARM,
Andrey Ryabinin, Matthias Brugger, Alexander Potapenko,
Andrew Morton, Dmitry Vyukov
In-Reply-To: <1567607824.5576.77.camel@lca.pw>
On Wed, 2019-09-04 at 10:37 -0400, Qian Cai wrote:
> On Wed, 2019-09-04 at 22:16 +0800, Walter Wu wrote:
> > On Wed, 2019-09-04 at 15:44 +0200, Andrey Konovalov wrote:
> > > On Wed, Sep 4, 2019 at 8:51 AM Walter Wu <walter-zh.wu@mediatek.com> wrote:
> > > > +config KASAN_DUMP_PAGE
> > > > + bool "Dump the page last stack information"
> > > > + depends on KASAN && PAGE_OWNER
> > > > + help
> > > > + By default, KASAN doesn't record alloc/free stack for page
> > > > allocator.
> > > > + It is difficult to fix up page use-after-free issue.
> > > > + This feature depends on page owner to record the last stack of
> > > > page.
> > > > + It is very helpful for solving the page use-after-free or out-
> > > > of-bound.
> > >
> > > I'm not sure if we need a separate config for this. Is there any
> > > reason to not have this enabled by default?
> >
> > PAGE_OWNER need some memory usage, it is not allowed to enable by
> > default in low RAM device. so I create new feature option and the person
> > who wants to use it to enable it.
>
> Or you can try to look into reducing the memory footprint of PAGE_OWNER to fit
> your needs. It does not always need to be that way.
Thanks your suggestion. We can try to think what can be slimmed.
Thanks.
Walter
_______________________________________________
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 v1 1/3] perf cs-etm: Refactor instruction size handling
From: Leo Yan @ 2019-09-05 1:50 UTC (permalink / raw)
To: Mathieu Poirier
Cc: Suzuki K Poulose, Alexander Shishkin, Linux Kernel Mailing List,
Arnaldo Carvalho de Melo, Adrian Hunter, Namhyung Kim,
Robert Walker, Jiri Olsa, linux-arm-kernel, Mike Leach
In-Reply-To: <CANLsYkwZXyzWqK1oiEg0hb99J89KfdNPsFOmS7G1XJ0xvoUc0Q@mail.gmail.com>
Hi Mathieu,
On Wed, Sep 04, 2019 at 11:06:10AM -0600, Mathieu Poirier wrote:
> On Wed, 4 Sep 2019 at 03:19, Leo Yan <leo.yan@linaro.org> wrote:
> >
> > Hi Mathieu,
> >
> > On Tue, Sep 03, 2019 at 04:22:15PM -0600, Mathieu Poirier wrote:
> > > On Fri, Aug 30, 2019 at 02:24:19PM +0800, Leo Yan wrote:
> > > > There has several code pieces need to know the instruction size, but
> > > > now every place calculates the instruction size separately.
> > > >
> > > > This patch refactors to create a new function cs_etm__instr_size() as
> > > > a central place to analyze the instruction length based on ISA type
> > > > and instruction value.
> > > >
> > > > Signed-off-by: Leo Yan <leo.yan@linaro.org>
> > > > ---
> > > > tools/perf/util/cs-etm.c | 44 +++++++++++++++++++++++++++-------------
> > > > 1 file changed, 30 insertions(+), 14 deletions(-)
> > > >
> > > > diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
> > > > index b3a5daaf1a8f..882a0718033d 100644
> > > > --- a/tools/perf/util/cs-etm.c
> > > > +++ b/tools/perf/util/cs-etm.c
> > > > @@ -914,6 +914,26 @@ static inline int cs_etm__t32_instr_size(struct cs_etm_queue *etmq,
> > > > return ((instrBytes[1] & 0xF8) >= 0xE8) ? 4 : 2;
> > > > }
> > > >
> > > > +static inline int cs_etm__instr_size(struct cs_etm_queue *etmq,
> > > > + u8 trace_chan_id,
> > > > + enum cs_etm_isa isa,
> > > > + u64 addr)
> > > > +{
> > > > + int insn_len;
> > > > +
> > > > + /*
> > > > + * T32 instruction size might be 32-bit or 16-bit, decide by calling
> > > > + * cs_etm__t32_instr_size().
> > > > + */
> > > > + if (isa == CS_ETM_ISA_T32)
> > > > + insn_len = cs_etm__t32_instr_size(etmq, trace_chan_id, addr);
> > > > + /* Otherwise, A64 and A32 instruction size are always 32-bit. */
> > > > + else
> > > > + insn_len = 4;
> > > > +
> > > > + return insn_len;
> > > > +}
> > > > +
> > > > static inline u64 cs_etm__first_executed_instr(struct cs_etm_packet *packet)
> > > > {
> > > > /* Returns 0 for the CS_ETM_DISCONTINUITY packet */
> > > > @@ -938,19 +958,23 @@ static inline u64 cs_etm__instr_addr(struct cs_etm_queue *etmq,
> > > > const struct cs_etm_packet *packet,
> > > > u64 offset)
> > > > {
> > > > + int insn_len;
> > > > +
> > > > if (packet->isa == CS_ETM_ISA_T32) {
> > > > u64 addr = packet->start_addr;
> > > >
> > > > while (offset > 0) {
> > > > - addr += cs_etm__t32_instr_size(etmq,
> > > > - trace_chan_id, addr);
> > > > + addr += cs_etm__instr_size(etmq, trace_chan_id,
> > > > + packet->isa, addr);
> > > > offset--;
> > > > }
> > > > return addr;
> > > > }
> > > >
> > > > - /* Assume a 4 byte instruction size (A32/A64) */
> > > > - return packet->start_addr + offset * 4;
> > > > + /* Return instruction size for A32/A64 */
> > > > + insn_len = cs_etm__instr_size(etmq, trace_chan_id,
> > > > + packet->isa, packet->start_addr);
> > > > + return packet->start_addr + offset * insn_len;
> > >
> > > This patch will work but from where I stand it makes things difficult to
> > > understand more than anything else. It is also adding coupling between function
> > > cs_etm__instr_addr() and cs_etm__instr_size(), meaning the code needs to be
> > > carefully inspected in order to make changes to either one.
> >
> > My purpose is to use a same place to calculate the instruction
> > size, rather than to spread the duplicate codes in several different
> > functions.
> >
> > > Last but not least function cs_etm__instr_size() isn't used in the upcoming
> > > patches. I really don't see what is gained here.
> >
> > Sorry that I forgot to commit my final change into patch 02.
> >
> > I planed to use cs_etm__instr_size() in patch 02; patch 02 has
> > function cs_etm__add_stack_event(), which also needs to get the
> > instruction size when it sends stack event.
> >
> > After apply patch 02, tools/perf/util/cs-etm.c will have below three
> > functions to caculate instruction size; this is the main reason I want
> > to refactor the code for instruction size.
> >
> > cs_etm__instr_addr()
> > cs_etm__copy_insn()
> > cs_etm__add_stack_event()
> >
> > If this lets code more difficult to understand, will drop it.
> >
>
> I agree with the consolidation but for that to work function
> cs_etm__instr_addr() needs to be refactored. Since
> cs_etm__instr_size() is already taking care of checking the ISA type
> the while() loop in cs_etm__instr_addr() can be done regardless of the
> operation mode. That way cs_etm__instr_size() can be changed at will
> without breaking anything.
>
> The downside is that we are doing a few more iterations... Which isn't
> that big a deal considering we are in user space. We can think about
> some optimisation if it is ever proven to be a bottleneck.
>
> Let me know if you see a problem with that approach.
Yes, your approach is neat; I will try it in next patch version.
Thanks a lot for suggestion!
[...]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 1/1] KVM: inject data abort if instruction cannot be decoded
From: Guoheyi @ 2019-09-05 1:35 UTC (permalink / raw)
To: Heinrich Schuchardt, Marc Zyngier
Cc: Peter Maydell, Daniel P . Berrangé, Julien Thierry,
Suzuki K Pouloze, linux-kernel, zhengxiang 00421807, James Morse,
Stefan Hajnoczi, wanghaibin 00208455, kvmarm, linux-arm-kernel
In-Reply-To: <20190904180736.29009-1-xypron.glpk@gmx.de>
That's interesting; we also met this issue yesterday :)
HG
On 2019/9/5 2:07, Heinrich Schuchardt wrote:
> If an application tries to access memory that is not mapped, an error
> ENOSYS, "load/store instruction decoding not implemented" may occur.
> QEMU will hang with a register dump.
>
> Instead create a data abort that can be handled gracefully by the
> application running in the virtual environment.
>
> Now the virtual machine can react to the event in the most appropriate
> way - by recovering, by writing an informative log, or by rebooting.
>
> Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
> ---
> virt/kvm/arm/mmio.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/virt/kvm/arm/mmio.c b/virt/kvm/arm/mmio.c
> index a8a6a0c883f1..0cbed7d6a0f4 100644
> --- a/virt/kvm/arm/mmio.c
> +++ b/virt/kvm/arm/mmio.c
> @@ -161,8 +161,8 @@ int io_mem_abort(struct kvm_vcpu *vcpu, struct kvm_run *run,
> if (ret)
> return ret;
> } else {
> - kvm_err("load/store instruction decoding not implemented\n");
> - return -ENOSYS;
> + kvm_inject_dabt(vcpu, kvm_vcpu_get_hfar(vcpu));
> + return 1;
> }
>
> rt = vcpu->arch.mmio_decode.rt;
> --
> 2.23.0.rc1
>
>
> _______________________________________________
> 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
* [PATCH v2 4/4] gpio: dt-bindings: Update documentation with ast2600 controllers
From: Rashmica Gupta @ 2019-09-05 1:18 UTC (permalink / raw)
To: linus.walleij
Cc: Mark Rutland, devicetree, linux-aspeed, linux-gpio,
Andrew Jeffery, linux-kernel, Bartosz Golaszewski, Rob Herring,
Joel Stanley, Rashmica Gupta, linux-arm-kernel
The ast2600 is a new generation of SoC from ASPEED. Similarly to the
ast2400 and ast2500, it has a GPIO controller for it's 3.6V GPIO pins.
Additionally, it has a GPIO controller for 36 1.8V GPIO pins. These
voltages are fixed and cannot be configured via pinconf, so we have two
separate drivers for them.
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
---
Documentation/devicetree/bindings/gpio/gpio-aspeed.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
index 7e9b586770b0..cd388797e07c 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-aspeed.txt
@@ -2,7 +2,8 @@ Aspeed GPIO controller Device Tree Bindings
-------------------------------------------
Required properties:
-- compatible : Either "aspeed,ast2400-gpio" or "aspeed,ast2500-gpio"
+- compatible : Either "aspeed,ast2400-gpio", "aspeed,ast2500-gpio",
+ "aspeed,ast2600-gpio", or "aspeed,ast2600-1-8v-gpio"
- #gpio-cells : Should be two
- First cell is the GPIO line number
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 3/4] gpio: Add in ast2600 details to Aspeed driver
From: Rashmica Gupta @ 2019-09-05 1:17 UTC (permalink / raw)
To: linus.walleij
Cc: linux-aspeed, linux-gpio, Andrew Jeffery, linux-kernel,
Bartosz Golaszewski, Joel Stanley, Rashmica Gupta,
linux-arm-kernel
The ast2600 is a new generation of SoC from ASPEED. Similarly to the
ast2400 and ast2500, it has a GPIO controller for it's 3.6V GPIO pins.
Additionally, it has a GPIO controller for 36 1.8V GPIO pins. These
voltages are fixed and cannot be configured via pinconf, so we need two
separate drivers for them.
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
---
drivers/gpio/gpio-aspeed.c | 30 ++++++++++++++++++++++++++++--
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 16c6eaf70857..4723b8780a8c 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -662,12 +662,14 @@ static void aspeed_gpio_irq_handler(struct irq_desc *desc)
struct gpio_chip *gc = irq_desc_get_handler_data(desc);
struct irq_chip *ic = irq_desc_get_chip(desc);
struct aspeed_gpio *data = gpiochip_get_data(gc);
- unsigned int i, p, girq;
+ unsigned int i, p, girq, banks;
unsigned long reg;
+ struct aspeed_gpio *gpio = gpiochip_get_data(gc);
chained_irq_enter(ic, desc);
- for (i = 0; i < ARRAY_SIZE(aspeed_gpio_banks); i++) {
+ banks = DIV_ROUND_UP(gpio->config->nr_gpios, 32);
+ for (i = 0; i < banks; i++) {
const struct aspeed_gpio_bank *bank = &aspeed_gpio_banks[i];
reg = ioread32(bank_reg(data, bank, reg_irq_status));
@@ -1108,9 +1110,33 @@ static const struct aspeed_gpio_config ast2500_config =
/* 232 for simplicity, actual number is 228 (4-GPIO hole in GPIOAB) */
{ .nr_gpios = 232, .props = ast2500_bank_props, };
+static const struct aspeed_bank_props ast2600_bank_props[] = {
+ /* input output */
+ {5, 0xffffffff, 0x0000ffff}, /* U/V/W/X */
+ {6, 0xffff0000, 0x0fff0000}, /* Y/Z */
+ { },
+};
+
+static const struct aspeed_gpio_config ast2600_config =
+ /* 208 3.6V GPIOs */
+ { .nr_gpios = 208, .props = ast2600_bank_props, };
+
+static const struct aspeed_bank_props ast2600_1_8v_bank_props[] = {
+ /* input output */
+ {1, 0x0000000f, 0x0000000f}, /* E */
+ { },
+};
+
+static const struct aspeed_gpio_config ast2600_1_8v_config =
+ /* 36 1.8V GPIOs */
+ { .nr_gpios = 36, .props = ast2600_1_8v_bank_props, };
+
static const struct of_device_id aspeed_gpio_of_table[] = {
{ .compatible = "aspeed,ast2400-gpio", .data = &ast2400_config, },
{ .compatible = "aspeed,ast2500-gpio", .data = &ast2500_config, },
+ { .compatible = "aspeed,ast2600-gpio", .data = &ast2600_config, },
+ { .compatible = "aspeed,ast2600-1-8v-gpio",
+ .data = &ast2600_1_8v_config, },
{}
};
MODULE_DEVICE_TABLE(of, aspeed_gpio_of_table);
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 2/4] gpio/aspeed: Setup irqchip dynamically
From: Rashmica Gupta @ 2019-09-05 1:17 UTC (permalink / raw)
To: linus.walleij
Cc: linux-aspeed, linux-gpio, Andrew Jeffery, linux-kernel,
Bartosz Golaszewski, Joel Stanley, Rashmica Gupta,
linux-arm-kernel
This is in preparation for adding ast2600 support. The ast2600 requires two
GPIO drivers which each need their own irqchip.
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
---
drivers/gpio/gpio-aspeed.c | 16 +++++++---------
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index b83e23aecd18..16c6eaf70857 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -52,6 +52,7 @@ struct aspeed_gpio_config {
*/
struct aspeed_gpio {
struct gpio_chip chip;
+ struct irq_chip irqc;
spinlock_t lock;
void __iomem *base;
int irq;
@@ -681,14 +682,6 @@ static void aspeed_gpio_irq_handler(struct irq_desc *desc)
chained_irq_exit(ic, desc);
}
-static struct irq_chip aspeed_gpio_irqchip = {
- .name = "aspeed-gpio",
- .irq_ack = aspeed_gpio_irq_ack,
- .irq_mask = aspeed_gpio_irq_mask,
- .irq_unmask = aspeed_gpio_irq_unmask,
- .irq_set_type = aspeed_gpio_set_type,
-};
-
static void set_irq_valid_mask(struct aspeed_gpio *gpio)
{
const struct aspeed_bank_props *props = gpio->config->props;
@@ -1192,7 +1185,12 @@ static int __init aspeed_gpio_probe(struct platform_device *pdev)
gpio->irq = rc;
girq = &gpio->chip.irq;
- girq->chip = &aspeed_gpio_irqchip;
+ girq->chip = &gpio->irqc;
+ girq->chip->name = dev_name(&pdev->dev);
+ girq->chip->irq_ack = aspeed_gpio_irq_ack;
+ girq->chip->irq_mask = aspeed_gpio_irq_mask;
+ girq->chip->irq_unmask = aspeed_gpio_irq_unmask;
+ girq->chip->irq_set_type = aspeed_gpio_set_type;
girq->parent_handler = aspeed_gpio_irq_handler;
girq->num_parents = 1;
girq->parents = devm_kcalloc(&pdev->dev, 1,
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 1/4] gpio/aspeed: Fix incorrect number of banks
From: Rashmica Gupta @ 2019-09-05 1:16 UTC (permalink / raw)
To: linus.walleij
Cc: linux-aspeed, linux-gpio, Andrew Jeffery, linux-kernel,
Bartosz Golaszewski, Joel Stanley, Rashmica Gupta,
linux-arm-kernel
The current calculation for the number of GPIO banks is only correct if
the number of GPIOs is a multiple of 32 (if there were 31 GPIOs we would
currently say there are 0 banks, which is incorrect).
Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver')
Signed-off-by: Rashmica Gupta <rashmica.g@gmail.com>
---
drivers/gpio/gpio-aspeed.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c
index 9defe25d4721..b83e23aecd18 100644
--- a/drivers/gpio/gpio-aspeed.c
+++ b/drivers/gpio/gpio-aspeed.c
@@ -1165,7 +1165,7 @@ static int __init aspeed_gpio_probe(struct platform_device *pdev)
gpio->chip.base = -1;
/* Allocate a cache of the output registers */
- banks = gpio->config->nr_gpios >> 5;
+ banks = DIV_ROUND_UP(gpio->config->nr_gpios, 32);
gpio->dcache = devm_kcalloc(&pdev->dev,
banks, sizeof(u32), GFP_KERNEL);
if (!gpio->dcache)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/4] Add ast2600 gpio support
From: Rashmica Gupta @ 2019-09-05 1:16 UTC (permalink / raw)
To: linus.walleij
Cc: linux-aspeed, linux-gpio, Andrew Jeffery, linux-kernel,
Bartosz Golaszewski, Joel Stanley, Rashmica Gupta,
linux-arm-kernel
v2: More verbose commit messages, using DIV_ROUND_UP().
Rashmica Gupta (4):
gpio/aspeed: Fix incorrect number of banks
gpio/aspeed: Setup irqchip dynamically
gpio: Add in ast2600 details to Aspeed driver
gpio: dt-bindings: Update documentation with ast2600 controllers
drivers/gpio/gpio-aspeed.c | 48 ++++++++++++++-----
.../devicetree/bindings/gpio/gpio-aspeed.txt | 3 +-
2 files changed, 38 insertions(+), 13 deletions(-)
--
2.20.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [GIT PULL] ARM: aspeed: devicetree changes for 5.4, round two
From: Joel Stanley @ 2019-09-05 0:43 UTC (permalink / raw)
To: arm, soc; +Cc: Andrew Jeffery, Linux ARM, linux-aspeed
Hello ARM maintainers,
Here are some late fixes I collected for the ASPEED boards.
I've thrown the commits on top of the ones in the first pull request, which
you've merged. I've not sent a second pull before so if that's not the done
thing then let me know what you prefer.
The following changes since commit 49b0f3be0b86292eed6f6aedadf4252131d9c111:
ARM: dts: aspeed: swift: Add eMMC device (2019-08-22 15:34:20 +0930)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed.git \
tags/aspeed-5.4-devicetree-2
for you to fetch changes up to 89b97c429e2e77d695b5133572ca12ec256a4ea4:
ARM: dts: aspeed-g5: Fixe gpio-ranges upper limit (2019-09-04 17:34:34 -0700)
----------------------------------------------------------------
ASPEED device tree updates for 5.4, second round
- Alternate flash support for Vesnin
- Minor cleanups and fixes
----------------------------------------------------------------
Eddie James (1):
ARM: dts: aspeed: swift: Change power supplies to version 2
Ivan Mikhaylov (2):
ARM: dts: aspeed: vesnin: Add wdt2 with alt-boot option
ARM: dts: aspeed: vesnin: Add secondary SPI flash chip
Joel Stanley (2):
ARM: dts: aspeed-g4: Add all flash chips
ARM; dts: aspeed: mihawk: File should not be executable
Oscar A Perez (1):
ARM: dts: aspeed-g5: Fixe gpio-ranges upper limit
arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts | 0
arch/arm/boot/dts/aspeed-bmc-opp-swift.dts | 4 ++--
arch/arm/boot/dts/aspeed-bmc-opp-vesnin.dts | 10 ++++++++++
arch/arm/boot/dts/aspeed-g4.dtsi | 20 ++++++++++++++++++++
arch/arm/boot/dts/aspeed-g5.dtsi | 2 +-
5 files changed, 33 insertions(+), 3 deletions(-)
mode change 100755 => 100644 arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: aspeed-g4: Add all flash chips
From: Andrew Jeffery @ 2019-09-05 0:33 UTC (permalink / raw)
To: Joel Stanley, Cédric Le Goater
Cc: devicetree, linux-aspeed, linux-arm-kernel
In-Reply-To: <20190905000221.31445-1-joel@jms.id.au>
On Thu, 5 Sep 2019, at 09:32, Joel Stanley wrote:
> The FMC supports five chip selects, so describe the five possible flash
> chips.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
> ---
> arch/arm/boot/dts/aspeed-g4.dtsi | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-g4.dtsi b/arch/arm/boot/dts/aspeed-g4.dtsi
> index e465cda40fe7..dffb595d30e4 100644
> --- a/arch/arm/boot/dts/aspeed-g4.dtsi
> +++ b/arch/arm/boot/dts/aspeed-g4.dtsi
> @@ -67,6 +67,26 @@
> compatible = "jedec,spi-nor";
> status = "disabled";
> };
> + flash@1 {
> + reg = < 1 >;
> + compatible = "jedec,spi-nor";
> + status = "disabled";
> + };
> + flash@2 {
> + reg = < 2 >;
> + compatible = "jedec,spi-nor";
> + status = "disabled";
> + };
> + flash@3 {
> + reg = < 3 >;
> + compatible = "jedec,spi-nor";
> + status = "disabled";
> + };
> + flash@4 {
> + reg = < 4 >;
> + compatible = "jedec,spi-nor";
> + status = "disabled";
> + };
The FMC supports parallel NOR and NAND interfaces too, but so far no-one has
cared for these options, so if they ever do we'll fix it then.
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
_______________________________________________
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