* [PATCH v2 1/3] ipmi: add an Aspeed BT IPMI BMC driver
From: Cédric Le Goater @ 2016-09-19 8:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <08e9b30f-6c35-8418-a8b0-0b63639dd36d@acm.org>
On 09/16/2016 09:41 PM, Corey Minyard wrote:
> On 09/16/2016 05:39 AM, C?dric Le Goater wrote:
>> From: Alistair Popple <alistair@popple.id.au>
>>
>> This patch adds a simple device driver to expose the iBT interface on
>> Aspeed SOCs (AST2400 and AST2500) as a character device. Such SOCs are
>> commonly used as BMCs (BaseBoard Management Controllers) and this
>> driver implements the BMC side of the BT interface.
>>
>> The BT (Block Transfer) interface is used to perform in-band IPMI
>> communication between a host and its BMC. Entire messages are buffered
>> before sending a notification to the other end, host or BMC, that
>> there is data to be read. Usually, the host emits requests and the BMC
>> responses but the specification provides a mean for the BMC to send
>> SMS Attention (BMC-to-Host attention or System Management Software
>> attention) messages.
>>
>> For this purpose, the driver introduces a specific ioctl on the
>> device: 'BT_BMC_IOCTL_SMS_ATN' that can be used by the system running
>> on the BMC to signal the host of such an event.
>>
>> The device name defaults to '/dev/ipmi-bt-host'
>
> Others have reviewed this for style and such, and I have looked
> at it from a protocol point of view. it looks to be sound for the
> most part. I have some higher level concerns:
>
> There appears to be no handling for multiple simultaneous users.
> This interface can only be used by one task at a time, so you should
> probably only allow one opener. Well, I guess the BMC could be split
> into a reader and a writer task, so I'm not really sure about that, but
> I would think in most situations having more than one opener is a
> bug. You do call clr_b_busy() on open, for instance, which might be
> an issue for multiple openers. Maybe a module parameter for
> maximum number of openers? Just want to make sure this was
> thought about, at least.
yes but not implemented ... The open_count in the bt_bmc structure
is unused. In v3, I will replace it with a global atomic_t tracked
in the open and release operations.
> There is also no mutex protecting reading or writing. If multiple
> threads call read or write at the same time, it probably wouldn't
> work correctly. I think you need a read and a write mutex on the
> interface to protect against this.
yes. I will add a mutex also in v3.
> The spec says:
>
> The BMC must not return a given response once the corresponding
> Request-to-Response interval has passed. The BMC can ensure this
> by maintaining its own internal list of outstanding requests through
> the interface. The BMC could age and expire the entries in the list
> by expiring the entries at an interval that is somewhat shorter than
> the specified Request-to-Response interval....
This is clearly not handled in the driver.
For this purpose, we could maintain a request expiry list using the seq
field of the BT message. Update the list in the read and write operations
and arm a timer to garbage collect any left overs. As for the errno in
the write when a response had timeout'ed, may be ETIMEDOUT ?
For configuration of the maximum response time, a sysfs file would do
I think.
Do you want that in v3 also ? I have some experimental patches for it,
that I can send as follow ups.
Thanks,
C.
> On the write side, though, there doesn't seem to be a way to handle a
> situation where the host side doesn't respond for a while and the
> pending message would need to be discarded.
>
> The spec doesn't mention much about error recovery on this interface,
> but the way this is written should be fine, I think.
>
> I'm copying Rocky Craig, who wrote the host side driver for Linux, in
> case he wants to comment on this.
>
> This is easy to read and understand, so I think v3 should be good.
>
> Thanks,
>
> -corey
>
>> Signed-off-by: Alistair Popple <alistair@popple.id.au>
>> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
>> Signed-off-by: Joel Stanley <joel@jms.id.au>
>> [clg: - checkpatch fixes
>> - added a devicetree binding documentation
>> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
>> the BMC side of the IPMI BT interface
>> - renamed the device to 'ipmi-bt-host'
>> - introduced a temporary buffer to copy_{to,from}_user
>> - used platform_get_irq()
>> - moved the driver under drivers/char/ipmi/ but kept it as a misc
>> device
>> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>> ]
>> Signed-off-by: C?dric Le Goater <clg@kaod.org>
>> ---
>>
>> Changes since v1:
>>
>> - replace 'bt_host' by 'bt_bmc' to reflect that the driver is
>> the BMC side of the IPMI BT interface
>> - renamed the device to 'ipmi-bt-host'
>> - introduced a temporary buffer to copy_{to,from}_user
>> - used platform_get_irq()
>> - moved the driver under drivers/char/ipmi/ but kept it as a misc
>> device
>> - changed the compatible cell to "aspeed,ast2400-bt-bmc"
>>
>> .../bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt | 23 +
>> drivers/Makefile | 2 +-
>> drivers/char/ipmi/Kconfig | 7 +
>> drivers/char/ipmi/Makefile | 1 +
>> drivers/char/ipmi/bt-bmc.c | 486 +++++++++++++++++++++
>> include/uapi/linux/Kbuild | 1 +
>> include/uapi/linux/bt-bmc.h | 18 +
>> 7 files changed, 537 insertions(+), 1 deletion(-)
>> create mode 100644 Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
>> create mode 100644 drivers/char/ipmi/bt-bmc.c
>> create mode 100644 include/uapi/linux/bt-bmc.h
>>
>> diff --git a/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt b/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
>> new file mode 100644
>> index 000000000000..fbbacd958240
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/char/ipmi/aspeed,ast2400-bt-bmc.txt
>> @@ -0,0 +1,23 @@
>> +* Aspeed BT (Block Transfer) IPMI interface
>> +
>> +The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs
>> +(BaseBoard Management Controllers) and the BT interface can be used to
>> +perform in-band IPMI communication with their host.
>> +
>> +Required properties:
>> +
>> +- compatible : should be "aspeed,ast2400-bt-bmc"
>> +- reg: physical address and size of the registers
>> +
>> +Optional properties:
>> +
>> +- interrupts: interrupt generated by the BT interface. without an
>> + interrupt, the driver will operate in poll mode.
>> +
>> +Example:
>> +
>> + ibt at 1e789140 {
>> + compatible = "aspeed,ast2400-bt-bmc";
>> + reg = <0x1e789140 0x18>;
>> + interrupts = <8>;
>> + };
>> diff --git a/drivers/Makefile b/drivers/Makefile
>> index 53abb4a5f736..5a9e7b6b7928 100644
>> --- a/drivers/Makefile
>> +++ b/drivers/Makefile
>> @@ -21,7 +21,7 @@ obj-y += video/
>> obj-y += idle/
>> # IPMI must come before ACPI in order to provide IPMI opregion support
>> -obj-$(CONFIG_IPMI_HANDLER) += char/ipmi/
>> +obj-y += char/ipmi/
>> obj-$(CONFIG_ACPI) += acpi/
>> obj-$(CONFIG_SFI) += sfi/
>> diff --git a/drivers/char/ipmi/Kconfig b/drivers/char/ipmi/Kconfig
>> index 5a9350b1069a..2c234e3e7513 100644
>> --- a/drivers/char/ipmi/Kconfig
>> +++ b/drivers/char/ipmi/Kconfig
>> @@ -76,3 +76,10 @@ config IPMI_POWEROFF
>> the IPMI management controller is capable of this.
>> endif # IPMI_HANDLER
>> +
>> +config ASPEED_BT_IPMI_BMC
>> + tristate "BT IPMI bmc driver"
>> + help
>> + Provides a driver for the BT (Block Transfer) IPMI interface
>> + found on Aspeed SOCs (AST2400 and AST2500). The driver
>> + implements the BMC side of the BT interface.
>> diff --git a/drivers/char/ipmi/Makefile b/drivers/char/ipmi/Makefile
>> index f3ffde1f5f1f..0d98cd91def1 100644
>> --- a/drivers/char/ipmi/Makefile
>> +++ b/drivers/char/ipmi/Makefile
>> @@ -11,3 +11,4 @@ obj-$(CONFIG_IPMI_SSIF) += ipmi_ssif.o
>> obj-$(CONFIG_IPMI_POWERNV) += ipmi_powernv.o
>> obj-$(CONFIG_IPMI_WATCHDOG) += ipmi_watchdog.o
>> obj-$(CONFIG_IPMI_POWEROFF) += ipmi_poweroff.o
>> +obj-$(CONFIG_ASPEED_BT_IPMI_BMC) += bt-bmc.o
>> diff --git a/drivers/char/ipmi/bt-bmc.c b/drivers/char/ipmi/bt-bmc.c
>> new file mode 100644
>> index 000000000000..b96cb421e1c2
>> --- /dev/null
>> +++ b/drivers/char/ipmi/bt-bmc.c
>> @@ -0,0 +1,486 @@
>> +/*
>> + * Copyright (c) 2015-2016, IBM Corporation.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version
>> + * 2 of the License, or (at your option) any later version.
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/moduleparam.h>
>> +#include <linux/errno.h>
>> +#include <linux/poll.h>
>> +#include <linux/sched.h>
>> +#include <linux/spinlock.h>
>> +#include <linux/slab.h>
>> +#include <linux/init.h>
>> +#include <linux/device.h>
>> +#include <linux/of.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/platform_device.h>
>> +#include <linux/io.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/delay.h>
>> +#include <linux/miscdevice.h>
>> +#include <linux/timer.h>
>> +#include <linux/jiffies.h>
>> +#include <linux/bt-bmc.h>
>> +
>> +/*
>> + * This is a BMC device used to communicate to the host
>> + */
>> +#define DEVICE_NAME "ipmi-bt-host"
>> +
>> +#define BT_IO_BASE 0xe4
>> +#define BT_IRQ 10
>> +
>> +#define BT_CR0 0x0
>> +#define BT_CR0_IO_BASE 16
>> +#define BT_CR0_IRQ 12
>> +#define BT_CR0_EN_CLR_SLV_RDP 0x8
>> +#define BT_CR0_EN_CLR_SLV_WRP 0x4
>> +#define BT_CR0_ENABLE_IBT 0x1
>> +#define BT_CR1 0x4
>> +#define BT_CR1_IRQ_H2B 0x01
>> +#define BT_CR1_IRQ_HBUSY 0x40
>> +#define BT_CR2 0x8
>> +#define BT_CR2_IRQ_H2B 0x01
>> +#define BT_CR2_IRQ_HBUSY 0x40
>> +#define BT_CR3 0xc
>> +#define BT_CTRL 0x10
>> +#define BT_CTRL_B_BUSY 0x80
>> +#define BT_CTRL_H_BUSY 0x40
>> +#define BT_CTRL_OEM0 0x20
>> +#define BT_CTRL_SMS_ATN 0x10
>> +#define BT_CTRL_B2H_ATN 0x08
>> +#define BT_CTRL_H2B_ATN 0x04
>> +#define BT_CTRL_CLR_RD_PTR 0x02
>> +#define BT_CTRL_CLR_WR_PTR 0x01
>> +#define BT_BMC2HOST 0x14
>> +#define BT_INTMASK 0x18
>> +#define BT_INTMASK_B2H_IRQEN 0x01
>> +#define BT_INTMASK_B2H_IRQ 0x02
>> +#define BT_INTMASK_BMC_HWRST 0x80
>> +
>> +struct bt_bmc {
>> + struct device dev;
>> + struct miscdevice miscdev;
>> + void __iomem *base;
>> + int open_count;
>> + int irq;
>> + wait_queue_head_t queue;
>> + struct timer_list poll_timer;
>> +};
>> +
>> +static u8 bt_inb(struct bt_bmc *bt_bmc, int reg)
>> +{
>> + return ioread8(bt_bmc->base + reg);
>> +}
>> +
>> +static void bt_outb(struct bt_bmc *bt_bmc, u8 data, int reg)
>> +{
>> + iowrite8(data, bt_bmc->base + reg);
>> +}
>> +
>> +static void clr_rd_ptr(struct bt_bmc *bt_bmc)
>> +{
>> + bt_outb(bt_bmc, BT_CTRL_CLR_RD_PTR, BT_CTRL);
>> +}
>> +
>> +static void clr_wr_ptr(struct bt_bmc *bt_bmc)
>> +{
>> + bt_outb(bt_bmc, BT_CTRL_CLR_WR_PTR, BT_CTRL);
>> +}
>> +
>> +static void clr_h2b_atn(struct bt_bmc *bt_bmc)
>> +{
>> + bt_outb(bt_bmc, BT_CTRL_H2B_ATN, BT_CTRL);
>> +}
>> +
>> +static void set_b_busy(struct bt_bmc *bt_bmc)
>> +{
>> + if (!(bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_B_BUSY))
>> + bt_outb(bt_bmc, BT_CTRL_B_BUSY, BT_CTRL);
>> +}
>> +
>> +static void clr_b_busy(struct bt_bmc *bt_bmc)
>> +{
>> + if (bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_B_BUSY)
>> + bt_outb(bt_bmc, BT_CTRL_B_BUSY, BT_CTRL);
>> +}
>> +
>> +static void set_b2h_atn(struct bt_bmc *bt_bmc)
>> +{
>> + bt_outb(bt_bmc, BT_CTRL_B2H_ATN, BT_CTRL);
>> +}
>> +
>> +static u8 bt_read(struct bt_bmc *bt_bmc)
>> +{
>> + return bt_inb(bt_bmc, BT_BMC2HOST);
>> +}
>> +
>> +static ssize_t bt_readn(struct bt_bmc *bt_bmc, u8 *buf, size_t n)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < n; i++)
>> + buf[i] = bt_read(bt_bmc);
>> + return n;
>> +}
>> +
>> +static void bt_write(struct bt_bmc *bt_bmc, u8 c)
>> +{
>> + bt_outb(bt_bmc, c, BT_BMC2HOST);
>> +}
>> +
>> +static ssize_t bt_writen(struct bt_bmc *bt_bmc, u8 *buf, size_t n)
>> +{
>> + int i;
>> +
>> + for (i = 0; i < n; i++)
>> + bt_write(bt_bmc, buf[i]);
>> + return n;
>> +}
>> +
>> +static void set_sms_atn(struct bt_bmc *bt_bmc)
>> +{
>> + bt_outb(bt_bmc, BT_CTRL_SMS_ATN, BT_CTRL);
>> +}
>> +
>> +static struct bt_bmc *file_bt_bmc(struct file *file)
>> +{
>> + return container_of(file->private_data, struct bt_bmc, miscdev);
>> +}
>> +
>> +static int bt_bmc_open(struct inode *inode, struct file *file)
>> +{
>> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
>> +
>> + clr_b_busy(bt_bmc);
>> +
>> + return 0;
>> +}
>> +
>> +#define BT_BMC_BUFFER_SIZE 256
>> +
>> +/*
>> + * The BT (Block Transfer) interface means that entire messages are
>> + * buffered by the host before a notification is sent to the BMC that
>> + * there is data to be read. The first byte is the length and the
>> + * message data follows. The read operation just tries to capture the
>> + * whole before returning it to userspace.
>> + */
>> +static ssize_t bt_bmc_read(struct file *file, char __user *buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
>> + u8 len;
>> + int len_byte = 1;
>> + u8 kbuffer[BT_BMC_BUFFER_SIZE];
>> + ssize_t ret = 0;
>> + ssize_t nread;
>> +
>> + if (!access_ok(VERIFY_WRITE, buf, count))
>> + return -EFAULT;
>> +
>> + WARN_ON(*ppos);
>> +
>> + if (wait_event_interruptible(bt_bmc->queue,
>> + bt_inb(bt_bmc, BT_CTRL) & BT_CTRL_H2B_ATN))
>> + return -ERESTARTSYS;
>> +
>> + set_b_busy(bt_bmc);
>> + clr_h2b_atn(bt_bmc);
>> + clr_rd_ptr(bt_bmc);
>> +
>> + /*
>> + * The BT frames start with the message length, which does not
>> + * include the length byte.
>> + */
>> + kbuffer[0] = bt_read(bt_bmc);
>> + len = kbuffer[0];
>> +
>> + /* We pass the length back to userspace as well */
>> + if (len + 1 > count)
>> + len = count - 1;
>> +
>> + while (len) {
>> + nread = min_t(ssize_t, len, sizeof(kbuffer) - len_byte);
>> +
>> + bt_readn(bt_bmc, kbuffer + len_byte, nread);
>> +
>> + if (copy_to_user(buf, kbuffer, nread + len_byte)) {
>> + ret = -EFAULT;
>> + break;
>> + }
>> + len -= nread;
>> + buf += nread + len_byte;
>> + ret += nread + len_byte;
>> + len_byte = 0;
>> + }
>> +
>> + clr_b_busy(bt_bmc);
>> +
>> + return ret;
>> +}
>> +
>> +static ssize_t bt_bmc_write(struct file *file, const char __user *buf,
>> + size_t count, loff_t *ppos)
>> +{
>> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
>> + u8 kbuffer[BT_BMC_BUFFER_SIZE];
>> + ssize_t ret = 0;
>> + ssize_t nwritten;
>> +
>> + if (!access_ok(VERIFY_READ, buf, count))
>> + return -EFAULT;
>> +
>> + WARN_ON(*ppos);
>> +
>> + /* There's no interrupt for clearing bmc busy so we have to
>> + * poll
>> + */
>> + if (wait_event_interruptible(bt_bmc->queue,
>> + !(bt_inb(bt_bmc, BT_CTRL) &
>> + (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN))))
>> + return -ERESTARTSYS;
>> +
>> + clr_wr_ptr(bt_bmc);
>> +
>> + while (count) {
>> + nwritten = min_t(ssize_t, count, sizeof(kbuffer));
>> + if (copy_from_user(&kbuffer, buf, nwritten)) {
>> + ret = -EFAULT;
>> + break;
>> + }
>> +
>> + bt_writen(bt_bmc, kbuffer, nwritten);
>> +
>> + count -= nwritten;
>> + buf += nwritten;
>> + ret += nwritten;
>> + }
>> +
>> + set_b2h_atn(bt_bmc);
>> +
>> + return ret;
>> +}
>> +
>> +static long bt_bmc_ioctl(struct file *file, unsigned int cmd,
>> + unsigned long param)
>> +{
>> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
>> +
>> + switch (cmd) {
>> + case BT_BMC_IOCTL_SMS_ATN:
>> + set_sms_atn(bt_bmc);
>> + return 0;
>> + }
>> + return -EINVAL;
>> +}
>> +
>> +static int bt_bmc_release(struct inode *inode, struct file *file)
>> +{
>> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
>> +
>> + set_b_busy(bt_bmc);
>> + return 0;
>> +}
>> +
>> +static unsigned int bt_bmc_poll(struct file *file, poll_table *wait)
>> +{
>> + struct bt_bmc *bt_bmc = file_bt_bmc(file);
>> + unsigned int mask = 0;
>> + uint8_t ctrl;
>> +
>> + poll_wait(file, &bt_bmc->queue, wait);
>> +
>> + ctrl = bt_inb(bt_bmc, BT_CTRL);
>> +
>> + if (ctrl & BT_CTRL_H2B_ATN)
>> + mask |= POLLIN;
>> +
>> + if (!(ctrl & (BT_CTRL_H_BUSY | BT_CTRL_B2H_ATN)))
>> + mask |= POLLOUT;
>> +
>> + return mask;
>> +}
>> +
>> +static const struct file_operations bt_bmc_fops = {
>> + .owner = THIS_MODULE,
>> + .open = bt_bmc_open,
>> + .read = bt_bmc_read,
>> + .write = bt_bmc_write,
>> + .release = bt_bmc_release,
>> + .poll = bt_bmc_poll,
>> + .unlocked_ioctl = bt_bmc_ioctl,
>> +};
>> +
>> +static void poll_timer(unsigned long data)
>> +{
>> + struct bt_bmc *bt_bmc = (void *)data;
>> +
>> + bt_bmc->poll_timer.expires += msecs_to_jiffies(500);
>> + wake_up(&bt_bmc->queue);
>> + add_timer(&bt_bmc->poll_timer);
>> +}
>> +
>> +static irqreturn_t bt_bmc_irq(int irq, void *arg)
>> +{
>> + struct bt_bmc *bt_bmc = arg;
>> + uint32_t reg;
>> +
>> + reg = ioread32(bt_bmc->base + BT_CR2);
>> + reg &= BT_CR2_IRQ_H2B | BT_CR2_IRQ_HBUSY;
>> + if (!reg)
>> + return IRQ_NONE;
>> +
>> + /* ack pending IRQs */
>> + iowrite32(reg, bt_bmc->base + BT_CR2);
>> +
>> + wake_up(&bt_bmc->queue);
>> + return IRQ_HANDLED;
>> +}
>> +
>> +static int bt_bmc_config_irq(struct bt_bmc *bt_bmc,
>> + struct platform_device *pdev)
>> +{
>> + struct device *dev = &pdev->dev;
>> + uint32_t reg;
>> + int rc;
>> +
>> + bt_bmc->irq = platform_get_irq(pdev, 0);
>> + if (!bt_bmc->irq)
>> + return -ENODEV;
>> +
>> + rc = devm_request_irq(dev, bt_bmc->irq, bt_bmc_irq, IRQF_SHARED,
>> + DEVICE_NAME, bt_bmc);
>> + if (rc < 0) {
>> + dev_warn(dev, "Unable to request IRQ %d\n", bt_bmc->irq);
>> + bt_bmc->irq = 0;
>> + return rc;
>> + }
>> +
>> + /* Configure IRQs on the bmc clearing the H2B and HBUSY bits;
>> + * H2B will be asserted when the bmc has data for us; HBUSY
>> + * will be cleared (along with B2H) when we can write the next
>> + * message to the BT buffer
>> + */
>> + reg = ioread32(bt_bmc->base + BT_CR1);
>> + reg |= BT_CR1_IRQ_H2B | BT_CR1_IRQ_HBUSY;
>> + iowrite32(reg, bt_bmc->base + BT_CR1);
>> +
>> + return 0;
>> +}
>> +
>> +static int bt_bmc_probe(struct platform_device *pdev)
>> +{
>> + struct bt_bmc *bt_bmc;
>> + struct device *dev;
>> + struct resource *res;
>> + int rc;
>> +
>> + if (!pdev || !pdev->dev.of_node)
>> + return -ENODEV;
>> +
>> + dev = &pdev->dev;
>> + dev_info(dev, "Found bt bmc device\n");
>> +
>> + bt_bmc = devm_kzalloc(dev, sizeof(*bt_bmc), GFP_KERNEL);
>> + if (!bt_bmc)
>> + return -ENOMEM;
>> +
>> + dev_set_drvdata(&pdev->dev, bt_bmc);
>> +
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + if (!res) {
>> + dev_err(dev, "Unable to find resources\n");
>> + rc = -ENXIO;
>> + goto out_free;
>> + }
>> +
>> + bt_bmc->base = devm_ioremap_resource(&pdev->dev, res);
>> + if (!bt_bmc->base) {
>> + rc = -ENOMEM;
>> + goto out_free;
>> + }
>> +
>> + init_waitqueue_head(&bt_bmc->queue);
>> +
>> + bt_bmc->miscdev.minor = MISC_DYNAMIC_MINOR,
>> + bt_bmc->miscdev.name = DEVICE_NAME,
>> + bt_bmc->miscdev.fops = &bt_bmc_fops,
>> + bt_bmc->miscdev.parent = dev;
>> + rc = misc_register(&bt_bmc->miscdev);
>> + if (rc) {
>> + dev_err(dev, "Unable to register device\n");
>> + goto out_unmap;
>> + }
>> +
>> + bt_bmc_config_irq(bt_bmc, pdev);
>> +
>> + if (bt_bmc->irq) {
>> + dev_info(dev, "Using IRQ %d\n", bt_bmc->irq);
>> + } else {
>> + dev_info(dev, "No IRQ; using timer\n");
>> + setup_timer(&bt_bmc->poll_timer, poll_timer,
>> + (unsigned long)bt_bmc);
>> + bt_bmc->poll_timer.expires = jiffies + msecs_to_jiffies(10);
>> + add_timer(&bt_bmc->poll_timer);
>> + }
>> +
>> + iowrite32((BT_IO_BASE << BT_CR0_IO_BASE) |
>> + (BT_IRQ << BT_CR0_IRQ) |
>> + BT_CR0_EN_CLR_SLV_RDP |
>> + BT_CR0_EN_CLR_SLV_WRP |
>> + BT_CR0_ENABLE_IBT,
>> + bt_bmc->base + BT_CR0);
>> +
>> + clr_b_busy(bt_bmc);
>> +
>> + return 0;
>> +
>> +out_unmap:
>> + devm_iounmap(&pdev->dev, bt_bmc->base);
>> +
>> +out_free:
>> + devm_kfree(dev, bt_bmc);
>> + return rc;
>> +
>> +}
>> +
>> +static int bt_bmc_remove(struct platform_device *pdev)
>> +{
>> + struct bt_bmc *bt_bmc = dev_get_drvdata(&pdev->dev);
>> +
>> + misc_deregister(&bt_bmc->miscdev);
>> + if (!bt_bmc->irq)
>> + del_timer_sync(&bt_bmc->poll_timer);
>> + devm_iounmap(&pdev->dev, bt_bmc->base);
>> + devm_kfree(&pdev->dev, bt_bmc);
>> + bt_bmc = NULL;
>> +
>> + return 0;
>> +}
>> +
>> +static const struct of_device_id bt_bmc_match[] = {
>> + { .compatible = "aspeed,ast2400-bt-bmc" },
>> + { },
>> +};
>> +
>> +static struct platform_driver bt_bmc_driver = {
>> + .driver = {
>> + .name = DEVICE_NAME,
>> + .of_match_table = bt_bmc_match,
>> + },
>> + .probe = bt_bmc_probe,
>> + .remove = bt_bmc_remove,
>> +};
>> +
>> +module_platform_driver(bt_bmc_driver);
>> +
>> +MODULE_DEVICE_TABLE(of, bt_bmc_match);
>> +MODULE_LICENSE("GPL");
>> +MODULE_AUTHOR("Alistair Popple <alistair@popple.id.au>");
>> +MODULE_DESCRIPTION("Linux device interface to the BT interface");
>> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
>> index 185f8ea2702f..17b12942c67d 100644
>> --- a/include/uapi/linux/Kbuild
>> +++ b/include/uapi/linux/Kbuild
>> @@ -74,6 +74,7 @@ header-y += bpf_common.h
>> header-y += bpf.h
>> header-y += bpqether.h
>> header-y += bsg.h
>> +header-y += bt-bmc.h
>> header-y += btrfs.h
>> header-y += can.h
>> header-y += capability.h
>> diff --git a/include/uapi/linux/bt-bmc.h b/include/uapi/linux/bt-bmc.h
>> new file mode 100644
>> index 000000000000..d9ec766a63d0
>> --- /dev/null
>> +++ b/include/uapi/linux/bt-bmc.h
>> @@ -0,0 +1,18 @@
>> +/*
>> + * Copyright (c) 2015-2016, IBM Corporation.
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License
>> + * as published by the Free Software Foundation; either version
>> + * 2 of the License, or (at your option) any later version.
>> + */
>> +
>> +#ifndef _UAPI_LINUX_BT_BMC_H
>> +#define _UAPI_LINUX_BT_BMC_H
>> +
>> +#include <linux/ioctl.h>
>> +
>> +#define __BT_BMC_IOCTL_MAGIC 0xb1
>> +#define BT_BMC_IOCTL_SMS_ATN _IO(__BT_BMC_IOCTL_MAGIC, 0x00)
>> +
>> +#endif /* _UAPI_LINUX_BT_BMC_H */
>
>
^ permalink raw reply
* [PATCH RFC 4/8] ARM: shmobile: r8a7743: basic SoC support
From: Geert Uytterhoeven @ 2016-09-19 7:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7093322.WFIWVqz40g@wasted.cogentembedded.com>
Hi Sergei,
On Fri, Sep 16, 2016 at 3:33 PM, Sergei Shtylyov
<sergei.shtylyov@cogentembedded.com> wrote:
> Add minimal support for the RZ/G1M (R8A7743) SoC.
>
> Based on the original (and large) patch by Dmitry Shifrin
> <dmitry.shifrin@cogentembedded.com>.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> --- /dev/null
> +++ renesas/arch/arm/mach-shmobile/setup-r8a7743.c
> @@ -0,0 +1,34 @@
> +static const char * const r8a7743_boards_compat_dt[] __initconst = {
> + "renesas,r8a7743",
To be documented in
Documentation/devicetree/bindings/arm/shmobile.txt.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v3 0/2] KVM: ARM: Enable vtimers with user space gic
From: Andrew Jones @ 2016-09-19 7:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B88B95A5-3631-4AEF-80DC-7762C415A811@suse.de>
On Fri, Sep 16, 2016 at 09:36:42PM +0200, Alexander Graf wrote:
>
>
> > Am 16.09.2016 um 15:46 schrieb Andrew Jones <drjones@redhat.com>:
> >
> >> On Fri, Sep 16, 2016 at 03:30:27PM +0200, Christoffer Dall wrote:
> >>> On Fri, Sep 16, 2016 at 02:31:42PM +0200, Paolo Bonzini wrote:
> >>>
> >>>
> >>> On 16/09/2016 14:30, Christoffer Dall wrote:
> >>>>>>> This patch set allows user space to receive vtimer events as well as mask
> >>>>>>> them, so that we can handle all vtimer related interrupt injection from user
> >>>>>>> space, enabling us to use architected timer with user space gic emulation.
> >>>>>>
> >>>>>> I have already voiced my concerns in the past, including face to face,
> >>>>>> and I'm going to repeat it: I not keen at all on adding a new userspace
> >>>>>> interface that is going to bitrot extremely quickly.
> >>>>>
> >>>>> You don't have automated tests set up? It's not going to bitrot if you
> >>>>> test it, either with kvm-unit-tests or just by smoke-testing Linux.
> >>>>> It's _for_ the raspi, but it's not limited to it.
> >>>>
> >>>> Our automated testing situation is not great, no. Something we're
> >>>> looking at, but have resource problems with.
> >>>
> >>> But it's not a good reason to hold back a feature...
> >>
> >> I didn't say that exactly, but choosing not to merge something we cannot
> >> maintain and which we're not paid to look after and where there's a
> >> minimal interest, is not entirely unreasonable.
> >>
> >> That being said, I'm not categorically against these patches, but I
> >> share Marc's view that we've already seen that non-vgic support had been
> >> broken for multiple versions without anyone complaining, and without
> >> automated testing or substantial interest in the work, the patches
> >> really are likely to bit-rot.
> >>
> >> But I haven't even looked at the patches in detail, I was just replying
> >> to the comment about testing.
> >
> > This may be a great time to start encouraging feature writers to submit
> > kvm-unit-tests patches at the same time as the feature (Hi Alex :-)
>
> I actually started off implementing this with the help of kvm-unit-tests. It's awesome!
>
> I'm lacking actual irq support to make the test reasonable though and wanted to get the kernel bits out first :). But I'll sit down on that again soon I hope.
I'm glad it looks like a good base for you. I need to get this series
https://github.com/rhdrjones/kvm-unit-tests/commits/arm/gic refreshed and
merged, and also it's time to start looking into adding interrupt
injection to chr-testdev. With those in place I hope it'll be an even
better base for you.
Thanks,
drew
^ permalink raw reply
* [RESEND PATCH v7 2/2] sdhci-of-arasan: Set controller to test mode when xlnx,fails-without-test-cd is present
From: Adrian Hunter @ 2016-09-19 7:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474038102-20937-2-git-send-email-zach.brown@ni.com>
On 16/09/16 18:01, Zach Brown wrote:
> The sdhci controller on xilinx zynq devices will not function unless
> the CD bit is provided. http://www.xilinx.com/support/answers/61064.html
> In cases where it is impossible to provide the CD bit in hardware,
> setting the controller to test mode and then setting inserted to true
> will get the controller to function without the CD bit.
>
> When the device has the property xlnx,fails-without-test-cd the driver
> changes the controller to test mode and sets test inserted to true to
> make the controller function.
>
> Signed-off-by: Zach Brown <zach.brown@ni.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 27 ++++++++++++++++++++++++++-
> drivers/mmc/host/sdhci.h | 2 ++
> 2 files changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-arasan.c
> index 33601a8..da8e40a 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -26,6 +26,7 @@
> #include <linux/phy/phy.h>
> #include <linux/regmap.h>
> #include "sdhci-pltfm.h"
> +#include <linux/of.h>
>
> #define SDHCI_ARASAN_CLK_CTRL_OFFSET 0x2c
> #define SDHCI_ARASAN_VENDOR_REGISTER 0x78
> @@ -98,6 +99,10 @@ struct sdhci_arasan_data {
>
> struct regmap *soc_ctl_base;
> const struct sdhci_arasan_soc_ctl_map *soc_ctl_map;
> + unsigned int quirks; /* Arasan deviations from spec */
> +
> +/* Controller does not have CD wired and will not function normally without */
> +#define SDHCI_ARASAN_QUIRK_FORCE_CDTEST BIT(0)
> };
>
> static const struct sdhci_arasan_soc_ctl_map rk3399_soc_ctl_map = {
> @@ -245,12 +250,27 @@ static void sdhci_arasan_hs400_enhanced_strobe(struct mmc_host *mmc,
> writel(vendor, host->ioaddr + SDHCI_ARASAN_VENDOR_REGISTER);
> }
>
> +void sdhci_arasan_reset(struct sdhci_host *host, u8 mask)
> +{
> + u8 ctrl;
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan = sdhci_pltfm_priv(pltfm_host);
> +
> + sdhci_reset(host, mask);
> +
> + if (sdhci_arasan->quirks & SDHCI_ARASAN_QUIRK_FORCE_CDTEST) {
> + ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> + ctrl |= SDHCI_CTRL_CDTEST_INS | SDHCI_CTRL_CDTEST_EN;
> + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> + }
> +}
> +
> static struct sdhci_ops sdhci_arasan_ops = {
> .set_clock = sdhci_arasan_set_clock,
> .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> .get_timeout_clock = sdhci_arasan_get_timeout_clock,
> .set_bus_width = sdhci_set_bus_width,
> - .reset = sdhci_reset,
> + .reset = sdhci_arasan_reset,
> .set_uhs_signaling = sdhci_set_uhs_signaling,
> };
>
> @@ -545,6 +565,7 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> struct sdhci_host *host;
> struct sdhci_pltfm_host *pltfm_host;
> struct sdhci_arasan_data *sdhci_arasan;
> + struct device_node *np = pdev->dev.of_node;
>
> host = sdhci_pltfm_init(pdev, &sdhci_arasan_pdata,
> sizeof(*sdhci_arasan));
> @@ -599,6 +620,10 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> }
>
> sdhci_get_of_property(pdev);
> +
> + if (of_property_read_bool(np, "xlnx,fails-without-test-cd"))
> + sdhci_arasan->quirks |= SDHCI_ARASAN_QUIRK_FORCE_CDTEST;
> +
> pltfm_host->clk = clk_xin;
>
> if (of_device_is_compatible(pdev->dev.of_node,
> diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
> index a2bc9e1..c722cd2 100644
> --- a/drivers/mmc/host/sdhci.h
> +++ b/drivers/mmc/host/sdhci.h
> @@ -84,6 +84,8 @@
> #define SDHCI_CTRL_ADMA32 0x10
> #define SDHCI_CTRL_ADMA64 0x18
> #define SDHCI_CTRL_8BITBUS 0x20
> +#define SDHCI_CTRL_CDTEST_INS 0x40
> +#define SDHCI_CTRL_CDTEST_EN 0x80
>
> #define SDHCI_POWER_CONTROL 0x29
> #define SDHCI_POWER_ON 0x01
>
^ permalink raw reply
* [PATCH 11/11] ARM: DT: STM32: add dma for usart1 on F429
From: Alexandre Torgue @ 2016-09-19 7:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAF3+TqcYuXnzokoR=vAsOofBkyA1WhuXvCc6HrekAovW2VejMQ@mail.gmail.com>
Hi Bruno,
On 09/19/2016 03:28 AM, Bruno Herrera wrote:
>> Signed-off-by: Gerald Baeza <gerald.baeza@st.com>
>> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
>
> I just tested your patch with success in two scenarios:
>
> 1) STM32F469IDISCO board
> 2) Custom board running STM32F439NI
>
> Tested-by: Bruno Herrera <bruherrera@gmail.com>
>
> One last comment I have bellow:
>
>>
>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
>> index 35df462..227376b 100644
>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>> @@ -161,6 +161,9 @@
>> interrupts = <37>;
>> clocks = <&rcc 0 164>;
>> status = "disabled";
>> + dmas = <&dma2 2 4 0x414 0x0>,
>> + <&dma2 7 4 0x414 0x0>;
>
> According to stm32-dma.txt documentation in the third parameter (32bit
> mask) only the following bits can be set : 9,10,15,16,17 and 0x414 is
> setting bits 2 and 4. It make sense if you look in the register itself
> (DMA_SxCR) but as far I could see from the DMA driver code this bits
> are set internally. The correct value should be 0x400.
Thanks for you careful review: the dma issue you noticed is due to the
fact that this bit field binding changed between kernel 4.2 and 4.8.
Front of kernel 4.2, 0x414 was fine... but now it is no more, you are
right.
I will fix it in my next pull request.
Thanks
Alex
>
>> + dma-names = "rx", "tx";
>> };
>>
>> usart6: serial at 40011400 {
.
^ permalink raw reply
* [PATCH v6 0/8] power: add power sequence library
From: Peter Chen @ 2016-09-19 7:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ecbc3c0d-4ce7-758d-7f7d-4b3f3003c1ac@linaro.org>
On Mon, Sep 19, 2016 at 01:09:10PM +0530, Vaibhav Hiremath wrote:
>
>
> On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
> >[...]
> >
> >>>>>We had an agreement that keep mmc's pwrseq framework unchanging.
> >>>>>Unless Ulf and rob both agree to change.
> >>>>Why 2 separate approach for same problem ?
> >>>>And I see this as possible duplication of code/functionality :)
> >>>How the new kernel compatibles old dts? If we do not need to
> >>>consider this problem, the mmc can try to use power sequence library
> >>>too in future.
> >>
> >>I think we should attempt to get both MMC and USB power seq
> >>come on one agreement, so that it can be reused.
> >That would be nice. Although, to do that you would have to allow some
> >DT bindings to be deprecated in the new generic power seq bindings, as
> >otherwise you would break existing DTBs.
> >
> >I guess that is what Rob was objecting to!?
>
> yeah, thats right.
>
> So lets adopt similar implementation for USB as well instead of
> library, but keeping MMC untouched as of now.
>
> What I am trying to propose here is,
>
> Lets have power-sequence framework (similar to V1 of this series),
> with,
>
> pwrseq: Core framework for power sequence.
> pwrseq_generic/simple: for all generic control, like reset and clock
> pwrseq_emmc: probably duplication of existing code - the idea
> here is, all future code should be using this new
> binding, so that we can deprecate the
> drivers/mmc/core/pwrseq
> pwrseq_arche: The usecase which I am dealing with today, which is more
> complex in nature.
>
> Then the respective drivers can add their drivers (if needed) based on
> complexity.
>
> comments ??
The key point here is DT maintainer (Rob) doesn't agree with adding new node
for power sequence at dts.
--
Best Regards,
Peter Chen
^ permalink raw reply
* [PATCH v5 3/5] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Arnd Bergmann @ 2016-09-19 7:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474259324.15220.5.camel@buserror.net>
On Sunday, September 18, 2016 11:28:44 PM CEST Scott Wood wrote:
> On Mon, 2016-09-12 at 13:30 +0100, Mark Rutland wrote:
> > On Mon, Sep 12, 2016 at 12:44:07PM +0100, Will Deacon wrote:
> > >
> > > On Mon, Sep 12, 2016 at 12:36:15PM +0100, Mark Rutland wrote:
> > > >
> > > > The changes in arm64's <asm/arch_timer.h> are going to conflict with
> > > > some cleanup [1,2] that just landed in the arm64 for-next/core branch.
> > > >
> > > > Could you please rebase atop of that?
> > > Well, we should figure out what tree this is going through first. There
> > > are a mixture of arm, arm64, driver and dts changes here and not all
> > > of it is carrying the appropriate acks for me to queue it.
> > Given that mix, I had assumed that this would all go through the arm64
> > tree -- I see that Rob has already acked the binding, and I'm happy to
> > give my ack for the driver once that's in shape.
> >
> > The dts change could go through arm-soc in parallel, I guess. It doesn't
> > look like arm-soc have been Cc'd for that, though.
>
> The arm-soc section of MAINTAINERS says to e-mail linux-arm-kernel, which I
> did. There doesn't appear to be a separate arm-soc mailing list, nor is there
> a request to CC Olof/Arnd. I did CC Shawn Guo who has been handling the
> device tree patches for these chips.
That is the right way to do it. If the DT change is a bugfix that should
get merged along with the rest, Shawn can also provide an Ack to have it
merged through the arm64 tree, ideally warning us if there might be any
conflicts with stuff that gets sent for arm-soc.
Arnd
^ permalink raw reply
* [PATCH v6 0/8] power: add power sequence library
From: Vaibhav Hiremath @ 2016-09-19 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFp0w0mBGNgu6uk7UevUka_ha6MvaVyOzXjCg3S8kdF7tg@mail.gmail.com>
On Friday 09 September 2016 02:17 PM, Ulf Hansson wrote:
> [...]
>
>>>>> We had an agreement that keep mmc's pwrseq framework unchanging.
>>>>> Unless Ulf and rob both agree to change.
>>>> Why 2 separate approach for same problem ?
>>>> And I see this as possible duplication of code/functionality :)
>>> How the new kernel compatibles old dts? If we do not need to
>>> consider this problem, the mmc can try to use power sequence library
>>> too in future.
>>
>> I think we should attempt to get both MMC and USB power seq
>> come on one agreement, so that it can be reused.
> That would be nice. Although, to do that you would have to allow some
> DT bindings to be deprecated in the new generic power seq bindings, as
> otherwise you would break existing DTBs.
>
> I guess that is what Rob was objecting to!?
yeah, thats right.
So lets adopt similar implementation for USB as well instead of
library, but keeping MMC untouched as of now.
What I am trying to propose here is,
Lets have power-sequence framework (similar to V1 of this series),
with,
pwrseq: Core framework for power sequence.
pwrseq_generic/simple: for all generic control, like reset and clock
pwrseq_emmc: probably duplication of existing code - the idea
here is, all future code should be using this new
binding, so that we can deprecate the
drivers/mmc/core/pwrseq
pwrseq_arche: The usecase which I am dealing with today, which is more
complex in nature.
Then the respective drivers can add their drivers (if needed) based on
complexity.
comments ??
>> MMC Power Seq :
>> It is based on platform_device/platform_driver approach,
> We recently converted MMC to this. It's has a clear benefit as you can
> rely on the behaviour from the driver core and PM core. So, it simply
> avoids duplication of code.
Agreed.
>> USB Power seq :
>> We are trying to propose library approach, with compatible string match.
>>
>> We should try to have one approach.
>>>
>>>>>> - Lets also add suspend/resume callback to struct pwrseq
>>>>>>
>>>>> Why suspend/resume can't do at related driver's suspend/resume API?
>>>> Nope...
>>>> The pwrseq library would have taken ownership of resources, so
>>>> related driver cannot suspend the device. Again it is architecture
>>>> specific, but we should have provision to handle this.
>>>>
>>>> The system I am dealing with today, does need suspend/resume
>>>> callback. To be precise, suspend is close to off state for some devices
>>>> or
>>>> they could enter standby or different low power state, but to do that,
>>>> we need same resource as used for ON/OFF functionality.
>>>>
>>> Ok, I will have API for suspend/resume. You can implement it at your own
>>> library or generic one.
> As stated, using a platform device + driver would simplify this, as
> you wouldn't need an API but only a driver. I guess.
Exactly.
Thanks,
Vaibhav
^ permalink raw reply
* [PATCH 4/7] phy: meson: add USB2 PHY support for Meson8b and GXBB
From: Arnd Bergmann @ 2016-09-19 7:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <57DF70AF.4050002@ti.com>
On Monday, September 19, 2016 10:29:27 AM CEST Kishon Vijay Abraham I wrote:
> On Monday 19 September 2016 01:26 AM, Martin Blumenstingl wrote:
> > On Fri, Sep 16, 2016 at 10:19 AM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
> >> This way the driver will be probed only once (the reset can be done during
> >> probe). The phy driver should scan the dt node and for every sub-node it
> >> invokes phy_create?
> > I'll recap what we have discussed so far (so you don't have to re-read
> > the whole thread):
> > The reference driver treats both USB PHYs as separate devices (the
> > datasheet has no information about the PHYs though). The only
> > "special" thing is the shared reset line -> together with Philipp
> > Zabel (the reset framework maintainer) we decided to make
> > reset_control_reset work for shared reset lines.
> >
> > That means we can keep the two PHYs as separate devices inside the
> > .dts, while keeping everything else separate (just like the reference
> > driver)
> > Is this fine for you and Arnd?
>
> yeah.. I'm fine with that.
>
Agreed, if we don't need to have a device modeled around both
instance, that's ideal.
Arnd
^ permalink raw reply
* [PATCH 5/6] arm/arm64: vgic-new: Implement VGICv3 CPU interface access
From: Vijay Kilari @ 2016-09-19 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160917123756.0a05a904@arm.com>
Hi Marc , Peter
On Sat, Sep 17, 2016 at 5:07 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
> On Sat, 17 Sep 2016 11:58:48 +0530
> Vijay Kilari <vijay.kilari@gmail.com> wrote:
>
>> On Fri, Sep 16, 2016 at 10:37 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> > On 16/09/16 17:57, Vijay Kilari wrote:
>> >> On Fri, Sep 16, 2016 at 8:06 PM, Marc Zyngier <marc.zyngier@arm.com> wrote:
>> >>> On 16/09/16 13:20, vijay.kilari at gmail.com wrote:
>> >>>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >>>>
>> >>>> VGICv3 CPU interface registers are accessed using
>> >>>> KVM_DEV_ARM_VGIC_CPU_SYSREGS ioctl. These registers are accessed
>> >>>> as 64-bit. The cpu MPIDR value is passed along with register id.
>> >>>> is used to identify the cpu for registers access.
>> >>>>
>> >>>> The version of VGIC v3 specification is define here
>> >>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>> >>>>
>> >>>> Signed-off-by: Pavel Fedin <p.fedin@samsung.com>
>> >>>> Signed-off-by: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>> >>>> ---
>> >>>> arch/arm64/include/uapi/asm/kvm.h | 3 +
>> >>>> arch/arm64/kvm/Makefile | 1 +
>> >>>> include/linux/irqchip/arm-gic-v3.h | 30 ++++
>> >>>> virt/kvm/arm/vgic/vgic-kvm-device.c | 27 ++++
>> >>>> virt/kvm/arm/vgic/vgic-mmio-v3.c | 18 +++
>> >>>> virt/kvm/arm/vgic/vgic-sys-reg-v3.c | 296 ++++++++++++++++++++++++++++++++++++
>> >>>> virt/kvm/arm/vgic/vgic.h | 10 ++
>> >>>> 7 files changed, 385 insertions(+)
>> >
>> > [...]
>> >
>> >>>> diff --git a/virt/kvm/arm/vgic/vgic-sys-reg-v3.c b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>> >>>> new file mode 100644
>> >>>> index 0000000..8e4f403
>> >>>> --- /dev/null
>> >>>> +++ b/virt/kvm/arm/vgic/vgic-sys-reg-v3.c
>> >>>> @@ -0,0 +1,296 @@
>> >>>> +#include <linux/irqchip/arm-gic-v3.h>
>> >>>> +#include <linux/kvm.h>
>> >>>> +#include <linux/kvm_host.h>
>> >>>> +#include <kvm/iodev.h>
>> >>>> +#include <kvm/arm_vgic.h>
>> >>>> +#include <asm/kvm_emulate.h>
>> >>>> +#include <asm/kvm_arm.h>
>> >>>> +#include <asm/kvm_mmu.h>
>> >>>> +
>> >>>> +#include "vgic.h"
>> >>>> +#include "vgic-mmio.h"
>> >>>> +#include "sys_regs.h"
>> >>>> +
>> >>>> +static bool access_gic_ctlr(struct kvm_vcpu *vcpu, struct sys_reg_params *p,
>> >>>> + const struct sys_reg_desc *r)
>> >>>> +{
>> >>>> + struct vgic_vmcr vmcr;
>> >>>> + u64 val;
>> >>>> + u32 ich_vtr;
>> >>>> +
>> >>>> + vgic_get_vmcr(vcpu, &vmcr);
>> >>>> + if (p->is_write) {
>> >>>> + val = p->regval;
>> >>>> + vmcr.ctlr &= ~(ICH_VMCR_CBPR_MASK | ICH_VMCR_EOIM_MASK);
>> >>>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_CBPR_MASK) >>
>> >>>> + ICC_CTLR_EL1_CBPR_SHIFT) << ICH_VMCR_CBPR_SHIFT;
>> >>>> + vmcr.ctlr |= ((val & ICC_CTLR_EL1_EOImode_MASK) >>
>> >>>> + ICC_CTLR_EL1_EOImode_SHIFT) << ICH_VMCR_EOIM_SHIFT;
>> >>>> + vgic_set_vmcr(vcpu, &vmcr);
>> >>>
>> >>> You've ignored my comments again: "What if userspace writes something
>> >>> that is incompatible with the current configuration? Wrong number of ID
>> >>> bits, or number of priorities?"
>> >>
>> >> IMO, In case of incompatibility,
>> >> If ID bits and PRI bits are less than HW supported, it is ok.
>> >
>> > Yes. But you also need to track of what the guest has programmed in
>> > order to be able to migrate it back to its original configuration.
>>
>> You mean the vgic has to track/store the ID and PRI bits that guest
>> has programmed
>> and return the same when guest reads back instead of
>> returning HW supported value for ICC_CTLR_EL1 reg access?.
>
> If you have two hosts (A and B), A having 5 bits of priority and B
> having 7 bits, you should be able to migrate from A to B, and then from
> B to A. Which means you have to preserve what the guest knows to be its
> configuration, even if you run on a more capable system. Otherwise,
> you're a bit stuck.
>
> You probably won't be able to hide the discrepancy from inside the
> guest though (the guest will be able to observe the change), but this
> is better than nothing.
In order to track the PRI and ID bits written by guest,
VGIC needs to store these values when ICC_CTRL_EL1 is updated.
However, QEMU is reseting VGIC by writing 0's to all the
registers after VGIC initialization and hence the back up values are
always reset to 0 and hence when guest read back, VGIC returns wrong value.
One option is to drop VGIC reset from QEMU which is not doing much.
^ permalink raw reply
* [PATCH 1/1] ARM: imx5: Add clocks configuration
From: Fabien Lahoudere @ 2016-09-19 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160918002451.GE15478@tiger>
Hi,
On 18/09/16 02:24, Shawn Guo wrote:
> On Sun, Sep 18, 2016 at 08:21:59AM +0800, Shawn Guo wrote:
>> On Thu, Sep 15, 2016 at 08:42:33PM +0300, Alexander Shiyan wrote:
>>>> ???????, 15 ???????? 2016, 13:13 +03:00 ?? Fabien Lahoudere <fabien.lahoudere@collabora.co.uk>:
>>>>
>>>> From: Kalle Kankare < kalle.kankare@vincit.fi >
>>>>
>>>> Add clocks configuration for CSI, FIRI and IEEE1588.
>>>>
>>>> Signed-off-by: Fabien Lahoudere < fabien.lahoudere@collabora.co.uk >
>>>> ---
>>>> drivers/clk/imx/clk-imx51-imx53.c | 20 ++++++++++++++++++++
>>>> include/dt-bindings/clock/imx5-clock.h | 15 ++++++++++++++-
>>>> 2 files changed, 34 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/clk/imx/clk-imx51-imx53.c b/drivers/clk/imx/clk-imx51-imx53.c
>>>> index 29d4c44..1e3c9ea 100644
>>>> --- a/drivers/clk/imx/clk-imx51-imx53.c
>>>> +++ b/drivers/clk/imx/clk-imx51-imx53.c
>>>> @@ -126,6 +126,7 @@ static const char *spdif0_com_sel[] = { "spdif0_podf", "ssi1_root_gate", };
>>>> static const char *mx51_spdif1_com_sel[] = { "spdif1_podf", "ssi2_root_gate", };
>>>> static const char *step_sels[] = { "lp_apm", };
>>>> static const char *cpu_podf_sels[] = { "pll1_sw", "step_sel" };
>>>> +static const char *ieee1588_sels[] = { "pll3_sw", "pll4_sw", "dummy" /* usbphy2_clk */, "dummy" /* fec_phy_clk */ };
>>>>
>>>> static struct clk *clk[IMX5_CLK_END];
>>>> static struct clk_onecell_data clk_data;
>>>> @@ -543,6 +544,25 @@ static void __init mx53_clocks_init(struct device_node *np)
>>> ...
>>>
>>> 2 Shawn Guo: Since the change affects only on i.MX53 architecture,
>>> I would ask to change the subject to i.MX53 if it possible.
>>
>> Yes. Actually, since clock driver is not moved to drivers/clk, we
>
> s/not/now
>
>> shouldn't prefix it with "ARM: " any longer.
Ok is "clk: imx53: Add clocks configuration" ok?
>
> Shawn
>
Thanks
Fabien
^ permalink raw reply
* [PATCH v2 3/6] dt/bindings: Add bindings for Tegra GMI controller
From: Mirza Krak @ 2016-09-19 7:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a3a2371b-5d98-db2d-b7e4-be6d08cb7271@nvidia.com>
2016-09-06 12:32 GMT+02:00 Jon Hunter <jonathanh@nvidia.com>:
>
> On 31/08/16 12:22, Mirza Krak wrote:
>> 2016-08-30 19:06 GMT+02:00 Rob Herring <robh@kernel.org>:
>
> ...
>
>>>> nvidia,snor-cs = <4>;
>>>
>>> NAK, no custom CS properties.
>
> Ok, so ...
>
>> gmi at 70090000 {
>> compatible = "nvidia,tegra20-gmi";
>> reg = <0x70009000 0x1000>;
>> #address-cells = <2>;
>> #size-cells = <1>;
>> clocks = <&tegra_car TEGRA20_CLK_NOR>;
>> clock-names = "gmi";
>> resets = <&tegra_car 42>;
>> reset-names = "gmi";
>> ranges = <4 0 0xd0000000 0xfffffff>;
>>
>> status = "okay";
>>
>> bus at 4,0 {
>> compatible = "simple-bus";
>> #address-cells = <1>;
>> #size-cells = <1>;
>> ranges = <0 4 0 0x40000>;
>>
>> nvidia,snor-mux-mode;
>> nvidia,snor-adv-inv;
>>
>> can at 0 {
>> reg = <0 0x100>;
>> ...
>> };
>>
>> can at 40000 {
>> reg = <0x40000 0x100>;
>> ...
>> };
>> };
>> };
>>
>> Have I understood you correct?
>>
>> Also wanted to verify the example case where you only have on device
>> connected to one CS#, from what I see in other implementations it
>> seems OK to put the CS# in the reg property in that case. Is this
>> correct?
>>
>> Example with one SJA1000 CAN controller connected to the GMI bus
>> on CS4:
>>
>> gmi at 70090000 {
>> compatible = "nvidia,tegra20-gmi";
>> reg = <0x70009000 0x1000>;
>> #address-cells = <2>;
>> #size-cells = <1>;
>> clocks = <&tegra_car TEGRA20_CLK_NOR>;
>> clock-names = "gmi";
>> resets = <&tegra_car 42>;
>> reset-names = "gmi";
>> ranges = <4 0 0xd0000000 0xfffffff>;
>>
>> status = "okay";
>>
>> can at 4,0 {
>> reg = <4 0 0x100>;
>> nvidia,snor-mux-mode;
>> nvidia,snor-adv-inv;
>> ...
>> };
>> };
>>
>> Jon, to be able to handle both cases in the driver we would first
>> attempt to decode the CS# from the ranges property, and fallback to
>> reg property if no ranges are defined. Does that sound reasonable?
>
> Given the above examples that may be supported, is there a
> better/simpler way to extract the CS# than what Mirza is proposing? For
> example, from the node-name unit-address?
>
Hi.
I have been on vacation and now I am back and wanted to finalize these
patch series.
So pinging this thread to see I we can agree on a solution.
Rob any comments to my proposal and Jon`s comment?
Best Regards
Mirza Krak
^ permalink raw reply
* [PATCH 07/19] ahci: st: Remove STiH416 dt example
From: Patrice Chotard @ 2016-09-19 7:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916155449.GB26371@htj.duckdns.org>
On 09/16/2016 05:54 PM, Tejun Heo wrote:
> On Wed, Sep 14, 2016 at 02:27:45PM +0100, Peter Griffin wrote:
>> This platform is being removed from the kernel so remove
>> the dt example.
>>
>> Signed-off-by: Peter Griffin <peter.griffin@linaro.org>
>> Cc: <tj@kernel.org>
>> Cc: <robh+dt@kernel.org>
>> Cc: <linux-ide@vger.kernel.org>
>
> This is gonna go through dt tree, right? If it should go through
> libata, please let me know.
Hi Tejun
I will take care of this patch and include it in the next STi DT pull request.
Thanks
>
> Thanks.
>
^ permalink raw reply
* [PATCH v14 0/4] Mediatek MT8173 CMDQ support
From: Horng-Shyang Liao @ 2016-09-19 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473039885-24009-1-git-send-email-hs.liao@mediatek.com>
On Mon, 2016-09-05 at 09:44 +0800, HS Liao wrote:
> Hi,
>
> This is Mediatek MT8173 Command Queue(CMDQ) driver. The CMDQ is used
> to help write registers with critical time limitation, such as
> updating display configuration during the vblank. It controls Global
> Command Engine (GCE) hardware to achieve this requirement.
>
> These patches have a build dependency on top of v4.8-rc1.
>
> Changes since v13:
> - move to mailbox folder
> - simplify cmdq_thread_is_in_wfe
>
> Best regards,
> HS Liao
>
> HS Liao (4):
> dt-bindings: soc: Add documentation for the MediaTek GCE unit
> CMDQ: Mediatek CMDQ driver
> arm64: dts: mt8173: Add GCE node
> CMDQ: save more energy in idle
>
> .../devicetree/bindings/mailbox/mtk-gce.txt | 43 +
> arch/arm64/boot/dts/mediatek/mt8173.dtsi | 10 +
> drivers/mailbox/Kconfig | 10 +
> drivers/mailbox/Makefile | 2 +
> drivers/mailbox/mtk-cmdq.c | 965 +++++++++++++++++++++
> include/linux/mailbox/mtk-cmdq.h | 180 ++++
> 6 files changed, 1210 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mailbox/mtk-gce.txt
> create mode 100644 drivers/mailbox/mtk-cmdq.c
> create mode 100644 include/linux/mailbox/mtk-cmdq.h
>
Hi Jassi,
Sorry to disturb you.
Do you have any further comment on CMDQ v14?
Thanks.
HS
^ permalink raw reply
* [PATCH v4] mtd: nand: automate NAND timings selection
From: Sascha Hauer @ 2016-09-19 6:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160916141918.0353f65f@bbrezillon>
On Fri, Sep 16, 2016 at 02:19:18PM +0200, Boris Brezillon wrote:
> On Thu, 15 Sep 2016 10:32:44 +0200
> Sascha Hauer <s.hauer@pengutronix.de> wrote:
>
> > This series aims at automating the NAND timings selection which is
> > currently supposed to be done in each NAND controller driver, thus
> > simplifying drivers implementation.
> >
> > As suggested by Boris this version of the series introduces a nand_reset()
> > function which replaces the several open coded NAND_CMD_RESET commands
> > in the code. This makes sure we can apply the timing each time after
> > after reset.
> >
> > Also I have brought back the conversion patch for teh sunxi driver whic
> > was part of Boris initial posting. It's untested due to the lack of hardware,
> > so please test before applying.
>
> Applied after fixing a few coding style issues (to make checkpatch
> happy), and exporting the onfi_init_data_interface() function (not sure
> it's the best solution, but at least, it's consistent with the other
> functions defined in nand_timings.c).
Thanks Boris.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH 2/2] media: mtk-mdp: fix build error
From: Minghsiu Tsai @ 2016-09-19 6:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474266883-51155-1-git-send-email-minghsiu.tsai@mediatek.com>
This patch fix build error without CONFIG_PM_RUNTIME
and CONFIG_PM_SLEEP
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
---
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index b0c421e..f4424064 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -233,7 +233,7 @@ static int mtk_mdp_remove(struct platform_device *pdev)
return 0;
}
-#if defined(CONFIG_PM_RUNTIME) || defined(CONFIG_PM_SLEEP)
+#ifdef CONFIG_PM
static int mtk_mdp_pm_suspend(struct device *dev)
{
struct mtk_mdp_dev *mdp = dev_get_drvdata(dev);
@@ -251,7 +251,7 @@ static int mtk_mdp_pm_resume(struct device *dev)
return 0;
}
-#endif /* CONFIG_PM_RUNTIME || CONFIG_PM_SLEEP */
+#endif /* CONFIG_PM */
#ifdef CONFIG_PM_SLEEP
static int mtk_mdp_suspend(struct device *dev)
--
1.7.9.5
^ permalink raw reply related
* [PATCH 1/2] media: mtk-mdp: fix build warning in arch x86
From: Minghsiu Tsai @ 2016-09-19 6:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474266883-51155-1-git-send-email-minghsiu.tsai@mediatek.com>
This patch fix build warning in arch x86
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
---
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 1 +
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 10 ++++++----
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
index a90972e..9a747e7 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
@@ -17,6 +17,7 @@
#include <linux/errno.h>
#include <linux/kernel.h>
#include <linux/pm_runtime.h>
+#include <linux/slab.h>
#include <linux/workqueue.h>
#include <media/v4l2-event.h>
#include <media/v4l2-ioctl.h>
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
index fb07bf3..39188e5 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
@@ -25,7 +25,8 @@ static inline struct mtk_mdp_ctx *vpu_to_ctx(struct mtk_mdp_vpu *vpu)
static void mtk_mdp_vpu_handle_init_ack(struct mdp_ipi_comm_ack *msg)
{
- struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
+ struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)
+ (unsigned long)msg->ap_inst;
/* mapping VPU address to kernel virtual address */
vpu->vsi = (struct mdp_process_vsi *)
@@ -37,7 +38,8 @@ static void mtk_mdp_vpu_ipi_handler(void *data, unsigned int len, void *priv)
{
unsigned int msg_id = *(unsigned int *)data;
struct mdp_ipi_comm_ack *msg = (struct mdp_ipi_comm_ack *)data;
- struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
+ struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)
+ (unsigned long)msg->ap_inst;
struct mtk_mdp_ctx *ctx;
vpu->failure = msg->status;
@@ -108,7 +110,7 @@ static int mtk_mdp_vpu_send_ap_ipi(struct mtk_mdp_vpu *vpu, uint32_t msg_id)
msg.msg_id = msg_id;
msg.ipi_id = IPI_MDP;
msg.vpu_inst_addr = vpu->inst_addr;
- msg.ap_inst = (uint64_t)vpu;
+ msg.ap_inst = (unsigned long)vpu;
err = mtk_mdp_vpu_send_msg((void *)&msg, sizeof(msg), vpu, IPI_MDP);
if (!err && vpu->failure)
err = -EINVAL;
@@ -126,7 +128,7 @@ int mtk_mdp_vpu_init(struct mtk_mdp_vpu *vpu)
msg.msg_id = AP_MDP_INIT;
msg.ipi_id = IPI_MDP;
- msg.ap_inst = (uint64_t)vpu;
+ msg.ap_inst = (unsigned long)vpu;
err = mtk_mdp_vpu_send_msg((void *)&msg, sizeof(msg), vpu, IPI_MDP);
if (!err && vpu->failure)
err = -EINVAL;
--
1.7.9.5
^ permalink raw reply related
* [PATCH 0/2] Fix build warning and error in Mediatek MDP driver
From: Minghsiu Tsai @ 2016-09-19 6:34 UTC (permalink / raw)
To: linux-arm-kernel
- Fix build warning in arch x86
- Fix build warning in kzalloc() and kfree() in arch x86
- Fix build error without CONFIG_PM_RUNTIME and CONFIG_PM_SLEEP
v4l2-compliance test output:
v4l2-compliance SHA : abc1453dfe89f244dccd3460d8e1a2e3091cbadb
Driver Info:
Driver name : mtk-mdp
Card type : soc:mdp
Bus info : platform:mt8173
Driver version: 4.8.0
Capabilities : 0x84204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04204000
Video Memory-to-Memory Multiplanar
Streaming
Extended Pix Format
Compliance test for device /dev/image-proc0 (not using libv4l2):
Required ioctls:
test VIDIOC_QUERYCAP: OK
Allow for multiple opens:
test second video open: OK
test VIDIOC_QUERYCAP: OK
test VIDIOC_G/S_PRIORITY: OK
test for unlimited opens: OK
Debug ioctls:
test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
test VIDIOC_LOG_STATUS: OK (Not Supported)
Input ioctls:
test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
test VIDIOC_ENUMAUDIO: OK (Not Supported)
test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
test VIDIOC_G/S_AUDIO: OK (Not Supported)
Inputs: 0 Audio Inputs: 0 Tuners: 0
Output ioctls:
test VIDIOC_G/S_MODULATOR: OK (Not Supported)
test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
test VIDIOC_ENUMAUDOUT: OK (Not Supported)
test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
test VIDIOC_G/S_AUDOUT: OK (Not Supported)
Outputs: 0 Audio Outputs: 0 Modulators: 0
Input/Output configuration ioctls:
test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
test VIDIOC_G/S_EDID: OK (Not Supported)
Control ioctls:
test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
test VIDIOC_QUERYCTRL: OK
test VIDIOC_G/S_CTRL: OK
test VIDIOC_G/S/TRY_EXT_CTRLS: OK
test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
Standard Controls: 5 Private Controls: 0
Format ioctls:
test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
test VIDIOC_G/S_PARM: OK (Not Supported)
test VIDIOC_G_FBUF: OK (Not Supported)
test VIDIOC_G_FMT: OK
test VIDIOC_TRY_FMT: OK
test VIDIOC_S_FMT: OK
test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
test Cropping: OK
test Composing: OK
test Scaling: OK
Codec ioctls:
test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
test VIDIOC_G_ENC_INDEX: OK (Not Supported)
test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
Buffer ioctls:
test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
test VIDIOC_EXPBUF: OK
Test input 0:
Total: 43, Succeeded: 43, Failed: 0, Warnings: 0
Minghsiu Tsai (2):
media: mtk-mdp: fix build warning in arch x86
media: mtk-mdp: fix build error
drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 4 ++--
drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 1 +
drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 10 ++++++----
3 files changed, 9 insertions(+), 6 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH V5] perf tools: adding support for address filters
From: Adrian Hunter @ 2016-09-19 6:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160917223311.19dac50f03da4f40fd5cc844@kernel.org>
On 17/09/16 16:33, Masami Hiramatsu wrote:
> On Fri, 16 Sep 2016 09:32:43 -0600
> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>
>> On 13 September 2016 at 17:25, Masami Hiramatsu <mhiramat@kernel.org> wrote:
>>> On Tue, 13 Sep 2016 08:18:10 -0600
>>> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
>>>
>>>> On 13 September 2016 at 04:01, Adrian Hunter <adrian.hunter@intel.com> wrote:
>>>>> On 12/09/16 20:53, Mathieu Poirier wrote:
>>>>>> This patch makes it possible to use the current filter
>>>>>> framework with address filters. That way address filters for
>>>>>> HW tracers such as CoreSight and IntelPT can be communicated
>>>>>> to the kernel drivers.
>>>>>>
>>>>>> Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>
>>>>>> ---
>>>>>> Changes for V5:
>>>>>> - Modified perf_evsel__append_filter() to take a string format
>>>>>> rather than an operation.
>>>>>
>>>>> Hope I'm not being a pain, but aren't there other places calling
>>>>> perf_evsel__append_filter() that need to be changed. Might make
>>>>> sense as a separate patch.
>>>>
>>>> No no, you're right - I completely overlooked that.
>>>>
>>>> But shouldn't it be in the same patch? That way a git bisect would
>>>> stay consistent...
>>>
>>> You're right. Caller and callee should be changed in atomic.
>>>
>>> BTW, could you add document updates how the perf command line
>>> will be changed, and also show the result in the patch description?
>>
>> This patch does not change anything on the perf command line. It
>> simply allows current options to succeed (as they should) rather than
>> fail.
>
> Yes, and it will make perf acceptable to pass --filter to CoreSight or
> Intel PT events, or am I misunderstand?
> If it is correct, could you give us an example how to pass it, since
> tools/perf/Documentation/perf-record.txt says it is only for tracepoints?
I am adding support for symbols in the address filter. I will send the
patches soon, but the documentation will be:
--filter=<filter>::
Event filter. This option should follow a event selector (-e) which
selects either tracepoint event(s) or a hardware trace PMU
(e.g. Intel PT or CoreSight).
- tracepoint filters
In the case of tracepoints, multiple '--filter' options are combined
using '&&'.
- address filters
A hardware trace PMU advertises its ability to accept a number of
address filters by specifying a non-zero value in
/sys/bus/event_source/devices/<pmu>/nr_addr_filters.
Address filters have the format:
filter|start|stop|tracestop <start> [/ <size>] [@<file name>]
Where:
- 'filter': defines a region that will be traced.
- 'start': defines an address at which tracing will begin.
- 'stop': defines an address at which tracing will stop.
- 'tracestop': defines a region in which tracing will stop.
<file name> is the name of the object file, <start> is the offset to the
code to trace in that file, and <size> is the size of the region to
trace. 'start' and 'stop' filters need not specify a <size>.
If no object file is specified then the kernel is assumed, in which case
the start address must be a current kernel memory address.
<start> can also be specified by providing the name of a symbol. If the
symbol name is not unique, it can be disambiguated by inserting #n where
'n' selects the n'th symbol in address order. Alternately #0, #g or #G
select only a global symbol. <size> can also be specified by providing
the name of a symbol, in which case the size is calculated to the end
of that symbol. For 'filter' and 'tracestop' filters, if <size> is
omitted and <start> is a symbol, then the size is calculated to the end
of that symbol.
If <size> is omitted and <start> is '*', then the start and size will
be calculated from the first and last symbols, i.e. to trace the whole
file.
If symbol names (or "*") are provided, they must be surrounded by white
space.
The filter passed to the kernel is not necessarily the same as entered.
To see the filter that is passed, use the -v option.
The kernel may not be able to configure a trace region if it is not
within a single mapping. MMAP events (or /proc/<pid>/maps) can be
examined to determine if that is a possibility.
Multiple filters can be separated with space or comma.
^ permalink raw reply
* [PATCH 0/2] ARM: imx31/of: clk: init clock controller with CLK_OF_DECLARE
From: Uwe Kleine-König @ 2016-09-19 5:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474252939-12579-1-git-send-email-vz@mleia.com>
Hello,
On Mon, Sep 19, 2016 at 05:42:17AM +0300, Vladimir Zapolskiy wrote:
> The change is based on v4.8.0-rc1 and plus it depends on this fixup:
>
> ARM: dts: imx31: fix clock control module interrupts description
>
> The change is tested on qemu kzm target and mx31lite board, while both
> targets don't have DTS in upstream, I had to write simple DTS files for
> them, because the proposed change is for i.MX31 targets with OF support.
>
> The second change in the series compilation time dependent on the first
> one, while the first change apparently should break runtime execution
> of i.MX31 boards with OF support, if both changes are applied everything
> should be fine, regression testing on the same legacy targets does not
that means this should be done in a single patch.
> show any problems. Moreover i.MX31/OF/clock initialization seems to be
> broken currently, if the change is not applied I can not get a working
> clock source during early boot stage, jiffies are not incremented, but
> because I didn't check the problem thoroughly (can it be caused by
> missing CLK_OF_DECLARE? Or caused by something fixed by the change
> http://www.spinics.net/lists/linux-clk/msg12235.html ?) and because
> the change was tested against code which is not found in upstream,
> I won't call this change as a fix, however its application is apparently
> wanted to get better OF support for i.MX31 targets.
Very appreciated!
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v6 0/6] Add MT8173 MDP Driver
From: Minghsiu Tsai @ 2016-09-19 5:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <703024ec-f6d4-60e8-ed09-6a2e935857d7@xs4all.nl>
On Wed, 2016-09-14 at 14:43 +0200, Hans Verkuil wrote:
> Hi Minghsiu,
>
> v6 looks good, but I get these warnings when compiling it for i686:
>
> linux-git-i686: WARNINGS
>
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_handle_init_ack':
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:28:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> ^
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_ipi_handler':
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:40:28: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
> struct mtk_mdp_vpu *vpu = (struct mtk_mdp_vpu *)msg->ap_inst;
> ^
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_send_ap_ipi':
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:111:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> msg.ap_inst = (uint64_t)vpu;
> ^
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c: In function 'mtk_mdp_vpu_init':
> /home/hans/work/build/media-git/drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c:129:16: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
> msg.ap_inst = (uint64_t)vpu;
> ^
>
> This is not blocking, but if you can post a follow-up patch for this, then that
> would be helpful.
>
Hi Hans,
I have duplicated this warning message in arch x86.
I also got the report from kbuild robot. There are build errors in
mtk_mdp_pm_suspend().
Besides, in arch x86, I also have build warning messages in kzalloc()
and kfree() used in mtk_mdp_m2m.c. It can be fixed by including
linux/slab.h
I will upload the patches today.
Thanks
Ming Hsiu
> Regards,
>
> Hans
>
>
> On 09/08/2016 03:09 PM, Minghsiu Tsai wrote:
> > Changes in v6:
> > - s_selection() can't set the _DEFAULT and _BOUNDS targets
> > - Add Maintainers entry
> >
> > Changes in v5:
> > - Add ack in the comment of dts patch
> > - Fix s/g_selection()
> > - Separate format V4L2_PIX_FMT_MT21C into new patch
> >
> > Changes in v4:
> > - Add "depends on HAS_DMA" in Kconfig.
> > - Fix s/g_selection()
> > - Replace struct v4l2_crop with u32 and struct v4l2_rect
> > - Remove VB2_USERPTR
> > - Move mutex lock after ctx allocation in mtk_mdp_m2m_open()
> > - Add new format V4L2_PIX_FMT_YVU420 to support software on Android platform.
> > - Only width/height of image in format V4L2_PIX_FMT_MT21 is aligned to 16/16,
> > other ones are aligned to 2/2 by default
> >
> > Changes in v3:
> > - Modify device ndoe as structured one.
> > - Fix conflict in dts on Linux 4.8-rc1
> >
> > Changes in v2:
> > - Add section to describe blocks function in dts-bindings
> > - Remove the assignment of device_caps in querycap()
> > - Remove format's name assignment
> > - Copy colorspace-related parameters from OUTPUT to CAPTURE
> > - Use m2m helper functions
> > - Fix DMA allocation failure
> > - Initialize lazily vpu instance in streamon()
> >
> > ==============
> > Introduction
> > ==============
> >
> > The purpose of this series is to add the driver for Media Data Path HW embedded in the Mediatek's MT8173 SoC.
> > MDP is used for scaling and color space conversion.
> >
> > It could convert V4L2_PIX_FMT_MT21 to V4L2_PIX_FMT_NV12M or V4L2_PIX_FMT_YUV420M.
> >
> > NV12M/YUV420M/MT21 -> MDP -> NV12M/YUV420M
> >
> > This patch series rely on MTK VPU driver in patch series "Add MT8173 Video Encoder Driver and VPU Driver"[1] and "Add MT8173 Video Decoder Driver"[2].
> > MDP driver rely on VPU driver to load, communicate with VPU.
> >
> > Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI both have been merged in v4.6-rc1.
> >
> > [1]https://patchwork.kernel.org/patch/9002171/
> > [2]https://patchwork.kernel.org/patch/9141245/
> >
> > ==================
> > Device interface
> > ==================
> >
> > In principle the driver bases on v4l2 memory-to-memory framework:
> > it provides a single video node and each opened file handle gets its own private context with separate buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source buffers) and CAPTURE (for destination buffers).
> > OUTPUT and CAPTURE buffer could be MMAP or DMABUF memory type.
> >
> > v4l2-compliance test output:
> > v4l2-compliance SHA : abc1453dfe89f244dccd3460d8e1a2e3091cbadb
> >
> > Driver Info:
> > Driver name : mtk-mdp
> > Card type : soc:mdp
> > Bus info : platform:mt8173
> > Driver version: 4.8.0
> > Capabilities : 0x84204000
> > Video Memory-to-Memory Multiplanar
> > Streaming
> > Extended Pix Format
> > Device Capabilities
> > Device Caps : 0x04204000
> > Video Memory-to-Memory Multiplanar
> > Streaming
> > Extended Pix Format
> >
> > Compliance test for device /dev/image-proc0 (not using libv4l2):
> >
> > Required ioctls:
> > test VIDIOC_QUERYCAP: OK
> >
> > Allow for multiple opens:
> > test second video open: OK
> > test VIDIOC_QUERYCAP: OK
> > test VIDIOC_G/S_PRIORITY: OK
> > test for unlimited opens: OK
> >
> > Debug ioctls:
> > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported)
> > test VIDIOC_LOG_STATUS: OK (Not Supported)
> >
> > Input ioctls:
> > test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: OK (Not Supported)
> > test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported)
> > test VIDIOC_ENUMAUDIO: OK (Not Supported)
> > test VIDIOC_G/S/ENUMINPUT: OK (Not Supported)
> > test VIDIOC_G/S_AUDIO: OK (Not Supported)
> > Inputs: 0 Audio Inputs: 0 Tuners: 0
> >
> > Output ioctls:
> > test VIDIOC_G/S_MODULATOR: OK (Not Supported)
> > test VIDIOC_G/S_FREQUENCY: OK (Not Supported)
> > test VIDIOC_ENUMAUDOUT: OK (Not Supported)
> > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported)
> > test VIDIOC_G/S_AUDOUT: OK (Not Supported)
> > Outputs: 0 Audio Outputs: 0 Modulators: 0
> >
> > Input/Output configuration ioctls:
> > test VIDIOC_ENUM/G/S/QUERY_STD: OK (Not Supported)
> > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported)
> > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported)
> > test VIDIOC_G/S_EDID: OK (Not Supported)
> >
> > Control ioctls:
> > test VIDIOC_QUERY_EXT_CTRL/QUERYMENU: OK
> > test VIDIOC_QUERYCTRL: OK
> > test VIDIOC_G/S_CTRL: OK
> > test VIDIOC_G/S/TRY_EXT_CTRLS: OK
> > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK
> > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported)
> > Standard Controls: 5 Private Controls: 0
> >
> > Format ioctls:
> > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK
> > test VIDIOC_G/S_PARM: OK (Not Supported)
> > test VIDIOC_G_FBUF: OK (Not Supported)
> > test VIDIOC_G_FMT: OK
> > test VIDIOC_TRY_FMT: OK
> > test VIDIOC_S_FMT: OK
> > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported)
> > test Cropping: OK
> > test Composing: OK
> > test Scaling: OK
> >
> > Codec ioctls:
> > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported)
> > test VIDIOC_G_ENC_INDEX: OK (Not Supported)
> > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported)
> >
> > Buffer ioctls:
> > test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK
> > test VIDIOC_EXPBUF: OK
> >
> > Test input 0:
> >
> >
> > Total: 43, Succeeded: 43, Failed: 0, Warnings: 0
> >
> > Minghsiu Tsai (6):
> > VPU: mediatek: Add mdp support
> > dt-bindings: Add a binding for Mediatek MDP
> > media: Add Mediatek MDP Driver
> > arm64: dts: mediatek: Add MDP for MT8173
> > media: mtk-mdp: support pixelformat V4L2_PIX_FMT_MT21C
> > media: mtk-mdp: add Maintainers entry for Mediatek MDP driver
> >
> > .../devicetree/bindings/media/mediatek-mdp.txt | 109 ++
> > MAINTAINERS | 9 +
> > arch/arm64/boot/dts/mediatek/mt8173.dtsi | 84 ++
> > drivers/media/platform/Kconfig | 17 +
> > drivers/media/platform/Makefile | 2 +
> > drivers/media/platform/mtk-mdp/Makefile | 9 +
> > drivers/media/platform/mtk-mdp/mtk_mdp_comp.c | 159 +++
> > drivers/media/platform/mtk-mdp/mtk_mdp_comp.h | 72 ++
> > drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 294 +++++
> > drivers/media/platform/mtk-mdp/mtk_mdp_core.h | 260 ++++
> > drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h | 126 ++
> > drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c | 1278 ++++++++++++++++++++
> > drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h | 22 +
> > drivers/media/platform/mtk-mdp/mtk_mdp_regs.c | 156 +++
> > drivers/media/platform/mtk-mdp/mtk_mdp_regs.h | 31 +
> > drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c | 145 +++
> > drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h | 41 +
> > drivers/media/platform/mtk-vpu/mtk_vpu.h | 5 +
> > 18 files changed, 2819 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/media/mediatek-mdp.txt
> > create mode 100644 drivers/media/platform/mtk-mdp/Makefile
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_comp.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_core.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_ipi.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_m2m.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_regs.h
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.c
> > create mode 100644 drivers/media/platform/mtk-mdp/mtk_mdp_vpu.h
> >
^ permalink raw reply
* [PATCH] clk: imx31: fix potential stack corruption on clock initialization
From: Uwe Kleine-König @ 2016-09-19 5:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474249708-11088-1-git-send-email-vz@mleia.com>
On Mon, Sep 19, 2016 at 04:48:28AM +0300, Vladimir Zapolskiy wrote:
> Function mx31_clocks_init() is called during clock intialization on
> legacy boards with reference clock frequency passed as its input
> argument, this can be verified by examination of the function
> declaration found in arch/arm/mach-imx/common.h and actual function
> users which include that header file.
I don't think this can corrupt the stack. The caller puts a value in r0
that is unused by mx31_clocks_init. And given that all callers pass
26000000 there should happen nothing bad apart from a compiler warning.
So: the change is fine, IMHO the commit log shouldn't mention stack
corruption.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 3/3] ARM: dts: imx6qdl-apalis: Use enable-gpios property for backlight
From: Sanchayan Maity @ 2016-09-19 5:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2263d508999ada9476268138b2922702eb50131f.1474260360.git.maitysanchayan@gmail.com>
Use enable-gpios property of PWM backlight driver for backlight
control.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
Changes since v1:
Fix commit message
v1: https://lkml.org/lkml/2016/9/14/55
---
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
index 8c67dd8..9100bde 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -49,7 +49,10 @@
backlight: backlight {
compatible = "pwm-backlight";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_bl_on>;
pwms = <&pwm4 0 5000000>;
+ enable-gpios = <&gpio3 13 GPIO_ACTIVE_HIGH>;
status = "disabled";
};
@@ -614,6 +617,12 @@
>;
};
+ pinctrl_gpio_bl_on: gpioblon {
+ fsl,pins = <
+ MX6QDL_PAD_EIM_DA13__GPIO3_IO13 0x1b0b0
+ >;
+ };
+
pinctrl_gpio_keys: gpio1io04grp {
fsl,pins = <
/* Power button */
--
2.9.3
^ permalink raw reply related
* [PATCH v2 2/3] ARM: dts: imx6q-apalis-ixora: Remove use of pwm-leds
From: Sanchayan Maity @ 2016-09-19 5:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2263d508999ada9476268138b2922702eb50131f.1474260360.git.maitysanchayan@gmail.com>
Remove use of pwm-leds and use the standard /sys/class/pwm
interface from PWM subsystem.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
---
v1: https://lkml.org/lkml/2016/9/14/55
---
arch/arm/boot/dts/imx6q-apalis-ixora.dts | 22 ----------------------
1 file changed, 22 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
index 82b81e0..383192c 100644
--- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
+++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
@@ -146,28 +146,6 @@
gpios = <&gpio2 2 GPIO_ACTIVE_HIGH>;
};
};
-
- pwmleds {
- compatible = "pwm-leds";
-
- ledpwm1 {
- label = "PWM1";
- pwms = <&pwm1 0 50000>;
- max-brightness = <255>;
- };
-
- ledpwm2 {
- label = "PWM2";
- pwms = <&pwm2 0 50000>;
- max-brightness = <255>;
- };
-
- ledpwm3 {
- label = "PWM3";
- pwms = <&pwm3 0 50000>;
- max-brightness = <255>;
- };
- };
};
&backlight {
--
2.9.3
^ permalink raw reply related
* [PATCH v2 1/3] ARM: dts: imx6qdl-apalis: Do not rely on DDC I2C bus bitbang for HDMI
From: Sanchayan Maity @ 2016-09-19 5:11 UTC (permalink / raw)
To: linux-arm-kernel
Remove the use of DDC I2C bus bitbang to support reading of EDID
and rely on support from internal HDMI I2C master controller instead.
As a result remove the device tree property ddc-i2c-bus.
Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
---
Changes since v1:
Change the ranking in i2c aliases
v1: https://lkml.org/lkml/2016/9/14/55
---
arch/arm/boot/dts/imx6q-apalis-ixora.dts | 12 +++---------
arch/arm/boot/dts/imx6qdl-apalis.dtsi | 25 +++++++++----------------
2 files changed, 12 insertions(+), 25 deletions(-)
diff --git a/arch/arm/boot/dts/imx6q-apalis-ixora.dts b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
index 207b85b..82b81e0 100644
--- a/arch/arm/boot/dts/imx6q-apalis-ixora.dts
+++ b/arch/arm/boot/dts/imx6q-apalis-ixora.dts
@@ -55,10 +55,9 @@
"fsl,imx6q";
aliases {
- i2c0 = &i2cddc;
- i2c1 = &i2c1;
- i2c2 = &i2c2;
- i2c3 = &i2c3;
+ i2c0 = &i2c1;
+ i2c1 = &i2c2;
+ i2c2 = &i2c3;
};
aliases {
@@ -186,11 +185,6 @@
};
&hdmi {
- ddc-i2c-bus = <&i2cddc>;
- status = "okay";
-};
-
-&i2cddc {
status = "okay";
};
diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
index 99e323b..8c67dd8 100644
--- a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
@@ -53,18 +53,6 @@
status = "disabled";
};
- /* DDC_I2C: I2C2_SDA/SCL on MXM3 205/207 */
- i2cddc: i2c at 0 {
- compatible = "i2c-gpio";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_i2c_ddc>;
- gpios = <&gpio3 16 GPIO_ACTIVE_HIGH /* sda */
- &gpio2 30 GPIO_ACTIVE_HIGH /* scl */
- >;
- i2c-gpio,delay-us = <2>; /* ~100 kHz */
- status = "disabled";
- };
-
reg_1p8v: regulator-1p8v {
compatible = "regulator-fixed";
regulator-name = "1P8V";
@@ -209,6 +197,12 @@
};
};
+&hdmi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi_ddc>;
+ status = "disabled";
+};
+
/*
* GEN1_I2C: I2C1_SDA/SCL on MXM3 209/211 (e.g. RTC on carrier
* board)
@@ -633,11 +627,10 @@
>;
};
- pinctrl_i2c_ddc: gpioi2cddcgrp {
+ pinctrl_hdmi_ddc: hdmiddcgrp {
fsl,pins = <
- /* DDC bitbang */
- MX6QDL_PAD_EIM_EB2__GPIO2_IO30 0x1b0b0
- MX6QDL_PAD_EIM_D16__GPIO3_IO16 0x1b0b0
+ MX6QDL_PAD_EIM_EB2__HDMI_TX_DDC_SCL 0x4001b8b1
+ MX6QDL_PAD_EIM_D16__HDMI_TX_DDC_SDA 0x4001b8b1
>;
};
--
2.9.3
^ 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