Re: [PATCH V3 1/2] tps6507x-ts: Add DT support
Hi Manish,
On Tue, May 21, 2013 at 02:24:17PM +0530, Vishwanathrao Badarkhe, Manish wrote:
Add device tree based support for TI's tps6507x touchscreen.
Tested on da850-evm.
Signed-off-by: Vishwanathrao Badarkhe, Manish manish...@ti.com
---
Changes since V2:
- Removed unnecessary code.
- Updated Documentation to provide proper names of
devicetree properties.
Changes since V1:
- Updated documentation to specify tps6507x as multifunctional
device.
- return proper error value in absence of platform and DT
data for touchscreen.
- Updated commit message.
:100755 100755 8fffa3c... 65ee2cd... M
Documentation/devicetree/bindings/mfd/tps6507x.txt
:100644 100644 65e0f9a... 89232ee... M
drivers/input/touchscreen/tps6507x-ts.c
Documentation/devicetree/bindings/mfd/tps6507x.txt | 28 ++-
drivers/input/touchscreen/tps6507x-ts.c| 98
++--
2 files changed, 95 insertions(+), 31 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt
b/Documentation/devicetree/bindings/mfd/tps6507x.txt
index 8fffa3c..65ee2cd 100755
--- a/Documentation/devicetree/bindings/mfd/tps6507x.txt
+++ b/Documentation/devicetree/bindings/mfd/tps6507x.txt
@@ -1,4 +1,8 @@
-TPS6507x Power Management Integrated Circuit
+TPS6507x Multifunctional Device.
+
+Features provided by TPS6507x:
+1.Power Management Integrated Circuit.
+2.Touch-Screen.
Required properties:
- compatible: ti,tps6507x
@@ -23,6 +27,12 @@ Required properties:
vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
vindcdc3-supply : VDCDC3 input.
vldo1_2-supply : VLDO1 and VLDO2 input.
+- tsc: This node specifies touch screen data.
+ ti,poll-period : Time at which touch input is getting sampled in ms.
+ ti,min-pressure: Minimum pressure value to trigger touch.
+ ti,vref: voltage reference for ADC.
+ 0: Reference voltage for ADC is disabled.
+ 1: Reference voltage for ADC is enabled.
Regulator Optional properties:
- defdcdc_default: It's property of DCDC2 and DCDC3 regulators.
@@ -30,6 +40,14 @@ Regulator Optional properties:
1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH.
If this property is not defined, it defaults to 0 (not enabled).
+Touchscreen Optional properties:
+- ti,vendor : Touchscreen vendor id to populate
+ in sysclass interface.
+- ti,product: Touchscreen product id to populate
+ in sysclass interface.
+- ti,version: Touchscreen version id to populate
+ in sysclass interface.
+
Example:
pmu: tps6507x@48 {
@@ -88,4 +106,12 @@ Example:
};
};
+ tsc {
+ ti,poll-period = 30;
+ ti,min-pressure = 0x30;
+ ti,vref = 0;
+ ti,vendor = 0;
+ ti,product = 65070;
+ ti,version = 0x100;
+ };
};
diff --git a/drivers/input/touchscreen/tps6507x-ts.c
b/drivers/input/touchscreen/tps6507x-ts.c
index 65e0f9a..89232ee 100644
--- a/drivers/input/touchscreen/tps6507x-ts.c
+++ b/drivers/input/touchscreen/tps6507x-ts.c
@@ -21,6 +21,8 @@
#include linux/mfd/tps6507x.h
#include linux/input/tps6507x-ts.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_device.h
#define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
#define TPS_DEFAULT_MIN_PRESSURE 0x30
@@ -231,36 +233,76 @@ done:
ret = tps6507x_adc_standby(tsc);
}
+static int tsc_init_data(struct tps6507x_dev *tps6507x_dev,
+ struct input_dev *input_dev)
+{
+ struct device_node *node = tps6507x_dev-dev-of_node;
+ struct tps6507x_board *tps_board =
+ (struct tps6507x_board *)tps6507x_dev-dev-platform_data;
Please make tps_board const pointer and use dev_get_platdata() to fetch
it.
+ struct touchscreen_init_data *init_data = NULL;
+ int err;
+
+ if (node)
+ node = of_find_node_by_name(node, tsc);
Why do you have to locate OF node manually instead of already having it
attached to the device stucture?
+ if (tps_board)
+ init_data = tps_board-tps6507x_ts_init_data;
+
+ if (node == NULL || init_data == NULL) {
+ err = -EINVAL;
+ goto error_ret;
+ } else if (init_data) {
+ tps6507x_dev-ts-poll_period = init_data-poll_period;
+ tps6507x_dev-ts-min_pressure = init_data-min_pressure;
+ tps6507x_dev-ts-vref = init_data-vref;
+ input_dev-id.vendor = init_data-vendor;
+ input_dev-id.product = init_data-product;
+ input_dev-id.version = init_data-version;
+ } else if (node) {
+ err = of_property_read_u32(node, ti,poll-period,
+ (u32
Re: [PATCH 2/2] ARM: nomadik: add the new clocks to the device tree
On Sun, Jun 9, 2013 at 4:21 PM, Arnd Bergmann a...@arndb.de wrote:
On Sunday 09 June 2013, Linus Walleij wrote:
+ /*
+* IP AMBA bus clocks, driving the bus side of the
+* peripheral clocking, clock gates.
+*/
+
+ hclkdma0: hclkdma0@48M {
+ #clock-cells = 0;
+ compatible = st,nomadik-src-clock;
+ clock-id = 0;
+ clocks = hclk;
+ };
+ hclksmc: hclksmc@48M {
+ #clock-cells = 0;
+ compatible = st,nomadik-src-clock;
+ clock-id = 1;
+ clocks = hclk;
+ };
+ hclksdram: hclksdram@48M {
+ #clock-cells = 0;
+ compatible = st,nomadik-src-clock;
+ clock-id = 2;
+ clocks = hclk;
+ };
+ hclkdma1: hclkdma1@48M {
+ #clock-cells = 0;
+ compatible = st,nomadik-src-clock;
+ clock-id = 3;
+ clocks = hclk;
+ };
Sorry if I'm being slow to understand how the clock bindings work, but if
you have 63 identical clocks that only differ in ther clock-id, can't you
just have a single DT node for them instead with #clock-cells=1 to pass the
number from the device using it?
I first had exactly that implementation but it didn't work. This is explained
in the commit message on patch 1/1:
The gated clocks are implemented with zero cells and
given the clock ID as a property of each node, so every
gate need to have its own node in the device tree.
This is because the gate registers contain both HCLK
gates and PCLK gates, where the latter has HCLK as
parent. As can be seen from the register layout, this
is a complete mixup, which means all these gates need
their own node to properly model parent/child relations
for PCLKs apart from the HCLKs.
Basically the shortcoming in device tree is that modelling this with
clock-cells = 1 requires them all to have one and the same parent,
but they don't.
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: tegra: add basic SecureOS support
On Sat, Jun 8, 2013 at 2:30 AM, Dave Martin dave.mar...@arm.com wrote:
Most likely it's either unnecessary, or insufficient.
Just for entering call SMC properly, it's not needed. If the Secure
World has its MMU on and maps Normal World memory using the same memory
types as Linux, then the Normal World and Secure World access the memory
coherently with no extra barrier needed.
It the Secure World's MMU is off, or if it maps Normal World memory
as Secure (pagetable NS bit = 0), or if it maps Normal World memory with
memory types incompatible with the ones Linux is using then you will get
coherency problems: the Secure and Normal Worlds won't necessarily see
the same data.
In the latter case, you must do explicit cache maintenance around SMC
for the data you want to exchange. This might also be needed in the
Secure World if caches are enabled over there. DSB isn't enough by
itself.
If the Secure World doesn't access Normal World memory at all, you
don't need to do anything special and can remove the DSB.
Otherwise, for performance reasons, it is definitely preferable to have
the Secure World MMU on if possible, though it's a bit more complex to
set up.
Thanks for the information. I will try to understand why we put it
here in the first place.
+ smc#0\n\t
+ ldrr3, =__tegra_smc_stack\n\t
+ ldmia r3, {r4-r12, lr}
+ :
+ : [type]r (type),
+ [subtype] r (subtype),
+ [arg] r (arg)
+ : r0, r1, r2, r3, r4, memory);
If r5-r12 are not clobbered, why do you save and restore them?
The secure monitor might change them.
Sure, but you could just add all the registers to the clobber list,
and then the compiler would save and restore them for you in the
function entry/exit sequences, which may be a bit more efficient.
Since you are going to replace this code anyway, it's academic
though.
Right. I suppose you mentioned this in the context of my initial code
- however if I understand how inline asm works (in case it wasn't
clear already, I probably don't), turning this function into a naked
function will make it impossible for the compiler to generate the
entry/exit sequences since the assembler code will be responsible for
returning from the function.
One could remove the naked attribute and put there registers into the
clobber list, but then the function will be inlined and we will have
to ensure the parameters end up in the right register (and having a
function that cannot be inlined is convenient in that respect). So as
far as I can tell, having the function naked and saving the registers
ourselves seems to be the most convenient way around this.
Thanks,
Alex.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: add dtsi for palmas
Totally agree to all the above concerns. So can we have a custom .dtsi file for a board+pmic combination? Or have only the required properties over ridden in the board file? The common approach is to only apply nodes and node properties to the .dtsi files which are appropriate for _all_ platforms which include them. Anything that is only relevant to a sub-set of boards should be in a higher ranking .dtsi file and finally, any settings which are board specific should be in the board's .dts file. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v9] i2c: exynos5: add High Speed I2C controller driver
On 17 May 2013 15:40, Naveen Krishna Chatradhi ch.nav...@samsung.com wrote:
Adds support for High Speed I2C driver found in Exynos5 and
later SoCs from Samsung.
Driver only supports Device Tree method.
Changes since v1:
1. Added FIFO functionality
2. Added High speed mode functionality
3. Remove SMBUS_QUICK
4. Remove the debugfs functionality
5. Use devm_* functions where ever possible
6. Driver is free from GPIO configs (only supports pinctrl method)
7. Use OF data string clock-frequency to get the bus operating frequencies
8. Split the clock divisor calculation function
9. Add resets for the failed transacton cases
10. few other bug fixes and cosmetic changes
Signed-off-by: Taekgyun Ko taeggyun...@samsung.com
Signed-off-by: Naveen Krishna Chatradhi ch.nav...@samsung.com
Reviewed-by: Simon Glass s...@google.com
Tested-by: Andrew Bresticker abres...@google.com
Signed-off-by: Yuvaraj Kumar C D yuvaraj...@samsung.com
Signed-off-by: Andrew Bresticker abres...@google.com
Hello Wolfram,
This driver was submitted, reviewed several times.
and been improved as we were using it.
I did not see any review comments on this driver.
Can we get this merged or Should we wait for few more reviews ?
Sorry for the earlier HTML version of the mail.
Thanks Regards,
Naveen Krishna
---
Changes since v8
1. improved the device tree bindings description page for i2c-exynos5
2. fixed the return value check for devm_ioremap_resource
.../devicetree/bindings/i2c/i2c-exynos5.txt| 45 +
drivers/i2c/busses/Kconfig |7 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-exynos5.c | 888
4 files changed, 941 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
create mode 100644 drivers/i2c/busses/i2c-exynos5.c
diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
new file mode 100644
index 000..29c01c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
@@ -0,0 +1,45 @@
+* Samsung's High Speed I2C controller
+
+The Samsung's High Speed I2C controller is used to interface with I2C devices
+at various speeds ranging from 100khz to 3.4Mhz.
+
+Required properties:
+ - compatible: value should be.
+ - samsung,exynos5-hsi2c, for i2c compatible with exynos5 hsi2c.
+ - reg: physical base address of the controller and length of memory mapped
+region.
+ - interrupts: interrupt number to the cpu.
+ - #address-cells: always 1 (for i2c addresses)
+ - #size-cells: always 0
+
+ - Pinctrl:
+- pinctrl-0: Pin control group to be used for this controller.
+- pinctrl-names: Should contain only one value - default.
+
+Optional properties:
+ - samsung,hs-mode: Mode of operation, High speed or Fast speed mode. If not
+specified, default value is 0.
+ - clock-frequency: Desired operating frequency in Hz of the bus.
+If not specified, the default value in Hz is 10.
+
+Example:
+
+hsi2c@12ca {
+ compatible = samsung,exynos5-hsi2c;
+ reg = 0x12ca 0x100;
+ interrupts = 56;
+ clock-frequency = 10;
+
+ /* Pinctrl variant begins here */
+ pinctrl-0 = i2c4_bus;
+ pinctrl-names = default;
+ /* Pinctrl variant ends here */
+
+ #address-cells = 1;
+ #size-cells = 0;
+
+ s2mps11_pmic@66 {
+ compatible = samsung,s2mps11-pmic;
+ reg = 0x66;
+ };
+};
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index adfee98..49a665f 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -434,6 +434,13 @@ config I2C_EG20T
ML7213/ML7223/ML7831 is companion chip for Intel Atom E6xx series.
ML7213/ML7223/ML7831 is completely compatible for Intel EG20T PCH.
+config I2C_EXYNOS5
+ tristate Exynos5 high-speed I2C driver
+ depends on ARCH_EXYNOS5 OF
+ help
+ Say Y here to include support for high-speed I2C controller in the
+ Exynos5 based Samsung SoCs.
+
config I2C_GPIO
tristate GPIO-based bitbanging I2C
depends on GENERIC_GPIO
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 8f4fc23..b19366c 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -42,6 +42,7 @@ i2c-designware-platform-objs := i2c-designware-platdrv.o
obj-$(CONFIG_I2C_DESIGNWARE_PCI) += i2c-designware-pci.o
i2c-designware-pci-objs := i2c-designware-pcidrv.o
obj-$(CONFIG_I2C_EG20T)+= i2c-eg20t.o
+obj-$(CONFIG_I2C_EXYNOS5) += i2c-exynos5.o
obj-$(CONFIG_I2C_GPIO) += i2c-gpio.o
obj-$(CONFIG_I2C_HIGHLANDER) += i2c-highlander.o
obj-$(CONFIG_I2C_IBM_IIC) += i2c-ibm_iic.o
diff --git
Re: [PATCH 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
Add palmas node and omap specific palmas regulator properties.
This patch is based on:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.11/dts
There's no need for this to be in the commit message.
Boot tested on omap5-uevm board.
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 145
++
1 files changed, 145 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..88172db 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -254,6 +254,151 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
The interrupt property is fairly ubiqutous. There's not really any
need to document it in this manor.
+ interrupts = 0 7 4; /* IRQ_SYS_1N cascaded to gic */
Use the IRQ includes in dt-bindings.
+ interrupt-parent = gic;
+ };
+
+};
+
+#include palmas.dtsi
I'm a bit confused by this. Is it now common practice to break out
nodes in this way? I assume to counter mass indentation, but it's a
bit alien to me.
+palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
Are these all board specific, or are they shared with any other
platform?
+ smps45_reg: smps45 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = 220;
+ regulator-max-microvolt = 220;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo5_reg: ldo5 {
+
Re: [PATCH] ARM: tegra: add basic SecureOS support
On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren swar...@wwwdotorg.org wrote: I think we need to separate the concept of support for *a* secure monitor, from support for a *particular* secure monitor. Agreed. In this case, can we assume that support for a specific secure monitor is not arch-specific, and that this patch should be moved outside of arch-tegra and down to arch/arm? In other words, the ABI of a particular secure monitor should be the same no matter the chip, shouldn't it? I would like to believe that the Trusted Foundations monitor had the same ABI irrespective of which Soc it was running on. However, I have absolutely no idea at all if that's true. Even if there's some common subset of the ABI that is identical across all SoCs, I wouldn't be too surprised if there were custom extensions for each different SoC, or just perhaps even each product. Can you research this and find out the answer? Will do. Information about TF is scarce unfortunately. What we can always do is make a compatible property that lists everything[1], and have the driver match on the most specific value for now, but relax the driver's matching later if it turns out that the ABI is indeed common. [1] That'd need to be at least secure OS name, and secure OS version. Perhaps the SoC and board data can be deduced from the DT's top-level compatible properties; nvidia,tegra114-shield, nvidia,tegra114? They can probably, but in theory nothing prevents a board from coming with different secure monitors (or none at all). In this case, just having the board name might not be enough. Having a proper node for the firmware like David and Tomasz suggested seems to be the best way to make sure we cover all cases - I think I will try to do it this way for the next version, and hopefully come with a binding that is useful for everyone. Thanks, Alex. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/6] ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC
On Saturday, June 08, 2013 2:43 AM, Arnd Bergmann wrote:
On Friday 07 June 2013, Jason Gunthorpe wrote:
Sounds fair to me.
But when we talk about multiple domains we don't mean a disjoint range
bus bus numbers, as your other email shows:
00:00.0 PCI bridge: Samsung Electronics Co Ltd Device a549 (rev 01)
(prog-if 00 [Normal decode])
10:00.0 PCI bridge: Samsung Electronics Co Ltd Device a549 (rev 01)
(prog-if 00 [Normal decode])
We mean multiple domains, it should look like this:
:00:00.0 PCI bridge: Samsung Electronics Co Ltd Device a549 (rev 01)
(prog-if 00 [Normal decode])
0001:00:00.0 PCI bridge: Samsung Electronics Co Ltd Device a549 (rev 01)
(prog-if 00 [Normal decode])
ie lspci -D.
Each domain gets a unique bus number range, config space, io range,
etc. This is much clearer to everyone than trying to pretend there is
only one domain when the HW is actually multi-domain.
Yes, absolutely. This means we also don't need a bus-range property in DT,
since each
domain will allow all 255 buses.
After removing a bus-range property in DT, it looks like:
00:00.0 PCI bridge: Samsung Electronics Co Ltd Device a549 (rev 01) (prog-if 00
[Normal decode])
02:00.0 PCI bridge: Samsung Electronics Co Ltd Device a549 (rev 01) (prog-if 00
[Normal decode])
For multiple domains, how can I fix the DT properties?
Current DT properties are as below:
+ pcie0@4000 {
+ compatible = samsung,exynos5440-pcie;
+ reg = 0x4000 0x4000
+ 0x29 0x1000
+ 0x27 0x1000
+ 0x271000 0x40;
+ interrupts = 0 20 0, 0 21 0, 0 22 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ device_type = pci;
+ ranges = 0x0800 0 0x4000 0x4000 0 0x0020 /*
configuration space */
+ 0x8100 0 0 0x4020 0 0x4000 /*
downstream I/O */
+ 0x8200 0 0 0x40204000 0 0x1000; /*
non-prefetchable memory */
+ };
+
+ pcie1@6000 {
+ compatible = samsung,exynos5440-pcie;
+ reg = 0x6000 0x4000
+ 0x2a 0x1000
+ 0x272000 0x1000
+ 0x271040 0x40;
+ interrupts = 0 23 0, 0 24 0, 0 25 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ device_type = pci;
+ ranges = 0x0800 0 0x6000 0x6000 0 0x0020 /*
configuration space */
+ 0x8100 0 0 0x6020 0 0x4000 /*
downstream I/O */
+ 0x8200 0 0 0x60204000 0 0x1000; /*
non-prefetchable memory */
+ };
Best regards,
Jingoo Han
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-pci in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/6] GPIO: xilinx: Simplify driver probe function
Hi Linus, can you please look at this patchset? Thanks, Michal On 06/03/2013 02:31 PM, Michal Simek wrote: Simplification is done by using OF helper function which increase readability of code and remove (if (var) var = be32_to_cpup;) assignment. Signed-off-by: Michal Simek michal.si...@xilinx.com --- Changes in v2: - New patch in this series drivers/gpio/gpio-xilinx.c | 24 ++-- 1 file changed, 10 insertions(+), 14 deletions(-) diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c index 9ae7aa8..2aad534 100644 --- a/drivers/gpio/gpio-xilinx.c +++ b/drivers/gpio/gpio-xilinx.c @@ -170,24 +170,20 @@ static int xgpio_of_probe(struct device_node *np) return -ENOMEM; /* Update GPIO state shadow register with default value */ - tree_info = of_get_property(np, xlnx,dout-default, NULL); - if (tree_info) - chip-gpio_state = be32_to_cpup(tree_info); + of_property_read_u32(np, xlnx,dout-default, chip-gpio_state); + + /* By default, all pins are inputs */ + chip-gpio_dir = 0x; /* Update GPIO direction shadow register with default value */ - chip-gpio_dir = 0x; /* By default, all pins are inputs */ - tree_info = of_get_property(np, xlnx,tri-default, NULL); - if (tree_info) - chip-gpio_dir = be32_to_cpup(tree_info); + of_property_read_u32(np, xlnx,tri-default, chip-gpio_dir); + + /* By default assume full GPIO controller */ + chip-mmchip.gc.ngpio = 32; /* Check device node and parent device node for device width */ - chip-mmchip.gc.ngpio = 32; /* By default assume full GPIO controller */ - tree_info = of_get_property(np, xlnx,gpio-width, NULL); - if (!tree_info) - tree_info = of_get_property(np-parent, - xlnx,gpio-width, NULL); - if (tree_info) - chip-mmchip.gc.ngpio = be32_to_cpup(tree_info); + of_property_read_u32(np, xlnx,gpio-width, + (u32 *)chip-mmchip.gc.ngpio); spin_lock_init(chip-gpio_lock); -- 1.8.2.3 -- Michal Simek, Ing. (M.Eng), OpenPGP - KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform signature.asc Description: OpenPGP digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: tegra: add basic SecureOS support
On Mon, Jun 10, 2013 at 04:47:22PM +0900, Alexandre Courbot wrote: One could remove the naked attribute and put there registers into the clobber list, but then the function will be inlined and we will have to ensure the parameters end up in the right register (and having a function that cannot be inlined is convenient in that respect). So as far as I can tell, having the function naked and saving the registers ourselves seems to be the most convenient way around this. If you use such a large clobber list, you risk the compiler barfing on you that it's run out of registers. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: tegra: add basic SecureOS support
On Mon, Jun 10, 2013 at 05:11:15PM +0900, Alexandre Courbot wrote: On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren swar...@wwwdotorg.org wrote: I think we need to separate the concept of support for *a* secure monitor, from support for a *particular* secure monitor. Agreed. In this case, can we assume that support for a specific secure monitor is not arch-specific, and that this patch should be moved outside of arch-tegra and down to arch/arm? In other words, the ABI of a particular secure monitor should be the same no matter the chip, shouldn't it? I would like to believe that the Trusted Foundations monitor had the same ABI irrespective of which Soc it was running on. However, I have absolutely no idea at all if that's true. Even if there's some common subset of the ABI that is identical across all SoCs, I wouldn't be too surprised if there were custom extensions for each different SoC, or just perhaps even each product. Can you research this and find out the answer? Will do. Information about TF is scarce unfortunately. The answer is... there isn't a common ABI. That is something I pressed ARM Ltd for when this stuff first appeared and they were adamant that they were not going to specify any kind of ABI for this interface. The net result is that everyone has invented their own interfaces around it. Some pass all arguments in registers, some pass arguments in memory and pass pointers to those memory locations, and those memory locations have to be flushed in some way. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/2] ARM: dts: add dtsi for palmas
On Monday 10 June 2013 02:34 PM, J Keerthy wrote: Adds palmas mfd and palmas regulator nodes. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: J Keerthy j-keer...@ti.com --- arch/arm/boot/dts/palmas.dtsi | 98 + Hi Keerthy, Can you please add documentation for dt binding: Documentation/devicetree/bindings/mfd Most of time we refer from this document for dt population. Thanks, Laxman ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 01/11] serial:st-asc: Add ST ASC driver.
This patch adds support to ASC (asynchronous serial controller)
driver, which is basically a standard serial driver. This IP is common
across all the ST parts for settop box platforms.
ASC is embedded in ST COMMS IP block. It supports Rx Tx functionality.
It support all industry standard baud rates.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
CC: Stephen Gallimore stephen.gallim...@st.com
CC: Stuart Menefy stuart.men...@st.com
CC: Arnd Bergmann a...@arndb.de
CC: Greg Kroah-Hartman gre...@linuxfoundation.org
---
.../devicetree/bindings/tty/serial/st-asc.txt | 18 +
drivers/tty/serial/Kconfig | 16 +
drivers/tty/serial/Makefile|1 +
drivers/tty/serial/st-asc.c| 911
include/uapi/linux/serial_core.h |3 +
5 files changed, 949 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/tty/serial/st-asc.txt
create mode 100644 drivers/tty/serial/st-asc.c
diff --git a/Documentation/devicetree/bindings/tty/serial/st-asc.txt
b/Documentation/devicetree/bindings/tty/serial/st-asc.txt
new file mode 100644
index 000..75d877f
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/st-asc.txt
@@ -0,0 +1,18 @@
+*st-asc(Serial Port)
+
+Required properties:
+- compatible : Should be st,asc.
+- reg, reg-names, interrupts, interrupt-names : Standard way to define device
+ resources with names. look in
+ Documentation/devicetree/bindings/resource-names.txt
+
+Optional properties:
+- st,hw-flow-ctrl bool flag to enable hardware flow control.
+- st,force-m1 bool flat to force asc to be in Mode-1 recommeded
+ for high bit rates (above 19.2K)
+Example:
+serial@fe44{
+compatible= st,asc;
+reg = 0xfe44 0x2c;
+interrupts = 0 209 0;
+};
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 7e7006f..0c6ddf6 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -1484,6 +1484,22 @@ config SERIAL_RP2_NR_UARTS
If multiple cards are present, the default limit of 32 ports may
need to be increased.
+config SERIAL_ST_ASC
+ tristate ST ASC serial port support
+ select SERIAL_CORE
+ help
+ This driver is for the on-chip Asychronous Serial Controller on
+ STMicroelectronics STi SoCs.
+ ASC is embedded in ST COMMS IP block. It supports Rx Tx
functionality.
+ It support all industry standard baud rates.
+
+ If unsure, say N.
+
+config SERIAL_ST_ASC_CONSOLE
+ bool Support for console on ST ASC
+ depends on SERIAL_ST_ASC=y
+ select SERIAL_CORE_CONSOLE
+
endmenu
endif # TTY
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index eedfec4..536ccc7 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_SERIAL_KGDB_NMI) += kgdb_nmi.o
obj-$(CONFIG_SERIAL_KS8695) += serial_ks8695.o
obj-$(CONFIG_SERIAL_OMAP) += omap-serial.o
obj-$(CONFIG_SERIAL_ALTERA_UART) += altera_uart.o
+obj-$(CONFIG_SERIAL_ST_ASC) += st-asc.o
obj-$(CONFIG_KGDB_SERIAL_CONSOLE) += kgdboc.o
obj-$(CONFIG_SERIAL_QE) += ucc_uart.o
obj-$(CONFIG_SERIAL_TIMBERDALE)+= timbuart.o
diff --git a/drivers/tty/serial/st-asc.c b/drivers/tty/serial/st-asc.c
new file mode 100644
index 000..6592c04
--- /dev/null
+++ b/drivers/tty/serial/st-asc.c
@@ -0,0 +1,911 @@
+/*
+ * st-asc.c: ST Asynchronous serial controller (ASC) driver
+ *
+ * Copyright (C) 2003-2013 STMicroelectronics (RD) Limited
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#if defined(CONFIG_SERIAL_ST_ASC_CONSOLE) defined(CONFIG_MAGIC_SYSRQ)
+#define SUPPORT_SYSRQ
+#endif
+
+#include linux/module.h
+#include linux/serial.h
+#include linux/console.h
+#include linux/sysrq.h
+#include linux/platform_device.h
+#include linux/io.h
+#include linux/irq.h
+#include linux/tty.h
+#include linux/tty_flip.h
+#include linux/delay.h
+#include linux/spinlock.h
+#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/serial_core.h
+#include linux/clk.h
+
+#define DRIVER_NAME st-asc
+#define ASC_SERIAL_NAME ttyAS
+#define ASC_FIFO_SIZE 16
+#define ASC_MAX_PORTS 8
+
+struct asc_port {
+ struct uart_port port;
+ struct clk *clk;
+ unsigned int hw_flow_control:1;
+ unsigned int check_parity:1;
+ unsigned int force_m1:1;
+};
+
+static struct asc_port asc_ports[ASC_MAX_PORTS];
+static struct uart_driver asc_uart_driver;
+
+/* UART Register definitions --*/
+
+/* Register offsets */
+
+#define
[PATCH v2 00/11] ARM:STixxxx: Add STixxxx platform and board support
From: Srinivas Kandagatla srinivas.kandaga...@st.com Here is new patch-set incorporating all the review comments. This patch-set adds basic support for STMicroelectronics STi SOCs which includes STiH415 and STiH416 with B2000 and B2020 board support. STiH415 and STiH416 are dual-core ARM Cortex-A9 CPU, designed for use in Set-top-boxes. The SOC support is available in mach-sti which contains support code for STiH415, STiH416 SOCs including the generic board support. Only device drivers included in this patch set are UART and pinctrl, other drivers will be added in future. The reason for adding two SOCs at this patch set is to show that no new C code is required for second SOC(STiH416) support. Thankyou all for reviewing the first set of RFC patches. I would appreciate any feedback on these patches. Changes since RFC: - st-asc Serial driver: - modified kconfig to remove default y - removed all the forward declaration. - use dynamic major numbering. - merge header-file in to driver. - ARM Global timer: - moved to drivers/clocksource. - added revision check in driver. - removed unused header file. - moved to u64 from union gt_counter - comments added in get_counter - removed leftover debug code. - moved code to use __raw_readl/writel. - used DIV_ROUND_CLOSEST - added check in interrupt handler. - expanded CE and CS acronyms usage. - Fixed minimum clock ticks value. - move to use clocksource_register_hz - added arch sched_clock support. - added ERRATA 740657 workaround. - ST-System Configuration Registers: - moved from syscon usage to st specific driver. - ST Pinctrl support: - fixed few typos in the documentation. - moved some of the retime offset information to driver. - STi Support: - all the SOC support code is moved to mach-sti - seperated DEBUG_LL code to new patch. - removed unnecessary #interrupt-cells - renamed uart to serial - moved to multi_v7_defconfig - used menuconfig in mach-stixxx/Kconfig - removed of_platform_populate as generic code does it for you. - scu address is ioremaped. Thanks, srini Srinivas Kandagatla (10): serial:st-asc: Add ST ASC driver. regmap: Add regmap_field APIs mfd:sti-syscfg: Add ST System Configuration support. pinctrl:sti: Add pinctrl and pinconf support. ARM:sti: Add STiH415 SOC support ARM:sti: Add STiH416 SOC support ARM:sti: Add DEBUG_LL console support ARM:sti: Add sti options to multi_v7_defconfig ARM:stih41x: Add B2000 board support ARM:stih41x: Add B2020 board support Stuart Menefy (1): clocksource:global_timer: Add ARM global timer support. Documentation/arm/sti/overview.txt | 33 + Documentation/arm/sti/stih415-overview.txt | 12 + Documentation/arm/sti/stih416-overview.txt | 12 + .../devicetree/bindings/arm/global_timer.txt | 21 + .../devicetree/bindings/mfd/sti-syscfg.txt | 18 + .../bindings/pinctrl/pinctrl-sti.txt | 116 ++ .../devicetree/bindings/tty/serial/st-asc.txt | 18 + MAINTAINERS| 11 + arch/arm/Kconfig |2 + arch/arm/Kconfig.debug | 38 + arch/arm/Makefile |1 + arch/arm/boot/dts/Makefile |4 + arch/arm/boot/dts/stih415-b2000.dts| 15 + arch/arm/boot/dts/stih415-b2020.dts| 15 + arch/arm/boot/dts/stih415-clock.dtsi | 38 + arch/arm/boot/dts/stih415-pinctrl.dtsi | 326 ++ arch/arm/boot/dts/stih415.dtsi | 102 ++ arch/arm/boot/dts/stih416-b2000.dts| 16 + arch/arm/boot/dts/stih416-b2020.dts| 16 + arch/arm/boot/dts/stih416-clock.dtsi | 41 + arch/arm/boot/dts/stih416-pinctrl.dtsi | 377 ++ arch/arm/boot/dts/stih416.dtsi | 111 ++ arch/arm/boot/dts/stih41x-b2000.dtsi | 41 + arch/arm/boot/dts/stih41x-b2020.dtsi | 42 + arch/arm/boot/dts/stih41x.dtsi | 38 + arch/arm/boot/dts/sti-pincfg.h | 94 ++ arch/arm/configs/multi_v7_defconfig| 32 +- arch/arm/include/debug/sti.S | 61 + arch/arm/mach-sti/Kconfig | 45 + arch/arm/mach-sti/Makefile |2 + arch/arm/mach-sti/board-dt.c | 50 + arch/arm/mach-sti/headsmp.S| 44 + arch/arm/mach-sti/platsmp.c| 117 ++ arch/arm/mach-sti/smp.h| 19 + drivers/base/regmap/internal.h |
[PATCH v2 04/11] mfd:stixxxx-syscfg: Add ST System Configuration support.
System configuration(aka syscfg) registers are very basic configuration
registers arranged in groups across ST Settop Box parts.
The SOCs are assembled from existing IP blocks, which don't change very
often. However these blocks are assembled in different configurations to
meet the device requirements. So most IP blocks as well as having a bus
interface through which their own registers are accessible, will also
have a number of bristles(wires) which are signals that are going in and
out of the IP for configuration and status. To make these signals
accessible to software they are wired to System Configuration
Registers.
Drivers target the IP blocks, which don't change much. Where as the
mapping of IP specific bristles(wires) to System Configuration
Registers do change per each SOC, and therefore we do not want this
information to be part of the driver.
Having a System Configuration infrastructure gives much flexibility and
abstraction to drivers to configure them. Typically in a SOC there will
be more than hundreds of these registers, which are again divided into
groups. The IP related config registers tend to much regular in latest
ST SOCs, so having a common place for configuring these registers makes
sense and avoid lot of code duplication.
This mfd driver provides higher level inialization routines for various
IPs like Ethernet, USB, PCIE, SATA and so on. Also it provides way to
get to syscfg registers via standard regmap api which is usefull for
drivers like pinctrl.
This patch adds support to ST System Configuration registers, which can
be configured by the drivers.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
CC: Stuart Menefy stuart.men...@st.com
CC: Stephen Gallimore stephen.gallim...@st.com
CC: Linus Walleij linus.wall...@linaro.org
CC: Mark Brown broo...@kernel.org
---
.../devicetree/bindings/mfd/sti-syscfg.txt | 18 ++
drivers/mfd/Kconfig| 10 ++
drivers/mfd/Makefile |1 +
drivers/mfd/sti-syscfg.c | 168
include/linux/mfd/sti-syscfg.h | 15 ++
5 files changed, 212 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/sti-syscfg.txt
create mode 100644 drivers/mfd/sti-syscfg.c
create mode 100644 include/linux/mfd/sti-syscfg.h
diff --git a/Documentation/devicetree/bindings/mfd/sti-syscfg.txt
b/Documentation/devicetree/bindings/mfd/sti-syscfg.txt
new file mode 100644
index 000..428c751
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/sti-syscfg.txt
@@ -0,0 +1,18 @@
+*STi SYSCFG
+
+- compatible : should be st,SOC-syscfg like st,stih415-syscfg
+ or st,stih416-syscfg.
+- reg, reg-names, interrupts, interrupt-names : Standard way to define device
+ resources with names. look in
+ Documentation/devicetree/bindings/resource-names.txt
+- syscfg-range start size : Should be syscfg number range for this bank.
+- syscfg-name : Should be name of the syscfg, will be used in
debugfs.
+
+Example of a SBC_SYSCFG bank node:
+
+syscfg_sbc: syscfg@fe60{
+ compatible = st,stih415-syscfg;
+ reg = 0xfe60 0xb4;
+ syscfg-range= 0 44;
+ syscfg-name = SYSCFG_SBC;
+};
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d54e985..af49b58 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -649,6 +649,16 @@ config MFD_STA2X11
select MFD_CORE
select REGMAP_MMIO
+config MFD_STI_SYSCFG
+ bool ST System Configuration Registers(aka syscfg) via regmap
+ select REGMAP_MMIO
+ help
+ Select this option to enable accessing STMicroelectronics
+ System Configuration Registers via standard regmap apis with
+ lookup helper functions.
+
+ If unsure, say N.
+
config MFD_SYSCON
bool System Controller Register R/W Based on Regmap
select REGMAP_MMIO
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 718e94a..c1f6570 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -150,6 +150,7 @@ obj-$(CONFIG_MFD_PALMAS)+= palmas.o
obj-$(CONFIG_MFD_VIPERBOARD)+= viperboard.o
obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
+obj-$(CONFIG_MFD_STI_SYSCFG) += sti-syscfg.o
obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-config.o vexpress-sysreg.o
diff --git a/drivers/mfd/sti-syscfg.c b/drivers/mfd/sti-syscfg.c
new file mode 100644
index 000..10ea4e4
--- /dev/null
+++ b/drivers/mfd/sti-syscfg.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics Limited
+ * Author: Srinivas Kandagatla srinivas.kandaga...@st.com
+ *
+ * May be copied
[PATCH v2 02/11] clocksource:global_timer: Add ARM global timer support.
From: Stuart Menefy stuart.men...@st.com
This is a simple driver for the global timer module found in the Cortex
A9-MP cores from revision r1p0 onwards. This should be able to perform
the functions of the system timer and the local timer in an SMP system.
The global timer has the following features:
The global timer is a 64-bit incrementing counter with an
auto-incrementing feature. It continues incrementing after sending
interrupts. The global timer is memory mapped in the private memory
region.
The global timer is accessible to all Cortex-A9 processors in the
cluster. Each Cortex-A9 processor has a private 64-bit comparator that
is used to assert a private interrupt when the global timer has reached
the comparator value. All the Cortex-A9 processors in a design use the
banked ID, ID27, for this interrupt. ID27 is sent to the Interrupt
Controller as a Private Peripheral Interrupt. The global timer is
clocked by PERIPHCLK.
Signed-off-by: Stuart Menefy stuart.men...@st.com
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
CC: Arnd Bergmann a...@arndb.de
CC: Rob Herring robherri...@gmail.com
CC: Linus Walleij linus.wall...@linaro.org
CC: Will Deacon will.dea...@arm.com
CC: Thomas Gleixner t...@linutronix.de
---
.../devicetree/bindings/arm/global_timer.txt | 21 ++
drivers/clocksource/Kconfig| 13 +
drivers/clocksource/Makefile |1 +
drivers/clocksource/arm_global_timer.c | 368
4 files changed, 403 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/global_timer.txt
create mode 100644 drivers/clocksource/arm_global_timer.c
diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt
b/Documentation/devicetree/bindings/arm/global_timer.txt
new file mode 100644
index 000..b64abac
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/global_timer.txt
@@ -0,0 +1,21 @@
+
+* ARM Global Timer
+ Cortex-A9 are often associated with a per-core Global timer.
+
+** Timer node required properties:
+
+- compatible : Should be arm,cortex-a9-global-timer
+ Driver supports versions r2p0 and above.
+
+- interrupts : One interrupt to each core
+
+- reg : Specify the base address and the size of the GT timer
+ register window.
+
+Example:
+
+ timer@2c000600 {
+ compatible = arm,cortex-a9-global-timer;
+ reg = 0x2c000600 0x20;
+ interrupts = 1 13 0xf01;
+ };
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index f151c6c..b0c4c42 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -67,6 +67,19 @@ config ARM_ARCH_TIMER
bool
select CLKSRC_OF if OF
+config ARM_GLOBAL_TIMER
+ bool
+ select CLKSRC_OF if OF
+ help
+ This options enables support for the ARM global timer unit
+
+config CLKSRC_ARM_GLOBAL_TIMER_SCHED_CLOCK
+ bool
+ depends on ARM_GLOBAL_TIMER
+ default y
+ help
+Use ARM global timer clock source as sched_clock
+
config CLKSRC_METAG_GENERIC
def_bool y if METAG
help
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 8d979c7..b2363cb 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -28,4 +28,5 @@ obj-$(CONFIG_CLKSRC_EXYNOS_MCT) += exynos_mct.o
obj-$(CONFIG_CLKSRC_SAMSUNG_PWM) += samsung_pwm_timer.o
obj-$(CONFIG_ARM_ARCH_TIMER) += arm_arch_timer.o
+obj-$(CONFIG_ARM_GLOBAL_TIMER) += arm_global_timer.o
obj-$(CONFIG_CLKSRC_METAG_GENERIC) += metag_generic.o
diff --git a/drivers/clocksource/arm_global_timer.c
b/drivers/clocksource/arm_global_timer.c
new file mode 100644
index 000..e4bc4fe
--- /dev/null
+++ b/drivers/clocksource/arm_global_timer.c
@@ -0,0 +1,368 @@
+/*
+ * drivers/clocksource/arm_global_timer.c
+ *
+ * Copyright (C) 2013 STMicroelectronics (RD) Limited.
+ * Author: Stuart Menefy stuart.men...@st.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/init.h
+#include linux/interrupt.h
+#include linux/clocksource.h
+#include linux/clockchips.h
+#include linux/clk.h
+#include linux/clkdev.h
+#include linux/err.h
+#include linux/io.h
+#include linux/of.h
+#include linux/of_irq.h
+#include linux/of_address.h
+
+#include asm/sched_clock.h
+#include asm/mach/irq.h
+#include asm/cputype.h
+#include asm/localtimer.h
+
+#define GT_COUNTER00x00
+#define GT_COUNTER10x04
+
+#define GT_CONTROL 0x08
+#define GT_CONTROL_TIMER_ENABLEBIT(0) /* this bit is NOT
banked */
+#define GT_CONTROL_COMP_ENABLE BIT(1) /* banked */
+#define GT_CONTROL_IRQ_ENABLE BIT(2) /* banked */
+#define GT_CONTROL_AUTO_INCBIT(3) /* banked */
+
[PATCH v2 05/11] pinctrl:stixxxx: Add pinctrl and pinconf support.
This patch add pinctrl support to ST SoCs.
About hardware:
ST Set-Top-Box parts have two blocks called PIO and PIO-mux which handle
pin configurations.
Each multi-function pin is controlled, driven and routed through the PIO
multiplexing block. Each pin supports GPIO functionality (ALT0) and
multiple alternate functions(ALT1 - ALTx) that directly connect the pin
to different hardware blocks. When a pin is in GPIO mode, Output Enable
(OE), Open Drain(OD), and Pull Up (PU) are driven by the related PIO
block. Otherwise the PIO multiplexing block configures these parameters
and retiming the signal.
About driver:
This pinctrl driver manages both PIO and PIO-mux block using pinctrl,
pinconf, pinmux, gpio subsystems. All the pinctrl related config
information can only come from device trees.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
CC: Stephen Gallimore stephen.gallim...@st.com
CC: Stuart Menefy stuart.men...@st.com
CC: Arnd Bergmann a...@arndb.de
CC: Linus Walleij linus.wall...@linaro.org
---
.../bindings/pinctrl/pinctrl-sti.txt | 116 ++
drivers/pinctrl/Kconfig| 11 +
drivers/pinctrl/Makefile |1 +
drivers/pinctrl/pinctrl-sti.c | 1212
drivers/pinctrl/pinctrl-sti.h | 197
5 files changed, 1537 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/pinctrl/pinctrl-sti.txt
create mode 100644 drivers/pinctrl/pinctrl-sti.c
create mode 100644 drivers/pinctrl/pinctrl-sti.h
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-sti.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-sti.txt
new file mode 100644
index 000..ac69dca
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-sti.txt
@@ -0,0 +1,116 @@
+*ST pin controller.
+
+Each multi-function pin is controlled, driven and routed through the
+PIO multiplexing block. Each pin supports GPIO functionality (ALT0)
+and multiple alternate functions(ALT1 - ALTx) that directly connect
+the pin to different hardware blocks.
+
+When a pin is in GPIO mode, Output Enable (OE), Open Drain(OD), and
+Pull Up (PU) are driven by the related PIO block.
+
+ST pinctrl driver controls PIO multiplexing block and also interacts with
+gpio driver to configure a pin.
+
+Required properties: (PIO multiplexing block)
+- compatible : should be st,sti-pinctrl
+ each subnode should set st,sti-gpio
+ as compatible for each gpio-controller bank.
+- gpio-controller : Indicates this device is a GPIO controller
+- #gpio-cells: Should be one. The first cell is the pin number.
+- st,retime-in-delay : Should be array of delays in nsecs.
+- st,retime-out-delay : Should be array of delays in nsecs.
+- st,retime-pin-mask : Should be mask to specify which pins can be retimed.
+- st,bank-name : Should be a name string for this bank.
+- st,syscfg: phandle of the syscfg node.
+- st,syscfg-offsets: Should be a 5 cell entry which represent offset of
altfunc,
+ output-enable, pull-up , open drain and retime registers in the syscfg
bank
+
+Example:
+ pin-controller {
+ compatible = st,sti-pinctrl, simple-bus;
+ st,retime-in-delay = 0 500 1000 1500;
+ st,retime-out-delay = 0 1000 2000 3000;
+ st,syscfg = syscfg_front;
+ st,syscfg-offsets = 0 8 10 12 16;
+ ranges;
+ PIO0: pinctrl@fe61 {
+ gpio-controller;
+ #gpio-cells = 1;
+ compatible = st,sti-gpio;
+ reg = 0xfe61 0x100;
+ st,bank-name = PIO0;
+ };
+ ...
+ pin-functions nodes follow...
+ };
+
+
+Contents of function subnode node:
+--
+Required properties for pin configuration node:
+- st,function : Should be alternate function number associated
+ with this set of pins. Use same numbers from datasheet.
+
+- st,pins : Child node with list of pins with configuration.
+
+Below is the format of how each pin conf should look like.
+
+bank offset mode rt_type rt_delay rt_clk
+
+Every PIO is represented with 4-7 parameters depending on retime configuration.
+Each parameter is explained as below.
+
+-bank : Should be bank phandle to which this PIO belongs.
+-offset: Offset in the PIO bank.
+-mode :pin configuration is selected from one of the below values.
+ IN
+ IN_PU
+ OUT
+ BIDIR
+ BIDIR_PU
+
+-rt_type Retiming Configuration for the pin.
+ Possible retime configuration are:
+
+ --- -
+ value args
+
[PATCH v2 03/11] regmap: Add regmap_field APIs
It is common to access regmap registers at bit level, using
regmap_update_bits or regmap_read functions, however the end user has to
take care of a mask or shifting. This becomes overhead when such use
cases are high. Having a common function to do this is much convenient
and less error prone.
The idea of regmap_field is simple, regmap_field gives a logical
structure to bits of the regmap register, and the driver can use this
logical entity without the knowledge of the bit postions and masks all
over the code. This way code looks much neat and it need not handle the
masks, shifts every time it access the those entities.
With this new regmap_field_read/write apis the end user can setup a
regmap field using regmap_field_init and use the return regmap_field to
read write the register field without worrying about the masks or
shifts.
Also this apis will be usefull for drivers which are based on regmaps,
like some clocks or pinctrls which can work on the regmap_fields
directly without having to worry about bit positions.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
CC: Mark Brown broo...@kernel.org
CC: Arnd Bergmann a...@arndb.de
CC: Alexander Shiyan shc_w...@mail.ru
CC: Lars-Peter Clausen l...@metafoo.de
---
drivers/base/regmap/internal.h |8 +++
drivers/base/regmap/regmap.c | 104
include/linux/regmap.h | 42
3 files changed, 154 insertions(+), 0 deletions(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index c130536..c5f6ebd 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -174,6 +174,14 @@ struct regmap_range_node {
unsigned int window_len;
};
+struct regmap_field {
+ struct regmap *regmap;
+ unsigned int mask;
+ /* lsb */
+ unsigned int shift;
+ unsigned int reg;
+};
+
#ifdef CONFIG_DEBUG_FS
extern void regmap_debugfs_initcall(void);
extern void regmap_debugfs_init(struct regmap *map, const char *name);
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index a941dcf..8d967cc 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -801,6 +801,67 @@ struct regmap *devm_regmap_init(struct device *dev,
}
EXPORT_SYMBOL_GPL(devm_regmap_init);
+static void regmap_field_init(struct regmap_field *rm_field,
+ struct regmap *regmap, struct reg_field reg_field)
+{
+ int field_bits = reg_field.msb - reg_field.lsb + 1;
+ rm_field-regmap = regmap;
+ rm_field-reg = reg_field.reg;
+ rm_field-shift = reg_field.lsb;
+ rm_field-mask = ((BIT(field_bits) - 1) reg_field.lsb);
+}
+
+/**
+ * devm_regmap_field_alloc(): Allocate and initialise a register field
+ * in a register map.
+ *
+ * @dev: Device that will be interacted with
+ * @regmap: regmap bank in which this register field is located.
+ * @reg_field: Register field with in the bank.
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer
+ * to a struct regmap_field. The regmap_field will be automatically freed
+ * by the device management code.
+ */
+struct regmap_field *devm_regmap_field_alloc(struct device *dev,
+ struct regmap *regmap, struct reg_field reg_field)
+{
+ struct regmap_field *rm_field = devm_kzalloc(dev,
+ sizeof(*rm_field), GFP_KERNEL);
+ if (!rm_field)
+ return ERR_PTR(-ENOMEM);
+
+ regmap_field_init(rm_field, regmap, reg_field);
+
+ return rm_field;
+
+}
+EXPORT_SYMBOL_GPL(devm_regmap_field_alloc);
+/**
+ * regmap_field_alloc(): Allocate and initialise a register field
+ * in a register map.
+ *
+ * @regmap: regmap bank in which this register field is located.
+ * @reg_field: Register field with in the bank.
+ *
+ * The return value will be an ERR_PTR() on error or a valid pointer
+ * to a struct regmap_field. The regmap_field should be freed by the
+ * user once its finished working with it using regmap_field_free().
+ */
+struct regmap_field *regmap_field_alloc(struct regmap *regmap,
+ struct reg_field reg_field)
+{
+ struct regmap_field *rm_field = kzalloc(sizeof(*rm_field), GFP_KERNEL);
+
+ if (!rm_field)
+ return ERR_PTR(-ENOMEM);
+
+ regmap_field_init(rm_field, regmap, reg_field);
+
+ return rm_field;
+}
+EXPORT_SYMBOL_GPL(regmap_field_alloc);
+
/**
* regmap_reinit_cache(): Reinitialise the current register cache
*
@@ -1249,6 +1310,23 @@ int regmap_raw_write(struct regmap *map, unsigned int
reg,
}
EXPORT_SYMBOL_GPL(regmap_raw_write);
+/**
+ * regmap_field_write(): Write a value to a single register field
+ *
+ * @field: Register field to write to
+ * @val: Value to be written
+ *
+ * A value of zero will be returned on success, a negative errno will
+ * be returned in error cases.
+ */
+
+int regmap_field_write(struct regmap_field *field, unsigned int val)
+{
+ return
Re: [patch -next] spi: spi-xilinx: cleanup a check in xilinx_spi_txrx_bufs()
On Sun, Jun 09, 2013 at 04:07:28PM +0300, Dan Carpenter wrote: '!' has higher precedence than comparisons so the original condition is equivalent to if (xspi-remaining_bytes == 0). This makes the static checkers complain. Applied, thanks. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: add dtsi for palmas
Hi Keerthy,
On 06/10/2013 06:03 AM, J, KEERTHY wrote:
Hi Stephen,
Thanks for the review comments.
From: Stephen Warren [swar...@wwwdotorg.org]
Sent: Saturday, June 08, 2013 1:26 AM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-discuss@lists.ozlabs.org;
linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/07/2013 05:28 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
+palmas {
Hmmm. That (i.e. requiring the board file to declare the node, then
setting up all the content by later including this file) is an
interesting approach. I guess it's reasonable. The one issue is that it
makes it a little harder for the board file to override any of the
properties in this file., although it certainly is possible by including
those overrides after the include.
Irrespective of that, some comments on this:
+ palmas_pmic {
+ ti,ldo6-vibrator;
For example, what if the board doesn't want to have the property set?
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
Or what if the board wants to limit the voltage range of this regulator
due to what it's used for on the board.
+ regulator-always-on;
+ regulator-boot-on;
And those two properties are almost certainly board-specific policy.
Totally agree to all the above concerns. So can we have a custom .dtsi file
for a board+pmic combination? Or have only the required properties over ridden
in the board file?
Yes, you can do that potentially if most OMAP5 boards will reuse the
same kind of settings. Kevin has just done that for OMAP3 + twl4030.
In this case, since we do have only one board, I'm not sure it worth the
effort.
Regards,
Benoit
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 11/11] ARM:stih41x: Add B2020 board support
B2020 ADI board is reference board for STIH415/416 SOCs, it has 2 x
UART, 4x USB, 1 x Ethernet, 1 x SATA, 1 x PCIe, and 2GB RAM with
standard set-top box IPs.
This patch adds initial support to B2020 with STiH415/416 with SBC_UART1
as console and a heard beat LED.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
CC: Stephen Gallimore stephen.gallim...@st.com
CC: Stuart Menefy stuart.men...@st.com
CC: Arnd Bergmann a...@arndb.de
---
arch/arm/boot/dts/Makefile |4 ++-
arch/arm/boot/dts/stih415-b2020.dts | 15
arch/arm/boot/dts/stih416-b2020.dts | 16 +
arch/arm/boot/dts/stih41x-b2020.dtsi | 42 ++
4 files changed, 76 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/boot/dts/stih415-b2020.dts
create mode 100644 arch/arm/boot/dts/stih416-b2020.dts
create mode 100644 arch/arm/boot/dts/stih41x-b2020.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index d4615fd..0d24c95 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -178,7 +178,9 @@ dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \
spear320-hmi.dtb
dtb-$(CONFIG_ARCH_SPEAR6XX)+= spear600-evb.dtb
dtb-$(CONFIG_ARCH_STI)+= stih415-b2000.dtb \
- stih416-b2000.dtb
+ stih416-b2000.dtb \
+ stih415-b2020.dtb \
+ stih416-b2020.dtb
dtb-$(CONFIG_ARCH_SUNXI) += \
sun4i-a10-cubieboard.dtb \
sun4i-a10-mini-xplus.dtb \
diff --git a/arch/arm/boot/dts/stih415-b2020.dts
b/arch/arm/boot/dts/stih415-b2020.dts
new file mode 100644
index 000..442b019
--- /dev/null
+++ b/arch/arm/boot/dts/stih415-b2020.dts
@@ -0,0 +1,15 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (RD) Limited.
+ * Author: Srinivas Kandagatla srinivas.kandaga...@st.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * publishhed by the Free Software Foundation.
+ */
+/dts-v1/;
+#include stih415.dtsi
+#include stih41x-b2020.dtsi
+/ {
+ model = STiH415 B2020 Board;
+ compatible = st,stih415, st,stih415-b2020;
+};
diff --git a/arch/arm/boot/dts/stih416-b2020.dts
b/arch/arm/boot/dts/stih416-b2020.dts
new file mode 100644
index 000..276f28d
--- /dev/null
+++ b/arch/arm/boot/dts/stih416-b2020.dts
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (RD) Limited.
+ * Author: Srinivas Kandagatla srinivas.kandaga...@st.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * publishhed by the Free Software Foundation.
+ */
+/dts-v1/;
+#include stih416.dtsi
+#include stih41x-b2020.dtsi
+/ {
+ model = STiH416 B2020;
+ compatible = st,stih416, st,stih416-b2020;
+
+};
diff --git a/arch/arm/boot/dts/stih41x-b2020.dtsi
b/arch/arm/boot/dts/stih41x-b2020.dtsi
new file mode 100644
index 000..133e181
--- /dev/null
+++ b/arch/arm/boot/dts/stih41x-b2020.dtsi
@@ -0,0 +1,42 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (RD) Limited.
+ * Author: Srinivas Kandagatla srinivas.kandaga...@st.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * publishhed by the Free Software Foundation.
+ */
+/ {
+ memory{
+ device_type = memory;
+ reg = 0x4000 0x8000;
+ };
+
+ chosen {
+ bootargs = console=ttyAS0,115200;
+ linux,stdout-path = sbc_serial1;
+ };
+
+ aliases {
+ ttyAS0 = sbc_serial1;
+ };
+ soc {
+ sbc_serial1: serial@fe531000 {
+ status = okay;
+ };
+
+ leds {
+ compatible = gpio-leds;
+ red {
+ #gpio-cells = 1;
+ label = Front Panel LED;
+ gpios = PIO4 1;
+ linux,default-trigger = heartbeat;
+ };
+ green {
+ gpios = PIO4 7;
+ default-state = off;
+ };
+ };
+ };
+};
--
1.7.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 08/11] ARM:stixxxx: Add DEBUG_LL console support
This patch adds low level debug uart support to sti based SOCs. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com CC: Arnd Bergmann a...@arndb.de --- arch/arm/Kconfig.debug | 38 +++ arch/arm/include/debug/sti.S | 61 ++ arch/arm/mach-sti/board-dt.c |2 + 3 files changed, 101 insertions(+), 0 deletions(-) create mode 100644 arch/arm/include/debug/sti.S diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index 1d41908..cc98ef3 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -483,6 +483,16 @@ choice This option selects UART0 on VIA/Wondermedia System-on-a-chip devices, including VT8500, WM8505, WM8650 and WM8850. + config DEBUG_STI_UART + depends on ARCH_STI + bool Use StiH415/416 ASC for low-level debug + help + Say Y here if you want kernel low-level debugging support + on StiH415/416 based platforms like B2000, B2020. + It support UART2 and SBC_UART1. + + If unsure, say N. + config DEBUG_LL_UART_NONE bool No low-level debugging UART depends on !ARCH_MULTIPLATFORM @@ -617,6 +627,33 @@ choice endchoice +choice + prompt Low-level debug console UART + depends on DEBUG_LL DEBUG_STI_UART + + config STIH41X_DEBUG_ASC2 + bool ASC2 UART + help + Say Y here if you want kernel low-level debugging support + on STiH415/416 based platforms like b2000, which has + default UART wired up to ASC2. + + If unsure, say N. + + config STIH41X_DEBUG_SBC_ASC1 + bool SBC ASC1 UART + help + Say Y here if you want kernel low-level debugging support + on STiH415/416 based platforms like b2020. which has + default UART wired up to SBC ASC1. + + If unsure, say N. + +endchoice + + + + config DEBUG_LL_INCLUDE string default debug/bcm2835.S if DEBUG_BCM2835 @@ -641,6 +678,7 @@ config DEBUG_LL_INCLUDE DEBUG_MMP_UART3 default debug/sirf.S if DEBUG_SIRFPRIMA2_UART1 || DEBUG_SIRFMARCO_UART1 default debug/socfpga.S if DEBUG_SOCFPGA_UART + default debug/sti.S if DEBUG_STI_UART default debug/sunxi.S if DEBUG_SUNXI_UART0 || DEBUG_SUNXI_UART1 default debug/tegra.S if DEBUG_TEGRA_UART default debug/ux500.S if DEBUG_UX500_UART diff --git a/arch/arm/include/debug/sti.S b/arch/arm/include/debug/sti.S new file mode 100644 index 000..7bc02a7 --- /dev/null +++ b/arch/arm/include/debug/sti.S @@ -0,0 +1,61 @@ +/* + * arch/arm/include/debug/sti.S + * + * Debugging macro include header + * Copyright (C) 2013 STMicroelectronics (RD) Limited. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#define STIH41X_COMMS_BASE 0xfed0 +#define STIH41X_ASC2_BASE (STIH41X_COMMS_BASE+0x32000) + +#define STIH41X_SBC_LPM_BASE0xfe40 +#define STIH41X_SBC_COMMS_BASE (STIH41X_SBC_LPM_BASE + 0x10) +#define STIH41X_SBC_ASC1_BASE (STIH41X_SBC_COMMS_BASE + 0x31000) + + +#define VIRT_ADDRESS(x)(x - 0x100) + +#if IS_ENABLED(CONFIG_STIH41X_DEBUG_ASC2) +#define DEBUG_LL_UART_BASE STIH41X_ASC2_BASE +#endif + +#if IS_ENABLED(CONFIG_STIH41X_DEBUG_SBC_ASC1) +#define DEBUG_LL_UART_BASE STIH41X_SBC_ASC1_BASE +#endif + +#ifndef DEBUG_LL_UART_BASE +#error DEBUG UART is not Configured +#endif + +#define ASC_TX_BUF_OFF 0x04 +#define ASC_CTRL_OFF0x0c +#define ASC_STA_OFF 0x14 + +#define ASC_STA_TX_FULL (19) +#define ASC_STA_TX_EMPTY(11) + + + .macro addruart, rp, rv, tmp + ldr \rp, =DEBUG_LL_UART_BASE @ physical base + ldr \rv, =VIRT_ADDRESS(DEBUG_LL_UART_BASE) @ virt base + .endm + +.macro senduart,rd,rx +strb\rd, [\rx, #ASC_TX_BUF_OFF] +.endm + +.macro waituart,rd,rx +1001: ldr \rd, [\rx, #ASC_STA_OFF] +tst \rd, #ASC_STA_TX_FULL +bne 1001b +.endm + +.macro busyuart,rd,rx +1001: ldr \rd, [\rx, #ASC_STA_OFF] +tst \rd, #ASC_STA_TX_EMPTY +beq 1001b +.endm diff --git a/arch/arm/mach-sti/board-dt.c b/arch/arm/mach-sti/board-dt.c index 2b2552e..2482d139 100644 --- a/arch/arm/mach-sti/board-dt.c +++ b/arch/arm/mach-sti/board-dt.c @@ -11,6 +11,7 @@
[PATCH v2 09/11] ARM:stixxxx: Add stixxxx options to multi_v7_defconfig
This patch adds stih415 and stih416 support to multi_v7_defconfig. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com CC: Arnd Bergmann a...@arndb.de --- arch/arm/configs/multi_v7_defconfig | 32 +++- 1 files changed, 15 insertions(+), 17 deletions(-) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 2e67a27..8a5cd5c 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -1,23 +1,20 @@ -CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_ARCH_MVEBU=y CONFIG_MACH_ARMADA_370=y -CONFIG_ARCH_SIRF=y CONFIG_MACH_ARMADA_XP=y CONFIG_ARCH_HIGHBANK=y CONFIG_ARCH_SOCFPGA=y -CONFIG_ARCH_SUNXI=y -CONFIG_ARCH_WM8850=y -# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set -CONFIG_ARCH_ZYNQ=y -CONFIG_ARM_ERRATA_754322=y CONFIG_PLAT_SPEAR=y CONFIG_ARCH_SPEAR13XX=y CONFIG_MACH_SPEAR1310=y CONFIG_MACH_SPEAR1340=y +CONFIG_ARCH_STI=y +CONFIG_ARCH_SUNXI=y +CONFIG_ARCH_SIRF=y +CONFIG_ARCH_WM8850=y +CONFIG_ARCH_ZYNQ=y CONFIG_SMP=y -CONFIG_ARM_ARCH_TIMER=y CONFIG_AEABI=y CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y @@ -25,27 +22,30 @@ CONFIG_ARM_APPENDED_DTB=y CONFIG_VFP=y CONFIG_NEON=y CONFIG_NET=y +CONFIG_DEVTMPFS=y CONFIG_BLK_DEV_SD=y CONFIG_ATA=y +CONFIG_SATA_AHCI_PLATFORM=y CONFIG_SATA_HIGHBANK=y CONFIG_SATA_MV=y -CONFIG_SATA_AHCI_PLATFORM=y CONFIG_NETDEVICES=y CONFIG_NET_CALXEDA_XGMAC=y CONFIG_SMSC911X=y CONFIG_STMMAC_ETH=y +CONFIG_KEYBOARD_SPEAR=y CONFIG_SERIO_AMBAKMI=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DW=y -CONFIG_KEYBOARD_SPEAR=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y -CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_SIRFSOC=y CONFIG_SERIAL_SIRFSOC_CONSOLE=y CONFIG_SERIAL_VT8500=y CONFIG_SERIAL_VT8500_CONSOLE=y +CONFIG_SERIAL_OF_PLATFORM=y +CONFIG_SERIAL_ST_ASC=y +CONFIG_SERIAL_ST_ASC_CONSOLE=y CONFIG_IPMI_HANDLER=y CONFIG_IPMI_SI=y CONFIG_I2C=y @@ -54,7 +54,6 @@ CONFIG_I2C_SIRF=y CONFIG_SPI=y CONFIG_SPI_PL022=y CONFIG_SPI_SIRF=y -CONFIG_GPIO_PL061=y CONFIG_FB=y CONFIG_FB_ARMCLCD=y CONFIG_FB_WM8505=y @@ -67,7 +66,6 @@ CONFIG_MMC_ARMMMCI=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PLTFM=y CONFIG_MMC_SDHCI_SPEAR=y -CONFIG_MMC_WMT=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_EDAC_HIGHBANK_MC=y @@ -75,9 +73,9 @@ CONFIG_EDAC_HIGHBANK_L2=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_PL031=y CONFIG_RTC_DRV_VT8500=y -CONFIG_PWM=y -CONFIG_PWM_VT8500=y CONFIG_DMADEVICES=y -CONFIG_PL330_DMA=y -CONFIG_SIRF_DMA=y CONFIG_DW_DMAC=y +CONFIG_SIRF_DMA=y +CONFIG_PL330_DMA=y +CONFIG_PWM=y +CONFIG_PWM_VT8500=y -- 1.7.6.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 10/11] ARM:stih41x: Add B2000 board support
B2000 board is reference board for STIH415/416 SOCs, it has
2 x UART, 4x USB, 2 x Ethernet, 1 x SATA, 1 x PCIe, and 1GB RAM.
This patch add initial support to b2000 with STiH415/416 with UART2 as
console and a heard beat LED.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
CC: Stephen Gallimore stephen.gallim...@st.com
CC: Arnd Bergmann a...@arndb.de
---
arch/arm/boot/dts/Makefile |2 +
arch/arm/boot/dts/stih415-b2000.dts | 15
arch/arm/boot/dts/stih416-b2000.dts | 16 +
arch/arm/boot/dts/stih41x-b2000.dtsi | 41 ++
4 files changed, 74 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/stih415-b2000.dts
create mode 100644 arch/arm/boot/dts/stih416-b2000.dts
create mode 100644 arch/arm/boot/dts/stih41x-b2000.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index f0895c5..d4615fd 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -177,6 +177,8 @@ dtb-$(CONFIG_ARCH_SPEAR3XX)+= spear300-evb.dtb \
spear320-evb.dtb \
spear320-hmi.dtb
dtb-$(CONFIG_ARCH_SPEAR6XX)+= spear600-evb.dtb
+dtb-$(CONFIG_ARCH_STI)+= stih415-b2000.dtb \
+ stih416-b2000.dtb
dtb-$(CONFIG_ARCH_SUNXI) += \
sun4i-a10-cubieboard.dtb \
sun4i-a10-mini-xplus.dtb \
diff --git a/arch/arm/boot/dts/stih415-b2000.dts
b/arch/arm/boot/dts/stih415-b2000.dts
new file mode 100644
index 000..d4af531
--- /dev/null
+++ b/arch/arm/boot/dts/stih415-b2000.dts
@@ -0,0 +1,15 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (RD) Limited.
+ * Author: Srinivas Kandagatla srinivas.kandaga...@st.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * publishhed by the Free Software Foundation.
+ */
+/dts-v1/;
+#include stih415.dtsi
+#include stih41x-b2000.dtsi
+/ {
+ model = STiH415 B2000 Board;
+ compatible = st,stih415, st,stih415-b2000;
+};
diff --git a/arch/arm/boot/dts/stih416-b2000.dts
b/arch/arm/boot/dts/stih416-b2000.dts
new file mode 100644
index 000..a5eb6ee
--- /dev/null
+++ b/arch/arm/boot/dts/stih416-b2000.dts
@@ -0,0 +1,16 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (RD) Limited.
+ * Author: Srinivas Kandagatla srinivas.kandaga...@st.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * publishhed by the Free Software Foundation.
+ */
+/dts-v1/;
+#include stih416.dtsi
+#include stih41x-b2000.dtsi
+
+/ {
+ compatible = st,stih416, st,stih416-b2000;
+ model = STiH416 B2000;
+};
diff --git a/arch/arm/boot/dts/stih41x-b2000.dtsi
b/arch/arm/boot/dts/stih41x-b2000.dtsi
new file mode 100644
index 000..8e694d2
--- /dev/null
+++ b/arch/arm/boot/dts/stih41x-b2000.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics (RD) Limited.
+ * Author: Srinivas Kandagatla srinivas.kandaga...@st.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * publishhed by the Free Software Foundation.
+ */
+/ {
+
+ memory{
+ device_type = memory;
+ reg = 0x6000 0x4000;
+ };
+
+ chosen {
+ bootargs = console=ttyAS0,115200;
+ linux,stdout-path = serial2;
+ };
+
+ aliases {
+ ttyAS0 = serial2;
+ };
+
+ soc {
+ serial2: serial@fed32000 {
+ status = okay;
+ };
+
+ leds {
+ compatible = gpio-leds;
+ fp_led {
+ #gpio-cells = 1;
+ label = Front Panel LED;
+ gpios = PIO105 7;
+ linux,default-trigger = heartbeat;
+ };
+ };
+
+ };
+};
--
1.7.6.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 01/11] serial:st-asc: Add ST ASC driver.
On Mon, Jun 10, 2013 at 10:21:00AM +0100, Srinivas KANDAGATLA wrote:
This patch adds support to ASC (asynchronous serial controller)
driver, which is basically a standard serial driver. This IP is common
across all the ST parts for settop box platforms.
ASC is embedded in ST COMMS IP block. It supports Rx Tx functionality.
It support all industry standard baud rates.
Your driver is not POSIX compliant.
+ for (; count != 0; count--) {
+ c = asc_in(port, ASC_RXBUF);
+ flag = TTY_NORMAL;
+ port-icount.rx++;
+
+ if (unlikely(c ASC_RXBUF_FE)) {
+ if (c == ASC_RXBUF_FE) {
+ port-icount.brk++;
+ if (uart_handle_break(port))
+ continue;
+ flag = TTY_BREAK;
+ } else {
+ port-icount.frame++;
+ flag = TTY_FRAME;
+ }
+ } else if (ascport-check_parity
+unlikely(c ASC_RXBUF_PE)) {
+ port-icount.parity++;
+ flag = TTY_PARITY;
+ }
+
+ if (uart_handle_sysrq_char(port, c))
+ continue;
+ tty_insert_flip_char(tport, c 0xff, flag);
+ }
+ if (overrun) {
+ port-icount.overrun++;
+ tty_insert_flip_char(tport, 0, TTY_OVERRUN);
+ }
No support for ignoring error conditions. No support for ignoring all
input... and:
+static void asc_set_termios(struct uart_port *port, struct ktermios *termios,
+ struct ktermios *old)
+{
+ struct asc_port *ascport = to_asc_port(port);
+ unsigned int baud;
+ u32 ctrl_val;
+ tcflag_t cflag;
+ unsigned long flags;
+
+ port-uartclk = clk_get_rate(ascport-clk);
+
+ baud = uart_get_baud_rate(port, termios, old, 0, port-uartclk/16);
+ cflag = termios-c_cflag;
+
+ spin_lock_irqsave(port-lock, flags);
+
+ /* read control register */
+ ctrl_val = asc_in(port, ASC_CTL);
+
+ /* stop serial port and reset value */
+ asc_out(port, ASC_CTL, (ctrl_val ~ASC_CTL_RUN));
+ ctrl_val = ASC_CTL_RXENABLE | ASC_CTL_FIFOENABLE;
+
+ /* reset fifo rx tx */
+ asc_out(port, ASC_TXRESET, 1);
+ asc_out(port, ASC_RXRESET, 1);
+
+ /* set character length */
+ if ((cflag CSIZE) == CS7) {
+ ctrl_val |= ASC_CTL_MODE_7BIT_PAR;
+ } else {
+ ctrl_val |= (cflag PARENB) ? ASC_CTL_MODE_8BIT_PAR :
+ ASC_CTL_MODE_8BIT;
+ }
+
+ ascport-check_parity = (cflag PARENB) ? 1 : 0;
+
+ /* set stop bit */
+ ctrl_val |= (cflag CSTOPB) ? ASC_CTL_STOP_2BIT : ASC_CTL_STOP_1BIT;
+
+ /* odd parity */
+ if (cflag PARODD)
+ ctrl_val |= ASC_CTL_PARITYODD;
+
+ /* hardware flow control */
+ if ((cflag CRTSCTS) ascport-hw_flow_control)
+ ctrl_val |= ASC_CTL_CTSENABLE;
This doesn't reflect those facts back into the termios structure to
indicate that they aren't supported.
Consider using uart_port's ignore and read status masks to implement
the break, framing, parity and overrun checking in your interrupt
handler using the same methodology as drivers like 8250, amba-pl011
etc. That will help you get these code sequences correct.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v4 2/6] clocksource: add Marvell Orion SoC timer
This patch add a DT enabled driver for timers found on Marvell Orion SoCs
(Kirkwood, Dove, Orion5x, and Discovery Innovation). It installs a free-
running clocksource on timer0 and a clockevent source on timer1.
Corresponding device tree documentation is also added.
Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com
---
Changelog:
v3-v4:
- export thread-safe access to TIMER_CTRL register to use with watchdog
- remove IRQF_DISABLED and add .irq to clock event (Suggested by Daniel Lezcano)
Notes:
- This is only an update to clocksource driver, the remaining patches are
not resent as they have not been changed.
- I will not rework orion watchdog driver for this patch set. It is written
Kirkwood/Orion5x specific although it will also work on Dove and it is messing
with shared registers. It has done it before, so I consider it broken anyway.
I (or somebody else) will take care of proper watchdog later.
- An updated branch can be found on
git://github.com/shesselba/linux-dove.git orion-irqchip-for-v3.11_v4
Cc: Grant Likely grant.lik...@linaro.org
Cc: Rob Herring rob.herr...@calxeda.com
Cc: Rob Landley r...@landley.net
Cc: Thomas Gleixner t...@linutronix.de
Cc: John Stultz john.stu...@linaro.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Jason Cooper ja...@lakedaemon.net
Cc: Andrew Lunn and...@lunn.ch
Cc: Thomas Petazzoni thomas.petazz...@free-electrons.com
Cc: Gregory Clement gregory.clem...@free-electrons.com
Cc: Daniel Lezcano daniel.lezc...@linaro.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
---
.../bindings/timer/marvell,orion-timer.txt | 17 +++
drivers/clocksource/Kconfig|5 +
drivers/clocksource/Makefile |1 +
drivers/clocksource/time-orion.c | 150
4 files changed, 173 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/timer/marvell,orion-timer.txt
create mode 100644 drivers/clocksource/time-orion.c
diff --git a/Documentation/devicetree/bindings/timer/marvell,orion-timer.txt
b/Documentation/devicetree/bindings/timer/marvell,orion-timer.txt
new file mode 100644
index 000..62bb826
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/marvell,orion-timer.txt
@@ -0,0 +1,17 @@
+Marvell Orion SoC timer
+
+Required properties:
+- compatible: shall be marvell,orion-timer
+- reg: base address of the timer register starting with TIMERS CONTROL register
+- interrupt-parent: phandle of the bridge interrupt controller
+- interrupts: should contain the interrupts for Timer0 and Timer1
+- clocks: phandle of timer reference clock (tclk)
+
+Example:
+ timer: timer {
+ compatible = marvell,orion-timer;
+ reg = 0x20300 0x20;
+ interrupt-parent = bridge_intc;
+ interrupts = 1, 2;
+ clocks = core_clk 0;
+ };
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index f151c6c..2404869 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -25,6 +25,11 @@ config DW_APB_TIMER_OF
config ARMADA_370_XP_TIMER
bool
+config ORION_TIMER
+ select CLKSRC_OF
+ select CLKSRC_MMIO
+ bool
+
config SUN4I_TIMER
bool
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 8d979c7..d1e8d68 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_DW_APB_TIMER_OF) += dw_apb_timer_of.o
obj-$(CONFIG_CLKSRC_NOMADIK_MTU) += nomadik-mtu.o
obj-$(CONFIG_CLKSRC_DBX500_PRCMU) += clksrc-dbx500-prcmu.o
obj-$(CONFIG_ARMADA_370_XP_TIMER) += time-armada-370-xp.o
+obj-$(CONFIG_ORION_TIMER) += time-orion.o
obj-$(CONFIG_ARCH_BCM2835) += bcm2835_timer.o
obj-$(CONFIG_ARCH_MARCO) += timer-marco.o
obj-$(CONFIG_ARCH_MXS) += mxs_timer.o
diff --git a/drivers/clocksource/time-orion.c b/drivers/clocksource/time-orion.c
new file mode 100644
index 000..ad7df17
--- /dev/null
+++ b/drivers/clocksource/time-orion.c
@@ -0,0 +1,150 @@
+/*
+ * Marvell Orion SoC timer handling.
+ *
+ * Sebastian Hesselbarth sebastian.hesselba...@gmail.com
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed as is without any
+ * warranty of any kind, whether express or implied.
+ *
+ * Timer 0 is used as free-running clocksource, while timer 1 is
+ * used as clock_event_device.
+ */
+
+#include linux/kernel.h
+#include linux/bitops.h
+#include linux/clk.h
+#include linux/clockchips.h
+#include linux/interrupt.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/spinlock.h
+#include asm/sched_clock.h
+
+#define TIMER_CTRL 0x00
+#define TIMER0_EN BIT(0)
+#define TIMER0_RELOAD_EN BIT(1)
+#define TIMER1_EN
Re: [PATCH v2 06/11] ARM:stixxxx: Add STiH415 SOC support
signature.asc Description: OpenPGP digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3] mfd: DT bindings for the palmas family MFD
On Mon, 10 Jun 2013, J, KEERTHY wrote: Hello Grant/Lee Jones, -Original Message- From: Lee Jones [mailto:lee.jo...@linaro.org] Sent: Thursday, June 06, 2013 12:36 PM To: J, KEERTHY Cc: linux-ker...@vger.kernel.org; grant.lik...@secretlab.ca; linux- d...@vger.kernel.org; devicetree-discuss@lists.ozlabs.org; swar...@wwwdotorg.org; swar...@nvidia.com; rob.herr...@calxeda.com; r...@landley.net; sa...@linux.intel.com; w...@iguana.be; lgirdw...@gmail.com; g...@slimlogic.co.uk; Kristo, Tero; Ian Lartey Subject: Re: [PATCH v3] mfd: DT bindings for the palmas family MFD On Thu, 06 Jun 2013, Lee Jones wrote: On Thu, 06 Jun 2013, J Keerthy wrote: Add the various binding files for the palmas family of chips. There is a top level MFD binding then a seperate binding for regulators IP blocks on chips. Signed-off-by: Graeme Gregory g...@slimlogic.co.uk Signed-off-by: J Keerthy j-keer...@ti.com Signed-off-by: Ian Lartey i...@slimlogic.co.uk Reviewed-by: Stephen Warren swar...@nvidia.com --- Documentation/devicetree/bindings/mfd/palmas.txt | 49 + .../devicetree/bindings/regulator/palmas-pmic.txt | 72 2 files changed, 121 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/mfd/palmas.txt create mode 100644 Documentation/devicetree/bindings/regulator/palmas-pmic.tx Applied, thanks. Ah wait. It appears Grant wants to take this. Unapplied, thanks. :) Is it applied? Not by me. I unapplied it when I saw that Grant took an earlier revision. I won't apply again unless Grant gives the nod. Failing that, I'm sure he'll take it. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH v2 07/11] ARM:stixxxx: Add STiH416 SOC support
The STiH416 is advanced HD AVC processor with 3D graphics acceleration
and 1.2-GHz ARM Cortex-A9 SMP CPU.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
CC: Stephen Gallimore stephen.gallim...@st.com
CC: Stuart Menefy stuart.men...@st.com
CC: Arnd Bergmann a...@arndb.de
CC: Linus Walleij linus.wall...@linaro.org
---
Documentation/arm/sti/stih416-overview.txt | 12 +
arch/arm/boot/dts/stih416-clock.dtsi | 41 +++
arch/arm/boot/dts/stih416-pinctrl.dtsi | 377
arch/arm/boot/dts/stih416.dtsi | 111 +++
arch/arm/mach-sti/board-dt.c |3 +-
5 files changed, 543 insertions(+), 1 deletions(-)
create mode 100644 Documentation/arm/sti/stih416-overview.txt
create mode 100644 arch/arm/boot/dts/stih416-clock.dtsi
create mode 100644 arch/arm/boot/dts/stih416-pinctrl.dtsi
create mode 100644 arch/arm/boot/dts/stih416.dtsi
diff --git a/Documentation/arm/sti/stih416-overview.txt
b/Documentation/arm/sti/stih416-overview.txt
new file mode 100644
index 000..e060867
--- /dev/null
+++ b/Documentation/arm/sti/stih416-overview.txt
@@ -0,0 +1,12 @@
+ STiH416 Overview
+
+
+Introduction
+
+
+The STiH416 is the next generation of HD, AVC set-top box processors
+for satellite, cable, terrestrial and IP-STB markets.
+
+Features
+- ARM Cortex-A9 1.2 GHz dual core CPU
+- SATA2×2,USB 2.0×3, PCIe, Gbit Ethernet MAC×2
diff --git a/arch/arm/boot/dts/stih416-clock.dtsi
b/arch/arm/boot/dts/stih416-clock.dtsi
new file mode 100644
index 000..7026bf1
--- /dev/null
+++ b/arch/arm/boot/dts/stih416-clock.dtsi
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2013 STMicroelectronics RD Limited
+ * stlinux-de...@stlinux.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/ {
+ clocks {
+ /*
+* Fixed 30MHz oscillator inputs to SoC
+*/
+ CLK_SYSIN: CLK_SYSIN {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 3000;
+ clock-output-names = CLK_SYSIN;
+ };
+
+ /*
+* ARM Peripheral clock for timers
+*/
+ arm_periph_clk: arm_periph_clk {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 6;
+ };
+
+ /*
+* Bootloader initialized system infrastructure clock for
+* serial devices.
+*/
+ CLK_S_ICN_REG_0: clockgenA0@4 {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1;
+ clock-output-names = CLK_S_ICN_REG_0;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/stih416-pinctrl.dtsi
b/arch/arm/boot/dts/stih416-pinctrl.dtsi
new file mode 100644
index 000..15843a9
--- /dev/null
+++ b/arch/arm/boot/dts/stih416-pinctrl.dtsi
@@ -0,0 +1,377 @@
+
+/*
+ * Copyright (C) 2013 STMicroelectronics Limited.
+ * Author: Srinivas Kandagatla srinivas.kandaga...@st.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * publishhed by the Free Software Foundation.
+ */
+#include sti-pincfg.h
+/ {
+
+ aliases {
+ gpio0 = PIO0;
+ gpio1 = PIO1;
+ gpio2 = PIO2;
+ gpio3 = PIO3;
+ gpio4 = PIO4;
+ gpio5 = PIO40;
+ gpio6 = PIO5;
+ gpio7 = PIO6;
+ gpio8 = PIO7;
+ gpio9 = PIO8;
+ gpio10 = PIO9;
+ gpio11 = PIO10;
+ gpio12 = PIO11;
+ gpio13 = PIO12;
+ gpio14 = PIO30;
+ gpio15 = PIO31;
+ gpio16 = PIO13;
+ gpio17 = PIO14;
+ gpio18 = PIO15;
+ gpio19 = PIO16;
+ gpio20 = PIO17;
+ gpio21 = PIO18;
+ gpio22 = PIO100;
+ gpio23 = PIO101;
+ gpio24 = PIO102;
+ gpio25 = PIO103;
+ gpio26 = PIO104;
+ gpio27 = PIO105;
+ gpio28 = PIO106;
+ gpio29 = PIO107;
+ };
+
+ soc {
+ pin-controller-sbc {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = st,stih416-pinctrl, simple-bus;
+ st,retime-in-delay = 0
RE: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
From: Tony Lindgren [t...@atomide.com]
Sent: Friday, June 07, 2013 11:50 PM
To: linus.wall...@linaro.org
Cc: devicetree-discuss@lists.ozlabs.org; Haojian Zhuang; Ujfalusi, Peter;
linux-o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Quadros, Roger
Subject: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up
events
For wake-up events from deeper idle modes we need to check the
configured padconf registers for the wake-up bit and then call
the related interrupt handler.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
drivers/pinctrl/Makefile |3
drivers/pinctrl/pinctrl-single-omap.c | 287 +
include/linux/platform_data/pinctrl-single-omap.h |4
3 files changed, 293 insertions(+), 1 deletion(-)
create mode 100644 drivers/pinctrl/pinctrl-single-omap.c
create mode 100644 include/linux/platform_data/pinctrl-single-omap.h
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 9bdaeb8..abf7f01 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -30,7 +30,8 @@ obj-$(CONFIG_PINCTRL_NOMADIK) += pinctrl-nomadik.o
obj-$(CONFIG_PINCTRL_STN8815) += pinctrl-nomadik-stn8815.o
obj-$(CONFIG_PINCTRL_DB8500) += pinctrl-nomadik-db8500.o
obj-$(CONFIG_PINCTRL_DB8540) += pinctrl-nomadik-db8540.o
-obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o
+pcs-$(CONFIG_ARCH_OMAP2PLUS) += pinctrl-single-omap.o
+obj-$(CONFIG_PINCTRL_SINGLE) += pinctrl-single.o $(pcs-y)
obj-$(CONFIG_PINCTRL_SIRF) += pinctrl-sirf.o
obj-$(CONFIG_PINCTRL_SUNXI)+= pinctrl-sunxi.o
obj-$(CONFIG_PINCTRL_TEGRA)+= pinctrl-tegra.o
diff --git a/drivers/pinctrl/pinctrl-single-omap.c
b/drivers/pinctrl/pinctrl-single-omap.c
new file mode 100644
index 000..680cf81
--- /dev/null
+++ b/drivers/pinctrl/pinctrl-single-omap.c
@@ -0,0 +1,287 @@
+/*
+ * pinctrl-single-omap - omap specific wake-up irq handler
+ *
+ * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ *
+ */
snip
+
+static int __init pcs_omap_init(void)
+{
+ platform_driver_register(pcs_omap_soc_driver);
+ platform_driver_register(pcs_omap_driver);
+
+ return 0;
+}
+module_init(pcs_omap_init);
It seems this has to be moved to an earlier place (e.g. subsys_initcall)
else the pinctrl core fails to find the pinctrl device at the device creation
time and bails out with -EPROBE_DEFER. Also, that device is never
created again, so -EPROBE_DEFER doesn't seem to work there.
The code i'm talking about is in dt_to_map_one_config()
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/pinctrl/devicetree.c#n109
+
+static void __exit pcs_omap_exit(void)
+{
+ platform_driver_unregister(pcs_omap_driver);
+ platform_driver_unregister(pcs_omap_soc_driver);
+}
+module_exit(pcs_omap_exit);
+
+MODULE_ALIAS(platform: pinctrl-single-omap);
+MODULE_AUTHOR(Texas Instruments Inc.);
+MODULE_DESCRIPTION(pinctrl-single-omap driver);
+MODULE_LICENSE(GPL v2);
diff --git a/include/linux/platform_data/pinctrl-single-omap.h
b/include/linux/platform_data/pinctrl-single-omap.h
new file mode 100644
index 000..bd92efc
--- /dev/null
+++ b/include/linux/platform_data/pinctrl-single-omap.h
@@ -0,0 +1,4 @@
+struct pcs_omap_pdata {
+ int irq;
+ void (*reconfigure_io_chain)(void);
+};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 2/2] ARM: dts: OMAP5: add palmas node and omap specific palmas regulator properties
On Mon, 10 Jun 2013, J Keerthy wrote:
Add palmas node and omap specific palmas regulator properties.
Signed-off-by: J Keerthy j-keer...@ti.com
---
arch/arm/boot/dts/omap5-uevm.dts | 147
++
1 files changed, 147 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-uevm.dts
b/arch/arm/boot/dts/omap5-uevm.dts
index 927db1e..ffbcc3f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -8,6 +8,8 @@
/dts-v1/;
#include omap5.dtsi
+#include dt-bindings/interrupt-controller/irq.h
+#include dt-bindings/interrupt-controller/arm-gic.h
/ {
model = TI OMAP5 uEVM board;
@@ -254,6 +256,151 @@
pinctrl-0 = i2c1_pins;
clock-frequency = 40;
+
+ palmas: palmas@48 {
+ reg = 0x48;
+ /* SPI = 0, IRQ# = 7, active high level-sensitive */
I still think this is superfluous, especially now you're using the
defines which basically say the same thing.
+ interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; /* IRQ_SYS_1N */
+ interrupt-parent = gic;
+ };
+
+};
+
+#include palmas.dtsi
+
+palmas {
+ palmas_pmic {
+ ti,ldo6-vibrator;
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps45_reg: smps45 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps6_reg: smps6 {
+ regulator-min-microvolt = 120;
+ regulator-max-microvolt = 120;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps7_reg: smps7 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps8_reg: smps8 {
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 131;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ smps9_reg: smps9 {
+ regulator-min-microvolt = 210;
+ regulator-max-microvolt = 210;
+ regulator-always-on;
+ regulator-boot-on;
+ ti,smps-range = 0x80;
+ };
+
+ smps10_reg: smps10 {
+ regulator-min-microvolt = 500;
+ regulator-max-microvolt = 500;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo1_reg: ldo1 {
+ regulator-min-microvolt = 280;
+ regulator-max-microvolt = 280;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo2_reg: ldo2 {
+ regulator-min-microvolt = 290;
+ regulator-max-microvolt = 290;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo3_reg: ldo3 {
+ regulator-min-microvolt = 300;
+ regulator-max-microvolt = 300;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo4_reg: ldo4 {
+ regulator-min-microvolt = 220;
+ regulator-max-microvolt = 220;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ ldo5_reg: ldo5 {
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: So, the biggest problem here has been patch 4 (having to have a hack to deploy this stuff is a bit worrying) plus the general not having a real driver thing. +- ti,i2c-slave-address - I2C slave address of the PMIC +- ti,i2c-voltage-register - I2C register address where voltage commands are + to be set. +- ti,i2c-command-register - I2C register address where commands are to be set + when OMAP enters low power state. This may be the same as + ti,i2c-voltage-register depending on the PMIC. +- ti,slew-rate-microvolt - worst case slew rate of rise / fall for voltage + transition in microvolts per microseconds (uV/uS) +- step-size-micro-volts - Step size in micovolts as to what one step in voltage + selector increment translates to. See example. +- regulator-min-microvolt - Minimum voltage in microvolts which is supported by + the PMIC in ti,step-size-microvolt increments. See example. +- regulator-max-microvolt - Maximum voltage in microvolts which is supported + by the PMIC in ti,step-size-microvolt increments. See example. The other thing is this whole business of encoding the properties of the PMIC in the DT like this. Paul Walmsley has started doing some work for some similiar hardware where instead of doing this the regulator is in the DT as normal and then the driver for the offloaded voltage scaling gets the information about the register layout from the regulator driver. This is a bit neater overall and would cope with determining which method to use at runtime. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 0/5] clk/exynos5250: add clocks for hdmi subsystem
Add clock changes for hdmi subsystem for exynos5250 SoC. These include addition of new clocks like mout_hdmi and smmu_tv, associating ID to clk_hdmiphy and some essential corrections. This set is based on kukjin's for-next branch at http://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git. Arun Kumar K (1): clk/exynos5250: Fix HDMI clock number in documentation Rahul Sharma (4): clk/exynos5250: add mout_hdmi mux clock for hdmi clk/exynos5250: add sclk_hdmiphy in the list of special clocks clk/exynos5250: add clock for tv sysmmu clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem .../devicetree/bindings/clock/exynos5250-clock.txt | 12 +++- drivers/clk/samsung/clk-exynos5250.c | 18 +- 2 files changed, 24 insertions(+), 6 deletions(-) -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/5] clk/exynos5250: Fix HDMI clock number in documentation
From: Arun Kumar K arun...@samsung.com This patch corrects the HDMI clock number given wrongly in the documentation. Signed-off-by: Arun Kumar K arun...@samsung.com Signed-off-by: Rahul Sharma rahul.sha...@samsung.com --- Documentation/devicetree/bindings/clock/exynos5250-clock.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt index 781a627..1a05761 100644 --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt @@ -154,7 +154,7 @@ clock which they consume. dsim0341 dp 342 mixer343 - hdmi 345 + hdmi 344 Example 1: An example of a clock controller node is listed below. -- 1.7.10.4 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 09/11] ARM:stixxxx: Add stixxxx options to multi_v7_defconfig
On Mon, Jun 10, 2013 at 10:27:57AM +0100, Srinivas KANDAGATLA wrote: This patch adds stih415 and stih416 support to multi_v7_defconfig. This seems to drop a few options also: CONFIG_ARM_ARCH_TIMER CONFIG_ARM_ERRATA_754322 CONFIG_EXPERIMENTAL CONFIG_GPIO_PL061 CONFIG_MMC_WMT I just applied this to v3.10-rc5, and ran `make ARCH=arm multi_v7_defconfig`. It seems MMC_WMT and GPIO_PL061 get selected elsewhere, but ARM_ARCH_TIMER and ARM_ERRATA_754322 are left unselected. Thanks, Mark. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com CC: Arnd Bergmann a...@arndb.de --- arch/arm/configs/multi_v7_defconfig | 32 +++- 1 files changed, 15 insertions(+), 17 deletions(-) diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig index 2e67a27..8a5cd5c 100644 --- a/arch/arm/configs/multi_v7_defconfig +++ b/arch/arm/configs/multi_v7_defconfig @@ -1,23 +1,20 @@ -CONFIG_EXPERIMENTAL=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y CONFIG_ARCH_MVEBU=y CONFIG_MACH_ARMADA_370=y -CONFIG_ARCH_SIRF=y CONFIG_MACH_ARMADA_XP=y CONFIG_ARCH_HIGHBANK=y CONFIG_ARCH_SOCFPGA=y -CONFIG_ARCH_SUNXI=y -CONFIG_ARCH_WM8850=y -# CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA is not set -CONFIG_ARCH_ZYNQ=y -CONFIG_ARM_ERRATA_754322=y CONFIG_PLAT_SPEAR=y CONFIG_ARCH_SPEAR13XX=y CONFIG_MACH_SPEAR1310=y CONFIG_MACH_SPEAR1340=y +CONFIG_ARCH_STI=y +CONFIG_ARCH_SUNXI=y +CONFIG_ARCH_SIRF=y +CONFIG_ARCH_WM8850=y +CONFIG_ARCH_ZYNQ=y CONFIG_SMP=y -CONFIG_ARM_ARCH_TIMER=y CONFIG_AEABI=y CONFIG_HIGHMEM=y CONFIG_HIGHPTE=y @@ -25,27 +22,30 @@ CONFIG_ARM_APPENDED_DTB=y CONFIG_VFP=y CONFIG_NEON=y CONFIG_NET=y +CONFIG_DEVTMPFS=y CONFIG_BLK_DEV_SD=y CONFIG_ATA=y +CONFIG_SATA_AHCI_PLATFORM=y CONFIG_SATA_HIGHBANK=y CONFIG_SATA_MV=y -CONFIG_SATA_AHCI_PLATFORM=y CONFIG_NETDEVICES=y CONFIG_NET_CALXEDA_XGMAC=y CONFIG_SMSC911X=y CONFIG_STMMAC_ETH=y +CONFIG_KEYBOARD_SPEAR=y CONFIG_SERIO_AMBAKMI=y CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_SERIAL_8250_DW=y -CONFIG_KEYBOARD_SPEAR=y CONFIG_SERIAL_AMBA_PL011=y CONFIG_SERIAL_AMBA_PL011_CONSOLE=y -CONFIG_SERIAL_OF_PLATFORM=y CONFIG_SERIAL_SIRFSOC=y CONFIG_SERIAL_SIRFSOC_CONSOLE=y CONFIG_SERIAL_VT8500=y CONFIG_SERIAL_VT8500_CONSOLE=y +CONFIG_SERIAL_OF_PLATFORM=y +CONFIG_SERIAL_ST_ASC=y +CONFIG_SERIAL_ST_ASC_CONSOLE=y CONFIG_IPMI_HANDLER=y CONFIG_IPMI_SI=y CONFIG_I2C=y @@ -54,7 +54,6 @@ CONFIG_I2C_SIRF=y CONFIG_SPI=y CONFIG_SPI_PL022=y CONFIG_SPI_SIRF=y -CONFIG_GPIO_PL061=y CONFIG_FB=y CONFIG_FB_ARMCLCD=y CONFIG_FB_WM8505=y @@ -67,7 +66,6 @@ CONFIG_MMC_ARMMMCI=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_PLTFM=y CONFIG_MMC_SDHCI_SPEAR=y -CONFIG_MMC_WMT=y CONFIG_EDAC=y CONFIG_EDAC_MM_EDAC=y CONFIG_EDAC_HIGHBANK_MC=y @@ -75,9 +73,9 @@ CONFIG_EDAC_HIGHBANK_L2=y CONFIG_RTC_CLASS=y CONFIG_RTC_DRV_PL031=y CONFIG_RTC_DRV_VT8500=y -CONFIG_PWM=y -CONFIG_PWM_VT8500=y CONFIG_DMADEVICES=y -CONFIG_PL330_DMA=y -CONFIG_SIRF_DMA=y CONFIG_DW_DMAC=y +CONFIG_SIRF_DMA=y +CONFIG_PL330_DMA=y +CONFIG_PWM=y +CONFIG_PWM_VT8500=y -- 1.7.6.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 4/5] clk/exynos5250: add clock for tv sysmmu
Adding sysmmu clock for tv for exynos5250 SoC. It also
adds aclk200_disp1 mux which is the actual parent of the
disp1 block (contains hdmi, mixer, sysmmu_tv).
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
Documentation/devicetree/bindings/clock/exynos5250-clock.txt |1 +
drivers/clk/samsung/clk-exynos5250.c |6 +-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index f333d61..f1c7e7f 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -156,6 +156,7 @@ clock which they consume.
dp 342
mixer343
hdmi 344
+ smmu_tv 345
[Clock Muxes]
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index 88cdb13..bb93d61 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -24,6 +24,7 @@
#define SRC_CORE1 0x4204
#define SRC_TOP0 0x10210
#define SRC_TOP2 0x10218
+#define SRC_TOP3 0x1021C
#define SRC_GSCL 0x10220
#define SRC_DISP1_00x1022c
#define SRC_MAU0x10240
@@ -99,7 +100,7 @@ enum exynos5250_clks {
spi2, i2s1, i2s2, pcm1, pcm2, pwm, spdif, ac97, hsi2c0, hsi2c1, hsi2c2,
hsi2c3, chipid, sysreg, pmu, cmu_top, cmu_core, cmu_mem, tzpc0, tzpc1,
tzpc2, tzpc3, tzpc4, tzpc5, tzpc6, tzpc7, tzpc8, tzpc9, hdmi_cec, mct,
- wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi,
+ wdt, rtc, tmu, fimd1, mie1, dsim0, dp, mixer, hdmi, smmu_tv,
/* mux clocks */
mout_hdmi = 1024,
@@ -172,6 +173,7 @@ PNAME(mout_mpll_user_p) = { fin_pll, sclk_mpll };
PNAME(mout_bpll_user_p)= { fin_pll, sclk_bpll };
PNAME(mout_aclk166_p) = { sclk_cpll, sclk_mpll_user };
PNAME(mout_aclk200_p) = { sclk_mpll_user, sclk_bpll_user };
+PNAME(mout_aclk200_disp1_sub_p) = { fin_pll, aclk200 };
PNAME(mout_hdmi_p) = { div_hdmi_pixel, sclk_hdmiphy };
PNAME(mout_usb3_p) = { sclk_mpll_user, sclk_cpll };
PNAME(mout_group1_p) = { fin_pll, fin_pll, sclk_hdmi27m,
@@ -227,6 +229,7 @@ struct samsung_mux_clock exynos5250_mux_clks[] __initdata =
{
MUX(none, mout_aclk166, mout_aclk166_p, SRC_TOP0, 8, 1),
MUX(none, mout_aclk333, mout_aclk166_p, SRC_TOP0, 16, 1),
MUX(none, mout_aclk200, mout_aclk200_p, SRC_TOP0, 12, 1),
+ MUX(none, aclk200_disp1, mout_aclk200_disp1_sub_p, SRC_TOP3, 4, 1),
MUX(none, mout_cam_bayer, mout_group1_p, SRC_GSCL, 12, 4),
MUX(none, mout_cam0, mout_group1_p, SRC_GSCL, 16, 4),
MUX(none, mout_cam1, mout_group1_p, SRC_GSCL, 20, 4),
@@ -328,6 +331,7 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata
= {
GATE(smmu_gscl1, smmu_gscl1, aclk266, GATE_IP_GSCL, 8, 0, 0),
GATE(smmu_gscl2, smmu_gscl2, aclk266, GATE_IP_GSCL, 9, 0, 0),
GATE(smmu_gscl3, smmu_gscl3, aclk266, GATE_IP_GSCL, 10, 0, 0),
+ GATE(smmu_tv, smmu_tv, aclk200_disp1, GATE_IP_DISP1, 9, 0, 0),
GATE(mfc, mfc, aclk333, GATE_IP_MFC, 0, 0, 0),
GATE(smmu_mfcl, smmu_mfcl, aclk333, GATE_IP_MFC, 1, 0, 0),
GATE(smmu_mfcr, smmu_mfcr, aclk333, GATE_IP_MFC, 2, 0, 0),
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/5] clk/exynos5250: change parent to aclk200_disp1 for hdmi subsystem
parent of hdmi and mixer block is mentioned as aclk200 which is
not correct. It is clocked by the ouput of aclk200_disp1. Hence
parent for mixer and hdmi clocks is changed to aclk200_disp1.
Signed-off-by: Rahul Sharma rahul.sha...@samsung.com
---
drivers/clk/samsung/clk-exynos5250.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index bb93d61..2075f5f 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -468,8 +468,8 @@ struct samsung_gate_clock exynos5250_gate_clks[] __initdata
= {
GATE(mie1, mie1, aclk200, GATE_IP_DISP1, 1, 0, 0),
GATE(dsim0, dsim0, aclk200, GATE_IP_DISP1, 3, 0, 0),
GATE(dp, dp, aclk200, GATE_IP_DISP1, 4, 0, 0),
- GATE(mixer, mixer, aclk200, GATE_IP_DISP1, 5, 0, 0),
- GATE(hdmi, hdmi, aclk200, GATE_IP_DISP1, 6, 0, 0),
+ GATE(mixer, mixer, aclk200_disp1, GATE_IP_DISP1, 5, 0, 0),
+ GATE(hdmi, hdmi, aclk200_disp1, GATE_IP_DISP1, 6, 0, 0),
};
static __initdata struct of_device_id ext_clk_match[] = {
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] arm64: Add support to pass earlyprintk argument via device tree
Hi,
On 3 June 2013 21:21, Pranavkumar Sawargaonkar pranavku...@linaro.org wrote:
This patch adds support for defining and passing earlyprintk
related information i.e. device and address information via
device tree by adding it inside chosen node.
This will help user to just specify earlyprintk from bootargs
without actually knowing the address and device to enable
earlyprintk.
Mechanism:
One can just append earlyprintk=device-type,address (same as we pass
through command line) in /chosen node to notify kernel which is the
earlyprintk device and what is its address.
Backward Compatibility:
This patch also allows existing method of specifying earlyprintk
parameter via bootargs.
Existing method i.e. passing via bootargs will still have precedence
over device tree i.e. if one specifies earlyprintk=device-type,address
in bootargs then kernel will use information from bootargs instead of
device tree.
If user just specifies earlyprintk (without =...) then kernel will
look for device tree earlyprintk parameter.
Signed-off-by: Pranavkumar Sawargaonkar pranavku...@linaro.org
Signed-off-by: Anup Patel anup.pa...@linaro.org
---
arch/arm64/kernel/early_printk.c |7 +++
arch/arm64/kernel/setup.c| 21 -
2 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/early_printk.c
b/arch/arm64/kernel/early_printk.c
index fbb6e18..4e6f845 100644
--- a/arch/arm64/kernel/early_printk.c
+++ b/arch/arm64/kernel/early_printk.c
@@ -29,6 +29,8 @@
static void __iomem *early_base;
static void (*printch)(char ch);
+extern char *earlyprintk_dt_args;
+
/*
* PL011 single character TX.
*/
@@ -116,6 +118,11 @@ static int __init setup_early_printk(char *buf)
phys_addr_t paddr = 0;
if (!buf) {
+ /* Try to check if Device Tree has this argument or not ? */
+ buf = earlyprintk_dt_args;
+ }
+
+ if (!buf) {
pr_warning(No earlyprintk arguments passed.\n);
return 0;
}
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 6a9a532..fb2d56f 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -60,6 +60,8 @@ EXPORT_SYMBOL(processor_id);
unsigned int elf_hwcap __read_mostly;
EXPORT_SYMBOL_GPL(elf_hwcap);
+char *earlyprintk_dt_args;
+
static const char *cpu_name;
static const char *machine_name;
phys_addr_t __fdt_pointer __initdata;
@@ -122,6 +124,23 @@ static void __init setup_processor(void)
elf_hwcap = 0;
}
+int __init early_init_dt_scan_chosen_arm64(unsigned long node,
+ const char *uname,
+ int depth, void *data)
+{
+ char *prop;
+
+ /* Check if this is chosen node */
+ if (early_init_dt_scan_chosen(node, uname, depth, data) == 0)
+ return 0;
+
+ prop = of_get_flat_dt_prop(node, earlyprintk, NULL);
+ if (prop)
+ earlyprintk_dt_args = prop;
+
+ return 1;
+}
+
static void __init setup_machine_fdt(phys_addr_t dt_phys)
{
struct boot_param_header *devtree;
@@ -165,7 +184,7 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
pr_info(Machine: %s\n, machine_name);
/* Retrieve various information from the /chosen node */
- of_scan_flat_dt(early_init_dt_scan_chosen, boot_command_line);
+ of_scan_flat_dt(early_init_dt_scan_chosen_arm64, boot_command_line);
/* Initialize {size,address}-cells info */
of_scan_flat_dt(early_init_dt_scan_root, NULL);
/* Setup memory, calling early_init_dt_add_memory_arch */
--
1.7.9.5
Ccing to devicetree-discuss@lists.ozlabs.org for comments.
Original RFC posted for this patch is:
https://patchwork.kernel.org/patch/2601411/
Thanks,
Pranav
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/5] clk/exynos5250: Fix HDMI clock number in documentation
This patch is already posted at http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg18331.html and Reviewed-by: Doug Anderson diand...@chromium.org On Mon, Jun 10, 2013 at 4:30 PM, Rahul Sharma rahul.sha...@samsung.com wrote: From: Arun Kumar K arun...@samsung.com This patch corrects the HDMI clock number given wrongly in the documentation. Signed-off-by: Arun Kumar K arun...@samsung.com Signed-off-by: Rahul Sharma rahul.sha...@samsung.com --- Documentation/devicetree/bindings/clock/exynos5250-clock.txt |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt index 781a627..1a05761 100644 --- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt +++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt @@ -154,7 +154,7 @@ clock which they consume. dsim0341 dp 342 mixer343 - hdmi 345 + hdmi 344 Example 1: An example of a clock controller node is listed below. -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 09/11] ARM:stixxxx: Add stixxxx options to multi_v7_defconfig
Thanks for testing... On 10/06/13 11:40, Mark Rutland wrote: On Mon, Jun 10, 2013 at 10:27:57AM +0100, Srinivas KANDAGATLA wrote: This patch adds stih415 and stih416 support to multi_v7_defconfig. This seems to drop a few options also: CONFIG_ARM_ARCH_TIMER Same as last comment 2: CONFIG_ARM_ERRATA_754322 ARM_ERRATA_754322 gets selected by the mach level Kconfig of sti, so it disappears, Should the mach level Kconfig select that? CONFIG_EXPERIMENTAL CONFIG_GPIO_PL061 CONFIG_MMC_WMT Comment 2: Without any modifications to multi_v7_defconfig if I run savedefconfig CONFIG_ARM_ARCH_TIMER, CONFIG_EXPERIMENTAL, CONFIG_GPIO_PL061 and CONFIG_MMC_WMT disappears. Which suggests that these options seems to be selected by another kconfigs or mach level. And since then the multi_v7_defconfig was not run with savedefconfig. Thanks, srini I just applied this to v3.10-rc5, and ran `make ARCH=arm multi_v7_defconfig`. It seems MMC_WMT and GPIO_PL061 get selected elsewhere, but ARM_ARCH_TIMER and ARM_ERRATA_754322 are left unselected. Thanks, Mark. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: tegra: add basic SecureOS support
On Mon, Jun 10, 2013 at 05:11:15PM +0900, Alexandre Courbot wrote: On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren swar...@wwwdotorg.org wrote: I think we need to separate the concept of support for *a* secure monitor, from support for a *particular* secure monitor. Agreed. In this case, can we assume that support for a specific secure monitor is not arch-specific, and that this patch should be moved outside of arch-tegra and down to arch/arm? In other words, the ABI of a particular secure monitor should be the same no matter the chip, shouldn't it? I would like to believe that the Trusted Foundations monitor had the same ABI irrespective of which Soc it was running on. However, I have absolutely no idea at all if that's true. Even if there's some common subset of the ABI that is identical across all SoCs, I wouldn't be too surprised if there were custom extensions for each different SoC, or just perhaps even each product. Can you research this and find out the answer? Will do. Information about TF is scarce unfortunately. I don't have full information on this topic, but there is certainly no common standard ABI. Every example I've seen is different so far, though some will be less different than others. ARM are baking some proposabls for that, but that doesn't change the existing software, and it's impossible to predict how rapidly a new standards proposal would be adopted. So unfortunately, diversity is something we will have to cope with for the foreseeable future. What we can always do is make a compatible property that lists everything[1], and have the driver match on the most specific value for now, but relax the driver's matching later if it turns out that the ABI is indeed common. [1] That'd need to be at least secure OS name, and secure OS version. Perhaps the SoC and board data can be deduced from the DT's top-level compatible properties; nvidia,tegra114-shield, nvidia,tegra114? They can probably, but in theory nothing prevents a board from coming with different secure monitors (or none at all). In this case, just having the board name might not be enough. Having a proper node for the firmware like David and Tomasz suggested seems to be the best way to make sure we cover all cases - I think I will try to do it this way for the next version, and hopefully come with a binding that is useful for everyone. Since existing SMC based firmwares are not safely probeable, describing what's there using DT feels like the best bet for now. Cheers ---Dave ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: tegra: add basic SecureOS support
On Mon, Jun 10, 2013 at 05:05:04PM +0900, Alexandre Courbot wrote:
On Sat, Jun 8, 2013 at 3:13 AM, Dave Martin dave.mar...@arm.com wrote:
One way to make the backend generic would be to have something like
one of the following (some syntax omitted due to laziness):
u32 __naked __call_smc(u32 r0, ...)
{
asm volatile (
stmfd sp!, {r4-r11,lr}
smc #0
ldmfd sp!, {r4-r11,pc}
::: memory
);
}
/* The above works for up to 4 u32 arguments */
u32 __naked __call_smc(u32 r0, ...)
{
asm volatile (
mov ip, sp
stmfd sp!, {r4-r11,lr}
ldmia ip, {r4-r11}
smc #0
ldmfd sp!, {r4-r11,pc}
::: memory
);
}
/*
* Works for up to 13 u32 arguments, provided the stack is deep
* enough to provide suitable garbage data to fill the registers
* if the caller supplied fewer arguments (a bit of a hack)
*/
u32 __naked __call_smc(struct pt_regs *regs) {
asm(
stmfd sp!, {r4-r11,lr}
/* load regs from regs */
smc #0
/* save regs back to regs */
ldmfd sp!, {r4-r11,pc}
);
}
/*
* Most generic, least-efficient version.
* Can return up to 13 u32 results instead of just one.
* For convenience, the r0 value returned by the SMC could be
* left in r0 so that it also determines the return value of the
* function.
*
* Most of the time, SMC shouldn't be called on any hot path,
* otherwise the performance battle is already lost -- so it may
* not be crucial to reach the maximum possible efficiency for
* these calls.
*/
A particular firmware's Linux glue code might have to put extra stuff
around calls to generic_smc, but at least generic_smc itself wouldn't
need to be reinvented, and the firmware-specific glue code could usually
avoid asm.
Another example is the function that Tomasz shown
(https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/arch/arm/mach-exynos/exynos-smc.S?id=refs/tags/next-20130606
), which preserves r4-r11 but also assumes r3 is an argument - that's
again another slightly different convention.
... for which the above implementations of __call_smc() should work too.
All in all the needs of the various firmwares might end up being just
different enough that we need to have a different backend for each of
them. The firmware_ops defined in arch/arm/include/asm/firmware.h
perform the abstraction at a higher level, which seems more fit here
IMHO.
Alex.
Indeed. If you think you could work with one of the above generics, we
could try it and see what it looks like though.
If it's an awkward fit, I might be being too optimistic.
I agree that your versions would most likely work in our (and probably
many others) case. But I wonder if individual platforms will not
prefer to sacrifice the ease of use of a generic version for the
ability to write faster code that will just preserve what is needed
(whether that performance gain is justified or not is of course
subject to debate). I don't have enough hindsight to decide which
approach is the best, but until we have more examples of firmwares
that would justify such a factorization, I think I'd like to go with
our own version first - for there is already more than enough to fix
in this patch. :)
Sure, I'll have another think based on your repost.
Cheers
---Dave
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 09/11] gpio: davinci: DT changes for driver
On Thu, May 30, 2013 at 23:55:22, Linus Walleij wrote: On Wed, May 22, 2013 at 9:10 AM, Philip Avinash avinashphi...@ti.com wrote: (...) +- interrupts: The Starting IRQ number for GPIO +- intc_irq_num: The number of IRQs supported by the Interrupt Controller (...) No this is not how you pass a number of IRQs in the device tree. interrupts is an array. Pass every interrupt here for a full resolution of the IRQs. Correct. I will change. Further this looks fishy: + interrupts = 42; Usually you pass flags with the IRQs, I would rather have expected an array like this: interrupts = 90 0x4 96 0x4 14 0x4 15 0x4 79 0x4; 0x4 is IRQ_TYPE_LEVEL_HIGH, you can use the dts #include dt-bindings/interrupt-controller/irq.h and define that symbolically. Doesn't the DaVinci IRQ controller support *any* IRQ flags? I wasn't sure about it. But from davinci GPIO driver perspective, GPIO pins are configured as edge sensitive. So IRQ_TYPE_EDGE_BOTH can be used. So I will correct Documentation and update DT nodes in next version. Since the driver code is not reading out the interrupts but (I guess?) falling back to platform data IRQ assignment, this seems wrong. Driver code reads Starting IRQ number for GPIO from platform resource See [PATCH 03/11] gpio: davinci: Modify to platform driver. Driver requires only starting offset of gpio irq number. GPIO interrupt Number expected in sequential order for davinci GPIO. Thanks Avinash Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 01/11] serial:st-asc: Add ST ASC driver.
Thankyou for your comment and suggestion,
I will fix the POSIX compliant issue.
On 10/06/13 10:35, Russell King - ARM Linux wrote:
On Mon, Jun 10, 2013 at 10:21:00AM +0100, Srinivas KANDAGATLA wrote:
This patch adds support to ASC (asynchronous serial controller)
driver, which is basically a standard serial driver. This IP is common
across all the ST parts for settop box platforms.
ASC is embedded in ST COMMS IP block. It supports Rx Tx functionality.
It support all industry standard baud rates.
Your driver is not POSIX compliant.
+for (; count != 0; count--) {
+c = asc_in(port, ASC_RXBUF);
+flag = TTY_NORMAL;
+port-icount.rx++;
+
+if (unlikely(c ASC_RXBUF_FE)) {
+if (c == ASC_RXBUF_FE) {
+port-icount.brk++;
+if (uart_handle_break(port))
+continue;
+flag = TTY_BREAK;
+} else {
+port-icount.frame++;
+flag = TTY_FRAME;
+}
+} else if (ascport-check_parity
+ unlikely(c ASC_RXBUF_PE)) {
+port-icount.parity++;
+flag = TTY_PARITY;
+}
+
+if (uart_handle_sysrq_char(port, c))
+continue;
+tty_insert_flip_char(tport, c 0xff, flag);
+}
+if (overrun) {
+port-icount.overrun++;
+tty_insert_flip_char(tport, 0, TTY_OVERRUN);
+}
No support for ignoring error conditions. No support for ignoring all
input... and:
+static void asc_set_termios(struct uart_port *port, struct ktermios
*termios,
+struct ktermios *old)
+{
+struct asc_port *ascport = to_asc_port(port);
+unsigned int baud;
+u32 ctrl_val;
+tcflag_t cflag;
+unsigned long flags;
+
+port-uartclk = clk_get_rate(ascport-clk);
+
+baud = uart_get_baud_rate(port, termios, old, 0, port-uartclk/16);
+cflag = termios-c_cflag;
+
+spin_lock_irqsave(port-lock, flags);
+
+/* read control register */
+ctrl_val = asc_in(port, ASC_CTL);
+
+/* stop serial port and reset value */
+asc_out(port, ASC_CTL, (ctrl_val ~ASC_CTL_RUN));
+ctrl_val = ASC_CTL_RXENABLE | ASC_CTL_FIFOENABLE;
+
+/* reset fifo rx tx */
+asc_out(port, ASC_TXRESET, 1);
+asc_out(port, ASC_RXRESET, 1);
+
+/* set character length */
+if ((cflag CSIZE) == CS7) {
+ctrl_val |= ASC_CTL_MODE_7BIT_PAR;
+} else {
+ctrl_val |= (cflag PARENB) ? ASC_CTL_MODE_8BIT_PAR :
+ASC_CTL_MODE_8BIT;
+}
+
+ascport-check_parity = (cflag PARENB) ? 1 : 0;
+
+/* set stop bit */
+ctrl_val |= (cflag CSTOPB) ? ASC_CTL_STOP_2BIT : ASC_CTL_STOP_1BIT;
+
+/* odd parity */
+if (cflag PARODD)
+ctrl_val |= ASC_CTL_PARITYODD;
+
+/* hardware flow control */
+if ((cflag CRTSCTS) ascport-hw_flow_control)
+ctrl_val |= ASC_CTL_CTSENABLE;
This doesn't reflect those facts back into the termios structure to
indicate that they aren't supported.
Consider using uart_port's ignore and read status masks to implement
the break, framing, parity and overrun checking in your interrupt
handler using the same methodology as drivers like 8250, amba-pl011
etc. That will help you get these code sequences correct.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2] i2c: core: make it possible to match a pure device tree driver
On Fri, Jun 7, 2013 at 11:32 PM, Wolfram Sang w...@the-dreams.de wrote: ... I2C devices probed from device tree should subsequently be fixed to handle the case where of_match_table() is used (I think none of them do that today), and platforms should fix their device trees to use compatible strings for I2C devices instead of setting the name to Linux device driver names as is done in multiple cases today. I guess your solution is the least intrusive one. Still, it could happen that of_match_table is scanned three times (by driver core, i2c layer, and i2c driver) which is IMO an indication to look for a more elegant solution tp find out what really matched? I think that is a generic problem with the device tree being completely stateless, and rather a comment on the of_match_device() intrinsics being inelegant than on this patch? Do you see it as a blocker for the patch? What happens before this patch is that instead of looping over the of_match_table, the id_table is always iterated to the end also in the DT case, yielding NULL as the last argument to driver-probe() anyway. Maybe the OF people have some comments on this... I cannot really see how it could be any different given the way the FDT works :-/ Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] ARM: nomadik: add the new clocks to the device tree
On Mon, Jun 10, 2013 at 7:12 AM, Bjorn Andersson bj...@kryo.se wrote: While hacking on clock support for msm8960 the other day I did the same thing; I figured that providing clocks with descriptive names would be of great benefit while reading the dts. I had my uart device setup with: clocks = gsbi8_uart_clk, gsbi8_p_clk; However, all currently present clock bindings follow the pattern described by Arnd. Following this pattern my uart would be setup as: clocks = clks 42, clks 44; Needless to say there is no way to make sense of this without consulting the specific binding documentation. So, although your way of setting up the clock binding is not the standard way I do prefer it, but it comes with plenty extra nodes in the tree. I agree. In my case this was just a side-effect of the different bits in the register having different parents, so the common pattern could not be used, but when looking at the end result it's strikingly more readable than the cryptic numbers. However it is possible to mitigate the latter by using the new DTS preprocessor support like so: #include dt-bindings/clk/my-clocks.h: /* Clock IDs */ #define GSBI8_UART_CLK 42 #define GSBI8_P_CLK 44 (...) clocks = clks GSBI8_UART_CLK, clks GSBI8_P_CLK; Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
Hi Tony, (sorry, on Outlook web)
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
This change is not necessary if we make sure the pinctrl-single-omap driver
gets registered early enough, before the pinctrl devices are probed.
(e.g. subsys_initcall())
I've commented about this in the other patch.
cheers,
-roger
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
From: Tony Lindgren [t...@atomide.com]
Sent: Friday, June 07, 2013 11:50 PM
To: linus.wall...@linaro.org
Cc: devicetree-discuss@lists.ozlabs.org; Haojian Zhuang; Ujfalusi, Peter;
linux-o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Quadros, Roger
Subject: [PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use
pinctrl-single-omap
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3.dtsi |4 ++--
arch/arm/boot/dts/omap4.dtsi |4 ++--
arch/arm/boot/dts/omap5.dtsi |4 ++--
arch/arm/mach-omap2/mux.c|8 ++--
arch/arm/mach-omap2/pm34xx.c |2 ++
arch/arm/mach-omap2/prm_common.c | 26 ++
6 files changed, 40 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99ba6e1..847af56 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -94,7 +94,7 @@
};
omap3_pmx_core: pinmux@48002030 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002030 0x05cc;
#address-cells = 1;
#size-cells = 0;
@@ -103,7 +103,7 @@
};
omap3_pmx_wkup: pinmux@0x48002a00 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002a00 0x5c;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..2a4f099 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -107,7 +107,7 @@
};
omap4_pmx_core: pinmux@4a100040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a100040 0x0196;
#address-cells = 1;
#size-cells = 0;
@@ -115,7 +115,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap4_pmx_wkup: pinmux@4a31e040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a31e040 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3dd7ff8..5515d58 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -100,7 +100,7 @@
};
omap5_pmx_core: pinmux@4a002840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a002840 0x01b6;
#address-cells = 1;
#size-cells = 0;
@@ -108,7 +108,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap5_pmx_wkup: pinmux@4ae0c840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4ae0c840 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index f82cf87..48094b58 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -811,6 +811,12 @@ int __init omap_mux_late_init(void)
}
}
+ omap_mux_dbg_init();
+
+ /* see pinctrl-single-omap for the wake-up interrupt handling */
+ if (of_have_populated_dt())
+ return 0;
+
ret = request_irq(omap_prcm_event_to_irq(io),
omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
hwmod_io,
Re: [PATCH v2 06/11] ARM:stixxxx: Add STiH415 SOC support
On Mon, Jun 10, 2013 at 11:26 AM, Srinivas KANDAGATLA
srinivas.kandaga...@st.com wrote:
The STiH415 is the next generation of HD, AVC set-top box processors for
satellite, cable, terrestrial and IP-STB markets. It is an ARM Cortex-A9
1.0 GHz, dual-core CPU.
(...)
+ soc {
+ pin-controller-sbc {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = st,stih415-pinctrl, simple-bus;
Why is the pin controller be a simple bus?
Maybe obvious, I'm not 100% familiar with when we use this...
+ pin-controller-front {
(...)
+ pin-controller-rear {
(...)
+ pin-controller-left {
(...)
+ pin-controller-right {
Please explain these orientations in some comment in the device
tree, I'm half-guessing that it's about the edges around the chip so
the PIO* names are actually pad names.
I would suggest you use the names north/south/west/east
if this is the case since left and right etc are relative measures.
(This terminology is used on e.g. dance mats for console games...)
If these names are from the datasheets by all means keep them.
+++ b/arch/arm/boot/dts/sti-pincfg.h
@@ -0,0 +1,94 @@
+#ifndef _STI_PINCFG_H_
+#define _STI_PINCFG_H_
+
+/* Alternate functions */
+#define ALT1 1
+#define ALT2 2
+#define ALT3 3
+#define ALT4 4
+#define ALT5 5
+#define ALT6 6
+#define ALT7 7
Why is this part of the DT definitions? In the pinctrl world this
is an intrinsic detail on how groups and functions are associated,
not something that you hard-code into the device tree. The
device tree should state how to combine functions with groups
and those will be strings, not numerals.
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 02/11] clocksource:global_timer: Add ARM global timer support.
On Mon, Jun 10, 2013 at 11:21 AM, Srinivas KANDAGATLA
srinivas.kandaga...@st.com wrote:
From: Stuart Menefy stuart.men...@st.com
This is a simple driver for the global timer module found in the Cortex
A9-MP cores from revision r1p0 onwards. This should be able to perform
the functions of the system timer and the local timer in an SMP system.
The global timer has the following features:
The global timer is a 64-bit incrementing counter with an
auto-incrementing feature. It continues incrementing after sending
interrupts. The global timer is memory mapped in the private memory
region.
The global timer is accessible to all Cortex-A9 processors in the
cluster. Each Cortex-A9 processor has a private 64-bit comparator that
is used to assert a private interrupt when the global timer has reached
the comparator value. All the Cortex-A9 processors in a design use the
banked ID, ID27, for this interrupt. ID27 is sent to the Interrupt
Controller as a Private Peripheral Interrupt. The global timer is
clocked by PERIPHCLK.
Signed-off-by: Stuart Menefy stuart.men...@st.com
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
CC: Arnd Bergmann a...@arndb.de
CC: Rob Herring robherri...@gmail.com
CC: Linus Walleij linus.wall...@linaro.org
CC: Will Deacon will.dea...@arm.com
CC: Thomas Gleixner t...@linutronix.de
This is starting to look very good!
(...)
+static int __cpuinit gt_clockevents_init(struct clock_event_device *clk)
+{
+ struct clock_event_device **this_cpu_clk;
+ int cpu = smp_processor_id();
+
+ clk-name = ARM global timer clock event;
+ clk-features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
+ clk-set_mode = gt_clockevent_set_mode;
+ clk-set_next_event = gt_clockevent_set_next_event;
+ this_cpu_clk = __this_cpu_ptr(gt_evt);
+ *this_cpu_clk = clk;
+ clk-cpumask = cpumask_of(cpu);
+ clk-irq = gt_ppi;
+ clockevents_config_and_register(clk, gt_clk_rate,
+ 0, 0x);
What do you mean with being able to set event on
0?
This should most probably be:
clockevents_config_and_register(clk, gt_clk_rate,
1, 0x);
(...)
+static struct clk *gt_get_clock(void)
+{
+ struct clk *clk;
+ int err;
+
+ clk = clk_get_sys(gt, NULL);
+ if (IS_ERR(clk)) {
+ pr_err(global-timer: clock not found: %ld\n, PTR_ERR(clk));
+ return clk;
+ }
(...)
+ clk = of_clk_get(np, 0);
+ if (!IS_ERR(clk))
+ clk_register_clkdev(clk, NULL, gt);
Well that was clever.
Isn't it better to pass a struct device_node *np around and have that as
NULL in the non-DT boot path?
(Maybe somebody in the community asked you to do this, then I
will live with it.)
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 09/11] ARM:stixxxx: Add stixxxx options to multi_v7_defconfig
On Mon, Jun 10, 2013 at 11:58:38AM +0100, Srinivas KANDAGATLA wrote: Thanks for testing... On 10/06/13 11:40, Mark Rutland wrote: On Mon, Jun 10, 2013 at 10:27:57AM +0100, Srinivas KANDAGATLA wrote: This patch adds stih415 and stih416 support to multi_v7_defconfig. This seems to drop a few options also: CONFIG_ARM_ARCH_TIMER Same as last comment 2: CONFIG_ARM_ERRATA_754322 ARM_ERRATA_754322 gets selected by the mach level Kconfig of sti, so it disappears, Should the mach level Kconfig select that? I couldn't find the patch adding mach-sti's Kconfig, though I seem to be missing patch 6 of the series. As long as CONFIG_ARM_ERRATA_754322 appears in the resulting .config, it should be fine. CONFIG_EXPERIMENTAL CONFIG_GPIO_PL061 CONFIG_MMC_WMT Comment 2: Without any modifications to multi_v7_defconfig if I run savedefconfig CONFIG_ARM_ARCH_TIMER, CONFIG_EXPERIMENTAL, CONFIG_GPIO_PL061 and CONFIG_MMC_WMT disappears. Which suggests that these options seems to be selected by another kconfigs or mach level. And since then the multi_v7_defconfig was not run with savedefconfig. CONFIG_EXPERIMENTAL's gone as of 3d374d09f1: final removal of CONFIG_EXPERIMENTAL, so that's fine to go. CONFIG_GPIO_PL061 and CONFIG_MMC_WMT get selected elsewhere, so that's fine. It looks like the architected timer deselection is fallout of my own making, the multi_v7_defconfig should now contain HAVE_ARM_ARCH_TIMER rather than ARM_ARCH_TIMER. Thanks, Mark. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 04/11] mfd:stixxxx-syscfg: Add ST System Configuration support.
On Mon, Jun 10, 2013 at 11:22 AM, Srinivas KANDAGATLA srinivas.kandaga...@st.com wrote: This mfd driver provides higher level inialization routines for various IPs like Ethernet, USB, PCIE, SATA and so on. Also it provides way to get to syscfg registers via standard regmap api which is usefull for drivers like pinctrl. This patch adds support to ST System Configuration registers, which can be configured by the drivers. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com CC: Stuart Menefy stuart.men...@st.com CC: Stephen Gallimore stephen.gallim...@st.com CC: Linus Walleij linus.wall...@linaro.org CC: Mark Brown broo...@kernel.org What is this driver doing that drivers/mfd/syscon.c is not already doing? I just get the feeling that you're reinventing the wheel here. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 02/11] clocksource:global_timer: Add ARM global timer support.
On 10/06/13 14:13, Linus Walleij wrote:
On Mon, Jun 10, 2013 at 11:21 AM, Srinivas KANDAGATLA
srinivas.kandaga...@st.com wrote:
Signed-off-by: Stuart Menefy stuart.men...@st.com
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com
CC: Arnd Bergmann a...@arndb.de
CC: Rob Herring robherri...@gmail.com
CC: Linus Walleij linus.wall...@linaro.org
CC: Will Deacon will.dea...@arm.com
CC: Thomas Gleixner t...@linutronix.de
This is starting to look very good!
(...)
Thankyou.
+static int __cpuinit gt_clockevents_init(struct clock_event_device *clk)
+{
+ struct clock_event_device **this_cpu_clk;
+ int cpu = smp_processor_id();
+
+ clk-name = ARM global timer clock event;
+ clk-features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT;
+ clk-set_mode = gt_clockevent_set_mode;
+ clk-set_next_event = gt_clockevent_set_next_event;
+ this_cpu_clk = __this_cpu_ptr(gt_evt);
+ *this_cpu_clk = clk;
+ clk-cpumask = cpumask_of(cpu);
+ clk-irq = gt_ppi;
+ clockevents_config_and_register(clk, gt_clk_rate,
+ 0, 0x);
What do you mean with being able to set event on
0?
Its a bit of over do from me.. I will change it to what you suggested...
This should most probably be:
clockevents_config_and_register(clk, gt_clk_rate,
1, 0x);
(...)
+static struct clk *gt_get_clock(void)
+{
+ struct clk *clk;
+ int err;
+
+ clk = clk_get_sys(gt, NULL);
+ if (IS_ERR(clk)) {
+ pr_err(global-timer: clock not found: %ld\n, PTR_ERR(clk));
+ return clk;
+ }
(...)
+ clk = of_clk_get(np, 0);
+ if (!IS_ERR(clk))
+ clk_register_clkdev(clk, NULL, gt);
Well that was clever.
Isn't it better to pass a struct device_node *np around and have that as
NULL in the non-DT boot path?
I will try it and see how it will look.
Thanks,
srini
(Maybe somebody in the community asked you to do this, then I
will live with it.)
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 07/11] ARM:stixxxx: Add STiH416 SOC support
On Monday 10 June 2013 10:27:05 Srinivas KANDAGATLA wrote:
+ soc {
+ pin-controller-sbc {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = st,stih416-pinctrl, simple-bus;
Why is this both its own device with a compatible string and a
simple-bus at the same time? Wouldn't it be simpler to just
scan the child device nodes from the st,stih416-pinctrl
driver instead of having a separate platform_driver for them?
+ st,retime-in-delay = 0 300 500 750 1000 1250 1500
1750 2000 2250 2500 2750 3000 3250;
+ st,retime-out-delay = 0 300 500 750 1000 1250 1500
1750 2000 2250 2500 2750 3000 3250;
+ st,syscfg = syscfg_sbc;
+ st,syscfg-offsets = 0 40 50 60 100;
+ ranges;
+ PIO0: pinctrl@fe61 {
+ #gpio-cells = 1;
+ compatible = st,sti-gpio;
+ gpio-controller;
+ reg = 0xfe61 0x100;
+ st,bank-name = PIO0;
+ st,retime-pin-mask = 0xff;
+ };
+ PIO1: pinctrl@fe611000 {
+ #gpio-cells = 1;
+ compatible = st,sti-gpio;
+ gpio-controller;
+ reg = 0xfe611000 0x100;
+ st,bank-name = PIO1;
+ st,retime-pin-mask = 0xff;
+ };
What is in the ranges between these registers? It seems you have
256 bytes for each pinctrl node, with 4kb spacing. I wonder if
it would make sense to declare the entire range to belong to a single
pinctrl device. At least since all of the registers are in a single
range, you could add a property like
ranges = 0 0xfe61 0x1;
and use relative addresses in the sub-nodes.
Please don't use identifiers with 'xxx' in them. Instead use numbers
of actual chips, ideally using the first one that this is compatible
with.
+ syscfg_sbc:syscfg@fe60{
+ compatible = st,stih416-syscfg;
+ reg = 0xfe60 0x1000;
+ syscfg-range= 0 999;
+ syscfg-name = SYSCFG_SBC;
+ };
+ syscfg_front:syscfg@fee1{
+ compatible = st,stih416-syscfg;
+ reg = 0xfee1 0x1000;
+ syscfg-range= 1000 999;
+ syscfg-name = SYSCFG_FRONT;
+ };
Did you mean to declare ranges excluding 1000 and 2000 here?
Normally I would expect inclusive ranges like syscfg-range=0 1000;
What is the idea of the 'syscfg-name'? If the nodes are all different,
I would expect them to have distinct compatible values and not
need them.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 04/11] mfd:stixxxx-syscfg: Add ST System Configuration support.
On 10/06/13 14:16, Linus Walleij wrote: On Mon, Jun 10, 2013 at 11:22 AM, Srinivas KANDAGATLA srinivas.kandaga...@st.com wrote: This mfd driver provides higher level inialization routines for various IPs like Ethernet, USB, PCIE, SATA and so on. Also it provides way to get to syscfg registers via standard regmap api which is usefull for drivers like pinctrl. This patch adds support to ST System Configuration registers, which can be configured by the drivers. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com CC: Stuart Menefy stuart.men...@st.com CC: Stephen Gallimore stephen.gallim...@st.com CC: Linus Walleij linus.wall...@linaro.org CC: Mark Brown broo...@kernel.org What is this driver doing that drivers/mfd/syscon.c is not already doing? As of now, the driver is very much similar to syscon + some additional functionality, but we are planning to use this file to add higher level functions to configure different IPs like ethernet, usb, power, reset and so on which are very much specific to ST System Configuration Registers. Thanks, srini I just get the feeling that you're reinventing the wheel here. Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 04/11] mfd:stixxxx-syscfg: Add ST System Configuration support.
On Monday 10 June 2013 14:52:38 Srinivas KANDAGATLA wrote: On 10/06/13 14:16, Linus Walleij wrote: On Mon, Jun 10, 2013 at 11:22 AM, Srinivas KANDAGATLA srinivas.kandaga...@st.com wrote: This mfd driver provides higher level inialization routines for various IPs like Ethernet, USB, PCIE, SATA and so on. Also it provides way to get to syscfg registers via standard regmap api which is usefull for drivers like pinctrl. This patch adds support to ST System Configuration registers, which can be configured by the drivers. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com CC: Stuart Menefy stuart.men...@st.com CC: Stephen Gallimore stephen.gallim...@st.com CC: Linus Walleij linus.wall...@linaro.org CC: Mark Brown broo...@kernel.org What is this driver doing that drivers/mfd/syscon.c is not already doing? As of now, the driver is very much similar to syscon + some additional functionality, but we are planning to use this file to add higher level functions to configure different IPs like ethernet, usb, power, reset and so on which are very much specific to ST System Configuration Registers. I was expecting that you'd actually interface with the syscon code and build on top, rather than copy it. There are multiple ways of doing that, e.g. you could export a function from syscon.c that you call to register the device node and then import the regmap from syscon into your high-level driver again. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 3/4] pinctrl: single: omap: Add SoC specific module for wake-up events
* Quadros, Roger rog...@ti.com [130610 03:09]:
+
+static int __init pcs_omap_init(void)
+{
+ platform_driver_register(pcs_omap_soc_driver);
+ platform_driver_register(pcs_omap_driver);
+
+ return 0;
+}
+module_init(pcs_omap_init);
It seems this has to be moved to an earlier place (e.g. subsys_initcall)
else the pinctrl core fails to find the pinctrl device at the device creation
time and bails out with -EPROBE_DEFER. Also, that device is never
created again, so -EPROBE_DEFER doesn't seem to work there.
Ah here, found your other comment :)
That's not needed, the real fix is to make twl-core.c and friends to
be regular module_init. There are already patches queued for that.
Regards,
Tony
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 6/6] ARM: dts: Add pcie controller node for Samsung EXYNOS5440 SoC
On Monday 10 June 2013, Jingoo Han wrote:
On Saturday, June 08, 2013 2:43 AM, Arnd Bergmann wrote:
For multiple domains, how can I fix the DT properties?
Domains are a Linux concept, you have to pick a new domain number for each
struct hw_pci you register.
Current DT properties are as below:
+ pcie0@4000 {
+ compatible = samsung,exynos5440-pcie;
+ reg = 0x4000 0x4000
+ 0x29 0x1000
+ 0x27 0x1000
+ 0x271000 0x40;
+ interrupts = 0 20 0, 0 21 0, 0 22 0;
+ #address-cells = 3;
+ #size-cells = 2;
+ device_type = pci;
+ ranges = 0x0800 0 0x4000 0x4000 0 0x0020 /*
configuration space */
+ 0x8100 0 0 0x4020 0 0x4000 /*
downstream I/O */
+ 0x8200 0 0 0x40204000 0 0x1000; /*
non-prefetchable memory */
+ };
An unrelated comment: your first reg field seems to overlap with part
of your configuration space. Is that intentional?
Also, shouldn't your memory space end on a 256MB boundary, rather than
extend up to 0x50203fff?
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/4] ARM: OMAP: Move DT wake-up event handling over to use pinctrl-single-omap
* Tony Lindgren t...@atomide.com [130607 13:58]:
* Tony Lindgren t...@atomide.com [130607 13:56]:
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
This patch I should queue separately, the rest should go via
the pinctrl tree.
Here's this one updated to add stubs for the SoC specific
reconfigure_io_chain functions when the SoC is not selected.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Fri, 7 Jun 2013 11:39:58 -0700
Subject: [PATCH] ARM: OMAP: Move DT wake-up event handling over to use
pinctrl-single-omap
Now pinctrl-single-omap can handle the wake-up events for us now
as long as the events are configured in the .dts files.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 99ba6e1..847af56 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -94,7 +94,7 @@
};
omap3_pmx_core: pinmux@48002030 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002030 0x05cc;
#address-cells = 1;
#size-cells = 0;
@@ -103,7 +103,7 @@
};
omap3_pmx_wkup: pinmux@0x48002a00 {
- compatible = ti,omap3-padconf, pinctrl-single;
+ compatible = ti,omap3-padconf;
reg = 0x48002a00 0x5c;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 2a56428..2a4f099 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -107,7 +107,7 @@
};
omap4_pmx_core: pinmux@4a100040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a100040 0x0196;
#address-cells = 1;
#size-cells = 0;
@@ -115,7 +115,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap4_pmx_wkup: pinmux@4a31e040 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a31e040 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 3dd7ff8..5515d58 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -100,7 +100,7 @@
};
omap5_pmx_core: pinmux@4a002840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4a002840 0x01b6;
#address-cells = 1;
#size-cells = 0;
@@ -108,7 +108,7 @@
pinctrl-single,function-mask = 0x7fff;
};
omap5_pmx_wkup: pinmux@4ae0c840 {
- compatible = ti,omap4-padconf, pinctrl-single;
+ compatible = ti,omap4-padconf;
reg = 0x4ae0c840 0x0038;
#address-cells = 1;
#size-cells = 0;
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index f82cf87..48094b58 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -811,6 +811,12 @@ int __init omap_mux_late_init(void)
}
}
+ omap_mux_dbg_init();
+
+ /* see pinctrl-single-omap for the wake-up interrupt handling */
+ if (of_have_populated_dt())
+ return 0;
+
ret = request_irq(omap_prcm_event_to_irq(io),
omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND,
hwmod_io, omap_mux_late_init);
@@ -818,8 +824,6 @@ int __init omap_mux_late_init(void)
if (ret)
pr_warning(mux: Failed to setup hwmod io irq %d\n, ret);
- omap_mux_dbg_init();
-
return 0;
}
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index c018593..9b19b14 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -172,6 +172,8 @@ static int prcm_clear_mod_irqs(s16 module, u8 regs, u32
ignore_bits)
wkst = omap2_prm_read_mod_reg(module, wkst_off);
wkst = ~ignore_bits;
c++;
+ if (c 10)
Re: [PATCH 2/4] pinctrl: single: Add hardware specific hooks for IRQ and GPIO wake-up events
* Haojian Zhuang haojian.zhu...@gmail.com [130608 21:51]:
I assume that this patch is used in both v1 v2 version. Since Manjunathappa
changed the logic of distinguishing bits and pins in blew.
if (pcs-bits_per_mux)
mask = vals-mask;
else
mask = pcs-fmask
Would you like to sync with his style?
Thanks for catching that, yes that's how it should be now. Updated
patch below.
Regards,
Tony
From: Tony Lindgren t...@atomide.com
Date: Sat, 8 Jun 2013 08:40:35 -0700
Subject: [PATCH] pinctrl: single: Add hardware specific hooks for IRQ and GPIO
wake-up events
At least on omaps, each board typically has at least one device
configured as wake-up capable from deeper idle modes. In the
deeper idle modes the normal interrupt wake-up path won't work
as the logic is powered off and separate wake-up hardware is
available either via IO ring or GPIO hardware. The wake-up
event can be device specific, or may need to be dynamically
remuxed to GPIO input for wake-up events. When the wake-up
event happens, it's IRQ need to be called so the device won't
lose interrupts.
Allow supporting IRQ and GPIO wake-up events if a hardware
spefific module is registered for the enable and disable
calls.
Done in collaboration with Roger Quadros rog...@ti.com.
Cc: Haojian Zhuang haojian.zhu...@gmail.com
Cc: Peter Ujfalusi peter.ujfal...@ti.com
Cc: devicetree-discuss@lists.ozlabs.org
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Tony Lindgren t...@atomide.com
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5a02e30..b95fa6c 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -69,6 +69,10 @@ Optional properties:
The number of parameters is depend on #pinctrl-single,gpio-range-cells
property.
+- interrrupts : the interrupt that a function may have for a wake-up event
+
+- gpios: the gpio that a function may have for a wake-up event
+
/* pin base, nr pins gpio function */
pinctrl-single,gpio-range = range 0 3 0 range 3 9 1;
@@ -205,6 +209,7 @@ pmx_gpio: pinmux@d401e000 {
0xdc 0x118
0xde 0
;
+ interrupts = 74;
};
};
diff --git a/drivers/pinctrl/pinctrl-single.c b/drivers/pinctrl/pinctrl-single.c
index e3b1f76..72efc8e 100644
--- a/drivers/pinctrl/pinctrl-single.c
+++ b/drivers/pinctrl/pinctrl-single.c
@@ -19,6 +19,8 @@
#include linux/of.h
#include linux/of_device.h
#include linux/of_address.h
+#include linux/of_gpio.h
+#include linux/of_irq.h
#include linux/pinctrl/pinctrl.h
#include linux/pinctrl/pinmux.h
@@ -95,6 +97,8 @@ struct pcs_conf_type {
* @nvals: number of entries in vals array
* @pgnames: array of pingroup names the function uses
* @npgnames: number of pingroup names the function uses
+ * @irq: optional irq associated with the function
+ * @gpio: optional gpio associated with the function
* @node: list node
*/
struct pcs_function {
@@ -105,6 +109,8 @@ struct pcs_function {
int npgnames;
struct pcs_conf_vals *conf;
int nconfs;
+ int irq;
+ int gpio;
struct list_head node;
};
@@ -411,6 +417,18 @@ static int pcs_get_function(struct pinctrl_dev *pctldev,
unsigned pin,
return 0;
}
+static void pcs_reg_init(struct pcs_reg *p, struct pcs_device *pcs,
+struct pcs_function *func,
+void __iomem *reg, unsigned val)
+{
+ p-read = pcs-read;
+ p-write = pcs-write;
+ p-irq = func-irq;
+ p-gpio = func-gpio;
+ p-reg = reg;
+ p-val = val;
+}
+
static int pcs_enable(struct pinctrl_dev *pctldev, unsigned fselector,
unsigned group)
{
@@ -444,6 +462,12 @@ static int pcs_enable(struct pinctrl_dev *pctldev,
unsigned fselector,
val = ~mask;
val |= (vals-val mask);
pcs-write(val, vals-reg);
+ if ((func-irq || func-gpio) pcs-soc pcs-soc-enable) {
+ struct pcs_reg pcsr;
+
+ pcs_reg_init(pcsr, pcs, func, vals-reg, val);
+ pcs-soc-enable(pcs-soc, pcsr);
+ }
}
return 0;
@@ -468,18 +492,6 @@ static void pcs_disable(struct pinctrl_dev *pctldev,
unsigned fselector,
return;
}
- /*
-* Ignore disable if function-off is not specified. Some hardware
-* does not have clearly defined disable function. For pin specific
-* off modes, you can use alternate named states as described in
-* pinctrl-bindings.txt.
-*/
- if (pcs-foff == PCS_OFF_DISABLED) {
- dev_dbg(pcs-dev, ignoring disable for %s function%i\n,
- func-name, fselector);
- return;
-
Re: [net-next PATCH v4 1/5] net: cpsw: enhance pinctrl support
On Fri, Jun 7, 2013 at 4:49 PM, Mugunthan V N mugunthan...@ti.com wrote: If you want to merge the direct networking parts of this series into another tree, I'm fine with that: Acked-by: David S. Miller da...@davemloft.net David Can you the below patch series as i have adopted pinctrl PM api in another series, this patch has direct usage of pinctrl_select_state apis http://marc.info/?l=linux-netdevm=137054250018667w=2 Linus Walleij Please drop this patch series and take my other [atch set mentioned above with David's Ack. Sure I didn't see David ACK the new versions explicitly but since they're even less intrusive I'll apply them assuming his ACK on these versions too... Yours, Linus Walleij ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 04/11] mfd:stixxxx-syscfg: Add ST System Configuration support.
Thanks for the comments. On 10/06/13 15:02, Arnd Bergmann wrote: On Monday 10 June 2013 14:52:38 Srinivas KANDAGATLA wrote: On 10/06/13 14:16, Linus Walleij wrote: On Mon, Jun 10, 2013 at 11:22 AM, Srinivas KANDAGATLA srinivas.kandaga...@st.com wrote: This mfd driver provides higher level inialization routines for various IPs like Ethernet, USB, PCIE, SATA and so on. Also it provides way to get to syscfg registers via standard regmap api which is usefull for drivers like pinctrl. This patch adds support to ST System Configuration registers, which can be configured by the drivers. Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@st.com CC: Stuart Menefy stuart.men...@st.com CC: Stephen Gallimore stephen.gallim...@st.com CC: Linus Walleij linus.wall...@linaro.org CC: Mark Brown broo...@kernel.org What is this driver doing that drivers/mfd/syscon.c is not already doing? As of now, the driver is very much similar to syscon + some additional functionality, but we are planning to use this file to add higher level functions to configure different IPs like ethernet, usb, power, reset and so on which are very much specific to ST System Configuration Registers. I was expecting that you'd actually interface with the syscon code and build on top, rather than copy it. I did not like the copying either, on the other hand I don't want to pollute the syscon code. As you said, I will make use of existing syscon and build System configuration interface on top of it and see how it look like. It will definitely get rid of lot of code duplication. Thanks, srini There are multiple ways of doing that, e.g. you could export a function from syscon.c that you call to register the device node and then import the regmap from syscon into your high-level driver again. Arnd ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
+Paul. On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown broo...@kernel.org wrote: On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: So, the biggest problem here has been patch 4 (having to have a hack to deploy this stuff is a bit worrying) plus the general not having a real driver thing. Patch #4 in this series was a hack as it was not properly split up and organized as a proper DTS series -it was meant as a proof of concept - not entirely meant to indicate the remaining 1-3 patches were hacks :). +- ti,i2c-slave-address - I2C slave address of the PMIC +- ti,i2c-voltage-register - I2C register address where voltage commands are + to be set. +- ti,i2c-command-register - I2C register address where commands are to be set + when OMAP enters low power state. This may be the same as + ti,i2c-voltage-register depending on the PMIC. +- ti,slew-rate-microvolt - worst case slew rate of rise / fall for voltage + transition in microvolts per microseconds (uV/uS) +- step-size-micro-volts - Step size in micovolts as to what one step in voltage + selector increment translates to. See example. +- regulator-min-microvolt - Minimum voltage in microvolts which is supported by + the PMIC in ti,step-size-microvolt increments. See example. +- regulator-max-microvolt - Maximum voltage in microvolts which is supported + by the PMIC in ti,step-size-microvolt increments. See example. The other thing is this whole business of encoding the properties of the PMIC in the DT like this. Paul Walmsley has started doing some work for some similiar hardware where instead of doing this the regulator is in the DT as normal and then the driver for the offloaded voltage scaling gets the information about the register layout from the regulator driver. This is a bit neater overall and would cope with determining which method to use at runtime. I think you mean http://marc.info/?t=13705924913r=1w=2 series. I will dig into it. if it is possible for Tegra and OMAP to use the same framework and strategy to deal with these kind of h/w blocks, all the more better. Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 07/11] ARM:stixxxx: Add STiH416 SOC support
Thankyou for your comments.
On 10/06/13 14:52, Arnd Bergmann wrote:
On Monday 10 June 2013 10:27:05 Srinivas KANDAGATLA wrote:
+soc {
+pin-controller-sbc {
+#address-cells = 1;
+#size-cells = 1;
+compatible = st,stih416-pinctrl, simple-bus;
Why is this both its own device with a compatible string and a
simple-bus at the same time? Wouldn't it be simpler to just
scan the child device nodes from the st,stih416-pinctrl
driver instead of having a separate platform_driver for them?
Am happy to get rid of gpio platform_driver, But looking at the existing
pinctrl drivers like at91, they do it exactly like this.
Also having a gpio platform driver ties the resources to driver in a
neat way.
+st,retime-in-delay = 0 300 500 750 1000 1250 1500
1750 2000 2250 2500 2750 3000 3250;
+st,retime-out-delay = 0 300 500 750 1000 1250 1500
1750 2000 2250 2500 2750 3000 3250;
+st,syscfg = syscfg_sbc;
+st,syscfg-offsets = 0 40 50 60 100;
+ranges;
+PIO0: pinctrl@fe61 {
+#gpio-cells = 1;
+compatible = st,sti-gpio;
+gpio-controller;
+reg = 0xfe61 0x100;
+st,bank-name = PIO0;
+st,retime-pin-mask = 0xff;
+};
+PIO1: pinctrl@fe611000 {
+#gpio-cells = 1;
+compatible = st,sti-gpio;
+gpio-controller;
+reg = 0xfe611000 0x100;
+st,bank-name = PIO1;
+st,retime-pin-mask = 0xff;
+};
What is in the ranges between these registers? It seems you have
256 bytes for each pinctrl node, with 4kb spacing. I wonder if
it would make sense to declare the entire range to belong to a single
pinctrl device. At least since all of the registers are in a single
range, you could add a property like
ranges = 0 0xfe61 0x1;
and use relative addresses in the sub-nodes.
OK, I will change to use ranges.
Please don't use identifiers with 'xxx' in them. Instead use numbers
of actual chips, ideally using the first one that this is compatible
with.
Ok, I will change st,sti-gpio to st,stih415-gpio.
+syscfg_sbc:syscfg@fe60{
+compatible = st,stih416-syscfg;
+reg = 0xfe60 0x1000;
+syscfg-range= 0 999;
+syscfg-name = SYSCFG_SBC;
+};
+syscfg_front:syscfg@fee1{
+compatible = st,stih416-syscfg;
+reg = 0xfee1 0x1000;
+syscfg-range= 1000 999;
+syscfg-name = SYSCFG_FRONT;
+};
Did you mean to declare ranges excluding 1000 and 2000 here?
Normally I would expect inclusive ranges like syscfg-range=0 1000;
These numbers are from data sheet so I used it as it is.
What is the idea of the 'syscfg-name'? If the nodes are all different,
The idea of having syscfg-name is to lookup any sysconf bank(regmap)
from code which do not have reference to phandle from device trees.
I would expect them to have distinct compatible values and not
need them.
Yes, If we have distinct compatible we would not need them, but there
will be 5-10 compatibility list for each SOC.
It looks like its going to be much neater Am going to try this change
and see how it looks like.
Arnd
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/10/2013 03:29 AM, Benoit Cousson wrote:
Hi Keerthy,
On 06/10/2013 06:03 AM, J, KEERTHY wrote:
Hi Stephen,
Thanks for the review comments.
From: Stephen Warren [swar...@wwwdotorg.org]
Sent: Saturday, June 08, 2013 1:26 AM
To: J, KEERTHY
Cc: Cousson, Benoit; devicetree-discuss@lists.ozlabs.org;
linux-o...@vger.kernel.org; linux-ker...@vger.kernel.org;
ldewan...@nvidia.com; grant.lik...@secretlab.ca; swar...@nvidia.com;
sa...@linux.intel.com; g...@slimlogic.co.uk; lee.jo...@linaro.org
Subject: Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/07/2013 05:28 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes. This is
based on the patch series:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg89957.html
The device tree nodes are based on:
https://lkml.org/lkml/2013/6/6/25
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
+palmas {
Hmmm. That (i.e. requiring the board file to declare the node, then
setting up all the content by later including this file) is an
interesting approach. I guess it's reasonable. The one issue is that it
makes it a little harder for the board file to override any of the
properties in this file., although it certainly is possible by including
those overrides after the include.
Irrespective of that, some comments on this:
+ palmas_pmic {
+ ti,ldo6-vibrator;
For example, what if the board doesn't want to have the property set?
+
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ regulator-min-microvolt = 60;
+ regulator-max-microvolt = 150;
Or what if the board wants to limit the voltage range of this regulator
due to what it's used for on the board.
+ regulator-always-on;
+ regulator-boot-on;
And those two properties are almost certainly board-specific policy.
Totally agree to all the above concerns. So can we have a custom .dtsi file
for a board+pmic combination? Or have only the required properties over
ridden
in the board file?
Yes, you can do that potentially if most OMAP5 boards will reuse the
same kind of settings. Kevin has just done that for OMAP3 + twl4030.
In this case, since we do have only one board, I'm not sure it worth the
effort.
IIUC, various Tegra boards use this PMIC, so there's more than one board
in question here.
Or were you talking about e.g.:
palmas.dtsi - base Palmas DT node for everything
omap-palmas.dtsi - common Palmas settings for all OMAP boards
... where the latter file would only be used by one board? If so, then
yes, creating the latter file might not make sense yet.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: dts: add dtsi for palmas
On 06/09/2013 10:03 PM, J, KEERTHY wrote: Hi Stephen, Thanks for the review comments. Cam you please fix your email client to quote the messages you're replyiing to correctly? In the message you sent, there's no differentiation between what I originally wrote and you quoted, vs. the new text you wrote as a response. That makes the message very confusing to read... ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 2/6] clocksource: add Marvell Orion SoC timer
On 06/10/13 18:04, Daniel Lezcano wrote: On 06/10/2013 11:35 AM, Sebastian Hesselbarth wrote: This patch add a DT enabled driver for timers found on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, and Discovery Innovation). It installs a free- running clocksource on timer0 and a clockevent source on timer1. Corresponding device tree documentation is also added. Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com It looks good for me. Sebastian, shall I take it through my tree (it will go to Thomas's tree) ? Daniel, I checked MAINTAINERS and thought clocksource, i.e. patch 2/6, would go through Thomas' or John's tree? If you want to take it, I am fine with it but guess I am not the one to choose here ;) Sebastian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/2] ARM: dts: add dtsi for palmas
On 06/10/2013 03:04 AM, J Keerthy wrote:
Adds palmas mfd and palmas regulator nodes.
Nits:
Well, you're really adding files that provide the nodes, not the nodes
themselves.
Palmas and MFD should be correctly capitalized.
diff --git a/arch/arm/boot/dts/palmas.dtsi b/arch/arm/boot/dts/palmas.dtsi
+palmas {
...
+ palmas_pmic {
...
+ ti,ldo6-vibrator;
Isn't that board-specific? I don't know the HW well enough to say, but I
assume that since there's a property, the whole point must be that some
boards want it set and some don't.
+ regulators {
+ smps123_reg: smps123 {
+ regulator-name = smps123;
+ };
So the node labels here duplicate those in omap5-uevm.dts in patch 2/2.
While dtc allows this, I don't think there's much point duplicating the
labels. I'd tend to only put the labels in omap5-uevm.dts and not put
them here. That will completely avoid the possibility of the labels in
this file from conflicting with any other labels in any top-level
board.dts file.
I also wonder if this file is actually terribly useful. The only thing
that this file provides is the regulator-name property. It seems simpler
just to put that into each board.dts file. The added advantage of doing
that, is that if a board doesn't use a particular regulator, the node
won't appear, and the regulator won't get registered.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] ARM: tegra: add basic SecureOS support
On 06/10/2013 03:14 AM, Russell King - ARM Linux wrote: On Mon, Jun 10, 2013 at 05:11:15PM +0900, Alexandre Courbot wrote: On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren swar...@wwwdotorg.org wrote: I think we need to separate the concept of support for *a* secure monitor, from support for a *particular* secure monitor. Agreed. In this case, can we assume that support for a specific secure monitor is not arch-specific, and that this patch should be moved outside of arch-tegra and down to arch/arm? In other words, the ABI of a particular secure monitor should be the same no matter the chip, shouldn't it? I would like to believe that the Trusted Foundations monitor had the same ABI irrespective of which Soc it was running on. However, I have absolutely no idea at all if that's true. Even if there's some common subset of the ABI that is identical across all SoCs, I wouldn't be too surprised if there were custom extensions for each different SoC, or just perhaps even each product. Can you research this and find out the answer? Will do. Information about TF is scarce unfortunately. The answer is... there isn't a common ABI. That is something I pressed ARM Ltd for when this stuff first appeared and they were adamant that they were not going to specify any kind of ABI for this interface. Right, there certainly isn't a common ABI across all secure monitors, but in this case I was wondering something more specific: whether for this specific implementation/provider of a secure monitor, if they had a consistent ABI across all SoCs (or even boards) that they implemented it on. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 06/11] ARM:stixxxx: Add STiH415 SOC support
On 10/06/13 13:43, Linus Walleij wrote:
On Mon, Jun 10, 2013 at 11:26 AM, Srinivas KANDAGATLA
srinivas.kandaga...@st.com wrote:
The STiH415 is the next generation of HD, AVC set-top box processors for
satellite, cable, terrestrial and IP-STB markets. It is an ARM Cortex-A9
1.0 GHz, dual-core CPU.
(...)
+ soc {
+ pin-controller-sbc {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = st,stih415-pinctrl, simple-bus;
Why is the pin controller be a simple bus?
As gpio banks are children of this node, the gpio driver associated with
these banks can only be probed if the parent of the node has simple bus
compatible string.
Maybe obvious, I'm not 100% familiar with when we use this...
+ pin-controller-front {
(...)
+ pin-controller-rear {
(...)
+ pin-controller-left {
(...)
+ pin-controller-right {
Please explain these orientations in some comment in the device
tree, I'm half-guessing that it's about the edges around the chip so
the PIO* names are actually pad names.
I would suggest you use the names north/south/west/east
if this is the case since left and right etc are relative measures.
(This terminology is used on e.g. dance mats for console games...)
If these names are from the datasheets by all means keep them.
I will add more comments in this area, the naming comes from
data-sheets. I have no choice.
+++ b/arch/arm/boot/dts/sti-pincfg.h
@@ -0,0 +1,94 @@
+#ifndef _STI_PINCFG_H_
+#define _STI_PINCFG_H_
+
+/* Alternate functions */
+#define ALT1 1
+#define ALT2 2
+#define ALT3 3
+#define ALT4 4
+#define ALT5 5
+#define ALT6 6
+#define ALT7 7
Why is this part of the DT definitions? In the pinctrl world this
is an intrinsic detail on how groups and functions are associated,
not something that you hard-code into the device tree. The
device tree should state how to combine functions with groups
and those will be strings, not numerals.
If this is wrong way to do things, I would like to fix this.
Functions in ST are alt-functions which are generally from alt0-alt7.
I use this property in the pinctrl group as shown in this simple example:
pinctrl_sbc_serial1:sbc_serial1 {
st,function = ALT3;
st,pins {
tx = PIO2 6 OUT;
rx = PIO2 7 IN;
};
};
To configure the group in alternate function 3.
You suggest that this should be
st,function = alt3; it does not look any different to what I have.
Looking at some of existing pinctrl nodes, I can see like:
samsung,pin-function = 2;
or
brcm,function = 4; /* alt0 */
Sorry ...Am I missing some thing?
Thanks,
srini
Yours,
Linus Walleij
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 2/6] clocksource: add Marvell Orion SoC timer
On 06/10/13 18:44, Daniel Lezcano wrote: On 06/10/2013 06:31 PM, Sebastian Hesselbarth wrote: On 06/10/13 18:04, Daniel Lezcano wrote: On 06/10/2013 11:35 AM, Sebastian Hesselbarth wrote: This patch add a DT enabled driver for timers found on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, and Discovery Innovation). It installs a free- running clocksource on timer0 and a clockevent source on timer1. Corresponding device tree documentation is also added. Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com It looks good for me. Sebastian, shall I take it through my tree (it will go to Thomas's tree) ? Daniel, I checked MAINTAINERS and thought clocksource, i.e. patch 2/6, would go through Thomas' or John's tree? If you want to take it, I am fine with it but guess I am not the one to choose here ;) Actually, I am giving a hand to John and Thomas. I take the patches for clockevents (and also for clocksource if both are mixed and John did not pick it yet) and Thomas pulls from my tree [1]. If there is no dependency with any other patches of your patchset, which seems to be the case, I will queue it for 3.11. Ok, thanks! Sebastian ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jun 10, 2013 at 11:16:59AM -0500, Nishanth Menon wrote: On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown broo...@kernel.org wrote: On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: So, the biggest problem here has been patch 4 (having to have a hack to deploy this stuff is a bit worrying) plus the general not having a real driver thing. Patch #4 in this series was a hack as it was not properly split up and organized as a proper DTS series -it was meant as a proof of concept - not entirely meant to indicate the remaining 1-3 patches were hacks :). The way it reads is that you're building up to a hack - if what you've done isn't enabling a sensible solution there might be a problem with the earlier steps. I think you mean http://marc.info/?t=13705924913r=1w=2 series. I will dig into it. if it is possible for Tegra and OMAP to use the same framework and strategy to deal with these kind of h/w blocks, all the more better. Not just better, if each system doing this sort of thing needs to reinvent the wheel something is going wrong. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V5] ASoC: fsl: add imx-wm8962 machine driver
On Fri, Jun 07, 2013 at 08:26:14PM +0800, Nicolin Chen wrote:
+
+struct imx_priv {
+ int hp_gpio;
+ int hp_active_low;
+ int hp_status;
+ int amic_gpio;
+ int amic_active_low;
+ int amic_status;
These are just recorded in the struct but never actually seem to be
used?
+ struct platform_device *pdev;
+ struct snd_pcm_substream *first_stream;
+ struct snd_pcm_substream *second_stream;
These aren't used any more.
signature.asc
Description: Digital signature
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 2/6] clocksource: add Marvell Orion SoC timer
On Mon, Jun 10, 2013 at 07:06:38PM +0200, Daniel Lezcano wrote: On 06/10/2013 06:47 PM, Sebastian Hesselbarth wrote: On 06/10/13 18:44, Daniel Lezcano wrote: On 06/10/2013 06:31 PM, Sebastian Hesselbarth wrote: On 06/10/13 18:04, Daniel Lezcano wrote: On 06/10/2013 11:35 AM, Sebastian Hesselbarth wrote: This patch add a DT enabled driver for timers found on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, and Discovery Innovation). It installs a free- running clocksource on timer0 and a clockevent source on timer1. Corresponding device tree documentation is also added. Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com It looks good for me. Sebastian, shall I take it through my tree (it will go to Thomas's tree) ? Daniel, I checked MAINTAINERS and thought clocksource, i.e. patch 2/6, would go through Thomas' or John's tree? If you want to take it, I am fine with it but guess I am not the one to choose here ;) Actually, I am giving a hand to John and Thomas. I take the patches for clockevents (and also for clocksource if both are mixed and John did not pick it yet) and Thomas pulls from my tree [1]. If there is no dependency with any other patches of your patchset, which seems to be the case, I will queue it for 3.11. Ok, thanks! I have a lot of ^M in the patch ... dos2unix removed them but I am wondering how they get there ? He sent it with git-send-mail, how are you extracting it from Thunderbird? thx, Jason. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v4 2/6] clocksource: add Marvell Orion SoC timer
On Mon, Jun 10, 2013 at 11:35:55AM +0200, Sebastian Hesselbarth wrote: This patch add a DT enabled driver for timers found on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, and Discovery Innovation). It installs a free- running clocksource on timer0 and a clockevent source on timer1. Corresponding device tree documentation is also added. Signed-off-by: Sebastian Hesselbarth sebastian.hesselba...@gmail.com --- Changelog: v3-v4: - export thread-safe access to TIMER_CTRL register to use with watchdog - remove IRQF_DISABLED and add .irq to clock event (Suggested by Daniel Lezcano) Notes: - This is only an update to clocksource driver, the remaining patches are not resent as they have not been changed. - I will not rework orion watchdog driver for this patch set. It is written Kirkwood/Orion5x specific although it will also work on Dove and it is messing with shared registers. It has done it before, so I consider it broken anyway. I (or somebody else) will take care of proper watchdog later. - An updated branch can be found on git://github.com/shesselba/linux-dove.git orion-irqchip-for-v3.11_v4 Hi Sebastian You can add a Tested-by: Andrew Lunn and...@lunn.ch I tested on my kirkwood QNAP. CPU0 2: 6062 bridge-interrupt-ctrl orion_event 9: 0 f1010140.gpio Reset 15: 0 f1010140.gpio USB Copy 24:106 main-interrupt-ctrl ehci_hcd:usb1 25: 2463 main-interrupt-ctrl sata_mv 26: 0 main-interrupt-ctrl f103.crypto 27: 2 main-interrupt-ctrl f1060800.xor 28: 2 main-interrupt-ctrl f1060800.xor 29: 71 main-interrupt-ctrl mv64xxx_i2c 30: 2 main-interrupt-ctrl f1060900.xor 31: 2 main-interrupt-ctrl f1060900.xor 32: 41 main-interrupt-ctrl eth0 33: 1317 main-interrupt-ctrl serial 75:745 main-interrupt-ctrl f1072004.mdio-bus Err: 0 Andrew ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC PATCH 1/4] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Mon, Jun 10, 2013 at 11:49 AM, Mark Brown broo...@kernel.org wrote: On Mon, Jun 10, 2013 at 11:16:59AM -0500, Nishanth Menon wrote: On Mon, Jun 10, 2013 at 5:31 AM, Mark Brown broo...@kernel.org wrote: On Wed, May 22, 2013 at 01:18:34PM -0500, Nishanth Menon wrote: So, the biggest problem here has been patch 4 (having to have a hack to deploy this stuff is a bit worrying) plus the general not having a real driver thing. Patch #4 in this series was a hack as it was not properly split up and organized as a proper DTS series -it was meant as a proof of concept - not entirely meant to indicate the remaining 1-3 patches were hacks :). The way it reads is that you're building up to a hack - if what you've done isn't enabling a sensible solution there might be a problem with the earlier steps. Understood, I should have taken extra steps to split up the patch into it's logical series, but wanted to get a quick feel from community about the approach before spending time on it. I apologize for the confusion caused. I think you mean http://marc.info/?t=13705924913r=1w=2 series. I will dig into it. if it is possible for Tegra and OMAP to use the same framework and strategy to deal with these kind of h/w blocks, all the more better. Not just better, if each system doing this sort of thing needs to reinvent the wheel something is going wrong. Fair enough, I did spend a short while digging through the discussion in the series, I need to find Tegra TRM to see if there is commonolity between OMAP and what Tegra does at hardware level. a) Tegra seems to use Lookup Table for sending predefinied voltage values to PMIC. OMAP has no concept of lookup table. b) Tegra and OMAP h/w blocks seem to use I2C - that is good. c) How about the i2c slave and register addresses, slew rates, start, end voltages, max voltages that SoC can support etc, I am yet to understand those. d) OMAP has 3 modules - AVS (SmartReflex), Voltage Processor(VP), Voltage Controller(VC) - I am not yet sure about the Tegra hardware blocks involved. maybe Paul could comment as well, I suppose if we could take a common approach between Tegra and OMAP. Regards, Nishanth Menon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 1/2] tps6507x-ts: Add DT support
Manish, On Mon, Jun 10, 2013 at 10:23:16AM +, Vishwanathrao Badarkhe, Manish wrote: Hi Dmitry, On Mon, Jun 10, 2013 at 11:34:42, Dmitry Torokhov wrote: Hi Manish, On Tue, May 21, 2013 at 02:24:17PM +0530, Vishwanathrao Badarkhe, Manish wrote: + struct touchscreen_init_data *init_data = NULL; + int err; + + if (node) + node = of_find_node_by_name(node, tsc); Why do you have to locate OF node manually instead of already having it attached to the device stucture? As TPS6507x is mfd device containing two nodes, regulator and touchscreen. It is necessary to use of_find_node_by_name to find child tsc node of TPS6507x MFD device. I understand that TPS6507x is a MFD device, However, I still do not understand why you do not attach OF data to the child platform device representing touchscreen when you create it. Thanks. -- Dmitry ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 3/9] ARM: dma-mapping: convert DMA direction into IOMMU protection attributes
IOMMU mappings take a prot parameter, identifying the protection bits
to enforce on the newly created mapping (READ or WRITE). The ARM
dma-mapping framework currently just passes 0 as the prot argument,
resulting in faulting mappings.
This patch infers the protection attributes based on the direction of
the DMA transfer.
Cc: Marek Szyprowski m.szyprow...@samsung.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
arch/arm/mm/dma-mapping.c | 18 --
1 file changed, 16 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6fb80cf..d119de7 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1636,13 +1636,27 @@ static dma_addr_t arm_coherent_iommu_map_page(struct
device *dev, struct page *p
{
struct dma_iommu_mapping *mapping = dev-archdata.mapping;
dma_addr_t dma_addr;
- int ret, len = PAGE_ALIGN(size + offset);
+ int ret, prot, len = PAGE_ALIGN(size + offset);
dma_addr = __alloc_iova(mapping, len);
if (dma_addr == DMA_ERROR_CODE)
return dma_addr;
- ret = iommu_map(mapping-domain, dma_addr, page_to_phys(page), len, 0);
+ switch (dir) {
+ case DMA_BIDIRECTIONAL:
+ prot = IOMMU_READ | IOMMU_WRITE;
+ break;
+ case DMA_TO_DEVICE:
+ prot = IOMMU_READ;
+ break;
+ case DMA_FROM_DEVICE:
+ prot = IOMMU_WRITE;
+ break;
+ default:
+ prot = 0;
+ }
+
+ ret = iommu_map(mapping-domain, dma_addr, page_to_phys(page), len,
prot);
if (ret 0)
goto fail;
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 5/9] arm64: pgtable: use pte_index instead of __pte_index
pte_index is a useful helper outside of arch/arm64, for things like the
ARM SMMU driver, so rename __pte_index to pte_index to be consistent
with both arch/arm/ and also the definitions of pmd_index and pgd_index.
Cc: Catalin Marinas catalin.mari...@arm.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
arch/arm64/include/asm/pgtable.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index e333a24..b93bc23 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -119,7 +119,7 @@ extern struct page *empty_zero_page;
#define pte_none(pte) (!pte_val(pte))
#define pte_clear(mm,addr,ptep)set_pte(ptep, __pte(0))
#define pte_page(pte) (pfn_to_page(pte_pfn(pte)))
-#define pte_offset_kernel(dir,addr)(pmd_page_vaddr(*(dir)) +
__pte_index(addr))
+#define pte_offset_kernel(dir,addr)(pmd_page_vaddr(*(dir)) +
pte_index(addr))
#define pte_offset_map(dir,addr) pte_offset_kernel((dir), (addr))
#define pte_offset_map_nested(dir,addr)pte_offset_kernel((dir), (addr))
@@ -263,7 +263,7 @@ static inline pmd_t *pmd_offset(pud_t *pud, unsigned long
addr)
#endif
/* Find an entry in the third-level page table.. */
-#define __pte_index(addr) (((addr) PAGE_SHIFT) (PTRS_PER_PTE - 1))
+#define pte_index(addr)(((addr) PAGE_SHIFT) (PTRS_PER_PTE
- 1))
static inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
{
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 7/9] documentation: iommu: add description of ARM System MMU binding
This patch adds a description of the device tree binding for the ARM
System MMU architecture.
Cc: Rob Herring robherri...@gmail.com
Cc: Andreas Herrmann andreas.herrm...@calxeda.com
Cc: Joerg Roedel j...@8bytes.org
Signed-off-by: Will Deacon will.dea...@arm.com
---
.../devicetree/bindings/iommu/arm,smmu.txt | 70 ++
1 file changed, 70 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iommu/arm,smmu.txt
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
new file mode 100644
index 000..e34c6cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -0,0 +1,70 @@
+* ARM System MMU Architecture Implementation
+
+ARM SoCs may contain an implementation of the ARM System Memory
+Management Unit Architecture, which can be used to provide 1 or 2 stages
+of address translation to bus masters external to the CPU.
+
+The SMMU may also raise interrupts in response to various fault
+conditions.
+
+** System MMU required properties:
+
+- compatible: Should be one of:
+
+arm,smmu-v1
+arm,smmu-v2
+arm,mmu-400
+arm,mmu-500
+
+ depending on the particular implementation and/or the
+ version of the architecture implemented.
+
+- reg : Base address and size of the SMMU.
+
+- #global-interrupts : The number of global interrupts exposed by the
+ device.
+
+- interrupts: Interrupt list, with the first #global-irqs entries
+ corresponding to the global interrupts and any
+ following entries corresponding to context interrupts,
+ specified in order of their indexing by the SMMU.
+
+ For SMMUv2 implementations, there must be exactly one
+ interrupt per context bank. In the case of a single,
+ combined interrupt, it must be listed multiple times.
+
+- mmu-masters : A list of phandles to device nodes representing bus
+ masters for which the SMMU can provide a translation
+ and their corresponding StreamIDs (see example below).
+ Each device node linked from this list must have a
+ #stream-id-cells property, indicating the number of
+ StreamIDs associated with it.
+
+** System MMU optional properties:
+
+- smmu-parent : When multiple SMMUs are chained together, this
+ property can be used to provide a phandle to the
+ parent SMMU (that is the next SMMU on the path going
+ from the mmu-masters towards memory) node for this
+ SMMU.
+
+Example:
+
+smmu {
+compatible = arm,smmu-v1;
+reg = 0xba5e 0x1;
+#global-interrupts = 2;
+interrupts = 0 32 4,
+ 0 33 4,
+ 0 34 4, /* This is the first context interrupt
*/
+ 0 35 4,
+ 0 36 4,
+ 0 37 4;
+
+/*
+ * Two DMA controllers, the first with two StreamIDs (0xd01d
+ * and 0xd01e) and the second with only one (0xd11c).
+ */
+mmu-masters = dma0 0xd01d 0xd01e,
+ dma1 0xd11c;
+};
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 6/9] arm64: device: add iommu pointer to device archdata
When using an IOMMU for device mappings, it is necessary to keep a
pointer between the device and the IOMMU to which it is attached in
order to obtain the correct IOMMU when attaching the device to a domain.
This patch adds an iommu pointer to the dev_archdata structure, in a
similar manner to other architectures (ARM, PowerPC, x86, ...).
Cc: Catalin Marinas catalin.mari...@arm.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
arch/arm64/include/asm/device.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/include/asm/device.h b/arch/arm64/include/asm/device.h
index 07dd743..01fac31 100644
--- a/arch/arm64/include/asm/device.h
+++ b/arch/arm64/include/asm/device.h
@@ -18,6 +18,9 @@
struct dev_archdata {
struct dma_map_ops *dma_ops;
+#ifdef CONFIG_IOMMU_API
+ void *iommu; /* private IOMMU data */
+#endif
struct dma_iommu_mapping*mapping;
};
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 2/9] dma: pl330: use dma_addr_t for describing bus addresses
The microcode bus address (pl330_dmac.mcode_bus) is currently a u32,
which fails to compile when building on a system with 64-bit bus
addresses.
This patch uses dma_addr_t to represent the address instead.
Cc: Jassi Brar jaswinder.si...@linaro.org
Cc: Vinod Koul vinod.k...@intel.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
drivers/dma/pl330.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 22e2a8f..f1bc593 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -501,7 +501,7 @@ struct pl330_dmac {
/* Maximum possible events/irqs */
int events[32];
/* BUS address of MicroCode buffer */
- u32 mcode_bus;
+ dma_addr_t mcode_bus;
/* CPU address of MicroCode buffer */
void*mcode_cpu;
/* List of all Channel threads */
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 1/9] dma: pl330: rip out broken, redundant ID probing
The PL330 driver probes the peripheral and primecell IDs of the device to
make sure that it is indeed an AMBA PL330. However, it does this by
making byte accesses to a device mapping of the word-aligned ID
registers, which is either UNPREDICTABLE or generates an alignment fault
(depending on the presence of the virtualisation extensions).
Rather than fix this code, we can actually rip most of it out and let
the AMBA bus driver correctly do the probing for us.
Cc: Jassi Brar jaswinder.si...@linaro.org
Cc: Vinod Koul vinod.k...@intel.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
drivers/dma/pl330.c | 27 +++
1 file changed, 3 insertions(+), 24 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 24e0754..22e2a8f 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -157,7 +157,6 @@ enum pl330_reqtype {
#define PERIPH_REV_R0P00
#define PERIPH_REV_R1P01
#define PERIPH_REV_R1P12
-#define PCELL_ID 0xff0
#define CR0_PERIPH_REQ_SET (1 0)
#define CR0_BOOT_EN_SET(1 1)
@@ -193,8 +192,6 @@ enum pl330_reqtype {
#define INTEG_CFG 0x0
#define PERIPH_ID_VAL ((PART 0) | (DESIGNER 12))
-#define PCELL_ID_VAL 0xb105f00d
-
#define PL330_STATE_STOPPED(1 0)
#define PL330_STATE_EXECUTING (1 1)
#define PL330_STATE_WFE(1 2)
@@ -292,7 +289,6 @@ static unsigned cmd_line;
/* Populated by the PL330 core driver for DMA API driver's info */
struct pl330_config {
u32 periph_id;
- u32 pcell_id;
#define DMAC_MODE_NS (1 0)
unsigned intmode;
unsigned intdata_bus_width:10; /* In number of bits */
@@ -650,19 +646,6 @@ static inline bool _manager_ns(struct pl330_thread *thrd)
return (pl330-pinfo-pcfg.mode DMAC_MODE_NS) ? true : false;
}
-static inline u32 get_id(struct pl330_info *pi, u32 off)
-{
- void __iomem *regs = pi-base;
- u32 id = 0;
-
- id |= (readb(regs + off + 0x0) 0);
- id |= (readb(regs + off + 0x4) 8);
- id |= (readb(regs + off + 0x8) 16);
- id |= (readb(regs + off + 0xc) 24);
-
- return id;
-}
-
static inline u32 get_revision(u32 periph_id)
{
return (periph_id PERIPH_REV_SHIFT) PERIPH_REV_MASK;
@@ -1986,9 +1969,6 @@ static void read_dmac_config(struct pl330_info *pi)
pi-pcfg.num_events = val;
pi-pcfg.irq_ns = readl(regs + CR3);
-
- pi-pcfg.periph_id = get_id(pi, PERIPH_ID);
- pi-pcfg.pcell_id = get_id(pi, PCELL_ID);
}
static inline void _reset_thread(struct pl330_thread *thrd)
@@ -2098,10 +2078,8 @@ static int pl330_add(struct pl330_info *pi)
regs = pi-base;
/* Check if we can handle this DMAC */
- if ((get_id(pi, PERIPH_ID) 0xf) != PERIPH_ID_VAL
- || get_id(pi, PCELL_ID) != PCELL_ID_VAL) {
- dev_err(pi-dev, PERIPH_ID 0x%x, PCELL_ID 0x%x !\n,
- get_id(pi, PERIPH_ID), get_id(pi, PCELL_ID));
+ if ((pi-pcfg.periph_id 0xf) != PERIPH_ID_VAL) {
+ dev_err(pi-dev, PERIPH_ID 0x%x !\n, pi-pcfg.periph_id);
return -EINVAL;
}
@@ -2922,6 +2900,7 @@ pl330_probe(struct amba_device *adev, const struct
amba_id *id)
if (ret)
return ret;
+ pi-pcfg.periph_id = adev-periphid;
ret = pl330_add(pi);
if (ret)
goto probe_err1;
--
1.8.2.2
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH 8/9] iommu: add support for ARM Ltd. System MMU architecture
This patch adds support for SMMUs implementing the ARM System MMU architecture versions 1 or 2. Both arm and arm64 are supported, although the v7s descriptor format is not used. Cc: Rob Herring robherri...@gmail.com Cc: Andreas Herrmann andreas.herrm...@calxeda.com Cc: Olav Haugan ohau...@codeaurora.org Cc: Joerg Roedel j...@8bytes.org Signed-off-by: Will Deacon will.dea...@arm.com --- drivers/iommu/Kconfig| 13 + drivers/iommu/Makefile |1 + drivers/iommu/arm-smmu.c | 1965 ++ 3 files changed, 1979 insertions(+) create mode 100644 drivers/iommu/arm-smmu.c diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig index c332fb9..957cfd4 100644 --- a/drivers/iommu/Kconfig +++ b/drivers/iommu/Kconfig @@ -261,4 +261,17 @@ config SHMOBILE_IOMMU_L1SIZE default 256 if SHMOBILE_IOMMU_ADDRSIZE_64MB default 128 if SHMOBILE_IOMMU_ADDRSIZE_32MB +config ARM_SMMU + bool ARM Ltd. System MMU (SMMU) Support + depends on ARM64 || (ARM_LPAE OF) + select IOMMU_API + select ARM_DMA_USE_IOMMU if ARM + help + Support for implementations of the ARM System MMU architecture + versions 1 and 2. The driver supports both v7l and v8l table + formats with 4k and 64k page sizes. + + Say Y here if your SoC includes an IOMMU device implementing + the ARM SMMU architecture. + endif # IOMMU_SUPPORT diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile index ef0e520..bbe7041 100644 --- a/drivers/iommu/Makefile +++ b/drivers/iommu/Makefile @@ -3,6 +3,7 @@ obj-$(CONFIG_OF_IOMMU) += of_iommu.o obj-$(CONFIG_MSM_IOMMU) += msm_iommu.o msm_iommu_dev.o obj-$(CONFIG_AMD_IOMMU) += amd_iommu.o amd_iommu_init.o obj-$(CONFIG_AMD_IOMMU_V2) += amd_iommu_v2.o +obj-$(CONFIG_ARM_SMMU) += arm-smmu.o obj-$(CONFIG_DMAR_TABLE) += dmar.o obj-$(CONFIG_INTEL_IOMMU) += iova.o intel-iommu.o obj-$(CONFIG_IRQ_REMAP) += intel_irq_remapping.o irq_remapping.o diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c new file mode 100644 index 000..57ec597 --- /dev/null +++ b/drivers/iommu/arm-smmu.c @@ -0,0 +1,1965 @@ +/* + * IOMMU API for ARM architected SMMU implementations. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License 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. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. + * + * Copyright (C) 2013 ARM Limited + * + * Author: Will Deacon will.dea...@arm.com + * + * This driver currently supports: + * - SMMUv1 and v2 implementations + * - Stream-matching and stream-indexing + * - v7/v8 long-descriptor format + * - Non-secure access to the SMMU + * - 4k and 64k pages, with contiguous pte hints. + * - Up to 39-bit addressing + * - Context fault reporting + */ + +#define pr_fmt(fmt) arm-smmu: fmt + +#include linux/dma-mapping.h +#include linux/err.h +#include linux/interrupt.h +#include linux/io.h +#include linux/iommu.h +#include linux/mm.h +#include linux/module.h +#include linux/of.h +#include linux/platform_device.h +#include linux/slab.h +#include linux/spinlock.h + +#include linux/amba/bus.h + +#include asm/pgalloc.h + +/* Maximum number of stream IDs assigned to a single device */ +#define MAX_MASTER_STREAMIDS 8 + +/* Maximum number of context banks per SMMU */ +#define ARM_SMMU_MAX_CBS 128 + +/* Maximum number of mapping groups per SMMU */ +#define ARM_SMMU_MAX_SMRS 128 + +/* Number of VMIDs per SMMU */ +#define ARM_SMMU_NUM_VMIDS 256 + +/* SMMU global address space */ +#define ARM_SMMU_GR0(smmu) ((smmu)-base) +#define ARM_SMMU_GR1(smmu) ((smmu)-base + (smmu)-pagesize) + +/* Page table bits */ +#define ARM_SMMU_PTE_PAGE (((pteval_t)3) 0) +#define ARM_SMMU_PTE_CONT (((pteval_t)1) 52) +#define ARM_SMMU_PTE_AF(((pteval_t)1) 10) +#define ARM_SMMU_PTE_SH_NS (((pteval_t)0) 8) +#define ARM_SMMU_PTE_SH_OS (((pteval_t)2) 8) +#define ARM_SMMU_PTE_SH_IS (((pteval_t)3) 8) + +#if PAGE_SIZE == SZ_4K +#define ARM_SMMU_PTE_CONT_ENTRIES 16 +#elif PAGE_SIZE == SZ_64K +#define ARM_SMMU_PTE_CONT_ENTRIES 32 +#else +#define ARM_SMMU_PTE_CONT_ENTRIES 1 +#endif + +#define ARM_SMMU_PTE_CONT_SIZE (PAGE_SIZE * ARM_SMMU_PTE_CONT_ENTRIES) +#define ARM_SMMU_PTE_CONT_MASK (~(ARM_SMMU_PTE_CONT_SIZE - 1)) +#define ARM_SMMU_PTE_HWTABLE_SIZE
Re: [PATCH v2 2/2] i2c: designware: add two optional property tx/rx-fifo-size
Hi Zhangfei Gao,
On Mon, Jun 10, 2013 at 01:02:55PM +0800, Zhangfei Gao wrote:
rx-fifo-size and tx-fifo-size will be updated if provided from dts
Signed-off-by: Zhangfei Gao zhangfei@linaro.org
CC: Baruch Siach bar...@tkos.co.il
---
.../devicetree/bindings/i2c/i2c-designware.txt |7 +++
drivers/i2c/busses/i2c-designware-platdrv.c|3 +++
2 files changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
index e42a2ee..61fdb44 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
@@ -6,6 +6,11 @@ Required properties :
- reg : Offset and length of the register set for the device
- interrupts : IRQ where IRQ is the interrupt number.
+Optional properties:
+
+ - rx-fifo-size : 1 cell, Rx fifo threshold
I'd use the word 'size' instead of 'threshold' here. The term 'threshold' is
used for something else in the datasheet.
baruch
+ - tx-fifo-size : 1 cell, Tx fifo threshold
+
Recommended properties :
- clock-frequency : desired I2C bus clock frequency in Hz.
@@ -18,5 +23,7 @@ Example :
compatible = snps,designware-i2c;
reg = 0xf 0x1000;
interrupts = 11;
+ rx-fifo-size = 16;
+ tx-fifo-size = 16;
clock-frequency = 40;
};
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 41659c0..6760cea 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -85,6 +85,7 @@ static int dw_i2c_probe(struct platform_device *pdev)
struct dw_i2c_dev *dev;
struct i2c_adapter *adap;
struct resource *mem;
+ struct device_node *np = pdev-dev.of_node;
int irq, r;
/* NOTE: driver uses the static register mapping */
@@ -140,6 +141,8 @@ static int dw_i2c_probe(struct platform_device *pdev)
dev-rx_fifo_depth = ((param1 8) 0xff) + 1;
dev-adapter.nr = pdev-id;
}
+ of_property_read_u32(np, rx-fifo-size, dev-rx_fifo_depth);
+ of_property_read_u32(np, tx-fifo-size, dev-tx_fifo_depth);
r = i2c_dw_init(dev);
if (r)
return r;
--
1.7.9.5
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH V3 0/8] mmc_of_parse() adaptations, switch mvsdio to mmc_of_parse()
On Sun, Jun 09, 2013 at 10:14:10PM +0200, Simon Baatz wrote: Hi, RESEND V3: - Dropped patches 9 and 10, they are part of linux-next already NB: patch 7 as well, but I did not want to change the numbering V3 changes: - Patch 01/10: Added EPROBE_DEFER case to mmc_of_parse() - Added Acked-By to (unmodified) patches 02 and 03. V2 changes: - Converted mvsdio to use mmc_of_parse() - Adapted DTS files using mvsdio accordingly - Changed mmc_of_parse() to return errors to the caller While adding DT support for the Sheevaplugs by Globalscale Technologies (Kirkwood), it turned out that the DT binding of mvsdio lacked features to properly support the hardware (active high/low of CD and WP pins could not be described in DT). This is standard functionality provided by the mmc_of_parse() helper function. However, mmc_of_parse() may allocate GPIO lines. If the allocation fails, it outputs an error, but does not return an error to its caller. Therefore, a proposal to handle errors in mmc_of_parse() is made. This also allows to handle the EPROBE_DEFER case when GPIO is not loaded yet. The patch set is structured as follows: 1 Adapt mmc_of_parse() to return errors 2-6 Handle errors in current drivers using mmc_of_parse() (compile tested only) 7-8 Convert mvsdio and respective dts files to mmc_of_parse() (tested on kirkwood) Hi Simon Tested-by: Andrew Lunn and...@lunn.ch I tested on kirkwood topkick with DT. SDIO wifi device is found. Andrew ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH V3 6/8] mmc: tegra: handle mmc_of_parse() errors during probe
On 06/09/2013 02:14 PM, Simon Baatz wrote: Signed-off-by: Simon Baatz gmbno...@gmail.com Tested-by: Stephen Warren swar...@nvidia.com (On Seaboard/Springbank board, i.e. Tegra20) diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c +err_parse_dt: err_power_req: err_alloc_tegra_host: Nit: It'd be nice if that new label got inserted into the middle of the list, so err_power_req, err_parse_dt, err_alloc_tegra_host. That way if we ever needed to add separate code there, they'd be in the right order already. Still, this isn't worth fixing unless you have to repost for some other reason I guess. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH V3 6/8] mmc: tegra: handle mmc_of_parse() errors during probe
Hi Stephen, On Mon, Jun 10, 2013 at 03:11:14PM -0600, Stephen Warren wrote: On 06/09/2013 02:14 PM, Simon Baatz wrote: Signed-off-by: Simon Baatz gmbno...@gmail.com Tested-by: Stephen Warren swar...@nvidia.com Thanks! (On Seaboard/Springbank board, i.e. Tegra20) diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c +err_parse_dt: err_power_req: err_alloc_tegra_host: Nit: It'd be nice if that new label got inserted into the middle of the list, so err_power_req, err_parse_dt, err_alloc_tegra_host. That way if we ever needed to add separate code there, they'd be in the right order already. Still, this isn't worth fixing unless you have to repost for some other reason I guess. Yes, you are right. I updated the patch locally, so the update will be in if I need to repost (or if the nicer version is explicitly requested). Since this change is only syntactical, I simply assume that your Tested-by is still valid even with the change ;-) - Simon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 06/11] ARM:stixxxx: Add STiH415 SOC support
On Mon, Jun 10, 2013 at 12:46:59PM +0100, Srinivas KANDAGATLA wrote: + aux_ctrl = (0x1 L2X0_AUX_CTRL_SHARE_OVERRIDE_SHIFT) | + (0x1 L2X0_AUX_CTRL_DATA_PREFETCH_SHIFT) | + (0x1 L2X0_AUX_CTRL_INSTR_PREFETCH_SHIFT) | + (way_size L2X0_AUX_CTRL_WAY_SIZE_SHIFT); #include linux/bitops.h Linus Walleij would write use BIT() here I will use BIT() macro. Without checking those fields... BIT() is only appropriate if you're really talking about single bits. If you have a field of more than a single bit which you happen to be setting to '1' then it's not appropriate to use BIT(). ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/1] of/documentation: Update document related to exynos_hdmi
On 20 May 2013 10:21, Sachin Kamat sachin.ka...@linaro.org wrote: Exynos SoCs use pinctrl to configure GPIOs. Update the document to reflect this change. Signed-off-by: Sachin Kamat sachin.ka...@linaro.org Cc: Rahul Sharma rahul.sha...@samsung.com --- .../devicetree/bindings/video/exynos_hdmi.txt |6 ++ 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt index 589edee..584385a 100644 --- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt +++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt @@ -8,9 +8,7 @@ Required properties: - hpd-gpio: following information about the hotplug gpio pin. a) phandle of the gpio controller node. b) pin number within the gpio controller. - c) pin function mode. - d) optional flags and pull up/down. - e) drive strength. + c) optional flags and pull up/down. Example: @@ -18,5 +16,5 @@ Example: compatible = samsung,exynos5-hdmi; reg = 0x1453 0x10; interrupts = 0 95 0; - hpd-gpio = gpx3 7 0xf 1 3; + hpd-gpio = gpx3 7 1; }; -- 1.7.9.5 Ping.. Inki, Would you like to take this through your tree? -- With warm regards, Sachin ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 4/9] ARM: dma-mapping: NULLify dev-archdata.mapping pointer on detach
Hi Will, Will Deacon will.dea...@arm.com wrote @ Mon, 10 Jun 2013 20:34:40 +0200: The current code only clobbers a local variable, so the device is left with a stale mapping pointer. True. This's my bad. Thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
