* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Bjorn Helgaas @ 2016-12-05 21:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLNDk-cMW8k+bXqH3+yYCye_kHf6RXUYQ=eCCZ4FF2ZTjgkQ@mail.gmail.com>
On Fri, Dec 02, 2016 at 11:06:30PM -0800, Duc Dang wrote:
> On Fri, Dec 2, 2016 at 3:39 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > index 8a177a1..a16fc8e 100644
> > --- a/arch/arm64/kernel/pci.c
> > +++ b/arch/arm64/kernel/pci.c
> > @@ -114,6 +114,19 @@ int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
> > return 0;
> > }
> >
> > +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
> > +{
> > + struct resource_entry *entry, *tmp;
> > + int status;
> > +
> > + status = acpi_pci_probe_root_resources(ci);
> > + resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
> > + if (!(entry->res->flags & IORESOURCE_WINDOW))
> > + resource_list_destroy_entry(entry);
> > + }
> > + return status;
> > +}
> > +
> > /*
> > * Lookup the bus range for the domain in MCFG, and set up config space
> > * mapping.
> > @@ -190,6 +203,7 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
> > }
> >
> > root_ops->release_info = pci_acpi_generic_release_info;
> > + root_ops->prepare_resources = pci_acpi_root_prepare_resources;
> > root_ops->pci_ops = &ri->cfg->ops->pci_ops;
> > bus = acpi_pci_root_create(root, root_ops, &ri->common, ri->cfg);
> > if (!bus)
>
> I tried your patch above with my X-Gene ECAM v4 patch on Mustang, here
> is the kernel boot log and output of 'cat /proc/iomem'. The PCIe core
> does not print the MMIO space as a window (which is expected per your
> patch above).
Thanks!
> ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
> acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
> acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
> acpi PNP0A08:00: MCFG quirk: ECAM at [mem 0xe0d0000000-0xe0dfffffff] for [bus 00-ff] with xgene_v1_pcie_ecam_ops
> acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0xe0d0000000-0xe0dfffffff] not reserved in ACPI namespace
> acpi PNP0A08:00: ECAM at [mem 0xe0d0000000-0xe0dfffffff] for [bus 00-ff]
> Remapped I/O 0x000000e010000000 to [io 0x0000-0xffff window]
> PCI host bridge to bus 0000:00
> pci_bus 0000:00: root bus resource [io 0x0000-0xffff window] (bus address [0x10000000-0x1000ffff])
> pci_bus 0000:00: root bus resource [mem 0xe040000000-0xe07fffffff window] (bus address [0x40000000-0x7fffffff])
> pci_bus 0000:00: root bus resource [mem 0xf000000000-0xffffffffff window]
> pci_bus 0000:00: root bus resource [bus 00-ff]
Yup, no bridge register space here; that's good. I assume the bridge
registers are at [mem 0x1f2b0000-0x1f2bffff] as shown in /proc/iomem
below.
> [root@(none) ~]# cat /proc/io mem
> ...
> 19000000-19007fff : 808622B7:00
> 1900c100-190fffff : 808622B7:00
> 1900c100-190fffff : 808622B7:00
> 19800000-19807fff : 808622B7:01
> 1980c100-198fffff : 808622B7:01
> 1980c100-198fffff : 808622B7:01
> ...
> 1f280000-1f28ffff : 808622B7:00
> 1f290000-1f29ffff : 808622B7:01
I'm curious what these "808622B7" devices are. Per ACPI 6.0, sec
6.1.5, that looks like a PCI vendor ID, which I guess is a valid ACPI
ID. But these resources don't seem to have any connection with PCI
(they're not in any of the host bridge apertures).
> 1f2b0000-1f2bffff : PNP0A08:00
Looks like the bridge register space; good.
> e040000000-e07fffffff : PCI Bus 0000:00
> e040000000-e0401fffff : PCI Bus 0000:01
> e040000000-e0400fffff : 0000:01:00.0
> e040000000-e0400fffff : mlx4_core
> e040100000-e0401fffff : 0000:01:00.0
> e0d0000000-e0dfffffff : PCI ECAM
This region should be described in either a PNP0C02 device or (if we
decide we can allow "consumer" descriptors) the PNP0A08 device. I
assume you'll fix that in a future firmware release.
But I think this reservation from pci_ecam_create() is good enough for
now.
> f000000000-ffffffffff : PCI Bus 0000:00
> f000000000-f001ffffff : PCI Bus 0000:01
> f000000000-f001ffffff : 0000:01:00.0
> f000000000-f001ffffff : mlx4_core
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Bjorn Helgaas @ 2016-12-05 21:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <62dd5462-4d68-b89f-2b45-0d58bbd96bcd@redhat.com>
On Fri, Dec 02, 2016 at 07:33:46PM -0500, Jon Masters wrote:
> On 12/02/2016 06:39 PM, Bjorn Helgaas wrote:
> > On Thu, Dec 01, 2016 at 11:08:23PM -0500, Jon Masters wrote:
>
> >> Let's see if I summarized this correctly...
> >>
> >> 1. The MMIO registers for the host bridge itself need to be described
> >> somewhere, especially if we need to find those in a quirk and poke
> >> them. Since those registers are very much part of the bridge device,
> >> it makes sense for them to be in the _CRS for PNP0A08/PNP0A03.
> >>
> >> 2. The address space covering these registers MUST be described as a
> >> ResourceConsumer in order to avoid accidentally exposing them as
> >> available for use by downstream devices on the PCI bus.
> >>
> >> 3. The ACPI specification allows for resources of the type "Memory32Fixed".
> >> This is a macro that doesn't have the notion of a producer or consumer.
> >> HOWEVER various interpretations seem to be that this could/should
> >> default to being interpreted as a consumed region.
> >
> > I agree; I think that per spec, Memory24, Memory32, Memory32Fixed, IO,
> > and FixedIO should all be for consumed resources, not for bridge
> > windows, since they don't have the notion of producer.
>
> Ok. If we ultimately codify this somewhere as the general Linux kernel
> consensus (Rafael?) then we can also go and get the various ARM server
> specs updated to reflect this in (for e.g.) reference firmware builds.
>
> > I'm pretty sure there's x86 firmware in the field that uses these for
> > windows, so I think we have to accept that usage, at least on x86.
>
> Ok. I was pondering how to even go about finding that out, but even if
> I scheduled a job across RH's infra to look, that would be a drop in
> the bucket of possible machines that might be out there doing this.
Hmmm, when researching this, I thought I came across a change
specifically for a machine that used Memory32Fixed this way, but I
can't find it now.
The only thing I did find was some old experiments with Windows that
showed it interpreting a Memory32Fixed region as a window and putting
PCI devices in it: https://bugzilla.kernel.org/show_bug.cgi?id=15817
But that was a synthetic example with qemu, not a real machine in the
field.
> > Even without this patch, I don't think it's a show-stopper to have
> > Linux mistakenly thinking this region is routed to PCI, because the
> > driver does reserve it and the PCI core will never try to use it.
>
> Ok. So are you happy with pulling in Duc's v4 patch and retaining
> status quo on the bridge resources for 4.10?
Yes, I think it looks good. I'll finish packaging things up and
repost the current series.
Bjorn
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Duc Dang @ 2016-12-05 21:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205212012.GA22455@bhelgaas-glaptop.roam.corp.google.com>
On Mon, Dec 5, 2016 at 1:20 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Fri, Dec 02, 2016 at 11:06:30PM -0800, Duc Dang wrote:
>> On Fri, Dec 2, 2016 at 3:39 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>
>> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>> > index 8a177a1..a16fc8e 100644
>> > --- a/arch/arm64/kernel/pci.c
>> > +++ b/arch/arm64/kernel/pci.c
>> > @@ -114,6 +114,19 @@ int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
>> > return 0;
>> > }
>> >
>> > +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
>> > +{
>> > + struct resource_entry *entry, *tmp;
>> > + int status;
>> > +
>> > + status = acpi_pci_probe_root_resources(ci);
>> > + resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
>> > + if (!(entry->res->flags & IORESOURCE_WINDOW))
>> > + resource_list_destroy_entry(entry);
>> > + }
>> > + return status;
>> > +}
>> > +
>> > /*
>> > * Lookup the bus range for the domain in MCFG, and set up config space
>> > * mapping.
>> > @@ -190,6 +203,7 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>> > }
>> >
>> > root_ops->release_info = pci_acpi_generic_release_info;
>> > + root_ops->prepare_resources = pci_acpi_root_prepare_resources;
>> > root_ops->pci_ops = &ri->cfg->ops->pci_ops;
>> > bus = acpi_pci_root_create(root, root_ops, &ri->common, ri->cfg);
>> > if (!bus)
>>
>> I tried your patch above with my X-Gene ECAM v4 patch on Mustang, here
>> is the kernel boot log and output of 'cat /proc/iomem'. The PCIe core
>> does not print the MMIO space as a window (which is expected per your
>> patch above).
>
> Thanks!
>
>> ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
>> acpi PNP0A08:00: _OSC: OS supports [ExtendedConfig ASPM ClockPM Segments MSI]
>> acpi PNP0A08:00: _OSC: OS now controls [PCIeHotplug PME AER PCIeCapability]
>> acpi PNP0A08:00: MCFG quirk: ECAM at [mem 0xe0d0000000-0xe0dfffffff] for [bus 00-ff] with xgene_v1_pcie_ecam_ops
>> acpi PNP0A08:00: [Firmware Bug]: ECAM area [mem 0xe0d0000000-0xe0dfffffff] not reserved in ACPI namespace
>> acpi PNP0A08:00: ECAM at [mem 0xe0d0000000-0xe0dfffffff] for [bus 00-ff]
>> Remapped I/O 0x000000e010000000 to [io 0x0000-0xffff window]
>> PCI host bridge to bus 0000:00
>> pci_bus 0000:00: root bus resource [io 0x0000-0xffff window] (bus address [0x10000000-0x1000ffff])
>> pci_bus 0000:00: root bus resource [mem 0xe040000000-0xe07fffffff window] (bus address [0x40000000-0x7fffffff])
>> pci_bus 0000:00: root bus resource [mem 0xf000000000-0xffffffffff window]
>> pci_bus 0000:00: root bus resource [bus 00-ff]
>
> Yup, no bridge register space here; that's good. I assume the bridge
> registers are at [mem 0x1f2b0000-0x1f2bffff] as shown in /proc/iomem
> below.
Yes, the bridge registers are at [mem 0x1f2b0000-0x1f2bffff].
>
>> [root@(none) ~]# cat /proc/io mem
>> ...
>> 19000000-19007fff : 808622B7:00
>> 1900c100-190fffff : 808622B7:00
>> 1900c100-190fffff : 808622B7:00
>> 19800000-19807fff : 808622B7:01
>> 1980c100-198fffff : 808622B7:01
>> 1980c100-198fffff : 808622B7:01
>> ...
>> 1f280000-1f28ffff : 808622B7:00
>> 1f290000-1f29ffff : 808622B7:01
>
> I'm curious what these "808622B7" devices are. Per ACPI 6.0, sec
> 6.1.5, that looks like a PCI vendor ID, which I guess is a valid ACPI
> ID. But these resources don't seem to have any connection with PCI
> (they're not in any of the host bridge apertures).
These are DesignWare USB 3.0 controllers (DWC3). The ACPI ID is
defined in drivers/usb/dwc3/core.c.
>
>> 1f2b0000-1f2bffff : PNP0A08:00
>
> Looks like the bridge register space; good.
Yes, it is.
>
>> e040000000-e07fffffff : PCI Bus 0000:00
>> e040000000-e0401fffff : PCI Bus 0000:01
>> e040000000-e0400fffff : 0000:01:00.0
>> e040000000-e0400fffff : mlx4_core
>> e040100000-e0401fffff : 0000:01:00.0
>
>> e0d0000000-e0dfffffff : PCI ECAM
>
> This region should be described in either a PNP0C02 device or (if we
> decide we can allow "consumer" descriptors) the PNP0A08 device. I
> assume you'll fix that in a future firmware release.
Yes, future firmware will have PNP0C02 node that describes this ECAM
space (or a new resource in PNP0A08 if we use 'consumer' descriptor).
>
> But I think this reservation from pci_ecam_create() is good enough for
> now.
>
>> f000000000-ffffffffff : PCI Bus 0000:00
>> f000000000-f001ffffff : PCI Bus 0000:01
>> f000000000-f001ffffff : 0000:01:00.0
>> f000000000-f001ffffff : mlx4_core
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Bjorn Helgaas @ 2016-12-05 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CADaLNDm6fPQ6ekQa85fveAamJtF3+HGeOvprmgGJ4gLnMhF2_w@mail.gmail.com>
On Thu, Dec 01, 2016 at 06:52:23PM -0800, Duc Dang wrote:
> On Thu, Dec 1, 2016 at 10:33 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> I made similar changes in v4 patch. The ECAM quirk will be built when
> ACPI and PCI_QUIRKS are enabled.
>
> When building for DT only, the ECAM quirk won't be compiled.
Perfect.
> >> #define XGENE_PCIE_IP_VER_UNKN 0
> >> #define XGENE_PCIE_IP_VER_1 1
> >> +#define XGENE_PCIE_IP_VER_2 2
> >
> > This isn't used anywhere, which makes me wonder whether it's worth
> > keeping it.
>
> V2 controller will use this XGENE_PCIE_IP_VER_2 (port->version =
> XGENE_PCIE_IP_VER_2). This will be used to indicate that the
> controller is V2, and to enable configuration request retry status
> feature (by not disable it like V1 controller).
OK, I see. You don't actually need XGENE_PCIE_IP_VER_2, you just need
port->version to be something other than XGENE_PCIE_IP_VER_1. So this
is fine as it is.
> >> static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
> >> {
> >> - struct xgene_pcie_port *port = bus->sysdata;
> >> + struct pci_config_window *cfg;
> >> + struct xgene_pcie_port *port;
> >> +
> >> + if (acpi_disabled)
> >> + port = bus->sysdata;
> >> + else {
> >> + cfg = bus->sysdata;
> >> + port = cfg->priv;
> >> + }
> >
> > I would really, really like to figure out a way to get rid of these
> > "if (acpi_disabled)" checks sprinkled through here. Is there any way
> > we can set up bus->sysdata to be the same, regardless of whether we're
> > using this as a platform driver or an ACPI quirk?
>
> Right now, I created a inline function to extract xgene_pcie_port from
> pci_bus. In order to get rid of acpi_disabled, I will need to make
> sysdata in DT case also point to pci_config_window structure, which
> means I will need to convert and test the DT driver to use ecam ops.
> It is a separate patch itself. So I think I should do it at later time
> (after this ECAM quirk patch). I hope you are ok with this.
OK. I did the simple-minded version of leaving the DT ops the same
but making sysdata point to a dummy pci_config_window. Your proposal
of using ECAM for DT would be much better.
It's interesting that you actually already use the same accessors
except that DT uses the 32-bit pci_generic_config_write32() and ACPI
uses the regular pci_generic_config_write(). I guess that means the
hardware actually *does* support sub-32 bit writes?
> I need to define the function (xgene_get_csr_resource()) inside
> pci-xgene.c to duplicate the code of acpi_get_rc_addr. The reason is
> X-Gene firmware does not have a dedicate PNP0C02 node to declare the
> resource, and if I use acpi_get_rc_resources() with "PNP0A08", I got
> error due to acpi_bus_get_device() returns error.
Looks good.
> > All these init functions are almost identical. Can we factor this out
> > by having wrappers that do nothing more than pass in the table and
> > version, and put the kzalloc and ioremap in a shared back-end?
>
> I refactor-ed these .init functions. And as a result, there are only 2
> ecam ops left: xgene_v1_pcie_ecam_ops and xgene_v2_pcie_ecam_ops.
Looks good.
Bjorn
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Duc Dang @ 2016-12-05 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205215318.GB22455@bhelgaas-glaptop.roam.corp.google.com>
On Mon, Dec 5, 2016 at 1:53 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
> On Thu, Dec 01, 2016 at 06:52:23PM -0800, Duc Dang wrote:
>> On Thu, Dec 1, 2016 at 10:33 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>
>> I made similar changes in v4 patch. The ECAM quirk will be built when
>> ACPI and PCI_QUIRKS are enabled.
>>
>> When building for DT only, the ECAM quirk won't be compiled.
>
> Perfect.
>
>> >> #define XGENE_PCIE_IP_VER_UNKN 0
>> >> #define XGENE_PCIE_IP_VER_1 1
>> >> +#define XGENE_PCIE_IP_VER_2 2
>> >
>> > This isn't used anywhere, which makes me wonder whether it's worth
>> > keeping it.
>>
>> V2 controller will use this XGENE_PCIE_IP_VER_2 (port->version =
>> XGENE_PCIE_IP_VER_2). This will be used to indicate that the
>> controller is V2, and to enable configuration request retry status
>> feature (by not disable it like V1 controller).
>
> OK, I see. You don't actually need XGENE_PCIE_IP_VER_2, you just need
> port->version to be something other than XGENE_PCIE_IP_VER_1. So this
> is fine as it is.
>
>> >> static void __iomem *xgene_pcie_get_cfg_base(struct pci_bus *bus)
>> >> {
>> >> - struct xgene_pcie_port *port = bus->sysdata;
>> >> + struct pci_config_window *cfg;
>> >> + struct xgene_pcie_port *port;
>> >> +
>> >> + if (acpi_disabled)
>> >> + port = bus->sysdata;
>> >> + else {
>> >> + cfg = bus->sysdata;
>> >> + port = cfg->priv;
>> >> + }
>> >
>> > I would really, really like to figure out a way to get rid of these
>> > "if (acpi_disabled)" checks sprinkled through here. Is there any way
>> > we can set up bus->sysdata to be the same, regardless of whether we're
>> > using this as a platform driver or an ACPI quirk?
>>
>> Right now, I created a inline function to extract xgene_pcie_port from
>> pci_bus. In order to get rid of acpi_disabled, I will need to make
>> sysdata in DT case also point to pci_config_window structure, which
>> means I will need to convert and test the DT driver to use ecam ops.
>> It is a separate patch itself. So I think I should do it at later time
>> (after this ECAM quirk patch). I hope you are ok with this.
>
> OK. I did the simple-minded version of leaving the DT ops the same
> but making sysdata point to a dummy pci_config_window. Your proposal
> of using ECAM for DT would be much better.
>
> It's interesting that you actually already use the same accessors
> except that DT uses the 32-bit pci_generic_config_write32() and ACPI
> uses the regular pci_generic_config_write(). I guess that means the
> hardware actually *does* support sub-32 bit writes?
Yes, the hardware does support sub-32 bit writes (and reads). This is
another item in my TODO list for DT (which does not seem quite urgent
now): switch to use pci_generic_config_write for DT. But, well, I will
need to do that for read as well (for both ACPI and DT).
>
>> I need to define the function (xgene_get_csr_resource()) inside
>> pci-xgene.c to duplicate the code of acpi_get_rc_addr. The reason is
>> X-Gene firmware does not have a dedicate PNP0C02 node to declare the
>> resource, and if I use acpi_get_rc_resources() with "PNP0A08", I got
>> error due to acpi_bus_get_device() returns error.
>
> Looks good.
>
>> > All these init functions are almost identical. Can we factor this out
>> > by having wrappers that do nothing more than pass in the table and
>> > version, and put the kzalloc and ioremap in a shared back-end?
>>
>> I refactor-ed these .init functions. And as a result, there are only 2
>> ecam ops left: xgene_v1_pcie_ecam_ops and xgene_v2_pcie_ecam_ops.
>
> Looks good.
>
> Bjorn
Regards,
Duc Dang.
^ permalink raw reply
* [PATCH] ACPI/IORT: Make dma masks set-up IORT specific
From: Rafael J. Wysocki @ 2016-12-05 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205122619.25045-1-lorenzo.pieralisi@arm.com>
On Mon, Dec 5, 2016 at 1:26 PM, Lorenzo Pieralisi
<lorenzo.pieralisi@arm.com> wrote:
> The introduction of acpi_dma_configure() allows to configure DMA
> and related IOMMU for any device that is DMA capable. To achieve
> that goal it ensures DMA masks are set-up to sane default values
> before proceeding with IOMMU and DMA ops configuration.
>
> On x86/ia64 systems, through acpi_bind_one(), acpi_dma_configure() is
> called for every device that has an ACPI companion, in that every device
> is considered DMA capable on x86/ia64 systems (ie acpi_get_dma_attr() API),
> which has the side effect of initializing dma masks also for
> pseudo-devices (eg CPUs and memory nodes) and potentially for devices
> whose dma masks were not set-up before the acpi_dma_configure() API was
> introduced, which may have noxious side effects.
>
> Therefore, in preparation for IORT firmware specific DMA masks set-up,
> wrap the default DMA masks set-up in acpi_dma_configure() inside an IORT
> specific wrapper that reverts to a NOP on x86/ia64 systems, restoring the
> default expected behaviour on x86/ia64 systems and keeping DMA default
> masks set-up on IORT based (ie ARM) arch configurations.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Hanjun Guo <hanjun.guo@linaro.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: Tomasz Nowicki <tn@semihalf.com>
> Cc: Joerg Roedel <joro@8bytes.org>
> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
> Cc: Sricharan R <sricharan@codeaurora.org>
Acked -by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
> Joerg,
>
> pending Rafael's ACK on it, given the 4.10 release timing and that the
> series is queued via the IOMMU tree please consider applying this patch to
> your arm/smmu branch for 4.10, it is not fixing a bug but it is modifying
> the x86/ia64 code path; I prefer preventing any issue related to default
> dma masks on x86/ia64 so I hope it can get merged along with the rest of
> the ACPI IORT SMMU series.
>
> Thanks a lot and apologies,
> Lorenzo
>
> drivers/acpi/arm64/iort.c | 22 ++++++++++++++++++++++
> drivers/acpi/scan.c | 14 +-------------
> include/linux/acpi_iort.h | 2 ++
> 3 files changed, 25 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
> index 47bace8..e0d2e6e 100644
> --- a/drivers/acpi/arm64/iort.c
> +++ b/drivers/acpi/arm64/iort.c
> @@ -547,6 +547,28 @@ static const struct iommu_ops *iort_iommu_xlate(struct device *dev,
> }
>
> /**
> + * iort_set_dma_mask - Set-up dma mask for a device.
> + *
> + * @dev: device to configure
> + */
> +void iort_set_dma_mask(struct device *dev)
> +{
> + /*
> + * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> + * setup the correct supported mask.
> + */
> + if (!dev->coherent_dma_mask)
> + dev->coherent_dma_mask = DMA_BIT_MASK(32);
> +
> + /*
> + * Set it to coherent_dma_mask by default if the architecture
> + * code has not set it.
> + */
> + if (!dev->dma_mask)
> + dev->dma_mask = &dev->coherent_dma_mask;
> +}
> +
> +/**
> * iort_iommu_configure - Set-up IOMMU configuration for a device.
> *
> * @dev: device to configure
> diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
> index 80698d3..93b00cf 100644
> --- a/drivers/acpi/scan.c
> +++ b/drivers/acpi/scan.c
> @@ -1380,19 +1380,7 @@ void acpi_dma_configure(struct device *dev, enum dev_dma_attr attr)
> {
> const struct iommu_ops *iommu;
>
> - /*
> - * Set default coherent_dma_mask to 32 bit. Drivers are expected to
> - * setup the correct supported mask.
> - */
> - if (!dev->coherent_dma_mask)
> - dev->coherent_dma_mask = DMA_BIT_MASK(32);
> -
> - /*
> - * Set it to coherent_dma_mask by default if the architecture
> - * code has not set it.
> - */
> - if (!dev->dma_mask)
> - dev->dma_mask = &dev->coherent_dma_mask;
> + iort_set_dma_mask(dev);
>
> iommu = iort_iommu_configure(dev);
>
> diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
> index dcb2b60..77e0809 100644
> --- a/include/linux/acpi_iort.h
> +++ b/include/linux/acpi_iort.h
> @@ -35,6 +35,7 @@ bool iort_node_match(u8 type);
> u32 iort_msi_map_rid(struct device *dev, u32 req_id);
> struct irq_domain *iort_get_device_domain(struct device *dev, u32 req_id);
> /* IOMMU interface */
> +void iort_set_dma_mask(struct device *dev);
> const struct iommu_ops *iort_iommu_configure(struct device *dev);
> #else
> static inline void acpi_iort_init(void) { }
> @@ -45,6 +46,7 @@ static inline struct irq_domain *iort_get_device_domain(struct device *dev,
> u32 req_id)
> { return NULL; }
> /* IOMMU interface */
> +static inline void iort_set_dma_mask(struct device *dev) { }
> static inline
> const struct iommu_ops *iort_iommu_configure(struct device *dev)
> { return NULL; }
> --
> 2.10.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v4 1/9] dt-bindings: clarify compatible property for rockchip timers
From: Rob Herring @ 2016-12-05 22:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480436092-10728-2-git-send-email-al.kochet@gmail.com>
On Tue, Nov 29, 2016 at 07:14:44PM +0300, Alexander Kochetkov wrote:
> Make all properties description in form '"rockchip,<chip>-timer",
> "rockchip,rk3288-timer"' for all chips found in linux kernel.
>
> Suggested-by: Heiko St?bner <heiko@sntech.de>
> Signed-off-by: Alexander Kochetkov <al.kochet@gmail.com>
> ---
> .../bindings/timer/rockchip,rk-timer.txt | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v4 4/4] [media] dt-bindings: add TI VPIF documentation
From: Rob Herring @ 2016-12-05 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161129235712.29846-5-khilman@baylibre.com>
On Tue, Nov 29, 2016 at 03:57:12PM -0800, Kevin Hilman wrote:
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> .../devicetree/bindings/media/ti,da850-vpif.txt | 67 ++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/ti,da850-vpif.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [RFC PATCH 00/29] arm64: Scalable Vector Extension core support
From: Torvald Riegel @ 2016-12-05 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130120654.GJ1574@e103592.cambridge.arm.com>
On Wed, 2016-11-30 at 12:06 +0000, Dave Martin wrote:
> So, my key goal is to support _per-process_ vector length control.
>
> From the kernel perspective, it is easiest to achieve this by providing
> per-thread control since that is the unit that context switching acts
> on.
>
> How useful it really is to have threads with different VLs in the same
> process is an open question. It's theoretically useful for runtime
> environments, which may want to dispatch code optimised for different
> VLs
What would be the primary use case(s)? Vectorization of short vectors
(eg, if having an array of structs or sth like that)?
> -- changing the VL on-the-fly within a single thread is not
> something I want to encourage, due to overhead and ABI issues, but
> switching between threads of different VLs would be more manageable.
So if on-the-fly switching is probably not useful, that would mean we
need special threads for the use cases. Is that a realistic assumption
for the use cases? Or do you primarily want to keep it possible to do
this, regardless of whether there are real use cases now?
I suppose allowing for a per-thread setting of VL could also be added as
a feature in the future without breaking existing code.
> For setcontext/setjmp, we don't save/restore any SVE state due to the
> caller-save status of SVE, and I would not consider it necessary to
> save/restore VL itself because of the no-change-on-the-fly policy for
> this.
Thus, you would basically consider VL changes or per-thread VL as in the
realm of compilation internals? So, the specific size for a particular
piece of code would not be part of an ABI?
> I'm not familiar with resumable functions/executors -- are these in
> the C++ standards yet (not that that would cause me to be familiar
> with them... ;) Any implementation of coroutines (i.e.,
> cooperative switching) is likely to fall under the "setcontext"
> argument above.
These are not part of the C++ standard yet, but will appear in TSes.
There are various features for which implementations would be assumed to
use one OS thread for several tasks, coroutines, etc. Some of them
switch between these tasks or coroutines while these are running,
whereas the ones that will be in C++17 only run more than parallel task
on the same OS thread but one after the other (like in a thread pool).
However, if we are careful not to expose VL or make promises about it,
this may just end up being a detail similar to, say, register
allocation, which isn't exposed beyond the internals of a particular
compiler either.
Exposing it as a feature the user can set without messing with the
implementation would introduce additional thread-specific state, as
Florian said. This might not be a show-stopper by itself, but the more
thread-specific state we have the more an implementation has to take
care of or switch, and the higher the runtime costs are. C++17 already
makes weaker promises for TLS for parallel tasks, so that
implementations don't have to run TLS constructors or destructors just
because a small parallel task was executed.
^ permalink raw reply
* [PATCH 1/3] Add DT bindings documentation for NS2 USB DRD phy
From: Rob Herring @ 2016-12-05 23:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485338-23451-2-git-send-email-raviteja.garimella@broadcom.com>
On Wed, Nov 30, 2016 at 11:25:36AM +0530, Raviteja Garimella wrote:
> This patch adds documentation for NS2 DRD Phy driver DT bindings
>
> Signed-off-by: Raviteja Garimella <raviteja.garimella@broadcom.com>
> ---
> .../devicetree/bindings/phy/brcm,ns2-drd-phy.txt | 40 ++++++++++++++++++++++
> 1 file changed, 40 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
> new file mode 100644
> index 0000000..5857f99
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/brcm,ns2-drd-phy.txt
> @@ -0,0 +1,40 @@
> +BROADCOM NORTHSTAR2 USB2 (DUAL ROLE DEVICE) PHY
> +
> +Required properties:
> + - compatible: brcm,ns2-drd-phy
> + - reg: offset and length of the NS2 PHY related registers.
> + - reg-names
> + The below registers must be provided.
> + icfg - for DRD ICFG configurations
> + rst-ctrl - for DRD IDM reset
> + crmu-ctrl - for CRMU core vdd, PHY and PHY PLL reset
> + usb2-strap - for port over current polarity reversal
> + - #phy-cells: Must be 0. No args required.
> + - vbus-gpios: vbus gpio binding
> + - id-gpios: id gpio binding
> +
> +Refer to phy/phy-bindings.txt for the generic PHY binding properties
> +
> +Example:
> + gpio_g: gpio at 660a0000 {
You don't really need to show gpio node for the example. Otherwise,
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* [PATCH 0/2] arm64: dts: NS2: XMC support and Nitro memreserve
From: Jon Mason @ 2016-12-05 23:12 UTC (permalink / raw)
To: linux-arm-kernel
Add support for the NS2 XMC formfactor via a new DTS file. Also, set
aside memory for Nitro firmware in the NS2 DTSI file.
Jon Mason (2):
arm64: dts: NS2: reserve memory for Nitro firmware
arm64: dts: NS2: add support for XMC form factor
arch/arm64/boot/dts/broadcom/Makefile | 2 +-
arch/arm64/boot/dts/broadcom/ns2-xmc.dts | 191 +++++++++++++++++++++++++++++++
arch/arm64/boot/dts/broadcom/ns2.dtsi | 2 +
3 files changed, 194 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/broadcom/ns2-xmc.dts
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] arm64: dts: NS2: reserve memory for Nitro firmware
From: Jon Mason @ 2016-12-05 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480979542-26871-1-git-send-email-jon.mason@broadcom.com>
Nitro firmware is loaded into memory by the bootloader at a specific
location. Set this memory range aside to prevent the kernel from using
it.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm64/boot/dts/broadcom/ns2.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/broadcom/ns2.dtsi b/arch/arm64/boot/dts/broadcom/ns2.dtsi
index 96ed47b..9f9e203 100644
--- a/arch/arm64/boot/dts/broadcom/ns2.dtsi
+++ b/arch/arm64/boot/dts/broadcom/ns2.dtsi
@@ -30,6 +30,8 @@
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
+/memreserve/ 0x81000000 0x00200000;
+
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/clock/bcm-ns2.h>
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: NS2: add support for XMC form factor
From: Jon Mason @ 2016-12-05 23:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480979542-26871-1-git-send-email-jon.mason@broadcom.com>
The BCM958712DxXMC board is a smaller form factor typically used as
controller boards for switches. This smaller board has less devices
pinned out, so only a few need be populated in the device tree.
Signed-off-by: Jon Mason <jon.mason@broadcom.com>
---
arch/arm64/boot/dts/broadcom/Makefile | 2 +-
arch/arm64/boot/dts/broadcom/ns2-xmc.dts | 191 +++++++++++++++++++++++++++++++
2 files changed, 192 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/boot/dts/broadcom/ns2-xmc.dts
diff --git a/arch/arm64/boot/dts/broadcom/Makefile b/arch/arm64/boot/dts/broadcom/Makefile
index 05faf2a..f1caece 100644
--- a/arch/arm64/boot/dts/broadcom/Makefile
+++ b/arch/arm64/boot/dts/broadcom/Makefile
@@ -1,5 +1,5 @@
dtb-$(CONFIG_ARCH_BCM2835) += bcm2837-rpi-3-b.dtb
-dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb
+dtb-$(CONFIG_ARCH_BCM_IPROC) += ns2-svk.dtb ns2-xmc.dtb
dtb-$(CONFIG_ARCH_VULCAN) += vulcan-eval.dtb
always := $(dtb-y)
diff --git a/arch/arm64/boot/dts/broadcom/ns2-xmc.dts b/arch/arm64/boot/dts/broadcom/ns2-xmc.dts
new file mode 100644
index 0000000..99a2723
--- /dev/null
+++ b/arch/arm64/boot/dts/broadcom/ns2-xmc.dts
@@ -0,0 +1,191 @@
+/*
+ * BSD LICENSE
+ *
+ * Copyright(c) 2016 Broadcom. All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in
+ * the documentation and/or other materials provided with the
+ * distribution.
+ * * Neither the name of Broadcom Corporation nor the names of its
+ * contributors may be used to endorse or promote products derived
+ * from this software without specific prior written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+ * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+ * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+ * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+ * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+ * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+/dts-v1/;
+
+#include "ns2.dtsi"
+
+/ {
+ model = "Broadcom NS2 XMC";
+ compatible = "brcm,ns2-xmc", "brcm,ns2";
+
+ aliases {
+ serial0 = &uart3;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ bootargs = "earlycon=uart8250,mmio32,0x66130000";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x000000000 0x80000000 0x00000001 0x00000000>;
+ };
+};
+
+&enet {
+ status = "ok";
+};
+
+&i2c0 {
+ status = "ok";
+};
+
+&i2c1 {
+ status = "ok";
+};
+
+&mdio_mux_iproc {
+ mdio at 10 {
+ gphy0: eth-phy at 10 {
+ reg = <0x10>;
+ };
+ };
+};
+
+&nand {
+ nandcs at 0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-ecc-mode = "hw";
+ nand-ecc-strength = <8>;
+ nand-ecc-step-size = <512>;
+ nand-bus-width = <16>;
+ brcm,nand-oob-sector-size = <16>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition at 0 {
+ label = "nboot";
+ reg = <0x00000000 0x00280000>; /* 2.5MB */
+ read-only;
+ };
+
+ partition at 280000 {
+ label = "nenv";
+ reg = <0x00280000 0x00040000>; /* 0.25MB */
+ read-only;
+ };
+
+ partition at 2c0000 {
+ label = "ndtb";
+ reg = <0x002c0000 0x00040000>; /* 0.25MB */
+ read-only;
+ };
+
+ partition at 300000 {
+ label = "nsystem";
+ reg = <0x00300000 0x03d00000>; /* 61MB */
+ read-only;
+ };
+
+ partition at 4000000 {
+ label = "nrootfs";
+ reg = <0x04000000 0x06400000>; /* 100MB */
+ };
+
+ partition at 0a400000{
+ label = "ncustfs";
+ reg = <0x0a400000 0x35c00000>; /* 860MB */
+ };
+ };
+};
+
+&pci_phy0 {
+ status = "ok";
+};
+
+&pcie0 {
+ status = "ok";
+};
+
+&pcie8 {
+ status = "ok";
+};
+
+&sata_phy0 {
+ status = "ok";
+};
+
+&sata_phy1 {
+ status = "ok";
+};
+
+&sata {
+ status = "ok";
+};
+
+&qspi {
+ flash: m25p80 at 0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "m25p80";
+ spi-max-frequency = <62500000>;
+ m25p,default-addr-width = <3>;
+ reg = <0x0 0x0>;
+
+ partition at 0 {
+ label = "bl0";
+ reg = <0x00000000 0x00080000>; /* 512KB */
+ };
+
+ partition at 80000 {
+ label = "fip";
+ reg = <0x00080000 0x00150000>; /* 1344KB */
+ };
+
+ partition at 1e0000 {
+ label = "env";
+ reg = <0x001e0000 0x00010000>;/* 64KB */
+ };
+
+ partition at 1f0000 {
+ label = "dtb";
+ reg = <0x001f0000 0x00010000>; /* 64KB */
+ };
+
+ partition at 200000 {
+ label = "kernel";
+ reg = <0x00200000 0x00e00000>; /* 14MB */
+ };
+
+ partition at 1000000 {
+ label = "rootfs";
+ reg = <0x01000000 0x01000000>; /* 16MB */
+ };
+ };
+};
+
+&uart3 {
+ status = "ok";
+};
--
2.7.4
^ permalink raw reply related
* [PATCH v2 3/5] dt-bindings: spi: Add documentation for the Armada 3700 SPI Controller
From: Rob Herring @ 2016-12-05 23:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161130094351.2748-4-romain.perier@free-electrons.com>
On Wed, Nov 30, 2016 at 10:43:49AM +0100, Romain Perier wrote:
> This adds the devicetree bindings documentation for the SPI controller
> present in the Marvell Armada 3700 SoCs.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
> .../devicetree/bindings/spi/spi-armada-3700.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/spi-armada-3700.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3] PCI/ACPI: xgene: Add ECAM quirk for X-Gene PCIe controller
From: Jon Masters @ 2016-12-05 23:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205212012.GA22455@bhelgaas-glaptop.roam.corp.google.com>
On 12/05/2016 04:20 PM, Bjorn Helgaas wrote:
> On Fri, Dec 02, 2016 at 11:06:30PM -0800, Duc Dang wrote:
>> On Fri, Dec 2, 2016 at 3:39 PM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>
>>> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
>>> index 8a177a1..a16fc8e 100644
>>> --- a/arch/arm64/kernel/pci.c
>>> +++ b/arch/arm64/kernel/pci.c
>>> @@ -114,6 +114,19 @@ int pcibios_root_bridge_prepare(struct pci_host_bridge *bridge)
>>> return 0;
>>> }
>>>
>>> +static int pci_acpi_root_prepare_resources(struct acpi_pci_root_info *ci)
>>> +{
>>> + struct resource_entry *entry, *tmp;
>>> + int status;
>>> +
>>> + status = acpi_pci_probe_root_resources(ci);
>>> + resource_list_for_each_entry_safe(entry, tmp, &ci->resources) {
>>> + if (!(entry->res->flags & IORESOURCE_WINDOW))
>>> + resource_list_destroy_entry(entry);
>>> + }
>>> + return status;
>>> +}
>>> +
>>> /*
>>> * Lookup the bus range for the domain in MCFG, and set up config space
>>> * mapping.
>>> @@ -190,6 +203,7 @@ struct pci_bus *pci_acpi_scan_root(struct acpi_pci_root *root)
>>> }
>>>
>>> root_ops->release_info = pci_acpi_generic_release_info;
>>> + root_ops->prepare_resources = pci_acpi_root_prepare_resources;
>>> root_ops->pci_ops = &ri->cfg->ops->pci_ops;
>>> bus = acpi_pci_root_create(root, root_ops, &ri->common, ri->cfg);
>>> if (!bus)
>>
>> I tried your patch above with my X-Gene ECAM v4 patch on Mustang, here
>> is the kernel boot log and output of 'cat /proc/iomem'. The PCIe core
>> does not print the MMIO space as a window (which is expected per your
>> patch above).
>
> Thanks!
...and just for the record, here it is on HPE ProLiant m400 (Moonshot),
with the same result that the region is no longer claimed as PCI space
(it - 1f500000 - is now showing as being owned by PNP0A08:00):
# cat /proc/iomem
10520000-10523fff : APMC0D18:00
10520000-10523fff : APMC0D18:00
10524000-10527fff : APMC0D17:00
10540000-1054a0ff : APMC0D01:00
10546000-10546fff : APMC0D50:00
1054a000-1054a00f : APMC0D12:03
1054a000-1054a00f : APMC0D12:02
1054a000-1054a00f : APMC0D12:01
1054a000-1054a00f : APMC0D12:00
17000000-17000fff : APMC0D01:00
17001000-17001fff : APMC0D01:00
17001000-170013ff : APMC0D15:00
17001000-170013ff : APMC0D15:00
1701c000-1701cfff : APMC0D14:00
1a800000-1a800fff : APMC0D0D:00
1a800000-1a800fff : APMC0D0D:00
1c000200-1c0002ff : APMC0D06:00
1c021000-1c0210ff : APMC0D08:00
1c021000-1c02101f : serial
1c024000-1c024fff : APMC0D07:00
1f230000-1f230fff : APMC0D0D:00
1f230000-1f230fff : APMC0D0D:00
1f23d000-1f23dfff : APMC0D0D:00
1f23d000-1f23dfff : APMC0D0D:00
1f23e000-1f23efff : APMC0D0D:00
1f23e000-1f23efff : APMC0D0D:00
1f2a0000-1f31ffff : APMC0D06:00
1f500000-1f50ffff : PNP0A08:00
78800000-78800fff : APMC0D13:00
78800000-78800fff : APMC0D12:03
78800000-78800fff : APMC0D12:02
78800000-78800fff : APMC0D12:01
78800000-78800fff : APMC0D12:00
78800000-78800fff : APMC0D11:00
78800000-78800fff : APMC0D10:03
78800000-78800fff : APMC0D10:02
78800000-78800fff : APMC0D10:01
78800000-78800fff : APMC0D10:00
79000000-798fffff : APMC0D0E:00
7c000000-7c1fffff : APMC0D12:00
7c200000-7c3fffff : APMC0D12:01
7c400000-7c5fffff : APMC0D12:02
7c600000-7c7fffff : APMC0D12:03
7e000000-7e000fff : APMC0D13:00
7e200000-7e200fff : APMC0D10:03
7e200000-7e200fff : APMC0D10:02
7e200000-7e200fff : APMC0D10:01
7e200000-7e200fff : APMC0D10:00
7e600000-7e600fff : APMC0D11:00
7e700000-7e700fff : APMC0D10:03
7e700000-7e700fff : APMC0D10:02
7e700000-7e700fff : APMC0D10:01
7e700000-7e700fff : APMC0D10:00
7e720000-7e720fff : APMC0D10:03
7e720000-7e720fff : APMC0D10:02
7e720000-7e720fff : APMC0D10:01
7e720000-7e720fff : APMC0D10:00
7e800000-7e800fff : APMC0D10:00
7e840000-7e840fff : APMC0D10:01
7e880000-7e880fff : APMC0D10:02
7e8c0000-7e8c0fff : APMC0D10:03
7e930000-7e930fff : APMC0D13:00
4000000000-4001ffffff : System RAM
4000080000-4000c3ffff : Kernel code
4000db0000-400165ffff : Kernel data
40023a0000-4ff733ffff : System RAM
4ff7340000-4ff77cffff : reserved
4ff77d0000-4ff79cffff : System RAM
4ff79d0000-4ff7e7ffff : reserved
4ff7e80000-4ff7e8ffff : System RAM
4ff7e90000-4ff7efffff : reserved
4ff7f10000-4ff800ffff : reserved
4ff8010000-4fffffffff : System RAM
a020000000-a03fffffff : PCI Bus 0000:00
a020000000-a0201fffff : PCI Bus 0000:01
a020000000-a0200fffff : 0000:01:00.0
a020000000-a0200fffff : mlx4_core
a020100000-a0201fffff : 0000:01:00.0
a060000000-a07fffffff : PCI Bus 0000:00
a0d0000000-a0dfffffff : PCI ECAM
a110000000-a14fffffff : PCI Bus 0000:00
a110000000-a121ffffff : PCI Bus 0000:01
a110000000-a111ffffff : 0000:01:00.0
a110000000-a111ffffff : mlx4_core
a112000000-a121ffffff : 0000:01:00.0
Tested-by: Jon Masters <jcm@redhat.com>
--
Computer Architect | Sent from my Fedora powered laptop
^ permalink raw reply
* [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: Rob Herring @ 2016-12-05 23:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480687813.2460.19.camel@pengutronix.de>
On Fri, Dec 02, 2016 at 03:10:13PM +0100, Philipp Zabel wrote:
> Am Freitag, den 02.12.2016, 13:32 +0100 schrieb Arnd Bergmann:
> > On Friday, December 2, 2016 8:21:33 AM CET zhangfei wrote:
> > > Hi, Arnd
> > >
> > > On 2016?12?01? 20:05, Arnd Bergmann wrote:
> > > > On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
> > > >> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
> > > >> + 0x20 0x10 /* 1: i2c1 */
> > > >> + 0x20 0x20 /* 2: i2c2 */
> > > >> + 0x20 0x8000000>; /* 3: i2c6 */
> > > >> + };
> > > >> +
> > > >> +Specifying reset lines connected to IP modules
> > > >> +==============================================
> > > >> +example:
> > > >> +
> > > >> + i2c0: i2c at ..... {
> > > >> + ...
> > > >> + resets = <&iomcu_rst 0>;
> > > >> + ...
> > > >> + };
> > > > I don't really like this approach, since now the information is
> > > > in two places. Why not put the data into the reset specifier
> > > > directly when it is used?
>
> From my point of view, with the binding above, all reset controller
> register/bit layout information is in a single place and can be easily
> compared to a list in the reference manual, whereas with your suggestion
> the description of the reset controller register layout is spread
> throughout one or even several dtsi files.
Which can be solved by tools.
> Also, since no two reset controllers are exactly the same, we get a
> proliferation of different slightly phandle argument meanings.
phandle args are supposed to be specific to the phandle it points to.
Otherwise, we'd never need more than 1 cell and everything could be a
lookup table.
>
> > > Any example, still not understand.
> > > They are consumer and provider.
> >
> > I mean in the i2c node, have
> >
> > i2c0: i2c at ..... {
> > ...
> > resets = <&iomcu_rst 0x20 0x8>;
> > ...
> > }
>
> There already are a few drivers that use this, and I fear people having
> to change their bindings because new flags are needed that have not been
> previously thought of.
>
Drivers that use what?
Rob
^ permalink raw reply
* [PATCH 07/12] usb: sunxi: Uses the resource-managed extcon API when registering extcon notifier
From: Chanwoo Choi @ 2016-12-06 0:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205163240.GA5783@uda0271908>
On 2016? 12? 06? 01:32, Bin Liu wrote:
> On Wed, Nov 30, 2016 at 09:45:03AM +0100, Maxime Ripard wrote:
>> On Wed, Nov 30, 2016 at 02:57:35PM +0900, Chanwoo Choi wrote:
>>> This patch just uses the resource-managed extcon API when registering
>>> the extcon notifier.
>>>
>>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>>
>> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> It would be ideal if the subject was "usb: musb: sunxi: ...".
>
> Acked-by: Bin Liu <b-liu@ti.com>
>
Thanks for the review. I'll change the subject.
--
Best Regards,
Chanwoo Choi
^ permalink raw reply
* [PATCH] dt: bindings: zx: Add header for PM domains specifiers
From: Baoyou Xie @ 2016-12-06 0:21 UTC (permalink / raw)
To: linux-arm-kernel
This patch adds header with values used for ZTE 2967
SoC's power domain driver.
Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
---
include/dt-bindings/arm/zte_pm_domains.h | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
create mode 100644 include/dt-bindings/arm/zte_pm_domains.h
diff --git a/include/dt-bindings/arm/zte_pm_domains.h b/include/dt-bindings/arm/zte_pm_domains.h
new file mode 100644
index 0000000..1485e8d
--- /dev/null
+++ b/include/dt-bindings/arm/zte_pm_domains.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (C) 2015 Linaro Ltd.
+ *
+ * Author: Baoyou Xie <baoyou.xie@linaro.org>
+ * License terms: GNU General Public License (GPL) version 2
+ */
+#ifndef _DT_BINDINGS_ARM_ZTE_PM_DOMAINS_H
+#define _DT_BINDINGS_ARM_ZTE_PM_DOMAINS_H
+
+#define DM_ZX296718_SAPPU 0
+#define DM_ZX296718_VDE 1 /*g1v6*/
+#define DM_ZX296718_VCE 2 /*h1v6*/
+#define DM_ZX296718_HDE 3 /*g2v2*/
+#define DM_ZX296718_VIU 4
+#define DM_ZX296718_USB20 5
+#define DM_ZX296718_USB21 6
+#define DM_ZX296718_USB30 7
+#define DM_ZX296718_HSIC 8
+#define DM_ZX296718_GMAC 9
+#define DM_ZX296718_TS 10
+#define DM_ZX296718_VOU 11
+
+#endif /* _DT_BINDINGS_ARM_ZTE_PM_DOMAINS_H */
--
2.7.4
^ permalink raw reply related
* [PATCH 01/12] phy: rcar-gen3-usb2: Replace the deprecated extcon API
From: Chanwoo Choi @ 2016-12-06 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-2-git-send-email-cw00.choi@samsung.com>
Hi Kishon,
Could you review and pick the patch1/2 for phy driver?
Best Regards,
Chanwoo Choi
On 2016? 11? 30? 14:57, Chanwoo Choi wrote:
> This patch replaces the deprecated extcon API as following:
> - extcon_set_cable_state_() -> extcon_set_state_sync()
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> drivers/phy/phy-rcar-gen3-usb2.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/phy/phy-rcar-gen3-usb2.c b/drivers/phy/phy-rcar-gen3-usb2.c
> index bd2430d7339c..7f8081f157f4 100644
> --- a/drivers/phy/phy-rcar-gen3-usb2.c
> +++ b/drivers/phy/phy-rcar-gen3-usb2.c
> @@ -93,11 +93,11 @@ static void rcar_gen3_phy_usb2_work(struct work_struct *work)
> work);
>
> if (ch->extcon_host) {
> - extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, true);
> - extcon_set_cable_state_(ch->extcon, EXTCON_USB, false);
> + extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, true);
> + extcon_set_state_sync(ch->extcon, EXTCON_USB, false);
> } else {
> - extcon_set_cable_state_(ch->extcon, EXTCON_USB_HOST, false);
> - extcon_set_cable_state_(ch->extcon, EXTCON_USB, true);
> + extcon_set_state_sync(ch->extcon, EXTCON_USB_HOST, false);
> + extcon_set_state_sync(ch->extcon, EXTCON_USB, true);
> }
> }
>
>
^ permalink raw reply
* [PATCH 03/12] power_supply: axp288_charger: Replace the extcon API
From: Chanwoo Choi @ 2016-12-06 0:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480485460-2663-4-git-send-email-cw00.choi@samsung.com>
Hi Sebastian,
Could you please review and pick the patch3/4 for power-supply driver?
Best Regards,
Chanwoo Choi
On 2016? 11? 30? 14:57, Chanwoo Choi wrote:
> This patch uses the resource-managed extcon API for extcon_register_notifier()
> and replaces the deprecated extcon API as following:
> - extcon_get_cable_state_() -> extcon_get_state()
>
> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
> ---
> drivers/power/supply/axp288_charger.c | 51 +++++++++--------------------------
> 1 file changed, 13 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/power/supply/axp288_charger.c b/drivers/power/supply/axp288_charger.c
> index 75b8e0c7402b..1115052e9a69 100644
> --- a/drivers/power/supply/axp288_charger.c
> +++ b/drivers/power/supply/axp288_charger.c
> @@ -581,15 +581,15 @@ static void axp288_charger_extcon_evt_worker(struct work_struct *work)
> bool old_connected = info->cable.connected;
>
> /* Determine cable/charger type */
> - if (extcon_get_cable_state_(edev, EXTCON_CHG_USB_SDP) > 0) {
> + if (extcon_get_state(edev, EXTCON_CHG_USB_SDP) > 0) {
> dev_dbg(&info->pdev->dev, "USB SDP charger is connected");
> info->cable.connected = true;
> info->cable.chg_type = POWER_SUPPLY_TYPE_USB;
> - } else if (extcon_get_cable_state_(edev, EXTCON_CHG_USB_CDP) > 0) {
> + } else if (extcon_get_state(edev, EXTCON_CHG_USB_CDP) > 0) {
> dev_dbg(&info->pdev->dev, "USB CDP charger is connected");
> info->cable.connected = true;
> info->cable.chg_type = POWER_SUPPLY_TYPE_USB_CDP;
> - } else if (extcon_get_cable_state_(edev, EXTCON_CHG_USB_DCP) > 0) {
> + } else if (extcon_get_state(edev, EXTCON_CHG_USB_DCP) > 0) {
> dev_dbg(&info->pdev->dev, "USB DCP charger is connected");
> info->cable.connected = true;
> info->cable.chg_type = POWER_SUPPLY_TYPE_USB_DCP;
> @@ -686,7 +686,7 @@ static int axp288_charger_handle_otg_evt(struct notifier_block *nb,
> struct axp288_chrg_info *info =
> container_of(nb, struct axp288_chrg_info, otg.id_nb);
> struct extcon_dev *edev = info->otg.cable;
> - int usb_host = extcon_get_cable_state_(edev, EXTCON_USB_HOST);
> + int usb_host = extcon_get_state(edev, EXTCON_USB_HOST);
>
> dev_dbg(&info->pdev->dev, "external connector USB-Host is %s\n",
> usb_host ? "attached" : "detached");
> @@ -841,33 +841,27 @@ static int axp288_charger_probe(struct platform_device *pdev)
> /* Register for extcon notification */
> INIT_WORK(&info->cable.work, axp288_charger_extcon_evt_worker);
> info->cable.nb.notifier_call = axp288_charger_handle_cable_evt;
> - ret = extcon_register_notifier(info->cable.edev, EXTCON_CHG_USB_SDP,
> - &info->cable.nb);
> + ret = devm_extcon_register_notifier(&pdev->dev, info->cable.edev,
> + EXTCON_CHG_USB_SDP, &info->cable.nb);
> if (ret) {
> dev_err(&info->pdev->dev,
> "failed to register extcon notifier for SDP %d\n", ret);
> return ret;
> }
>
> - ret = extcon_register_notifier(info->cable.edev, EXTCON_CHG_USB_CDP,
> - &info->cable.nb);
> + ret = devm_extcon_register_notifier(&pdev->dev, info->cable.edev,
> + EXTCON_CHG_USB_CDP, &info->cable.nb);
> if (ret) {
> dev_err(&info->pdev->dev,
> "failed to register extcon notifier for CDP %d\n", ret);
> - extcon_unregister_notifier(info->cable.edev,
> - EXTCON_CHG_USB_SDP, &info->cable.nb);
> return ret;
> }
>
> - ret = extcon_register_notifier(info->cable.edev, EXTCON_CHG_USB_DCP,
> - &info->cable.nb);
> + ret = devm_extcon_register_notifier(&pdev->dev, info->cable.edev,
> + EXTCON_CHG_USB_DCP, &info->cable.nb);
> if (ret) {
> dev_err(&info->pdev->dev,
> "failed to register extcon notifier for DCP %d\n", ret);
> - extcon_unregister_notifier(info->cable.edev,
> - EXTCON_CHG_USB_SDP, &info->cable.nb);
> - extcon_unregister_notifier(info->cable.edev,
> - EXTCON_CHG_USB_CDP, &info->cable.nb);
> return ret;
> }
>
> @@ -887,13 +881,13 @@ static int axp288_charger_probe(struct platform_device *pdev)
> /* Register for OTG notification */
> INIT_WORK(&info->otg.work, axp288_charger_otg_evt_worker);
> info->otg.id_nb.notifier_call = axp288_charger_handle_otg_evt;
> - ret = extcon_register_notifier(info->otg.cable, EXTCON_USB_HOST,
> - &info->otg.id_nb);
> + ret = devm_extcon_register_notifier(&pdev->dev, info->otg.cable,
> + EXTCON_USB_HOST, &info->otg.id_nb);
> if (ret)
> dev_warn(&pdev->dev, "failed to register otg notifier\n");
>
> if (info->otg.cable)
> - info->otg.id_short = extcon_get_cable_state_(
> + info->otg.id_short = extcon_get_state(
> info->otg.cable, EXTCON_USB_HOST);
>
> /* Register charger interrupts */
> @@ -921,17 +915,8 @@ static int axp288_charger_probe(struct platform_device *pdev)
> return 0;
>
> intr_reg_failed:
> - if (info->otg.cable)
> - extcon_unregister_notifier(info->otg.cable, EXTCON_USB_HOST,
> - &info->otg.id_nb);
> power_supply_unregister(info->psy_usb);
> psy_reg_failed:
> - extcon_unregister_notifier(info->cable.edev, EXTCON_CHG_USB_SDP,
> - &info->cable.nb);
> - extcon_unregister_notifier(info->cable.edev, EXTCON_CHG_USB_CDP,
> - &info->cable.nb);
> - extcon_unregister_notifier(info->cable.edev, EXTCON_CHG_USB_DCP,
> - &info->cable.nb);
> return ret;
> }
>
> @@ -939,16 +924,6 @@ static int axp288_charger_remove(struct platform_device *pdev)
> {
> struct axp288_chrg_info *info = dev_get_drvdata(&pdev->dev);
>
> - if (info->otg.cable)
> - extcon_unregister_notifier(info->otg.cable, EXTCON_USB_HOST,
> - &info->otg.id_nb);
> -
> - extcon_unregister_notifier(info->cable.edev, EXTCON_CHG_USB_SDP,
> - &info->cable.nb);
> - extcon_unregister_notifier(info->cable.edev, EXTCON_CHG_USB_CDP,
> - &info->cable.nb);
> - extcon_unregister_notifier(info->cable.edev, EXTCON_CHG_USB_DCP,
> - &info->cable.nb);
> power_supply_unregister(info->psy_usb);
>
> return 0;
>
^ permalink raw reply
* [PATCH v3 3/4] dt-bindings: display: add Amlogic Meson DRM Bindings
From: Rob Herring @ 2016-12-06 0:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480583160-31806-4-git-send-email-narmstrong@baylibre.com>
On Thu, Dec 01, 2016 at 10:05:59AM +0100, Neil Armstrong wrote:
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../bindings/display/amlogic,meson-vpu.txt | 112 +++++++++++++++++++++
> 1 file changed, 112 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/amlogic,meson-vpu.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3 3/5] spi: armada-3700: Add documentation for the Armada 3700 SPI Controller
From: Rob Herring @ 2016-12-06 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161201102719.4291-4-romain.perier@free-electrons.com>
On Thu, Dec 01, 2016 at 11:27:17AM +0100, Romain Perier wrote:
> This adds the devicetree bindings documentation for the SPI controller
> present in the Marvell Armada 3700 SoCs.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
>
> Changes in v3:
> - Added tag "Tested-by" by Gregory
> - Fixed commit title, as requested by Mark Brown
>
> .../devicetree/bindings/spi/spi-armada-3700.txt | 25 ++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/spi/spi-armada-3700.txt
Didn't catch the duplicate with the subject change...
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCHv4 05/10] arm64: Use __pa_symbol for kernel symbols
From: Florian Fainelli @ 2016-12-06 0:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480445729-27130-6-git-send-email-labbott@redhat.com>
On 11/29/2016 10:55 AM, Laura Abbott wrote:
> __pa_symbol is technically the marco that should be used for kernel
> symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL which
> will do bounds checking. As part of this, introduce lm_alias, a
> macro which wraps the __va(__pa(...)) idiom used a few places to
> get the alias.
>
> Signed-off-by: Laura Abbott <labbott@redhat.com>
> ---
> v4: Stop calling __va early, conversion of a few more sites. I decided against
> wrapping the __p*d_populate calls into new functions since the call sites
> should be limited.
> ---
> - pud_populate(&init_mm, pud, bm_pmd);
> + if (pud_none(*pud))
> + __pud_populate(pud, __pa_symbol(bm_pmd), PMD_TYPE_TABLE);
> pmd = fixmap_pmd(addr);
> - pmd_populate_kernel(&init_mm, pmd, bm_pte);
> + __pmd_populate(pmd, __pa_symbol(bm_pte), PMD_TYPE_TABLE);
Is there a particular reason why pmd_populate_kernel() is not changed to
use __pa_symbol() instead of using __pa()? The other users in the arm64
kernel is arch/arm64/kernel/hibernate.c which seems to call this against
kernel symbols as well?
--
Florian
^ permalink raw reply
* [PATCH v2 1/2] arm64: dts: zx: Fix gic GICR property
From: Olof Johansson @ 2016-12-06 0:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161205022451.GA2749@dragon>
Hi Shawn,
On Sun, Dec 4, 2016 at 6:24 PM, Shawn Guo <shawnguo@kernel.org> wrote:
> Hi Arnd,
>
> On Fri, Dec 02, 2016 at 09:28:58PM +0100, Arnd Bergmann wrote:
>> Given that there is any concern about the patch now, and the merge
>> window is almost open, I'm moving both patches to the
>> next/fixes-non-critical branch and will merge it for v4.10 instead
>> of sending it for v4.9.
>>
>> If you end up deciding that the patch is wrong, please follow up
>> with a fix on top. Once the situation is resolved and the patch
>> merged upstream, feel free to ask stable at vger.kernel.org for a
>> backport to stable kernels to get it into v4.9.x.
>
> The patch is correct, though it can be cleaned up a bit further per
> Marc's suggestion. Since we now have 4.9-rc8, I'm wondering if we can
> still get this into 4.9 to save the stable kernel backport.
>
> I sent you a cleanup patch on top of this one yesterday. If you like,
> I can quickly resend the patch with the cleanup squashed.
Since the patches have already been applied, an incremental patch to
apply on top would work best here.
Thanks!
-Olof
^ permalink raw reply
* [resend v2: PATCH 1/2] dt-bindings: Document the hi3660 reset bindings
From: zhangfei @ 2016-12-06 1:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5982682.vMJxVociDa@wuerfel>
Hi, Arnd
On 2016?12?02? 20:32, Arnd Bergmann wrote:
> On Friday, December 2, 2016 8:21:33 AM CET zhangfei wrote:
>> Hi, Arnd
>>
>> On 2016?12?01? 20:05, Arnd Bergmann wrote:
>>> On Thursday, December 1, 2016 8:48:40 AM CET Zhangfei Gao wrote:
>>>> + hisi,reset-bits = <0x20 0x8 /* 0: i2c0 */
>>>> + 0x20 0x10 /* 1: i2c1 */
>>>> + 0x20 0x20 /* 2: i2c2 */
>>>> + 0x20 0x8000000>; /* 3: i2c6 */
>>>> + };
>>>> +
>>>> +Specifying reset lines connected to IP modules
>>>> +==============================================
>>>> +example:
>>>> +
>>>> + i2c0: i2c at ..... {
>>>> + ...
>>>> + resets = <&iomcu_rst 0>;
>>>> + ...
>>>> + };
>>> I don't really like this approach, since now the information is
>>> in two places. Why not put the data into the reset specifier
>>> directly when it is used?
>> Any example, still not understand.
>> They are consumer and provider.
> I mean in the i2c node, have
>
> i2c0: i2c at ..... {
> ...
> resets = <&iomcu_rst 0x20 0x8>;
> ...
> }
Got it.
There is function of_xlate in reset_controller_dev can parse the dts
when devm_reset_control_get
* @of_xlate: translation function to translate from specifier as found
in the
* device tree to id as given to the reset control ops
Will use this instead.
>>> Also the format seems a little too close to the actual register
>>> layout and could be a little more abstract, using bit numbers instead
>>> of a bitmask and register numbers instead of offsets.
>> We use bit numbers first.
>> But in the developing process, we found several bits may be required for
>> one driver.
>> And they may not be continuous as the bits may already be occupied.
>> Directly using offset, we can set several bits together for simple, to
>> give more flexibility.
>> So after discussion, we directly use offset.
> Can you give an example for why this is needed? Is this different
> from a device that has multiple reset lines?
Yes, we can use multiple reset lines, which is also our original method.
But it may have too many reset lines, like pcie driver will have 5 resets.
So just thinking it can be optimized.
However, when using of_xlate, parsing offset & bit to rstc->id (unsigned
int),
It only support u32, so will use bit numbers again.
rstc_id = rcdev->of_xlate(rcdev, &args);
Will update v3 patch, help take a look.
Thanks
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox