* [PATCH v8 02/16] drivers: acpi: iort: introduce linker section for IORT entries probing
From: Lorenzo Pieralisi @ 2016-11-16 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116152936.22955-1-lorenzo.pieralisi@arm.com>
Since commit e647b532275b ("ACPI: Add early device probing
infrastructure") the kernel has gained the infrastructure that allows
adding linker script section entries to execute ACPI driver callbacks
(ie probe routines) for all subsystems that register a table entry
in the respective kernel section (eg clocksource, irqchip).
Since ARM IOMMU devices data is described through IORT tables when
booting with ACPI, the ARM IOMMU drivers must be made able to hook ACPI
callback routines that are called to probe IORT entries and initialize
the respective IOMMU devices.
To avoid adding driver specific hooks into IORT table initialization
code (breaking therefore code modularity - ie ACPI IORT code must be made
aware of ARM SMMU drivers ACPI init callbacks), this patch adds code
that allows ARM SMMU drivers to take advantage of the ACPI early probing
infrastructure, so that they can add linker script section entries
containing drivers callback to be executed on IORT tables detection.
Since IORT nodes are differentiated by a type, the callback routines
can easily parse the IORT table entries, check the IORT nodes and
carry out some actions whenever the IORT node type associated with
the driver specific callback is matched.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: Tomasz Nowicki <tn@semihalf.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/acpi/arm64/iort.c | 13 ++++++++++---
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/acpi_iort.h | 3 +++
3 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/arm64/iort.c b/drivers/acpi/arm64/iort.c
index 6b81746..2c46ebc 100644
--- a/drivers/acpi/arm64/iort.c
+++ b/drivers/acpi/arm64/iort.c
@@ -361,8 +361,15 @@ void __init acpi_iort_init(void)
acpi_status status;
status = acpi_get_table(ACPI_SIG_IORT, 0, &iort_table);
- if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
- const char *msg = acpi_format_exception(status);
- pr_err("Failed to get table, %s\n", msg);
+ if (ACPI_FAILURE(status)) {
+ if (status != AE_NOT_FOUND) {
+ const char *msg = acpi_format_exception(status);
+
+ pr_err("Failed to get table, %s\n", msg);
+ }
+
+ return;
}
+
+ acpi_probe_device_table(iort);
}
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 3074796..f9c9f3c 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -563,6 +563,7 @@
IRQCHIP_OF_MATCH_TABLE() \
ACPI_PROBE_TABLE(irqchip) \
ACPI_PROBE_TABLE(clksrc) \
+ ACPI_PROBE_TABLE(iort) \
EARLYCON_TABLE()
#define INIT_TEXT \
diff --git a/include/linux/acpi_iort.h b/include/linux/acpi_iort.h
index 0e32dac..d16fdda 100644
--- a/include/linux/acpi_iort.h
+++ b/include/linux/acpi_iort.h
@@ -39,4 +39,7 @@ static inline struct irq_domain *iort_get_device_domain(struct device *dev,
{ return NULL; }
#endif
+#define IORT_ACPI_DECLARE(name, table_id, fn) \
+ ACPI_DECLARE_PROBE_ENTRY(iort, name, table_id, 0, NULL, 0, fn)
+
#endif /* __ACPI_IORT_H__ */
--
2.10.0
^ permalink raw reply related
* [PATCH v8 01/16] drivers: acpi: add FWNODE_ACPI_STATIC fwnode type
From: Lorenzo Pieralisi @ 2016-11-16 15:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116152936.22955-1-lorenzo.pieralisi@arm.com>
On systems booting with a device tree, every struct device is associated
with a struct device_node, that provides its DT firmware representation.
The device node can be used in generic kernel contexts (eg IRQ
translation, IOMMU streamid mapping), to retrieve the properties
associated with the device and carry out kernel operations accordingly.
Owing to the 1:1 relationship between the device and its device_node,
the device_node can also be used as a look-up token for the device (eg
looking up a device through its device_node), to retrieve the device in
kernel paths where the device_node is available.
On systems booting with ACPI, the same abstraction provided by
the device_node is required to provide look-up functionality.
The struct acpi_device, that represents firmware objects in the
ACPI namespace already includes a struct fwnode_handle of
type FWNODE_ACPI as their member; the same abstraction is missing
though for devices that are instantiated out of static ACPI tables
entries (eg ARM SMMU devices).
Add a new fwnode_handle type to associate devices created out
of static ACPI table entries to the respective firmware components
and create a simple ACPI core layer interface to dynamically allocate
and free the corresponding firmware nodes so that kernel subsystems
can use it to instantiate the nodes and associate them with the
respective devices.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Hanjun Guo <hanjun.guo@linaro.org>
Reviewed-by: Tomasz Nowicki <tn@semihalf.com>
Tested-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Tomasz Nowicki <tn@semihalf.com>
Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
---
include/linux/acpi.h | 21 +++++++++++++++++++++
include/linux/fwnode.h | 3 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 689a8b9..6efb13c 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -56,6 +56,27 @@ static inline acpi_handle acpi_device_handle(struct acpi_device *adev)
acpi_fwnode_handle(adev) : NULL)
#define ACPI_HANDLE(dev) acpi_device_handle(ACPI_COMPANION(dev))
+static inline struct fwnode_handle *acpi_alloc_fwnode_static(void)
+{
+ struct fwnode_handle *fwnode;
+
+ fwnode = kzalloc(sizeof(struct fwnode_handle), GFP_KERNEL);
+ if (!fwnode)
+ return NULL;
+
+ fwnode->type = FWNODE_ACPI_STATIC;
+
+ return fwnode;
+}
+
+static inline void acpi_free_fwnode_static(struct fwnode_handle *fwnode)
+{
+ if (WARN_ON(!fwnode || fwnode->type != FWNODE_ACPI_STATIC))
+ return;
+
+ kfree(fwnode);
+}
+
/**
* ACPI_DEVICE_CLASS - macro used to describe an ACPI device with
* the PCI-defined class-code information
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 8516717..8bd28ce 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -17,8 +17,9 @@ enum fwnode_type {
FWNODE_OF,
FWNODE_ACPI,
FWNODE_ACPI_DATA,
+ FWNODE_ACPI_STATIC,
FWNODE_PDATA,
- FWNODE_IRQCHIP,
+ FWNODE_IRQCHIP
};
struct fwnode_handle {
--
2.10.0
^ permalink raw reply related
* [PATCH v8 00/16] ACPI IORT ARM SMMU support
From: Lorenzo Pieralisi @ 2016-11-16 15:29 UTC (permalink / raw)
To: linux-arm-kernel
This patch series is v8 of a previous posting:
https://lkml.org/lkml/2016/11/9/422
v7 -> v8
- Renamed fwnode iommu_ops registration API according to review
- Minor change in ARM SMMU driver DT/ACPI split
- Added review tags
v6 -> v7
- Rebased against v4.9-rc4
- Fixed IORT probing on ACPI systems with missing IORT table
- Fixed SMMUv1/v2 global interrupt detection
- Updated iommu_ops firmware look-up
v5 -> v6
- Rebased against v4.9-rc1
- Changed FWNODE_IOMMU to FWNODE_ACPI_STATIC
- Moved platform devices creation into IORT code
- Updated fwnode handling
- Added default dma masks initialization
v4 -> v5
- Added SMMUv1/v2 support
- Rebased against v4.8-rc5 and dependencies series
- Consolidated IORT platform devices creation
v3 -> v4
- Added single mapping API (for IORT named components)
- Fixed arm_smmu_iort_xlate() return value
- Reworked fwnode registration and platform device creation
ordering to fix probe ordering dependencies
- Added code to keep device_node ref count with new iommu
fwspec API
- Added patch to make iommu_fwspec arch agnostic
- Dropped RFC status
- Rebased against v4.8-rc2
v2 -> v3
- Rebased on top of dependencies series [1][2][3](v4.7-rc3)
- Added back reliance on ACPI early probing infrastructure
- Patch[1-3] merged through other dependent series
- Added back IOMMU fwnode generalization
- Move SMMU v3 static functions configuration to IORT code
- Implemented generic IOMMU fwspec API
- Added code to implement fwnode platform device look-up
v1 -> v2:
- Rebased on top of dependencies series [1][2][3](v4.7-rc1)
- Removed IOMMU fwnode generalization
- Implemented ARM SMMU v3 ACPI probing instead of ARM SMMU v2
owing to patch series dependencies [1]
- Moved platform device creation logic to IORT code to
generalize its usage for ARM SMMU v1-v2-v3 components
- Removed reliance on ACPI early device probing
- Created IORT specific iommu_xlate() translation hook leaving
OF code unchanged according to v1 reviews
The ACPI IORT table provides information that allows instantiating
ARM SMMU devices and carrying out id mappings between components on
ARM based systems (devices, IOMMUs, interrupt controllers).
http://infocenter.arm.com/help/topic/com.arm.doc.den0049b/DEN0049B_IO_Remapping_Table.pdf
Building on basic IORT support, this patchset enables ARM SMMUs support
on ACPI systems.
Most of the code is aimed at building the required generic ACPI
infrastructure to create and enable IOMMU components and to bring
the IOMMU infrastructure for ACPI on par with DT, which is going to
make future ARM SMMU components easier to integrate.
PATCH (1) adds a FWNODE_ACPI_STATIC type to the struct fwnode_handle type.
It is required to attach a fwnode identifier to platform
devices allocated/detected through static ACPI table entries
(ie IORT tables entries).
IOMMU devices have to have an identifier to look them up
eg IOMMU core layer carrying out id translation. This can be
done through a fwnode_handle (ie IOMMU platform devices created
out of IORT tables are not ACPI devices hence they can't be
allocated as such, otherwise they would have a fwnode_handle of
type FWNODE_ACPI).
PATCH (2) makes use of the ACPI early probing API to add a linker script
section for probing devices via IORT ACPI kernel code.
PATCH (3) provides IORT support for registering IOMMU IORT node through
their fwnode handle.
PATCH (4) make of_iommu_{set/get}_ops() functions DT agnostic and
rename the registration API.
PATCH (5) convert ARM SMMU driver to use fwnode instead of of_node as
look-up and iommu_ops retrieval token.
PATCH (6) convert ARM SMMU v3 driver to use fwnode instead of of_node as
look-up and iommu_ops retrieval token.
PATCH (7) implements the of_dma_configure() API in ACPI world -
acpi_dma_configure() - and patches PCI and ACPI core code to
start making use of it.
PATCH (8) provides an IORT function to detect existence of specific type
of IORT components.
PATCH (9) creates the kernel infrastructure required to create ARM SMMU
platform devices for IORT nodes.
PATCH (10) refactors the ARM SMMU v3 driver so that the init functions are
split in a way that groups together code that probes through DT
and code that carries out HW registers FW agnostic probing, in
preparation for adding the ACPI probing path.
PATCH (11) adds ARM SMMU v3 IORT IOMMU operations to create and probe
ARM SMMU v3 components.
PATCH (12) refactors the ARM SMMU v1/v2 driver so that the init functions
are split in a way that groups together code that probes
through DT and code that carries out HW registers FW agnostic
probing, in preparation for adding the ACPI probing path.
PATCH (13) adds ARM SMMU v1/v2 IORT IOMMU operations to create and
probe ARM SMMU v1/v2 components.
PATCH (14) Extend the IORT iort_node_map_rid() to work on a type mask
instead of a single type so that the translation API can
be used on a range of components.
PATCH (15) Add IORT API to carry out id mappings for components that do
do not have an input identifier/RIDs (ie named components).
PATCH (16) provides IORT infrastructure to carry out IOMMU configuration
for devices and hook it up to the previously introduced ACPI
DMA configure API.
This patchset is provided for review/testing purposes here:
git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git acpi/iort-smmu-v8
Tested on Juno and FVP models for ARM SMMU v1 and v3 probing path.
Lorenzo Pieralisi (16):
drivers: acpi: add FWNODE_ACPI_STATIC fwnode type
drivers: acpi: iort: introduce linker section for IORT entries probing
drivers: acpi: iort: add support for IOMMU fwnode registration
drivers: iommu: make of_iommu_set/get_ops() DT agnostic
drivers: iommu: arm-smmu: convert struct device of_node to fwnode
usage
drivers: iommu: arm-smmu-v3: convert struct device of_node to fwnode
usage
drivers: acpi: implement acpi_dma_configure
drivers: acpi: iort: add node match function
drivers: acpi: iort: add support for ARM SMMU platform devices
creation
drivers: iommu: arm-smmu-v3: split probe functions into DT/generic
portions
drivers: iommu: arm-smmu-v3: add IORT configuration
drivers: iommu: arm-smmu: split probe functions into DT/generic
portions
drivers: iommu: arm-smmu: add IORT configuration
drivers: acpi: iort: replace rid map type with type mask
drivers: acpi: iort: add single mapping function
drivers: acpi: iort: introduce iort_iommu_configure
drivers/acpi/arm64/iort.c | 595 +++++++++++++++++++++++++++++++++++++-
drivers/acpi/glue.c | 4 +-
drivers/acpi/scan.c | 45 +++
drivers/iommu/arm-smmu-v3.c | 105 +++++--
drivers/iommu/arm-smmu.c | 154 ++++++++--
drivers/iommu/iommu.c | 40 +++
drivers/iommu/of_iommu.c | 39 ---
drivers/pci/probe.c | 3 +-
include/acpi/acpi_bus.h | 2 +
include/asm-generic/vmlinux.lds.h | 1 +
include/linux/acpi.h | 26 ++
include/linux/acpi_iort.h | 14 +
include/linux/fwnode.h | 3 +-
include/linux/iommu.h | 14 +
include/linux/of_iommu.h | 12 +-
15 files changed, 953 insertions(+), 104 deletions(-)
--
2.10.0
^ permalink raw reply
* [PATCH] iommu: mtk: add common-clk dependency
From: Arnd Bergmann @ 2016-11-16 15:28 UTC (permalink / raw)
To: linux-arm-kernel
After the MT2701 clock driver was added, we get a harmless warning for
the iommu driver that selects it, when compile-testing without
COMMON_CLK.
warning: (MTK_IOMMU_V1) selects COMMON_CLK_MT2701_IMGSYS which has unmet direct dependencies (COMMON_CLK)
Adding a dependency on COMMON_CLK avoids the warning.
Fixes: e9862118272a ("clk: mediatek: Add MT2701 clock support")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/iommu/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
index 8ee54d71c7eb..bb537d06d319 100644
--- a/drivers/iommu/Kconfig
+++ b/drivers/iommu/Kconfig
@@ -346,7 +346,7 @@ config MTK_IOMMU
config MTK_IOMMU_V1
bool "MTK IOMMU Version 1 (M4U gen1) Support"
- depends on ARM
+ depends on ARM && COMMON_CLK
depends on ARCH_MEDIATEK || COMPILE_TEST
select ARM_DMA_USE_IOMMU
select IOMMU_API
--
2.9.0
^ permalink raw reply related
* [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Ard Biesheuvel @ 2016-11-16 15:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116090838.6c540230@gandalf.local.home>
On 16 November 2016 at 14:08, Steven Rostedt <rostedt@goodmis.org> wrote:
> On Wed, 16 Nov 2016 11:48:38 +0000
> Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>
>> >
>> > Does that allay your concerns?
>> >
>>
>> Yes, it does. Thanks
>
> Does this mean I can pull this patch into my queue then?
>
Fine by me
Thanks,
Ard.
^ permalink raw reply
* [PATCH] ARM: ux500: fix prcmu_is_cpu_in_wfi() calculation
From: Arnd Bergmann @ 2016-11-16 15:20 UTC (permalink / raw)
To: linux-arm-kernel
This function clearly never worked and always returns true,
as pointed out by gcc-7:
arch/arm/mach-ux500/pm.c: In function 'prcmu_is_cpu_in_wfi':
arch/arm/mach-ux500/pm.c:137:212: error: ?: using integer constants in boolean context, the expression will always evaluate to 'true' [-Werror=int-in-bool-context]
With the added braces, the condition actually makes sense.
Fixes: 34fe6f107eab ("mfd : Check if the other db8500 core is in WFI")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
arch/arm/mach-ux500/pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-ux500/pm.c b/arch/arm/mach-ux500/pm.c
index 8538910db202..a970e7fcba9e 100644
--- a/arch/arm/mach-ux500/pm.c
+++ b/arch/arm/mach-ux500/pm.c
@@ -134,8 +134,8 @@ bool prcmu_pending_irq(void)
*/
bool prcmu_is_cpu_in_wfi(int cpu)
{
- return readl(PRCM_ARM_WFI_STANDBY) & cpu ? PRCM_ARM_WFI_STANDBY_WFI1 :
- PRCM_ARM_WFI_STANDBY_WFI0;
+ return readl(PRCM_ARM_WFI_STANDBY) &
+ (cpu ? PRCM_ARM_WFI_STANDBY_WFI1 : PRCM_ARM_WFI_STANDBY_WFI0);
}
/*
--
2.9.0
^ permalink raw reply related
* [PATCH net 2/3] dt-bindings: net: add DT bindings for realtek phys
From: Jerome Brunet @ 2016-11-16 15:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116151104.5sfcqjyvrzre5pkn@rob-hp-laptop>
On Wed, 2016-11-16 at 09:11 -0600, Rob Herring wrote:
> On Tue, Nov 15, 2016 at 03:29:13PM +0100, Jerome Brunet wrote:
> >
> > Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> > Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> > ---
> > ?.../devicetree/bindings/net/realtek-phy.txt??????????| 20
> > ++++++++++++++++++++
> > ?1 file changed, 20 insertions(+)
> > ?create mode 100644 Documentation/devicetree/bindings/net/realtek-
> > phy.txt
> >
> > diff --git a/Documentation/devicetree/bindings/net/realtek-phy.txt
> > b/Documentation/devicetree/bindings/net/realtek-phy.txt
> > new file mode 100644
> > index 000000000000..dc2845a6b387
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/realtek-phy.txt
> > @@ -0,0 +1,20 @@
> > +Realtek Ethernet PHY
> > +
> > +Some boards require special tuning values of the phy.
> > +
> > +Optional properties:
> > +
> > +realtek,disable-eee-1000t:
> > +realtek,disable-eee-100tx:
>
> Make these generic/common.
Same feedback from the net folks. Will do.
Thx Rob
>
> >
> > +??If set, respectively disable 1000-BaseT and 100-BaseTx energy
> > efficient
> > +??ethernet capabilty advertisement
> > +??default: Leave the phy default settings unchanged (capabilities
> > advertised)
> > +
> > +Example:
> > +
> > +&mdio0 {
> > + ethernetphy0: ethernet-phy at 0 {
> > + reg = <0>;
> > + realtek,disable-eee-1000t;
> > + };
> > +};
> > --?
> > 2.7.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > devicetree" 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 v3 1/6] Documentation: dt-bindings: Document STM32 ADC DT bindings
From: Rob Herring @ 2016-11-16 15:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479223861-21747-2-git-send-email-fabrice.gasnier@st.com>
On Tue, Nov 15, 2016 at 04:30:56PM +0100, Fabrice Gasnier wrote:
> This patch adds documentation of device tree bindings for the STM32 ADC.
>
> Signed-off-by: Fabrice Gasnier <fabrice.gasnier@st.com>
> ---
> .../devicetree/bindings/iio/adc/st,stm32-adc.txt | 83 ++++++++++++++++++++++
> 1 file changed, 83 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/st,stm32-adc.txt
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH] ARM: dts: imx: Adjust CPU nodes
From: Fabio Estevam @ 2016-11-16 15:15 UTC (permalink / raw)
To: linux-arm-kernel
Make CPU nodes consistent throughout the i.MX dts files, which
also matches the description from ePAPR spec.
This also fixes the following W=1 warning in some cases:
Warning (unit_address_vs_reg): Node /cpus/cpu at 0 has a unit name, but no reg property
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
---
arch/arm/boot/dts/imx1.dtsi | 3 ++-
arch/arm/boot/dts/imx23.dtsi | 5 +++--
arch/arm/boot/dts/imx25.dtsi | 5 +++--
arch/arm/boot/dts/imx27.dtsi | 1 +
arch/arm/boot/dts/imx28.dtsi | 5 +++--
arch/arm/boot/dts/imx31.dtsi | 5 +++--
arch/arm/boot/dts/imx35.dtsi | 5 +++--
7 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/arch/arm/boot/dts/imx1.dtsi b/arch/arm/boot/dts/imx1.dtsi
index b792eee..dd3de38 100644
--- a/arch/arm/boot/dts/imx1.dtsi
+++ b/arch/arm/boot/dts/imx1.dtsi
@@ -43,8 +43,9 @@
#size-cells = <0>;
#address-cells = <1>;
- cpu: cpu at 0 {
+ cpu at 0 {
device_type = "cpu";
+ reg = <0>;
compatible = "arm,arm920t";
operating-points = <200000 1900000>;
clock-latency = <62500>;
diff --git a/arch/arm/boot/dts/imx23.dtsi b/arch/arm/boot/dts/imx23.dtsi
index ac2a9da..96eae64 100644
--- a/arch/arm/boot/dts/imx23.dtsi
+++ b/arch/arm/boot/dts/imx23.dtsi
@@ -29,12 +29,13 @@
};
cpus {
- #address-cells = <0>;
+ #address-cells = <1>;
#size-cells = <0>;
- cpu {
+ cpu at 0 {
compatible = "arm,arm926ej-s";
device_type = "cpu";
+ reg = <0>;
};
};
diff --git a/arch/arm/boot/dts/imx25.dtsi b/arch/arm/boot/dts/imx25.dtsi
index 831d09a..6a34815 100644
--- a/arch/arm/boot/dts/imx25.dtsi
+++ b/arch/arm/boot/dts/imx25.dtsi
@@ -43,12 +43,13 @@
};
cpus {
- #address-cells = <0>;
+ #address-cells = <1>;
#size-cells = <0>;
- cpu {
+ cpu at 0 {
compatible = "arm,arm926ej-s";
device_type = "cpu";
+ reg = <0>;
};
};
diff --git a/arch/arm/boot/dts/imx27.dtsi b/arch/arm/boot/dts/imx27.dtsi
index 9d8b596..6a7cb9e 100644
--- a/arch/arm/boot/dts/imx27.dtsi
+++ b/arch/arm/boot/dts/imx27.dtsi
@@ -65,6 +65,7 @@
cpu: cpu at 0 {
device_type = "cpu";
+ reg = <0>;
compatible = "arm,arm926ej-s";
operating-points = <
/* kHz uV */
diff --git a/arch/arm/boot/dts/imx28.dtsi b/arch/arm/boot/dts/imx28.dtsi
index 3aabf65..70927d5 100644
--- a/arch/arm/boot/dts/imx28.dtsi
+++ b/arch/arm/boot/dts/imx28.dtsi
@@ -40,12 +40,13 @@
};
cpus {
- #address-cells = <0>;
+ #address-cells = <1>;
#size-cells = <0>;
- cpu {
+ cpu at 0 {
compatible = "arm,arm926ej-s";
device_type = "cpu";
+ reg = <0>;
};
};
diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index 685916e..aa4d9cb 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -22,12 +22,13 @@
};
cpus {
- #address-cells = <0>;
+ #address-cells = <1>;
#size-cells = <0>;
- cpu {
+ cpu at 0 {
compatible = "arm,arm1136jf-s";
device_type = "cpu";
+ reg = <0>;
};
};
diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index 9f40e62..6f7b943 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -27,12 +27,13 @@
};
cpus {
- #address-cells = <0>;
+ #address-cells = <1>;
#size-cells = <0>;
- cpu {
+ cpu at 0 {
compatible = "arm,arm1136jf-s";
device_type = "cpu";
+ reg = <0>;
};
};
--
2.7.4
^ permalink raw reply related
* [PATCH v8 0/7] arm/arm64: vgic: Implement API for vGICv3 live migration
From: Christoffer Dall @ 2016-11-16 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALicx6t=0sRYG1jn_=hqod+Kca9-8fWbtwL_-HXE3HvrA_h7PQ@mail.gmail.com>
On Wed, Nov 16, 2016 at 08:24:16PM +0530, Vijay Kilari wrote:
> On Wed, Nov 16, 2016 at 5:17 PM, Christoffer Dall
> <christoffer.dall@linaro.org> wrote:
> > On Fri, Nov 04, 2016 at 04:43:26PM +0530, vijay.kilari at gmail.com wrote:
> >> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
> >>
> >> This patchset adds API for saving and restoring
> >> of VGICv3 registers to support live migration with new vgic feature.
> >> This API definition is as per version of VGICv3 specification
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
> >>
> >> The patch 3 & 4 are picked from the Pavel's previous implementation.
> >> http://www.spinics.net/lists/kvm/msg122040.html
> >
> > Do we have QEMU/kvmtool patches somewhere at this point so that I can
> > test this?
>
> I will send you next revision of QEMU patches tomorrow.
>
Sounds good, thanks.
-Christoffer
^ permalink raw reply
* [PATCH net 2/3] dt-bindings: net: add DT bindings for realtek phys
From: Rob Herring @ 2016-11-16 15:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479220154-25851-3-git-send-email-jbrunet@baylibre.com>
On Tue, Nov 15, 2016 at 03:29:13PM +0100, Jerome Brunet wrote:
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
> ---
> .../devicetree/bindings/net/realtek-phy.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/net/realtek-phy.txt
>
> diff --git a/Documentation/devicetree/bindings/net/realtek-phy.txt b/Documentation/devicetree/bindings/net/realtek-phy.txt
> new file mode 100644
> index 000000000000..dc2845a6b387
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/realtek-phy.txt
> @@ -0,0 +1,20 @@
> +Realtek Ethernet PHY
> +
> +Some boards require special tuning values of the phy.
> +
> +Optional properties:
> +
> +realtek,disable-eee-1000t:
> +realtek,disable-eee-100tx:
Make these generic/common.
> + If set, respectively disable 1000-BaseT and 100-BaseTx energy efficient
> + ethernet capabilty advertisement
> + default: Leave the phy default settings unchanged (capabilities advertised)
> +
> +Example:
> +
> +&mdio0 {
> + ethernetphy0: ethernet-phy at 0 {
> + reg = <0>;
> + realtek,disable-eee-1000t;
> + };
> +};
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" 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 net 1/3] net: phy: realtek: add eee advertisement disable options
From: Andrew Lunn @ 2016-11-16 15:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479307890.17538.40.camel@baylibre.com>
On Wed, Nov 16, 2016 at 03:51:30PM +0100, Jerome Brunet wrote:
> On Wed, 2016-11-16 at 14:23 +0100, Andrew Lunn wrote:
> > >
> > > There two kind of PHYs supporting eee, the one advertising eee by
> > > default (like realtek) and the one not advertising it (like
> > > micrel).
>
> This is just the default register value.
>
> >
> > I don't know too much about EEE. So maybe a dumb question. Does the
> > MAC need to be involved? Or is it just the PHY?
> >
> > If the MAC needs to be involved, the PHY should not be advertising
> > EEE
> > unless the MAC asks for it by calling phy_init_eee(). If this is
> > true,
> > maybe we need to change the realtek driver, and others in that class.
>
> As far I understand, the advertised capabilities are exchanged during
> the auto-negotiation.
>
> At this stage, if the advertisement is disabled (regarless of the
> actual support) on either side of the link, there will be no low power
> idle state on the Tx nor the Rx path.
>
> If the advertisement is enabled on both side but we don't call
> phy_init_eee, I suppose Tx won't enter LPI, but Rx could.
What i was trying to find out is, if the MAC needs to support EEE as
well as the PHY, what happens when the MAC does not support EEE, but
the PHYs do negotiate EEE? Does it break?
Andrew
^ permalink raw reply
* [PATCH v8 0/7] arm/arm64: vgic: Implement API for vGICv3 live migration
From: Vijay Kilari @ 2016-11-16 14:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116114722.GB3811@cbox>
On Wed, Nov 16, 2016 at 5:17 PM, Christoffer Dall
<christoffer.dall@linaro.org> wrote:
> On Fri, Nov 04, 2016 at 04:43:26PM +0530, vijay.kilari at gmail.com wrote:
>> From: Vijaya Kumar K <Vijaya.Kumar@cavium.com>
>>
>> This patchset adds API for saving and restoring
>> of VGICv3 registers to support live migration with new vgic feature.
>> This API definition is as per version of VGICv3 specification
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2016-July/445611.html
>>
>> The patch 3 & 4 are picked from the Pavel's previous implementation.
>> http://www.spinics.net/lists/kvm/msg122040.html
>
> Do we have QEMU/kvmtool patches somewhere at this point so that I can
> test this?
I will send you next revision of QEMU patches tomorrow.
>
> Thanks,
> -Christoffer
^ permalink raw reply
* [PATCH net 1/3] net: phy: realtek: add eee advertisement disable options
From: Jerome Brunet @ 2016-11-16 14:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161116132337.GD19962@lunn.ch>
On Wed, 2016-11-16 at 14:23 +0100, Andrew Lunn wrote:
> >
> > There two kind of PHYs supporting eee, the one advertising eee by
> > default (like realtek) and the one not advertising it (like
> > micrel).
This is just the default register value.
>
> I don't know too much about EEE. So maybe a dumb question. Does the
> MAC need to be involved? Or is it just the PHY?
>
> If the MAC needs to be involved, the PHY should not be advertising
> EEE
> unless the MAC asks for it by calling phy_init_eee(). If this is
> true,
> maybe we need to change the realtek driver, and others in that class.
As far I understand, the advertised capabilities are exchanged during
the auto-negotiation.
At this stage, if the advertisement is disabled (regarless of the
actual support) on either side of the link, there will be no low power
idle state on the Tx nor the Rx path.
If the advertisement is enabled on both side but we don't call
phy_init_eee, I suppose Tx won't enter LPI, but Rx could.
>
> ??????Andrew
^ permalink raw reply
* specifying order of /dev/mmcblk devices via device-tree?
From: Ulf Hansson @ 2016-11-16 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161028153755.GL5806@leverpostej>
On 28 October 2016 at 17:37, Mark Rutland <mark.rutland@arm.com> wrote:
> On Fri, Oct 28, 2016 at 08:23:04AM -0700, Tim Harvey wrote:
>> Greetings,
>>
>> I have an IMX6 board that has the following:
>> sdhc1: mmc0: sdio radio
>> sdhc2: mmc1: /dev/mmcblk1: microSD connector
>> sdhc3: mmc2: /dev/mmcblk2: on-board eMMC
>>
>> I would like to have sdhc3 registered as /dev/mmcblk0 and sdhc2
>> registered as /dev/mmcblk1 so that permanent storage is the first
>> mmcblk device as I think this is more intuitive however currently
>> these get instanced in the order they appear in the imx6qdl.dtsi
>> device-tree configuration and are not able to be mapped the way I want
>> them in my dts file.
>>
>> Is there a way, or if not is there a desire for a way, to specify the
>> order of /dev/mmcblk devices via device-tree?
>
> As with many other devices, there is no standard way of controlling the
> Linux enumeration (and given the ID space is shared with other dynamic
> devices it's not something that could generally work).
>
> These should be refererd to by UUID if possible.
>
> If not, we could cosider adding a by-dt-path or something like that.
So does that mean you think using "DT aliases" would be okay? As
Javier pointed out, there have been some attempts [1] for that, but
they didn't make it.
Perhaps we need to re-consider, and if so please re-review the DT
bindings patch from that series.
Kind regards
Uffe
[1]
https://lkml.org/lkml/2016/4/29/610 or
http://www.spinics.net/lists/linux-mmc/msg36701.html
^ permalink raw reply
* [PATCH v5 1/2] drm: tilcdc: implement palette loading for rev1
From: Jyri Sarha @ 2016-11-16 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAMpxmJUh8KypU_-HtGa+ieCpO46FBME8_VQCJvYkCjFhmuVWgg@mail.gmail.com>
On 11/16/16 13:34, Bartosz Golaszewski wrote:
> 2016-10-31 17:05 GMT+01:00 Jyri Sarha <jsarha@ti.com>:
>> On 10/31/16 16:19, Bartosz Golaszewski wrote:
>>> Revision 1 of the IP doesn't work if we don't load the palette (even
>>> if it's not used, which is the case for the RGB565 format).
>>>
>>> Add a function called from tilcdc_crtc_enable() which performs all
>>> required actions if we're dealing with a rev1 chip.
>>>
>>
>> There is only one thing I do not like about this patch. The palette
>> loading is done so late that the frame buffer address are already placed
>> into DMA base and ceiling registers, and we need to read them from the
>> registers and restore them back after the palette loading.
>>
>> Could you try if the palette loading function works without trouble when
>> called from tilcdc_pm_resume() before drm_atomic_helper_resume() call?
>> If it does it would be cleaner in the sense that you could get rid off
>> the old dma address restore code. You could reinit the completion always
>> there right before the palette loading.
>>
>> If you can not get the above suggestion to work, then I can take this
>> patch.
>>
>
> Hi Jyri,
>
> the problem is that tilcdc_pm_resume() is not called when tilcdc is
> initialized. We would have to have two calls in different places for
> that to work.
>
Yep, I know now. I worked on the issue while you were on vacation.
Please review my latest patch series (including this patch) and more
importantly test if the palette loading still works on rev 1 LCDC.
>>> +static void tilcdc_crtc_load_palette(struct drm_crtc *crtc)
>>> +{
>>> + u32 dma_fb_base, dma_fb_ceiling, raster_ctl;
>>> + struct tilcdc_crtc *tilcdc_crtc;
>>> + struct drm_device *dev;
>>> + u16 *first_entry;
>>> +
>>> + dev = crtc->dev;
>>> + tilcdc_crtc = to_tilcdc_crtc(crtc);
>>> + first_entry = tilcdc_crtc->palette_base;
>>> +
>>> + *first_entry = TILCDC_REV1_PALETTE_FIRST_ENTRY;
>>> +
>>> + dma_fb_base = tilcdc_read(dev, LCDC_DMA_FB_BASE_ADDR_0_REG);
>>> + dma_fb_ceiling = tilcdc_read(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG);
>>> + raster_ctl = tilcdc_read(dev, LCDC_RASTER_CTRL_REG);
>>> +
>>> + /* Tell the LCDC where the palette is located. */
>>> + tilcdc_write(dev, LCDC_DMA_FB_BASE_ADDR_0_REG,
>>> + tilcdc_crtc->palette_dma_handle);
>>> + tilcdc_write(dev, LCDC_DMA_FB_CEILING_ADDR_0_REG,
>>> + (u32)tilcdc_crtc->palette_dma_handle
>>
>> Just a nit pick, but I would put the plus sign to the end of the line
>> above instead of the beginning of the line bellow. However,
>> check_patch.pl does not complain about this so I guess I can accept it too.
>>
>>> + + TILCDC_REV1_PALETTE_SIZE - 1);
>>> +
>
> I'll fix that in v6.
>
> Thanks,
> Bartosz Golaszewski
>
^ permalink raw reply
* [PATCH 08/16] ARM: vexpress: use generic API for enabling SCU
From: Sudeep Holla @ 2016-11-16 14:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479099731-28108-9-git-send-email-pankaj.dubey@samsung.com>
On 14/11/16 05:02, Pankaj Dubey wrote:
> Now as we have of_scu_enable which takes care of mapping
> scu base from DT, lets use it.
>
> CC: Liviu Dudau <liviu.dudau@arm.com>
> CC: Sudeep Holla <sudeep.holla@arm.com>
I assume you will take this series through a single tree. Also I assume
you may make changes around a9 SCU. I will try to test if I can get my
setup back working. But if this patch is not changed, then
Acked-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH 1/2] phy: rockchip-inno-usb2: fix uninitialized tmout variable
From: Arnd Bergmann @ 2016-11-16 14:22 UTC (permalink / raw)
To: linux-arm-kernel
The newly added OTG support has an obvious uninitialized variable
access that gcc warns about:
drivers/phy/phy-rockchip-inno-usb2.c: In function 'rockchip_chg_detect_work':
drivers/phy/phy-rockchip-inno-usb2.c:717:7: error: 'tmout' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This replaces the use of the uninitialized variable with what
the value was in the previous USB_CHG_STATE_WAIT_FOR_DCD
state.
Fixes: 0c42fe48fd23 ("phy: rockchip-inno-usb2: support otg-port for rk3399")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/phy/phy-rockchip-inno-usb2.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/phy-rockchip-inno-usb2.c b/drivers/phy/phy-rockchip-inno-usb2.c
index eb89de59b68f..2f99ec95079c 100644
--- a/drivers/phy/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/phy-rockchip-inno-usb2.c
@@ -714,7 +714,7 @@ static void rockchip_chg_detect_work(struct work_struct *work)
delay = CHG_SECONDARY_DET_TIME;
rphy->chg_state = USB_CHG_STATE_PRIMARY_DONE;
} else {
- if (tmout) {
+ if (rphy->dcd_retries == CHG_DCD_MAX_RETRIES) {
/* floating charger found */
rphy->chg_type = POWER_SUPPLY_TYPE_USB_DCP;
rphy->chg_state = USB_CHG_STATE_DETECTED;
--
2.9.0
^ permalink raw reply related
* [PATCH 1/1] drivers: dma-contiguous: Ensure cma reserve region never cross the low/high mem boundary
From: Jason Liu @ 2016-11-16 14:19 UTC (permalink / raw)
To: linux-arm-kernel
If the cma reserve region goes through the device-tree method,
also need ensure the cma reserved region not cross the low/high
mem boundary. This patch did the similar fix as commit:16195dd
("mm: cma: Ensure that reservations never cross the low/high mem boundary")
Signed-off-by: Jason Liu <jason.hui.liu@nxp.com>
Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/base/dma-contiguous.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/drivers/base/dma-contiguous.c b/drivers/base/dma-contiguous.c
index e167a1e1..2bc093c 100644
--- a/drivers/base/dma-contiguous.c
+++ b/drivers/base/dma-contiguous.c
@@ -244,6 +244,7 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
{
phys_addr_t align = PAGE_SIZE << max(MAX_ORDER - 1, pageblock_order);
phys_addr_t mask = align - 1;
+ phys_addr_t highmem_start;
unsigned long node = rmem->fdt_node;
struct cma *cma;
int err;
@@ -256,6 +257,32 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem)
pr_err("Reserved memory: incorrect alignment of CMA region\n");
return -EINVAL;
}
+#ifdef CONFIG_X86
+ /*
+ * high_memory isn't direct mapped memory so retrieving its physical
+ * address isn't appropriate. But it would be useful to check the
+ * physical address of the highmem boundary so it's justfiable to get
+ * the physical address from it. On x86 there is a validation check for
+ * this case, so the following workaround is needed to avoid it.
+ */
+ highmem_start = __pa_nodebug(high_memory);
+#else
+ highmem_start = __pa(high_memory);
+#endif
+
+ /*
+ * All pages in the reserved area must come from the same zone.
+ * If the reserved region crosses the low/high memory boundary,
+ * try to fix it up and then fall back to allocate from the low mem
+ */
+ if (rmem->base < highmem_start &&
+ (rmem->base + rmem->size) > highmem_start) {
+ memblock_free(rmem->base, rmem->size);
+ rmem->base = memblock_alloc_range(rmem->size, align, 0,
+ highmem_start, MEMBLOCK_NONE);
+ if (!rmem->base)
+ return -ENOMEM;
+ }
err = cma_init_reserved_mem(rmem->base, rmem->size, 0, &cma);
if (err) {
--
1.9.1
^ permalink raw reply related
* [PATCH] pinctrl: sunxi: fix theoretical uninitialized variable access
From: Arnd Bergmann @ 2016-11-16 14:18 UTC (permalink / raw)
To: linux-arm-kernel
gcc warns about a way that it could use an uninitialized variable:
drivers/pinctrl/sunxi/pinctrl-sunxi.c: In function 'sunxi_pinctrl_init':
drivers/pinctrl/sunxi/pinctrl-sunxi.c:1191:8: error: 'best_div' may be used uninitialized in this function [-Werror=maybe-uninitialized]
This cannot really happen except if 'freq' is UINT_MAX and 'clock' is
zero, and both of these are forbidden. To shut up the warning anyway,
this changes the logic to initialize the return code to the first
divider value before looking at the others.
Fixes: 7c926492d38a ("pinctrl: sunxi: Add support for interrupt debouncing")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
drivers/pinctrl/sunxi/pinctrl-sunxi.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
index 2339d4718b4d..6b7953da4228 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
@@ -1125,10 +1125,13 @@ static int sunxi_pinctrl_build_state(struct platform_device *pdev)
static int sunxi_pinctrl_get_debounce_div(struct clk *clk, int freq, int *diff)
{
unsigned long clock = clk_get_rate(clk);
- unsigned int best_diff = ~0, best_div;
+ unsigned int best_diff, best_div;
int i;
- for (i = 0; i < 8; i++) {
+ best_diff = abs(freq - clock);
+ best_div = 0;
+
+ for (i = 1; i < 8; i++) {
int cur_diff = abs(freq - (clock >> i));
if (cur_diff < best_diff) {
--
2.9.0
^ permalink raw reply related
* [PATCH v05 60/72] arch/arm/include/uapi/asm/signal.h: use __kernel_size_t instead of size_t
From: Mikko Rapeli @ 2016-11-16 14:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1898059.B1P75dnZ5Q@wuerfel>
On Wed, Aug 24, 2016 at 05:02:56PM +0200, Arnd Bergmann wrote:
> On Monday, August 22, 2016 8:33:17 PM CEST Mikko Rapeli wrote:
> > diff --git a/arch/arm/include/uapi/asm/signal.h b/arch/arm/include/uapi/asm/signal.h
> > index 33073bd..859f2de 100644
> > --- a/arch/arm/include/uapi/asm/signal.h
> > +++ b/arch/arm/include/uapi/asm/signal.h
> > @@ -113,7 +113,7 @@ struct sigaction {
> > typedef struct sigaltstack {
> > void __user *ss_sp;
> > int ss_flags;
> > - size_t ss_size;
> > + __kernel_size_t ss_size;
> > } stack_t;
>
> I was going to reply with an Ack, but on further consideration,
> I'm not sure if we can't do this in general: size_t may be either
> 'unsigned int' or 'unsigned long' (depending on the architecture
> and toolchain), and if kernel and glibc disagree on this, we
> have a problem with any user space code that expects sigaltstack->ss_size
> to be the same type as size_t (as mandated by the man page).
>
> I wonder if there is another way to address this.
I presume that kernel headers need to follow libc in this case and include
<stddef.h>?
-Mikko
^ permalink raw reply
* [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Steven Rostedt @ 2016-11-16 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKv+Gu_8hhp1J1BwWE6m=mtYYCixajJLj1GJGRuNPtO328qQGg@mail.gmail.com>
On Wed, 16 Nov 2016 11:48:38 +0000
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> >
> > Does that allay your concerns?
> >
>
> Yes, it does. Thanks
Does this mean I can pull this patch into my queue then?
-- Steve
^ permalink raw reply
* [PATCH v16 15/15] acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver
From: fu.wei at linaro.org @ 2016-11-16 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479304148-2965-1-git-send-email-fu.wei@linaro.org>
From: Fu Wei <fu.wei@linaro.org>
This driver adds support for parsing SBSA Generic Watchdog timer
in GTDT, parse all info in SBSA Generic Watchdog Structure in GTDT,
and creating a platform device with that information.
This allows the operating system to obtain device data from the
resource of platform device. The platform device named "sbsa-gwdt"
can be used by the ARM SBSA Generic Watchdog driver.
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Tested-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
---
drivers/acpi/arm64/gtdt.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++
drivers/watchdog/Kconfig | 1 +
2 files changed, 101 insertions(+)
diff --git a/drivers/acpi/arm64/gtdt.c b/drivers/acpi/arm64/gtdt.c
index 08d9506..69483f6 100644
--- a/drivers/acpi/arm64/gtdt.c
+++ b/drivers/acpi/arm64/gtdt.c
@@ -14,6 +14,7 @@
#include <linux/acpi.h>
#include <linux/init.h>
#include <linux/kernel.h>
+#include <linux/platform_device.h>
#include <clocksource/arm_arch_timer.h>
@@ -66,6 +67,14 @@ static inline bool is_watchdog(void *platform_timer)
return gh->type == ACPI_GTDT_TYPE_WATCHDOG;
}
+static inline struct acpi_gtdt_watchdog *get_watchdog(unsigned int index)
+{
+ if (index >= acpi_gtdt_desc.watchdog_count || !watchdog)
+ return NULL;
+
+ return watchdog[index];
+}
+
static int __init map_gt_gsi(u32 interrupt, u32 flags)
{
int trigger, polarity;
@@ -309,3 +318,94 @@ int __init gtdt_arch_timer_mem_init(struct arch_timer_mem *data,
return 0;
}
+
+/*
+ * Initialize a SBSA generic Watchdog platform device info from GTDT
+ */
+static int __init gtdt_import_sbsa_gwdt(struct acpi_gtdt_watchdog *wd,
+ int index)
+{
+ struct platform_device *pdev;
+ int irq = map_gt_gsi(wd->timer_interrupt, wd->timer_flags);
+ int no_irq = 1;
+
+ /*
+ * According to SBSA specification the size of refresh and control
+ * frames of SBSA Generic Watchdog is SZ_4K(Offset 0x000 ? 0xFFF).
+ */
+ struct resource res[] = {
+ DEFINE_RES_MEM(wd->control_frame_address, SZ_4K),
+ DEFINE_RES_MEM(wd->refresh_frame_address, SZ_4K),
+ DEFINE_RES_IRQ(irq),
+ };
+
+ pr_debug("found a Watchdog (0x%llx/0x%llx gsi:%u flags:0x%x).\n",
+ wd->refresh_frame_address, wd->control_frame_address,
+ wd->timer_interrupt, wd->timer_flags);
+
+ if (!(wd->refresh_frame_address && wd->control_frame_address)) {
+ pr_err(FW_BUG "failed to get the Watchdog base address.\n");
+ return -EINVAL;
+ }
+
+ if (!wd->timer_interrupt)
+ pr_warn(FW_BUG "failed to get the Watchdog interrupt.\n");
+ else if (irq <= 0)
+ pr_warn("failed to map the Watchdog interrupt.\n");
+ else
+ no_irq = 0;
+
+ /*
+ * Add a platform device named "sbsa-gwdt" to match the platform driver.
+ * "sbsa-gwdt": SBSA(Server Base System Architecture) Generic Watchdog
+ * The platform driver (like drivers/watchdog/sbsa_gwdt.c)can get device
+ * info below by matching this name.
+ */
+ pdev = platform_device_register_simple("sbsa-gwdt", index, res,
+ ARRAY_SIZE(res) - no_irq);
+ if (IS_ERR(pdev)) {
+ acpi_unregister_gsi(wd->timer_interrupt);
+ return PTR_ERR(pdev);
+ }
+
+ return 0;
+}
+
+static int __init gtdt_sbsa_gwdt_init(void)
+{
+ int i, ret;
+ struct acpi_table_header *table;
+ struct acpi_gtdt_watchdog *watchdog;
+
+ if (acpi_disabled)
+ return 0;
+
+ if (ACPI_FAILURE(acpi_get_table(ACPI_SIG_GTDT, 0, &table)))
+ return -EINVAL;
+
+ ret = acpi_gtdt_init(table);
+ if (ret)
+ return ret;
+
+ if (!acpi_gtdt_desc.watchdog_count)
+ return 0;
+
+ for (i = 0; i < acpi_gtdt_desc.watchdog_count; i++) {
+ watchdog = get_watchdog(i);
+ if (!watchdog) {
+ ret = -ENODEV;
+ break;
+ }
+ ret = gtdt_import_sbsa_gwdt(watchdog, i);
+ if (ret)
+ break;
+ }
+
+ pr_info("found %d SBSA generic Watchdog(s), %d imported.\n",
+ acpi_gtdt_desc.watchdog_count, i);
+
+ acpi_gtdt_release();
+ return ret;
+}
+
+device_initcall(gtdt_sbsa_gwdt_init);
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index fdd3228..e5ba1f0 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -218,6 +218,7 @@ config ARM_SBSA_WATCHDOG
tristate "ARM SBSA Generic Watchdog"
depends on ARM64
depends on ARM_ARCH_TIMER
+ depends on ACPI_GTDT || !ACPI
select WATCHDOG_CORE
help
ARM SBSA Generic Watchdog has two stage timeouts:
--
2.7.4
^ permalink raw reply related
* [PATCH v16 14/15] clocksource/drivers/arm_arch_timer: Add GTDT support for memory-mapped timer
From: fu.wei at linaro.org @ 2016-11-16 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479304148-2965-1-git-send-email-fu.wei@linaro.org>
From: Fu Wei <fu.wei@linaro.org>
The patch add memory-mapped timer register support by using the
information provided by the new GTDT driver of ACPI.
Signed-off-by: Fu Wei <fu.wei@linaro.org>
---
drivers/clocksource/arm_arch_timer.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/arm_arch_timer.c b/drivers/clocksource/arm_arch_timer.c
index c494ca8..0aad60a 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -1067,7 +1067,28 @@ CLOCKSOURCE_OF_DECLARE(armv7_arch_timer_mem, "arm,armv7-timer-mem",
arch_timer_mem_of_init);
#ifdef CONFIG_ACPI_GTDT
-/* Initialize per-processor generic timer */
+static int __init arch_timer_mem_acpi_init(void)
+{
+ struct arch_timer_mem *timer_mem;
+ int ret = 0;
+ int i = 0;
+
+ timer_mem = kzalloc(sizeof(*timer_mem), GFP_KERNEL);
+ if (!timer_mem)
+ return -ENOMEM;
+
+ while (!gtdt_arch_timer_mem_init(timer_mem, i)) {
+ ret = arch_timer_mem_init(timer_mem);
+ if (ret)
+ break;
+ i++;
+ }
+
+ kfree(timer_mem);
+ return ret;
+}
+
+/* Initialize per-processor generic timer and memory-mapped timer(if present) */
static int __init arch_timer_acpi_init(struct acpi_table_header *table)
{
int ret;
@@ -1104,6 +1125,9 @@ static int __init arch_timer_acpi_init(struct acpi_table_header *table)
/* Get the frequency from CNTFRQ */
arch_timer_detect_rate(NULL);
+ if (arch_timer_mem_acpi_init())
+ pr_err("Failed to initialize memory-mapped timer.\n");
+
ret = arch_timer_init();
error:
--
2.7.4
^ permalink raw reply related
* [PATCH v16 13/15] acpi/arm64: Add memory-mapped timer support in GTDT driver
From: fu.wei at linaro.org @ 2016-11-16 13:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479304148-2965-1-git-send-email-fu.wei@linaro.org>
From: Fu Wei <fu.wei@linaro.org>
On platforms booting with ACPI, architected memory-mapped timers'
configuration data is provided by firmware through the ACPI GTDT
static table.
The clocksource architected timer kernel driver requires a firmware
interface to collect timer configuration and configure its driver.
this infrastructure is present for device tree systems, but it is
missing on systems booting with ACPI.
Implement the kernel infrastructure required to parse the static
ACPI GTDT table so that the architected timer clocksource driver can
make use of it on systems booting with ACPI, therefore enabling
the corresponding timers configuration.
Signed-off-by: Fu Wei <fu.wei@linaro.org>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
---
drivers/acpi/arm64/gtdt.c | 95 +++++++++++++++++++++++++++++++++++++++++++++++
include/linux/acpi.h | 1 +
2 files changed, 96 insertions(+)
diff --git a/drivers/acpi/arm64/gtdt.c b/drivers/acpi/arm64/gtdt.c
index 2de79aa..08d9506 100644
--- a/drivers/acpi/arm64/gtdt.c
+++ b/drivers/acpi/arm64/gtdt.c
@@ -51,6 +51,14 @@ static inline bool is_timer_block(void *platform_timer)
return gh->type == ACPI_GTDT_TYPE_TIMER_BLOCK;
}
+static inline struct acpi_gtdt_timer_block *get_timer_block(unsigned int index)
+{
+ if (index >= acpi_gtdt_desc.timer_block_count || !timer_block)
+ return NULL;
+
+ return timer_block[index];
+}
+
static inline bool is_watchdog(void *platform_timer)
{
struct acpi_gtdt_header *gh = platform_timer;
@@ -214,3 +222,90 @@ int __init acpi_gtdt_init(struct acpi_table_header *table)
acpi_gtdt_release();
return -EINVAL;
}
+
+/*
+ * Get ONE GT block info for memory-mapped timer from GTDT table.
+ * @data: the GT block data (parsing result)
+ * @index: the index number of GT block
+ * Note: we already verify @data in caller, it can't be NULL here.
+ * Returns 0 if success, -EINVAL/-ENODEV if error.
+ */
+int __init gtdt_arch_timer_mem_init(struct arch_timer_mem *data,
+ unsigned int index)
+{
+ struct acpi_gtdt_timer_block *block;
+ struct acpi_gtdt_timer_entry *frame;
+ int i;
+
+ block = get_timer_block(index);
+ if (!block)
+ return -ENODEV;
+
+ if (!block->timer_count) {
+ pr_err(FW_BUG "GT block present, but frame count is zero.");
+ return -ENODEV;
+ }
+
+ if (block->timer_count > ARCH_TIMER_MEM_MAX_FRAMES) {
+ pr_err(FW_BUG "GT block lists %d frames, ACPI spec only allows 8\n",
+ block->timer_count);
+ return -EINVAL;
+ }
+
+ data->cntctlbase = (phys_addr_t)block->block_address;
+ /*
+ * We can NOT get the size info from GTDT table,
+ * but according to "Table * CNTCTLBase memory map" of
+ * <ARM Architecture Reference Manual> for ARMv8,
+ * it should be 4KB(Offset 0x000 ? 0xFFC).
+ */
+ data->size = SZ_4K;
+ data->num_frames = block->timer_count;
+
+ frame = (void *)block + block->timer_offset;
+ if (frame + block->timer_count != (void *)block + block->header.length)
+ return -EINVAL;
+
+ /*
+ * Get the GT timer Frame data for every GT Block Timer
+ */
+ for (i = 0; i < block->timer_count; i++, frame++) {
+ if (!frame->base_address || !frame->timer_interrupt)
+ return -EINVAL;
+
+ data->frame[i].phys_irq = map_gt_gsi(frame->timer_interrupt,
+ frame->timer_flags);
+ if (data->frame[i].phys_irq <= 0) {
+ pr_warn("failed to map physical timer irq in frame %d.\n",
+ i);
+ return -EINVAL;
+ }
+
+ if (frame->virtual_timer_interrupt) {
+ data->frame[i].virt_irq =
+ map_gt_gsi(frame->virtual_timer_interrupt,
+ frame->virtual_timer_flags);
+ if (data->frame[i].virt_irq <= 0) {
+ pr_warn("failed to map virtual timer irq in frame %d.\n",
+ i);
+ return -EINVAL;
+ }
+ }
+
+ data->frame[i].frame_nr = frame->frame_number;
+ data->frame[i].cntbase = frame->base_address;
+ /*
+ * We can NOT get the size info from GTDT table,
+ * but according to "Table * CNTBaseN memory map" of
+ * <ARM Architecture Reference Manual> for ARMv8,
+ * it should be 4KB(Offset 0x000 ? 0xFFC).
+ */
+ data->frame[i].size = SZ_4K;
+ }
+
+ if (acpi_gtdt_desc.timer_block_count)
+ pr_info("parsed No.%d of %d memory-mapped timer block(s).\n",
+ index, acpi_gtdt_desc.timer_block_count);
+
+ return 0;
+}
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index a1611d1..44b8c1b 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -582,6 +582,7 @@ int acpi_gtdt_init(struct acpi_table_header *table);
int acpi_gtdt_map_ppi(int type);
bool acpi_gtdt_c3stop(int type);
void acpi_gtdt_release(void);
+int gtdt_arch_timer_mem_init(struct arch_timer_mem *data, unsigned int index);
#endif
#else /* !CONFIG_ACPI */
--
2.7.4
^ 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