* Re: [PATCH v2 4/6] irqchip/irq-pruss-intc: Add helper functions to configure internal mapping
From: David Lechner @ 2019-08-08 17:09 UTC (permalink / raw)
To: Suman Anna, Marc Zyngier, Thomas Gleixner, Jason Cooper
Cc: Rob Herring, Tony Lindgren, Andrew F. Davis, Roger Quadros,
Lokesh Vutla, Grygorii Strashko, Sekhar Nori, Murali Karicheri,
devicetree, linux-omap, linux-arm-kernel, linux-kernel
In-Reply-To: <6c17875e-496d-1277-278f-239d3a9d8ca2@ti.com>
On 8/2/19 4:26 PM, Suman Anna wrote:
> Point is different applications might use mapping differently as per
> their firmware and driver/application design and their split across one
> or more PRUs (design by contract). And we need to set this up at runtime
> when the application driver is getting run. We will have either the Soft
> UART or the Ethernet running at a time depending on the end goal desired
>
>> I have an idea that we can use multiple struct irq_domains to make
>> this work in the existing IRQ framework, but it would be helpful to
>> know more about the bigger picture first.
>
> Yeah, would be great if there is a way this can be solved without having
> to introduce additional API.
>
Here is what I came up with to use existing IRQ APIs to implement event mapping.
Basically it is the same as my previous suggestion [1], with the addition of
multiple IRQ domains.
The idea is that each external interrupt controller (or DMA controller, etc.)
that is connected to the PRUSS interrupt controller is considered an interrupt
domain. One of the objections to my previous patch was that we could only have
one IRQ descriptor per event. Now we can have one descriptor per event per
domain.
I am still proposing that we use the interrupt-cells and identical vendor
resource data structures in the PRU firmware be used to provide the mapping
information. (As a side note, I still think it is important to include EVTSEL
on AM18xx in order to fully describe the event.)
The bindings will have N = 4 cells (or N = 5 when EVTSEL is required to fully
describe the event):
Cell 0: The PRUSS event number, e.g. 0 to 64 for most PRUSSs
Cell 1: The EVTSEL value (omitted when N == 4), e.g. 0, 1 or
TI_PRUSS_INTC_EVTSEL_ANY if the event is the same for all EVTSEL
values. On AM18xx, external events will all require 0 or 1 while
system events will always be TI_PRUSS_INTC_EVTSEL_ANY.
Cell N-3: The channel that the event gets mapped to, e.g. 0 to 9
Cell N-2: The host that the channel gets mapped to, e.g. 0 to 9
Cell N-1: The interrupt domain, e.g. TI_PRUSS_INTC_DOMAIN_PRU or
TI_PRUSS_INTC_DOMAIN_MCU
The TI_PRUSS_INTC_DOMAIN_* values are just arbitrary numbers assigned to the
possible domains. For example, on AM18xx and AM33xx, there are just two domains,
the PRU domain for host 0 and host 1 and the MCU domain for host 2 thru 9.
Looking at the AM65xx manual, it looks like it would have 4 domains, the PRU
domain, the RTU PRU domain, the MCU domain and a task manager domain. (And I
suppose that domains could even be more granular if needed, e.g. we could drop
the arbitrary domain number and treat each host interrupt/event as an interrupt
domain, then there would be an IRQ descriptor per PRU INTC event per host.)
The AM18xx example I have been using will look like this in the device tree:
interrupts = <63 TI_PRUSS_INTC_EVTSEL_ANY 0 0 TI_PRUSS_INTC_DOMAIN_PRU>,
<62 TI_PRUSS_INTC_EVTSEL_ANY 2 2 TI_PRUSS_INTC_DOMAIN_MCU>;
To keep parsing simple, the PRU firmware can include vendor resources that have
essentially the same format as the device tree bindings. For example:
enum {
/* IRQ descriptor without EVTSEL */
TI_PRU_VENDOR_RESOURCE_IRQ = RSC_VENDOR_START,
/* IRQ descriptor with EVTSEL */
TI_PRU_VENDOR_RESOURCE_IRQ2,
};
struct ti_pru_vendor_resource_irq {
__le32 event;
__le32 channel;
__le32 host;
__le32 domain;
};
struct ti_pru_vendor_resource_irq2 {
__le32 event;
__le32 evt_sel;
__le32 channel;
__le32 host;
__le32 domain;
};
Then we can provide a vendor resource hook in the remoteproc driver to handle
these resources:
static int ti_pru_rproc_handle_rsc(struct rproc *rproc, u32 rsc_type, void *rsc,
int offset, int avail)
{
struct ti_pru_data *pru = rproc->priv;
struct irq_fwspec fwspec;
unsigned int virq;
switch (rsc_type) {
case TI_PRU_VENDOR_RESOURCE_IRQ:
{
struct ti_pru_vendor_resource_irq *rsc_irq = rsc;
fwspec.fwnode = pru->intc_fwnode;
fwspec.param[0] = le32_to_cpu(rsc_irq->event);
fwspec.param[1] = le32_to_cpu(rsc_irq->channel);
fwspec.param[2] = le32_to_cpu(rsc_irq->host);
fwspec.param[3] = le32_to_cpu(rsc_irq->domain);
fwspec.param_count = 4;
}
break;
case TI_PRU_VENDOR_RESOURCE_IRQ2:
{
struct ti_pru_vendor_resource_irq2 *rsc_irq2 = rsc;
fwspec.fwnode = pru->intc_fwnode;
fwspec.param[0] = le32_to_cpu(rsc_irq2->event);
fwspec.param[1] = le32_to_cpu(rsc_irq2->evt_sel);
fwspec.param[2] = le32_to_cpu(rsc_irq2->channel);
fwspec.param[3] = le32_to_cpu(rsc_irq2->host);
fwspec.param[4] = le32_to_cpu(rsc_irq2->domain);
fwspec.param_count = 5;
break;
}
default:
return RSC_IGNORED;
}
virq = irq_create_fwspec_mapping(&fwspec);
if (!virq)
return -EINVAL;
/* TODO: save virq (and other metadata) for later use */
return RSC_HANDLED;
}
static const struct rproc_ops ti_pru_rproc_ops = {
.start = ti_pru_rproc_start,
.stop = ti_pru_rproc_stop,
.kick = ti_pru_rproc_kick,
.da_to_va = ti_pru_rproc_da_to_va,
.handle_rsc = ti_pru_rproc_handle_rsc,
};
The handle_rsc callback is called for each resource when the PRU is booted.
The function irq_create_fwspec_mapping() causes the IRQ to be mapped in
hardware. From what I understand from the previous discussions, this is exactly
when we want this to happen.
This patch applies on top of "irqchip/irq-pruss-intc: Add a PRUSS irqchip driver
for PRUSS interrupts", "irqchip/irq-pruss-intc: Add support for shared and
invalid interrupts" and "irqchip/irq-pruss-intc: Implement irq_{get,set}
_irqchip_state ops" from [PATCH v2 0/6] "Add TI PRUSS Local Interrupt Controller
IRQChip driver" [2].
A working copy along with some remoteproc and rpmsg hacks can be found on my
GitHub [3].
[1]: https://lore.kernel.org/lkml/fb2bdb7b-4d4d-508f-722a-554888280145@lechnology.com/
[2]: https://lore.kernel.org/lkml/20190731224149.11153-1-s-anna@ti.com/
[3]: https://github.com/dlech/linux/commits/pruss-2019-08-08
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Andrew F. Davis <afd@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: David Lechner <david@lechnology.com>
---
drivers/irqchip/irq-pruss-intc.c | 387 +++++++++++++++++-
.../interrupt-controller/ti-pruss.h | 27 ++
2 files changed, 396 insertions(+), 18 deletions(-)
create mode 100644 include/dt-bindings/interrupt-controller/ti-pruss.h
diff --git a/drivers/irqchip/irq-pruss-intc.c b/drivers/irqchip/irq-pruss-intc.c
index c1fd6c09f2f2..da4349df08c3 100644
--- a/drivers/irqchip/irq-pruss-intc.c
+++ b/drivers/irqchip/irq-pruss-intc.c
@@ -5,6 +5,8 @@
* Copyright (C) 2016-2019 Texas Instruments Incorporated - http://www.ti.com/
* Andrew F. Davis <afd@ti.com>
* Suman Anna <s-anna@ti.com>
+ *
+ * Copyright (C) 2019 David Lechner <david@lechnology.com>
*/
#include <linux/interrupt.h>
@@ -14,6 +16,14 @@
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
+#include <linux/pm_runtime.h>
+
+#include <dt-bindings/interrupt-controller/ti-pruss.h>
+
+/* The number of possible interrupt domains, see TI_PRUSS_INTC_DOMAIN_* in
+ * dt-bindings/interrupt-controller/ti-pruss.h
+ */
+#define NUM_TI_PRUSS_INTC_DOMAIN 5
/*
* Number of host interrupts reaching the main MPU sub-system. Note that this
@@ -25,6 +35,12 @@
/* minimum starting host interrupt number for MPU */
#define MIN_PRU_HOST_INT 2
+/* maximum number of host interrupts */
+#define MAX_PRU_HOST_INT 10
+
+/* maximum number of interrupt channels */
+#define MAX_PRU_CHANNELS 10
+
/* maximum number of system events */
#define MAX_PRU_SYS_EVENTS 64
@@ -57,27 +73,83 @@
#define PRU_INTC_HINLR(x) (0x1100 + (x) * 4)
#define PRU_INTC_HIER 0x1500
+/* CMR register bit-field macros */
+#define CMR_EVT_MAP_MASK 0xf
+#define CMR_EVT_MAP_BITS 8
+#define CMR_EVT_PER_REG 4
+
+/* HMR register bit-field macros */
+#define HMR_CH_MAP_MASK 0xf
+#define HMR_CH_MAP_BITS 8
+#define HMR_CH_PER_REG 4
+
/* HIPIR register bit-fields */
#define INTC_HIPIR_NONE_HINT 0x80000000
+/**
+ * struct pruss_intc_hwirq_data - additional metadata associated with a PRU
+ * system event
+ * @evtsel: The event select index (AM18xx only)
+ * @channel: The PRU INTC channel that the system event should be mapped to
+ * @host: The PRU INTC host that the channel should be mapped to
+ */
+struct pruss_intc_hwirq_data {
+ u8 evtsel;
+ u8 channel;
+ u8 host;
+};
+
+/**
+ * struct pruss_intc_map_record - keeps track of actual mapping state
+ * @value: The currently mapped value (evtsel, channel or host)
+ * @ref_count: Keeps track of number of current users of this resource
+ */
+struct pruss_intc_map_record {
+ u8 value;
+ u8 ref_count;
+};
+
+/**
+ * struct pruss_intc_domain - information specific to an external IRQ domain
+ * @hwirq_data: Table of additional mapping data received from device tree
+ * or PRU firmware
+ * @domain: irq domain
+ * @intc: the interrupt controller
+ * @id: Unique domain identifier (from device tree bindings)
+ */
+struct pruss_intc_domain {
+ struct pruss_intc_hwirq_data hwirq_data[MAX_PRU_SYS_EVENTS];
+ struct irq_domain *domain;
+ struct pruss_intc *intc;
+ u32 id;
+};
+
/**
* struct pruss_intc - PRUSS interrupt controller structure
+ * @domain: External interrupt domains
+ * @evtsel: Tracks the current state of CFGCHIP3[3].PRUSSEVTSEL (AM18xx only)
+ * @event_channel: Tracks the current state of system event to channel mappings
+ * @channel_host: Tracks the current state of channel to host mappings
* @irqs: kernel irq numbers corresponding to PRUSS host interrupts
* @base: base virtual address of INTC register space
* @irqchip: irq chip for this interrupt controller
- * @domain: irq domain for this interrupt controller
* @lock: mutex to serialize access to INTC
* @shared_intr: bit-map denoting if the MPU host interrupt is shared
* @invalid_intr: bit-map denoting if host interrupt is not connected to MPU
+ * @has_evtsel: indicates that the chip has an event select mux
*/
struct pruss_intc {
+ struct pruss_intc_domain domain[NUM_ISA_INTERRUPTS];
+ struct pruss_intc_map_record evtsel;
+ struct pruss_intc_map_record event_channel[MAX_PRU_SYS_EVENTS];
+ struct pruss_intc_map_record channel_host[MAX_PRU_CHANNELS];
unsigned int irqs[MAX_NUM_HOST_IRQS];
void __iomem *base;
struct irq_chip *irqchip;
- struct irq_domain *domain;
struct mutex lock; /* PRUSS INTC lock */
u16 shared_intr;
u16 invalid_intr;
+ bool has_evtsel;
};
static inline u32 pruss_intc_read_reg(struct pruss_intc *intc, unsigned int reg)
@@ -105,6 +177,172 @@ static int pruss_intc_check_write(struct pruss_intc *intc, unsigned int reg,
return 0;
}
+/**
+ * pruss_intc_map() - configure the PRUSS INTC
+ * @domain: pru intc domain pointer
+ * @hwirq: the system event number
+ *
+ * Configures the PRUSS INTC with the provided configuration from the one
+ * parsed in the xlate function. Any existing event to channel mappings or
+ * channel to host interrupt mappings are checked to make sure there are no
+ * conflicting configuration between both the PRU cores.
+ *
+ * Returns 0 on success, or a suitable error code otherwise
+ */
+static int pruss_intc_map(struct pruss_intc_domain *domain, unsigned long hwirq)
+{
+ struct pruss_intc *intc = domain->intc;
+ struct device* dev = intc->irqchip->parent_device;
+ u32 val;
+ int idx, ret;
+ u8 evtsel, ch, host;
+
+ if (hwirq >= MAX_PRU_SYS_EVENTS)
+ return -EINVAL;
+
+ mutex_lock(&intc->lock);
+
+ evtsel = domain->hwirq_data[hwirq].evtsel;
+ ch = domain->hwirq_data[hwirq].channel;
+ host = domain->hwirq_data[hwirq].host;
+
+ if (intc->has_evtsel && intc->evtsel.ref_count > 0 &&
+ intc->evtsel.value != evtsel) {
+ dev_err(dev, "event %lu (req. evtsel %d) already assigned to evtsel %d\n",
+ hwirq, evtsel, intc->evtsel.value);
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ /* check if sysevent already assigned */
+ if (intc->event_channel[hwirq].ref_count > 0 &&
+ intc->event_channel[hwirq].value != ch) {
+ dev_err(dev, "event %lu (req. channel %d) already assigned to channel %d\n",
+ hwirq, ch, intc->event_channel[hwirq].value);
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ /* check if channel already assigned */
+ if (intc->channel_host[ch].ref_count > 0 &&
+ intc->channel_host[ch].value != host) {
+ dev_err(dev, "channel %d (req. host %d) already assigned to host %d\n",
+ ch, host, intc->channel_host[ch].value);
+ ret = -EBUSY;
+ goto unlock;
+ }
+
+ if (++intc->evtsel.ref_count == 1) {
+ intc->evtsel.value = evtsel;
+
+ /* TODO: need to implement CFGCHIP3[3].PRUSSEVTSEL */
+ }
+
+ if (++intc->event_channel[hwirq].ref_count == 1) {
+ intc->event_channel[hwirq].value = ch;
+
+ /*
+ * configure channel map registers - each register holds map
+ * info for 4 events, with each event occupying the lower nibble
+ * in a register byte address in little-endian fashion
+ */
+ idx = hwirq / CMR_EVT_PER_REG;
+
+ val = pruss_intc_read_reg(intc, PRU_INTC_CMR(idx));
+ val &= ~(CMR_EVT_MAP_MASK <<
+ ((hwirq % CMR_EVT_PER_REG) * CMR_EVT_MAP_BITS));
+ val |= ch << ((hwirq % CMR_EVT_PER_REG) * CMR_EVT_MAP_BITS);
+ pruss_intc_write_reg(intc, PRU_INTC_CMR(idx), val);
+
+ dev_dbg(dev, "SYSEV%lu -> CH%d (CMR%d 0x%08x)\n", hwirq, ch,
+ idx, pruss_intc_read_reg(intc, PRU_INTC_CMR(idx)));
+
+ /* clear and enable system event */
+ pruss_intc_write_reg(intc, PRU_INTC_SICR, hwirq);
+ pruss_intc_write_reg(intc, PRU_INTC_EISR, hwirq);
+ }
+
+ if (++intc->channel_host[ch].ref_count == 1) {
+ intc->channel_host[ch].value = host;
+
+ /*
+ * set host map registers - each register holds map info for
+ * 4 channels, with each channel occupying the lower nibble in
+ * a register byte address in little-endian fashion
+ */
+ idx = ch / HMR_CH_PER_REG;
+
+ val = pruss_intc_read_reg(intc, PRU_INTC_HMR(idx));
+ val &= ~(HMR_CH_MAP_MASK <<
+ ((ch % HMR_CH_PER_REG) * HMR_CH_MAP_BITS));
+ val |= host << ((ch % HMR_CH_PER_REG) * HMR_CH_MAP_BITS);
+ pruss_intc_write_reg(intc, PRU_INTC_HMR(idx), val);
+
+ dev_dbg(dev, "CH%d -> HOST%d (HMR%d 0x%08x)\n", ch, host, idx,
+ pruss_intc_read_reg(intc, PRU_INTC_HMR(idx)));
+
+ /* enable host interrupts */
+ pruss_intc_write_reg(intc, PRU_INTC_HIEISR, host);
+ }
+
+ dev_info(dev, "mapped system_event = %lu channel = %d host = %d domain = %u\n",
+ hwirq, ch, host, domain->id);
+
+ /* global interrupt enable */
+ pruss_intc_write_reg(intc, PRU_INTC_GER, 1);
+
+ mutex_unlock(&intc->lock);
+ return 0;
+
+unlock:
+ mutex_unlock(&intc->lock);
+ return ret;
+}
+
+/**
+ * pruss_intc_unmap() - unconfigure the PRUSS INTC
+ * @domain: pru intc domain pointer
+ * @hwirq: the system event number
+ *
+ * Undo whatever was done in pruss_intc_map() for a PRU core.
+ * Mappings are reference counted, so resources are only disabled when there
+ * are no longer any users.
+ */
+static void pruss_intc_unmap(struct pruss_intc_domain *domain, unsigned long hwirq)
+{
+ struct pruss_intc *intc = domain->intc;
+ struct device* dev = intc->irqchip->parent_device;
+ u8 ch, host;
+
+ if (hwirq >= MAX_PRU_SYS_EVENTS)
+ return;
+
+ mutex_lock(&intc->lock);
+
+ ch = intc->event_channel[hwirq].value;
+ host = intc->channel_host[ch].value;
+
+ if (--intc->channel_host[ch].ref_count == 0) {
+ /* disable host interrupts */
+ pruss_intc_write_reg(intc, PRU_INTC_HIDISR, host);
+ }
+
+ if (--intc->event_channel[hwirq].ref_count == 0) {
+ /* disable system events */
+ pruss_intc_write_reg(intc, PRU_INTC_EICR, hwirq);
+ /* clear any pending status */
+ pruss_intc_write_reg(intc, PRU_INTC_SICR, hwirq);
+ }
+
+ if (intc->has_evtsel)
+ intc->evtsel.ref_count--;
+
+ dev_info(dev, "unmapped system_event = %lu channel = %d host = %d\n",
+ hwirq, ch, host);
+
+ mutex_unlock(&intc->lock);
+}
+
static void pruss_intc_init(struct pruss_intc *intc)
{
int i;
@@ -198,10 +436,83 @@ static int pruss_intc_irq_set_irqchip_state(struct irq_data *data,
return pruss_intc_check_write(intc, PRU_INTC_SICR, data->hwirq);
}
+static int pruss_intc_irq_domain_select(struct irq_domain *d,
+ struct irq_fwspec *fwspec,
+ enum irq_domain_bus_token bus_token)
+{
+ struct pruss_intc_domain *domain = d->host_data;
+ int num_cells = domain->intc->has_evtsel ? 5 : 4;
+ u32 domain_id;
+
+ if (!fwspec || fwspec->fwnode != domain->domain->fwnode)
+ return 0;
+
+ if (bus_token != DOMAIN_BUS_ANY && bus_token != domain->domain->bus_token)
+ return 0;
+
+ if (WARN_ON_ONCE(fwspec->param_count != num_cells))
+ return 0;
+
+ domain_id = fwspec->param[fwspec->param_count - 1];
+ if (domain_id != domain->id)
+ return 0;
+
+ return 1;
+}
+
+static int
+pruss_intc_irq_domain_xlate(struct irq_domain *d, struct device_node *node,
+ const u32 *intspec, unsigned int intsize,
+ unsigned long *out_hwirq, unsigned int *out_type)
+{
+ struct pruss_intc_domain *domain = d->host_data;
+ struct pruss_intc *intc = domain->intc;
+ int num_cells = intc->has_evtsel ? 5 : 4;
+ u32 sys_event, channel, host, domain_id;
+ u32 evtsel = 0;
+
+ if (WARN_ON_ONCE(intsize != num_cells))
+ return -EINVAL;
+
+ sys_event = intspec[0];
+ if (sys_event >= MAX_PRU_SYS_EVENTS)
+ return -EINVAL;
+
+ if (intc->has_evtsel)
+ evtsel = intspec[1];
+
+ channel = intspec[intsize - 3];
+ if (channel >= MAX_PRU_CHANNELS)
+ return -EINVAL;
+
+ host = intspec[intsize - 2];
+ if (host >= MAX_PRU_HOST_INT)
+ return -EINVAL;
+
+ domain_id = intspec[intsize - 1];
+ if (domain_id != domain->id)
+ return -EINVAL;
+
+ domain->hwirq_data[sys_event].evtsel = evtsel;
+ domain->hwirq_data[sys_event].channel = channel;
+ domain->hwirq_data[sys_event].host = host;
+
+ *out_hwirq = sys_event;
+ *out_type = IRQ_TYPE_NONE;
+
+ return 0;
+}
+
static int pruss_intc_irq_domain_map(struct irq_domain *d, unsigned int virq,
irq_hw_number_t hw)
{
- struct pruss_intc *intc = d->host_data;
+ struct pruss_intc_domain *domain = d->host_data;
+ struct pruss_intc *intc = domain->intc;
+ int err;
+
+ err = pruss_intc_map(domain, hw);
+ if (err < 0)
+ return err;
irq_set_chip_data(virq, intc);
irq_set_chip_and_handler(virq, intc->irqchip, handle_level_irq);
@@ -211,12 +522,17 @@ static int pruss_intc_irq_domain_map(struct irq_domain *d, unsigned int virq,
static void pruss_intc_irq_domain_unmap(struct irq_domain *d, unsigned int virq)
{
+ struct pruss_intc_domain *domain = d->host_data;
+ unsigned long hwirq = irqd_to_hwirq(irq_get_irq_data(virq));
+
irq_set_chip_and_handler(virq, NULL, NULL);
irq_set_chip_data(virq, NULL);
+ pruss_intc_unmap(domain, hwirq);
}
static const struct irq_domain_ops pruss_intc_irq_domain_ops = {
- .xlate = irq_domain_xlate_onecell,
+ .select = pruss_intc_irq_domain_select,
+ .xlate = pruss_intc_irq_domain_xlate,
.map = pruss_intc_irq_domain_map,
.unmap = pruss_intc_irq_domain_unmap,
};
@@ -245,7 +561,8 @@ static void pruss_intc_irq_handler(struct irq_desc *desc)
hipir = pruss_intc_read_reg(intc, PRU_INTC_HIPIR(i));
while (!(hipir & INTC_HIPIR_NONE_HINT)) {
hwirq = hipir & GENMASK(9, 0);
- virq = irq_linear_revmap(intc->domain, hwirq);
+ virq = irq_linear_revmap(
+ intc->domain[TI_PRUSS_INTC_DOMAIN_MCU].domain, hwirq);
/*
* NOTE: manually ACK any system events that do not have a
@@ -272,7 +589,8 @@ static int pruss_intc_probe(struct platform_device *pdev)
struct pruss_intc *intc;
struct resource *res;
struct irq_chip *irqchip;
- int i, irq, count;
+ int i, err, irq, count;
+ u32 num_cells;
u8 temp_intr[MAX_NUM_HOST_IRQS] = { 0 };
intc = devm_kzalloc(dev, sizeof(*intc), GFP_KERNEL);
@@ -323,13 +641,22 @@ static int pruss_intc_probe(struct platform_device *pdev)
}
}
+ err = of_property_read_u32(dev->of_node, "#interrupt-cells", &num_cells);
+ if (!err && num_cells == 5)
+ intc->has_evtsel = true;
+
mutex_init(&intc->lock);
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
+
pruss_intc_init(intc);
irqchip = devm_kzalloc(dev, sizeof(*irqchip), GFP_KERNEL);
- if (!irqchip)
- return -ENOMEM;
+ if (!irqchip) {
+ err = -ENOMEM;
+ goto fail_alloc;
+ }
irqchip->irq_ack = pruss_intc_irq_ack;
irqchip->irq_mask = pruss_intc_irq_mask;
@@ -338,14 +665,24 @@ static int pruss_intc_probe(struct platform_device *pdev)
irqchip->irq_release_resources = pruss_intc_irq_relres;
irqchip->irq_get_irqchip_state = pruss_intc_irq_get_irqchip_state;
irqchip->irq_set_irqchip_state = pruss_intc_irq_set_irqchip_state;
+ irqchip->parent_device = dev;
irqchip->name = dev_name(dev);
intc->irqchip = irqchip;
- /* always 64 events */
- intc->domain = irq_domain_add_linear(dev->of_node, MAX_PRU_SYS_EVENTS,
- &pruss_intc_irq_domain_ops, intc);
- if (!intc->domain)
- return -ENOMEM;
+ for (i = 0; i < NUM_TI_PRUSS_INTC_DOMAIN; i++) {
+ intc->domain[i].intc = intc;
+ intc->domain[i].id = i;
+ /* always 64 events */
+ intc->domain[i].domain = irq_domain_add_linear(dev->of_node,
+ MAX_PRU_SYS_EVENTS, &pruss_intc_irq_domain_ops,
+ &intc->domain[i]);
+ if (!intc->domain[i].domain) {
+ while (--i >= 0)
+ irq_domain_remove(intc->domain[i].domain);
+ err = -ENOMEM;
+ goto fail_alloc;
+ }
+ }
for (i = 0; i < MAX_NUM_HOST_IRQS; i++) {
irq = platform_get_irq_byname(pdev, irq_names[i]);
@@ -356,6 +693,7 @@ static int pruss_intc_probe(struct platform_device *pdev)
dev_err(dev, "platform_get_irq_byname failed for %s : %d\n",
irq_names[i], irq);
+ err = irq;
goto fail_irq;
}
@@ -372,13 +710,20 @@ static int pruss_intc_probe(struct platform_device *pdev)
irq_set_chained_handler_and_data(intc->irqs[i], NULL,
NULL);
}
- irq_domain_remove(intc->domain);
- return irq;
+ for (i = 0; i < NUM_TI_PRUSS_INTC_DOMAIN; i++)
+ irq_domain_remove(intc->domain[i].domain);
+
+fail_alloc:
+ pm_runtime_put(dev);
+ pm_runtime_disable(dev);
+
+ return err;
}
static int pruss_intc_remove(struct platform_device *pdev)
{
struct pruss_intc *intc = platform_get_drvdata(pdev);
+ struct device *dev = &pdev->dev;
unsigned int hwirq;
int i;
@@ -388,9 +733,15 @@ static int pruss_intc_remove(struct platform_device *pdev)
NULL);
}
- for (hwirq = 0; hwirq < MAX_PRU_SYS_EVENTS; hwirq++)
- irq_dispose_mapping(irq_find_mapping(intc->domain, hwirq));
- irq_domain_remove(intc->domain);
+ for (i = 0; i < NUM_TI_PRUSS_INTC_DOMAIN; i++) {
+ for (hwirq = 0; hwirq < MAX_PRU_SYS_EVENTS; hwirq++)
+ irq_dispose_mapping(irq_find_mapping(
+ intc->domain[i].domain, hwirq));
+ irq_domain_remove(intc->domain[i].domain);
+ }
+
+ pm_runtime_put(dev);
+ pm_runtime_disable(dev);
return 0;
}
diff --git a/include/dt-bindings/interrupt-controller/ti-pruss.h b/include/dt-bindings/interrupt-controller/ti-pruss.h
new file mode 100644
index 000000000000..326a68c31bce
--- /dev/null
+++ b/include/dt-bindings/interrupt-controller/ti-pruss.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+/*
+ * This header provides constants for the Texas Instruments Programmable
+ * Realtime Unit Subsystem (PRUSS) interrupt controller.
+ */
+
+#ifndef _DT_BINDINGS_INTERRUPT_CONTROLLER_TI_PRUSS_H
+#define _DT_BINDINGS_INTERRUPT_CONTROLLER_TI_PRUSS_H
+
+/* interrupt specifier for optional cell 1 */
+
+#define TI_PRUSS_INTC_EVTSEL_ANY 0xffffffff
+
+/* interrupt specifier for cell #interrupt-cells - 1 */
+
+/* host interrupt is connected to PRU cores, e.g. host events 0 and 1 */
+#define TI_PRUSS_INTC_DOMAIN_PRU 0
+/* host interrupt is connected to MCU's interrupt controller */
+#define TI_PRUSS_INTC_DOMAIN_MCU 1
+/* host interrupt is connected to DSP's interrupt controller */
+#define TI_PRUSS_INTC_DOMAIN_DSP 2
+/* host interrupt is connected to the auxillary PRU cores */
+#define TI_PRUSS_INTC_DOMAIN_RTU_PRU 3
+/* host interrupt is connected to the task managers */
+#define TI_PRUSS_INTC_DOMAIN_TASK 4
+
+#endif /* _DT_BINDINGS_INTERRUPT_CONTROLLER_TI_PRUSS_H */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 5/6] tty: serial: Add linflexuart driver for S32V234
From: Will Deacon @ 2019-08-08 17:17 UTC (permalink / raw)
To: Stefan-gabriel Mirea
Cc: corbet@lwn.net, robh+dt@kernel.org, mark.rutland@arm.com,
gregkh@linuxfoundation.org, catalin.marinas@arm.com,
shawnguo@kernel.org, Leo Li, jslaby@suse.com,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-serial@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Cosmin Stefan Stoica,
Larisa Ileana Grigore
In-Reply-To: <VI1PR0402MB28635661A4A294EC6F01095EDFD70@VI1PR0402MB2863.eurprd04.prod.outlook.com>
Hi,
On Thu, Aug 08, 2019 at 12:47:00PM +0000, Stefan-gabriel Mirea wrote:
> On 8/8/2019 11:08 AM, Will Deacon wrote:
> > On Fri, Aug 02, 2019 at 07:47:23PM +0000, Stefan-gabriel Mirea wrote:
> >> + linflex,<addr>
> >> + Use early console provided by Freescale LinFlex UART
> >> + serial driver for NXP S32V234 SoCs. A valid base
> >> + address must be provided, and the serial port must
> >> + already be setup and configured.
> >
> > Why isn't earlycon= sufficient for this?
>
> "earlycon=" is not actually supported. I will fix this in the next
> version by adding a /chosen/stdout-path to the dts. The compatible
> string provided to OF_EARLYCON_DECLARE will also be changed from
> "fsl,s32v234-linflexuart" to "fsl,s32-linflexuart" to match the one in
> the device tree nodes. I missed this after importing a rename from our
> codebase.
>
> Should I remove this addition from kernel-parameters.txt after that?
Yes, if you can use earlycon instead, then you can drop your custom option
entirely and therefore there's no need to document it either.
Will
^ permalink raw reply
* [PATCH v4 1/3] dt-bindings: vendor-prefixes: Add Anvo-Systems
From: Krzysztof Kozlowski @ 2019-08-08 17:26 UTC (permalink / raw)
To: Schrempf Frieder, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, devicetree, linux-kernel, linux-arm-kernel
Cc: notify, Krzysztof Kozlowski
Add vendor prefix for Anvo-Systems Dresden GmbH.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
Changes since v3:
1. Add Rob's tag,
2. Remove Admatec (not needed anymore).
Changes since v2:
1. Use admatecde vendor prefix.
2. Add Anvo-Systems Dresden GmbH.
Changes since v1:
New patch
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 6992bbbbffab..519889f5aec8 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -81,6 +81,8 @@ patternProperties:
description: Analogix Semiconductor, Inc.
"^andestech,.*":
description: Andes Technology Corporation
+ "^anvo,.*":
+ description: Anvo-Systems Dresden GmbH
"^apm,.*":
description: Applied Micro Circuits Corporation (APM)
"^aptina,.*":
--
2.17.1
^ permalink raw reply related
* [PATCH v4 2/3] dt-bindings: eeprom: at25: Add Anvo ANV32E61W
From: Krzysztof Kozlowski @ 2019-08-08 17:26 UTC (permalink / raw)
To: Schrempf Frieder, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, devicetree, linux-kernel, linux-arm-kernel
Cc: notify, Krzysztof Kozlowski
In-Reply-To: <20190808172616.11728-1-krzk@kernel.org>
Document the compatible for ANV32E61W EEPROM chip.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
---
New patch
---
Documentation/devicetree/bindings/eeprom/at25.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/eeprom/at25.txt b/Documentation/devicetree/bindings/eeprom/at25.txt
index b3bde97dc199..42577dd113dd 100644
--- a/Documentation/devicetree/bindings/eeprom/at25.txt
+++ b/Documentation/devicetree/bindings/eeprom/at25.txt
@@ -3,6 +3,7 @@ EEPROMs (SPI) compatible with Atmel at25.
Required properties:
- compatible : Should be "<vendor>,<type>", and generic value "atmel,at25".
Example "<vendor>,<type>" values:
+ "anvo,anv32e61w"
"microchip,25lc040"
"st,m95m02"
"st,m95256"
--
2.17.1
^ permalink raw reply related
* [PATCH v4 3/3] ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards
From: Krzysztof Kozlowski @ 2019-08-08 17:26 UTC (permalink / raw)
To: Schrempf Frieder, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, devicetree, linux-kernel, linux-arm-kernel
Cc: notify, Krzysztof Kozlowski
In-Reply-To: <20190808172616.11728-1-krzk@kernel.org>
Add support for i.MX6UL modules from Kontron Electronics GmbH (before
acquisition: Exceet Electronics) and evalkit boards based on it:
1. N6310 SOM: i.MX6 UL System-on-Module, a 25x25 mm solderable module
(LGA pads and pin castellations) with 256 MB RAM, 1 MB NOR-Flash,
256 MB NAND and other interfaces,
2. N6310 S: evalkit, w/wo eMMC, without display,
3. N6310 S 43: evalkit with 4.3" display,
The work is based on Exceet/Kontron source code (GPLv2) with numerous
changes:
1. Reorganize files,
2. Rename Exceet -> Kontron,
3. Rename models/compatibles to match newest Kontron product naming,
4. Fix coding style errors and adjust to device tree coding guidelines,
5. Fix DTC warnings,
6. Extend compatibles so eval boards inherit the SoM compatible,
7. Use defines instead of GPIO and interrupt flag values,
8. Use proper vendor compatible for Macronix SPI NOR,
9. Replace deprecated bindings with proper ones,
10. Sort nodes alphabetically,
11. Remove Admatec display nodes (not yet supported).
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
---
Changes since v3, after Shawn's review:
1. Split bindings update to patch 2/3,
2. Remove unsupported displays from (Admatec),
3. Remove N6310 S 50 board (same as N6310 S 43 since there is no Admatec
display),
4. Order iomux nodes by name, minor cleanup,
5. Use wakeup-source instead of enable-sdio-wakeup,
6. Add review tags.
Changes since v2, after Fabio's review:
1. Add "imx6ul" compatible to board name (that's what I understood from
review),
2. Add vendor/device prefix to eeprom and document the compatible,
3. Use "admatecde" as vendor compatible to avoid confusion with Admatec
AG in Switzerland (also making LCD panels),
4. Use generic names for nodes,
5. Use IRQ_TYPE_LEVEL_LOW,
6. Move iomux to the end of files,
7. Remove regulators node (include regulators in top level),
8. Remove cpu clock-frequency,
9. Other minor fixes pointed by Fabio.
Changes since v1, after Frieder's review:
1. Remove unneeded license notes,
2. Add Kontron copyright (2018),
3. Rename the files/models/compatibles to new naming - N6310,
4. Remove unneeded CPU operating points override,
5. Switch regulator nodes into simple children nodes without addresses
(so not simple bus),
6. Use proper vendor compatible for Macronix SPI NOR.
---
.../devicetree/bindings/arm/fsl.yaml | 3 +
arch/arm/boot/dts/Makefile | 2 +
.../boot/dts/imx6ul-kontron-n6310-s-43.dts | 102 +++++
arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts | 420 ++++++++++++++++++
.../boot/dts/imx6ul-kontron-n6310-som.dtsi | 134 ++++++
5 files changed, 661 insertions(+)
create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
create mode 100644 arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 7294ac36f4c0..d07b3c06d7cf 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -161,6 +161,9 @@ properties:
items:
- enum:
- fsl,imx6ul-14x14-evk # i.MX6 UltraLite 14x14 EVK Board
+ - kontron,imx6ul-n6310-som # Kontron N6310 SOM
+ - kontron,imx6ul-n6310-s # Kontron N6310 S Board
+ - kontron,imx6ul-n6310-s-43 # Kontron N6310 S 43 Board
- const: fsl,imx6ul
- description: i.MX6ULL based Boards
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9159fa2cea90..747eef501f95 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -569,6 +569,8 @@ dtb-$(CONFIG_SOC_IMX6UL) += \
imx6ul-geam.dtb \
imx6ul-isiot-emmc.dtb \
imx6ul-isiot-nand.dtb \
+ imx6ul-kontron-n6310-s.dtb \
+ imx6ul-kontron-n6310-s-43.dtb \
imx6ul-liteboard.dtb \
imx6ul-opos6uldev.dtb \
imx6ul-pico-hobbit.dtb \
diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
new file mode 100644
index 000000000000..5bad29683cc3
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-s-43.dts
@@ -0,0 +1,102 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 exceet electronics GmbH
+ * Copyright (C) 2018 Kontron Electronics GmbH
+ * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
+ */
+
+#include "imx6ul-kontron-n6310-s.dts"
+
+/ {
+ model = "Kontron N6310 S 43";
+ compatible = "kontron,imx6ul-n6310-s-43", "kontron,imx6ul-n6310-s",
+ "kontron,imx6ul-n6310-som", "fsl,imx6ul";
+
+ backlight {
+ compatible = "pwm-backlight";
+ pwms = <&pwm7 0 5000000>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ status = "okay";
+ };
+};
+
+&i2c4 {
+ touchscreen@5d {
+ compatible = "goodix,gt928";
+ reg = <0x5d>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_cap_touch>;
+ interrupt-parent = <&gpio5>;
+ interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
+ reset-gpios = <&gpio5 8 GPIO_ACTIVE_HIGH>;
+ irq-gpios = <&gpio5 6 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&lcdif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lcdif_dat &pinctrl_lcdif_ctrl>;
+ /* Leave status disabled because of missing display panel node */
+};
+
+&pwm7 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm7>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_cap_touch: captouchgrp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER6__GPIO5_IO06 0x1b0b0 /* Touch Interrupt */
+ MX6UL_PAD_SNVS_TAMPER7__GPIO5_IO07 0x1b0b0 /* Touch Reset */
+ MX6UL_PAD_SNVS_TAMPER8__GPIO5_IO08 0x1b0b0 /* Touch Wake */
+ >;
+ };
+
+ pinctrl_lcdif_ctrl: lcdifctrlgrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_CLK__LCDIF_CLK 0x79
+ MX6UL_PAD_LCD_ENABLE__LCDIF_ENABLE 0x79
+ MX6UL_PAD_LCD_HSYNC__LCDIF_HSYNC 0x79
+ MX6UL_PAD_LCD_VSYNC__LCDIF_VSYNC 0x79
+ MX6UL_PAD_LCD_RESET__LCDIF_RESET 0x79
+ >;
+ };
+
+ pinctrl_lcdif_dat: lcdifdatgrp {
+ fsl,pins = <
+ MX6UL_PAD_LCD_DATA00__LCDIF_DATA00 0x79
+ MX6UL_PAD_LCD_DATA01__LCDIF_DATA01 0x79
+ MX6UL_PAD_LCD_DATA02__LCDIF_DATA02 0x79
+ MX6UL_PAD_LCD_DATA03__LCDIF_DATA03 0x79
+ MX6UL_PAD_LCD_DATA04__LCDIF_DATA04 0x79
+ MX6UL_PAD_LCD_DATA05__LCDIF_DATA05 0x79
+ MX6UL_PAD_LCD_DATA06__LCDIF_DATA06 0x79
+ MX6UL_PAD_LCD_DATA07__LCDIF_DATA07 0x79
+ MX6UL_PAD_LCD_DATA08__LCDIF_DATA08 0x79
+ MX6UL_PAD_LCD_DATA09__LCDIF_DATA09 0x79
+ MX6UL_PAD_LCD_DATA10__LCDIF_DATA10 0x79
+ MX6UL_PAD_LCD_DATA11__LCDIF_DATA11 0x79
+ MX6UL_PAD_LCD_DATA12__LCDIF_DATA12 0x79
+ MX6UL_PAD_LCD_DATA13__LCDIF_DATA13 0x79
+ MX6UL_PAD_LCD_DATA14__LCDIF_DATA14 0x79
+ MX6UL_PAD_LCD_DATA15__LCDIF_DATA15 0x79
+ MX6UL_PAD_LCD_DATA16__LCDIF_DATA16 0x79
+ MX6UL_PAD_LCD_DATA17__LCDIF_DATA17 0x79
+ MX6UL_PAD_LCD_DATA18__LCDIF_DATA18 0x79
+ MX6UL_PAD_LCD_DATA19__LCDIF_DATA19 0x79
+ MX6UL_PAD_LCD_DATA20__LCDIF_DATA20 0x79
+ MX6UL_PAD_LCD_DATA21__LCDIF_DATA21 0x79
+ MX6UL_PAD_LCD_DATA22__LCDIF_DATA22 0x79
+ MX6UL_PAD_LCD_DATA23__LCDIF_DATA23 0x79
+ >;
+ };
+
+ pinctrl_pwm7: pwm7grp {
+ fsl,pins = <
+ MX6UL_PAD_CSI_VSYNC__PWM7_OUT 0x110b0
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts b/arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
new file mode 100644
index 000000000000..0205fd56d975
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-s.dts
@@ -0,0 +1,420 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 exceet electronics GmbH
+ * Copyright (C) 2018 Kontron Electronics GmbH
+ * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
+ */
+
+/dts-v1/;
+
+#include "imx6ul-kontron-n6310-som.dtsi"
+
+/ {
+ model = "Kontron N6310 S";
+ compatible = "kontron,imx6ul-n6310-s", "kontron,imx6ul-n6310-som",
+ "fsl,imx6ul";
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_leds>;
+
+ led1 {
+ label = "debug-led1";
+ gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ linux,default-trigger = "heartbeat";
+ };
+
+ led2 {
+ label = "debug-led2";
+ gpios = <&gpio5 3 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+
+ led3 {
+ label = "debug-led3";
+ gpios = <&gpio5 2 GPIO_ACTIVE_LOW>;
+ default-state = "off";
+ };
+ };
+
+ pwm-beeper {
+ compatible = "pwm-beeper";
+ pwms = <&pwm8 0 5000>;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ reg_usb_otg1_vbus: regulator-usb-otg1-vbus {
+ compatible = "regulator-fixed";
+ regulator-name = "usb_otg1_vbus";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ gpio = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_vref_adc: regulator-vref-adc {
+ compatible = "regulator-fixed";
+ regulator-name = "vref-adc";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+};
+
+&adc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc1>;
+ num-channels = <3>;
+ vref-supply = <®_vref_adc>;
+ status = "okay";
+};
+
+&can2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+ status = "okay";
+};
+
+&ecspi1 {
+ cs-gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ status = "okay";
+
+ eeprom@0 {
+ compatible = "anvo,anv32e61w", "atmel,at25";
+ reg = <0>;
+ spi-max-frequency = <20000000>;
+ spi-cpha;
+ spi-cpol;
+ pagesize = <1>;
+ size = <8192>;
+ address-width = <16>;
+ };
+};
+
+&fec1 {
+ pinctrl-0 = <&pinctrl_enet1>;
+ /delete-node/ mdio;
+};
+
+&fec2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet2 &pinctrl_enet2_mdio>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy2>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy@1 {
+ reg = <1>;
+ micrel,led-mode = <0>;
+ clocks = <&clks IMX6UL_CLK_ENET_REF>;
+ clock-names = "rmii-ref";
+ };
+
+ ethphy2: ethernet-phy@2 {
+ reg = <2>;
+ micrel,led-mode = <0>;
+ clocks = <&clks IMX6UL_CLK_ENET2_REF>;
+ clock-names = "rmii-ref";
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ status = "okay";
+};
+
+&i2c4 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ status = "okay";
+
+ rtc@32 {
+ compatible = "epson,rx8900";
+ reg = <0x32>;
+ };
+};
+
+&pwm8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm8>;
+ status = "okay";
+};
+
+&snvs_poweroff {
+ status = "okay";
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ linux,rs485-enabled-at-boot-time;
+ rs485-rx-during-tx;
+ rs485-rts-active-low;
+ uart-has-rtscts;
+ status = "okay";
+};
+
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ fsl,uart-has-rtscts;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ status = "okay";
+};
+
+&usbotg1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbotg1>;
+ dr_mode = "otg";
+ srp-disable;
+ hnp-disable;
+ adp-disable;
+ vbus-supply = <®_usb_otg1_vbus>;
+ status = "okay";
+};
+
+&usbotg2 {
+ dr_mode = "host";
+ disable-over-current;
+ status = "okay";
+};
+
+&usdhc1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ cd-gpios = <&gpio1 19 GPIO_ACTIVE_LOW>;
+ keep-power-in-suspend;
+ wakeup-source;
+ vmmc-supply = <®_3v3>;
+ voltage-ranges = <3300 3300>;
+ no-1-8-v;
+ status = "okay";
+};
+
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>;
+ non-removable;
+ keep-power-in-suspend;
+ wakeup-source;
+ vmmc-supply = <®_3v3>;
+ voltage-ranges = <3300 3300>;
+ no-1-8-v;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-0 = <&pinctrl_reset_out &pinctrl_gpio>;
+
+ pinctrl_adc1: adc1grp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO02__GPIO1_IO02 0xb0
+ MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0xb0
+ MX6UL_PAD_GPIO1_IO08__GPIO1_IO08 0xb0
+ >;
+ };
+
+ /* FRAM */
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX6UL_PAD_CSI_DATA07__ECSPI1_MISO 0x100b1
+ MX6UL_PAD_CSI_DATA06__ECSPI1_MOSI 0x100b1
+ MX6UL_PAD_CSI_DATA04__ECSPI1_SCLK 0x100b1
+ MX6UL_PAD_CSI_DATA05__GPIO4_IO26 0x100b1 /* ECSPI1-CS1 */
+ >;
+ };
+
+ pinctrl_enet2: enet2grp {
+ fsl,pins = <
+ MX6UL_PAD_ENET2_RX_EN__ENET2_RX_EN 0x1b0b0
+ MX6UL_PAD_ENET2_RX_ER__ENET2_RX_ER 0x1b0b0
+ MX6UL_PAD_ENET2_RX_DATA0__ENET2_RDATA00 0x1b0b0
+ MX6UL_PAD_ENET2_RX_DATA1__ENET2_RDATA01 0x1b0b0
+ MX6UL_PAD_ENET2_TX_EN__ENET2_TX_EN 0x1b0b0
+ MX6UL_PAD_ENET2_TX_DATA0__ENET2_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET2_TX_DATA1__ENET2_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET2_TX_CLK__ENET2_REF_CLK2 0x4001b009
+ >;
+ };
+
+ pinctrl_enet2_mdio: enet2mdiogrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__ENET2_MDC 0x1b0b0
+ MX6UL_PAD_GPIO1_IO06__ENET2_MDIO 0x1b0b0
+ >;
+ };
+
+ pinctrl_flexcan2: flexcan2grp{
+ fsl,pins = <
+ MX6UL_PAD_UART2_RTS_B__FLEXCAN2_RX 0x1b020
+ MX6UL_PAD_UART2_CTS_B__FLEXCAN2_TX 0x1b020
+ >;
+ };
+
+ pinctrl_gpio: gpiogrp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER5__GPIO5_IO05 0x1b0b0 /* DOUT1 */
+ MX6UL_PAD_SNVS_TAMPER4__GPIO5_IO04 0x1b0b0 /* DIN1 */
+ MX6UL_PAD_SNVS_TAMPER1__GPIO5_IO01 0x1b0b0 /* DOUT2 */
+ MX6UL_PAD_SNVS_TAMPER0__GPIO5_IO00 0x1b0b0 /* DIN2 */
+ >;
+ };
+
+ pinctrl_gpio_leds: gpioledsgrp {
+ fsl,pins = <
+ MX6UL_PAD_UART5_TX_DATA__GPIO1_IO30 0x1b0b0 /* LED H14 */
+ MX6UL_PAD_SNVS_TAMPER3__GPIO5_IO03 0x1b0b0 /* LED H15 */
+ MX6UL_PAD_SNVS_TAMPER2__GPIO5_IO02 0x1b0b0 /* LED H16 */
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX6UL_PAD_CSI_PIXCLK__I2C1_SCL 0x4001b8b0
+ MX6UL_PAD_CSI_MCLK__I2C1_SDA 0x4001b8b0
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX6UL_PAD_UART2_TX_DATA__I2C4_SCL 0x4001f8b0
+ MX6UL_PAD_UART2_RX_DATA__I2C4_SDA 0x4001f8b0
+ >;
+ };
+
+ pinctrl_pwm8: pwm8grp {
+ fsl,pins = <
+ MX6UL_PAD_CSI_HSYNC__PWM8_OUT 0x110b0
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX6UL_PAD_UART1_TX_DATA__UART1_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART1_RX_DATA__UART1_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_DATA04__UART2_DCE_TX 0x1b0b1
+ MX6UL_PAD_NAND_DATA05__UART2_DCE_RX 0x1b0b1
+ MX6UL_PAD_NAND_DATA06__UART2_DCE_CTS 0x1b0b1
+ /*
+ * mux unused RTS to make sure it doesn't cause
+ * any interrupts when it is undefined
+ */
+ MX6UL_PAD_NAND_DATA07__UART2_DCE_RTS 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX6UL_PAD_UART3_TX_DATA__UART3_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART3_RX_DATA__UART3_DCE_RX 0x1b0b1
+ MX6UL_PAD_UART3_CTS_B__UART3_DCE_CTS 0x1b0b1
+ MX6UL_PAD_UART3_RTS_B__UART3_DCE_RTS 0x1b0b1
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX6UL_PAD_UART4_TX_DATA__UART4_DCE_TX 0x1b0b1
+ MX6UL_PAD_UART4_RX_DATA__UART4_DCE_RX 0x1b0b1
+ >;
+ };
+
+ pinctrl_usbotg1: usbotg1 {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO04__GPIO1_IO04 0x1b0b0
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX6UL_PAD_SD1_CMD__USDHC1_CMD 0x17059
+ MX6UL_PAD_SD1_CLK__USDHC1_CLK 0x10059
+ MX6UL_PAD_SD1_DATA0__USDHC1_DATA0 0x17059
+ MX6UL_PAD_SD1_DATA1__USDHC1_DATA1 0x17059
+ MX6UL_PAD_SD1_DATA2__USDHC1_DATA2 0x17059
+ MX6UL_PAD_SD1_DATA3__USDHC1_DATA3 0x17059
+ MX6UL_PAD_UART1_RTS_B__GPIO1_IO19 0x100b1 /* SD1_CD */
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x10059
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x17059
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x17059
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x17059
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x17059
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x17059
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x100b9
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x170b9
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x170b9
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x170b9
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x170b9
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170b9
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_RE_B__USDHC2_CLK 0x100f9
+ MX6UL_PAD_NAND_WE_B__USDHC2_CMD 0x170f9
+ MX6UL_PAD_NAND_DATA00__USDHC2_DATA0 0x170f9
+ MX6UL_PAD_NAND_DATA01__USDHC2_DATA1 0x170f9
+ MX6UL_PAD_NAND_DATA02__USDHC2_DATA2 0x170f9
+ MX6UL_PAD_NAND_DATA03__USDHC2_DATA3 0x170f9
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO09__WDOG1_WDOG_ANY 0x30b0
+ >;
+ };
+};
diff --git a/arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi b/arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi
new file mode 100644
index 000000000000..a896b2348dd2
--- /dev/null
+++ b/arch/arm/boot/dts/imx6ul-kontron-n6310-som.dtsi
@@ -0,0 +1,134 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2017 exceet electronics GmbH
+ * Copyright (C) 2018 Kontron Electronics GmbH
+ * Copyright (c) 2019 Krzysztof Kozlowski <krzk@kernel.org>
+ */
+
+#include "imx6ul.dtsi"
+#include <dt-bindings/gpio/gpio.h>
+
+/ {
+ model = "Kontron N6310 SOM";
+ compatible = "kontron,imx6ul-n6310-som", "fsl,imx6ul";
+
+ memory@80000000 {
+ reg = <0x80000000 0x10000000>;
+ device_type = "memory";
+ };
+};
+
+&ecspi2 {
+ cs-gpios = <&gpio4 22 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi2>;
+ status = "okay";
+
+ spi-flash@0 {
+ compatible = "mxicy,mx25v8035f", "jedec,spi-nor";
+ spi-max-frequency = <50000000>;
+ reg = <0>;
+ };
+};
+
+&fec1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_enet1 &pinctrl_enet1_mdio>;
+ phy-mode = "rmii";
+ phy-handle = <ðphy1>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy1: ethernet-phy@1 {
+ reg = <1>;
+ micrel,led-mode = <0>;
+ clocks = <&clks IMX6UL_CLK_ENET_REF>;
+ clock-names = "rmii-ref";
+ };
+ };
+};
+
+&fec2 {
+ phy-mode = "rmii";
+ status = "disabled";
+};
+
+&qspi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_qspi>;
+ status = "okay";
+
+ spi-flash@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "spi-nand";
+ spi-max-frequency = <108000000>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ reg = <0>;
+
+ partition@0 {
+ label = "ubi1";
+ reg = <0x00000000 0x08000000>;
+ };
+
+ partition@8000000 {
+ label = "ubi2";
+ reg = <0x08000000 0x08000000>;
+ };
+ };
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reset_out>;
+
+ pinctrl_ecspi2: ecspi2grp {
+ fsl,pins = <
+ MX6UL_PAD_CSI_DATA03__ECSPI2_MISO 0x100b1
+ MX6UL_PAD_CSI_DATA02__ECSPI2_MOSI 0x100b1
+ MX6UL_PAD_CSI_DATA00__ECSPI2_SCLK 0x100b1
+ MX6UL_PAD_CSI_DATA01__GPIO4_IO22 0x100b1
+ >;
+ };
+
+ pinctrl_enet1: enet1grp {
+ fsl,pins = <
+ MX6UL_PAD_ENET1_RX_EN__ENET1_RX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_RX_ER__ENET1_RX_ER 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA0__ENET1_RDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_RX_DATA1__ENET1_RDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_EN__ENET1_TX_EN 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA0__ENET1_TDATA00 0x1b0b0
+ MX6UL_PAD_ENET1_TX_DATA1__ENET1_TDATA01 0x1b0b0
+ MX6UL_PAD_ENET1_TX_CLK__ENET1_REF_CLK1 0x4001b009
+ >;
+ };
+
+ pinctrl_enet1_mdio: enet1mdiogrp {
+ fsl,pins = <
+ MX6UL_PAD_GPIO1_IO07__ENET1_MDC 0x1b0b0
+ MX6UL_PAD_GPIO1_IO06__ENET1_MDIO 0x1b0b0
+ >;
+ };
+
+ pinctrl_qspi: qspigrp {
+ fsl,pins = <
+ MX6UL_PAD_NAND_WP_B__QSPI_A_SCLK 0x70a1
+ MX6UL_PAD_NAND_READY_B__QSPI_A_DATA00 0x70a1
+ MX6UL_PAD_NAND_CE0_B__QSPI_A_DATA01 0x70a1
+ MX6UL_PAD_NAND_CE1_B__QSPI_A_DATA02 0x70a1
+ MX6UL_PAD_NAND_CLE__QSPI_A_DATA03 0x70a1
+ MX6UL_PAD_NAND_DQS__QSPI_A_SS0_B 0x70a1
+ >;
+ };
+
+ pinctrl_reset_out: rstoutgrp {
+ fsl,pins = <
+ MX6UL_PAD_SNVS_TAMPER9__GPIO5_IO09 0x1b0b0
+ >;
+ };
+};
--
2.17.1
^ permalink raw reply related
* [PATCH] nds32: remove unneeded clean-files for DTB
From: Masahiro Yamada @ 2019-08-08 17:30 UTC (permalink / raw)
To: Greentime Hu, Vincent Chen
Cc: Masahiro Yamada, Mark Rutland, Rob Herring, devicetree,
linux-kernel
These patterns are cleaned-up by the top-level Makefile
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
arch/nds32/boot/dts/Makefile | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/nds32/boot/dts/Makefile b/arch/nds32/boot/dts/Makefile
index fff8ade7a84f..f84bd529b6fd 100644
--- a/arch/nds32/boot/dts/Makefile
+++ b/arch/nds32/boot/dts/Makefile
@@ -5,5 +5,3 @@ else
BUILTIN_DTB :=
endif
obj-$(CONFIG_OF) += $(BUILTIN_DTB)
-
-clean-files := *.dtb *.dtb.S
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 3/8] of/fdt: add function to get the SoC wide DMA addressable memory size
From: Nicolas Saenz Julienne @ 2019-08-08 17:30 UTC (permalink / raw)
To: Rob Herring
Cc: phill, devicetree,
moderated list:BROADCOM BCM2835 ARM ARCHITECTURE,
Florian Fainelli, Will Deacon, Eric Anholt, Marc Zyngier,
Catalin Marinas, Frank Rowand, linux-kernel@vger.kernel.org,
linux-mm, Linux IOMMU, Matthias Brugger, wahrenst, Andrew Morton,
Robin Murphy, Christoph Hellwig,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE, Marek
In-Reply-To: <CAL_JsqJS6XBSc8DuK2sJApHtY4nCSFpLezf003YMD75THLHAqg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4552 bytes --]
On Thu, 2019-08-08 at 09:02 -0600, Rob Herring wrote:
> On Tue, Aug 6, 2019 at 12:12 PM Nicolas Saenz Julienne
> <nsaenzjulienne@suse.de> wrote:
> > Hi Rob,
> >
> > On Mon, 2019-08-05 at 13:23 -0600, Rob Herring wrote:
> > > On Mon, Aug 5, 2019 at 10:03 AM Nicolas Saenz Julienne
> > > <nsaenzjulienne@suse.de> wrote:
> > > > Hi Rob,
> > > > Thanks for the review!
> > > >
> > > > On Fri, 2019-08-02 at 11:17 -0600, Rob Herring wrote:
> > > > > On Wed, Jul 31, 2019 at 9:48 AM Nicolas Saenz Julienne
> > > > > <nsaenzjulienne@suse.de> wrote:
> > > > > > Some SoCs might have multiple interconnects each with their own DMA
> > > > > > addressing limitations. This function parses the 'dma-ranges' on
> > > > > > each of
> > > > > > them and tries to guess the maximum SoC wide DMA addressable memory
> > > > > > size.
> > > > > >
> > > > > > This is specially useful for arch code in order to properly setup
> > > > > > CMA
> > > > > > and memory zones.
> > > > >
> > > > > We already have a way to setup CMA in reserved-memory, so why is this
> > > > > needed for that?
> > > >
> > > > Correct me if I'm wrong but I got the feeling you got the point of the
> > > > patch
> > > > later on.
> > >
> > > No, for CMA I don't. Can't we already pass a size and location for CMA
> > > region under /reserved-memory. The only advantage here is perhaps the
> > > CMA range could be anywhere in the DMA zone vs. a fixed location.
> >
> > Now I get it, sorry I wasn't aware of that interface.
> >
> > Still, I'm not convinced it matches RPi's use case as this would hard-code
> > CMA's size. Most people won't care, but for the ones that do, it's nicer to
> > change the value from the kernel command line than editing the dtb.
>
> Sure, I fully agree and am not a fan of the CMA DT overlays I've seen.
>
> > I get that
> > if you need to, for example, reserve some memory for the video to work, it's
> > silly not to hard-code it. Yet due to the board's nature and users base I
> > say
> > it's important to favor flexibility. It would also break compatibility with
> > earlier versions of the board and diverge from the downstream kernel
> > behaviour.
> > Which is a bigger issue than it seems as most users don't always understand
> > which kernel they are running and unknowingly copy configuration options
> > from
> > forums.
> >
> > As I also need to know the DMA addressing limitations to properly configure
> > memory zones and dma-direct. Setting up the proper CMA constraints during
> > the
> > arch's init will be trivial anyway.
>
> It was really just commentary on commit text as for CMA alone we have
> a solution already. I agree on the need for zones.
Ok, understood :)
> > > > > IMO, I'd just do:
> > > > >
> > > > > if (of_fdt_machine_is_compatible(blob, "brcm,bcm2711"))
> > > > > dma_zone_size = XX;
> > > > >
> > > > > 2 lines of code is much easier to maintain than 10s of incomplete code
> > > > > and is clearer who needs this. Maybe if we have dozens of SoCs with
> > > > > this problem we should start parsing dma-ranges.
> > > >
> > > > FYI that's what arm32 is doing at the moment and was my first instinct.
> > > > But
> > > > it
> > > > seems that arm64 has been able to survive so far without any machine
> > > > specific
> > > > code and I have the feeling Catalin and Will will not be happy about
> > > > this
> > > > solution. Am I wrong?
> > >
> > > No doubt. I'm fine if the 2 lines live in drivers/of/.
> > >
> > > Note that I'm trying to reduce the number of early_init_dt_scan_*
> > > calls from arch code into the DT code so there's more commonality
> > > across architectures in the early DT scans. So ideally, this can all
> > > be handled under early_init_dt_scan() call.
> >
> > How does this look? (I'll split it in two patches and add a comment
> > explaining
> > why dt_dma_zone_size is needed)
> >
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index f2444c61a136..1395be40b722 100644
> > --- a/drivers/of/fdt.c
> > +++ b/drivers/of/fdt.c
> > @@ -30,6 +30,8 @@
> >
> > #include "of_private.h"
> >
> > +u64 dt_dma_zone_size __ro_after_init;
>
> Avoiding a call from arch code by just having a variable isn't really
> better. I'd rather see a common, non DT specific variable that can be
> adjusted. Something similar to initrd_start/end. Then the arch code
> doesn't have to care what hardware description code adjusted the
> value.
Way better, I'll update it.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] interconnect: qcom: Add OSM L3 interconnect provider support
From: Sibi Sankar @ 2019-08-08 17:36 UTC (permalink / raw)
To: Saravana Kannan
Cc: Rob Herring, Georgi Djakov, Bjorn Andersson, agross, LKML,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-arm-msm, Mark Rutland, Evan Green, David Dai
In-Reply-To: <CAGETcx8JgigJpRgjXsG+xChLUPrASRO7BapkYaSrvvTdQKfEuQ@mail.gmail.com>
Hey Saravana,
Thanks for the review!
On 8/8/19 2:51 AM, Saravana Kannan wrote:
> On Wed, Aug 7, 2019 at 4:24 AM Sibi Sankar <sibis@codeaurora.org> wrote:
>>
>> On some Qualcomm SoCs, Operating State Manager (OSM) controls the
>> resources of scaling L3 caches. Add a driver to handle bandwidth
>> requests to OSM L3 from CPU/GPU.
>>
>> Signed-off-by: Sibi Sankar <sibis@codeaurora.org>
>> ---
>> drivers/interconnect/qcom/Kconfig | 7 +
>> drivers/interconnect/qcom/Makefile | 2 +
>> drivers/interconnect/qcom/osm-l3.c | 292 +++++++++++++++++++++++++++++
>> 3 files changed, 301 insertions(+)
>> create mode 100644 drivers/interconnect/qcom/osm-l3.c
>>
>> diff --git a/drivers/interconnect/qcom/Kconfig b/drivers/interconnect/qcom/Kconfig
>> index d5e70ebc24108..f6c2a11a1a2c9 100644
>> --- a/drivers/interconnect/qcom/Kconfig
>> +++ b/drivers/interconnect/qcom/Kconfig
>> @@ -5,6 +5,13 @@ config INTERCONNECT_QCOM
>> help
>> Support for Qualcomm's Network-on-Chip interconnect hardware.
>>
>> +config INTERCONNECT_QCOM_OSM_L3
>> + tristate "Qualcomm OSM L3 interconnect driver"
>> + depends on INTERCONNECT_QCOM || COMPILE_TEST
>> + help
>> + Say y here to support the Operating State Manager (OSM) interconnect
>> + driver which controls the scaling of L3 caches on Qualcomm SoCs.
>> +
>> config INTERCONNECT_QCOM_SDM845
>> tristate "Qualcomm SDM845 interconnect driver"
>> depends on INTERCONNECT_QCOM
>> diff --git a/drivers/interconnect/qcom/Makefile b/drivers/interconnect/qcom/Makefile
>> index 1c1cea690f922..9078af5fed109 100644
>> --- a/drivers/interconnect/qcom/Makefile
>> +++ b/drivers/interconnect/qcom/Makefile
>> @@ -1,5 +1,7 @@
>> # SPDX-License-Identifier: GPL-2.0
>>
>> +icc-osm-l3-objs := osm-l3.o
>> qnoc-sdm845-objs := sdm845.o
>>
>> +obj-$(CONFIG_INTERCONNECT_QCOM_OSM_L3) += icc-osm-l3.o
>> obj-$(CONFIG_INTERCONNECT_QCOM_SDM845) += qnoc-sdm845.o
>> diff --git a/drivers/interconnect/qcom/osm-l3.c b/drivers/interconnect/qcom/osm-l3.c
>> new file mode 100644
>> index 0000000000000..1e7dfce6f4f9b
>> --- /dev/null
>> +++ b/drivers/interconnect/qcom/osm-l3.c
>> @@ -0,0 +1,292 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (c) 2019, The Linux Foundation. All rights reserved.
>> + *
>> + */
>> +
>> +#include <dt-bindings/interconnect/qcom,osm-l3.h>
>> +#include <dt-bindings/interconnect/qcom,sdm845.h>
>> +#include <linux/bitfield.h>
>> +#include <linux/clk.h>
>> +#include <linux/interconnect-provider.h>
>> +#include <linux/io.h>
>> +#include <linux/kernel.h>
>> +#include <linux/module.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/platform_device.h>
>> +
>> +#define LUT_MAX_ENTRIES 40U
>> +#define LUT_SRC GENMASK(31, 30)
>> +#define LUT_L_VAL GENMASK(7, 0)
>> +#define LUT_ROW_SIZE 32
>> +#define CLK_HW_DIV 2
>> +
>> +/* Register offsets */
>> +#define REG_ENABLE 0x0
>> +#define REG_FREQ_LUT 0x110
>> +#define REG_PERF_STATE 0x920
>> +
>> +#define OSM_L3_MAX_LINKS 1
>> +
>> +#define to_qcom_provider(_provider) \
>> + container_of(_provider, struct qcom_icc_provider, provider)
>> +
>> +enum {
>> + SDM845_MASTER_OSM_L3_APPS = SLAVE_TCU + 1,
>> + SDM845_MASTER_OSM_L3_GPU,
>> + SDM845_SLAVE_OSM_L3,
>> +};
>> +
>> +struct qcom_icc_provider {
>> + void __iomem *base;
>> + unsigned int max_state;
>> + unsigned long lut_tables[LUT_MAX_ENTRIES];
>> + struct icc_provider provider;
>> +};
>> +
>> +/**
>> + * struct qcom_icc_node - Qualcomm specific interconnect nodes
>> + * @name: the node name used in debugfs
>> + * @links: an array of nodes where we can go next while traversing
>> + * @id: a unique node identifier
>> + * @num_links: the total number of @links
>> + * @buswidth: width of the interconnect between a node and the bus
>> + */
>> +struct qcom_icc_node {
>> + const char *name;
>> + u16 links[OSM_L3_MAX_LINKS];
>> + u16 id;
>> + u16 num_links;
>> + u16 buswidth;
>> +};
>> +
>> +struct qcom_icc_desc {
>> + struct qcom_icc_node **nodes;
>> + size_t num_nodes;
>> +};
>> +
>> +#define DEFINE_QNODE(_name, _id, _buswidth, ...) \
>> + static struct qcom_icc_node _name = { \
>> + .name = #_name, \
>> + .id = _id, \
>> + .buswidth = _buswidth, \
>> + .num_links = ARRAY_SIZE(((int[]){ __VA_ARGS__ })), \
>> + .links = { __VA_ARGS__ }, \
>> + }
>> +
>> +DEFINE_QNODE(osm_apps_l3, SDM845_MASTER_OSM_L3_APPS, 16, SDM845_SLAVE_OSM_L3);
>> +DEFINE_QNODE(osm_gpu_l3, SDM845_MASTER_OSM_L3_GPU, 16, SDM845_SLAVE_OSM_L3);
>> +DEFINE_QNODE(osm_l3, SDM845_SLAVE_OSM_L3, 16);
>> +
>> +static struct qcom_icc_node *sdm845_osm_l3_nodes[] = {
>> + [MASTER_OSM_L3_APPS] = &osm_apps_l3,
>> + [MASTER_OSM_L3_GPU] = &osm_gpu_l3,
>> + [SLAVE_OSM_L3] = &osm_l3,
>> +};
>> +
>> +static struct qcom_icc_desc sdm845_osm_l3 = {
>> + .nodes = sdm845_osm_l3_nodes,
>> + .num_nodes = ARRAY_SIZE(sdm845_osm_l3_nodes),
>> +};
>> +
>> +static int qcom_icc_aggregate(struct icc_node *node, u32 avg_bw,
>> + u32 peak_bw, u32 *agg_avg, u32 *agg_peak)
>> +{
>> + *agg_avg += avg_bw;
>> + *agg_peak = max_t(u32, *agg_peak, peak_bw);
>> +
>> + return 0;
>> +}
>> +
>> +static int qcom_icc_set(struct icc_node *src, struct icc_node *dst)
>> +{
>> + struct icc_provider *provider;
>> + struct qcom_icc_provider *qp;
>> + struct qcom_icc_node *qn;
>> + struct icc_node *n;
>> + unsigned int index;
>> + u32 agg_peak = 0;
>> + u32 agg_avg = 0;
>> + u64 rate;
>> +
>> + qn = src->data;
>> + provider = src->provider;
>> + qp = to_qcom_provider(provider);
>> +
>> + list_for_each_entry(n, &provider->nodes, node_list)
>> + qcom_icc_aggregate(n, n->avg_bw, n->peak_bw,
>> + &agg_avg, &agg_peak);
>> +
>> + rate = max(agg_avg, agg_peak);
>> + rate = icc_units_to_bps(rate);
>> + do_div(rate, qn->buswidth);
>> +
>> + for (index = 0; index < qp->max_state; index++) {
>> + if (qp->lut_tables[index] >= rate)
>> + break;
>> + }
>> +
>> + writel_relaxed(index, qp->base + REG_PERF_STATE);
>> +
>> + return 0;
>> +}
>> +
>> +static int qcom_osm_l3_probe(struct platform_device *pdev)
>> +{
>> + u32 info, src, lval, i, prev_freq = 0, freq;
>> + static unsigned long hw_rate, xo_rate;
>> + const struct qcom_icc_desc *desc;
>> + struct icc_onecell_data *data;
>> + struct icc_provider *provider;
>> + struct qcom_icc_node **qnodes;
>> + struct qcom_icc_provider *qp;
>> + struct icc_node *node;
>> + size_t num_nodes;
>> + struct clk *clk;
>> + int ret;
>> +
>> + clk = clk_get(&pdev->dev, "xo");
>> + if (IS_ERR(clk))
>> + return PTR_ERR(clk);
>> +
>> + xo_rate = clk_get_rate(clk);
>> + clk_put(clk);
>> +
>> + clk = clk_get(&pdev->dev, "alternate");
>> + if (IS_ERR(clk))
>> + return PTR_ERR(clk);
>> +
>> + hw_rate = clk_get_rate(clk) / CLK_HW_DIV;
>> + clk_put(clk);
>> +
>> + qp = devm_kzalloc(&pdev->dev, sizeof(*qp), GFP_KERNEL);
>> + if (!qp)
>> + return -ENOMEM;
>> +
>> + qp->base = devm_platform_ioremap_resource(pdev, 0);
>> + if (IS_ERR(qp->base))
>> + return PTR_ERR(qp->base);
>> +
>> + /* HW should be in enabled state to proceed */
>> + if (!(readl_relaxed(qp->base + REG_ENABLE) & 0x1)) {
>> + dev_err(&pdev->dev, "error hardware not enabled\n");
>> + return -ENODEV;
>> + }
>> +
>> + for (i = 0; i < LUT_MAX_ENTRIES; i++) {
>> + info = readl_relaxed(qp->base + REG_FREQ_LUT +
>> + i * LUT_ROW_SIZE);
>> + src = FIELD_GET(LUT_SRC, info);
>> + lval = FIELD_GET(LUT_L_VAL, info);
>> + if (src)
>> + freq = xo_rate * lval;
>> + else
>> + freq = hw_rate;
>> +
>> + /*
>> + * Two of the same frequencies with the same core counts means
>> + * end of table
>> + */
>> + if (i > 0 && prev_freq == freq)
>> + break;
>> +
>> + qp->lut_tables[i] = freq;
>> + prev_freq = freq;
>> + }
>> + qp->max_state = i;
>> +
>> + desc = of_device_get_match_data(&pdev->dev);
>> + if (!desc)
>> + return -EINVAL;
>> +
>> + qnodes = desc->nodes;
>> + num_nodes = desc->num_nodes;
>> +
>> + data = devm_kcalloc(&pdev->dev, num_nodes, sizeof(*node), GFP_KERNEL);
>> + if (!data)
>> + return -ENOMEM;
>> +
>> + provider = &qp->provider;
>> + provider->dev = &pdev->dev;
>> + provider->set = qcom_icc_set;
>> + provider->aggregate = qcom_icc_aggregate;
>> + provider->xlate = of_icc_xlate_onecell;
>> + INIT_LIST_HEAD(&provider->nodes);
>> + provider->data = data;
>> +
>> + ret = icc_provider_add(provider);
>> + if (ret) {
>> + dev_err(&pdev->dev, "error adding interconnect provider\n");
>> + return ret;
>> + }
>> +
>> + for (i = 0; i < num_nodes; i++) {
>> + size_t j;
>> +
>> + node = icc_node_create(qnodes[i]->id);
>> + if (IS_ERR(node)) {
>> + ret = PTR_ERR(node);
>> + goto err;
>> + }
>> +
>> + node->name = qnodes[i]->name;
>> + node->data = qnodes[i];
>> + icc_node_add(node, provider);
>> +
>> + dev_dbg(&pdev->dev, "registered node %p %s %d\n", node,
>> + qnodes[i]->name, node->id);
>> +
>> + /* populate links */
>> + for (j = 0; j < qnodes[i]->num_links; j++)
>> + icc_link_create(node, qnodes[i]->links[j]);
>> +
>> + data->nodes[i] = node;
>> + }
>> + data->num_nodes = num_nodes;
>> +
>> + platform_set_drvdata(pdev, qp);
>> +
>> + return ret;
>> +err:
>> + list_for_each_entry(node, &provider->nodes, node_list) {
>> + icc_node_del(node);
>> + icc_node_destroy(node->id);
>> + }
>> +
>> + icc_provider_del(provider);
>> + return ret;
>> +}
>> +
>> +static int qcom_osm_l3_remove(struct platform_device *pdev)
>> +{
>> + struct qcom_icc_provider *qp = platform_get_drvdata(pdev);
>> + struct icc_provider *provider = &qp->provider;
>> + struct icc_node *n;
>> +
>> + list_for_each_entry(n, &provider->nodes, node_list) {
>> + icc_node_del(n);
>> + icc_node_destroy(n->id);
>> + }
>> +
>> + return icc_provider_del(provider);
>> +}
>> +
>> +static const struct of_device_id osm_l3_of_match[] = {
>> + { .compatible = "qcom,sdm845-osm-l3", .data = &sdm845_osm_l3 },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(of, osm_l3_of_match);
>> +
>> +static struct platform_driver osm_l3_driver = {
>> + .probe = qcom_osm_l3_probe,
>> + .remove = qcom_osm_l3_remove,
>> + .driver = {
>> + .name = "osm-l3",
>> + .of_match_table = osm_l3_of_match,
>> + },
>> +};
>> +module_platform_driver(osm_l3_driver);
>> +
>> +MODULE_DESCRIPTION("Qualcomm OSM L3 interconnect driver");
>> +MODULE_LICENSE("GPL v2");
>
> Did a quick scan of the code and it's not clear how you connect the L3
> interconnect provider to the rest of the interconnect. I don't see any
> DT or code references to the rest of the interconnects in the system.
> If GPU is making a bandwidth request all the way to L3, how do you
> make sure the interconnects between GPU and L3 also scale up properly.
For SDM845 OSM L3 provider the icc nodes endpoints are isolated from
rsc icc node endpoints i.e GPU would need to vote on this path in
addition to voting for DDR. On future SoCs if the need to scale
interconnect between GPU rsc nodes along with the OSM l3 nodes arises,
it can be trivially extended by linking the osm icc nodes with global
icc node ids of the gpu rsc nodes.
>
> -Saravana
>
--
Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc, is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH RESEND v7 0/3] add support for rng-seed
From: Hsin-Yi Wang @ 2019-08-08 17:38 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rob Herring, devicetree, linux-kernel, Frank Rowand,
Catalin Marinas, Will Deacon, Andrew Morton, Mike Rapoport,
Ard Biesheuvel, Miles Chen, Hsin-Yi Wang, James Morse,
Andrew Murray, Mark Rutland, Jun Yao, Yu Zhao, Robin Murphy,
Laura Abbott, Stephen Boyd, Kees Cook
Introducing a chosen node, rng-seed, which is an entropy that can be
passed to kernel called very early to increase initial device
randomness. This can be used for adding sufficient initial entropy
for stack canary. Especially architectures that lack per-stack canary.
Hsin-Yi Wang (3):
arm64: map FDT as RW for early_init_dt_scan()
fdt: add support for rng-seed
arm64: kexec_file: add rng-seed support
arch/arm64/include/asm/mmu.h | 2 +-
arch/arm64/kernel/kaslr.c | 5 +----
arch/arm64/kernel/machine_kexec_file.c | 18 +++++++++++++++++-
arch/arm64/kernel/setup.c | 9 ++++++++-
arch/arm64/mm/mmu.c | 15 +--------------
drivers/of/fdt.c | 10 ++++++++++
6 files changed, 38 insertions(+), 21 deletions(-)
--
2.20.1
^ permalink raw reply
* [PATCH RESEND v7 1/3] arm64: map FDT as RW for early_init_dt_scan()
From: Hsin-Yi Wang @ 2019-08-08 17:38 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rob Herring, devicetree, linux-kernel, Frank Rowand,
Catalin Marinas, Will Deacon, Andrew Morton, Mike Rapoport,
Ard Biesheuvel, Miles Chen, Hsin-Yi Wang, James Morse,
Andrew Murray, Mark Rutland, Jun Yao, Yu Zhao, Robin Murphy,
Laura Abbott, Stephen Boyd, Kees Cook
In-Reply-To: <20190808173803.1146-1-hsinyi@chromium.org>
Currently in arm64, FDT is mapped to RO before it's passed to
early_init_dt_scan(). However, there might be some codes
(eg. commit "fdt: add support for rng-seed") that need to modify FDT
during init. Map FDT to RO after early fixups are done.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Mike Rapoport <rppt@linux.ibm.com>
---
arch/arm64/include/asm/mmu.h | 2 +-
arch/arm64/kernel/kaslr.c | 5 +----
arch/arm64/kernel/setup.c | 9 ++++++++-
arch/arm64/mm/mmu.c | 15 +--------------
4 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/arch/arm64/include/asm/mmu.h b/arch/arm64/include/asm/mmu.h
index fd6161336653..f217e3292919 100644
--- a/arch/arm64/include/asm/mmu.h
+++ b/arch/arm64/include/asm/mmu.h
@@ -126,7 +126,7 @@ extern void init_mem_pgprot(void);
extern void create_pgd_mapping(struct mm_struct *mm, phys_addr_t phys,
unsigned long virt, phys_addr_t size,
pgprot_t prot, bool page_mappings_only);
-extern void *fixmap_remap_fdt(phys_addr_t dt_phys);
+extern void *fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot);
extern void mark_linear_text_alias_ro(void);
#define INIT_MM_CONTEXT(name) \
diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c
index 708051655ad9..d94a3e41cef9 100644
--- a/arch/arm64/kernel/kaslr.c
+++ b/arch/arm64/kernel/kaslr.c
@@ -62,9 +62,6 @@ static __init const u8 *kaslr_get_cmdline(void *fdt)
return default_cmdline;
}
-extern void *__init __fixmap_remap_fdt(phys_addr_t dt_phys, int *size,
- pgprot_t prot);
-
/*
* This routine will be executed with the kernel mapped at its default virtual
* address, and if it returns successfully, the kernel will be remapped, and
@@ -93,7 +90,7 @@ u64 __init kaslr_early_init(u64 dt_phys)
* attempt at mapping the FDT in setup_machine()
*/
early_fixmap_init();
- fdt = __fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL);
+ fdt = fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL);
if (!fdt)
return 0;
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 9c4bad7d7131..25f5127210f8 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -170,9 +170,13 @@ static void __init smp_build_mpidr_hash(void)
static void __init setup_machine_fdt(phys_addr_t dt_phys)
{
- void *dt_virt = fixmap_remap_fdt(dt_phys);
+ int size;
+ void *dt_virt = fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL);
const char *name;
+ if (dt_virt)
+ memblock_reserve(dt_phys, size);
+
if (!dt_virt || !early_init_dt_scan(dt_virt)) {
pr_crit("\n"
"Error: invalid device tree blob at physical address %pa (virtual address 0x%p)\n"
@@ -184,6 +188,9 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
cpu_relax();
}
+ /* Early fixups are done, map the FDT as read-only now */
+ fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL_RO);
+
name = of_flat_dt_get_machine_name();
if (!name)
return;
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 63d730c5b7a9..bed9db92be24 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -876,7 +876,7 @@ void __set_fixmap(enum fixed_addresses idx,
}
}
-void *__init __fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
+void *__init fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
{
const u64 dt_virt_base = __fix_to_virt(FIX_FDT);
int offset;
@@ -929,19 +929,6 @@ void *__init __fixmap_remap_fdt(phys_addr_t dt_phys, int *size, pgprot_t prot)
return dt_virt;
}
-void *__init fixmap_remap_fdt(phys_addr_t dt_phys)
-{
- void *dt_virt;
- int size;
-
- dt_virt = __fixmap_remap_fdt(dt_phys, &size, PAGE_KERNEL_RO);
- if (!dt_virt)
- return NULL;
-
- memblock_reserve(dt_phys, size);
- return dt_virt;
-}
-
int __init arch_ioremap_p4d_supported(void)
{
return 0;
--
2.20.1
^ permalink raw reply related
* [PATCH RESEND v7 2/3] fdt: add support for rng-seed
From: Hsin-Yi Wang @ 2019-08-08 17:38 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rob Herring, devicetree, linux-kernel, Frank Rowand,
Catalin Marinas, Will Deacon, Andrew Morton, Mike Rapoport,
Ard Biesheuvel, Miles Chen, Hsin-Yi Wang, James Morse,
Andrew Murray, Mark Rutland, Jun Yao, Yu Zhao, Robin Murphy,
Laura Abbott, Stephen Boyd, Kees Cook
In-Reply-To: <20190808173803.1146-1-hsinyi@chromium.org>
Introducing a chosen node, rng-seed, which is an entropy that can be
passed to kernel called very early to increase initial device
randomness. Bootloader should provide this entropy and the value is
read from /chosen/rng-seed in DT.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Rob Herring <robh@kernel.org>
---
drivers/of/fdt.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index 9cdf14b9aaab..640c817cf65b 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -24,6 +24,7 @@
#include <linux/debugfs.h>
#include <linux/serial_core.h>
#include <linux/sysfs.h>
+#include <linux/random.h>
#include <asm/setup.h> /* for COMMAND_LINE_SIZE */
#include <asm/page.h>
@@ -1044,6 +1045,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
{
int l;
const char *p;
+ const void *rng_seed;
pr_debug("search \"chosen\", depth: %d, uname: %s\n", depth, uname);
@@ -1078,6 +1080,14 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
pr_debug("Command line is: %s\n", (char*)data);
+ rng_seed = of_get_flat_dt_prop(node, "rng-seed", &l);
+ if (rng_seed && l > 0) {
+ add_device_randomness(rng_seed, l);
+
+ /* try to clear seed so it won't be found. */
+ fdt_nop_property(initial_boot_params, node, "rng-seed");
+ }
+
/* break now */
return 1;
}
--
2.20.1
^ permalink raw reply related
* [PATCH RESEND v7 3/3] arm64: kexec_file: add rng-seed support
From: Hsin-Yi Wang @ 2019-08-08 17:38 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Rob Herring, devicetree, linux-kernel, Frank Rowand,
Catalin Marinas, Will Deacon, Andrew Morton, Mike Rapoport,
Ard Biesheuvel, Miles Chen, Hsin-Yi Wang, James Morse,
Andrew Murray, Mark Rutland, Jun Yao, Yu Zhao, Robin Murphy,
Laura Abbott, Stephen Boyd, Kees Cook
In-Reply-To: <20190808173803.1146-1-hsinyi@chromium.org>
Adding "rng-seed" to dtb. It's fine to add this property if original
fdt doesn't contain it. Since original seed will be wiped after
read, so use a default size 128 bytes here.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
---
arch/arm64/kernel/machine_kexec_file.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
index ba78ee7ca990..7b08bf9499b6 100644
--- a/arch/arm64/kernel/machine_kexec_file.c
+++ b/arch/arm64/kernel/machine_kexec_file.c
@@ -27,6 +27,8 @@
#define FDT_PROP_INITRD_END "linux,initrd-end"
#define FDT_PROP_BOOTARGS "bootargs"
#define FDT_PROP_KASLR_SEED "kaslr-seed"
+#define FDT_PROP_RNG_SEED "rng-seed"
+#define RNG_SEED_SIZE 128
const struct kexec_file_ops * const kexec_file_loaders[] = {
&kexec_image_ops,
@@ -102,6 +104,19 @@ static int setup_dtb(struct kimage *image,
FDT_PROP_KASLR_SEED);
}
+ /* add rng-seed */
+ if (rng_is_initialized()) {
+ u8 rng_seed[RNG_SEED_SIZE];
+ get_random_bytes(rng_seed, RNG_SEED_SIZE);
+ ret = fdt_setprop(dtb, off, FDT_PROP_RNG_SEED, rng_seed,
+ RNG_SEED_SIZE);
+ if (ret)
+ goto out;
+ } else {
+ pr_notice("RNG is not initialised: omitting \"%s\" property\n",
+ FDT_PROP_RNG_SEED);
+ }
+
out:
if (ret)
return (ret == -FDT_ERR_NOSPACE) ? -ENOMEM : -EINVAL;
@@ -110,7 +125,8 @@ static int setup_dtb(struct kimage *image,
}
/*
- * More space needed so that we can add initrd, bootargs and kaslr-seed.
+ * More space needed so that we can add initrd, bootargs, kaslr-seed, and
+ * rng-seed.
*/
#define DTB_EXTRA_SPACE 0x1000
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v4 2/3] dt-bindings: eeprom: at25: Add Anvo ANV32E61W
From: Schrempf Frieder @ 2019-08-08 18:09 UTC (permalink / raw)
To: Krzysztof Kozlowski, Rob Herring, Mark Rutland, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
NXP Linux Team, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: notify@kernel.org
In-Reply-To: <20190808172616.11728-2-krzk@kernel.org>
On 08.08.19 19:26, Krzysztof Kozlowski wrote:
> Document the compatible for ANV32E61W EEPROM chip.
This chip is actually not an EEPROM, but a SPI nvSRAM. It can be
interfaced by the at25 driver similar to an EEPROM. This is not the
ideal solution, but it works until there's a proper driver for such
chips. Maybe you can add some of these details to the commit message
here. Also there is more information on this topic here:
https://patchwork.ozlabs.org/patch/1043950/.
>
> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
>
> ---
>
> New patch
> ---
> Documentation/devicetree/bindings/eeprom/at25.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/eeprom/at25.txt b/Documentation/devicetree/bindings/eeprom/at25.txt
> index b3bde97dc199..42577dd113dd 100644
> --- a/Documentation/devicetree/bindings/eeprom/at25.txt
> +++ b/Documentation/devicetree/bindings/eeprom/at25.txt
> @@ -3,6 +3,7 @@ EEPROMs (SPI) compatible with Atmel at25.
> Required properties:
> - compatible : Should be "<vendor>,<type>", and generic value "atmel,at25".
> Example "<vendor>,<type>" values:
> + "anvo,anv32e61w"
> "microchip,25lc040"
> "st,m95m02"
> "st,m95256"
>
^ permalink raw reply
* Re: [PATCH v3 0/2] dt-bindings: net: meson-dwmac: convert to yaml
From: David Miller @ 2019-08-08 18:20 UTC (permalink / raw)
To: narmstrong
Cc: robh+dt, martin.blumenstingl, devicetree, netdev, linux-amlogic,
linux-arm-kernel, linux-kernel
In-Reply-To: <20190808114101.29982-1-narmstrong@baylibre.com>
From: Neil Armstrong <narmstrong@baylibre.com>
Date: Thu, 8 Aug 2019 13:40:59 +0200
> This patchsets converts the Amlogic Meson DWMAC glue bindings over to
> YAML schemas using the already converted dwmac bindings.
>
> The first patch is needed because the Amlogic glue needs a supplementary
> reg cell to access the DWMAC glue registers.
>
> Changes since v2:
> - Added review tags
> - Updated allwinner,sun7i-a20-gmac.yaml reg maxItems
Where is this targetted to be merged, an ARM tree? Or one of my
networking trees?
^ permalink raw reply
* Re: [PATCH v2 00/15] net: phy: adin: add support for Analog Devices PHYs
From: David Miller @ 2019-08-08 18:24 UTC (permalink / raw)
To: alexandru.ardelean
Cc: netdev, devicetree, linux-kernel, robh+dt, mark.rutland,
f.fainelli, hkallweit1, andrew
In-Reply-To: <20190808123026.17382-1-alexandru.ardelean@analog.com>
From: Alexandru Ardelean <alexandru.ardelean@analog.com>
Date: Thu, 8 Aug 2019 15:30:11 +0300
> This changeset adds support for Analog Devices Industrial Ethernet PHYs.
> Particularly the PHYs this driver adds support for:
> * ADIN1200 - Robust, Industrial, Low Power 10/100 Ethernet PHY
> * ADIN1300 - Robust, Industrial, Low Latency 10/100/1000 Gigabit
> Ethernet PHY
>
> The 2 chips are pin & register compatible with one another. The main
> difference being that ADIN1200 doesn't operate in gigabit mode.
>
> The chips can be operated by the Generic PHY driver as well via the
> standard IEEE PHY registers (0x0000 - 0x000F) which are supported by the
> kernel as well. This assumes that configuration of the PHY has been done
> completely in HW, according to spec, i.e. no extra SW configuration
> required.
>
> This changeset also implements the ability to configure the chips via SW
> registers.
>
> Datasheets:
> https://www.analog.com/media/en/technical-documentation/data-sheets/ADIN1300.pdf
> https://www.analog.com/media/en/technical-documentation/data-sheets/ADIN1200.pdf
>
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
I think, at a minimum, the c22 vs. c45 issues need to be discussed more
and even if no code changes occur there is definitely some adjustments
and clairifications that need to occur on this issue in the commit
messages and/or documentation.
^ permalink raw reply
* Re: [PATCH v2 4/6] irqchip/irq-pruss-intc: Add helper functions to configure internal mapping
From: David Lechner @ 2019-08-08 18:31 UTC (permalink / raw)
To: Suman Anna, Marc Zyngier, Thomas Gleixner, Jason Cooper
Cc: Rob Herring, Tony Lindgren, Andrew F. Davis, Roger Quadros,
Lokesh Vutla, Grygorii Strashko, Sekhar Nori, Murali Karicheri,
devicetree, linux-omap, linux-arm-kernel, linux-kernel
In-Reply-To: <124b03b8-f8e7-682b-8767-13a739329da2@lechnology.com>
On 8/8/19 12:09 PM, David Lechner wrote:
>
> Then we can provide a vendor resource hook in the remoteproc driver to handle
> these resources:
>
> static int ti_pru_rproc_handle_rsc(struct rproc *rproc, u32 rsc_type, void *rsc,
> int offset, int avail)
> {
> struct ti_pru_data *pru = rproc->priv;
> struct irq_fwspec fwspec;
> unsigned int virq;
>
> switch (rsc_type) {
> case TI_PRU_VENDOR_RESOURCE_IRQ:
> {
> struct ti_pru_vendor_resource_irq *rsc_irq = rsc;
>
> fwspec.fwnode = pru->intc_fwnode;
> fwspec.param[0] = le32_to_cpu(rsc_irq->event);
> fwspec.param[1] = le32_to_cpu(rsc_irq->channel);
> fwspec.param[2] = le32_to_cpu(rsc_irq->host);
> fwspec.param[3] = le32_to_cpu(rsc_irq->domain);
> fwspec.param_count = 4;
> }
> break;
> case TI_PRU_VENDOR_RESOURCE_IRQ2:
> {
> struct ti_pru_vendor_resource_irq2 *rsc_irq2 = rsc;
>
> fwspec.fwnode = pru->intc_fwnode;
> fwspec.param[0] = le32_to_cpu(rsc_irq2->event);
> fwspec.param[1] = le32_to_cpu(rsc_irq2->evt_sel);
> fwspec.param[2] = le32_to_cpu(rsc_irq2->channel);
> fwspec.param[3] = le32_to_cpu(rsc_irq2->host);
> fwspec.param[4] = le32_to_cpu(rsc_irq2->domain);
> fwspec.param_count = 5;
> break;
> }
> default:
> return RSC_IGNORED;
> }
>
> virq = irq_create_fwspec_mapping(&fwspec);
> if (!virq)
> return -EINVAL;
>
> /* TODO: save virq (and other metadata) for later use */
>
> return RSC_HANDLED;
> }
>
> static const struct rproc_ops ti_pru_rproc_ops = {
> .start = ti_pru_rproc_start,
> .stop = ti_pru_rproc_stop,
> .kick = ti_pru_rproc_kick,
> .da_to_va = ti_pru_rproc_da_to_va,
> .handle_rsc = ti_pru_rproc_handle_rsc,
> };
>
After re-reading some of the previous discussions, it sounds like
we wouldn't want to always map every IRQ in the firmware resource
table.
In that case, we could implement the rproc_ops parse_fw callback
instead. All firmware nodes could be collected (from both the
firmware resource table and device tree) and the remoteproc driver
could decide which ones need to be mapped and which ones don't.
Then it could call irq_create_fwspec_mapping() only the nodes
that need to be mapped based on the current application.
^ permalink raw reply
* Re: [PATCH] dt-bindings: mfd: rn5t618: Document optional property system-power-controller
From: Jonathan Neuschäfer @ 2019-08-08 18:39 UTC (permalink / raw)
To: Lee Jones
Cc: Jonathan Neuschäfer, devicetree, Rob Herring, Mark Rutland,
linux-kernel
In-Reply-To: <20190201092411.GG783@dell>
[-- Attachment #1: Type: text/plain, Size: 684 bytes --]
On Fri, Feb 01, 2019 at 09:24:11AM +0000, Lee Jones wrote:
> On Tue, 29 Jan 2019, Jonathan Neuschäfer wrote:
>
> > The RN5T618 family of PMICs can be used as system management
> > controllers, in which case they handle poweroff and restart. Document
> > this capability by referring to the corresponding generic DT binding.
> >
> > Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
> > ---
> > Documentation/devicetree/bindings/mfd/rn5t618.txt | 5 +++++
> > 1 file changed, 5 insertions(+)
>
> Applied, thanks.
Hi,
apparently this patch got lost somehow (I can't find it in mainline or
-next). Should I resend it?
Thanks
Jonathan Neuschäfer
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] spi: npcm-fiu: add NPCM FIU controller driver
From: Mark Brown @ 2019-08-08 18:55 UTC (permalink / raw)
To: Tomer Maimon
Cc: Rob Herring, Mark Rutland, Vignesh Raghavendra, bbrezillon,
Avi Fishman, Tali Perry, Patrick Venture, Nancy Yuen,
Benjamin Fair, linux-spi, devicetree, OpenBMC Maillist,
Linux Kernel Mailing List
In-Reply-To: <CAP6Zq1j7jHejdx9h-nxCJcVjtGx_3rHmay7R8nn11DLaE8Q4gA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
On Thu, Aug 08, 2019 at 06:37:06PM +0300, Tomer Maimon wrote:
> for example in our driver we modify the access type (singe, dual or quad)
> according the op->addr.buswidth
> for example in the npcm_fiu_set_drd function.
> regmap_update_bits(fiu->regmap, NPCM_FIU_DRD_CFG,
> NPCM_FIU_DRD_CFG_ACCTYPE,
> ilog2(op->addr.buswidth) <<
> NPCM_FIU_DRD_ACCTYPE_SHIFT);
> we also modify it in the UMA R/W functions.
Ah, it's only for the flash functions - that's fine.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 02/15] net: phy: adin: hook genphy_read_abilities() to get_features
From: Heiner Kallweit @ 2019-08-08 19:32 UTC (permalink / raw)
To: Andrew Lunn, Alexandru Ardelean
Cc: netdev, devicetree, linux-kernel, davem, robh+dt, mark.rutland,
f.fainelli
In-Reply-To: <20190808152403.GB27917@lunn.ch>
On 08.08.2019 17:24, Andrew Lunn wrote:
> On Thu, Aug 08, 2019 at 03:30:13PM +0300, Alexandru Ardelean wrote:
>> The ADIN PHYs can operate with Clause 45, however they are not typical for
>> how phylib considers Clause 45 PHYs.
>>
>> If the `features` field & the `get_features` hook are unspecified, and the
>> device wants to operate via Clause 45, it would also try to read features
>> via the `genphy_c45_pma_read_abilities()`, which will try to read PMA regs
>> that are unsupported.
>>
>> Hooking the `genphy_read_abilities()` function to the `get_features` hook
>> will ensure that this does not happen and the PHY features are read
>> correctly regardless of Clause 22 or Clause 45 operation.
>
> I think we need to stop and think about a PHY which supports both C22
> and C45.
>
> How does bus enumeration work? Is it discovered twice? I've always
> considered phydev->is_c45 means everything is c45, not that some
> registers can be accessed via c45. But the driver is mixing c22 and
> c45. Does the driver actually require c45? Are some features which are
> only accessibly via C45? What does C45 actually bring us for this
> device?
>
genphy_c45_pma_read_abilities() is only called if phydev->is_c45 is set.
And this flag means that the PHY complies with Clause 45 incl. all the
standard devices like PMA. In the case here only some vendor-specific
registers can be accessed via Clause 45 and therefore is_c45 shouldn't
bet set. As a consequence this patch isn't needed.
> Andrew
>
Heiner
^ permalink raw reply
* Re: [PATCH v2 13/15] net: phy: adin: configure downshift on config_init
From: Heiner Kallweit @ 2019-08-08 19:38 UTC (permalink / raw)
To: Alexandru Ardelean, netdev, devicetree, linux-kernel
Cc: davem, robh+dt, mark.rutland, f.fainelli, andrew
In-Reply-To: <20190808123026.17382-14-alexandru.ardelean@analog.com>
On 08.08.2019 14:30, Alexandru Ardelean wrote:
> Down-speed auto-negotiation may not always be enabled, in which case the
> PHY won't down-shift to 100 or 10 during auto-negotiation.
>
> This change enables downshift and configures the number of retries to
> default 8 (maximum supported value).
>
> The change has been adapted from the Marvell PHY driver.
>
Instead of a fixed downshift setting (like in the Marvell driver) you
may consider to implement the ethtool phy-tunable ETHTOOL_PHY_DOWNSHIFT.
See the Aquantia PHY driver for an example.
Then the user can configure whether he wants downshift and if yes after
how many retries.
> Signed-off-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
> ---
> drivers/net/phy/adin.c | 39 +++++++++++++++++++++++++++++++++++++++
> 1 file changed, 39 insertions(+)
[...]
Heiner
^ permalink raw reply
* Re: [PATCH v2 2/6] thermal: amlogic: Add thermal driver to support G12 SoCs
From: Martin Blumenstingl @ 2019-08-08 19:47 UTC (permalink / raw)
To: Kevin Hilman
Cc: guillaume La Roque, daniel.lezcano, devicetree, linux-amlogic,
linux-kernel, linux-arm-kernel, linux-pm
In-Reply-To: <7hblx0fjkw.fsf@baylibre.com>
Hi Kevin,
On Thu, Aug 8, 2019 at 4:59 AM Kevin Hilman <khilman@baylibre.com> wrote:
>
> Martin Blumenstingl <martin.blumenstingl@googlemail.com> writes:
>
> > Hi Guillaume,
> >
> > On Mon, Aug 5, 2019 at 2:48 PM guillaume La Roque <glaroque@baylibre.com> wrote:
> >>
> >> Hi Martin,
> >>
> >> again thanks for your review.
> > you're welcome - thank you for working on the driver :-)
> >
> > [...]
> >> > The IP block has more functionality, which may be added to this driver
> >> > in the future:
> >> > - reading up to 16 stored temperature samples
> >>
> >> it's not working, you can verify it if you check the regmap define in the driver. in fact temp is only write in one register, it's confirmed by amlogic.
> > I missed that - so please skip this part
> >
> > [...]
> >> >> +config AMLOGIC_THERMAL
> >> > we typically use "MESON" in the Kconfig symbols:
> >> > $ grep -c AMLOGIC .config
> >> > 1
> >> > $ grep -c MESON .config
> >> > 33
> >> >
> >> > I also wonder if we should add G12 or G12A so we don't conflict with
> >> > upcoming thermal sensors with a different design (assuming that this
> >> > will be a thing).
> >> > for example we already have three different USB2 PHY drivers
> >> >
> >> > [...]
> >>
> >> i check with Neil and for new family it's better to use Amlogic instead of meson.
> > can you please share the considerations behind this decision?
> > if new drivers should use AMLOGIC_* Kconfig symbols instead of MESON_*
> > then we all should know about it
> >
> >> i don't add G12 because we already know it's same sensors for SM1 SoC family [0].
> > my idea behind this was to avoid conflicts in the future
> > in case of the thermal driver we may be fine with using a generic name
> > assuming that Amlogic will not switch to a new IP block in the next
> > years
> > I'm not saying you have to change the name - I'm bringing this up so
> > you can decide for yourself based on examples from the past
> >
> > here are a few examples:
> > - when Kevin upstreamed the MMC driver for GX he decided to use
> > MMC_MESON_GX for the Kconfig symbol name. it turns out that this is
> > smart because there are at least two other MMC controller IPs on the
> > 32-bit SoCs. due to him including GX in the name the drivers are easy
> > to differentiate (MMC_MESON_MX_SDIO and MMC_MESON_MX_SDHC being the
> > other ones, while the latter is not upstream yet)
> > - when Carlo upstreamed the eFuse driver he decided to use MESON_EFUSE
> > for the Kconfig symbol name. I found out much later that the 32-bit
> > SoCs use a different IP (or at least direct register access instead of
> > going through Secure Monitor). the driver for the 32-bit SoCs now uses
> > MESON_MX_EFUSE. if you don't know which driver applies where then it's
> > easy to mix up MESON_EFUSE and MESON_MX_EFUSE
> > - when Jerome upstreamed the ALSA driver for AXG (which is also used
> > on G12A and G12B) he decided to use the SND_MESON_AXG_* prefix for the
> > Kconfig symbol names. in my opinion this was a good choice because GXM
> > and everything earlier (including the 32-bit SoCs) use a different
> > audio IP block. we won't have a Kconfig symbol name clash when a
> > driver for the "older" SoCs is upstreamed
> > - (there are more examples, Meson8b USB PHY driver, Meson8b DWMAC
> > glue, ... - just like there's many examples where the IP block is
> > mostly compatible with older generations: SAR ADC, RNG, SPI, ...)
>
> While these are all good examples, you can see it can go both ways, so
> there's really no way know up front what is the "right" way. We only
> know after the fact. Unfortunately, we simply have no visibility into
> future chips and where IP blocks may be shared or not (there are other
> examples where vendors add a new version of an IP *and* keep the old
> version. ;)
>
> Even having worked inside a (different) SoC vendor and having some
> knowledge about what IPs are shared, it's difficult to get this right.
right. The fact that it'll be the IP block in SM1 will be backwards
compatible (or even the same) means that it has a longer life-span
than some of the USB PHY IP.
so I'm fine either way
Martin
^ permalink raw reply
* Re: [PATCH 7/9] dt-bindings: phy: meson-g12a-usb3-pcie-phy: convert to yaml
From: Martin Blumenstingl @ 2019-08-08 19:50 UTC (permalink / raw)
To: Neil Armstrong
Cc: devicetree, Rob Herring, kishon, robh+dt, linux-amlogic,
linux-arm-kernel
In-Reply-To: <20190808085139.21438-8-narmstrong@baylibre.com>
On Thu, Aug 8, 2019 at 10:54 AM Neil Armstrong <narmstrong@baylibre.com> wrote:
>
> Now that we have the DT validation in place, let's convert the device tree
> bindings for the Amlogic G12A USB3 + PCIE Combo PHY over to a YAML schemas.
>
> While the original phy bindings specifies phy-supply as required,
> the examples and implementations makes it optional, thus phy-supply
> is not present in the properties and required lists.
nit-pick: the original bindings didn't mention the phy-supply property at all
I'm not sure if you have to re-send it, maybe this can be fixed up
while applying?
> Reviewed-by: Rob Herring <robh@kernel.org>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: soundwire: add slave bindings
From: Mark Brown @ 2019-08-08 19:52 UTC (permalink / raw)
To: Srinivas Kandagatla
Cc: Pierre-Louis Bossart, vkoul, bgoswami, plai, robh+dt, devicetree,
lgirdwood, alsa-devel, linux-kernel
In-Reply-To: <cdd2bded-551c-65f5-ca29-d2bb825bdaba@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 862 bytes --]
On Thu, Aug 08, 2019 at 05:48:56PM +0100, Srinivas Kandagatla wrote:
> On 08/08/2019 16:58, Pierre-Louis Bossart wrote:
> > > +- sdw-instance-id: Should be ('Instance ID') from SoundWire
> > > + Enumeration Address. Instance ID is for the cases
> > > + where multiple Devices of the same type or Class
> > > + are attached to the bus.
> > so it is actually required if you have a single Slave device? Or is it
> > only required when you have more than 1 device of the same type?
> This is mandatory for any slave device!
If it's mandatory the wording is a bit unclear. How about something
like:
Should be ('Instance ID') from the SoundWire Enumeration
Address. This must always be provided, if multiple devices
with the same type or class or attached to the bus each
instance must have a distinct value.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: dts: allwinner: a64: Drop PMU node
From: Vasily Khoruzhick @ 2019-08-08 19:59 UTC (permalink / raw)
To: Maxime Ripard
Cc: Mark Rutland, devicetree, Jared D . McNeill, Chen-Yu Tsai,
Rob Herring, Harald Geyer, Robin Murphy, arm-linux
In-Reply-To: <20190808162628.pthvy3tgf3naj76s@flea>
On Thu, Aug 8, 2019 at 9:26 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
>
> On Wed, Aug 07, 2019 at 10:36:08AM -0700, Vasily Khoruzhick wrote:
> > On Wed, Aug 7, 2019 at 4:56 AM Maxime Ripard <maxime.ripard@bootlin.com> wrote:
> > >
> > > On Tue, Aug 06, 2019 at 07:39:26PM -0700, Vasily Khoruzhick wrote:
> > > > On Tue, Aug 6, 2019 at 2:14 PM Robin Murphy <robin.murphy@arm.com> wrote:
> > > > >
> > > > > On 2019-08-06 9:52 pm, Vasily Khoruzhick wrote:
> > > > > > On Tue, Aug 6, 2019 at 1:19 PM Harald Geyer <harald@ccbib.org> wrote:
> > > > > >>
> > > > > >> Vasily Khoruzhick writes:
> > > > > >>> On Tue, Aug 6, 2019 at 7:35 AM Robin Murphy <robin.murphy@arm.com> wrote:
> > > > > >>>>
> > > > > >>>> On 06/08/2019 15:01, Vasily Khoruzhick wrote:
> > > > > >>>>> Looks like PMU in A64 is broken, it generates no interrupts at all and
> > > > > >>>>> as result 'perf top' shows no events.
> > > > > >>>>
> > > > > >>>> Does something like 'perf stat sleep 1' at least count cycles correctly?
> > > > > >>>> It could well just be that the interrupt numbers are wrong...
> > > > > >>>
> > > > > >>> Looks like it does, at least result looks plausible:
> > > > > >>
> > > > > >> I'm using perf stat regularly (cache benchmarks) and it works fine.
> > > > > >>
> > > > > >> Unfortunately I wasn't aware that perf stat is a poor test for
> > > > > >> the interrupts part of the node, when I added it. So I'm not too
> > > > > >> surprised I got it wrong.
> > > > > >>
> > > > > >> However, it would be unfortunate if the node got removed completely,
> > > > > >> because perf stat would not work anymore. Maybe we can only remove
> > > > > >> the interrupts or just fix them even if the HW doesn't work?
> > > > > >
> > > > > > I'm not familiar with PMU driver. Is it possible to get it working
> > > > > > without interrupts?
> > > > >
> > > > > Yup - you get a grumpy message from the driver, it will refuse sampling
> > > > > events (the ones which weren't working anyway), and if you measure
> > > > > anything for long enough that a counter overflows you'll get wonky
> > > > > results. But for counting hardware events over relatively short periods
> > > > > it'll still do the job.
> > > >
> > > > I tried to drop interrupts completely from the node but 'perf top' is
> > > > still broken. Though now in different way: it complains "cycles: PMU
> > > > Hardware doesn't support sampling/overflow-interrupts. Try 'perf
> > > > stat'"
> > >
> > > I have no idea if that's the culprit, but what is the state of the
> > > 0x09010000 register?
> >
> > What register is that and how do I check it?
>
> It's in the CPUX Configuration block, and the bits are labelled as CPU
> Debug Reset.
>
> And if you have busybox, you can use devmem.
CPUX configuration block is at 0x01700000 according to A64 user
manual, and particular register you're interested in is at 0x01700080,
its value is 0x1110110F.
Bits 16-19 are not defined in user manual and are not set.
> Maxime
>
> --
> Maxime Ripard, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
^ permalink raw reply
* Applied "regulator: dt-bindings: Add PM8150x compatibles" to the regulator tree
From: Mark Brown @ 2019-08-08 20:33 UTC (permalink / raw)
To: Vinod Koul
Cc: Andy Gross, Bjorn Andersson, devicetree, Liam Girdwood,
linux-arm-msm, linux-kernel, Mark Brown, Mark Rutland,
Rob Herring
In-Reply-To: <20190808093343.5600-1-vkoul@kernel.org>
The patch
regulator: dt-bindings: Add PM8150x compatibles
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git for-5.4
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From d566aae1c80d9be2276057b3236c68bdcc5b3254 Mon Sep 17 00:00:00 2001
From: Vinod Koul <vkoul@kernel.org>
Date: Thu, 8 Aug 2019 15:03:42 +0530
Subject: [PATCH] regulator: dt-bindings: Add PM8150x compatibles
Add PM8150, PM8150L and PM8009 compatibles for these PMICs found
in some Qualcomm platforms.
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20190808093343.5600-1-vkoul@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
---
.../devicetree/bindings/regulator/qcom,rpmh-regulator.txt | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
index 14d2eee96b3d..1a9cab50503a 100644
--- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.txt
@@ -25,6 +25,9 @@ Supported regulator node names:
PM8998: smps1 - smps13, ldo1 - ldo28, lvs1 - lvs2
PMI8998: bob
PM8005: smps1 - smps4
+ PM8150: smps1 - smps10, ldo1 - ldo18
+ PM8150L: smps1 - smps8, ldo1 - ldo11, bob, flash, rgb
+ PM8009: smps1 - smps2, ld01 - ldo7
========================
First Level Nodes - PMIC
@@ -35,7 +38,10 @@ First Level Nodes - PMIC
Value type: <string>
Definition: Must be one of: "qcom,pm8998-rpmh-regulators",
"qcom,pmi8998-rpmh-regulators" or
- "qcom,pm8005-rpmh-regulators".
+ "qcom,pm8005-rpmh-regulators" or
+ "qcom,pm8150-rpmh-regulators" or
+ "qcom,pm8150l-rpmh-regulators" or
+ "qcom,pm8009-rpmh-regulators".
- qcom,pmic-id
Usage: required
--
2.20.1
^ 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