Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
Hi On Fri, 13 Jul 2012, Rob Herring wrote: > I'm not sure this is really a good use of aliases. UARTs use aliases > because it is important that the UART number to tty number is known and > fixed. IIUC, as an example you are picking timer1 because it has > properties X, Y and Z. If so, then you should describe those h/w > properties within the timer nodes so you can pick which timer to use > based on it's h/w properties. Some GPTIMER blocks have input and output signals that can be routed to external package balls. So it's possible that some application may need to request a specific timer ID, since that timer would be connected to a specific off-chip device. - Paul ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Mis?use of aliases
> I'm not sure this is really a good use of aliases. UARTs use aliases > because it is important that the UART number to tty number is known and > fixed. This brings up an issue that I've been meaning to comment on. The use of phandle-valued properties in the aliases node causes real OFW implementations some amount of heartburn. The Open Firmware standard says that the properties in /aliases are string-valued. That's important, because aliases are shorthand for fragments of full device specifiers (pathnames that can include arguments to nodes). Phandles can point to nodes, but can't be relative, and can't encode per-node-component arguments. For binding a Linux unit number to a device node, I would prefer to decorate the node with a property like "linux,unit#", instead of breaking the standard semantics of /aliases. Mitch ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH 1/1] clk: add DT support for clock gating control
On 07/13/2012 04:42 AM, Sebastian Hesselbarh wrote:
> On 07/13/2012 05:19 AM, Rob Herring wrote:
>> What's implemented in Linux should not define the binding. The binding
>> should describe the hardware.
>> [...]
>> True, but not your problem to implement. A binding doesn't necessarily
>> mean there is a full Linux implementation. We just don't want to create
>> something only to find others need something completely different.
>
> Ok, what about a DT describing the following for a simple register-based
> clock gating controller and the corresponding gated-clock independent of
> the controller. I am sure there are a bunch of SoCs out there that
> control their clock gates by writing some bits to a register. If that
> DT description matches your expectations, I ll prepare patches with
> documentation and implementation for common clock framework.
>
Clock gates are just 1 part. There's muxes, dividers, plls, etc. I'm not
convinced that it makes sense to define clocks at this level. For
complex chips, I think just defining the chips clock controller module
as a single node with lots of clock outputs. The primary need is to
describe board specific changes not SOC level clock tree. Much of it is
static and generally only a few clocks may change config board to board.
> Sebastian
>
> --
> /* Simple clock gating controller based on bitmasks and register */
> cgc: clock-gating-control@f100 {
> compatible = "clock-gating-control-register";
> reg = <0xf100 0x4>;
>
> /* Clock gating control with one bit at bit position 0
> enable with (1<<0), disable with (0<<0) */
> cgctrl_usb0: cgc_usb0 {
> clock-gating-control,shift = <0>;
> clock-gating-control,mask = <1>;
> clock-gating-control,enable = <1>;
> clock-gating-control,disable = <0>;
> };
>
> /* Clock gating control with two bits at bit position 1-2
> enable with (2<<1), disable with (0<<1) */
> cgctrl_sata: cgc_sata {
> clock-gating-control,shift = <1>;
> clock-gating-control,mask = <3>;
> clock-gating-control,enable = <2>;
> clock-gating-control,disable = <0>;
> };
> };
>
> /* Generic clock gate description that can be used with
>any clock gating controller */
> cg_usb0: clockgate@0 {
> compatible = "gated-clock";
> #clock-cells = <0>;
> clocks = <&osc>;
> clock-gate-control = <&cgctrl_usb0>;
> };
I don't see this scaling to ~50 clocks.
Rob
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 5/7] ARM: davinci: i2c: add OF support
Hello Sekhar,
On 13.07.2012 15:57, Sekhar Nori wrote:
Hi Heiko,
On 5/30/2012 3:49 PM, Heiko Schocher wrote:
add of support for the davinci i2c driver.
Signed-off-by: Heiko Schocher
Cc: davinci-linux-open-sou...@linux.davincidsp.com
Cc: linux-arm-ker...@lists.infradead.org
Cc: devicetree-discuss@lists.ozlabs.org
Cc: linux-...@vger.kernel.org
Cc: Ben Dooks
Cc: Wolfram Sang
Cc: Grant Likely
Cc: Sekhar Nori
Cc: Wolfgang Denk
Cc: Sylwester Nawrocki
[...]
diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt
b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
new file mode 100644
index 000..e98a025
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
[...]
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index a76d85f..4e7a966 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -38,9 +38,12 @@
#include
#include
#include
+#include
+#include
#include
#include
+#include
Seems like a stray change. I was able to build and use just fine
without this include.
Hups. Good catch! Removed.
/* - global defines --- */
@@ -114,6 +117,7 @@ struct davinci_i2c_dev {
struct completion xfr_complete;
struct notifier_block freq_transition;
#endif
+ struct davinci_i2c_platform_data *pdata;
};
/* default platform data to use if not supplied in the platform_device */
@@ -149,13 +153,22 @@ static void generic_i2c_clock_pulse(unsigned int scl_pin)
}
}
+static struct davinci_i2c_platform_data
+ *i2c_get_plattformdata(struct davinci_i2c_dev *dev)
+{
+ if (dev->dev->platform_data == NULL)
+ return dev->pdata;
+
+ return dev->dev->platform_data;
+}
It seems to me that if we setup the newly introduced dev->pdata
member correctly once in probe, there should not be a need for this
function. We can also eliminate multiple checks for pdata in code.
See below for more.
Ok.
+
/* This routine does i2c bus recovery as specified in the
* i2c protocol Rev. 03 section 3.16 titled "Bus clear"
*/
static void i2c_recover_bus(struct davinci_i2c_dev *dev)
{
u32 flag = 0;
- struct davinci_i2c_platform_data *pdata = dev->dev->platform_data;
+ struct davinci_i2c_platform_data *pdata = i2c_get_plattformdata(dev);
dev_err(dev->dev, "initiating i2c bus recovery\n");
/* Send NACK to the slave */
@@ -187,7 +200,7 @@ static inline void davinci_i2c_reset_ctrl(struct
davinci_i2c_dev *i2c_dev,
static void i2c_davinci_calc_clk_dividers(struct davinci_i2c_dev *dev)
{
- struct davinci_i2c_platform_data *pdata = dev->dev->platform_data;
+ struct davinci_i2c_platform_data *pdata = i2c_get_plattformdata(dev);
u16 psc;
u32 clk;
u32 d;
@@ -235,7 +248,7 @@ static void i2c_davinci_calc_clk_dividers(struct
davinci_i2c_dev *dev)
*/
static int i2c_davinci_init(struct davinci_i2c_dev *dev)
{
- struct davinci_i2c_platform_data *pdata = dev->dev->platform_data;
+ struct davinci_i2c_platform_data *pdata = i2c_get_plattformdata(dev);
if (!pdata)
pdata =&davinci_i2c_platform_data_default;
@@ -308,7 +321,7 @@ static int
i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct i2c_msg *msg, int stop)
{
struct davinci_i2c_dev *dev = i2c_get_adapdata(adap);
- struct davinci_i2c_platform_data *pdata = dev->dev->platform_data;
+ struct davinci_i2c_platform_data *pdata = i2c_get_plattformdata(dev);
u32 flag;
u16 w;
int r;
@@ -635,6 +648,12 @@ static struct i2c_algorithm i2c_davinci_algo = {
.functionality = i2c_davinci_func,
};
+static const struct of_device_id davinci_i2c_of_match[] = {
+ {.compatible = "ti,davinci-i2c", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, davinci_i2c_of_match);
+
static int davinci_i2c_probe(struct platform_device *pdev)
{
struct davinci_i2c_dev *dev;
@@ -676,6 +695,25 @@ static int davinci_i2c_probe(struct platform_device *pdev)
dev->irq = irq->start;
platform_set_drvdata(pdev, dev);
+ if ((dev->dev->platform_data == NULL)&&
+ (pdev->dev.of_node)) {
+ u32 prop;
+
+ dev->pdata = devm_kzalloc(&pdev->dev,
+ sizeof(struct davinci_i2c_platform_data), GFP_KERNEL);
+ if (!dev->pdata) {
+ r = -ENOMEM;
+ goto err_free_mem;
+ }
+ memcpy(dev->pdata,&davinci_i2c_platform_data_default,
+ sizeof(struct davinci_i2c_platform_data));
+ if (!of_property_read_u32(pdev->dev.of_node, "clock-frequency",
+ &prop))
+ dev->pdata->bus_freq = prop / 1000;
+ if (!of_property_read_u32(pdev->dev.of_node, "bus-delay",
+ &prop))
+
Re: [RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
On 07/13/2012 05:26 PM, Jon Hunter wrote:
> Add the 12 GP timers nodes present in OMAP3.
> Add the 11 GP timers nodes present in OMAP4.
>
> Add documentation for timer properties specific to OMAP.
>
> For each timer an alias is being added. The purpose for doing this is because
> the OMAP dmtimer driver uses an ID to distinguish between the different timer
> instances. For example, a timer can be requested by its ID. By adding an alias
> for each timer we can then use the function of_alias_get_id() to extract the
> ID for each timer from the alias name. The same method is used for the TTY
> serial devices. If it is preferred that such an alias is not added and there
> is a better way to pass an ID from device-tree let me know.
I'm not sure this is really a good use of aliases. UARTs use aliases
because it is important that the UART number to tty number is known and
fixed. IIUC, as an example you are picking timer1 because it has
properties X, Y and Z. If so, then you should describe those h/w
properties within the timer nodes so you can pick which timer to use
based on it's h/w properties.
Rob
>
> Cc: Benoit Cousson
> Signed-off-by: Jon Hunter
> ---
> .../devicetree/bindings/arm/omap/timer.txt | 34 +++
> arch/arm/boot/dts/omap3.dtsi | 104
>
> arch/arm/boot/dts/omap4.dtsi | 93 +
> 3 files changed, 231 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
> b/Documentation/devicetree/bindings/arm/omap/timer.txt
> new file mode 100644
> index 000..dcbb451
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -0,0 +1,34 @@
> +OMAP Timer controller bindings
> +
> +Required properties:
> +- compatible:
> + - "ti,omap3-timer" for OMAP3+ controllers
> +- reg: Contains timer register address range (base address and length)
> +- interrupts: Contains the interrupt information for the timer. The format is
> + being dependent on which interrupt controller the OMAP device uses.
> +
> +OMAP specific properties:
> +- ti,hwmods: Name of the hwmod associated to the timer:
> + "timer", being the 1-based instance number from the HW spec
> +- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
> +- ti,timer-pwm: Indicates the timer supports can generate PWM output.
> +- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
> and
> + therefore cannot be used by the kernel.
> +
> +Note: Each timer should have an alias correctly numbered in "aliases" node.
> The
> + alias is used to identify the timer instance in the driver.
> +
> +Example:
> +
> +aliases {
> + timer12 = &timer12;
> +};
> +
> +timer12: timer@48304000 {
> + compatible = "ti,omap3-timer";
> + reg = <0x48304000 0xfff>;
> + interrupts = <95>;
> + ti,hwmods = "timer12"
> + ti,timer-alwon;
> + ti,timer-secure;
> +};
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 8109471..f309f2a 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -12,12 +12,25 @@
>
> / {
> compatible = "ti,omap3430", "ti,omap3";
> + interrupt-parent = <&intc>;
>
> aliases {
> serial0 = &uart1;
> serial1 = &uart2;
> serial2 = &uart3;
> serial3 = &uart4;
> + timer1 = &timer1;
> + timer2 = &timer2;
> + timer3 = &timer3;
> + timer4 = &timer4;
> + timer5 = &timer5;
> + timer6 = &timer6;
> + timer7 = &timer7;
> + timer8 = &timer8;
> + timer9 = &timer9;
> + timer10 = &timer10;
> + timer11 = &timer11;
> + timer12 = &timer12;
> };
>
> cpus {
> @@ -220,5 +233,96 @@
> compatible = "ti,omap3-wdt";
> ti,hwmods = "wd_timer2";
> };
> +
> + timer1: timer@48318000 {
> + compatible = "ti,omap3-timer";
> + reg = <0x48318000 0xfff>;
> + interrupts = <37>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer@49032000 {
> + compatible = "ti,omap3-timer";
> + reg = <0x49032000 0xfff>;
> + interrupts = <38>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer@49034000 {
> + compatible = "ti,omap3-timer";
> + reg = <0x49034000 0xfff>;
> + interrupts = <39>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer@49036000 {
> + compatible = "ti,omap3-timer";
> +
Re: [RFC RESEND 4/4] ARM: OMAP: Add DT support for timer driver
On 07/13/2012 06:41 PM, Paul Walmsley wrote: > Hi > > On Fri, 13 Jul 2012, Jon Hunter wrote: > >> 1. If DT blob is present, then let HWMOD create the timer devices >> dynamically. > > This probably should read "is _not_ present", yes? Yes, you are right. What a balls-up ... Thanks Jon ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC RESEND 4/4] ARM: OMAP: Add DT support for timer driver
Hi On Fri, 13 Jul 2012, Jon Hunter wrote: > 1. If DT blob is present, then let HWMOD create the timer devices dynamically. This probably should read "is _not_ present", yes? - Paul ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC RESEND 4/4] ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. If DT blob is present, then let HWMOD create the timer devices dynamically.
2. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and the timer instance is looked-up using the
device tree alias mechanism. Therefore, avoid using "pdev-id" in the driver
and use "timer->id" which will be initialised correctly regardless of whether
device tree is present.
3. When device-tree is present the platform_data structure will be NULL and so
check for this.
4. The OMAP timer device tree binding optional parameters ...
a. ti,timer-alwon --> Timer is in an always-on power domain
b. ti,timer-pwn--> Timer can generate a PWM output
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |4
arch/arm/plat-omap/dmtimer.c | 32 ++--
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index e3b9931..ad5b29a 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -473,6 +473,10 @@ static int __init omap2_dm_timer_init(void)
{
int ret;
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
ret = omap_hwmod_for_each_by_class("timer", omap_timer_init, NULL);
if (unlikely(ret)) {
pr_err("%s: device registration failed.\n", __func__);
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 626ad8c..5a51b67 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -40,6 +40,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -123,7 +125,7 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
omap_dm_timer_enable(timer);
- if (timer->pdev->id != 1) {
+ if (timer->id != 1) {
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
omap_dm_timer_wait_for_reset(timer);
}
@@ -214,7 +216,7 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int id)
spin_lock_irqsave(&dm_timer_lock, flags);
list_for_each_entry(t, &omap_timer_list, node) {
- if (t->pdev->id == id && !t->reserved) {
+ if (t->id == id && !t->reserved) {
timer = t;
timer->reserved = 1;
break;
@@ -414,7 +416,7 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
* use the clock framework to set the parent clock. To be removed
* once OMAP1 migrated to using clock framework for dmtimers
*/
- if (pdata->set_timer_src)
+ if (pdata && pdata->set_timer_src)
return pdata->set_timer_src(timer->pdev, source);
fclk = clk_get(&timer->pdev->dev, "fck");
@@ -695,7 +697,7 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
struct device *dev = &pdev->dev;
struct dmtimer_platform_data *pdata = pdev->dev.platform_data;
- if (!pdata) {
+ if (!pdata && !dev->of_node) {
dev_err(dev, "%s: no platform data.\n", __func__);
return -ENODEV;
}
@@ -724,11 +726,21 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
return -ENOMEM;
}
- timer->id = pdev->id;
+ if (dev->of_node) {
+ timer->id = of_alias_get_id(dev->of_node, "timer");
+
+ if (of_find_property(dev->of_node, "ti,timer-alwon", NULL))
+ timer->capability |= OMAP_TIMER_ALWON;
+ if (of_find_property(dev->of_node, "ti,timer-pwm", NULL))
+ timer->capability |= OMAP_TIMER_HAS_PWM;
+ } else {
+ timer->id = pdev->id;
+ timer->capability = pdata->timer_capability;
+ }
+
timer->irq = irq->start;
timer->reserved = omap_dm_timer_reserved_systimer(timer->id);
timer->pdev = pdev;
- timer->capability = pdata->timer_capability;
/* Skip pm_runtime_enable for OMAP1 */
if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
@@ -778,11 +790,19 @@ static int __devexit omap_dm_timer_remove(struct
platform_device *pdev)
return ret;
}
+static const struct of_device_id omap_timer_match[] = {
+ { .compatible = "ti,omap3-timer", },
+ { .compatible = "ti,omap2-timer", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_timer_match);
+
static struct platform_driver omap_dm_timer_driver = {
.probe = omap_dm_timer_probe,
.remove = __devexit_p(omap_dm_timer_remo
[RFC RESEND 3/4] ARM: OMAP4: Add timer clock aliases for device-tree
For OMAP4, the dmtimers are located in the Wake-up, ABE and Peripheral (PER)
power domains. Hence, when the dmtimer is configured to use the "timer_sys_ck"
as its functional clock the actual clock used is different depending on whether
the clock is in the Wake-up, ABE or PER domain. So when we look-up the dmtimer's
"timer_sys_ck" we need to specify the timer device name as well as clock alias
to find the right clock.
Currently, the device names for the timers have the format "omap_timer.X" where
X is the timer instance number. When using to device tree, the format of the
device name created by device-tree is different and has the format
"." (this is assuming that the device-tree "reg"
property is specified). This causes the look-up for the OMAP4 "timer_sys_ck" to
fail. To fix this add new timer clock alias for using device-tree.
Please note that adding a 2nd set of clock aliases for the same clocks to only
temporary until device-tree migration is complete. Then we can remove the legacy
aliases. Hence, I have marked the legacy aliases with a "TODO" to remove them.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/clock44xx_data.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index d7f55e4..7dfeaf0 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3314,6 +3314,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK("usbhs_omap", "usbtll_fck", &dummy_ck,
CK_443X),
CLK("omap_wdt", "ick", &dummy_ck,
CK_443X),
CLK(NULL, "timer_32k_ck", &sys_32k_ck,CK_443X),
+ /* TODO: Remove "omap_timer.X" aliases once DT migration is complete */
CLK("omap_timer.1", "timer_sys_ck", &sys_clkin_ck, CK_443X),
CLK("omap_timer.2", "timer_sys_ck", &sys_clkin_ck, CK_443X),
CLK("omap_timer.3", "timer_sys_ck", &sys_clkin_ck, CK_443X),
@@ -3325,6 +3326,17 @@ static struct omap_clk omap44xx_clks[] = {
CLK("omap_timer.6", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
CLK("omap_timer.7", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
CLK("omap_timer.8", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
+ CLK("4a318000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("48032000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("48034000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("48036000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("4803e000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("48086000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("48088000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("49038000.timer", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
+ CLK("4903a000.timer", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
+ CLK("4903c000.timer", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
+ CLK("4903e000.timer", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
};
int __init omap4xxx_clk_init(void)
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RFC 0/4] ARM: OMAP3+: Add device-tree support for timers
Sorry for all the noise. I was having network problems in the midst of sending and then I royally screwed it up by deciding to make some last minute edits. So ignore this version of the series. Jon On 07/13/2012 05:19 PM, Jon Hunter wrote: > This series adds device-tree support for the timers on OMAP3/4 devices. Once > everyone is happy with the implementation I can add support for OMAP2/5 > devices > too. > > Testing: > - I have tested the all the timers (not used by the kernel as sys-timers) on > both OMAP3430 Beagle and OMAP4460 Panda with/without device-tree with this > series. > - The testing includes > - Configuring, starting a timer and checking the counter value is > incrementing. > - Testing timer overflow interrupt when timer expires. > - Using different clock sources to operate the timer with. > - Using DT to provide resource information for IRQ and memory by > removing Benoit's intention "HACK" in commit a4f6cdb0 (ARM: OMAP: > omap_device: Add omap_device_[alloc|delete] for DT integration) > > Jon Hunter (4): > arm/dts: OMAP: Add timer nodes > ARM: OMAP3: Dynamically disable secure timer nodes for secure devices > ARM: OMAP4: Add timer clock aliases for device-tree > ARM: OMAP: Add DT support for timer driver > > .../devicetree/bindings/arm/omap/timer.txt | 34 +++ > arch/arm/boot/dts/omap3.dtsi | 104 > > arch/arm/boot/dts/omap4.dtsi | 93 + > arch/arm/mach-omap2/board-generic.c|1 + > arch/arm/mach-omap2/clock44xx_data.c | 12 +++ > arch/arm/mach-omap2/common.h |1 + > arch/arm/mach-omap2/timer.c| 40 > arch/arm/plat-omap/dmtimer.c | 32 -- > 8 files changed, 311 insertions(+), 6 deletions(-) > create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC RESEND 2/4] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
OMAP3 devices may or may not have security features enabled. Security enabled
devices are known as high-secure (HS) and devices without security are known as
general purpose (GP).
For OMAP3 devices there are 12 general purpose timers available. On secure
devices the 12th timer is reserved for secure usage and so cannot be used by
the kernel, where as for a GP device it is available. We can detect the OMAP
device type, secure or GP, at runtime via an on-chip register. Today, when not
using DT, we do not register the 12th timer as a linux device if the device is
secure.
When using device tree, device tree is going to register all the timer devices
it finds in the device tree blob. To prevent device tree from registering 12th
timer on a secure OMAP3 device we can add a status property to the timer
binding with the value "disabled" at boot time. Note that timer 12 on a OMAP3
device has a property "ti,timer-secure" to indicate that it will not be
available on a secure device and so for secure OMAP3 devices, we search for
timers with this property and then disable them. Using the prom_add_property()
function to dynamically add a property was a recommended approach suggested by
Rob Herring [1].
I have tested this on an OMAP3 GP device and faking it to pretend to be a
secure device to ensure that any timers marked with "ti,timer-secure" are not
registered on boot. I have also made sure that all timers are registered as
expected on a GP device by default.
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|1 +
arch/arm/mach-omap2/timer.c | 36 +++
3 files changed, 38 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 6f93a20..20124d7 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[] __initdata =
{
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
+ omap_dmtimer_init();
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 1f65b18..d6a4875 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params
*sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
struct omap2_hsmmc_info;
extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
+extern void omap_dmtimer_init(void);
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 13d20c8..e3b9931 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
@@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
}
arch_initcall(omap2_dm_timer_init);
+static struct property timer_disabled = {
+ .name = "status",
+ .length = sizeof("disabled"),
+ .value = "disabled",
+};
+
+static struct of_device_id omap3_timer_match[] __initdata = {
+ { .compatible = "ti,omap3-timer", },
+ { }
+};
+
+/**
+ * omap_dmtimer_init - initialisation function when device tree is used
+ *
+ * For secure OMAP3 devices, timers with device type "timer-secure" cannot
+ * be used by the kernel as they are reserved. Therefore, to prevent the
+ * kernel registering these devices remove them dynamically from the device
+ * tree on boot.
+ */
+void __init omap_dmtimer_init(void)
+{
+ struct device_node *np;
+
+ if (!cpu_is_omap34xx())
+ return;
+
+ /* If we are a secure device, remove any secure timer nodes */
+ if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
+ for_each_matching_node(np, omap3_timer_match) {
+ if (of_get_property(np, "ti,timer-secure", NULL))
+ prom_add_property(np, &timer_disabled);
+ }
+ }
+}
+
/**
* omap2_override_clocksource - clocksource override with user configuration
*
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC RESEND 1/4] arm/dts: OMAP: Add timer nodes
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add documentation for timer properties specific to OMAP.
For each timer an alias is being added. The purpose for doing this is because
the OMAP dmtimer driver uses an ID to distinguish between the different timer
instances. For example, a timer can be requested by its ID. By adding an alias
for each timer we can then use the function of_alias_get_id() to extract the
ID for each timer from the alias name. The same method is used for the TTY
serial devices. If it is preferred that such an alias is not added and there
is a better way to pass an ID from device-tree let me know.
Cc: Benoit Cousson
Signed-off-by: Jon Hunter
---
.../devicetree/bindings/arm/omap/timer.txt | 34 +++
arch/arm/boot/dts/omap3.dtsi | 104
arch/arm/boot/dts/omap4.dtsi | 93 +
3 files changed, 231 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
b/Documentation/devicetree/bindings/arm/omap/timer.txt
new file mode 100644
index 000..dcbb451
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -0,0 +1,34 @@
+OMAP Timer controller bindings
+
+Required properties:
+- compatible:
+ - "ti,omap3-timer" for OMAP3+ controllers
+- reg: Contains timer register address range (base address and length)
+- interrupts: Contains the interrupt information for the timer. The format is
+ being dependent on which interrupt controller the OMAP device uses.
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the timer:
+ "timer", being the 1-based instance number from the HW spec
+- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
+- ti,timer-pwm: Indicates the timer supports can generate PWM output.
+- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device and
+ therefore cannot be used by the kernel.
+
+Note: Each timer should have an alias correctly numbered in "aliases" node. The
+ alias is used to identify the timer instance in the driver.
+
+Example:
+
+aliases {
+ timer12 = &timer12;
+};
+
+timer12: timer@48304000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x48304000 0xfff>;
+ interrupts = <95>;
+ ti,hwmods = "timer12"
+ ti,timer-alwon;
+ ti,timer-secure;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8109471..f309f2a 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -12,12 +12,25 @@
/ {
compatible = "ti,omap3430", "ti,omap3";
+ interrupt-parent = <&intc>;
aliases {
serial0 = &uart1;
serial1 = &uart2;
serial2 = &uart3;
serial3 = &uart4;
+ timer1 = &timer1;
+ timer2 = &timer2;
+ timer3 = &timer3;
+ timer4 = &timer4;
+ timer5 = &timer5;
+ timer6 = &timer6;
+ timer7 = &timer7;
+ timer8 = &timer8;
+ timer9 = &timer9;
+ timer10 = &timer10;
+ timer11 = &timer11;
+ timer12 = &timer12;
};
cpus {
@@ -220,5 +233,96 @@
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
};
+
+ timer1: timer@48318000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x48318000 0xfff>;
+ interrupts = <37>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer@49032000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49032000 0xfff>;
+ interrupts = <38>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer@49034000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49034000 0xfff>;
+ interrupts = <39>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer@49036000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49036000 0xfff>;
+ interrupts = <40>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer@49038000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49038000 0xfff>;
+ interrupts = <41>;
+ ti,hwmods = "timer5";
+ };
+
+ timer6: timer@4903a000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x4903a000 0xfff>;
+
[RFC RESEND 0/4] ARM: OMAP3+: Add device-tree support for timers
This series adds device-tree support for the timers on OMAP3/4 devices. Once everyone is happy with the implementation I can add support for OMAP2/5 devices too. Testing: - I have tested the all the timers (not used by the kernel as sys-timers) on both OMAP3430 Beagle and OMAP4460 Panda with/without device-tree with this series. - The testing includes - Configuring, starting a timer and checking the counter value is incrementing. - Testing timer overflow interrupt when timer expires. - Using different clock sources to operate the timer with. - Using DT to provide resource information for IRQ and memory by removing Benoit's intention "HACK" in commit a4f6cdb0 (ARM: OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration) Jon Hunter (4): arm/dts: OMAP: Add timer nodes ARM: OMAP3: Dynamically disable secure timer nodes for secure devices ARM: OMAP4: Add timer clock aliases for device-tree ARM: OMAP: Add DT support for timer driver .../devicetree/bindings/arm/omap/timer.txt | 34 +++ arch/arm/boot/dts/omap3.dtsi | 104 arch/arm/boot/dts/omap4.dtsi | 93 + arch/arm/mach-omap2/board-generic.c|1 + arch/arm/mach-omap2/clock44xx_data.c | 12 +++ arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/timer.c| 40 arch/arm/plat-omap/dmtimer.c | 32 -- 8 files changed, 311 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC 3/4] ARM: OMAP4: Add timer clock aliases for device-tree
For OMAP4, the dmtimers are located in the Wake-up, ABE and Peripheral (PER)
power domains. Hence, when the dmtimer is configured to use the "timer_sys_ck"
as its functional clock the actual clock used is different depending on whether
the clock is in the Wake-up, ABE or PER domain. So when we look-up the dmtimer's
"timer_sys_ck" we need to specify the timer device name as well as clock alias
to find the right clock.
Currently, the device names for the timers have the format "omap_timer.X" where
X is the timer instance number. When using to device tree, the format of the
device name created by device-tree is different and has the format
"." (this is assuming that the device-tree "reg"
property is specified). This causes the look-up for the OMAP4 "timer_sys_ck" to
fail. To fix this add new timer clock alias for using device-tree.
Please note that adding a 2nd set of clock aliases for the same clocks to only
temporary until device-tree migration is complete. Then we can remove the legacy
aliases. Hence, I have marked the legacy aliases with a "TODO" to remove them.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/clock44xx_data.c | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index d7f55e4..7dfeaf0 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3314,6 +3314,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK("usbhs_omap", "usbtll_fck", &dummy_ck,
CK_443X),
CLK("omap_wdt", "ick", &dummy_ck,
CK_443X),
CLK(NULL, "timer_32k_ck", &sys_32k_ck,CK_443X),
+ /* TODO: Remove "omap_timer.X" aliases once DT migration is complete */
CLK("omap_timer.1", "timer_sys_ck", &sys_clkin_ck, CK_443X),
CLK("omap_timer.2", "timer_sys_ck", &sys_clkin_ck, CK_443X),
CLK("omap_timer.3", "timer_sys_ck", &sys_clkin_ck, CK_443X),
@@ -3325,6 +3326,17 @@ static struct omap_clk omap44xx_clks[] = {
CLK("omap_timer.6", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
CLK("omap_timer.7", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
CLK("omap_timer.8", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
+ CLK("4a318000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("48032000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("48034000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("48036000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("4803e000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("48086000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("48088000.timer", "timer_sys_ck", &sys_clkin_ck, CK_443X),
+ CLK("49038000.timer", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
+ CLK("4903a000.timer", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
+ CLK("4903c000.timer", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
+ CLK("4903e000.timer", "timer_sys_ck", &syc_clk_div_ck,
CK_443X),
};
int __init omap4xxx_clk_init(void)
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC 4/4] ARM: OMAP: Add DT support for dmtimer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. If DT blob is present, then let HWMOD create the timer devices dynamically.
2. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and the timer instance is looked-up using the
device tree alias mechanism. Therefore, avoid using "pdev-id" in the driver
and use "timer->id" which will be initialised correctly regardless of whether
device tree is present.
3. When device-tree is present the platform_data structure will be NULL and so
check for this.
4. The OMAP timer device tree binding optional parameters ...
a. ti,timer-alwon --> Timer is in an always-on power domain
b. ti,timer-pwn--> Timer can generate a PWM output
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |4
arch/arm/plat-omap/dmtimer.c | 32 ++--
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index e3b9931..ad5b29a 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -473,6 +473,10 @@ static int __init omap2_dm_timer_init(void)
{
int ret;
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
ret = omap_hwmod_for_each_by_class("timer", omap_timer_init, NULL);
if (unlikely(ret)) {
pr_err("%s: device registration failed.\n", __func__);
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 626ad8c..5a51b67 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -40,6 +40,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -123,7 +125,7 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
omap_dm_timer_enable(timer);
- if (timer->pdev->id != 1) {
+ if (timer->id != 1) {
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
omap_dm_timer_wait_for_reset(timer);
}
@@ -214,7 +216,7 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int id)
spin_lock_irqsave(&dm_timer_lock, flags);
list_for_each_entry(t, &omap_timer_list, node) {
- if (t->pdev->id == id && !t->reserved) {
+ if (t->id == id && !t->reserved) {
timer = t;
timer->reserved = 1;
break;
@@ -414,7 +416,7 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
* use the clock framework to set the parent clock. To be removed
* once OMAP1 migrated to using clock framework for dmtimers
*/
- if (pdata->set_timer_src)
+ if (pdata && pdata->set_timer_src)
return pdata->set_timer_src(timer->pdev, source);
fclk = clk_get(&timer->pdev->dev, "fck");
@@ -695,7 +697,7 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
struct device *dev = &pdev->dev;
struct dmtimer_platform_data *pdata = pdev->dev.platform_data;
- if (!pdata) {
+ if (!pdata && !dev->of_node) {
dev_err(dev, "%s: no platform data.\n", __func__);
return -ENODEV;
}
@@ -724,11 +726,21 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
return -ENOMEM;
}
- timer->id = pdev->id;
+ if (dev->of_node) {
+ timer->id = of_alias_get_id(dev->of_node, "timer");
+
+ if (of_find_property(dev->of_node, "ti,timer-alwon", NULL))
+ timer->capability |= OMAP_TIMER_ALWON;
+ if (of_find_property(dev->of_node, "ti,timer-pwm", NULL))
+ timer->capability |= OMAP_TIMER_HAS_PWM;
+ } else {
+ timer->id = pdev->id;
+ timer->capability = pdata->timer_capability;
+ }
+
timer->irq = irq->start;
timer->reserved = omap_dm_timer_reserved_systimer(timer->id);
timer->pdev = pdev;
- timer->capability = pdata->timer_capability;
/* Skip pm_runtime_enable for OMAP1 */
if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
@@ -778,11 +790,19 @@ static int __devexit omap_dm_timer_remove(struct
platform_device *pdev)
return ret;
}
+static const struct of_device_id omap_timer_match[] = {
+ { .compatible = "ti,omap3-timer", },
+ { .compatible = "ti,omap2-timer", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_timer_match);
+
static struct platform_driver omap_dm_timer_driver = {
.probe = omap_dm_timer_probe,
.remove = __devexit_p(omap_dm_timer_remo
[RFC 4/4] ARM: OMAP: Add DT support for timer driver
In order to add device-tree support to the timer driver the following changes
were made ...
1. If DT blob is present, then let HWMOD create the timer devices dynamically.
2. When device-tree is present the "id" field in the platform_device structure
(pdev->id) is initialised to -1 and the timer instance is looked-up using the
device tree alias mechanism. Therefore, avoid using "pdev-id" in the driver
and use "timer->id" which will be initialised correctly regardless of whether
device tree is present.
3. When device-tree is present the platform_data structure will be NULL and so
check for this.
4. The OMAP timer device tree binding optional parameters ...
a. ti,timer-alwon --> Timer is in an always-on power domain
b. ti,timer-pwn--> Timer can generate a PWM output
Search for the above parameters and set the appropriate timer attribute
flags.
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/timer.c |4
arch/arm/plat-omap/dmtimer.c | 32 ++--
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index e3b9931..ad5b29a 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -473,6 +473,10 @@ static int __init omap2_dm_timer_init(void)
{
int ret;
+ /* If dtb is there, the devices will be created dynamically */
+ if (of_have_populated_dt())
+ return -ENODEV;
+
ret = omap_hwmod_for_each_by_class("timer", omap_timer_init, NULL);
if (unlikely(ret)) {
pr_err("%s: device registration failed.\n", __func__);
diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c
index 626ad8c..5a51b67 100644
--- a/arch/arm/plat-omap/dmtimer.c
+++ b/arch/arm/plat-omap/dmtimer.c
@@ -40,6 +40,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -123,7 +125,7 @@ static void omap_dm_timer_wait_for_reset(struct
omap_dm_timer *timer)
static void omap_dm_timer_reset(struct omap_dm_timer *timer)
{
omap_dm_timer_enable(timer);
- if (timer->pdev->id != 1) {
+ if (timer->id != 1) {
omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG, 0x06);
omap_dm_timer_wait_for_reset(timer);
}
@@ -214,7 +216,7 @@ struct omap_dm_timer *omap_dm_timer_request_specific(int id)
spin_lock_irqsave(&dm_timer_lock, flags);
list_for_each_entry(t, &omap_timer_list, node) {
- if (t->pdev->id == id && !t->reserved) {
+ if (t->id == id && !t->reserved) {
timer = t;
timer->reserved = 1;
break;
@@ -414,7 +416,7 @@ int omap_dm_timer_set_source(struct omap_dm_timer *timer,
int source)
* use the clock framework to set the parent clock. To be removed
* once OMAP1 migrated to using clock framework for dmtimers
*/
- if (pdata->set_timer_src)
+ if (pdata && pdata->set_timer_src)
return pdata->set_timer_src(timer->pdev, source);
fclk = clk_get(&timer->pdev->dev, "fck");
@@ -695,7 +697,7 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
struct device *dev = &pdev->dev;
struct dmtimer_platform_data *pdata = pdev->dev.platform_data;
- if (!pdata) {
+ if (!pdata && !dev->of_node) {
dev_err(dev, "%s: no platform data.\n", __func__);
return -ENODEV;
}
@@ -724,11 +726,21 @@ static int __devinit omap_dm_timer_probe(struct
platform_device *pdev)
return -ENOMEM;
}
- timer->id = pdev->id;
+ if (dev->of_node) {
+ timer->id = of_alias_get_id(dev->of_node, "timer");
+
+ if (of_find_property(dev->of_node, "ti,timer-alwon", NULL))
+ timer->capability |= OMAP_TIMER_ALWON;
+ if (of_find_property(dev->of_node, "ti,timer-pwm", NULL))
+ timer->capability |= OMAP_TIMER_HAS_PWM;
+ } else {
+ timer->id = pdev->id;
+ timer->capability = pdata->timer_capability;
+ }
+
timer->irq = irq->start;
timer->reserved = omap_dm_timer_reserved_systimer(timer->id);
timer->pdev = pdev;
- timer->capability = pdata->timer_capability;
/* Skip pm_runtime_enable for OMAP1 */
if (!(timer->capability & OMAP_TIMER_NEEDS_RESET)) {
@@ -778,11 +790,19 @@ static int __devexit omap_dm_timer_remove(struct
platform_device *pdev)
return ret;
}
+static const struct of_device_id omap_timer_match[] = {
+ { .compatible = "ti,omap3-timer", },
+ { .compatible = "ti,omap2-timer", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_timer_match);
+
static struct platform_driver omap_dm_timer_driver = {
.probe = omap_dm_timer_probe,
.remove = __devexit_p(omap_dm_timer_remo
[RFC 2/4] ARM: OMAP3: Dynamically disable secure timer nodes for secure devices
OMAP3 devices may or may not have security features enabled. Security enabled
devices are known as high-secure (HS) and devices without security are known as
general purpose (GP).
For OMAP3 devices there are 12 general purpose timers available. On secure
devices the 12th timer is reserved for secure usage and so cannot be used by
the kernel, where as for a GP device it is available. We can detect the OMAP
device type, secure or GP, at runtime via an on-chip register. Today, when not
using DT, we do not register the 12th timer as a linux device if the device is
secure.
When using device tree, device tree is going to register all the timer devices
it finds in the device tree blob. To prevent device tree from registering 12th
timer on a secure OMAP3 device we can add a status property to the timer
binding with the value "disabled" at boot time. Note that timer 12 on a OMAP3
device has a property "ti,timer-secure" to indicate that it will not be
available on a secure device and so for secure OMAP3 devices, we search for
timers with this property and then disable them. Using the prom_add_property()
function to dynamically add a property was a recommended approach suggested by
Rob Herring [1].
I have tested this on an OMAP3 GP device and faking it to pretend to be a
secure device to ensure that any timers marked with "ti,timer-secure" are not
registered on boot. I have also made sure that all timers are registered as
expected on a GP device by default.
[1] http://comments.gmane.org/gmane.linux.ports.arm.omap/79203
Signed-off-by: Jon Hunter
---
arch/arm/mach-omap2/board-generic.c |1 +
arch/arm/mach-omap2/common.h|1 +
arch/arm/mach-omap2/timer.c | 36 +++
3 files changed, 38 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 6f93a20..20124d7 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -40,6 +40,7 @@ static struct of_device_id omap_dt_match_table[] __initdata =
{
static void __init omap_generic_init(void)
{
omap_sdrc_init(NULL, NULL);
+ omap_dmtimer_init();
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
}
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 1f65b18..d6a4875 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -326,6 +326,7 @@ extern void omap_sdrc_init(struct omap_sdrc_params
*sdrc_cs0,
struct omap_sdrc_params *sdrc_cs1);
struct omap2_hsmmc_info;
extern int omap4_twl6030_hsmmc_init(struct omap2_hsmmc_info *controllers);
+extern void omap_dmtimer_init(void);
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 13d20c8..e3b9931 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -36,6 +36,7 @@
#include
#include
#include
+#include
#include
#include
@@ -482,6 +483,41 @@ static int __init omap2_dm_timer_init(void)
}
arch_initcall(omap2_dm_timer_init);
+static struct property timer_disabled = {
+ .name = "status",
+ .length = sizeof("disabled"),
+ .value = "disabled",
+};
+
+static struct of_device_id omap3_timer_match[] __initdata = {
+ { .compatible = "ti,omap3-timer", },
+ { }
+};
+
+/**
+ * omap_dmtimer_init - initialisation function when device tree is used
+ *
+ * For secure OMAP3 devices, timers with device type "timer-secure" cannot
+ * be used by the kernel as they are reserved. Therefore, to prevent the
+ * kernel registering these devices remove them dynamically from the device
+ * tree on boot.
+ */
+void __init omap_dmtimer_init(void)
+{
+ struct device_node *np;
+
+ if (!cpu_is_omap34xx())
+ return;
+
+ /* If we are a secure device, remove any secure timer nodes */
+ if ((omap_type() != OMAP2_DEVICE_TYPE_GP)) {
+ for_each_matching_node(np, omap3_timer_match) {
+ if (of_get_property(np, "ti,timer-secure", NULL))
+ prom_add_property(np, &timer_disabled);
+ }
+ }
+}
+
/**
* omap2_override_clocksource - clocksource override with user configuration
*
--
1.7.9.5
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC 1/4] arm/dts: OMAP: Add timer nodes
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add documentation for timer properties specific to OMAP.
For each timer an alias is being added. The purpose for doing this is because
the OMAP dmtimer driver uses an ID to distinguish between the different timer
instances. For example, a timer can be requested by its ID. By adding an alias
for each timer we can then use the function of_alias_get_id() to extract the
ID for each timer from the alias name. The same method is used for the TTY
serial devices. If it is preferred that such an alias is not added and there
is a better way to pass an ID from device-tree let me know.
Cc: Benoit Cousson
Signed-off-by: Jon Hunter
---
.../devicetree/bindings/arm/omap/timer.txt | 34 +++
arch/arm/boot/dts/omap3.dtsi | 104
arch/arm/boot/dts/omap4.dtsi | 93 +
3 files changed, 231 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
b/Documentation/devicetree/bindings/arm/omap/timer.txt
new file mode 100644
index 000..dcbb451
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -0,0 +1,34 @@
+OMAP Timer controller bindings
+
+Required properties:
+- compatible:
+ - "ti,omap3-timer" for OMAP3+ controllers
+- reg: Contains timer register address range (base address and length)
+- interrupts: Contains the interrupt information for the timer. The format is
+ being dependent on which interrupt controller the OMAP device uses.
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the timer:
+ "timer", being the 1-based instance number from the HW spec
+- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
+- ti,timer-pwm: Indicates the timer supports can generate PWM output.
+- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device and
+ therefore cannot be used by the kernel.
+
+Note: Each timer should have an alias correctly numbered in "aliases" node. The
+ alias is used to identify the timer instance in the driver.
+
+Example:
+
+aliases {
+ timer12 = &timer12;
+};
+
+timer12: timer@48304000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x48304000 0xfff>;
+ interrupts = <95>;
+ ti,hwmods = "timer12"
+ ti,timer-alwon;
+ ti,timer-secure;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8109471..f309f2a 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -12,12 +12,25 @@
/ {
compatible = "ti,omap3430", "ti,omap3";
+ interrupt-parent = <&intc>;
aliases {
serial0 = &uart1;
serial1 = &uart2;
serial2 = &uart3;
serial3 = &uart4;
+ timer1 = &timer1;
+ timer2 = &timer2;
+ timer3 = &timer3;
+ timer4 = &timer4;
+ timer5 = &timer5;
+ timer6 = &timer6;
+ timer7 = &timer7;
+ timer8 = &timer8;
+ timer9 = &timer9;
+ timer10 = &timer10;
+ timer11 = &timer11;
+ timer12 = &timer12;
};
cpus {
@@ -220,5 +233,96 @@
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
};
+
+ timer1: timer@48318000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x48318000 0xfff>;
+ interrupts = <37>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer@49032000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49032000 0xfff>;
+ interrupts = <38>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer@49034000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49034000 0xfff>;
+ interrupts = <39>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer@49036000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49036000 0xfff>;
+ interrupts = <40>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer@49038000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49038000 0xfff>;
+ interrupts = <41>;
+ ti,hwmods = "timer5";
+ };
+
+ timer6: timer@4903a000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x4903a000 0xfff>;
+
[RFC 1/4] arm/dts: OMAP: Add genernal purpose timer nodes
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add documentation for timer properties specific to OMAP.
For each timer an alias is being added. The purpose for doing this is because
the OMAP dmtimer driver uses an ID to distinguish between the different timer
instances. For example, a timer can be requested by its ID. By adding an alias
for each timer we can then use the function of_alias_get_id() to extract the
ID for each timer from the alias name. The same method is used for the TTY
serial devices. If it is preferred that such an alias is not added and there
is a better way to pass an ID from device-tree let me know.
Cc: Benoit Cousson
Signed-off-by: Jon Hunter
---
.../devicetree/bindings/arm/omap/timer.txt | 34 +++
arch/arm/boot/dts/omap3.dtsi | 104
arch/arm/boot/dts/omap4.dtsi | 93 +
3 files changed, 231 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
b/Documentation/devicetree/bindings/arm/omap/timer.txt
new file mode 100644
index 000..dcbb451
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -0,0 +1,34 @@
+OMAP Timer controller bindings
+
+Required properties:
+- compatible:
+ - "ti,omap3-timer" for OMAP3+ controllers
+- reg: Contains timer register address range (base address and length)
+- interrupts: Contains the interrupt information for the timer. The format is
+ being dependent on which interrupt controller the OMAP device uses.
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the timer:
+ "timer", being the 1-based instance number from the HW spec
+- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
+- ti,timer-pwm: Indicates the timer supports can generate PWM output.
+- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device and
+ therefore cannot be used by the kernel.
+
+Note: Each timer should have an alias correctly numbered in "aliases" node. The
+ alias is used to identify the timer instance in the driver.
+
+Example:
+
+aliases {
+ timer12 = &timer12;
+};
+
+timer12: timer@48304000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x48304000 0xfff>;
+ interrupts = <95>;
+ ti,hwmods = "timer12"
+ ti,timer-alwon;
+ ti,timer-secure;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8109471..f309f2a 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -12,12 +12,25 @@
/ {
compatible = "ti,omap3430", "ti,omap3";
+ interrupt-parent = <&intc>;
aliases {
serial0 = &uart1;
serial1 = &uart2;
serial2 = &uart3;
serial3 = &uart4;
+ timer1 = &timer1;
+ timer2 = &timer2;
+ timer3 = &timer3;
+ timer4 = &timer4;
+ timer5 = &timer5;
+ timer6 = &timer6;
+ timer7 = &timer7;
+ timer8 = &timer8;
+ timer9 = &timer9;
+ timer10 = &timer10;
+ timer11 = &timer11;
+ timer12 = &timer12;
};
cpus {
@@ -220,5 +233,96 @@
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
};
+
+ timer1: timer@48318000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x48318000 0xfff>;
+ interrupts = <37>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer@49032000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49032000 0xfff>;
+ interrupts = <38>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer@49034000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49034000 0xfff>;
+ interrupts = <39>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer@49036000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49036000 0xfff>;
+ interrupts = <40>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer@49038000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49038000 0xfff>;
+ interrupts = <41>;
+ ti,hwmods = "timer5";
+ };
+
+ timer6: timer@4903a000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x4903a000 0xfff>;
+
[RFC 0/4] ARM: OMAP3+: Add device-tree support for timers
This series adds device-tree support for the timers on OMAP3/4 devices. Once everyone is happy with the implementation I can add support for OMAP2/5 devices too. Testing: - I have tested the all the timers (not used by the kernel as sys-timers) on both OMAP3430 Beagle and OMAP4460 Panda with/without device-tree with this series. - The testing includes - Configuring, starting a timer and checking the counter value is incrementing. - Testing timer overflow interrupt when timer expires. - Using different clock sources to operate the timer with. - Using DT to provide resource information for IRQ and memory by removing Benoit's intention "HACK" in commit a4f6cdb0 (ARM: OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration) Jon Hunter (4): arm/dts: OMAP: Add timer nodes ARM: OMAP3: Dynamically disable secure timer nodes for secure devices ARM: OMAP4: Add timer clock aliases for device-tree ARM: OMAP: Add DT support for timer driver .../devicetree/bindings/arm/omap/timer.txt | 34 +++ arch/arm/boot/dts/omap3.dtsi | 104 arch/arm/boot/dts/omap4.dtsi | 93 + arch/arm/mach-omap2/board-generic.c|1 + arch/arm/mach-omap2/clock44xx_data.c | 12 +++ arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/timer.c| 40 arch/arm/plat-omap/dmtimer.c | 32 -- 8 files changed, 311 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
[RFC 1/4] arm/dts: OMAP: Add genernal purpose timer nodes
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add documentation for timer properties specific to OMAP.
For each timer an alias is being added. The purpose for doing this is because
the OMAP dmtimer driver uses an ID to distinguish between the different timer
instances. For example, a timer can be requested by its ID. By adding an alias
for each timer we can then use the function of_alias_get_id() to extract the
ID for each timer from the alias name. The same method is used for the TTY
serial devices. If it is preferred that such an alias is not added and there
is a better way to pass an ID from device-tree let me know.
Cc: Benoit Cousson
Signed-off-by: Jon Hunter
---
.../devicetree/bindings/arm/omap/timer.txt | 34 +++
arch/arm/boot/dts/omap3.dtsi | 104
arch/arm/boot/dts/omap4.dtsi | 93 +
3 files changed, 231 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
b/Documentation/devicetree/bindings/arm/omap/timer.txt
new file mode 100644
index 000..dcbb451
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -0,0 +1,34 @@
+OMAP Timer controller bindings
+
+Required properties:
+- compatible:
+ - "ti,omap3-timer" for OMAP3+ controllers
+- reg: Contains timer register address range (base address and length)
+- interrupts: Contains the interrupt information for the timer. The format is
+ being dependent on which interrupt controller the OMAP device uses.
+
+OMAP specific properties:
+- ti,hwmods: Name of the hwmod associated to the timer:
+ "timer", being the 1-based instance number from the HW spec
+- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
+- ti,timer-pwm: Indicates the timer supports can generate PWM output.
+- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device and
+ therefore cannot be used by the kernel.
+
+Note: Each timer should have an alias correctly numbered in "aliases" node. The
+ alias is used to identify the timer instance in the driver.
+
+Example:
+
+aliases {
+ timer12 = &timer12;
+};
+
+timer12: timer@48304000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x48304000 0xfff>;
+ interrupts = <95>;
+ ti,hwmods = "timer12"
+ ti,timer-alwon;
+ ti,timer-secure;
+};
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8109471..f309f2a 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -12,12 +12,25 @@
/ {
compatible = "ti,omap3430", "ti,omap3";
+ interrupt-parent = <&intc>;
aliases {
serial0 = &uart1;
serial1 = &uart2;
serial2 = &uart3;
serial3 = &uart4;
+ timer1 = &timer1;
+ timer2 = &timer2;
+ timer3 = &timer3;
+ timer4 = &timer4;
+ timer5 = &timer5;
+ timer6 = &timer6;
+ timer7 = &timer7;
+ timer8 = &timer8;
+ timer9 = &timer9;
+ timer10 = &timer10;
+ timer11 = &timer11;
+ timer12 = &timer12;
};
cpus {
@@ -220,5 +233,96 @@
compatible = "ti,omap3-wdt";
ti,hwmods = "wd_timer2";
};
+
+ timer1: timer@48318000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x48318000 0xfff>;
+ interrupts = <37>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer@49032000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49032000 0xfff>;
+ interrupts = <38>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer@49034000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49034000 0xfff>;
+ interrupts = <39>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer@49036000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49036000 0xfff>;
+ interrupts = <40>;
+ ti,hwmods = "timer4";
+ };
+
+ timer5: timer@49038000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x49038000 0xfff>;
+ interrupts = <41>;
+ ti,hwmods = "timer5";
+ };
+
+ timer6: timer@4903a000 {
+ compatible = "ti,omap3-timer";
+ reg = <0x4903a000 0xfff>;
+
[RFC 0/4] ARM: OMAP3+: Add device-tree support for dmtimers
This series adds device-tree support for the dmtimers on OMAP3/4 devices. Once everyone is happy with the implementation I can add support for OMAP2/5 devices too. Testing: - I have tested the all the dmtimers (not used by the kernel as sys-timers) on both OMAP3430 Beagle and OMAP4460 Panda with/without device-tree with this series. - The testing includes - Configuring, starting a timer and checking the counter value is incrementing. - Testing timer overflow interrupt when timer expires. - Using different clock sources to operate the timer with. - Using DT to provide resource information for IRQ and memory by removing Benoit's intention "HACK" in commit a4f6cdb0 (ARM: OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration) Jon Hunter (4): arm/dts: OMAP: Add genernal purpose timer nodes ARM: OMAP3: Dynamically disable secure timer nodes for secure devices ARM: OMAP4: Add timer clock aliases for device-tree ARM: OMAP: Add DT support for dmtimer driver .../devicetree/bindings/arm/omap/timer.txt | 34 +++ arch/arm/boot/dts/omap3.dtsi | 104 arch/arm/boot/dts/omap4.dtsi | 93 + arch/arm/mach-omap2/board-generic.c|1 + arch/arm/mach-omap2/clock44xx_data.c | 12 +++ arch/arm/mach-omap2/common.h |1 + arch/arm/mach-omap2/timer.c| 40 arch/arm/plat-omap/dmtimer.c | 32 -- 8 files changed, 311 insertions(+), 6 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt -- 1.7.9.5 ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
Hi Vinod On Fri, 13 Jul 2012, Vinod Koul wrote: > On Wed, 2012-06-27 at 15:20 +, Arnd Bergmann wrote: [snip] > > Do you mean there must be a global table, or are you ok with putting > > the information about a channel into the device that uses the channel, > > as we do for most other subsystems (IRQ, GPIO, pinctrl, ...). > > If not, what is the problem with that approach? > > Today, we simple ask, "give me dma channel with DMA_SLAVE capability". > > If we change it to "give me dma channel which suits my need" and have > additional information in dmaengine to handle this request effectively. > > What that would mean is > a) DMA channel either knows which channel to provide, Or > b) Additional arguments provided to dmaengine API to help it find out > which channel to provide. > > It would be good to have client ask for a specific channel. But in order > to build generic clients, we face a problem that clients may not know > how they mapped to dmac by SoC designer. Or the mux maybe entirely > flexible on which channel. > > If we add this as DT property (which I assume should be platform > specific), then client will know which channel to request. > It can have two levels, dmac and channel. In case mux is flexible enough > then client gets a channel and program the mux for this mapping. > > I think this is the most simplistic solution I have for this, thoughts? How about this my idea: http://thread.gmane.org/gmane.linux.ports.arm.omap/75828/focus=15501 A small correction to it would be, that it shouldn't (necessarily) be a separate driver, because in some cases the mux resides on the DMAC, they share registers, so, it shouldn't really be a separate device and a separate driver, don't think it's worth an MFD set up or anything similar. So, I am trying ATM to implement something along the lines of struct dma_chan *dma_request_slave_channel(struct device *dev, enum dma_transfer_direction direction, const char *name); The connection between clients and the mux is always static, so, the dmaengine core can always just pass to the mux a client-side "pad" specifier (dev + direction + (optionally) name). The mux call-back will then see, where it can connect that pad and return a suitable channel descriptor - possibly with the help of the DMAC driver proper. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/11] make struct of_device_id.data const
On 07/13/2012 12:49 PM, Uwe Kleine-König wrote: [snip] > I guess this results in a warning until after patch 10 is applied? (A > few more down below.) > > In the meantime I expanded my defconfig build script to handle powerpc, > too. I'll check these. I think I'll have to let the build run over > night... I'm not certain but just an allyesconfig build on powerpc should be sufficient rather than building defconfigs. We still dream about doing that on ARM. Rob ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/11] make struct of_device_id.data const
On Fri, Jul 13, 2012 at 6:41 AM, Rob Herring wrote: > On 07/13/2012 07:32 AM, y...@pengutronix.de wrote: >> From: Uwe Kleine-König >> >> Hello, >> >> this series' goal is to make struct of_device_id.data const. >> Conceptually a driver must not modify the data contained there so making >> it const is the right thing. >> >> This change might introduce warnings because drivers don't use const to >> access the data pointed to by of_device_id.data. In most cases the fix >> is to add some consts. >> >> This series (apart from adding this const in patch 10) fixes all drivers >> covered by all arm defconfigs (based on v3.5-rc6). >> > > What about other arches? This whole series is of questionable value to me. While I agree that .data should be const, I don't think changing it has is measurably better than what we have now. Particularly when the series isn't complete for all users. And "building all defconfigs" is not the right way to look for affected users. g. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/11] make struct of_device_id.data const
On Friday 13 July 2012, Uwe Kleine-König wrote:
> > @@ -502,15 +502,15 @@ static const struct fsl_msi_feature vmpic_msi_feature
> > = {
> > static const struct of_device_id fsl_of_msi_ids[] = {
> > {
> > .compatible = "fsl,mpic-msi",
> > - .data = (void *)&mpic_msi_feature,
> > + .data = &mpic_msi_feature,
> This looks unrelated.
>
Well, the cast to (void *) was used to cast away the const-ness of the
"static const struct fsl_msi_feature mpic_msi_feature", so that is no
longer needed after the last patch.
Arnd.
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/11] make struct of_device_id.data const
Hello,
On Fri, Jul 13, 2012 at 04:24:26PM +, Arnd Bergmann wrote:
> On Friday 13 July 2012, Uwe Kleine-König wrote:
> > On Fri, Jul 13, 2012 at 07:41:02AM -0500, Rob Herring wrote:
> > > On 07/13/2012 07:32 AM, y...@pengutronix.de wrote:
> > > > From: Uwe Kleine-König
> > > >
> > > > this series' goal is to make struct of_device_id.data const.
> > > > Conceptually a driver must not modify the data contained there so making
> > > > it const is the right thing.
> > > >
> > > > This change might introduce warnings because drivers don't use const to
> > > > access the data pointed to by of_device_id.data. In most cases the fix
> > > > is to add some consts.
> > > >
> > > > This series (apart from adding this const in patch 10) fixes all drivers
> > > > covered by all arm defconfigs (based on v3.5-rc6).
> > > >
> > >
> > > What about other arches?
> >
> > I didn't looked at them, mainly because I don't have the scripts for
> > arches other than arm to do such testing. Also note that it introduces
> > only some warnings, but no breakage. So adding the const in the merge
> > window might be ok?!
>
> I think it makes sense to change the drivers that are easy to find now:
>
> git grep -A6 of_device_id | grep '\.*=' | brain
>
> arch/c6x/platforms/plldata.c- { .compatible = "ti,c6455-pll", .data =
> c6455_setup_clocks },
> arch/mips/lantiq/irq.c- { .compatible = "lantiq,icu", .data = icu_of_init },
> arch/powerpc/platforms/83xx/suspend.c- .data = &pmc_types[0],
> arch/powerpc/platforms/cell/celleb_pci.c- .data =
> &celleb_fake_pci_spec,
> arch/powerpc/platforms/cell/celleb_pci.c- .data =
> &celleb_epci_spec,
> arch/powerpc/sysdev/fsl_msi.c- .data = (void *)&mpic_msi_feature,
> drivers/atm/fore200e.c- .data = (void *) &fore200e_bus[1],
> drivers/char/xilinx_hwicap/xilinx_hwicap.c- { .compatible =
> "xlnx,opb-hwicap-1.00.b", .data = &buffer_icap_config},
> drivers/i2c/busses/i2c-mpc.c- {.compatible = "mpc5200-i2c", .data =
> &mpc_i2c_data_52xx, },
> drivers/macintosh/mediabay.c- .data = &keylargo_mb_ops,
> drivers/mfd/da9052-i2c.c- { .compatible = "dlg,da9053-aa", .data =
> &da9052_i2c_id[1] },
> drivers/net/can/mscan/mpc5xxx_can.c-{ .compatible = "fsl,mpc5200-mscan",
> .data = &mpc5200_can_data, },
> drivers/scsi/qlogicpti.c- .data = &qpti_template,
> drivers/usb/host/fsl-mph-dr-of.c- { .compatible = "fsl-usb2-mph", .data
> = &fsl_usb2_mpc8xxx_pd, },
> drivers/watchdog/mpc8xxx_wdt.c- .data = &(struct mpc8xxx_wdt_type) {
>
> I'm optimistic that this list covers the vast majority of the non-ARM
> drivers, and some of them don't even need any changes. I've done
> patches for the others below.
>
> Signed-off-by: Arnd Bergmann
> ---
> arch/powerpc/platforms/83xx/suspend.c|2 +-
> arch/powerpc/platforms/cell/celleb_pci.c |2 +-
> arch/powerpc/sysdev/fsl_msi.c|8
> drivers/i2c/busses/i2c-mpc.c | 12 ++--
> drivers/macintosh/mediabay.c |8
> drivers/mfd/da9052-i2c.c |4 ++--
> drivers/net/can/mscan/mpc5xxx_can.c |6 +++---
> drivers/scsi/qlogicpti.c |2 +-
> drivers/watchdog/mpc8xxx_wdt.c |2 +-
> 10 files changed, 23 insertions(+), 26 deletions(-)
>
> diff --git a/arch/powerpc/platforms/83xx/suspend.c
> b/arch/powerpc/platforms/83xx/suspend.c
> index 1a04671..1d769a2 100644
> --- a/arch/powerpc/platforms/83xx/suspend.c
> +++ b/arch/powerpc/platforms/83xx/suspend.c
> @@ -326,7 +326,7 @@ static int pmc_probe(struct platform_device *ofdev)
> const struct of_device_id *match;
> struct device_node *np = ofdev->dev.of_node;
> struct resource res;
> - struct pmc_type *type;
> + const struct pmc_type *type;
> int ret = 0;
>
> match = of_match_device(pmc_match, &ofdev->dev);
> diff --git a/arch/powerpc/platforms/cell/celleb_pci.c
> b/arch/powerpc/platforms/cell/celleb_pci.c
> index 5822141..abc8af4 100644
> --- a/arch/powerpc/platforms/cell/celleb_pci.c
> +++ b/arch/powerpc/platforms/cell/celleb_pci.c
> @@ -472,7 +472,7 @@ int __init celleb_setup_phb(struct pci_controller *phb)
> {
> struct device_node *dev = phb->dn;
> const struct of_device_id *match;
> - struct celleb_phb_spec *phb_spec;
> + const struct celleb_phb_spec *phb_spec;
> int rc;
>
> match = of_match_node(celleb_phb_match, dev);
> diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
> index 6e097de..51ffafa 100644
> --- a/arch/powerpc/sysdev/fsl_msi.c
> +++ b/arch/powerpc/sysdev/fsl_msi.c
> @@ -368,7 +368,7 @@ static int __devinit fsl_of_msi_probe(struct
> platform_device *dev)
> int err, i, j, irq_index, count;
> int rc;
> const u32 *p;
> - struct fsl_msi_feature *features;
> + const struct fsl_msi_feature *features;
> int len;
> u32 offset;
> st
Re: [PATCH 00/11] make struct of_device_id.data const
On Friday 13 July 2012, Uwe Kleine-König wrote:
> On Fri, Jul 13, 2012 at 07:41:02AM -0500, Rob Herring wrote:
> > On 07/13/2012 07:32 AM, y...@pengutronix.de wrote:
> > > From: Uwe Kleine-König
> > >
> > > this series' goal is to make struct of_device_id.data const.
> > > Conceptually a driver must not modify the data contained there so making
> > > it const is the right thing.
> > >
> > > This change might introduce warnings because drivers don't use const to
> > > access the data pointed to by of_device_id.data. In most cases the fix
> > > is to add some consts.
> > >
> > > This series (apart from adding this const in patch 10) fixes all drivers
> > > covered by all arm defconfigs (based on v3.5-rc6).
> > >
> >
> > What about other arches?
>
> I didn't looked at them, mainly because I don't have the scripts for
> arches other than arm to do such testing. Also note that it introduces
> only some warnings, but no breakage. So adding the const in the merge
> window might be ok?!
I think it makes sense to change the drivers that are easy to find now:
git grep -A6 of_device_id | grep '\.*=' | brain
arch/c6x/platforms/plldata.c- { .compatible = "ti,c6455-pll", .data =
c6455_setup_clocks },
arch/mips/lantiq/irq.c- { .compatible = "lantiq,icu", .data = icu_of_init },
arch/powerpc/platforms/83xx/suspend.c- .data = &pmc_types[0],
arch/powerpc/platforms/cell/celleb_pci.c- .data =
&celleb_fake_pci_spec,
arch/powerpc/platforms/cell/celleb_pci.c- .data =
&celleb_epci_spec,
arch/powerpc/sysdev/fsl_msi.c- .data = (void *)&mpic_msi_feature,
drivers/atm/fore200e.c- .data = (void *) &fore200e_bus[1],
drivers/char/xilinx_hwicap/xilinx_hwicap.c- { .compatible =
"xlnx,opb-hwicap-1.00.b", .data = &buffer_icap_config},
drivers/i2c/busses/i2c-mpc.c- {.compatible = "mpc5200-i2c", .data =
&mpc_i2c_data_52xx, },
drivers/macintosh/mediabay.c- .data = &keylargo_mb_ops,
drivers/mfd/da9052-i2c.c- { .compatible = "dlg,da9053-aa", .data =
&da9052_i2c_id[1] },
drivers/net/can/mscan/mpc5xxx_can.c-{ .compatible = "fsl,mpc5200-mscan",
.data = &mpc5200_can_data, },
drivers/scsi/qlogicpti.c- .data = &qpti_template,
drivers/usb/host/fsl-mph-dr-of.c- { .compatible = "fsl-usb2-mph", .data =
&fsl_usb2_mpc8xxx_pd, },
drivers/watchdog/mpc8xxx_wdt.c- .data = &(struct mpc8xxx_wdt_type) {
I'm optimistic that this list covers the vast majority of the non-ARM
drivers, and some of them don't even need any changes. I've done
patches for the others below.
Signed-off-by: Arnd Bergmann
---
arch/powerpc/platforms/83xx/suspend.c|2 +-
arch/powerpc/platforms/cell/celleb_pci.c |2 +-
arch/powerpc/sysdev/fsl_msi.c|8
drivers/i2c/busses/i2c-mpc.c | 12 ++--
drivers/macintosh/mediabay.c |8
drivers/mfd/da9052-i2c.c |4 ++--
drivers/net/can/mscan/mpc5xxx_can.c |6 +++---
drivers/scsi/qlogicpti.c |2 +-
drivers/watchdog/mpc8xxx_wdt.c |2 +-
10 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/arch/powerpc/platforms/83xx/suspend.c
b/arch/powerpc/platforms/83xx/suspend.c
index 1a04671..1d769a2 100644
--- a/arch/powerpc/platforms/83xx/suspend.c
+++ b/arch/powerpc/platforms/83xx/suspend.c
@@ -326,7 +326,7 @@ static int pmc_probe(struct platform_device *ofdev)
const struct of_device_id *match;
struct device_node *np = ofdev->dev.of_node;
struct resource res;
- struct pmc_type *type;
+ const struct pmc_type *type;
int ret = 0;
match = of_match_device(pmc_match, &ofdev->dev);
diff --git a/arch/powerpc/platforms/cell/celleb_pci.c
b/arch/powerpc/platforms/cell/celleb_pci.c
index 5822141..abc8af4 100644
--- a/arch/powerpc/platforms/cell/celleb_pci.c
+++ b/arch/powerpc/platforms/cell/celleb_pci.c
@@ -472,7 +472,7 @@ int __init celleb_setup_phb(struct pci_controller *phb)
{
struct device_node *dev = phb->dn;
const struct of_device_id *match;
- struct celleb_phb_spec *phb_spec;
+ const struct celleb_phb_spec *phb_spec;
int rc;
match = of_match_node(celleb_phb_match, dev);
diff --git a/arch/powerpc/sysdev/fsl_msi.c b/arch/powerpc/sysdev/fsl_msi.c
index 6e097de..51ffafa 100644
--- a/arch/powerpc/sysdev/fsl_msi.c
+++ b/arch/powerpc/sysdev/fsl_msi.c
@@ -368,7 +368,7 @@ static int __devinit fsl_of_msi_probe(struct
platform_device *dev)
int err, i, j, irq_index, count;
int rc;
const u32 *p;
- struct fsl_msi_feature *features;
+ const struct fsl_msi_feature *features;
int len;
u32 offset;
static const u32 all_avail[] = { 0, NR_MSI_IRQS };
@@ -502,15 +502,15 @@ static const struct fsl_msi_feature vmpic_msi_feature = {
static const struct of_device_id fsl_of_msi_ids[] = {
{
.compatible = "fsl,mpic-msi",
-
Re: [RFC] media DT bindings
Hi,
Cc: devicetree-dissc...@lists.ozlabs.org
On 07/11/2012 04:27 PM, Guennadi Liakhovetski wrote:
> Hi all
>
> Background
> ==
>
> With ARM adoption of flat Device Trees a need arises to move platform
> device descriptions and their data from platform files to DT. This has
> also to be done for media devices, e.g., video capture and output
> interfaces, data processing devices, camera sensors, TV decoders and
> encoders. This RFC is trying to spawn a discussion to define standard V4L
> DT bindings. The first version will concentrate on the capture path,
> mostly taking care of simple capture-interface - camera sensor / TV
> decoder configurations. Since the author is not working intensively yet
> with the Media Controller API, pad-level configuration, these topics might
> be underrepresented in this RFC. I hope others, actively working in these
> areas, will fill me in on them.
We've done some work on device tree support for SoC camera interface
with driver based on the Media Controller API, I've posted some RFC
patches a few weeks ago:
http://www.mail-archive.com/devicetree-discuss@lists.ozlabs.org/msg14769.html
But unfortunately didn't receive any comments, perhaps because the actual
bindings were not abstracted enough from a specific hardware support.
An updated version of these patch set can be found here:
https://github.com/snawrocki/linux/commits/camera-of-2
Of course we shouldn't be forgetting that underlying bindings need to
be the same, regardless of the drivers are based on soc_camera, Media
Controller/subdev pad-level frameworks, or something else. Anything
linux specific in the bindings would be inappropriate.
> Overview
>
>
> As mentioned above, typical configurations, that we'll be dealing with
> consist of a DMA data capture engine, one or more data sources like camera
> sensors, possibly some data processing units. Data capture and processing
> engines are usually platform devices, whereas data source devices are
> typically I2C slaves. Apart from defining each device we'll also describe
> connections between them as well as properties of those connections.
>
> Capture devices
> ==
>
> These are usually platform devices, integrated into respective SoCs. There
> also exist external image processing devices, but they are rare. Obvious
> differences between them and integrated devices include a different bus
> attribution and a need to explicitly describe the connection to the SoC.
> As far as capture devices are concerned, their configuration will
> typically include a few device-specific bindings, as well as standard
> ones. Standard bindings will include the usual "reg," "interrupts,"
> "clock-frequency" properties.
>
> It is more complex to describe external links. We need to describe
> configurations, used with various devices, attached to various pads. It is
> proposed to describe such links as child nodes. Each such link will
> reference a client pad, a local pad and specify the bus configuration. The
> media bus can be either parallel or serial, e.g., MIPI CSI-2. It is
> proposed to describe both the bus-width in the parallel case and the
> number of lanes in the serial case, using the standard "bus-width"
> property.
>
> On the parallel bus common properties include signal polarities, possibly
> data line shift (8 if lines 15:8 are used, 2 if 9:2, and 0 if lines 7:0),
> protocol (e.g., BT.656). Additionally device-specific properties can be
> defined.
>
> A MIPI CSI-2 bus common properties would include, apart from the number of
> lanes, routed to that client, the clock frequency, a channel number,
> possibly CRC and ECC flags.
>
> An sh-mobile CEU DT node could look like
>
> ceu0@0xfe91 = {
> compatible = "renesas,sh-mobile-ceu";
> reg =<0xfe91 0xa0>;
> interrupts =<0x880>;
> bus-width =<16>;/* #lines routed on the board */
> clock-frequency =<5000>;/* max clock */
> #address-cells =<1>;
> #size-cells =<0>;
> ...
> ov772x-1 = {
> reg =<0>;
> client =<&ov772x@0x21-0>;
> local-pad = "parallel-sink";
> remote-pad = "parallel-source";
I'm not sure I like that. Is it really needed when we already have
the child/parent properties around ?
> bus-width =<8>; /* used data lines */
> data-shift =<0>;/* lines 7:0 are used */
> hsync-active =<1>; /* active high */
> vsync-active =<1>; /* active high */
In the end I took a bit different approach, similar to how the interrupt
flag bindings are defined:
https://github.com/snawrocki/linux/commit/c17a61a07008eeb8faea0205f7cc440545641adb
However using a separate boolean for each signal, as you proposed, might
not be that much of str
Re: [PATCH v5 6/6] spi: s3c64xx: add device tree support
On 13 July 2012 19:12, Kukjin Kim wrote: > Thomas Abraham wrote: >> >> On 13 July 2012 16:58, Kukjin Kim wrote: >> > Thomas Abraham wrote: >> >> >> >> On 13 July 2012 04:08, Kukjin Kim wrote: >> >> > Thomas, the DMACH_DT_PROP is available only on pl330 now. So seems >> occur >> >> > following build error with s3c6400_defconfig. >> >> > >> >> > drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_get_dmares': >> >> > drivers/spi/spi-s3c64xx.c:1098: error: 'DMACH_DT_PROP' undeclared >> (first >> >> use >> >> > in this function) >> >> > drivers/spi/spi-s3c64xx.c:1098: error: (Each undeclared identifier is >> >> > reported only once >> >> > drivers/spi/spi-s3c64xx.c:1098: error: for each function it appears >> in.) >> >> > make[3]: *** [drivers/spi/spi-s3c64xx.o] Error 1 >> >> > make[2]: *** [drivers/spi] Error 2 >> >> > >> >> >> >> Dear Mr. Kim, >> >> >> >> Thanks for considering these patches to be merged via your tree. For >> >> the build break you mentioned above, there was a patch submitted some >> >> time back to handle this. The link to that patch is: >> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2012- >> >> June/102627.html. >> >> Could you please apply this patch also to your tree. >> >> >> > Sure, it looks good to me, will apply that then this series will be >> rebased >> > on top of that. >> >> There are six more patches that enable spi device tree support for >> Exynos4 and Exynos5 platforms. Could you consider to apply those >> patches as well. The link to those patches is: >> http://www.mail-archive.com/linux-samsung- >> s...@vger.kernel.org/msg10851.html. >> > Yeah, I remember, but I think some patches is needed to re-work as per > comments...? I checked again for any pending comments on v2 version. There are no pending comments for the v2 version of this patch series. Thanks. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/2] regulator: tps6586x: add support for input supply
On Fri, Jul 13, 2012 at 07:20:32PM +0530, Laxman Dewangan wrote: > There is multiple voltage input pins on device which > takes the voltage input for different voltage regulator. > Support to configure the voltage input supplied by > different regulator for each regulators. 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 v5 5/7] ARM: davinci: i2c: add OF support
Hi Heiko,
On 5/30/2012 3:49 PM, Heiko Schocher wrote:
> add of support for the davinci i2c driver.
>
> Signed-off-by: Heiko Schocher
> Cc: davinci-linux-open-sou...@linux.davincidsp.com
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> Cc: Ben Dooks
> Cc: Wolfram Sang
> Cc: Grant Likely
> Cc: Sekhar Nori
> Cc: Wolfgang Denk
> Cc: Sylwester Nawrocki
>
> ---
> - changes for v2:
> - add comments from Sylwester Nawrocki :
> - use "cell-index" instead "id"
> - OF_DEV_AUXDATA in the machine code, instead pre-define platform
> device name
> - add comment from Grant Likely:
> - removed "id" resp. "cell-index" completely
> - fixed documentation
> - use of_match_ptr()
> - use devm_kzalloc() for allocating plattform data mem
> - fixed a whitespace issue
> - no changes for v3
> - changes for v4
> remove "pinmux-handle" property as discussed here:
> http://www.spinics.net/lists/arm-kernel/msg175701.html
> with Nori Sekhar
>
> - changes for v5
> add comments from Grant Likely:
> - do not change value of dev->dev->platform_data, instead
> hold a copy in davinci_i2c_dev.
>
> .../devicetree/bindings/arm/davinci/i2c.txt| 31
> drivers/i2c/busses/i2c-davinci.c | 49
> ++--
> 2 files changed, 76 insertions(+), 4 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/davinci/i2c.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> new file mode 100644
> index 000..e98a025
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/i2c.txt
> @@ -0,0 +1,31 @@
> +* Texas Instruments Davinci I2C
> +
> +This file provides information, what the device node for the
> +davinci i2c interface contain.
> +
> +Required properties:
> +- compatible: "ti,davinci-i2c";
> +- reg : Offset and length of the register set for the device
> +
> +Recommended properties :
> +- interrupts : standard interrupt property.
> +- clock-frequency : desired I2C bus clock frequency in Hz.
> +
> +Optional properties:
> +- bus-delay: bus delay in usec
> +
> +Example (enbw_cmc board):
> + i2c@1c22000 {
> + compatible = "ti,davinci-i2c";
> + reg = <0x22000 0x1000>;
> + clock-frequency = <10>;
> + interrupts = <15>;
> + interrupt-parent = <&intc>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + dtt@48 {
> + compatible = "national,lm75";
> + reg = <0x48>;
> + };
> + };
> diff --git a/drivers/i2c/busses/i2c-davinci.c
> b/drivers/i2c/busses/i2c-davinci.c
> index a76d85f..4e7a966 100644
> --- a/drivers/i2c/busses/i2c-davinci.c
> +++ b/drivers/i2c/busses/i2c-davinci.c
> @@ -38,9 +38,12 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include
> #include
> +#include
Seems like a stray change. I was able to build and use just fine
without this include.
>
> /* - global defines --- */
>
> @@ -114,6 +117,7 @@ struct davinci_i2c_dev {
> struct completion xfr_complete;
> struct notifier_block freq_transition;
> #endif
> + struct davinci_i2c_platform_data *pdata;
> };
>
> /* default platform data to use if not supplied in the platform_device */
> @@ -149,13 +153,22 @@ static void generic_i2c_clock_pulse(unsigned int
> scl_pin)
> }
> }
>
> +static struct davinci_i2c_platform_data
> + *i2c_get_plattformdata(struct davinci_i2c_dev *dev)
> +{
> + if (dev->dev->platform_data == NULL)
> + return dev->pdata;
> +
> + return dev->dev->platform_data;
> +}
It seems to me that if we setup the newly introduced dev->pdata
member correctly once in probe, there should not be a need for this
function. We can also eliminate multiple checks for pdata in code.
See below for more.
> +
> /* This routine does i2c bus recovery as specified in the
> * i2c protocol Rev. 03 section 3.16 titled "Bus clear"
> */
> static void i2c_recover_bus(struct davinci_i2c_dev *dev)
> {
> u32 flag = 0;
> - struct davinci_i2c_platform_data *pdata = dev->dev->platform_data;
> + struct davinci_i2c_platform_data *pdata = i2c_get_plattformdata(dev);
>
> dev_err(dev->dev, "initiating i2c bus recovery\n");
> /* Send NACK to the slave */
> @@ -187,7 +200,7 @@ static inline void davinci_i2c_reset_ctrl(struct
> davinci_i2c_dev *i2c_dev,
>
> static void i2c_davinci_calc_clk_dividers(struct davinci_i2c_dev *dev)
> {
> - struct davinci_i2c_platform_data *pdata = dev->dev->platform_data;
> + struct davinci_i2c_platform_data *pdata = i2c_get_plattformdata(dev);
> u16 psc;
> u32 clk;
> u32 d;
> @@ -235,7 +248,7 @@ static void i2c_davinci_ca
Re: [PATCH 07/11] dmaengine: at_hdmac: add a few const qualifiers
On 07/13/2012 02:32 PM, y...@pengutronix.de :
> From: Uwe Kleine-König
>
> This prepares of_device_id.data becoming const. Without this change
> the following warning would occur:
>
> drivers/dma/at_hdmac.c: In function 'at_dma_get_driver_data':
> drivers/dma/at_hdmac.c:1228: warning: return discards qualifiers from
> pointer target type
>
> Signed-off-by: Uwe Kleine-König
> Cc: Nicolas Ferre
Acked-by: Nicolas Ferre
> Cc: Dan Williams
> Cc: Vinod Koul
> ---
> drivers/dma/at_hdmac.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index 7292aa8..7e9d265 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -1217,7 +1217,7 @@ static const struct platform_device_id atdma_devtypes[]
> = {
> }
> };
>
> -static inline struct at_dma_platform_data * __init at_dma_get_driver_data(
> +static inline const struct at_dma_platform_data * __init
> at_dma_get_driver_data(
> struct platform_device *pdev)
> {
> if (pdev->dev.of_node) {
> @@ -1255,7 +1255,7 @@ static int __init at_dma_probe(struct platform_device
> *pdev)
> int irq;
> int err;
> int i;
> - struct at_dma_platform_data *plat_dat;
> + const struct at_dma_platform_data *plat_dat;
>
> /* setup platform data for each SoC */
> dma_cap_set(DMA_MEMCPY, at91sam9rl_config.cap_mask);
>
--
Nicolas Ferre
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v3 4/4] i2c: i2c-ocores: support for 16bit and 32bit IO
Hello,
On Fri, Jul 13, 2012 at 7:14 PM, Jayachandran C
wrote:
> From: Ganesan Ramalingam
>
> Some architectures supports only 16-bit or 32-bit read/write access to
> their IO space. Add a 'reg-io-width' platform and OF parameter which
> specifies the IO width to support these platforms.
>
> reg-io-width can be specified as 1, 2 or 4, and has a default value
> of 1 if it is unspecified.
>
> Signed-off-by: Ganesan Ramalingam
> Signed-off-by: Jayachandran C
> ---
> .../devicetree/bindings/i2c/i2c-ocores.txt |2 ++
> drivers/i2c/busses/i2c-ocores.c| 21
> ++--
> include/linux/i2c-ocores.h |1 +
> 3 files changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
> b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
> index 1c9334b..c15781f 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
> @@ -10,6 +10,7 @@ Required properties:
>
> Optional properties:
> - reg-shift : device register offsets are shifted by this value
> +- reg-io-width: io register width in bytes (1, 2 or 4)
> - regstep : deprecated, use reg-shift above
>
> Example:
> @@ -23,6 +24,7 @@ Example:
> clock-frequency = <2000>;
>
> reg-shift = <0>;/* 8 bit registers */
> + reg-io-width = <1>; /* 8 bit read/write */
>
> dummy@60 {
> compatible = "dummy";
> diff --git a/drivers/i2c/busses/i2c-ocores.c b/drivers/i2c/busses/i2c-ocores.c
> index 721ead9..de3b119 100644
> --- a/drivers/i2c/busses/i2c-ocores.c
> +++ b/drivers/i2c/busses/i2c-ocores.c
> @@ -30,6 +30,7 @@
> struct ocores_i2c {
> void __iomem *base;
> u32 reg_shift;
> + u32 reg_io_width;
> wait_queue_head_t wait;
> struct i2c_adapter adap;
> struct i2c_msg *msg;
> @@ -72,12 +73,22 @@ struct ocores_i2c {
>
> static inline void oc_setreg(struct ocores_i2c *i2c, int reg, u8 value)
> {
> - iowrite8(value, i2c->base + (reg << i2c->reg_shift));
> + if (i2c->reg_io_width == 4)
> + iowrite32(value, i2c->base + (reg << i2c->reg_shift));
> + else if (i2c->reg_io_width == 2)
> + iowrite16(value, i2c->base + (reg << i2c->reg_shift));
> + else
> + iowrite8(value, i2c->base + (reg << i2c->reg_shift));
> }
>
> static inline u8 oc_getreg(struct ocores_i2c *i2c, int reg)
Should the return type be changed.
Now that it is returning more that than 8 bits.
Did I miss something?
> {
> - return ioread8(i2c->base + (reg << i2c->reg_shift));
> + if (i2c->reg_io_width == 4)
> + return ioread32(i2c->base + (reg << i2c->reg_shift));
> + else if (i2c->reg_io_width == 2)
> + return ioread16(i2c->base + (reg << i2c->reg_shift));
> + else
> + return ioread8(i2c->base + (reg << i2c->reg_shift));
> }
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/11] make struct of_device_id.data const
On Fri, Jul 13, 2012 at 07:41:02AM -0500, Rob Herring wrote: > On 07/13/2012 07:32 AM, y...@pengutronix.de wrote: > > From: Uwe Kleine-König > > > > this series' goal is to make struct of_device_id.data const. > > Conceptually a driver must not modify the data contained there so making > > it const is the right thing. > > > > This change might introduce warnings because drivers don't use const to > > access the data pointed to by of_device_id.data. In most cases the fix > > is to add some consts. > > > > This series (apart from adding this const in patch 10) fixes all drivers > > covered by all arm defconfigs (based on v3.5-rc6). > > > > What about other arches? I didn't looked at them, mainly because I don't have the scripts for arches other than arm to do such testing. Also note that it introduces only some warnings, but no breakage. So adding the const in the merge window might be ok?! I'm not sure I'll have the capacity to fix other arches now. Maybe only add the const for ARCH=arm for now and I'll address the other archs as time permits even though this is ugly? At least getting in patches 1-9 would be nice to get in to save me from keeping them up to date. Which other arches do you consider relevant? $ git grep -l '\' arch/*/Kconfig arch/arm/Kconfig arch/c6x/Kconfig arch/microblaze/Kconfig arch/mips/Kconfig arch/openrisc/Kconfig arch/powerpc/Kconfig arch/sparc/Kconfig arch/x86/Kconfig For most of these I first have to look where to get a toolchain from. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v5 6/6] spi: s3c64xx: add device tree support
Thomas Abraham wrote: > > On 13 July 2012 16:58, Kukjin Kim wrote: > > Thomas Abraham wrote: > >> > >> On 13 July 2012 04:08, Kukjin Kim wrote: > >> > Thomas, the DMACH_DT_PROP is available only on pl330 now. So seems > occur > >> > following build error with s3c6400_defconfig. > >> > > >> > drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_get_dmares': > >> > drivers/spi/spi-s3c64xx.c:1098: error: 'DMACH_DT_PROP' undeclared > (first > >> use > >> > in this function) > >> > drivers/spi/spi-s3c64xx.c:1098: error: (Each undeclared identifier is > >> > reported only once > >> > drivers/spi/spi-s3c64xx.c:1098: error: for each function it appears > in.) > >> > make[3]: *** [drivers/spi/spi-s3c64xx.o] Error 1 > >> > make[2]: *** [drivers/spi] Error 2 > >> > > >> > >> Dear Mr. Kim, > >> > >> Thanks for considering these patches to be merged via your tree. For > >> the build break you mentioned above, there was a patch submitted some > >> time back to handle this. The link to that patch is: > >> http://lists.infradead.org/pipermail/linux-arm-kernel/2012- > >> June/102627.html. > >> Could you please apply this patch also to your tree. > >> > > Sure, it looks good to me, will apply that then this series will be > rebased > > on top of that. > > There are six more patches that enable spi device tree support for > Exynos4 and Exynos5 platforms. Could you consider to apply those > patches as well. The link to those patches is: > http://www.mail-archive.com/linux-samsung- > s...@vger.kernel.org/msg10851.html. > Yeah, I remember, but I think some patches is needed to re-work as per comments...? Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 04/11] misc/atmel_tc: make atmel_tc.tcb_config member point to const data
On 07/13/2012 02:32 PM, y...@pengutronix.de :
> From: Uwe Kleine-König
>
> This prepares of_device_id.data becoming const. Without this change
> the following warning would occur:
>
> drivers/misc/atmel_tclib.c: In function 'tc_probe':
> drivers/misc/atmel_tclib.c:170: warning: assignment discards qualifiers
> from pointer target type
>
> Signed-off-by: Uwe Kleine-König
> Cc: Nicolas Ferre
Acked-by: Nicolas Ferre
Thanks Uwe!
> Cc: Greg Kroah-Hartman
> ---
> Hello,
>
> btw, get_maintainer.pl suggested to Cc:
> linux-atm-gene...@lists.sourceforge.net but not the Atmel people because
> include/linux/atmel_tc.h matches include/linux/atm*.
Ah, ok, good to know. I will try to update MAINTAINERS file for this.
Bye,
> Best regards
> Uwe
> include/linux/atmel_tc.h |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/atmel_tc.h b/include/linux/atmel_tc.h
> index 1d14b1dc..89a931b 100644
> --- a/include/linux/atmel_tc.h
> +++ b/include/linux/atmel_tc.h
> @@ -63,7 +63,7 @@ struct atmel_tc {
> struct platform_device *pdev;
> struct resource *iomem;
> void __iomem*regs;
> - struct atmel_tcb_config *tcb_config;
> + const struct atmel_tcb_config *tcb_config;
> int irq[3];
> struct clk *clk[3];
> struct list_headnode;
>
--
Nicolas Ferre
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
[PATCH] spi: Add support for specifing 3-wire mode via device tree
This patch allows to specify that a SPI device is connected in 3-wire mode via
the device tree.
Signed-off-by: Lars-Peter Clausen
---
Documentation/devicetree/bindings/spi/spi-bus.txt |2 ++
drivers/spi/spi.c |2 ++
2 files changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt
b/Documentation/devicetree/bindings/spi/spi-bus.txt
index e782add..46f2f3b 100644
--- a/Documentation/devicetree/bindings/spi/spi-bus.txt
+++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -33,6 +33,8 @@ contain the following properties.
shifted clock phase (CPHA) mode
- spi-cs-high - (optional) Empty property indicating device requires
chip select active high
+- spi-3wire - (optional) Empty property indicating device requires
+ 3-wire mode.
SPI example for an MPC5200 SPI bus:
spi@f00 {
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index fc0da39..09da7de 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -856,6 +856,8 @@ static void of_register_spi_devices(struct spi_master
*master)
spi->mode |= SPI_CPOL;
if (of_find_property(nc, "spi-cs-high", NULL))
spi->mode |= SPI_CS_HIGH;
+ if (of_find_property(nc, "spi-3wire", NULL))
+ spi->mode |= SPI_3WIRE;
/* Device speed */
prop = of_get_property(nc, "spi-max-frequency", &len);
--
1.7.10.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH] spi: Add support for specifing 3-wire mode via device tree
On 07/13/2012 07:43 AM, Lars-Peter Clausen wrote:
> This patch allows to specify that a SPI device is connected in 3-wire mode via
> the device tree.
>
> Signed-off-by: Lars-Peter Clausen
> ---
Might explain what 3-wire mode is, but otherwise
Acked-by: Rob Herring
> Documentation/devicetree/bindings/spi/spi-bus.txt |2 ++
> drivers/spi/spi.c |2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt
> b/Documentation/devicetree/bindings/spi/spi-bus.txt
> index e782add..46f2f3b 100644
> --- a/Documentation/devicetree/bindings/spi/spi-bus.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
> @@ -33,6 +33,8 @@ contain the following properties.
> shifted clock phase (CPHA) mode
> - spi-cs-high - (optional) Empty property indicating device requires
> chip select active high
> +- spi-3wire - (optional) Empty property indicating device requires
> + 3-wire mode.
>
> SPI example for an MPC5200 SPI bus:
> spi@f00 {
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index fc0da39..09da7de 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -856,6 +856,8 @@ static void of_register_spi_devices(struct spi_master
> *master)
> spi->mode |= SPI_CPOL;
> if (of_find_property(nc, "spi-cs-high", NULL))
> spi->mode |= SPI_CS_HIGH;
> + if (of_find_property(nc, "spi-3wire", NULL))
> + spi->mode |= SPI_3WIRE;
>
> /* Device speed */
> prop = of_get_property(nc, "spi-max-frequency", &len);
>
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/11] make struct of_device_id.data const
On 07/13/2012 07:32 AM, y...@pengutronix.de wrote: > From: Uwe Kleine-König > > Hello, > > this series' goal is to make struct of_device_id.data const. > Conceptually a driver must not modify the data contained there so making > it const is the right thing. > > This change might introduce warnings because drivers don't use const to > access the data pointed to by of_device_id.data. In most cases the fix > is to add some consts. > > This series (apart from adding this const in patch 10) fixes all drivers > covered by all arm defconfigs (based on v3.5-rc6). > What about other arches? Rob > There is one exception though: > drivers/regulator/twl-regulator.c (build in omap2plus_defconfig) now > issues: > > drivers/regulator/twl-regulator.c: In function 'twlreg_probe': > drivers/regulator/twl-regulator.c:1181: warning: assignment discards > qualifiers from pointer target type > drivers/regulator/twl-regulator.c:1190: warning: assignment discards > qualifiers from pointer target type > > that is because this driver really modifies his .of_match_table in the > precence of a traditionally probed device. > I didn't check deeply, but probably the easiest fix is to remove > traditional platform support. Don't know if omap is ready for that > though. > > And also patch 11 adds some more consts that are possible now after > patch 10. > > This series is available in my git tree at: > > git://git.pengutronix.de/git/ukl/linux.git ofdeviceiddata > > Best regards > Uwe > > Uwe Kleine-König (11): > spi/imx: make spi_imx_data.devtype_data member point to const data > serial/imx: make imx_port.devdata member point to const data > ARM: cache-l2x0: add a const qualifier > misc/atmel_tc: make atmel_tc.tcb_config member point to const data > gpio/gpio-omap.c: add a const qualifier > i2c/i2c-omap: add a const qualifier > dmaengine: at_hdmac: add a few const qualifiers > spi/spi-omap2-mcspi: add a const qualifier > mmc/omap_hsmmc: add a const qualifier > of: add const to struct of_device_id.data > gpio/gpio-omap: make platformdata used as of_device_id.data const > > arch/arm/mm/cache-l2x0.c|2 +- > drivers/dma/at_hdmac.c |4 ++-- > drivers/gpio/gpio-omap.c|8 > drivers/i2c/busses/i2c-omap.c |3 ++- > drivers/mmc/host/omap_hsmmc.c |2 +- > drivers/spi/spi-imx.c |2 +- > drivers/spi/spi-omap2-mcspi.c |2 +- > drivers/tty/serial/imx.c|2 +- > include/linux/atmel_tc.h|2 +- > include/linux/mod_devicetable.h |2 +- > 10 files changed, 15 insertions(+), 14 deletions(-) > ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 00/11] make struct of_device_id.data const
Hello, On Fri, Jul 13, 2012 at 02:32:02PM +0200, y...@pengutronix.de wrote: This is utter non-sense, it was me who sent these mails (and pressed 'y' when git send-email asked if "Uwe Kleine-König " is the right sender). Please make sure to correct this when replying to the patches. Sorry for the inconvenience. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v5 6/6] spi: s3c64xx: add device tree support
On 13 July 2012 16:58, Kukjin Kim wrote: > Thomas Abraham wrote: >> >> On 13 July 2012 04:08, Kukjin Kim wrote: >> > Thomas, the DMACH_DT_PROP is available only on pl330 now. So seems occur >> > following build error with s3c6400_defconfig. >> > >> > drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_get_dmares': >> > drivers/spi/spi-s3c64xx.c:1098: error: 'DMACH_DT_PROP' undeclared (first >> use >> > in this function) >> > drivers/spi/spi-s3c64xx.c:1098: error: (Each undeclared identifier is >> > reported only once >> > drivers/spi/spi-s3c64xx.c:1098: error: for each function it appears in.) >> > make[3]: *** [drivers/spi/spi-s3c64xx.o] Error 1 >> > make[2]: *** [drivers/spi] Error 2 >> > >> >> Dear Mr. Kim, >> >> Thanks for considering these patches to be merged via your tree. For >> the build break you mentioned above, there was a patch submitted some >> time back to handle this. The link to that patch is: >> http://lists.infradead.org/pipermail/linux-arm-kernel/2012- >> June/102627.html. >> Could you please apply this patch also to your tree. >> > Sure, it looks good to me, will apply that then this series will be rebased > on top of that. There are six more patches that enable spi device tree support for Exynos4 and Exynos5 platforms. Could you consider to apply those patches as well. The link to those patches is: http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg10851.html. Thanks, Thomas. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
RE: [PATCH v5 6/6] spi: s3c64xx: add device tree support
Thomas Abraham wrote: > > On 13 July 2012 04:08, Kukjin Kim wrote: > > Thomas, the DMACH_DT_PROP is available only on pl330 now. So seems occur > > following build error with s3c6400_defconfig. > > > > drivers/spi/spi-s3c64xx.c: In function 's3c64xx_spi_get_dmares': > > drivers/spi/spi-s3c64xx.c:1098: error: 'DMACH_DT_PROP' undeclared (first > use > > in this function) > > drivers/spi/spi-s3c64xx.c:1098: error: (Each undeclared identifier is > > reported only once > > drivers/spi/spi-s3c64xx.c:1098: error: for each function it appears in.) > > make[3]: *** [drivers/spi/spi-s3c64xx.o] Error 1 > > make[2]: *** [drivers/spi] Error 2 > > > > Dear Mr. Kim, > > Thanks for considering these patches to be merged via your tree. For > the build break you mentioned above, there was a patch submitted some > time back to handle this. The link to that patch is: > http://lists.infradead.org/pipermail/linux-arm-kernel/2012- > June/102627.html. > Could you please apply this patch also to your tree. > Sure, it looks good to me, will apply that then this series will be rebased on top of that. Thanks. Best regards, Kgene. -- Kukjin Kim , Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH v2 1/3] regulator: tps65217: Add device tree support
On Fri, Jul 13, 2012 at 05:43:30AM +, AnilKumar, Chimata wrote: > Thanks much, are you going to push reset of the patches in this series? No, there's no dependency so I'd expect them to be applied by the architecture maintainers. signature.asc Description: Digital signature ___ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [RESEND PATCH 1/1] clk: add DT support for clock gating control
On 07/13/2012 05:19 AM, Rob Herring wrote:
What's implemented in Linux should not define the binding. The binding
should describe the hardware.
[...]
True, but not your problem to implement. A binding doesn't necessarily
mean there is a full Linux implementation. We just don't want to create
something only to find others need something completely different.
Ok, what about a DT describing the following for a simple register-based
clock gating controller and the corresponding gated-clock independent of
the controller. I am sure there are a bunch of SoCs out there that
control their clock gates by writing some bits to a register. If that
DT description matches your expectations, I ll prepare patches with
documentation and implementation for common clock framework.
Sebastian
--
/* Simple clock gating controller based on bitmasks and register */
cgc: clock-gating-control@f100 {
compatible = "clock-gating-control-register";
reg = <0xf100 0x4>;
/* Clock gating control with one bit at bit position 0
enable with (1<<0), disable with (0<<0) */
cgctrl_usb0: cgc_usb0 {
clock-gating-control,shift = <0>;
clock-gating-control,mask = <1>;
clock-gating-control,enable = <1>;
clock-gating-control,disable = <0>;
};
/* Clock gating control with two bits at bit position 1-2
enable with (2<<1), disable with (0<<1) */
cgctrl_sata: cgc_sata {
clock-gating-control,shift = <1>;
clock-gating-control,mask = <3>;
clock-gating-control,enable = <2>;
clock-gating-control,disable = <0>;
};
};
/* Generic clock gate description that can be used with
any clock gating controller */
cg_usb0: clockgate@0 {
compatible = "gated-clock";
#clock-cells = <0>;
clocks = <&osc>;
clock-gate-control = <&cgctrl_usb0>;
};
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
re: regulator: tps65217: Add device tree support
Hello AnilKumar Ch,
This is a semi-automatic email about new static checker warnings.
The patch a7f1b63eb856: "regulator: tps65217: Add device tree
support" from Jul 10, 2012, leads to the following Smatch complaint:
drivers/mfd/tps65217.c:245 tps65217_probe()
error: we previously assumed 'pdata' could be null (see line 205)
drivers/mfd/tps65217.c
204
205 if (!pdata && client->dev.of_node)
^^
New check.
206 pdata = tps65217_parse_dt(client);
207
208 tps = devm_kzalloc(&client->dev, sizeof(*tps), GFP_KERNEL);
209 if (!tps)
210 return -ENOMEM;
211
212 tps->pdata = pdata;
213 tps->regmap = devm_regmap_init_i2c(client,
&tps65217_regmap_config);
214 if (IS_ERR(tps->regmap)) {
215 ret = PTR_ERR(tps->regmap);
216 dev_err(tps->dev, "Failed to allocate register map:
%d\n",
217 ret);
218 return ret;
219 }
220
221 i2c_set_clientdata(client, tps);
222 tps->dev = &client->dev;
223
224 ret = tps65217_reg_read(tps, TPS65217_REG_CHIPID, &version);
225 if (ret < 0) {
226 dev_err(tps->dev, "Failed to read revision register:
%d\n",
227 ret);
228 return ret;
229 }
230
231 dev_info(tps->dev, "TPS65217 ID %#x version 1.%d\n",
232 (version & TPS65217_CHIPID_CHIP_MASK) >> 4,
233 version & TPS65217_CHIPID_REV_MASK);
234
235 for (i = 0; i < TPS65217_NUM_REGULATOR; i++) {
236 struct platform_device *pdev;
237
238 pdev = platform_device_alloc("tps65217-pmic", i);
239 if (!pdev) {
240 dev_err(tps->dev, "Cannot create regulator
%d\n", i);
241 continue;
242 }
243
244 pdev->dev.parent = tps->dev;
245 pdev->dev.of_node = pdata->of_node[i];
^^
Old dereference.
246 reg_data = pdata->tps65217_init_data[i];
247 platform_device_add_data(pdev, reg_data,
sizeof(*reg_data));
regards,
dan carpenter
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 1/3 v2] USB: ohci-exynos: Add support for device tree
On Thursday, July 12, 2012 2:55 PM, Vivek Gautam wrote:
>
> This patch adds support to parse probe data for
> ohci driver for exynos using device tree.
>
> Signed-off-by: Thomas Abraham
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Vivek Gautam
>
> diff --git a/drivers/usb/host/ohci-exynos.c b/drivers/usb/host/ohci-exynos.c
> index 2909621..c4ad60f 100644
> --- a/drivers/usb/host/ohci-exynos.c
> +++ b/drivers/usb/host/ohci-exynos.c
> @@ -12,6 +12,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -71,6 +72,8 @@ static const struct hc_driver exynos_ohci_hc_driver = {
> .start_port_reset = ohci_start_port_reset,
> };
>
> +static u64 ohci_exynos_dma_mask = DMA_BIT_MASK(32);
> +
> static int __devinit exynos_ohci_probe(struct platform_device *pdev)
> {
> struct exynos4_ohci_platdata *pdata;
> @@ -87,6 +90,16 @@ static int __devinit exynos_ohci_probe(struct
> platform_device *pdev)
> return -EINVAL;
> }
>
> + /*
> + * Right now device-tree probed devices don't get dma_mask set.
> + * Since shared usb code relies on it, set it here for now.
> + * Once we move to full device tree support this will vanish off.
> + */
> + if (!pdev->dev.dma_mask)
> + pdev->dev.dma_mask = &ohci_exynos_dma_mask;
> + if (!pdev->dev.coherent_dma_mask)
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> +
> exynos_ohci = kzalloc(sizeof(struct exynos_ohci_hcd), GFP_KERNEL);
This makes conflict on 'usb-next' branch.
Please re-base the patch on 'usb-next' branch.
> if (!exynos_ohci)
> return -ENOMEM;
> @@ -258,6 +271,14 @@ static const struct dev_pm_ops exynos_ohci_pm_ops = {
> .resume = exynos_ohci_resume,
> };
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id exynos_ohci_match[] = {
> + { .compatible = "samsung,exynos-ohci" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_ohci_match);
> +#endif
> +
> static struct platform_driver exynos_ohci_driver = {
> .probe = exynos_ohci_probe,
> .remove = __devexit_p(exynos_ohci_remove),
> @@ -266,6 +287,7 @@ static struct platform_driver exynos_ohci_driver = {
> .name = "exynos-ohci",
> .owner = THIS_MODULE,
> .pm = &exynos_ohci_pm_ops,
> + .of_match_table = of_match_ptr(exynos_ohci_match),
> }
> };
>
> --
> 1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
Re: [PATCH 2/3 v2] USB: ehci-s5p: Add support for device tree
On Thursday, July 12, 2012 2:55 PM, Vivek Gautam wrote:
>
> This patch adds support to parse probe data for
> ehci driver for exynos using device tree
>
> Signed-off-by: Thomas Abraham
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Vivek Gautam
>
> diff --git a/drivers/usb/host/ehci-s5p.c b/drivers/usb/host/ehci-s5p.c
> index c474cec..52d0049 100644
> --- a/drivers/usb/host/ehci-s5p.c
> +++ b/drivers/usb/host/ehci-s5p.c
> @@ -13,6 +13,7 @@
> */
>
> #include
> +#include
> #include
> #include
> #include
> @@ -63,6 +64,8 @@ static const struct hc_driver s5p_ehci_hc_driver = {
> .clear_tt_buffer_complete = ehci_clear_tt_buffer_complete,
> };
>
> +static u64 ehci_s5p_dma_mask = DMA_BIT_MASK(32);
> +
> static int __devinit s5p_ehci_probe(struct platform_device *pdev)
> {
> struct s5p_ehci_platdata *pdata;
> @@ -79,6 +82,16 @@ static int __devinit s5p_ehci_probe(struct platform_device
> *pdev)
> return -EINVAL;
> }
>
> + /*
> + * Right now device-tree probed devices don't get dma_mask set.
> + * Since shared usb code relies on it, set it here for now.
> + * Once we move to full device tree support this will vanish off.
> + */
> + if (!pdev->dev.dma_mask)
> + pdev->dev.dma_mask = &ehci_s5p_dma_mask;
> + if (!pdev->dev.coherent_dma_mask)
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> +
> s5p_ehci = kzalloc(sizeof(struct s5p_ehci_hcd), GFP_KERNEL);
This makes conflict on 'usb-next' branch.
Please re-base the patch on 'usb-next' branch.
> if (!s5p_ehci)
> return -ENOMEM;
> @@ -298,6 +311,14 @@ static int s5p_ehci_resume(struct device *dev)
> #define s5p_ehci_resume NULL
> #endif
>
> +#ifdef CONFIG_OF
> +static const struct of_device_id exynos_ehci_match[] = {
> + { .compatible = "samsung,exynos-ehci" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, exynos_ehci_match);
> +#endif
> +
Please move " struct of_device_id exynos_ehci_match[]"
to the next of "struct dev_pm_ops s5p_ehci_pm_ops",
as you did at 1st patch '[PATCH 1/3 v2] USB: ohci-exynos: Add support for
device tree'.
Please keep the code sync as possible.
> static const struct dev_pm_ops s5p_ehci_pm_ops = {
> .suspend= s5p_ehci_suspend,
> .resume = s5p_ehci_resume,
> @@ -311,6 +332,7 @@ static struct platform_driver s5p_ehci_driver = {
> .name = "s5p-ehci",
> .owner = THIS_MODULE,
> .pm = &s5p_ehci_pm_ops,
> + .of_match_table = of_match_ptr(exynos_ehci_match),
> }
> };
>
> --
> 1.7.0.4
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
