* Status of Subsystems - MICROCHIP SAMA5D2-COMPATIBLE PIOBU GPIO
From: Sebastian Duda @ 2019-08-20 13:27 UTC (permalink / raw)
To: Andrei Stefanescu
Cc: linux-gpio, linux-kernel, linux-arm-kernel, lukas.bulwahn
Hello Andrei,
in my master thesis, I'm using the association of subsystems to
maintainers/reviewers and its status given in the MAINTAINERS file.
During the research I noticed that there are several subsystems without
a status in the maintainers file. One of them is the subsystem
`MICROCHIP SAMA5D2-COMPATIBLE PIOBU GPIO` where you're mentioned as
maintainer.
Is it intended not to mention a status for your subsystems?
What is the current status of your subsystem?
Kind regards
Sebastian Duda
_______________________________________________
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] MAINTAINERS: Extend patterns for Samsung SoC, Security Subsystem and clock drivers
From: Sylwester Nawrocki @ 2019-08-20 13:34 UTC (permalink / raw)
To: Krzysztof Kozlowski, linux-samsung-soc, linux-clk
Cc: Herbert Xu, Stephen Boyd, linux-kernel, Michael Turquette,
Tomasz Figa, Vladimir Zapolskiy, Chanwoo Choi, Kukjin Kim,
linux-crypto, Kamil Konieczny, David S. Miller, linux-arm-kernel
In-Reply-To: <20190818172750.20921-1-krzk@kernel.org>
On 8/18/19 19:27, Krzysztof Kozlowski wrote:
> Extend the patterns to cover all related files in respective
> categories:
> 1. Samsung Exynos ARM architecture: add soc drivers headers and make
> directory matches consistent,
> 2. Samsung Security SubSystem driver (crypto): add bindings,
> 3. Samsung SoC clock drivers: add S3C24xx, S3C64xx and S5Pv210 bindings.
Acked-by: Sylwester Nawrocki <s.nawrocki@samsung.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v4 04/10] mailbox: sunxi-msgbox: Add a new mailbox driver
From: Ondřej Jirman @ 2019-08-20 13:34 UTC (permalink / raw)
To: Samuel Holland
Cc: Mark Rutland, devicetree, linux-sunxi, Maxime Ripard,
Michael Turquette, Jassi Brar, linux-kernel, Stephen Boyd,
Chen-Yu Tsai, Rob Herring, Corentin Labbe, linux-clk,
linux-arm-kernel
In-Reply-To: <bc09e14c-1cf5-8124-fc34-c651b78577ce@sholland.org>
Hi,
On Tue, Aug 20, 2019 at 08:07:53AM -0500, Samuel Holland wrote:
> On 8/20/19 6:18 AM, Ondřej Jirman wrote:
> > Hi Samuel,
> >
> > On Mon, Aug 19, 2019 at 10:23:05PM -0500, Samuel Holland wrote:
> >> Allwinner sun8i, sun9i, and sun50i SoCs contain a hardware message box
> >> used for communication between the ARM CPUs and the ARISC management
> >> coprocessor. The hardware contains 8 unidirectional 4-message FIFOs.
> >>
> >> Add a driver for it, so it can be used for SCPI or other communication
> >> protocols.
> >>
> >> Signed-off-by: Samuel Holland <samuel@sholland.org>
> >> ---
> >> drivers/mailbox/Kconfig | 10 +
> >> drivers/mailbox/Makefile | 2 +
> >> drivers/mailbox/sunxi-msgbox.c | 323 +++++++++++++++++++++++++++++++++
> >> 3 files changed, 335 insertions(+)
> >> create mode 100644 drivers/mailbox/sunxi-msgbox.c
> >>
> >> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> >> index ab4eb750bbdd..57d12936175e 100644
> >> --- a/drivers/mailbox/Kconfig
> >> +++ b/drivers/mailbox/Kconfig
> >> @@ -227,4 +227,14 @@ config ZYNQMP_IPI_MBOX
> >> message to the IPI buffer and will access the IPI control
> >> registers to kick the other processor or enquire status.
> >>
> >> +config SUNXI_MSGBOX
> >> + tristate "Allwinner sunxi Message Box"
> >> + depends on ARCH_SUNXI || COMPILE_TEST
> >> + default ARCH_SUNXI
> >> + help
> >> + Mailbox implementation for the hardware message box present in
> >> + Allwinner sun8i, sun9i, and sun50i SoCs. The hardware message box is
> >> + used for communication between the application CPUs and the power
> >> + management coprocessor.
> >> +
> >> endif
> >> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> >> index c22fad6f696b..bec2d50b0976 100644
> >> --- a/drivers/mailbox/Makefile
> >> +++ b/drivers/mailbox/Makefile
> >> @@ -48,3 +48,5 @@ obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
> >> obj-$(CONFIG_MTK_CMDQ_MBOX) += mtk-cmdq-mailbox.o
> >>
> >> obj-$(CONFIG_ZYNQMP_IPI_MBOX) += zynqmp-ipi-mailbox.o
> >> +
> >> +obj-$(CONFIG_SUNXI_MSGBOX) += sunxi-msgbox.o
> >> diff --git a/drivers/mailbox/sunxi-msgbox.c b/drivers/mailbox/sunxi-msgbox.c
> >> new file mode 100644
> >> index 000000000000..29a5101a5390
> >> --- /dev/null
> >> +++ b/drivers/mailbox/sunxi-msgbox.c
> >> @@ -0,0 +1,323 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +//
> >> +// Copyright (c) 2017-2019 Samuel Holland <samuel@sholland.org>
> >> +
> >> +#include <linux/bitops.h>
> >> +#include <linux/clk.h>
> >> +#include <linux/device.h>
> >> +#include <linux/err.h>
> >> +#include <linux/interrupt.h>
> >> +#include <linux/io.h>
> >> +#include <linux/kernel.h>
> >> +#include <linux/mailbox_controller.h>
> >> +#include <linux/module.h>
> >> +#include <linux/of.h>
> >> +#include <linux/of_irq.h>
> >> +#include <linux/platform_device.h>
> >> +#include <linux/reset.h>
> >> +#include <linux/spinlock.h>
> >> +
> >> +#define NUM_CHANS 8
> >> +
> >> +#define CTRL_REG(n) (0x0000 + 0x4 * ((n) / 4))
> >> +#define CTRL_RX(n) BIT(0 + 8 * ((n) % 4))
> >> +#define CTRL_TX(n) BIT(4 + 8 * ((n) % 4))
> >> +
> >> +#define REMOTE_IRQ_EN_REG 0x0040
> >> +#define REMOTE_IRQ_STAT_REG 0x0050
> >> +#define LOCAL_IRQ_EN_REG 0x0060
> >> +#define LOCAL_IRQ_STAT_REG 0x0070
> >> +
> >> +#define RX_IRQ(n) BIT(0 + 2 * (n))
> >> +#define RX_IRQ_MASK 0x5555
> >> +#define TX_IRQ(n) BIT(1 + 2 * (n))
> >> +#define TX_IRQ_MASK 0xaaaa
> >> +
> >> +#define FIFO_STAT_REG(n) (0x0100 + 0x4 * (n))
> >> +#define FIFO_STAT_MASK GENMASK(0, 0)
> >> +
> >> +#define MSG_STAT_REG(n) (0x0140 + 0x4 * (n))
> >> +#define MSG_STAT_MASK GENMASK(2, 0)
> >> +
> >> +#define MSG_DATA_REG(n) (0x0180 + 0x4 * (n))
> >> +
> >> +#define mbox_dbg(mbox, ...) dev_dbg((mbox)->controller.dev, __VA_ARGS__)
> >> +
> >> +struct sunxi_msgbox {
> >> + struct mbox_controller controller;
> >> + struct clk *clk;
> >> + spinlock_t lock;
> >> + void __iomem *regs;
> >> +};
> >> +
> >> +static bool sunxi_msgbox_last_tx_done(struct mbox_chan *chan);
> >> +static bool sunxi_msgbox_peek_data(struct mbox_chan *chan);
> >> +
> >> +static inline int channel_number(struct mbox_chan *chan)
> >> +{
> >> + return chan - chan->mbox->chans;
> >> +}
> >> +
> >> +static inline struct sunxi_msgbox *channel_to_msgbox(struct mbox_chan *chan)
> >> +{
> >> + return chan->con_priv;
> >> +}
> >> +
> >> +static irqreturn_t sunxi_msgbox_irq(int irq, void *dev_id)
> >> +{
> >> + struct sunxi_msgbox *mbox = dev_id;
> >> + uint32_t status;
> >> + int n;
> >> +
> >> + /* Only examine channels that are currently enabled. */
> >> + status = readl(mbox->regs + LOCAL_IRQ_EN_REG) &
> >> + readl(mbox->regs + LOCAL_IRQ_STAT_REG);
> >> +
> >> + if (!(status & RX_IRQ_MASK))
> >> + return IRQ_NONE;
> >> +
> >> + for (n = 0; n < NUM_CHANS; ++n) {
> >> + struct mbox_chan *chan = &mbox->controller.chans[n];
> >> +
> >> + if (!(status & RX_IRQ(n)))
> >> + continue;
> >> +
> >> + while (sunxi_msgbox_peek_data(chan)) {
> >> + uint32_t msg = readl(mbox->regs + MSG_DATA_REG(n));
> >> +
> >> + mbox_dbg(mbox, "Channel %d received 0x%08x\n", n, msg);
> >> + mbox_chan_received_data(chan, &msg);
> >> + }
> >> +
> >> + /* The IRQ can be cleared only once the FIFO is empty. */
> >> + writel(RX_IRQ(n), mbox->regs + LOCAL_IRQ_STAT_REG);
> >> + }
> >> +
> >> + return IRQ_HANDLED;
> >> +}
> >> +
> >> +static int sunxi_msgbox_send_data(struct mbox_chan *chan, void *data)
> >> +{
> >> + struct sunxi_msgbox *mbox = channel_to_msgbox(chan);
> >> + int n = channel_number(chan);
> >> + uint32_t msg = *(uint32_t *)data;
> >> +
> >> + /* Using a channel backwards gets the hardware into a bad state. */
> >> + if (WARN_ON_ONCE(!(readl(mbox->regs + CTRL_REG(n)) & CTRL_TX(n))))
> >> + return 0;
> >> +
> >> + /* We cannot post a new message if the FIFO is full. */
> >> + if (readl(mbox->regs + FIFO_STAT_REG(n)) & FIFO_STAT_MASK) {
> >> + mbox_dbg(mbox, "Channel %d busy sending 0x%08x\n", n, msg);
> >> + return -EBUSY;
> >> + }
> >> +
> >> + writel(msg, mbox->regs + MSG_DATA_REG(n));
> >> + mbox_dbg(mbox, "Channel %d sent 0x%08x\n", n, msg);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static int sunxi_msgbox_startup(struct mbox_chan *chan)
> >> +{
> >> + struct sunxi_msgbox *mbox = channel_to_msgbox(chan);
> >> + int n = channel_number(chan);
> >> +
> >> + /* The coprocessor is responsible for setting channel directions. */
> >> + if (readl(mbox->regs + CTRL_REG(n)) & CTRL_RX(n)) {
> >> + /* Flush the receive FIFO. */
> >> + while (sunxi_msgbox_peek_data(chan))
> >> + readl(mbox->regs + MSG_DATA_REG(n));
> >> + writel(RX_IRQ(n), mbox->regs + LOCAL_IRQ_STAT_REG);
> >> +
> >> + /* Enable the receive IRQ. */
> >> + spin_lock(&mbox->lock);
> >> + writel(readl(mbox->regs + LOCAL_IRQ_EN_REG) | RX_IRQ(n),
> >> + mbox->regs + LOCAL_IRQ_EN_REG);
> >> + spin_unlock(&mbox->lock);
> >> + }
> >> +
> >> + mbox_dbg(mbox, "Channel %d startup complete\n", n);
> >> +
> >> + return 0;
> >> +}
> >> +
> >> +static void sunxi_msgbox_shutdown(struct mbox_chan *chan)
> >> +{
> >> + struct sunxi_msgbox *mbox = channel_to_msgbox(chan);
> >> + int n = channel_number(chan);
> >> +
> >> + if (readl(mbox->regs + CTRL_REG(n)) & CTRL_RX(n)) {
> >> + /* Disable the receive IRQ. */
> >> + spin_lock(&mbox->lock);
> >> + writel(readl(mbox->regs + LOCAL_IRQ_EN_REG) & ~RX_IRQ(n),
> >> + mbox->regs + LOCAL_IRQ_EN_REG);
> >> + spin_unlock(&mbox->lock);
> >> +
> >> + /* Attempt to flush the FIFO until the IRQ is cleared. */
> >> + do {
> >> + while (sunxi_msgbox_peek_data(chan))
> >> + readl(mbox->regs + MSG_DATA_REG(n));
> >> + writel(RX_IRQ(n), mbox->regs + LOCAL_IRQ_STAT_REG);
> >> + } while (readl(mbox->regs + LOCAL_IRQ_STAT_REG) & RX_IRQ(n));
> >> + }
> >> +
> >> + mbox_dbg(mbox, "Channel %d shutdown complete\n", n);
> >> +}
> >> +
> >> +static bool sunxi_msgbox_last_tx_done(struct mbox_chan *chan)
> >> +{
> >> + struct sunxi_msgbox *mbox = channel_to_msgbox(chan);
> >> + int n = channel_number(chan);
> >> +
> >> + /*
> >> + * The hardware allows snooping on the remote user's IRQ statuses.
> >> + * We consider a message to be acknowledged only once the receive IRQ
> >> + * for that channel is cleared. Since the receive IRQ for a channel
> >> + * cannot be cleared until the FIFO for that channel is empty, this
> >> + * ensures that the message has actually been read. It also gives the
> >> + * recipient an opportunity to perform minimal processing before
> >> + * acknowledging the message.
> >> + */
> >> + return !(readl(mbox->regs + REMOTE_IRQ_STAT_REG) & RX_IRQ(n));
> >> +}
> >> +
> >> +static bool sunxi_msgbox_peek_data(struct mbox_chan *chan)
> >> +{
> >> + struct sunxi_msgbox *mbox = channel_to_msgbox(chan);
> >> + int n = channel_number(chan);
> >> +
> >> + return readl(mbox->regs + MSG_STAT_REG(n)) & MSG_STAT_MASK;
> >> +}
> >> +
> >> +static const struct mbox_chan_ops sunxi_msgbox_chan_ops = {
> >> + .send_data = sunxi_msgbox_send_data,
> >> + .startup = sunxi_msgbox_startup,
> >> + .shutdown = sunxi_msgbox_shutdown,
> >> + .last_tx_done = sunxi_msgbox_last_tx_done,
> >> + .peek_data = sunxi_msgbox_peek_data,
> >> +};
> >> +
> >> +static int sunxi_msgbox_probe(struct platform_device *pdev)
> >> +{
> >> + struct device *dev = &pdev->dev;
> >> + struct mbox_chan *chans;
> >> + struct reset_control *reset;
> >> + struct resource *res;
> >> + struct sunxi_msgbox *mbox;
> >> + int i, ret;
> >> +
> >> + mbox = devm_kzalloc(dev, sizeof(*mbox), GFP_KERNEL);
> >> + if (!mbox)
> >> + return -ENOMEM;
> >> +
> >> + chans = devm_kcalloc(dev, NUM_CHANS, sizeof(*chans), GFP_KERNEL);
> >> + if (!chans)
> >> + return -ENOMEM;
> >> +
> >> + for (i = 0; i < NUM_CHANS; ++i)
> >> + chans[i].con_priv = mbox;
> >> +
> >> + mbox->clk = devm_clk_get(dev, NULL);
> >> + if (IS_ERR(mbox->clk)) {
> >> + ret = PTR_ERR(mbox->clk);
> >> + dev_err(dev, "Failed to get clock: %d\n", ret);
> >> + return ret;
> >> + }
> >> +
> >> + ret = clk_prepare_enable(mbox->clk);
> >> + if (ret) {
> >> + dev_err(dev, "Failed to enable clock: %d\n", ret);
> >> + return ret;
> >> + }
> >> +
> >> + reset = devm_reset_control_get(dev, NULL);
> >> + if (IS_ERR(reset)) {
> >> + ret = PTR_ERR(reset);
> >> + dev_err(dev, "Failed to get reset control: %d\n", ret);
> >> + goto err_disable_unprepare;
> >> + }
> >> +
> >> + ret = reset_control_deassert(reset);
> >> + if (ret) {
> >> + dev_err(dev, "Failed to deassert reset: %d\n", ret);
> >> + goto err_disable_unprepare;
> >> + }
> >
> > You need to assert the reset again from now on, in error paths. devm
> > will not do that for you.
>
> I know, and that's intentional. This same message box device is used for ATF to
> communicate with SCP firmware (on a different channel). This could be happening
> on a different core while Linux is running. So Linux is not allowed to deassert
> the reset. clk_disable_unprepare() is only okay because the clock is marked as
> critical.
Okay. It needs to be docummented here though, so that someone will
not "fix" it in the future, after finding this with coccinelle or
something.
regards,
o.
> >> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >> + if (!res) {
> >> + ret = -ENODEV;
> >> + goto err_disable_unprepare;
> >> + }
> >> +
> >> + mbox->regs = devm_ioremap_resource(&pdev->dev, res);
> >> + if (IS_ERR(mbox->regs)) {
> >> + ret = PTR_ERR(mbox->regs);
> >> + dev_err(dev, "Failed to map MMIO resource: %d\n", ret);
> >> + goto err_disable_unprepare;
> >> + }
> >> +
> >> + /* Disable all IRQs for this end of the msgbox. */
> >> + writel(0, mbox->regs + LOCAL_IRQ_EN_REG);
> >> +
> >> + ret = devm_request_irq(dev, irq_of_parse_and_map(dev->of_node, 0),
> >> + sunxi_msgbox_irq, 0, dev_name(dev), mbox);
> >> + if (ret) {
> >> + dev_err(dev, "Failed to register IRQ handler: %d\n", ret);
> >> + goto err_disable_unprepare;
> >> + }
> >> +
> >> + mbox->controller.dev = dev;
> >> + mbox->controller.ops = &sunxi_msgbox_chan_ops;
> >> + mbox->controller.chans = chans;
> >> + mbox->controller.num_chans = NUM_CHANS;
> >> + mbox->controller.txdone_irq = false;
> >> + mbox->controller.txdone_poll = true;
> >> + mbox->controller.txpoll_period = 5;
> >> +
> >> + spin_lock_init(&mbox->lock);
> >> + platform_set_drvdata(pdev, mbox);
> >> +
> >> + ret = mbox_controller_register(&mbox->controller);
> >> + if (ret) {
> >> + dev_err(dev, "Failed to register controller: %d\n", ret);
> >> + goto err_disable_unprepare;
> >> + }
> >> +
> >> + return 0;
> >> +
> >> +err_disable_unprepare:
> >> + clk_disable_unprepare(mbox->clk);
> >> +
> >> + return ret;
> >> +}
> >> +
> >> +static int sunxi_msgbox_remove(struct platform_device *pdev)
> >> +{
> >> + struct sunxi_msgbox *mbox = platform_get_drvdata(pdev);
> >> +
> >> + mbox_controller_unregister(&mbox->controller);
> >> + clk_disable_unprepare(mbox->clk);
> >
> > Also, assert the reset here.
>
> Same comment as above. This is intentional.
>
> Thanks,
> Samuel
>
> >> + return 0;
> >> +}
> >> +
> >> +static const struct of_device_id sunxi_msgbox_of_match[] = {
> >> + { .compatible = "allwinner,sun6i-a31-msgbox", },
> >> + {},
> >> +};
> >> +MODULE_DEVICE_TABLE(of, sunxi_msgbox_of_match);
> >> +
> >> +static struct platform_driver sunxi_msgbox_driver = {
> >> + .driver = {
> >> + .name = "sunxi-msgbox",
> >> + .of_match_table = sunxi_msgbox_of_match,
> >> + },
> >> + .probe = sunxi_msgbox_probe,
> >> + .remove = sunxi_msgbox_remove,
> >> +};
> >> +module_platform_driver(sunxi_msgbox_driver);
> >> +
> >> +MODULE_AUTHOR("Samuel Holland <samuel@sholland.org>");
> >> +MODULE_DESCRIPTION("Allwinner sunxi Message Box");
> >> +MODULE_LICENSE("GPL v2");
> >> --
> >> 2.21.0
>
> _______________________________________________
> 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 4/4] iommu/io-pgtable-arm: Prepare for TTBR1 usage
From: Robin Murphy @ 2019-08-20 13:51 UTC (permalink / raw)
To: will, joro, iommu, linux-arm-kernel, robdclark
In-Reply-To: <20190819223439.GG28465@jcrouse1-lnx.qualcomm.com>
On 19/08/2019 23:34, Jordan Crouse wrote:
> On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
>> Now that callers are free to use a given table for TTBR1 if they wish
>> (all they need do is shift the provided attributes when constructing
>> their final TCR value), the only remaining impediment is the address
>> validation on map/unmap. The fact that the LPAE address space split is
>> symmetric makes this easy to accommodate - by simplifying the current
>> range checks into explicit tests that address bits above IAS are all
>> zero, it then follows straightforwardly to add the inverse test to
>> allow the all-ones case as well.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/io-pgtable-arm.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>> index 09cb20671fbb..f39c50356351 100644
>> --- a/drivers/iommu/io-pgtable-arm.c
>> +++ b/drivers/iommu/io-pgtable-arm.c
>> @@ -475,13 +475,13 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
>> arm_lpae_iopte *ptep = data->pgd;
>> int ret, lvl = ARM_LPAE_START_LVL(data);
>> arm_lpae_iopte prot;
>> + long iaext = (long)iova >> data->iop.cfg.ias;
>>
>> /* If no access, then nothing to do */
>> if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
>> return 0;
>>
>> - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias) ||
>> - paddr >= (1ULL << data->iop.cfg.oas)))
>> + if (WARN_ON((iaext && ~iaext) || paddr >> data->iop.cfg.oas))
>> return -ERANGE;
>>
>> prot = arm_lpae_prot_to_pte(data, iommu_prot);
>
> We'll want to cast away the sign extended bits before mapping the iova, this
> might be a good patch for that too as long as we are calculating the iaext.
Ah good point, I'd forgotten that ARM_LPAE_LVL_IDX() doesn't actually
cap to IAS if the top level is smaller than bits_per_level (I suppose we
*could* make it do so for purity, but that's bound to hurt efficiency
far more than just zeroing out the offending bits here).
Thanks,
Robin.
>
>> @@ -647,8 +647,9 @@ static size_t arm_lpae_unmap(struct io_pgtable_ops *ops, unsigned long iova,
>> struct arm_lpae_io_pgtable *data = io_pgtable_ops_to_data(ops);
>> arm_lpae_iopte *ptep = data->pgd;
>> int lvl = ARM_LPAE_START_LVL(data);
>> + long iaext = (long)iova >> data->iop.cfg.ias;
>>
>> - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias)))
>> + if (WARN_ON(iaext && ~iaext))
>> return 0;
>>
>> return __arm_lpae_unmap(data, iova, size, lvl, ptep);
>
> And here too.
>
> Jordan
>
_______________________________________________
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] iommu/arm-smmu: Break insecure users by disabling bypass by default
From: Marc Gonzalez @ 2019-08-20 13:55 UTC (permalink / raw)
To: Will Deacon, Jean-Philippe Brucker, Michael S. Tsirkin
Cc: Joerg Roedel, Will Deacon, Douglas Anderson, Jon Hunter,
Thierry Reding, Robin Murphy, Linux ARM
In-Reply-To: <20190819144827.6h4hm2gytogwepi7@willie-the-truck>
On 19/08/2019 16:48, Will Deacon wrote:
> If we can get by with extending the iommu-map entries for the masters,
> that would certainly be the neatest imo. Sounds like it's worth a quick
> hack, if nothing else.
Tangent: I've been meaning to ask about some iommu-map shenanigan.
My kernel reports:
OF: /soc/pci@1c00000: no iommu-map translation for rid 0x0 on (null)
Errr... "Is that a problem, doctor?"
It's a pr_info() message from of_map_rid() in drivers/of/base.c
I note that it used to be an error before fb709b5e1cca5
Regards.
_______________________________________________
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: rockchip: remove rk3288 fennec board support
From: Heiko Stuebner @ 2019-08-20 13:56 UTC (permalink / raw)
To: Kever Yang
Cc: Mark Rutland, devicetree, linux-kernel, linux-rockchip,
Rob Herring, linux-arm-kernel
In-Reply-To: <20190820100353.17728-1-kever.yang@rock-chips.com>
Hi Kever,
Am Dienstag, 20. August 2019, 12:03:52 CEST schrieb Kever Yang:
> Since there is no one using this board, remove it.
so just to elaborate a bit, I guess this board was internal to Rockchip,
never went to the market and therefore is obsolete without any users,
right?
Also we should remove the binding from
Documentation/devicetree/bindings/arm/rockchip.yaml as well
Heiko
> Signed-off-by: Kever Yang <kever.yang@rock-chips.com>
> ---
>
> arch/arm/boot/dts/rk3288-fennec.dts | 347 ----------------------------
> 1 file changed, 347 deletions(-)
> delete mode 100644 arch/arm/boot/dts/rk3288-fennec.dts
>
> diff --git a/arch/arm/boot/dts/rk3288-fennec.dts b/arch/arm/boot/dts/rk3288-fennec.dts
> deleted file mode 100644
> index 4847cf902a15..000000000000
> --- a/arch/arm/boot/dts/rk3288-fennec.dts
> +++ /dev/null
> @@ -1,347 +0,0 @@
> -// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> -
> -/dts-v1/;
> -
> -#include "rk3288.dtsi"
> -
> -/ {
> - model = "Rockchip RK3288 Fennec Board";
> - compatible = "rockchip,rk3288-fennec", "rockchip,rk3288";
> -
> - memory@0 {
> - reg = <0x0 0x0 0x0 0x80000000>;
> - device_type = "memory";
> - };
> -
> - ext_gmac: external-gmac-clock {
> - compatible = "fixed-clock";
> - #clock-cells = <0>;
> - clock-frequency = <125000000>;
> - clock-output-names = "ext_gmac";
> - };
> -
> - vcc_sys: vsys-regulator {
> - compatible = "regulator-fixed";
> - regulator-name = "vcc_sys";
> - regulator-min-microvolt = <5000000>;
> - regulator-max-microvolt = <5000000>;
> - regulator-always-on;
> - regulator-boot-on;
> - };
> -};
> -
> -&cpu0 {
> - cpu0-supply = <&vdd_cpu>;
> -};
> -
> -&emmc {
> - bus-width = <8>;
> - cap-mmc-highspeed;
> - non-removable;
> - pinctrl-names = "default";
> - pinctrl-0 = <&emmc_clk &emmc_cmd &emmc_pwr &emmc_bus8>;
> - status = "okay";
> -};
> -
> -&gmac {
> - assigned-clocks = <&cru SCLK_MAC>;
> - assigned-clock-parents = <&ext_gmac>;
> - clock_in_out = "input";
> - pinctrl-names = "default";
> - pinctrl-0 = <&rgmii_pins>, <&phy_rst>, <&phy_pmeb>, <&phy_int>;
> - phy-supply = <&vcc_lan>;
> - phy-mode = "rgmii";
> - snps,reset-active-low;
> - snps,reset-delays-us = <0 10000 1000000>;
> - snps,reset-gpio = <&gpio4 RK_PB0 GPIO_ACTIVE_LOW>;
> - tx_delay = <0x30>;
> - rx_delay = <0x10>;
> - status = "okay";
> -};
> -
> -&gpu {
> - mali-supply = <&vdd_gpu>;
> - status = "okay";
> -};
> -
> -&hdmi {
> - status = "okay";
> -};
> -
> -&i2c0 {
> - status = "okay";
> - clock-frequency = <400000>;
> -
> - rk808: pmic@1b {
> - compatible = "rockchip,rk808";
> - reg = <0x1b>;
> - interrupt-parent = <&gpio0>;
> - interrupts = <RK_PA4 IRQ_TYPE_LEVEL_LOW>;
> - #clock-cells = <1>;
> - clock-output-names = "xin32k", "rk808-clkout2";
> - pinctrl-names = "default";
> - pinctrl-0 = <&pmic_int &global_pwroff>;
> - rockchip,system-power-controller;
> - wakeup-source;
> -
> - vcc1-supply = <&vcc_sys>;
> - vcc2-supply = <&vcc_sys>;
> - vcc3-supply = <&vcc_sys>;
> - vcc4-supply = <&vcc_sys>;
> - vcc6-supply = <&vcc_sys>;
> - vcc7-supply = <&vcc_sys>;
> - vcc8-supply = <&vcc_io>;
> - vcc9-supply = <&vcc_io>;
> - vcc10-supply = <&vcc_io>;
> - vcc11-supply = <&vcc_io>;
> - vcc12-supply = <&vcc_io>;
> - vddio-supply = <&vcc_io>;
> -
> - regulators {
> - vdd_cpu: DCDC_REG1 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <750000>;
> - regulator-max-microvolt = <1350000>;
> - regulator-name = "vdd_arm";
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vdd_gpu: DCDC_REG2 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <850000>;
> - regulator-max-microvolt = <1250000>;
> - regulator-name = "vdd_gpu";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1000000>;
> - };
> - };
> -
> - vcc_ddr: DCDC_REG3 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-name = "vcc_ddr";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - };
> - };
> -
> - vcc_io: DCDC_REG4 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-name = "vcc_io";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <3300000>;
> - };
> - };
> -
> - vccio_pmu: LDO_REG1 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-name = "vccio_pmu";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <3300000>;
> - };
> - };
> -
> - vcca_33: LDO_REG2 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <3300000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-name = "vcca_33";
> - regulator-state-mem {
> - regulator-off-in-suspend;
> - };
> - };
> -
> - vdd_10: LDO_REG3 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1000000>;
> - regulator-max-microvolt = <1000000>;
> - regulator-name = "vdd_10";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1000000>;
> - };
> - };
> -
> - vcc_wl: LDO_REG4 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-name = "vcc_wl";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1800000>;
> - };
> - };
> -
> - vccio_sd: LDO_REG5 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <3300000>;
> - regulator-name = "vccio_sd";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <3300000>;
> - };
> - };
> -
> - vdd10_lcd: LDO_REG6 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1000000>;
> - regulator-max-microvolt = <1000000>;
> - regulator-name = "vdd10_lcd";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1000000>;
> - };
> - };
> -
> - vcc_18: LDO_REG7 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-name = "vcc_18";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1800000>;
> - };
> - };
> -
> - vcc18_lcd: LDO_REG8 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <1800000>;
> - regulator-max-microvolt = <1800000>;
> - regulator-name = "vcc18_lcd";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - regulator-suspend-microvolt = <1800000>;
> - };
> - };
> -
> - vcc_sd: SWITCH_REG1 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-name = "vcc_sd";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - };
> - };
> -
> - vcc_lan: SWITCH_REG2 {
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-name = "vcc_lan";
> - regulator-state-mem {
> - regulator-on-in-suspend;
> - };
> - };
> - };
> - };
> -};
> -
> -&pinctrl {
> - pcfg_output_high: pcfg-output-high {
> - output-high;
> - };
> -
> - pcfg_output_low: pcfg-output-low {
> - output-low;
> - };
> -
> - pcfg_pull_none_drv_8ma: pcfg-pull-none-drv-8ma {
> - drive-strength = <8>;
> - };
> -
> - pcfg_pull_up_drv_8ma: pcfg-pull-up-drv-8ma {
> - bias-pull-up;
> - drive-strength = <8>;
> - };
> -
> - gmac {
> - phy_int: phy-int {
> - rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> -
> - phy_pmeb: phy-pmeb {
> - rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> -
> - phy_rst: phy-rst {
> - rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_output_high>;
> - };
> - };
> -
> - pmic {
> - pmic_int: pmic-int {
> - rockchip,pins = <0 RK_PA4 RK_FUNC_GPIO &pcfg_pull_up>;
> - };
> - };
> -
> - usbphy {
> - host_drv: host-drv {
> - rockchip,pins = <0 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
> - };
> - };
> -};
> -
> -&uart2 {
> - status = "okay";
> -};
> -
> -&usbphy {
> - pinctrl-names = "default";
> - pinctrl-0 = <&host_drv>;
> - vbus_drv-gpios = <&gpio0 RK_PB6 GPIO_ACTIVE_HIGH>;
> - status = "okay";
> -};
> -
> -&usb_host0_ehci {
> - status = "okay";
> -};
> -
> -&usb_host1 {
> - status = "okay";
> -};
> -
> -&usb_otg {
> - status = "okay";
> -};
> -
> -&usb_hsic {
> - status = "okay";
> -};
> -
> -&vopb {
> - status = "okay";
> -};
> -
> -&vopb_mmu {
> - status = "okay";
> -};
> -
> -&vopl {
> - status = "okay";
> -};
> -
> -&vopl_mmu {
> - status = "okay";
> -};
>
_______________________________________________
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] ARM64: dts: allwinner: Add devicetree for pine H64 modelA evaluation board
From: Maxime Ripard @ 2019-08-20 13:58 UTC (permalink / raw)
To: Corentin Labbe
Cc: mark.rutland, devicetree, linux-sunxi, linux-kernel, wens,
robh+dt, linux-arm-kernel
In-Reply-To: <20190816140016.GA30445@Red>
[-- Attachment #1.1: Type: text/plain, Size: 5840 bytes --]
On Fri, Aug 16, 2019 at 04:00:16PM +0200, Corentin Labbe wrote:
> On Fri, Aug 16, 2019 at 03:52:06PM +0200, Maxime Ripard wrote:
> > On Fri, Aug 16, 2019 at 01:57:50PM +0200, Corentin Labbe wrote:
> > > On Fri, Aug 16, 2019 at 01:36:50PM +0200, Maxime Ripard wrote:
> > > > On Fri, Aug 16, 2019 at 11:35:13AM +0200, Corentin Labbe wrote:
> > > > > On Wed, Aug 14, 2019 at 03:33:22PM +0200, Maxime Ripard wrote:
> > > > > > On Wed, Aug 14, 2019 at 03:17:41PM +0200, Corentin Labbe wrote:
> > > > > > > On Mon, Aug 12, 2019 at 11:40:00AM +0200, Maxime Ripard wrote:
> > > > > > > > On Thu, Aug 08, 2019 at 10:42:53AM +0200, Corentin Labbe wrote:
> > > > > > > > > This patch adds the evaluation variant of the model A of the PineH64.
> > > > > > > > > The model A has the same size of the pine64 and has a PCIE slot.
> > > > > > > > >
> > > > > > > > > The only devicetree difference with current pineH64, is the PHY
> > > > > > > > > regulator.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > > > > > > ---
> > > > > > > > > arch/arm64/boot/dts/allwinner/Makefile | 1 +
> > > > > > > > > .../sun50i-h6-pine-h64-modelA-eval.dts | 26 +++++++++++++++++++
> > > > > > > > > 2 files changed, 27 insertions(+)
> > > > > > > > > create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > > > > > > >
> > > > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> > > > > > > > > index f6db0611cb85..9a02166cbf72 100644
> > > > > > > > > --- a/arch/arm64/boot/dts/allwinner/Makefile
> > > > > > > > > +++ b/arch/arm64/boot/dts/allwinner/Makefile
> > > > > > > > > @@ -25,3 +25,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-3.dtb
> > > > > > > > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-lite2.dtb
> > > > > > > > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-plus.dtb
> > > > > > > > > dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> > > > > > > > > +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-modelA-eval.dtb
> > > > > > > > > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > > > > > > > new file mode 100644
> > > > > > > > > index 000000000000..d8ff02747efe
> > > > > > > > > --- /dev/null
> > > > > > > > > +++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64-modelA-eval.dts
> > > > > > > > > @@ -0,0 +1,26 @@
> > > > > > > > > +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> > > > > > > > > +/*
> > > > > > > > > + * Copyright (C) 2019 Corentin Labbe <clabbe.montjoie@gmail.com>
> > > > > > > > > + */
> > > > > > > > > +
> > > > > > > > > +#include "sun50i-h6-pine-h64.dts"
> > > > > > > > > +
> > > > > > > > > +/ {
> > > > > > > > > + model = "Pine H64 model A evaluation board";
> > > > > > > > > + compatible = "pine64,pine-h64-modelA-eval", "allwinner,sun50i-h6";
> > > > > > > > > +
> > > > > > > > > + reg_gmac_3v3: gmac-3v3 {
> > > > > > > > > + compatible = "regulator-fixed";
> > > > > > > > > + regulator-name = "vcc-gmac-3v3";
> > > > > > > > > + regulator-min-microvolt = <3300000>;
> > > > > > > > > + regulator-max-microvolt = <3300000>;
> > > > > > > > > + startup-delay-us = <100000>;
> > > > > > > > > + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>;
> > > > > > > > > + enable-active-high;
> > > > > > > > > + };
> > > > > > > > > +
> > > > > > > > > +};
> > > > > > > > > +
> > > > > > > > > +&emac {
> > > > > > > > > + phy-supply = <®_gmac_3v3>;
> > > > > > > > > +};
> > > > > > > >
> > > > > > > > I might be missing some context here, but I'm pretty sure that the
> > > > > > > > initial intent of the pine h64 DTS was to support the model A all
> > > > > > > > along.
> > > > > > > >
> > > > > > >
> > > > > > > The regulator changed between modelA and B.
> > > > > > > See this old patchset (supporting modelA) https://patchwork.kernel.org/patch/10539149/ for example.
> > > > > >
> > > > > > I'm not sure what your point is, but mine is that everything about the
> > > > > > model A should be in sun50i-h6-pine-h64.dts.
> > > > > >
> > > > >
> > > > > model A and B are different enough for distinct dtb, (see sub-thread
> > > > > on HDMI difference for an other difference than PHY regulator)
> > > >
> > > > I don't mind having separate DTBs for model A and model B.
> > > >
> > > > > And clearly, the current dtb is for model B.
> > > >
> > > > That DTS was added almost a year before the model B was announced, and
> > > > no commit to that file mention the model B, so it's definitely not
> > > > clear.
> > >
> > > Normal it was added for model A (without any ethernet/HDMI support,
> > > so nothing distinct from model B), and the modelB ethernet/HDMI
> > > support cames after.
> >
> > Changing the board a DT is meant to halfway through the development is
> > definitely not ok.
> >
> > > > > So do you mean that we need to create a new dtb for model B ? (and
> > > > > hack the current back to model A ?)
> > > >
> > > > I'd prefer not to hack anything, but yes
> > > >
> > >
> > > Since model A is not public (only evaluations boards exists), the
> > > probability of a production model A is low and the current dtb is
> > > perfect for model B , could you reconsider this ?
> >
> > I mean, you could buy it, so it's definitely public.
>
> Where ? official pineh64 site speaks only of modelB.
It's not available anymore, but it used to be.
> >
> > Model A also had HDMI, and it doesn't look like there's anything
> > particularly specific with that board.
>
> A subthread just say the opposite, modelA need something more for HDMI
> https://lkml.org/lkml/2019/8/12/394
Right, but that's not in the DT at the moment.
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: Best representation for TDM devices
From: Maxime Ripard @ 2019-08-20 14:06 UTC (permalink / raw)
To: Mark Brown; +Cc: Ali Burak Parım, linux-arm-kernel
In-Reply-To: <20190819154514.GB5563@sirena.co.uk>
[-- Attachment #1.1: Type: text/plain, Size: 1197 bytes --]
On Mon, Aug 19, 2019 at 04:45:14PM +0100, Mark Brown wrote:
> On Mon, Aug 19, 2019 at 10:41:41AM +0200, Maxime Ripard wrote:
> > On Wed, Aug 14, 2019 at 05:02:34PM +0100, Mark Brown wrote:
>
> > > OK, in that case I'd recommend providing them to userspace as a single
> > > four channel stream - keeping everything bundled together as long as
> > > possible to make it easier to keep the processing synced up.
>
> > Ok, that's what I had in mind as well :)
>
> > However, it looks like we can only capture as many channels as the max
> > being exposed by the codec on the link?
>
> > Any attempt at capturing something with 4 channels here using arecord
> > was either reduced to two channels (the amount of channels provided by
> > the adau7002 driver), or just refused by the ALSA core.
>
> > Is there anything that we need to configure / work on to enable this?
>
> I'd expect there's some issue in the capability/constraint matching code
> that needs fixing - that should work but I can totally see it not
> working unless someone goes in and does something to fix it.
Ok, I'll have a look, thanks!
Maxime
--
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: vf610-zii-cfu1: Slow I2C0 down to 100kHz
From: Chris Healy @ 2019-08-20 14:08 UTC (permalink / raw)
To: Andrey Smirnov; +Cc: Fabio Estevam, Shawn Guo, linux-kernel, linux ARM
In-Reply-To: <20190820030804.8892-1-andrew.smirnov@gmail.com>
On Mon, Aug 19, 2019 at 8:08 PM Andrey Smirnov <andrew.smirnov@gmail.com> wrote:
>
> Fiber-optic module attached to the bus is only rated to work at
> 100kHz, so drop the bus frequncy to accomodate that.
>
> Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Chris Healy <cphealy@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/arm/boot/dts/vf610-zii-cfu1.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/vf610-zii-cfu1.dts b/arch/arm/boot/dts/vf610-zii-cfu1.dts
> index ff460a1de85a..28732249cfc0 100644
> --- a/arch/arm/boot/dts/vf610-zii-cfu1.dts
> +++ b/arch/arm/boot/dts/vf610-zii-cfu1.dts
> @@ -207,7 +207,7 @@
> };
>
> &i2c0 {
> - clock-frequency = <400000>;
> + clock-frequency = <100000>;
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_i2c0>;
> status = "okay";
> --
> 2.21.0
>
Reviewed-by: Chris Healy <cphealy@gmail.com>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v2] iommu/arm-smmu: Break insecure users by disabling bypass by default
From: Robin Murphy @ 2019-08-20 14:10 UTC (permalink / raw)
To: Marc Gonzalez, Will Deacon, Jean-Philippe Brucker,
Michael S. Tsirkin
Cc: Joerg Roedel, Will Deacon, Douglas Anderson, Jon Hunter,
Thierry Reding, Linux ARM
In-Reply-To: <ada29112-87c1-e223-aa66-b7871e20a49a@free.fr>
On 20/08/2019 14:55, Marc Gonzalez wrote:
> On 19/08/2019 16:48, Will Deacon wrote:
>
>> If we can get by with extending the iommu-map entries for the masters,
>> that would certainly be the neatest imo. Sounds like it's worth a quick
>> hack, if nothing else.
>
> Tangent: I've been meaning to ask about some iommu-map shenanigan.
>
> My kernel reports:
>
> OF: /soc/pci@1c00000: no iommu-map translation for rid 0x0 on (null)
>
> Errr... "Is that a problem, doctor?"
>
> It's a pr_info() message from of_map_rid() in drivers/of/base.c
> I note that it used to be an error before fb709b5e1cca5
It means your host bridge doesn't have a stream ID. Depending on how the
root complex is wired up to the SMMU that may or may not be technically
accurate, but either way if your host bridge ever starts doing DMA for
itself then you should probably be more concerned with tracking down PCI
SIG's exorcism spec.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/4] iommu/io-pgtable-arm: Rationalise TTBRn handling
From: Robin Murphy @ 2019-08-20 14:17 UTC (permalink / raw)
To: Will Deacon; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <20190820101911.ndwtaf76kn3zplk2@willie-the-truck>
On 20/08/2019 11:19, Will Deacon wrote:
> On Mon, Aug 19, 2019 at 07:19:29PM +0100, Robin Murphy wrote:
>> TTBR1 values have so far been redundant since no users implement any
>> support for split address spaces. Crucially, though, one of the main
>> reasons for wanting to do so is to be able to manage each half entirely
>> independently, e.g. context-switching one set of mappings without
>> disturbing the other. Thus it seems unlikely that tying two tables
>> together in a single io_pgtable_cfg would ever be particularly desirable
>> or useful.
>>
>> Streamline the configs to just a single conceptual TTBR value
>> representing the allocated table. This paves the way for future users to
>> support split address spaces by simply allocating a table and dealing
>> with the detailed TTBRn logistics themselves.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/arm-smmu-v3.c | 2 +-
>> drivers/iommu/arm-smmu.c | 9 ++++-----
>> drivers/iommu/io-pgtable-arm-v7s.c | 16 +++++++---------
>> drivers/iommu/io-pgtable-arm.c | 7 +++----
>> drivers/iommu/ipmmu-vmsa.c | 2 +-
>> drivers/iommu/msm_iommu.c | 4 ++--
>> drivers/iommu/mtk_iommu.c | 4 ++--
>> drivers/iommu/qcom_iommu.c | 3 +--
>> include/linux/io-pgtable.h | 4 ++--
>> 9 files changed, 23 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> index 2a8db896d698..2e50cf49c3c4 100644
>> --- a/drivers/iommu/arm-smmu-v3.c
>> +++ b/drivers/iommu/arm-smmu-v3.c
>> @@ -1722,7 +1722,7 @@ static int arm_smmu_domain_finalise_s1(struct arm_smmu_domain *smmu_domain,
>> }
>>
>> cfg->cd.asid = (u16)asid;
>> - cfg->cd.ttbr = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>> + cfg->cd.ttbr = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
>> cfg->cd.tcr = pgtbl_cfg->arm_lpae_s1_cfg.tcr;
>> cfg->cd.mair = pgtbl_cfg->arm_lpae_s1_cfg.mair;
>> return 0;
>> diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
>> index 184ca41e9de7..19030c4b5904 100644
>> --- a/drivers/iommu/arm-smmu.c
>> +++ b/drivers/iommu/arm-smmu.c
>> @@ -473,13 +473,12 @@ static void arm_smmu_init_context_bank(struct arm_smmu_domain *smmu_domain,
>> /* TTBRs */
>> if (stage1) {
>> if (cfg->fmt == ARM_SMMU_CTX_FMT_AARCH32_S) {
>> - cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr[0];
>> - cb->ttbr[1] = pgtbl_cfg->arm_v7s_cfg.ttbr[1];
>> + cb->ttbr[0] = pgtbl_cfg->arm_v7s_cfg.ttbr;
>> + cb->ttbr[1] = 0;
>> } else {
>> - cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[0];
>> + cb->ttbr[0] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr;
>> cb->ttbr[0] |= FIELD_PREP(TTBRn_ASID, cfg->asid);
>> - cb->ttbr[1] = pgtbl_cfg->arm_lpae_s1_cfg.ttbr[1];
>> - cb->ttbr[1] |= FIELD_PREP(TTBRn_ASID, cfg->asid);
>> + cb->ttbr[1] = FIELD_PREP(TTBRn_ASID, cfg->asid);
>
> Why do you continue to put the ASID in here?
For the same reason we put it there before ;)
Although I guess if TCR.A1 were ever to get flipped accidentally then
we're still cool.
>> diff --git a/drivers/iommu/qcom_iommu.c b/drivers/iommu/qcom_iommu.c
>> index 34bb357b3cfa..de55b6d82ef1 100644
>> --- a/drivers/iommu/qcom_iommu.c
>> +++ b/drivers/iommu/qcom_iommu.c
>> @@ -247,10 +247,9 @@ static int qcom_iommu_init_domain(struct iommu_domain *domain,
>>
>> /* TTBRs */
>> iommu_writeq(ctx, ARM_SMMU_CB_TTBR0,
>> - pgtbl_cfg.arm_lpae_s1_cfg.ttbr[0] |
>> + pgtbl_cfg.arm_lpae_s1_cfg.ttbr |
>> FIELD_PREP(TTBRn_ASID, ctx->asid));
>> iommu_writeq(ctx, ARM_SMMU_CB_TTBR1,
>> - pgtbl_cfg.arm_lpae_s1_cfg.ttbr[1] |
>> FIELD_PREP(TTBRn_ASID, ctx->asid));
>
> Same here.
>
>> diff --git a/include/linux/io-pgtable.h b/include/linux/io-pgtable.h
>> index a6c8aa204733..7a0905d7a006 100644
>> --- a/include/linux/io-pgtable.h
>> +++ b/include/linux/io-pgtable.h
>> @@ -90,7 +90,7 @@ struct io_pgtable_cfg {
>> /* Low-level data specific to the table format */
>> union {
>> struct {
>> - u64 ttbr[2];
>> + u64 ttbr;
>> u64 tcr;
>> u64 mair;
>> } arm_lpae_s1_cfg;
>> @@ -101,7 +101,7 @@ struct io_pgtable_cfg {
>> } arm_lpae_s2_cfg;
>>
>> struct {
>> - u32 ttbr[2];
>> + u32 ttbr;
>
> We could probably do with a comment for these 'ttbr' field now saying that
> they refer to ttbr0 (since the tcr will have EPD1 set).
Yeah, I did wonder whether this might want elaboration, or whether the
commit messages plus the code consuming it made the idea sufficiently
clear - I guess that's my answer...
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] ARM: dts: vf610-zii-cfu1: Slow I2C0 down to 100kHz
From: Marc Gonzalez @ 2019-08-20 14:39 UTC (permalink / raw)
To: Andrey Smirnov, Linux ARM; +Cc: Fabio Estevam, Shawn Guo, LKML, Chris Healy
In-Reply-To: <20190820030804.8892-1-andrew.smirnov@gmail.com>
On 20/08/2019 05:08, Andrey Smirnov wrote:
> Fiber-optic module attached to the bus is only rated to work at
> 100kHz, so drop the bus frequncy to accomodate that.
s/100kHz/100 kHz
s/frequncy/frequency
s/accomodate/accommodate
Regards.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 2/6] dt-bindings: soc: amlogic: clk-measure: Add SM1 compatible
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman
Cc: devicetree, Neil Armstrong, Martin Blumenstingl, linux-kernel,
linux-amlogic, Rob Herring, linux-arm-kernel
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add the Amlogic SM1 Compatible for the clk-measurer IP.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt b/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt
index 6bf6b43f8dd8..3dd563cec794 100644
--- a/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt
+++ b/Documentation/devicetree/bindings/soc/amlogic/clk-measure.txt
@@ -11,6 +11,7 @@ Required properties:
"amlogic,meson8b-clk-measure" for Meson8b SoCs
"amlogic,meson-axg-clk-measure" for AXG SoCs
"amlogic,meson-g12a-clk-measure" for G12a SoCs
+ "amlogic,meson-sm1-clk-measure" for SM1 SoCs
- reg: base address and size of the Clock Measurer register space.
Example:
--
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 related
* [PATCH 4/6] dt-bindings: arm: amlogic: add SM1 bindings
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, devicetree, linux-kernel, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add bindings for the new Amlogic SM1 SoC Family.
It a derivative of the G12A SoC Family with :
- Cortex-A55 core instead of A53
- more power domains
- a neural network co-processor
- a CSI input and image processor
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index 96f66911e3c6..d701e8447363 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -150,4 +150,7 @@ properties:
- const: amlogic,s922x
- const: amlogic,g12b
+ - description: Boards with the Amlogic Meson SM1 S905X3 SoC
+ items:
+ - const: amlogic,sm1
...
--
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 related
* [PATCH 1/6] soc: amlogic: meson-gx-socinfo: Add SM1 and S905X3 IDs
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman
Cc: Neil Armstrong, Martin Blumenstingl, linux-kernel, linux-amlogic,
linux-arm-kernel, Jerome Brunet
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add the SoC IDs for the S905X3 Amlogic SM1 SoC.
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/soc/amlogic/meson-gx-socinfo.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/soc/amlogic/meson-gx-socinfo.c b/drivers/soc/amlogic/meson-gx-socinfo.c
index ff86a75939e8..b9f4c6f4fd03 100644
--- a/drivers/soc/amlogic/meson-gx-socinfo.c
+++ b/drivers/soc/amlogic/meson-gx-socinfo.c
@@ -39,6 +39,7 @@ static const struct meson_gx_soc_id {
{ "TXHD", 0x27 },
{ "G12A", 0x28 },
{ "G12B", 0x29 },
+ { "SM1", 0x2b },
};
static const struct meson_gx_package_id {
@@ -66,6 +67,7 @@ static const struct meson_gx_package_id {
{ "S905X2", 0x28, 0x40, 0xf0 },
{ "S922X", 0x29, 0x40, 0xf0 },
{ "A311D", 0x29, 0x10, 0xf0 },
+ { "S905X3", 0x2b, 0x5, 0xf },
};
static inline unsigned int socinfo_to_major(u32 socinfo)
--
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 related
* [PATCH 0/6] arm64: Add support for Amlogic SM1 SoC Family
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
The new Amlogic SM1 SoC Family is a derivative of the Amlogic G12A
SoC Family, with the following changes :
- Cortex-A55 cores instead of A53
- more power domains, including USB & PCIe
- a neural network co-processor (NNA)
- a CSI input and image processor
- some changes in the audio complex, thus not yet enabled
- new clocks, for NNA, CSI and a clock tree for each CPU Core
This serie does not add support for NNA, CSI, Audio, USB, Display
or DVFS, it only aligns with the current G12A Support.
With this serie, the SEI610 Board has supported :
- Default-boot CPU frequency
- Ethernet
- LEDs
- IR
- GPIO Buttons
- eMMC
- SDCard
- SDIO WiFi
- UART Bluetooth
Audio (HDMI, Embedded HP, MIcs), USB, HDMI, IR Output, & RGB Led
would be supported in following patchsets.
Dependencies:
- g12-common.dtsi from the DVFS patchset at [1]
Changes from rfc at [2]:
- Removed Power domain patches & display/USB support, will resend separately
- Removed applied AO-CEC patches
- Fixed clk-measure IDs
- Collected reviewed-by tags
[1] https://patchwork.kernel.org/cover/11025309/
[2] https://patchwork.kernel.org/cover/11025511/
Neil Armstrong (6):
soc: amlogic: meson-gx-socinfo: Add SM1 and S905X3 IDs
dt-bindings: soc: amlogic: clk-measure: Add SM1 compatible
soc: amlogic: clk-measure: Add support for SM1
dt-bindings: arm: amlogic: add SM1 bindings
dt-bindings: arm: amlogic: add SEI Robotics SEI610 bindings
arm64: dts: add support for SM1 based SEI Robotics SEI610
.../devicetree/bindings/arm/amlogic.yaml | 5 +
.../bindings/soc/amlogic/clk-measure.txt | 1 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-sm1-sei610.dts | 300 ++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 68 ++++
drivers/soc/amlogic/meson-clk-measure.c | 134 ++++++++
drivers/soc/amlogic/meson-gx-socinfo.c | 2 +
7 files changed, 511 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
--
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
* [PATCH 5/6] dt-bindings: arm: amlogic: add SEI Robotics SEI610 bindings
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman
Cc: linux-amlogic, devicetree, linux-kernel, linux-arm-kernel,
Neil Armstrong
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add the compatible for the Amlogic SM1 Based SEI610 board.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index d701e8447363..b48ea1e4913a 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -152,5 +152,7 @@ properties:
- description: Boards with the Amlogic Meson SM1 S905X3 SoC
items:
+ - enum:
+ - seirobotics,sei610
- const: amlogic,sm1
...
--
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 related
* [PATCH 3/6] soc: amlogic: clk-measure: Add support for SM1
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add the clk-measurer clocks IDs for the Amlogic SM1 SoC family.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
drivers/soc/amlogic/meson-clk-measure.c | 134 ++++++++++++++++++++++++
1 file changed, 134 insertions(+)
diff --git a/drivers/soc/amlogic/meson-clk-measure.c b/drivers/soc/amlogic/meson-clk-measure.c
index f09b404b39d3..0fa47d77577d 100644
--- a/drivers/soc/amlogic/meson-clk-measure.c
+++ b/drivers/soc/amlogic/meson-clk-measure.c
@@ -357,6 +357,136 @@ static struct meson_msr_id clk_msr_g12a[CLK_MSR_MAX] = {
CLK_MSR_ID(122, "audio_pdm_dclk"),
};
+static struct meson_msr_id clk_msr_sm1[CLK_MSR_MAX] = {
+ CLK_MSR_ID(0, "ring_osc_out_ee_0"),
+ CLK_MSR_ID(1, "ring_osc_out_ee_1"),
+ CLK_MSR_ID(2, "ring_osc_out_ee_2"),
+ CLK_MSR_ID(3, "ring_osc_out_ee_3"),
+ CLK_MSR_ID(4, "gp0_pll"),
+ CLK_MSR_ID(5, "gp1_pll"),
+ CLK_MSR_ID(6, "enci"),
+ CLK_MSR_ID(7, "clk81"),
+ CLK_MSR_ID(8, "encp"),
+ CLK_MSR_ID(9, "encl"),
+ CLK_MSR_ID(10, "vdac"),
+ CLK_MSR_ID(11, "eth_tx"),
+ CLK_MSR_ID(12, "hifi_pll"),
+ CLK_MSR_ID(13, "mod_tcon"),
+ CLK_MSR_ID(14, "fec_0"),
+ CLK_MSR_ID(15, "fec_1"),
+ CLK_MSR_ID(16, "fec_2"),
+ CLK_MSR_ID(17, "sys_pll_div16"),
+ CLK_MSR_ID(18, "sys_cpu_div16"),
+ CLK_MSR_ID(19, "lcd_an_ph2"),
+ CLK_MSR_ID(20, "rtc_osc_out"),
+ CLK_MSR_ID(21, "lcd_an_ph3"),
+ CLK_MSR_ID(22, "eth_phy_ref"),
+ CLK_MSR_ID(23, "mpll_50m"),
+ CLK_MSR_ID(24, "eth_125m"),
+ CLK_MSR_ID(25, "eth_rmii"),
+ CLK_MSR_ID(26, "sc_int"),
+ CLK_MSR_ID(27, "in_mac"),
+ CLK_MSR_ID(28, "sar_adc"),
+ CLK_MSR_ID(29, "pcie_inp"),
+ CLK_MSR_ID(30, "pcie_inn"),
+ CLK_MSR_ID(31, "mpll_test_out"),
+ CLK_MSR_ID(32, "vdec"),
+ CLK_MSR_ID(34, "eth_mpll_50m"),
+ CLK_MSR_ID(35, "mali"),
+ CLK_MSR_ID(36, "hdmi_tx_pixel"),
+ CLK_MSR_ID(37, "cdac"),
+ CLK_MSR_ID(38, "vdin_meas"),
+ CLK_MSR_ID(39, "bt656"),
+ CLK_MSR_ID(40, "arm_ring_osc_out_4"),
+ CLK_MSR_ID(41, "eth_rx_or_rmii"),
+ CLK_MSR_ID(42, "mp0_out"),
+ CLK_MSR_ID(43, "fclk_div5"),
+ CLK_MSR_ID(44, "pwm_b"),
+ CLK_MSR_ID(45, "pwm_a"),
+ CLK_MSR_ID(46, "vpu"),
+ CLK_MSR_ID(47, "ddr_dpll_pt"),
+ CLK_MSR_ID(48, "mp1_out"),
+ CLK_MSR_ID(49, "mp2_out"),
+ CLK_MSR_ID(50, "mp3_out"),
+ CLK_MSR_ID(51, "sd_emmc_c"),
+ CLK_MSR_ID(52, "sd_emmc_b"),
+ CLK_MSR_ID(53, "sd_emmc_a"),
+ CLK_MSR_ID(54, "vpu_clkc"),
+ CLK_MSR_ID(55, "vid_pll_div_out"),
+ CLK_MSR_ID(56, "wave420l_a"),
+ CLK_MSR_ID(57, "wave420l_c"),
+ CLK_MSR_ID(58, "wave420l_b"),
+ CLK_MSR_ID(59, "hcodec"),
+ CLK_MSR_ID(60, "arm_ring_osc_out_5"),
+ CLK_MSR_ID(61, "gpio_msr"),
+ CLK_MSR_ID(62, "hevcb"),
+ CLK_MSR_ID(63, "dsi_meas"),
+ CLK_MSR_ID(64, "spicc_1"),
+ CLK_MSR_ID(65, "spicc_0"),
+ CLK_MSR_ID(66, "vid_lock"),
+ CLK_MSR_ID(67, "dsi_phy"),
+ CLK_MSR_ID(68, "hdcp22_esm"),
+ CLK_MSR_ID(69, "hdcp22_skp"),
+ CLK_MSR_ID(70, "pwm_f"),
+ CLK_MSR_ID(71, "pwm_e"),
+ CLK_MSR_ID(72, "pwm_d"),
+ CLK_MSR_ID(73, "pwm_c"),
+ CLK_MSR_ID(74, "arm_ring_osc_out_6"),
+ CLK_MSR_ID(75, "hevcf"),
+ CLK_MSR_ID(76, "arm_ring_osc_out_7"),
+ CLK_MSR_ID(77, "rng_ring_osc_0"),
+ CLK_MSR_ID(78, "rng_ring_osc_1"),
+ CLK_MSR_ID(79, "rng_ring_osc_2"),
+ CLK_MSR_ID(80, "rng_ring_osc_3"),
+ CLK_MSR_ID(81, "vapb"),
+ CLK_MSR_ID(82, "ge2d"),
+ CLK_MSR_ID(83, "co_rx"),
+ CLK_MSR_ID(84, "co_tx"),
+ CLK_MSR_ID(85, "arm_ring_osc_out_8"),
+ CLK_MSR_ID(86, "arm_ring_osc_out_9"),
+ CLK_MSR_ID(87, "mipi_dsi_phy"),
+ CLK_MSR_ID(88, "cis2_adapt"),
+ CLK_MSR_ID(89, "hdmi_todig"),
+ CLK_MSR_ID(90, "hdmitx_sys"),
+ CLK_MSR_ID(91, "nna_core"),
+ CLK_MSR_ID(92, "nna_axi"),
+ CLK_MSR_ID(93, "vad"),
+ CLK_MSR_ID(94, "eth_phy_rx"),
+ CLK_MSR_ID(95, "eth_phy_pll"),
+ CLK_MSR_ID(96, "vpu_b"),
+ CLK_MSR_ID(97, "cpu_b_tmp"),
+ CLK_MSR_ID(98, "ts"),
+ CLK_MSR_ID(99, "arm_ring_osc_out_10"),
+ CLK_MSR_ID(100, "arm_ring_osc_out_11"),
+ CLK_MSR_ID(101, "arm_ring_osc_out_12"),
+ CLK_MSR_ID(102, "arm_ring_osc_out_13"),
+ CLK_MSR_ID(103, "arm_ring_osc_out_14"),
+ CLK_MSR_ID(104, "arm_ring_osc_out_15"),
+ CLK_MSR_ID(105, "arm_ring_osc_out_16"),
+ CLK_MSR_ID(106, "ephy_test"),
+ CLK_MSR_ID(107, "au_dac_g128x"),
+ CLK_MSR_ID(108, "audio_locker_out"),
+ CLK_MSR_ID(109, "audio_locker_in"),
+ CLK_MSR_ID(110, "audio_tdmout_c_sclk"),
+ CLK_MSR_ID(111, "audio_tdmout_b_sclk"),
+ CLK_MSR_ID(112, "audio_tdmout_a_sclk"),
+ CLK_MSR_ID(113, "audio_tdmin_lb_sclk"),
+ CLK_MSR_ID(114, "audio_tdmin_c_sclk"),
+ CLK_MSR_ID(115, "audio_tdmin_b_sclk"),
+ CLK_MSR_ID(116, "audio_tdmin_a_sclk"),
+ CLK_MSR_ID(117, "audio_resample"),
+ CLK_MSR_ID(118, "audio_pdm_sys"),
+ CLK_MSR_ID(119, "audio_spdifout_b"),
+ CLK_MSR_ID(120, "audio_spdifout"),
+ CLK_MSR_ID(121, "audio_spdifin"),
+ CLK_MSR_ID(122, "audio_pdm_dclk"),
+ CLK_MSR_ID(123, "audio_resampled"),
+ CLK_MSR_ID(124, "earcrx_pll"),
+ CLK_MSR_ID(125, "earcrx_pll_test"),
+ CLK_MSR_ID(126, "csi_phy0"),
+ CLK_MSR_ID(127, "csi2_data"),
+};
+
static int meson_measure_id(struct meson_msr_id *clk_msr_id,
unsigned int duration)
{
@@ -545,6 +675,10 @@ static const struct of_device_id meson_msr_match_table[] = {
.compatible = "amlogic,meson-g12a-clk-measure",
.data = (void *)clk_msr_g12a,
},
+ {
+ .compatible = "amlogic,meson-sm1-clk-measure",
+ .data = (void *)clk_msr_sm1,
+ },
{ /* sentinel */ }
};
--
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 related
* [PATCH 6/6] arm64: dts: add support for SM1 based SEI Robotics SEI610
From: Neil Armstrong @ 2019-08-20 14:40 UTC (permalink / raw)
To: khilman; +Cc: linux-amlogic, linux-kernel, linux-arm-kernel, Neil Armstrong
In-Reply-To: <20190820144052.18269-1-narmstrong@baylibre.com>
Add support for the Amlogic SM1 Based SEI610 board.
The SM1 SoC is a derivative of the G12A SoC Family with :
- Cortex-A55 core instead of A53
- more power domains, including USB & PCIe
- a neural network co-processor (NNA)
- a CSI input and image processor
- some changes in the audio complex, thus not yet enabled
The SEI610 board is a derivative of the SEI510 board with :
- removed ADC based touch button, replaced with 3x GPIO buttons
- physical switch disabling on-board MICs
- USB-C port for USB 2.0 OTG
- On-board FTDI USB2SERIAL port for Linux console
Audio, Display and USB support will be added later when support of the
corresponding power domains will be added, for now they are kept disabled.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-sm1-sei610.dts | 300 ++++++++++++++++++
arch/arm64/boot/dts/amlogic/meson-sm1.dtsi | 68 ++++
3 files changed, 369 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
create mode 100644 arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index ae5e8d0c08da..edbf128e7707 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -34,3 +34,4 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q200.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-q201.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-rbox-pro.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-sm1-sei610.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
new file mode 100644
index 000000000000..12dab0ba2f26
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1-sei610.dts
@@ -0,0 +1,300 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre SAS. All rights reserved.
+ */
+
+/dts-v1/;
+
+#include "meson-sm1.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/meson-g12a-gpio.h>
+
+/ {
+ compatible = "seirobotics,sei610", "amlogic,sm1";
+ model = "SEI Robotics SEI610";
+
+ aliases {
+ serial0 = &uart_AO;
+ ethernet0 = ðmac;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio BOOT_12 GPIO_ACTIVE_LOW>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ key1 {
+ label = "A";
+ linux,code = <BTN_0>;
+ gpios = <&gpio GPIOH_6 GPIO_ACTIVE_LOW>;
+ };
+
+ key2 {
+ label = "B";
+ linux,code = <BTN_1>;
+ gpios = <&gpio GPIOH_7 GPIO_ACTIVE_LOW>;
+ };
+
+ key3 {
+ label = "C";
+ linux,code = <BTN_2>;
+ gpios = <&gpio_ao GPIOAO_2 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ bluetooth {
+ label = "sei610:blue:bt";
+ gpios = <&gpio GPIOC_7 (GPIO_ACTIVE_LOW | GPIO_OPEN_DRAIN)>;
+ default-state = "off";
+ };
+ };
+
+ pwmleds {
+ compatible = "pwm-leds";
+
+ power {
+ label = "sei610:red:power";
+ pwms = <&pwm_AO_ab 0 30518 0>;
+ max-brightness = <255>;
+ linux,default-trigger = "default-on";
+ active-low;
+ };
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x40000000>;
+ };
+
+ ao_5v: regulator-ao_5v {
+ compatible = "regulator-fixed";
+ regulator-name = "AO_5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&dc_in>;
+ regulator-always-on;
+ };
+
+ dc_in: regulator-dc_in {
+ compatible = "regulator-fixed";
+ regulator-name = "DC_IN";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ emmc_1v8: regulator-emmc_1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "EMMC_1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ vddao_3v3: regulator-vddao_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&dc_in>;
+ regulator-always-on;
+ };
+
+ /* Used by Tuner, RGB Led & IR Emitter LED array */
+ vddao_3v3_t: regultor-vddao_3v3_t {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3_T";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vddao_3v3>;
+ gpio = <&gpio GPIOH_8 GPIO_OPEN_DRAIN>;
+ enable-active-low;
+ regulator-always-on;
+ };
+
+ vddio_ao1v8: regulator-vddio_ao1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ reserved-memory {
+ /* TEE Reserved Memory */
+ bl32_reserved: bl32@5000000 {
+ reg = <0x0 0x05300000 0x0 0x2000000>;
+ no-map;
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&wifi32k>;
+ clock-names = "ext_clock";
+ };
+
+ wifi32k: wifi32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+};
+
+&cec_AO {
+ pinctrl-0 = <&cec_ao_a_h_pins>;
+ pinctrl-names = "default";
+ status = "disabled";
+ hdmi-phandle = <&hdmi_tx>;
+};
+
+&cecb_AO {
+ pinctrl-0 = <&cec_ao_b_h_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+ hdmi-phandle = <&hdmi_tx>;
+};
+
+ðmac {
+ status = "okay";
+ phy-handle = <&internal_ephy>;
+ phy-mode = "rmii";
+};
+
+&i2c3 {
+ status = "okay";
+ pinctrl-0 = <&i2c3_sda_a_pins>, <&i2c3_sck_a_pins>;
+ pinctrl-names = "default";
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_input_ao_pins>;
+ pinctrl-names = "default";
+};
+
+&pwm_AO_ab {
+ status = "okay";
+ pinctrl-0 = <&pwm_ao_a_pins>;
+ pinctrl-names = "default";
+ clocks = <&xtal>;
+ clock-names = "clkin0";
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins>;
+ pinctrl-names = "default";
+ clocks = <&xtal>;
+ clock-names = "clkin0";
+};
+
+&saradc {
+ status = "okay";
+ vref-supply = <&vddio_ao1v8>;
+};
+
+/* SDIO */
+&sd_emmc_a {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ max-frequency = <100000000>;
+
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&sdio_pwrseq>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+
+ brcmf: wifi@1 {
+ reg = <1>;
+ compatible = "brcm,bcm4329-fmac";
+ };
+};
+
+/* SD card */
+&sd_emmc_b {
+ status = "okay";
+ pinctrl-0 = <&sdcard_c_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_c_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <50000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddao_3v3>;
+};
+
+/* eMMC */
+&sd_emmc_c {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&emmc_1v8>;
+};
+
+&uart_A {
+ status = "okay";
+ pinctrl-0 = <&uart_a_pins>, <&uart_a_cts_rts_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+
+ bluetooth {
+ compatible = "brcm,bcm43438-bt";
+ shutdown-gpios = <&gpio GPIOX_17 GPIO_ACTIVE_HIGH>;
+ max-speed = <2000000>;
+ clocks = <&wifi32k>;
+ clock-names = "lpo";
+ vbat-supply = <&vddao_3v3>;
+ vddio-supply = <&vddio_ao1v8>;
+ };
+};
+
+/* Exposed via the on-board USB to Serial FT232RL IC */
+&uart_AO {
+ status = "okay";
+ pinctrl-0 = <&uart_ao_a_pins>;
+ pinctrl-names = "default";
+};
diff --git a/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
new file mode 100644
index 000000000000..e902d4f9165f
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-sm1.dtsi
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2019 BayLibre, SAS
+ * Author: Neil Armstrong <narmstrong@baylibre.com>
+ */
+
+#include "meson-g12-common.dtsi"
+
+/ {
+ compatible = "amlogic,sm1";
+
+ cpus {
+ #address-cells = <0x2>;
+ #size-cells = <0x0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu2: cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x2>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu3: cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x3>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache0 {
+ compatible = "cache";
+ };
+ };
+};
+
+&cecb_AO {
+ compatible = "amlogic,meson-sm1-ao-cec";
+};
+
+&clk_msr {
+ compatible = "amlogic,meson-sm1-clk-measure";
+};
+
+&pwrc_vpu {
+ status = "disabled";
+};
+
+&vpu {
+ status = "disabled";
+};
--
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 related
* Re: [PATCH 4/4] iommu/io-pgtable-arm: Prepare for TTBR1 usage
From: Robin Murphy @ 2019-08-20 14:51 UTC (permalink / raw)
To: Will Deacon; +Cc: robdclark, joro, jcrouse, iommu, linux-arm-kernel
In-Reply-To: <20190820103048.xacfbtn5o4wermhi@willie-the-truck>
On 20/08/2019 11:30, Will Deacon wrote:
> On Mon, Aug 19, 2019 at 07:19:31PM +0100, Robin Murphy wrote:
>> Now that callers are free to use a given table for TTBR1 if they wish
>> (all they need do is shift the provided attributes when constructing
>> their final TCR value), the only remaining impediment is the address
>> validation on map/unmap. The fact that the LPAE address space split is
>> symmetric makes this easy to accommodate - by simplifying the current
>> range checks into explicit tests that address bits above IAS are all
>> zero, it then follows straightforwardly to add the inverse test to
>> allow the all-ones case as well.
>>
>> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
>> ---
>> drivers/iommu/io-pgtable-arm.c | 7 ++++---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
>> index 09cb20671fbb..f39c50356351 100644
>> --- a/drivers/iommu/io-pgtable-arm.c
>> +++ b/drivers/iommu/io-pgtable-arm.c
>> @@ -475,13 +475,13 @@ static int arm_lpae_map(struct io_pgtable_ops *ops, unsigned long iova,
>> arm_lpae_iopte *ptep = data->pgd;
>> int ret, lvl = ARM_LPAE_START_LVL(data);
>> arm_lpae_iopte prot;
>> + long iaext = (long)iova >> data->iop.cfg.ias;
>>
>> /* If no access, then nothing to do */
>> if (!(iommu_prot & (IOMMU_READ | IOMMU_WRITE)))
>> return 0;
>>
>> - if (WARN_ON(iova >= (1ULL << data->iop.cfg.ias) ||
>> - paddr >= (1ULL << data->iop.cfg.oas)))
>> + if (WARN_ON((iaext && ~iaext) || paddr >> data->iop.cfg.oas))
>
> I had to read that '&&' twice, but I see what you're doing now :)
>
>> return -ERANGE;
>
> This doesn't seem sufficient to prevent a mixture of TTBR1 and TTBR0
> addresses from being mapped in the same TTBR. Perhaps we need a quirk for
> TTBR1, which could then take care of setting EPDx appropriately?
Right, that's the one downside of going for the minimalist "io-pgtable
doesn't even have to know" approach. On reflection, though, in that
paradigm it should probably be the caller's responsibility to convert
TTBR1 addresses to preserve the "as if TTBR0" illusion anyway :/
The advantage of not having a quirk is that it allows split address
spaces to fit more closely with the aux_domain idea, i.e. we could
allocate and initialise a domain without having to assume, or even care,
whether it will end up attached as a primary or aux domain. It *might*
even be potentially useful to have a domain attached to TTBR0 of one
device's context and TTBR1 of another's at the same time, although
that's pretty niche.
Robin.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH 0/6] Add ethernet support for Orange Pi 3
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
From: Ondrej Jirman <megous@megous.com>
This series implements ethernet support for Xunlong Orange Pi 3 board, by:
- making small cleanups of existing dwmac-sun8i code
- adding DT bindings docummentation
- adding support for phy-io-supply to dwmac-sun8i code
- adding DT configuration for Orange Pi 3 board
For some people, ethernet doesn't work after reboot because u-boot doesn't
support AXP805 PMIC, and will not turn off the etherent PHY regulators.
So the regulator controlled by gpio will be shut down, but the other one
controlled by the AXP PMIC will not.
This is a problem only when running with a builtin driver. This needs
to be fixed in u-boot and should not prevent these patches from being
merged.
This evolved out of the Orange Pi 3 patches series, as I didn't want
to stretch that out any longer.
Please take a look.
thank you and regards,
Ondrej Jirman
Ondrej Jirman (6):
dt-bindings: net: sun8i-a83t-emac: Add phy-supply property
dt-bindings: net: sun8i-a83t-emac: Add phy-io-supply property
net: stmmac: sun8i: Use devm_regulator_get for PHY regulator
net: stmmac: sun8i: Rename PHY regulator variable to regulator_phy
net: stmmac: sun8i: Add support for enabling a regulator for PHY I/O
pins
arm64: dts: allwinner: orange-pi-3: Enable ethernet
.../net/allwinner,sun8i-a83t-emac.yaml | 8 ++
.../dts/allwinner/sun50i-h6-orangepi-3.dts | 40 ++++++++++
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 74 ++++++++++++-------
3 files changed, 96 insertions(+), 26 deletions(-)
--
2.22.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 2/6] dt-bindings: net: sun8i-a83t-emac: Add phy-io-supply property
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Some PHYs require separate power supply for I/O pins in some modes
of operation. Add phy-io-supply property, to allow enabling this
power supply.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 304f244e9ab5..782e202aa124 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -47,6 +47,10 @@ properties:
description:
PHY regulator
+ phy-io-supply:
+ description:
+ PHY I/O pins regulator
+
required:
- compatible
- reg
--
2.22.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 1/6] dt-bindings: net: sun8i-a83t-emac: Add phy-supply property
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
This is already supported by the driver, but is missing from the
bindings.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
index 3fb0714e761e..304f244e9ab5 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
+++ b/Documentation/devicetree/bindings/net/allwinner,sun8i-a83t-emac.yaml
@@ -43,6 +43,10 @@ properties:
Phandle to the device containing the EMAC or GMAC clock
register
+ phy-supply:
+ description:
+ PHY regulator
+
required:
- compatible
- reg
--
2.22.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 4/6] net: stmmac: sun8i: Rename PHY regulator variable to regulator_phy
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
We'll be adding further optional regulators, and this makes it clearer
what the regulator is for.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 32 ++++++++++---------
1 file changed, 17 insertions(+), 15 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 3e951a11aec3..e7df30d3cab1 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -57,19 +57,21 @@ struct emac_variant {
};
/* struct sunxi_priv_data - hold all sunxi private data
- * @tx_clk: reference to MAC TX clock
- * @ephy_clk: reference to the optional EPHY clock for the internal PHY
- * @regulator: reference to the optional regulator
- * @rst_ephy: reference to the optional EPHY reset for the internal PHY
- * @variant: reference to the current board variant
- * @regmap: regmap for using the syscon
- * @internal_phy_powered: Does the internal PHY is enabled
- * @mux_handle: Internal pointer used by mdio-mux lib
+ * @tx_clk: reference to MAC TX clock
+ * @ephy_clk: reference to the optional EPHY clock for
+ * the internal PHY
+ * @regulator_phy: reference to the optional regulator
+ * @rst_ephy: reference to the optional EPHY reset for
+ * the internal PHY
+ * @variant: reference to the current board variant
+ * @regmap: regmap for using the syscon
+ * @internal_phy_powered: Does the internal PHY is enabled
+ * @mux_handle: Internal pointer used by mdio-mux lib
*/
struct sunxi_priv_data {
struct clk *tx_clk;
struct clk *ephy_clk;
- struct regulator *regulator;
+ struct regulator *regulator_phy;
struct reset_control *rst_ephy;
const struct emac_variant *variant;
struct regmap_field *regmap_field;
@@ -528,9 +530,9 @@ static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
struct sunxi_priv_data *gmac = priv;
int ret;
- ret = regulator_enable(gmac->regulator);
+ ret = regulator_enable(gmac->regulator_phy);
if (ret) {
- dev_err(&pdev->dev, "Fail to enable regulator\n");
+ dev_err(&pdev->dev, "Fail to enable PHY regulator\n");
return ret;
}
@@ -990,7 +992,7 @@ static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
clk_disable_unprepare(gmac->tx_clk);
- regulator_disable(gmac->regulator);
+ regulator_disable(gmac->regulator_phy);
}
static void sun8i_dwmac_set_mac_loopback(void __iomem *ioaddr, bool enable)
@@ -1126,9 +1128,9 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
}
/* Optional regulator for PHY */
- gmac->regulator = devm_regulator_get(dev, "phy");
- if (IS_ERR(gmac->regulator)) {
- ret = PTR_ERR(gmac->regulator);
+ gmac->regulator_phy = devm_regulator_get(dev, "phy");
+ if (IS_ERR(gmac->regulator_phy)) {
+ ret = PTR_ERR(gmac->regulator_phy);
if (ret != -EPROBE_DEFER)
dev_err(dev, "Failed to get PHY regulator (%d)\n", ret);
return ret;
--
2.22.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 3/6] net: stmmac: sun8i: Use devm_regulator_get for PHY regulator
From: megous @ 2019-08-20 14:53 UTC (permalink / raw)
To: David S. Miller, Rob Herring, Mark Rutland, Maxime Ripard,
Chen-Yu Tsai, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin
Cc: Ondrej Jirman, devicetree, netdev, linux-kernel, linux-stm32,
linux-arm-kernel
In-Reply-To: <20190820145343.29108-1-megous@megous.com>
From: Ondrej Jirman <megous@megous.com>
Use devm_regulator_get instead of devm_regulator_get_optional and rely
on dummy supply. This avoids NULL checks before regulator_enable/disable
calls.
This path also improves error reporting, because we now report both
use of dummy supply and error during registration with more detail,
instead of generic info level message "No regulator found" that
was reported previously on errors and lack of regulator property in DT.
Finally, we'll be adding further optional regulators, and the overall
code will be simpler.
Signed-off-by: Ondrej Jirman <megous@megous.com>
---
.../net/ethernet/stmicro/stmmac/dwmac-sun8i.c | 23 ++++++++-----------
1 file changed, 10 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
index 4083019c547a..3e951a11aec3 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c
@@ -528,12 +528,10 @@ static int sun8i_dwmac_init(struct platform_device *pdev, void *priv)
struct sunxi_priv_data *gmac = priv;
int ret;
- if (gmac->regulator) {
- ret = regulator_enable(gmac->regulator);
- if (ret) {
- dev_err(&pdev->dev, "Fail to enable regulator\n");
- return ret;
- }
+ ret = regulator_enable(gmac->regulator);
+ if (ret) {
+ dev_err(&pdev->dev, "Fail to enable regulator\n");
+ return ret;
}
ret = clk_prepare_enable(gmac->tx_clk);
@@ -992,8 +990,7 @@ static void sun8i_dwmac_exit(struct platform_device *pdev, void *priv)
clk_disable_unprepare(gmac->tx_clk);
- if (gmac->regulator)
- regulator_disable(gmac->regulator);
+ regulator_disable(gmac->regulator);
}
static void sun8i_dwmac_set_mac_loopback(void __iomem *ioaddr, bool enable)
@@ -1129,12 +1126,12 @@ static int sun8i_dwmac_probe(struct platform_device *pdev)
}
/* Optional regulator for PHY */
- gmac->regulator = devm_regulator_get_optional(dev, "phy");
+ gmac->regulator = devm_regulator_get(dev, "phy");
if (IS_ERR(gmac->regulator)) {
- if (PTR_ERR(gmac->regulator) == -EPROBE_DEFER)
- return -EPROBE_DEFER;
- dev_info(dev, "No regulator found\n");
- gmac->regulator = NULL;
+ ret = PTR_ERR(gmac->regulator);
+ if (ret != -EPROBE_DEFER)
+ dev_err(dev, "Failed to get PHY regulator (%d)\n", ret);
+ return ret;
}
/* The "GMAC clock control" register might be located in the
--
2.22.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
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