* [PATCH -next] cpufreq: brcmstb-avs-cpufreq: make symbol brcm_avs_cpufreq_attr static
From: Rafael J. Wysocki @ 2016-11-14 0:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGt4E5sQvRXdS+wh2jqa9jF4jxS9TxnULXwg1vJm1fwU-Gja4g@mail.gmail.com>
On Thursday, November 10, 2016 02:06:16 PM Markus Mayer wrote:
> On 10 November 2016 at 07:19, Wei Yongjun <weiyj.lk@gmail.com> wrote:
> > From: Wei Yongjun <weiyongjun1@huawei.com>
> >
> > Fixes the following sparse warning:
> >
> > drivers/cpufreq/brcmstb-avs-cpufreq.c:982:18: warning:
> > symbol 'brcm_avs_cpufreq_attr' was not declared. Should it be static?
>
> Yes, thanks for the fix.
>
> Acked-by: Markus Mayer <mmayer@broadcom.com>
Applied.
Thanks,
Rafael
^ permalink raw reply
* [PATCH] PM / AVS: rockchip-io: make the log more consistent
From: Rafael J. Wysocki @ 2016-11-14 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1883054.D2Rm2X9N2G@phil>
On Monday, October 10, 2016 10:15:50 PM Heiko Stuebner wrote:
> Am Montag, 10. Oktober 2016, 20:44:22 CEST schrieb Shawn Lin:
> > When testing SD hotplug automatically, I got bunch of
> > useless log like this:
> >
> > [ 588.357838] mmc0: card 0007 removed
> > [ 589.492664] rockchip-iodomain ff770000.syscon:io-domains: Setting to
> > 3300000 done [ 589.500698] vccio_sd: ramp_delay not set
> > [ 589.504817] rockchip-iodomain ff770000.syscon:io-domains: Setting to
> > 3300000 done [ 589.669705] rockchip-iodomain ff770000.syscon:io-domains:
> > Setting to 3300000 done [ 589.677593] vccio_sd: ramp_delay not set
> > [ 589.681581] rockchip-iodomain ff770000.syscon:io-domains: Setting to
> > 1800000 done [ 590.032820] dwmmc_rockchip ff0c0000.dwmmc: Successfully
> > tuned phase to 140 [ 590.039725] mmc0: new ultra high speed SDR50 SDHC
> > card at address 0007 [ 590.046641] mmcblk0: mmc0:0007 SD32G 29.3 GiB
> > [ 590.052163] mmcblk0: p1
> >
> > Moreover the code is intent to print the 'uV' for debug but
> > later print it using dev_info. It looks more like to me that
> > it should be the real intention of the code. Anyway, let's
> > mark this verbose log as debug message.
> >
> > Signed-off-by: Shawn Lin <shawn.lin@rock-chips.com>
>
> reducing the amount of logs, especially for information not generally needed
> looks sane
>
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>
>
> > ---
> >
> > drivers/power/avs/rockchip-io-domain.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/power/avs/rockchip-io-domain.c
> > b/drivers/power/avs/rockchip-io-domain.c index 01b6d3f..56bce19 100644
> > --- a/drivers/power/avs/rockchip-io-domain.c
> > +++ b/drivers/power/avs/rockchip-io-domain.c
> > @@ -143,7 +143,7 @@ static int rockchip_iodomain_notify(struct
> > notifier_block *nb, if (ret && event == REGULATOR_EVENT_PRE_VOLTAGE_CHANGE)
> > return NOTIFY_BAD;
> >
> > - dev_info(supply->iod->dev, "Setting to %d done\n", uV);
> > + dev_dbg(supply->iod->dev, "Setting to %d done\n", uV);
> > return NOTIFY_OK;
> > }
>
Applied (for v4.10).
Thanks,
Rafael
^ permalink raw reply
* [PATCH fpga 8/9] fpga socfpga: Use the scatterlist interface
From: Jason Gunthorpe @ 2016-11-14 0:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1611131712210.2735@atull-VirtualBox>
On Sun, Nov 13, 2016 at 05:19:34PM -0600, atull wrote:
> Currently or soon we have 3 drivers that don't really use the sg
> interface natively. So this workaround ends up in each of them?
Thinking of the SG list as a workaround is not really right - the SG
list is a way to pass memory stored in non-contiguous pages around,
and the miter is a way to access them from the CPU.
socfpga *does* use sg natively because it is happy to process the data
from the CPU page-at-time. It just doesn't use DMA.
> That's a lot of duplicated code. Why can't this code be in the
> fpga-mgr.c core for drivers that aren't using sg (to minimizing
> duplication).
Sure, if it is a common pattern it is a good idea to lift it.
I'd add a newop 'write_fragment' and a driver must define write_sg
write_fragment, if write_fragment is used then the core supplies
that loop.
Is there a tree with these new drivers someplace?
> I will test this when I get time, may not be this week. I just
> moved to a new building and lab and am in a course all week and
> so forth.
Sure, I don't expect any problems, Zynq uses the same loop and it
seems fine.
Jason
^ permalink raw reply
* [PATCH 3.16 122/346] arm64: Define AT_VECTOR_SIZE_ARCH for ARCH_DLINFO
From: Ben Hutchings @ 2016-11-14 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <lsq.1479082458.755945576@decadent.org.uk>
3.16.39-rc1 review patch. If anyone has any objections, please let me know.
------------------
From: James Hogan <james.hogan@imgtec.com>
commit 3146bc64d12377a74dbda12b96ea32da3774ae07 upstream.
AT_VECTOR_SIZE_ARCH should be defined with the maximum number of
NEW_AUX_ENT entries that ARCH_DLINFO can contain, but it wasn't defined
for arm64 at all even though ARCH_DLINFO will contain one NEW_AUX_ENT
for the VDSO address.
This shouldn't be a problem as AT_VECTOR_SIZE_BASE includes space for
AT_BASE_PLATFORM which arm64 doesn't use, but lets define it now and add
the comment above ARCH_DLINFO as found in several other architectures to
remind future modifiers of ARCH_DLINFO to keep AT_VECTOR_SIZE_ARCH up to
date.
Fixes: f668cd1673aa ("arm64: ELF definitions")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: linux-arm-kernel at lists.infradead.org
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
arch/arm64/include/asm/elf.h | 1 +
arch/arm64/include/uapi/asm/auxvec.h | 2 ++
2 files changed, 3 insertions(+)
--- a/arch/arm64/include/asm/elf.h
+++ b/arch/arm64/include/asm/elf.h
@@ -137,6 +137,7 @@ extern unsigned long randomize_et_dyn(un
#define SET_PERSONALITY(ex) clear_thread_flag(TIF_32BIT);
+/* update AT_VECTOR_SIZE_ARCH if the number of NEW_AUX_ENT entries changes */
#define ARCH_DLINFO \
do { \
NEW_AUX_ENT(AT_SYSINFO_EHDR, \
--- a/arch/arm64/include/uapi/asm/auxvec.h
+++ b/arch/arm64/include/uapi/asm/auxvec.h
@@ -19,4 +19,6 @@
/* vDSO location */
#define AT_SYSINFO_EHDR 33
+#define AT_VECTOR_SIZE_ARCH 1 /* entries in ARCH_DLINFO */
+
#endif
^ permalink raw reply
* [PATCH v2 06/19] ARM: dts: armada-370-xp: Fixup bootrom DT warning
From: Rob Herring @ 2016-11-14 0:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113212402.3060-7-gregory.clement@free-electrons.com>
On Sun, Nov 13, 2016 at 3:23 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> bootrom has a reg property so the unit name should contain an address.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
> ---
> arch/arm/boot/dts/armada-370.dtsi | 2 +-
> arch/arm/boot/dts/armada-xp.dtsi | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/armada-370.dtsi b/arch/arm/boot/dts/armada-370.dtsi
> index 079494e52554..7598fb013355 100644
> --- a/arch/arm/boot/dts/armada-370.dtsi
> +++ b/arch/arm/boot/dts/armada-370.dtsi
> @@ -65,7 +65,7 @@
> soc {
> compatible = "marvell,armada370-mbus", "simple-bus";
>
> - bootrom {
> + bootrom at 01_e0_0 {
Please add documentation as to what the unit address format is.
Really, since you claim compatibility with simple-bus, you should not
deviate from the simple-bus format.
Drop the leading zero and use ',' not '_'. I know the DT spec / ePAPR
allows more, but convention is more restricted.
Rob
> compatible = "marvell,bootrom";
> reg = <MBUS_ID(0x01, 0xe0) 0 0x100000>;
> };
^ permalink raw reply
* [RESEND PATCH v1 05/11] dt-bindings: perf: hisi: Add Devicetree bindings for Hisilicon SoC PMU
From: Anurup M @ 2016-11-14 0:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161110183040.GD10137@leverpostej>
On Friday 11 November 2016 12:00 AM, Mark Rutland wrote:
> Hi,
>
> On Thu, Nov 03, 2016 at 01:42:01AM -0400, Anurup M wrote:
>> 1) Device tree bindings for Hisilicon SoC PMU.
>> 2) Add example for Hisilicon L3 cache, MN and DDRC PMU.
>>
>> Signed-off-by: Anurup M<anurup.m@huawei.com>
>> Signed-off-by: Shaokun Zhang<zhangshaokun@hisilicon.com>
>> ---
>> .../devicetree/bindings/arm/hisilicon/pmu.txt | 127 +++++++++++++++++++++
>> 1 file changed, 127 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
>>
>> diff --git a/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
>> new file mode 100644
>> index 0000000..e7b35e0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/arm/hisilicon/pmu.txt
>> @@ -0,0 +1,127 @@
>> +Hisilicon SoC hip05/06/07 ARMv8 PMU
>> +===================================
>> +
>> +The Hisilicon SoC chips like hip05/06/07 etc. consist of varous independent
>> +system device PMU's such as L3 cache (L3C), Miscellaneous Nodes(MN) and DDR
> s/PMU's/PMUs/
OK.
>> +comtroller. These PMU devices are independent and have hardware logic to
> s/comtroller/controller/
>
>> +gather statistics and performance information.
>> +
>> +HiSilicon SoC chip is encapsulated by multiple CPU and IO die's. The CPU die
> s/die's/dies/
OK.
>> +is called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
>> +is further grouped as CPU clusters (CCL) which includes 4 cpu-cores each.
>> +e.g. In the case of hip05/06/07, each SCCL has 1 L3 cache and 1 MN PMU device.
>> +
>> +The Hisilicon SoC PMU DT node bindigs for uncore PMU devices are as below.
> s/bindigs/bindings/
OK. Thanks. I shall make sure with spell checker before sending v2.
>> +For PMU devices like L3 cache. MN etc. which are accessed using the djtag,
>> +the parent node will be the djtag node of the corresponding CPU die(SCCL).
>> +
>> +For uncore PMU devices there are some common required properties as detailed
>> +below.
>> +
>> +Required properties:
>> + - compatible : This field contain two values. The first value is
>> + always "hisilicon" and second value is the Module type as shown
>> + in below examples:
> Just say:
>
> - Compatible: should contain one of:
OK.
>> + (a) "hisilicon,hisi-pmu-l3c-v1" for Hisilicon SoC L3C PMU
>> + device (Version 1)
>> + (b) "hisilicon,hisi-pmu-mn-v1" for Hisilicon SoC MN PMU
>> + device (Version 1)
>> + (c) "hisilicon,hisi-pmu-ddrc-v1" for Hisilicon SoC DDRC PMU
>> + device (Version 1)
>> + The hip05/06/07 chips have v1 hardware for L3C, MN and DDRC.
>> +
>> + - scl-id : The Super Cluster ID. This can be the ID of the CPU die
>> + or IO die in the chip.
> What's this needed for?
This is used as suffix to the PMU name. hisi_l3c<scl-id>. (hisi_l3c2 -
for scl-id = 2).
This is to identify the pmu correspond to which CPU die in the socket.
>> + - num-events : No of events supported by this PMU device.
>> +
>> + - num-counters : No of hardware counters available for counting.
> This isn't probeable or well-known?
My idea is to have the common properties of SoC PMU added here.
The num-events, num-counters etc. So that handling can be made common in
the driver.
Is it not recommended? Please share your comments.
>> +
>> +L3 cache
>> +--------
>> +The L3 cache is dedicated for each SCCL and hence there are separate DT nodes
>> +for L3 cache for each SCCL. For L3 cache PMU the additional required properties
>> +are
>> + - counter-reg : Counter register offset.
>> +
>> + - evtype-reg : Event select register offset.
>> +
>> + - evctrl-reg : Event counting control(LAUCTRL) register offset.
> Surely for a given revision of the chip these offsets are known? i.e.
> surely the compatible string implies specific offsets?
>
>> + - event-en : Event enable value.
> Huh?
As for the hip05/06 and 07 chips, the above four properties are same, I
shall
move them to the driver.
The below two properties (module-id, cfgen-map) differs between chips
hip05/06 and hip07.
There were moved here so as to have minimal changes in driver across
chips hip05/06/07.
OR whether it is more recommended to have the of_device_id .data set
accordingly for handling
different chip versions?
Please suggest.
>> + - module-id : Module ID to input for djtag. This property is an array of
>> + module_id for each L3 cache banks.
>> +
>> + - num-banks : Number of banks or instances of the device.
> What's a bank? Surely they have separate instances of the PMU?
Yes each bank is a separate instance of PMU.
If it is recommended to have each L3 cache bank registered as separate
PMU with perf, then this property will be removed.
> What order are these in?
The bank number will start from "1" till "4" for L3 cache as there are
four banks in hip05/06/07 chips.
>> + - cfgen-map : Config enable array to select the bank.
> Huh?
>
>> +Miscellaneous Node
>> +-------------------
>> +The MN is dedicated for each SCCL and hence there are separate DT nodes for MN
>> +for each SCCL. For MN PMU the additional required properties are
>> + - counter-reg : Counter register offset.
>> +
>> + - evtype-reg : Event select register offset.
>> +
>> + - evctrl-reg : Event counting control register offset.
> Likewise, surely this is well-known for a given revision of the chip?
>
>> +
>> + - module-id : Module ID to input for djtag. As MN doesnot have multiple banks
>> + this property is a single value.
>> +
>> + - cfgen-map : Config enable to select the bank. For MN it is a single value
>> +
>> + - event-en : Event enable value.
> Same comments as for the L3 cache nodes
>
>
> [...]
>
>> +DDR controller
>> +--------------
>> +Each SCCL in Hip05/06/07 chips have 2 DDR channels and hence 2 DDR controllers.
>> +There are separate DT nodes for each DDR channel.
>> +For DDRC PMU the additional required properties are
>> +
>> + - ch-id : DDRC Channel ID.
> Why is this necessary?
This is used as suffix to the PMU name. hisi_ddrc<scl-id>_<ch-id>.
(hisi_ddrc2_0 - for scl-id = 2, ddrc channel = 0).
This is to identify the pmu correspond to which DDRC channel.
Thanks,
Anurup
> Thanks,
> Mark.
>
>> + - reg : Register base address and range for the DDRC channel.
>> +
>> +Example:
>> + /* DDRC for CPU die scl #2 Channel #1 for hip05 */
>> + pmu_sccl0_ddrc1: pmu_ddrc1 at 80358000 {
>> + compatible = "hisilicon,hisi-pmu-ddrc-v1";
>> + scl-id = <0x02>;
>> + ch-id = <0x1>;
>> + num-events = <0x0D>;
>> + num-counters = <0x04>;
>> + reg = <0x80358000 0x10000>; /* TOTEMC DDRC1 */
>> + };
>> --
>> 2.1.4
>>
^ permalink raw reply
* [PATCH fpga 8/9] fpga socfpga: Use the scatterlist interface
From: atull @ 2016-11-13 23:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478732303-13718-9-git-send-email-jgunthorpe@obsidianresearch.com>
On Wed, 9 Nov 2016, Jason Gunthorpe wrote:
> socfpga just uses the CPU to memory copy the bitstream, so there is
> no reason it needs contiguous kernel memory. Switch to use the sg
> interface.
>
> Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> ---
> drivers/fpga/socfpga.c | 56 +++++++++++++++++++++++++++++++++-----------------
> 1 file changed, 37 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c
> index 27d2ff28132c..f3f390b2eecf 100644
> --- a/drivers/fpga/socfpga.c
> +++ b/drivers/fpga/socfpga.c
> @@ -24,6 +24,7 @@
> #include <linux/of_address.h>
> #include <linux/of_irq.h>
> #include <linux/pm.h>
> +#include <linux/scatterlist.h>
>
> /* Register offsets */
> #define SOCFPGA_FPGMGR_STAT_OFST 0x0
> @@ -408,10 +409,22 @@ static int socfpga_fpga_reset(struct fpga_manager *mgr)
> * Prepare the FPGA to receive the configuration data.
> */
> static int socfpga_fpga_ops_configure_init(struct fpga_manager *mgr, u32 flags,
> - const char *buf, size_t count)
> + struct sg_table *sgt)
> {
> struct socfpga_fpga_priv *priv = mgr->priv;
> - int ret;
> + struct scatterlist *sg;
> + int ret, i;
> +
> + /* We use the CPU to read the bitstream 32 bits at a time, and thus
> + * require alignment.
> + */
> + for_each_sg(sgt->sgl, sg, sgt->nents, i) {
> + if ((sg->offset % 4) != 0) {
> + dev_err(&mgr->dev,
> + "Invalid bitstream, chunks must be aligned\n");
> + return -EINVAL;
> + }
> + }
>
> if (flags & FPGA_MGR_PARTIAL_RECONFIG) {
> dev_err(&mgr->dev, "Partial reconfiguration not supported.\n");
> @@ -440,40 +453,45 @@ static int socfpga_fpga_ops_configure_init(struct fpga_manager *mgr, u32 flags,
> /*
> * Step 9: write data to the FPGA data register
> */
> -static int socfpga_fpga_ops_configure_write(struct fpga_manager *mgr,
> - const char *buf, size_t count)
> +static void socfpga_write_buf(struct socfpga_fpga_priv *priv, const u32 *buf,
> + size_t count)
> {
> - struct socfpga_fpga_priv *priv = mgr->priv;
> - u32 *buffer_32 = (u32 *)buf;
> size_t i = 0;
>
> - if (count <= 0)
> - return -EINVAL;
> -
> /* Write out the complete 32-bit chunks. */
> while (count >= sizeof(u32)) {
> - socfpga_fpga_data_writel(priv, buffer_32[i++]);
> + socfpga_fpga_data_writel(priv, buf[i++]);
> count -= sizeof(u32);
> }
>
> /* Write out remaining non 32-bit chunks. */
> switch (count) {
> case 3:
> - socfpga_fpga_data_writel(priv, buffer_32[i++] & 0x00ffffff);
> + socfpga_fpga_data_writel(priv, buf[i++] & 0x00ffffff);
> break;
> case 2:
> - socfpga_fpga_data_writel(priv, buffer_32[i++] & 0x0000ffff);
> + socfpga_fpga_data_writel(priv, buf[i++] & 0x0000ffff);
> break;
> case 1:
> - socfpga_fpga_data_writel(priv, buffer_32[i++] & 0x000000ff);
> - break;
> - case 0:
> + socfpga_fpga_data_writel(priv, buf[i++] & 0x000000ff);
> break;
> default:
> - /* This will never happen. */
> - return -EFAULT;
> + break;
> }
> +}
> +
> +static int socfpga_fpga_ops_configure_write(struct fpga_manager *mgr,
> + struct sg_table *sgt)
> +{
> + struct socfpga_fpga_priv *priv = mgr->priv;
> + struct sg_mapping_iter miter;
> +
> + sg_miter_start(&miter, sgt->sgl, sgt->nents, SG_MITER_FROM_SG);
> +
> + while (sg_miter_next(&miter))
> + socfpga_write_buf(priv, miter.addr, miter.length);
>
> + sg_miter_stop(&miter);
> return 0;
> }
Hi Jason,
Currently or soon we have 3 drivers that don't really use the sg
interface natively. So this workaround ends up in each of them?
That's a lot of duplicated code. Why can't this code be in the
fpga-mgr.c core for drivers that aren't using sg (to minimizing
duplication).
I will test this when I get time, may not be this week. I just
moved to a new building and lab and am in a course all week and
so forth.
Alan
>
> @@ -545,8 +563,8 @@ static enum fpga_mgr_states socfpga_fpga_ops_state(struct fpga_manager *mgr)
>
> static const struct fpga_manager_ops socfpga_fpga_ops = {
> .state = socfpga_fpga_ops_state,
> - .write_init = socfpga_fpga_ops_configure_init,
> - .write = socfpga_fpga_ops_configure_write,
> + .write_init_sg = socfpga_fpga_ops_configure_init,
> + .write_sg = socfpga_fpga_ops_configure_write,
> .write_complete = socfpga_fpga_ops_configure_complete,
> };
>
> --
> 2.1.4
>
>
^ permalink raw reply
* [PATCH 4/4] fpga mgr: socfpga: Expose support for encrypted bitstreams
From: atull @ 2016-11-13 22:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161107001326.7395-5-moritz.fischer@ettus.com>
On Mon, 7 Nov 2016, Moritz Fischer wrote:
> Expose support for on the fly decryption of bitstreams.
> This needs no additional work or configuration,
> so just expose the new capability.
Hi Moritz,
When we talked about this, I was thinking about the arria10
support which I'd done more recently. c5 and a10 are
quite different here.
The c5 datasheet:
https://www.altera.com/literature/hb/cyclone-v/cv_5v4.pdf
Look for the 'stat' register on page 4-12 onwards. This
register exposes the setting of the msel pins (are a dipswitch
on some boards). The msel pins determine the programming
mode and whether it is expecting an encrypted and/or
compressed bitstream. So you could read this reg and
set the capabilities accordingly.
For arria10, encryption is enabled and if the bitstream
says it's encrypted, the driver handles it.
Alan
>
> Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
> Cc: Alan Tull <atull@opensource.altera.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: S?ren Brinkmann <soren.brinkmann@xilinx.com>
> Cc: linux-kernel at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org
> ---
>
> Alan,
>
> can you please let me know if that works this way, or where to find
> information on encrypted bitstreams? I have a CycloneV SoCFPGA to test
> on ...
>
> Cheers,
>
> Moritz
> ---
> drivers/fpga/socfpga.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/fpga/socfpga.c b/drivers/fpga/socfpga.c
> index fd9760c..ab57ec0c 100644
> --- a/drivers/fpga/socfpga.c
> +++ b/drivers/fpga/socfpga.c
> @@ -579,6 +579,7 @@ static int socfpga_fpga_probe(struct platform_device *pdev)
>
> fpga_mgr_cap_zero(&caps);
> fpga_mgr_cap_set(FPGA_MGR_CAP_FULL_RECONF, caps);
> + fpga_mgr_cap_set(FPGA_MGR_CAP_DECRYPT, caps);
>
> return fpga_mgr_register(dev, "Altera SOCFPGA FPGA Manager",
> &socfpga_fpga_ops, caps, priv);
> --
> 2.10.0
>
>
^ permalink raw reply
* [PATCH fpga 9/9] fpga: Remove support for non-sg drivers
From: Jason Gunthorpe @ 2016-11-13 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.10.1611131439190.2735@atull-VirtualBox>
On Sun, Nov 13, 2016 at 02:44:51PM -0600, atull wrote:
> > >> Would it not make sense to keep the top level API the same?
> > > Fundamentally no.
>
> NACK for now. Let's slow down here a bit.
>
> I don't see any rush in getting rid of the contiguous
> buffer interface.
As I explained to Joshua, until all the drivers support sg the public
sg interface can not be sensibly added, so it actually is a hard
blocker to making progress.
Further, the longer things are left, the more code will depend on the
broken interface and the harder it will be to ultimately fix. This is
a good time because there are only 2 upstream drivers, and I can test
one, you can test the other :)
> At the very least, my socfpga-a10 driver is using the old
> interface and has been just applied. And currently your
> socfpga changes are untested whereas my original driver
> has been in use and is known to work.
Well, looks like a10 uses the same write code as socfpga, so the patch
should trivially port over. Let me know if you need help.
Are you able to test the modified socfpga?
> Let's wait on that patch until we have quite a few FPGA's
> supported and can be sure that we won't miss the old
> interface.
Well, I am sure :) There is no reason to need this contiguous virtual
memory at the driver level. Our existing drivers demonstrate both how
to do DMA and PIO from the SG list, there really are no other transfer
modes supported by the kernel ...
But even if you are not sure, keeping the unused dead API around is
the exact opposite of the accepted kernel process. Read
stable-api-nonsense.txt and understand how that applies here.
The API can be revised again if a driver comes along that needs an
improvement, but given how intrinsically broken huge contiguous
allocations are, I can't forsee any situation where returning to this
interface would be a good idea.
Do you have comments on the other patches?
Jason
^ permalink raw reply
* [PATCH V7 3/3] irqchip: qcom: Add IRQ combiner driver
From: Agustin Vega-Frias @ 2016-11-13 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479074375-2629-1-git-send-email-agustinv@codeaurora.org>
Driver for interrupt combiners in the Top-level Control and Status
Registers (TCSR) hardware block in Qualcomm Technologies chips.
An interrupt combiner in this block combines a set of interrupts by
OR'ing the individual interrupt signals into a summary interrupt
signal routed to a parent interrupt controller, and provides read-
only, 32-bit registers to query the status of individual interrupts.
The status bit for IRQ n is bit (n % 32) within register (n / 32)
of the given combiner. Thus, each combiner can be described as a set
of register offsets and the number of IRQs managed.
Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
---
drivers/irqchip/Kconfig | 8 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/qcom-irq-combiner.c | 337 ++++++++++++++++++++++++++++++++++++
3 files changed, 346 insertions(+)
create mode 100644 drivers/irqchip/qcom-irq-combiner.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index bc0af33..610f902 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -279,3 +279,11 @@ config EZNPS_GIC
config STM32_EXTI
bool
select IRQ_DOMAIN
+
+config QCOM_IRQ_COMBINER
+ bool "QCOM IRQ combiner support"
+ depends on ARCH_QCOM
+ select IRQ_DOMAIN
+ help
+ Say yes here to add support for the IRQ combiner devices embedded
+ in Qualcomm Technologies chips.
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index e4dbfc8..1818a0b 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -74,3 +74,4 @@ obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
obj-$(CONFIG_EZNPS_GIC) += irq-eznps.o
obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o
obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
+obj-$(CONFIG_QCOM_IRQ_COMBINER) += qcom-irq-combiner.o
diff --git a/drivers/irqchip/qcom-irq-combiner.c b/drivers/irqchip/qcom-irq-combiner.c
new file mode 100644
index 0000000..fc25251
--- /dev/null
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -0,0 +1,337 @@
+/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+/*
+ * Driver for interrupt combiners in the Top-level Control and Status
+ * Registers (TCSR) hardware block in Qualcomm Technologies chips.
+ * An interrupt combiner in this block combines a set of interrupts by
+ * OR'ing the individual interrupt signals into a summary interrupt
+ * signal routed to a parent interrupt controller, and provides read-
+ * only, 32-bit registers to query the status of individual interrupts.
+ * The status bit for IRQ n is bit (n % 32) within register (n / 32)
+ * of the given combiner. Thus, each combiner can be described as a set
+ * of register offsets and the number of IRQs managed.
+ */
+
+#include <linux/acpi.h>
+#include <linux/irqchip/chained_irq.h>
+#include <linux/irqdomain.h>
+#include <linux/platform_device.h>
+
+#define REG_SIZE 32
+
+struct combiner_reg {
+ void __iomem *addr;
+ unsigned long mask;
+};
+
+struct combiner {
+ struct irq_chip irq_chip;
+ struct irq_domain *domain;
+ int parent_irq;
+ u32 nirqs;
+ u32 nregs;
+ struct combiner_reg regs[0];
+};
+
+static inline u32 irq_register(int irq)
+{
+ return irq / REG_SIZE;
+}
+
+static inline u32 irq_bit(int irq)
+{
+ return irq % REG_SIZE;
+
+}
+
+static inline int irq_nr(u32 reg, u32 bit)
+{
+ return reg * REG_SIZE + bit;
+}
+
+/*
+ * Handler for the cascaded IRQ.
+ */
+static void combiner_handle_irq(struct irq_desc *desc)
+{
+ struct combiner *combiner = irq_desc_get_handler_data(desc);
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ u32 reg;
+
+ chained_irq_enter(chip, desc);
+
+ for (reg = 0; reg < combiner->nregs; reg++) {
+ int virq;
+ int hwirq;
+ u32 bit;
+ u32 status;
+
+ if (combiner->regs[reg].mask == 0)
+ continue;
+
+ status = readl_relaxed(combiner->regs[reg].addr);
+ status &= combiner->regs[reg].mask;
+
+ while (status) {
+ bit = __ffs(status);
+ status &= ~(1 << bit);
+ hwirq = irq_nr(reg, bit);
+ virq = irq_find_mapping(combiner->domain, hwirq);
+ if (virq >= 0)
+ generic_handle_irq(virq);
+
+ }
+ }
+
+ chained_irq_exit(chip, desc);
+}
+
+/*
+ * irqchip callbacks
+ */
+
+static void combiner_irq_chip_mask_irq(struct irq_data *data)
+{
+ struct combiner *combiner = irq_data_get_irq_chip_data(data);
+ struct combiner_reg *reg = combiner->regs + irq_register(data->hwirq);
+
+ clear_bit(irq_bit(data->hwirq), ®->mask);
+}
+
+static void combiner_irq_chip_unmask_irq(struct irq_data *data)
+{
+ struct combiner *combiner = irq_data_get_irq_chip_data(data);
+ struct combiner_reg *reg = combiner->regs + irq_register(data->hwirq);
+
+ set_bit(irq_bit(data->hwirq), ®->mask);
+}
+
+/*
+ * irq_domain_ops callbacks
+ */
+
+static int combiner_irq_map(struct irq_domain *domain, unsigned int irq,
+ irq_hw_number_t hwirq)
+{
+ struct combiner *combiner = domain->host_data;
+
+ if (hwirq >= combiner->nirqs)
+ return -EINVAL;
+
+ irq_set_chip_and_handler(irq, &combiner->irq_chip, handle_level_irq);
+ irq_set_chip_data(irq, combiner);
+ irq_set_parent(irq, combiner->parent_irq);
+ irq_set_noprobe(irq);
+ return 0;
+}
+
+static void combiner_irq_unmap(struct irq_domain *domain, unsigned int irq)
+{
+ irq_set_chip_and_handler(irq, NULL, NULL);
+ irq_set_chip_data(irq, NULL);
+ irq_set_parent(irq, -1);
+}
+
+#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
+static int combiner_irq_translate(struct irq_domain *d, struct irq_fwspec *fws,
+ unsigned long *hwirq, unsigned int *type)
+{
+ if (is_acpi_node(fws->fwnode)) {
+ if (fws->param_count != 2)
+ return -EINVAL;
+
+ *hwirq = fws->param[0];
+ *type = fws->param[1];
+ return 0;
+ }
+
+ return -EINVAL;
+}
+#endif
+
+static const struct irq_domain_ops domain_ops = {
+ .map = combiner_irq_map,
+ .unmap = combiner_irq_unmap,
+#ifdef CONFIG_IRQ_DOMAIN_HIERARCHY
+ .translate = combiner_irq_translate
+#endif
+};
+
+/*
+ * Device probing
+ */
+
+#ifdef CONFIG_ACPI
+
+static acpi_status count_registers_cb(struct acpi_resource *ares, void *context)
+{
+ int *count = context;
+
+ if (ares->type == ACPI_RESOURCE_TYPE_GENERIC_REGISTER)
+ ++(*count);
+ return AE_OK;
+}
+
+static int count_registers(struct platform_device *pdev)
+{
+ struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
+ acpi_status status;
+ int count = 0;
+
+ if (!acpi_has_method(adev->handle, METHOD_NAME__CRS))
+ return -EINVAL;
+
+ status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
+ count_registers_cb, &count);
+ if (ACPI_FAILURE(status))
+ return -EINVAL;
+ return count;
+}
+
+struct get_registers_context {
+ struct device *dev;
+ struct combiner *combiner;
+ int err;
+};
+
+static acpi_status get_registers_cb(struct acpi_resource *ares, void *context)
+{
+ struct get_registers_context *ctx = context;
+ struct acpi_resource_generic_register *reg;
+ phys_addr_t paddr;
+ void __iomem *vaddr;
+
+ if (ares->type != ACPI_RESOURCE_TYPE_GENERIC_REGISTER)
+ return AE_OK;
+
+ reg = &ares->data.generic_reg;
+ paddr = reg->address;
+ if ((reg->space_id != ACPI_SPACE_MEM) ||
+ (reg->bit_offset != 0) ||
+ (reg->bit_width > REG_SIZE)) {
+ dev_err(ctx->dev, "Bad register resource @%pa\n", &paddr);
+ ctx->err = -EINVAL;
+ return AE_ERROR;
+ }
+
+ vaddr = devm_ioremap(ctx->dev, reg->address, REG_SIZE);
+ if (IS_ERR(vaddr)) {
+ dev_err(ctx->dev, "Can't map register @%pa\n", &paddr);
+ ctx->err = PTR_ERR(vaddr);
+ return AE_ERROR;
+ }
+
+ ctx->combiner->regs[ctx->combiner->nregs].addr = vaddr;
+ ctx->combiner->nirqs += reg->bit_width;
+ ctx->combiner->nregs++;
+ return AE_OK;
+}
+
+static int get_registers(struct platform_device *pdev, struct combiner *comb)
+{
+ struct acpi_device *adev = ACPI_COMPANION(&pdev->dev);
+ acpi_status status;
+ struct get_registers_context ctx;
+
+ if (!acpi_has_method(adev->handle, METHOD_NAME__CRS))
+ return -EINVAL;
+
+ ctx.dev = &pdev->dev;
+ ctx.combiner = comb;
+ ctx.err = 0;
+
+ status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS,
+ get_registers_cb, &ctx);
+ if (ACPI_FAILURE(status))
+ return ctx.err;
+ return 0;
+}
+
+#else /* !CONFIG_ACPI */
+
+static int count_registers(struct platform_device *pdev)
+{
+ return -EINVAL;
+}
+
+static int get_registers(struct platform_device *pdev, struct combiner *comb)
+{
+ return -EINVAL;
+}
+
+#endif
+
+static int __init combiner_probe(struct platform_device *pdev)
+{
+ struct combiner *combiner;
+ size_t alloc_sz;
+ u32 nregs;
+ int err;
+
+ nregs = count_registers(pdev);
+ if (nregs <= 0) {
+ dev_err(&pdev->dev, "Error reading register resources\n");
+ return -EINVAL;
+ }
+
+ alloc_sz = sizeof(*combiner) + sizeof(struct combiner_reg) * nregs;
+ combiner = devm_kzalloc(&pdev->dev, alloc_sz, GFP_KERNEL);
+ if (!combiner)
+ return -ENOMEM;
+
+ err = get_registers(pdev, combiner);
+ if (err < 0)
+ return err;
+
+ combiner->parent_irq = platform_get_irq(pdev, 0);
+ if (combiner->parent_irq <= 0) {
+ dev_err(&pdev->dev, "Error getting IRQ resource\n");
+ return -EINVAL;
+ }
+
+ combiner->domain = irq_domain_create_linear(
+ pdev->dev.fwnode, combiner->nirqs, &domain_ops, combiner);
+ if (!combiner->domain)
+ /* Errors printed by irq_domain_create_linear */
+ return -ENODEV;
+
+ irq_set_chained_handler_and_data(combiner->parent_irq,
+ combiner_handle_irq, combiner);
+ combiner->irq_chip.irq_mask = combiner_irq_chip_mask_irq;
+ combiner->irq_chip.irq_unmask = combiner_irq_chip_unmask_irq;
+ combiner->irq_chip.name = pdev->name;
+
+ dev_info(&pdev->dev, "Initialized with [p=%d,n=%d,r=%p]\n",
+ combiner->parent_irq, combiner->nirqs, combiner->regs[0].addr);
+ return 0;
+}
+
+static const struct acpi_device_id qcom_irq_combiner_acpi_match[] = {
+ { "QCOM80B1", },
+ { }
+};
+
+static struct platform_driver qcom_irq_combiner_probe = {
+ .driver = {
+ .name = "qcom-irq-combiner",
+ .owner = THIS_MODULE,
+ .acpi_match_table = ACPI_PTR(qcom_irq_combiner_acpi_match),
+ },
+ .probe = combiner_probe,
+};
+
+static int __init register_qcom_irq_combiner(void)
+{
+ return platform_driver_register(&qcom_irq_combiner_probe);
+}
+device_initcall(register_qcom_irq_combiner);
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH V7 2/3] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Agustin Vega-Frias @ 2016-11-13 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479074375-2629-1-git-send-email-agustinv@codeaurora.org>
When an Extended IRQ Resource contains a valid ResourceSource
use it to map the IRQ on the domain associated with the ACPI
device referenced.
With this in place an irqchip driver can create its domain using
irq_domain_create_linear and pass the device fwnode to create
the domain mapping. When dependent devices are probed these
changes allow the ACPI core find the domain and map the IRQ.
Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
---
drivers/acpi/Makefile | 2 +-
drivers/acpi/{gsi.c => irq.c} | 98 +++++++++++++++++++++++++++++++++++++------
drivers/acpi/resource.c | 29 +++++++------
include/linux/acpi.h | 19 +++++++++
4 files changed, 121 insertions(+), 27 deletions(-)
rename drivers/acpi/{gsi.c => irq.c} (53%)
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 9ed0878..a391bbc 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -55,7 +55,7 @@ acpi-$(CONFIG_DEBUG_FS) += debugfs.o
acpi-$(CONFIG_ACPI_NUMA) += numa.o
acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
acpi-y += acpi_lpat.o
-acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
+acpi-$(CONFIG_ACPI_GENERIC_GSI) += irq.o
acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
# These are (potentially) separate modules
diff --git a/drivers/acpi/gsi.c b/drivers/acpi/irq.c
similarity index 53%
rename from drivers/acpi/gsi.c
rename to drivers/acpi/irq.c
index ee9e0f2..c6ecaab 100644
--- a/drivers/acpi/gsi.c
+++ b/drivers/acpi/irq.c
@@ -18,6 +18,45 @@
static struct fwnode_handle *acpi_gsi_domain_id;
/**
+ * acpi_get_irq_source_fwhandle() - Retrieve the fwhandle of the given
+ * acpi_resource_source which is used
+ * to be used as an IRQ domain id
+ * @source: acpi_resource_source to use for the lookup
+ *
+ * Returns: The appropriate IRQ fwhandle domain id
+ * NULL on failure
+ */
+struct fwnode_handle *
+acpi_get_irq_source_fwhandle(const struct acpi_resource_source *source)
+{
+ struct fwnode_handle *result;
+ struct acpi_device *device;
+ acpi_handle handle;
+ acpi_status status;
+
+ if (!source->string_length)
+ return acpi_gsi_domain_id;
+
+ status = acpi_get_handle(NULL, source->string_ptr, &handle);
+ if (ACPI_FAILURE(status)) {
+ pr_warn("Could not find handle for %s\n", source->string_ptr);
+ return NULL;
+ }
+
+ device = acpi_bus_get_acpi_device(handle);
+ if (!device) {
+ pr_warn("Could not get device for %s\n", source->string_ptr);
+ return NULL;
+ }
+
+ result = &device->fwnode;
+ acpi_bus_put_acpi_device(device);
+
+ return result;
+}
+EXPORT_SYMBOL_GPL(acpi_get_irq_source_fwhandle);
+
+/**
* acpi_gsi_to_irq() - Retrieve the linux irq number for a given GSI
* @gsi: GSI IRQ number to map
* @irq: pointer where linux IRQ number is stored
@@ -42,6 +81,50 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
EXPORT_SYMBOL_GPL(acpi_gsi_to_irq);
/**
+ * acpi_register_irq() - Map a hardware to a linux IRQ number
+ * @source: IRQ source
+ * @hwirq: Hardware IRQ number
+ * @trigger: trigger type of the IRQ number to be mapped
+ * @polarity: polarity of the IRQ to be mapped
+ *
+ * Returns: a valid linux IRQ number on success
+ * -EINVAL on failure
+ */
+int acpi_register_irq(struct fwnode_handle *source, u32 hwirq, int trigger,
+ int polarity)
+{
+ struct irq_fwspec fwspec;
+
+ if (!source)
+ return -EINVAL;
+
+ if (irq_find_matching_fwnode(source, DOMAIN_BUS_ANY) == NULL)
+ return -EPROBE_DEFER;
+
+ fwspec.fwnode = source;
+ fwspec.param[0] = hwirq;
+ fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
+ fwspec.param_count = 2;
+
+ return irq_create_fwspec_mapping(&fwspec);
+}
+EXPORT_SYMBOL_GPL(acpi_register_irq);
+
+/**
+ * acpi_unregister_irq() - Free a Hardware IRQ<->linux IRQ number mapping
+ * @hwirq: Hardware IRQ number
+ */
+void acpi_unregister_irq(struct fwnode_handle *source, u32 hwirq)
+{
+ struct irq_domain *d = irq_find_matching_fwnode(source,
+ DOMAIN_BUS_ANY);
+ int irq = irq_find_mapping(d, hwirq);
+
+ irq_dispose_mapping(irq);
+}
+EXPORT_SYMBOL_GPL(acpi_unregister_irq);
+
+/**
* acpi_register_gsi() - Map a GSI to a linux IRQ number
* @dev: device for which IRQ has to be mapped
* @gsi: GSI IRQ number
@@ -54,19 +137,12 @@ int acpi_gsi_to_irq(u32 gsi, unsigned int *irq)
int acpi_register_gsi(struct device *dev, u32 gsi, int trigger,
int polarity)
{
- struct irq_fwspec fwspec;
-
if (WARN_ON(!acpi_gsi_domain_id)) {
pr_warn("GSI: No registered irqchip, giving up\n");
return -EINVAL;
}
- fwspec.fwnode = acpi_gsi_domain_id;
- fwspec.param[0] = gsi;
- fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
- fwspec.param_count = 2;
-
- return irq_create_fwspec_mapping(&fwspec);
+ return acpi_register_irq(acpi_gsi_domain_id, gsi, trigger, polarity);
}
EXPORT_SYMBOL_GPL(acpi_register_gsi);
@@ -76,11 +152,7 @@ int acpi_register_gsi(struct device *dev, u32 gsi, int trigger,
*/
void acpi_unregister_gsi(u32 gsi)
{
- struct irq_domain *d = irq_find_matching_fwnode(acpi_gsi_domain_id,
- DOMAIN_BUS_ANY);
- int irq = irq_find_mapping(d, gsi);
-
- irq_dispose_mapping(irq);
+ acpi_unregister_irq(acpi_gsi_domain_id, gsi);
}
EXPORT_SYMBOL_GPL(acpi_unregister_gsi);
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 4beda15..83cff00 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -374,21 +374,22 @@ unsigned int acpi_dev_get_irq_type(int triggering, int polarity)
}
EXPORT_SYMBOL_GPL(acpi_dev_get_irq_type);
-static void acpi_dev_irqresource_disabled(struct resource *res, u32 gsi)
+static void acpi_dev_irqresource_disabled(struct resource *res, u32 hwirq)
{
- res->start = gsi;
- res->end = gsi;
+ res->start = hwirq;
+ res->end = hwirq;
res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
}
-static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
+static void acpi_dev_get_irqresource(struct resource *res, u32 hwirq,
+ struct fwnode_handle *source,
u8 triggering, u8 polarity, u8 shareable,
bool legacy)
{
int irq, p, t;
- if (!valid_IRQ(gsi)) {
- acpi_dev_irqresource_disabled(res, gsi);
+ if (!source && !valid_IRQ(hwirq)) {
+ acpi_dev_irqresource_disabled(res, hwirq);
return;
}
@@ -402,25 +403,25 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
* using extended IRQ descriptors we take the IRQ configuration
* from _CRS directly.
*/
- if (legacy && !acpi_get_override_irq(gsi, &t, &p)) {
+ if (legacy && !acpi_get_override_irq(hwirq, &t, &p)) {
u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
if (triggering != trig || polarity != pol) {
- pr_warning("ACPI: IRQ %d override to %s, %s\n", gsi,
- t ? "level" : "edge", p ? "low" : "high");
+ pr_warn("ACPI: IRQ %d override to %s, %s\n", hwirq,
+ t ? "level" : "edge", p ? "low" : "high");
triggering = trig;
polarity = pol;
}
}
res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
- irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
+ irq = acpi_register_irq(source, hwirq, triggering, polarity);
if (irq >= 0) {
res->start = irq;
res->end = irq;
} else {
- acpi_dev_irqresource_disabled(res, gsi);
+ acpi_dev_irqresource_disabled(res, hwirq);
}
}
@@ -448,6 +449,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
{
struct acpi_resource_irq *irq;
struct acpi_resource_extended_irq *ext_irq;
+ struct fwnode_handle *src;
switch (ares->type) {
case ACPI_RESOURCE_TYPE_IRQ:
@@ -460,7 +462,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
acpi_dev_irqresource_disabled(res, 0);
return false;
}
- acpi_dev_get_irqresource(res, irq->interrupts[index],
+ acpi_dev_get_irqresource(res, irq->interrupts[index], NULL,
irq->triggering, irq->polarity,
irq->sharable, true);
break;
@@ -470,7 +472,8 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
acpi_dev_irqresource_disabled(res, 0);
return false;
}
- acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
+ src = acpi_get_irq_source_fwhandle(&ext_irq->resource_source);
+ acpi_dev_get_irqresource(res, ext_irq->interrupts[index], src,
ext_irq->triggering, ext_irq->polarity,
ext_irq->sharable, false);
break;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 325bdb9..1099b51 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -321,6 +321,25 @@ void acpi_set_irq_model(enum acpi_irq_model_id model,
*/
void acpi_unregister_gsi (u32 gsi);
+#ifdef CONFIG_ACPI_GENERIC_GSI
+struct fwnode_handle *
+acpi_get_irq_source_fwhandle(const struct acpi_resource_source *source);
+int acpi_register_irq(struct fwnode_handle *source, u32 hwirq, int trigger,
+ int polarity);
+void acpi_unregister_irq(struct fwnode_handle *source, u32 hwirq);
+#else
+#define acpi_get_irq_source_fwhandle(source) (NULL)
+static inline int acpi_register_irq(struct fwnode_handle *source, u32 hwirq,
+ int trigger, int polarity)
+{
+ return acpi_register_gsi(NULL, hwirq, trigger, polarity);
+}
+static inline void acpi_unregister_irq(struct fwnode_handle *source, u32 hwirq)
+{
+ acpi_unregister_gsi(hwirq);
+}
+#endif
+
struct pci_dev;
int acpi_pci_irq_enable (struct pci_dev *dev);
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH V7 1/3] ACPI: Retry IRQ conversion if it failed previously
From: Agustin Vega-Frias @ 2016-11-13 21:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479074375-2629-1-git-send-email-agustinv@codeaurora.org>
This allows probe deferral to work properly when a dependent device
fails to get a valid IRQ because the IRQ domain was not registered
at the time the resources were added to the platform_device.
Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
---
drivers/acpi/resource.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++
drivers/base/platform.c | 9 +++++++-
include/linux/acpi.h | 7 ++++++
3 files changed, 74 insertions(+), 1 deletion(-)
diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
index 56241eb..4beda15 100644
--- a/drivers/acpi/resource.c
+++ b/drivers/acpi/resource.c
@@ -664,3 +664,62 @@ int acpi_dev_filter_resource_type(struct acpi_resource *ares,
return (type & types) ? 0 : 1;
}
EXPORT_SYMBOL_GPL(acpi_dev_filter_resource_type);
+
+struct acpi_irq_get_ctx {
+ unsigned int index;
+ struct resource *res;
+};
+
+static acpi_status acpi_irq_get_cb(struct acpi_resource *ares, void *context)
+{
+ struct acpi_irq_get_ctx *ctx = context;
+ struct acpi_resource_irq *irq;
+ struct acpi_resource_extended_irq *ext_irq;
+
+ switch (ares->type) {
+ case ACPI_RESOURCE_TYPE_IRQ:
+ irq = &ares->data.irq;
+ if (ctx->index < irq->interrupt_count) {
+ acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
+ return AE_CTRL_TERMINATE;
+ }
+ ctx->index -= irq->interrupt_count;
+ break;
+ case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
+ ext_irq = &ares->data.extended_irq;
+ if (ctx->index < ext_irq->interrupt_count) {
+ acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
+ return AE_CTRL_TERMINATE;
+ }
+ ctx->index -= ext_irq->interrupt_count;
+ break;
+ }
+
+ return AE_OK;
+}
+
+/**
+ * acpi_irq_get - Look for the ACPI IRQ resource with the given index and
+ * use it to initialize the given Linux IRQ resource.
+ * @handle ACPI device handle
+ * @index ACPI IRQ resource index to lookup
+ * @res Linux IRQ resource to initialize
+ *
+ * Return: 0 on success
+ * -EINVAL if an error occurs
+ * -EPROBE_DEFER if the IRQ lookup/conversion failed
+ */
+int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res)
+{
+ struct acpi_irq_get_ctx ctx = { index, res };
+ acpi_status status;
+
+ status = acpi_walk_resources(handle, METHOD_NAME__CRS,
+ acpi_irq_get_cb, &ctx);
+ if (ACPI_FAILURE(status))
+ return -EINVAL;
+ if (res->flags & IORESOURCE_DISABLED)
+ return -EPROBE_DEFER;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(acpi_irq_get);
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index c4af003..61423d2 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -102,6 +102,14 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
}
r = platform_get_resource(dev, IORESOURCE_IRQ, num);
+ if (r && r->flags & IORESOURCE_DISABLED && ACPI_COMPANION(&dev->dev)) {
+ int ret;
+
+ ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
+ if (ret)
+ return ret;
+ }
+
/*
* The resources may pass trigger flags to the irqs that need
* to be set up. It so happens that the trigger flags for
@@ -1450,4 +1458,3 @@ void __init early_platform_cleanup(void)
memset(&pd->dev.devres_head, 0, sizeof(pd->dev.devres_head));
}
}
-
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 689a8b9..325bdb9 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -406,6 +406,7 @@ bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
unsigned int acpi_dev_get_irq_type(int triggering, int polarity);
bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
struct resource *res);
+int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res);
void acpi_dev_free_resource_list(struct list_head *list);
int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
@@ -763,6 +764,12 @@ static inline int acpi_reconfig_notifier_unregister(struct notifier_block *nb)
return -EINVAL;
}
+static inline int acpi_irq_get(acpi_handle handle, unsigned int index,
+ struct resource *res)
+{
+ return -EINVAL;
+}
+
#endif /* !CONFIG_ACPI */
#ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH V7 0/3] irqchip: qcom: Add IRQ combiner driver
From: Agustin Vega-Frias @ 2016-11-13 21:59 UTC (permalink / raw)
To: linux-arm-kernel
Add support for IRQ combiners in the Top-level Control and Status
Registers (TCSR) hardware block in Qualcomm Technologies chips.
The first patch fixes IRQ probe deferral by allowing platform_device
IRQ resources to be re-initialized if the ACPI core failed to find
the IRQ domain during ACPI bus scan.
The second patch adds support for ResourceSource/IRQ domain mapping
when using Extended IRQ Resources with a specific ResourceSource.
These changes are conditional on the ACPI_GENERIC_GSI config.
The third patch takes advantage of the new capabilities to implement
the driver for the IRQ combiners.
Tested on top of v4.9-rc4.
Changes V6 -> V7:
* Consolidate changes for ResourceSource/IRQ domain mapping to the same
source file implementing the generic GSI support, making it conditional
on CONFIG_ACPI_GENERIC_GSI.
* Eliminate some code duplication by implementing acpi_register_gsi in
terms of the new acpi_register_irq API.
Changes V5 -> V6:
* Drop probe table and on-demand probing based on resource_source
* Add patch to fix probe deferral
* Change back combiner driver to use the platform_device/platform_driver
APIs
Agustin Vega-Frias (3):
ACPI: Retry IRQ conversion if it failed previously
ACPI: Add support for ResourceSource/IRQ domain mapping
irqchip: qcom: Add IRQ combiner driver
drivers/acpi/Makefile | 2 +-
drivers/acpi/{gsi.c => irq.c} | 98 +++++++++--
drivers/acpi/resource.c | 88 ++++++++--
drivers/base/platform.c | 9 +-
drivers/irqchip/Kconfig | 8 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/qcom-irq-combiner.c | 337 ++++++++++++++++++++++++++++++++++++
include/linux/acpi.h | 26 +++
8 files changed, 541 insertions(+), 28 deletions(-)
rename drivers/acpi/{gsi.c => irq.c} (53%)
create mode 100644 drivers/irqchip/qcom-irq-combiner.c
--
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v3] crypto: arm64/sha2: integrate OpenSSL implementations of SHA256/SHA512
From: Andy Polyakov @ 2016-11-13 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c82fd8f0-5c0e-74d9-fbf3-b2a5c0dc3a1c@openssl.org>
>>>>> Looking at the generated code, I see references to __ARMEB__ and
>>>> __ILP32__.
>>>>> The former is probably a bug,
>>>
>>> Oh! You mean that it should be __AARCH64EB__/__AARCH64EL__!
>>
>> Indeed:
>>
>> $ aarch64-linux-gnu-gcc -dM -E - <<<"" |grep AARCH
>> #define __AARCH64_CMODEL_SMALL__ 1
>> #define __AARCH64EL__ 1
>>
>> $ aarch64-linux-gnu-gcc -dM -E -mbig-endian - <<<"" |grep AARCH
>> #define __AARCH64_CMODEL_SMALL__ 1
>> #define __AARCH64EB__ 1
>
> As it turns out it wasn't really an overlook, at least not in OpenSSL
> context, as I force __ARMEB__/__ARMEL__ in 64-bit build through
> arm_arch.h, which in turn is shared between 32- and 64-bit builds. But
> shared code should be preferred to be self-sufficient. It doesn't mean
> that it won't be fixed, only that it wasn't really a bug in OpenSSL context.
>
https://github.com/openssl/openssl/pull/1914.
^ permalink raw reply
* [PATCH v2 13/13] ARM: dts: armada-375: Fixup ethernet child DT warning
From: Gregory CLEMENT @ 2016-11-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113213234.3368-1-gregory.clement@free-electrons.com>
Child of mvpp2 ethernet do not have a reg property so the unit name
should not contain an address: remove them.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 0a3fff844c17..f54220099202 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -224,13 +224,13 @@
clock-names = "pp_clk", "gop_clk";
status = "disabled";
- eth0: eth0 at c4000 {
+ eth0: eth0 {
interrupts = <GIC_SPI 37 IRQ_TYPE_LEVEL_HIGH>;
port-id = <0>;
status = "disabled";
};
- eth1: eth1 at c5000 {
+ eth1: eth1 {
interrupts = <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
port-id = <1>;
status = "disabled";
--
2.10.2
^ permalink raw reply related
* [PATCH v2 12/13] ARM: dts: armada-375: Fixup memory DT warning
From: Gregory CLEMENT @ 2016-11-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113213234.3368-1-gregory.clement@free-electrons.com>
memory has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375-db.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index c92c1df9d01a..8f3e0a51c12c 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -58,7 +58,7 @@
stdout-path = "serial0:115200n8";
};
- memory {
+ memory at 0 {
device_type = "memory";
reg = <0x00000000 0x40000000>; /* 1 GB */
};
--
2.10.2
^ permalink raw reply related
* [PATCH v2 11/13] ARM: dts: armada-375: Remove skeleton.dtsi
From: Gregory CLEMENT @ 2016-11-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113213234.3368-1-gregory.clement@free-electrons.com>
The skeleton.dtsi file was removed in ARM64 for different reasons as
explained in commit ("3ebee5a2e141 arm64: dts: kill skeleton.dtsi").
These also applies to ARM and it will also allow to get rid of the
following DTC warnings in the future:
"Node /memory has a reg or ranges property, but no unit name"
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 9e61351a58c2..0a3fff844c17 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -45,7 +45,6 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include "skeleton.dtsi"
#include <dt-bindings/interrupt-controller/arm-gic.h>
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/phy/phy.h>
@@ -53,6 +52,9 @@
#define MBUS_ID(target,attributes) (((target) << 24) | ((attributes) << 16))
/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+
model = "Marvell Armada 375 family SoC";
compatible = "marvell,armada375";
--
2.10.2
^ permalink raw reply related
* [PATCH v2 10/13] ARM: dts: armada-375: Fixup internal-regs DT warning
From: Gregory CLEMENT @ 2016-11-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113213234.3368-1-gregory.clement@free-electrons.com>
internal-regs has a ranges property so the unit name should contain an
address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 4e510489a9b9..9e61351a58c2 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -165,7 +165,7 @@
status = "disabled";
};
- internal-regs {
+ internal-regs at f0_01_0 {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <1>;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 09/13] ARM: dts: armada-375: Fixup soc DT warning
From: Gregory CLEMENT @ 2016-11-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113213234.3368-1-gregory.clement@free-electrons.com>
soc has a ranges property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375-db.dts | 2 +-
arch/arm/boot/dts/armada-375.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375-db.dts b/arch/arm/boot/dts/armada-375-db.dts
index b33a674088ed..c92c1df9d01a 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -63,7 +63,7 @@
reg = <0x00000000 0x40000000>; /* 1 GB */
};
- soc {
+ soc at f0_01_0 {
ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index aedd74ee6f6b..4e510489a9b9 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -101,7 +101,7 @@
interrupts-extended = <&mpic 3>;
};
- soc {
+ soc at f0_01_0 {
compatible = "marvell,armada375-mbus", "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 08/13] ARM: dts: armada-375: Fixup pinctrl DT warnings
From: Gregory CLEMENT @ 2016-11-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113213234.3368-1-gregory.clement@free-electrons.com>
pinctrl has a ranges property, so the unit name should contain an
address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 4824a4c1883c..aedd74ee6f6b 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -307,7 +307,7 @@
status = "disabled";
};
- pinctrl: pinctrl {
+ pinctrl: pinctrl at 18000 {
compatible = "marvell,mv88f6720-pinctrl";
reg = <0x18000 0x24>;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 07/13] ARM: dts: armada-375: Fixup pcie DT warnings
From: Gregory CLEMENT @ 2016-11-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113213234.3368-1-gregory.clement@free-electrons.com>
PCIe has a range property, so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index ba9d7d64221c..4824a4c1883c 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -580,7 +580,7 @@
};
};
- pciec: pcie-controller {
+ pciec: pcie-controller at 82000000 {
compatible = "marvell,armada-370-pcie";
status = "disabled";
device_type = "pci";
--
2.10.2
^ permalink raw reply related
* [PATCH v2 06/13] ARM: dts: armada-375: Fixup sa-ram DT warning
From: Gregory CLEMENT @ 2016-11-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113213234.3368-1-gregory.clement@free-electrons.com>
sa-sram which is a mmio-sram has a reg property so the unit name should
contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index e83eaa39e7ea..ba9d7d64221c 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -635,7 +635,7 @@
};
- crypto_sram0: sa-sram0 {
+ crypto_sram0: sa-sram at 09_09_0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x09) 0 0x800>;
clocks = <&gateclk 30>;
@@ -644,7 +644,7 @@
ranges = <0 MBUS_ID(0x09, 0x09) 0 0x800>;
};
- crypto_sram1: sa-sram1 {
+ crypto_sram1: sa-sram at 09_05_0 {
compatible = "mmio-sram";
reg = <MBUS_ID(0x09, 0x05) 0 0x800>;
clocks = <&gateclk 31>;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 05/13] ARM: dts: armada-375: Fixup devbus DT warning
From: Gregory CLEMENT @ 2016-11-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113213234.3368-1-gregory.clement@free-electrons.com>
devbus has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index f7e553eeb685..e83eaa39e7ea 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -115,7 +115,7 @@
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
- devbus_bootcs: devbus-bootcs {
+ devbus_bootcs: devbus-bootcs at f0_01_10400 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10400 0x8>;
ranges = <0 MBUS_ID(0x01, 0x2f) 0 0xffffffff>;
@@ -125,7 +125,7 @@
status = "disabled";
};
- devbus_cs0: devbus-cs0 {
+ devbus_cs0: devbus-cs at f0_01_10408 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10408 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3e) 0 0xffffffff>;
@@ -135,7 +135,7 @@
status = "disabled";
};
- devbus_cs1: devbus-cs1 {
+ devbus_cs1: devbus-cs at f0_01_10410 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10410 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3d) 0 0xffffffff>;
@@ -145,7 +145,7 @@
status = "disabled";
};
- devbus_cs2: devbus-cs2 {
+ devbus_cs2: devbus-cs at f0_01_10418 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10418 0x8>;
ranges = <0 MBUS_ID(0x01, 0x3b) 0 0xffffffff>;
@@ -155,7 +155,7 @@
status = "disabled";
};
- devbus_cs3: devbus-cs3 {
+ devbus_cs3: devbus-cs at f0_01_10420 {
compatible = "marvell,mvebu-devbus";
reg = <MBUS_ID(0xf0, 0x01) 0x10420 0x8>;
ranges = <0 MBUS_ID(0x01, 0x37) 0 0xffffffff>;
--
2.10.2
^ permalink raw reply related
* [PATCH v2 04/13] ARM: dts: armada-375: Fixup bootrom DT warning
From: Gregory CLEMENT @ 2016-11-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113213234.3368-1-gregory.clement@free-electrons.com>
bootrom has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index 97b663d83fb6..f7e553eeb685 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -110,7 +110,7 @@
pcie-mem-aperture = <0xe0000000 0x8000000>;
pcie-io-aperture = <0xe8000000 0x100000>;
- bootrom {
+ bootrom at 01_1d_0 {
compatible = "marvell,bootrom";
reg = <MBUS_ID(0x01, 0x1d) 0 0x100000>;
};
--
2.10.2
^ permalink raw reply related
* [PATCH v2 03/13] ARM: dts: armada-375: Fixup mdio DT warning
From: Gregory CLEMENT @ 2016-11-13 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161113213234.3368-1-gregory.clement@free-electrons.com>
MDIO has a reg property so the unit name should contain an address.
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
---
arch/arm/boot/dts/armada-375.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/armada-375.dtsi b/arch/arm/boot/dts/armada-375.dtsi
index e016ff3ed970..97b663d83fb6 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -203,7 +203,7 @@
<0xc100 0x100>;
};
- mdio: mdio {
+ mdio: mdio at c0054 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "marvell,orion-mdio";
--
2.10.2
^ 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