Re: [PATCH v2 5/8] ARM: OMAP2+: hwmod: ensure that SYSCONFIG bits are reprogrammed after a reset
Hola Omar, On Wed, 14 Mar 2012, Ramirez Luna, Omar wrote: If we reached here the reset lines will be asserted, and then the code below touches sysc registers on a module under reset. Do you know of any case where this would be a problem? Seems like it would only affect IP blocks that have both hard reset lines and SYSCONFIG registers, and as far as I know, we don't have any of those defined? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPIO abort on 3630/Zoom3
On Thu, Mar 15, 2012 at 8:43 AM, DebBarma, Tarun Kanti tarun.ka...@ti.com wrote: On Thu, Mar 15, 2012 at 3:35 AM, Kevin Hilman khil...@ti.com wrote: Tarun, Can you investigate an abort during boot on 3630/Zoom3? Both Tony and I are seeing the abort below on 3630/Zoom3. I'm using arm-soc/for-next and Tony is using linux-next, but we see the same abort. The crash looks very similar to what we fixed yesterday. The problem was basically due to usage of OMAP_GPIO_IRQ macro instead of gpio_to_irq() which came as part of Benoit's dynamic irq allocation change. The fix is to replace those macros in the board files. (The same problem is seen on OMAP3430 SDP as well.) Anyways, I will confirm. Adding in your latest fixes series doesn't make the problem go away, but backing out the GPIO runtime PM series does make the problem go away. Because of dynamic irq allocation we end up into wrong GPIO Bank unless we use the new gpio_to_irq(). As a result _set_gpio_triggering() tries to operate on a GPIO Bank whose clock was not turned on using omap_gpio_request(). Probably, that is why we do not see the problem when the runtime PM series is removed because in this case all the GPIO banks are turned on. To be clear, the issue which we saw was wiith Grant's tree which has GPIO sparce IRQ conversion. So if the issue is seen with linux for-next, it must be the same issue. There are many board files which are still using static OMAP_GPIO_IRQ macro to retrieve the IRQ number which won't work anymore after the gpio sparce irq conversion series. We will post a patch against Grant's tree to fix those board files. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] OMAPDSS: provide default timings functions for panels
On Wed, 2012-03-14 at 18:33 +0200, Grazvydas Ignotas wrote: On Wed, Mar 14, 2012 at 1:22 PM, Tomi Valkeinen tomi.valkei...@ti.com wrote: Hi, On Mon, 2012-03-12 at 13:27 +0200, Grazvydas Ignotas wrote: With this we can eliminate some duplicate code in panel drivers. Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and tpo-td043mtea1 gain support of timings control over sysfs. I don't like this patch. Panels usually have a single, fixed timing configuration that should be used, like the ones you mention above. There's no need to alter the timings. But they often have a range of timings they can tolerate, and that can be used to alter refresh rate, for example. We do that on pandora to match graphics drawing rate (or multiples of it) to create a feeling smoothness. True. And it's a valid operation anyway, so I guess there's no reason why not to allow changing of the timings there. But it's true that there's some duplicate code currently in the panel drivers. However, adding just simple funcs like you did in this patch doesn't work quite properly. There should be locking (for example to prevent disabling the panel while timings are being set), and currently the locking is panel driver specific. Oh, and one more problem with the patch is that currently the panel informs its inability to change timings by leaving set_timings and check_timings as NULL, and this tells omapfb etc that the timings cannot be changed, and the patch changes that behavior. ok, what about a version of this with .get_timings only then? This should not need a lock unless panel has a set function, but in that case panel will be expected to provide safe version of .get and .set itself. I guess there's no harm in having default for get_timings(). It should be present on all panel drivers anyway. Tomi signature.asc Description: This is a digitally signed message part
[PATCH] of: Add generic device tree DMA helpers
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be implemented
by the DMA controller can carry any type of dma-request argument.
The DMA client will search its associated DMA controller in the list and
call the registered of_dam_xlate() function to retrieve the request values.
One simple xlate function is provided for the single number type of
request binding.
This implementation is independent from dmaengine so it can also be used
by legacy drivers.
For legacy reason another API will export the DMA request number into a
Linux resource of type IORESOURCE_DMA.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Signed-off-by: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
---
Documentation/devicetree/bindings/dma/dma.txt | 45 +
drivers/of/Kconfig|5 +
drivers/of/Makefile |1 +
drivers/of/dma.c | 260 +
include/linux/of_dma.h| 67 +++
5 files changed, 378 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/dma.txt
create mode 100644 drivers/of/dma.c
create mode 100644 include/linux/of_dma.h
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
new file mode 100644
index 000..c49e98d
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -0,0 +1,45 @@
+* Generic DMA Controller and DMA request bindings
+
+Generic binding to provide a way for a driver to retrieve the
+DMA request line that goes from an IP to a DMA controller.
+
+
+* DMA controller
+
+Required property:
+- #dma-cells: Number of cells for each DMA line.
+
+
+Example:
+
+ sdma: dma-controller@4800 {
+ compatible = ti,sdma-omap4
+ reg = 0x4800 0x1000;
+ interrupts = 12;
+ #dma-cells = 1;
+ };
+
+
+
+* DMA client
+
+Client drivers should specify the DMA request property using a phandle to
+the controller. If needed, the DMA request identity on that controller is then
+added followed by optional request specifications.
+
+Required property:
+- dma-request: List of phandle + dma-request + request specifications,
+ one group per request line.
+Optional property:
+- dma-request-names: list of strings in the same order as the dma-request
+ in the dma-request property.
+
+
+Example:
+
+ i2c1: i2c@1 {
+ ...
+ dma-request = sdma 2 sdma 3;
+ dma-request-names = tx, rx;
+ ...
+ };
diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
index 268163d..7d1f06b 100644
--- a/drivers/of/Kconfig
+++ b/drivers/of/Kconfig
@@ -90,4 +90,9 @@ config OF_PCI_IRQ
help
OpenFirmware PCI IRQ routing helpers
+config OF_DMA
+ def_bool y
+ help
+ Device Tree DMA routing helpers
+
endmenu # OF
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index a73f5a5..6eb50c6 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -12,3 +12,4 @@ obj-$(CONFIG_OF_SELFTEST) += selftest.o
obj-$(CONFIG_OF_MDIO) += of_mdio.o
obj-$(CONFIG_OF_PCI) += of_pci.o
obj-$(CONFIG_OF_PCI_IRQ) += of_pci_irq.o
+obj-$(CONFIG_OF_DMA) += dma.o
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
new file mode 100644
index 000..3315844
--- /dev/null
+++ b/drivers/of/dma.c
@@ -0,0 +1,260 @@
+/*
+ * Device tree helpers for DMA request / controller
+ *
+ * Based on of_gpio.c
+ *
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/module.h
+#include linux/rculist.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/of_dma.h
+
+static LIST_HEAD(of_dma_list);
+
+struct of_dma {
+ struct list_head of_dma_controllers;
+ struct device_node *of_node;
+ int of_dma_n_cells;
+ int (*of_dma_xlate)(struct of_phandle_args *dma_spec, void *data);
+};
+
+/**
+ * of_dma_find_controller() - Find a DMA controller in DT DMA helpers list
+ * @np:device node of DMA controller
+ */
+static struct of_dma *of_dma_find_controller(struct device_node *np)
+{
+ struct of_dma *ofdma;
+
+ list_for_each_entry_rcu(ofdma, of_dma_list, of_dma_controllers) {
+ if (ofdma-of_node == np)
+ return ofdma;
+
Re: [GIT PULL] ARM: OMAP: i2c, gpio, spi, regulator and mmc DTS updates
On Thursday 15 March 2012, Tony Lindgren wrote: * Cousson, Benoit b-cous...@ti.com [120314 16:41]: Hi Tony, Here are the remaining DTS patches for 3.4. On top of the previous pull request, I just added the MMC DTS since the driver adaptation just got queued. It will be still be good to have that for 3.4 if possible, otherwise we will have a bunch of drivers DT adapted but no DTS file to use them :-( This might be doable as a follow-up patch series at the end of the merge window or at -rc1 when the related driver changes have been merged. Arnd and Olof, what do you guys think? I'll have to look at the patches more closely, but from the diffstat it definitely looks ok for a later merge once the driver is in. If you can rebase the branch on top of the mmc tree (or the merge of that tree with whatever else is needed), it should give us a bisectable history and I can stick it into a late/* branch right away. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap2+: add drm device
On Wed, 2012-03-14 at 10:06 -0500, Rob Clark wrote: Well, as I said, it's not an issue for me and from my side it can be improved later. yeah, when CMA is actually merged, there are a few other things I'd like to do to, incl converting omapfb over to use CMA and remove omap_vram.. but I guess those will be other patches. Right, I just realized CMA is not in the kernel, nor does it seem to be in the linux-next. Is there a reason why you want it already merged? Wouldn't it be easier to get it in only when it can actually be used. Especially if there's room for improvement. Tomi signature.asc Description: This is a digitally signed message part
Re: [PATCH] of: Add generic device tree DMA helpers
On Thursday 15 March 2012, Nicolas Ferre wrote:
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be implemented
by the DMA controller can carry any type of dma-request argument.
The DMA client will search its associated DMA controller in the list and
call the registered of_dam_xlate() function to retrieve the request values.
One simple xlate function is provided for the single number type of
request binding.
This implementation is independent from dmaengine so it can also be used
by legacy drivers.
For legacy reason another API will export the DMA request number into a
Linux resource of type IORESOURCE_DMA.
This looks very good. I missed the first version of this patch, but was
thinking of very similar bindings.
+Client drivers should specify the DMA request property using a phandle to
+the controller. If needed, the DMA request identity on that controller is
then
+added followed by optional request specifications.
+
+Required property:
+- dma-request: List of phandle + dma-request + request specifications,
+ one group per request line.
+Optional property:
+- dma-request-names: list of strings in the same order as the dma-request
+ in the dma-request property.
+
+
+Example:
+
+ i2c1: i2c@1 {
+ ...
+ dma-request = sdma 2 sdma 3;
+ dma-request-names = tx, rx;
+ ...
+ };
This is slightly different from how the proposed pwm binding works that
Thierry is working on, which uses an arbitrary property name instead of
requiring the use of a specific property but then allowing to give names
in another property.
I don't care much which way it's done, but please try to agree on one
approach that is used for both.
The one you have here is already used by reg and irq, while the other
one is used in gpio.
+/**
+ * of_get_dma_request() - Get the associated DMA request data
+ * @np: device node to get DMA request from
+ * @index: index of the DMA request
+ * @out_data:a output that can be filled in by the of_dma_xlate()
function
+ *
+ * Returns return value of of_dma_xlate() and fills out_data (if provided).
+ * On error returns the appropriate errno value.
+ */
I would suggest provinding a helper function around this one that directly
calls __dma_request_channel(). AFAICT, you should be able to let the dma
controller provide a generic filter function in struct of_dma that the
driver can use by default.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Add generic device tree DMA helpers
On Thu, Mar 15, 2012 at 09:22:06AM +, Arnd Bergmann wrote: On Thursday 15 March 2012, Nicolas Ferre wrote: Add some basic helpers to retrieve a DMA controller device_node and the DMA request specifications. By making DMA controllers register a generic translation function, we allow the management of any type of DMA requests specification. The void * output of an of_dma_xlate() function that will be implemented by the DMA controller can carry any type of dma-request argument. The DMA client will search its associated DMA controller in the list and call the registered of_dam_xlate() function to retrieve the request values. One simple xlate function is provided for the single number type of request binding. This implementation is independent from dmaengine so it can also be used by legacy drivers. For legacy reason another API will export the DMA request number into a Linux resource of type IORESOURCE_DMA. This looks very good. I missed the first version of this patch, but was thinking of very similar bindings. There's one issue which is concerning me - when we switch OMAP to use DMA engine, it won't use numeric stuff anymore but the DMA engine way of requesting a channel (match function + data). How does that fit into this scheme? -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Add generic device tree DMA helpers
On Thursday 15 March 2012, Russell King - ARM Linux wrote: On Thu, Mar 15, 2012 at 09:22:06AM +, Arnd Bergmann wrote: On Thursday 15 March 2012, Nicolas Ferre wrote: Add some basic helpers to retrieve a DMA controller device_node and the DMA request specifications. By making DMA controllers register a generic translation function, we allow the management of any type of DMA requests specification. The void * output of an of_dma_xlate() function that will be implemented by the DMA controller can carry any type of dma-request argument. The DMA client will search its associated DMA controller in the list and call the registered of_dam_xlate() function to retrieve the request values. One simple xlate function is provided for the single number type of request binding. This implementation is independent from dmaengine so it can also be used by legacy drivers. For legacy reason another API will export the DMA request number into a Linux resource of type IORESOURCE_DMA. This looks very good. I missed the first version of this patch, but was thinking of very similar bindings. There's one issue which is concerning me - when we switch OMAP to use DMA engine, it won't use numeric stuff anymore but the DMA engine way of requesting a channel (match function + data). How does that fit into this scheme? I haven't looked at the omap dma driver much, but if it just uses a channel number, then I'd assume the data would be a single u32 cell with that number, and the match function would be trivial. Is that what you are asking about or am I missing the point? Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Add generic device tree DMA helpers
* Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
[...]
+ i2c1: i2c@1 {
+ ...
+ dma-request = sdma 2 sdma 3;
+ dma-request-names = tx, rx;
+ ...
+ };
This is slightly different from how the proposed pwm binding works that
Thierry is working on, which uses an arbitrary property name instead of
requiring the use of a specific property but then allowing to give names
in another property.
I don't care much which way it's done, but please try to agree on one
approach that is used for both.
The one you have here is already used by reg and irq, while the other
one is used in gpio.
I think we can just use pwm as the fixed property name. Or alternatively do
something along the lines of the regulator bindings, where we use -pwm as
the suffix for specifying PWM devices. For instance if a named PWM is
requested, the OF support code would look for a name-pwm property, while
requesting an unnamed PWM would simply look at the pwm property.
When it comes to the labelling of PWM devices, I don't think both variants
are exclusive. Currently the PWM framework uses name of the user OF device
node for the PWM label. That is, if I have the following in the DTS:
pwm {
...
};
backlight {
compatible = pwm-backlight;
pwm = pwm 0 500;
...
};
Then the PWM will be labelled backlight:
$ cat cat /sys/kernel/debug/pwm
platform/tegra-pwm, 4 PWM devices
pwm-0 (backlight ): requested enabled
pwm-1 ((null) ):
pwm-2 ((null) ):
pwm-3 ((null) ):
So if we decide to explicitly allow specifying names, then we can always add
a pwm-names property (or name-pwm-names respectively) to use as label and
fallback to the user OF device node name if that property is not present.
Thierry
pgpWjFSQszFmu.pgp
Description: PGP signature
Lost fixes?
These fixes are a collection from other people which resolve various issues found with the new kautobuilder. They're now a month old, and as far as I can see, have not been merged into Linus' tree. What's the status of them, and when are they going to be merged? Thanks. arch/arm/mach-omap2/Makefile |5 + arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |2 +- arch/arm/mach-omap2/clock.c |2 +- arch/arm/mach-omap2/clock.h |2 +- arch/arm/mach-omap2/smartreflex.c|2 +- arch/arm/plat-omap/clock.c |2 +- arch/arm/plat-omap/dma.c |2 +- arch/arm/plat-omap/include/plat/clock.h |4 ++-- drivers/cpufreq/Kconfig.arm |6 ++ drivers/cpufreq/Makefile |2 +- drivers/mfd/da9052-spi.c |4 ++-- kernel/irq/chip.c|3 +-- 12 files changed, 19 insertions(+), 17 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ARM: OMAP: fix missing __devexit_p() annotations
Missing __devexit_p() annotations in driver structures for remove functions
marked with __devexit is waiting for build errors to happen, such as:
`omap_system_dma_remove' referenced in section `.data' of arch/arm/plat-omap/bui
lt-in.o: defined in discarded section `.devexit.text' of arch/arm/plat-omap/buil
t-in.o
Add the necessary annotation, and as a result of audit, fix others which
are also missing in arch/arm/*omap*.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/smartreflex.c |2 +-
arch/arm/plat-omap/dma.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 7e755bb..47c77a1 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1012,7 +1012,7 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
}
static struct platform_driver smartreflex_driver = {
- .remove = omap_sr_remove,
+ .remove = __devexit_p(omap_sr_remove),
.driver = {
.name = smartreflex,
},
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index 002fb4d..cb856fe 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2125,7 +2125,7 @@ static int __devexit omap_system_dma_remove(struct
platform_device *pdev)
static struct platform_driver omap_system_dma_driver = {
.probe = omap_system_dma_probe,
- .remove = omap_system_dma_remove,
+ .remove = __devexit_p(omap_system_dma_remove),
.driver = {
.name = omap_dma_system
},
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] ARM: OMAP2+: I2C: always compile I2C reset code, even if I2C driver is not built
During kernel init, we reset all IP blocks on the OMAP that we can, even if there is no driver compiled for that IP block. Unlike most IP blocks, the I2C block requires some extra programming for this to work. This reset code is incorrectly omitted when the I2C driver is deselected. In this circumstance, the build breaks. Fix by compiling the I2C reset code unconditionally. Problem reported by Russell King li...@arm.linux.org.uk. Signed-off-by: Paul Walmsley p...@pwsan.com Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-omap2/Makefile |5 + 1 files changed, 1 insertions(+), 4 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index bd76394..56a6e98 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -4,7 +4,7 @@ # Common support obj-y := id.o io.o control.o mux.o devices.o serial.o gpmc.o timer.o pm.o \ -common.o gpio.o dma.o wd_timer.o display.o +common.o gpio.o dma.o wd_timer.o display.o i2c.o omap-2-3-common= irq.o sdrc.o hwmod-common = omap_hwmod.o \ @@ -182,9 +182,6 @@ obj-$(CONFIG_OMAP_IOMMU)+= iommu2.o iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o obj-y += $(iommu-m) $(iommu-y) -i2c-omap-$(CONFIG_I2C_OMAP):= i2c.o -obj-y += $(i2c-omap-m) $(i2c-omap-y) - ifneq ($(CONFIG_TIDSPBRIDGE),) obj-y += dsp.o endif -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] ARM: OMAP: fix cpufreq build
OMAPs cpufreq requires the frequency table support, but nothing ensures
that this is selected. This can result in configurations which fail to
build:
drivers/built-in.o:(.data+0x5238): undefined reference to
`cpufreq_freq_attr_scaling_available_freqs'
drivers/cpufreq/omap-cpufreq.c:88: undefined reference to
`cpufreq_frequency_table_target'
drivers/cpufreq/omap-cpufreq.c:60: undefined reference to
`cpufreq_frequency_table_verify'
drivers/cpufreq/omap-cpufreq.c:186: undefined reference to
`cpufreq_frequency_table_cpuinfo'
drivers/cpufreq/omap-cpufreq.c:190: undefined reference to
`cpufreq_frequency_table_get_attr'
Fix this by introducing a new configuration variable and having that
select CPU_FREQ_TABLE.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
---
arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |2 +-
arch/arm/mach-omap2/clock.c |2 +-
arch/arm/mach-omap2/clock.h |2 +-
arch/arm/plat-omap/clock.c |2 +-
arch/arm/plat-omap/include/plat/clock.h |4 ++--
drivers/cpufreq/Kconfig.arm |5 +
drivers/cpufreq/Makefile |2 +-
7 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
index 39f9d5a..4705b50 100644
--- a/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
+++ b/arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c
@@ -165,7 +165,7 @@ int omap2_select_table_rate(struct clk *clk, unsigned long
rate)
return 0;
}
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_OMAP2PLUS_CPUFREQ
/*
* Walk PRCM rate table and fillout cpufreq freq_table
* XXX This should be replaced by an OPP layer in the near future
diff --git a/arch/arm/mach-omap2/clock.c b/arch/arm/mach-omap2/clock.c
index f57ed5b..450feb0 100644
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
@@ -536,7 +536,7 @@ struct clk_functions omap2_clk_functions = {
.clk_set_rate = omap2_clk_set_rate,
.clk_set_parent = omap2_clk_set_parent,
.clk_disable_unused = omap2_clk_disable_unused,
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_OMAP2PLUS_CPUFREQ
/* These will be removed when the OPP code is integrated */
.clk_init_cpufreq_table = omap2_clk_init_cpufreq_table,
.clk_exit_cpufreq_table = omap2_clk_exit_cpufreq_table,
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index b8c2a68..f331cfc 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -146,7 +146,7 @@ extern const struct clksel_rate gpt_sys_rates[];
extern const struct clksel_rate gfx_l3_rates[];
extern const struct clksel_rate dsp_ick_rates[];
-#if defined(CONFIG_ARCH_OMAP2) defined(CONFIG_CPU_FREQ)
+#if defined(CONFIG_ARCH_OMAP2) defined(CONFIG_ARM_OMAP2PLUS_CPUFREQ)
extern void omap2_clk_init_cpufreq_table(struct cpufreq_frequency_table
**table);
extern void omap2_clk_exit_cpufreq_table(struct cpufreq_frequency_table
**table);
#else
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 567e4b5..2e2efb6 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -399,7 +399,7 @@ struct clk dummy_ck = {
.ops= clkops_null,
};
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_OMAP2PLUS_CPUFREQ
void clk_init_cpufreq_table(struct cpufreq_frequency_table **table)
{
unsigned long flags;
diff --git a/arch/arm/plat-omap/include/plat/clock.h
b/arch/arm/plat-omap/include/plat/clock.h
index 240a7b9..879ba27 100644
--- a/arch/arm/plat-omap/include/plat/clock.h
+++ b/arch/arm/plat-omap/include/plat/clock.h
@@ -283,7 +283,7 @@ struct clk_functions {
void(*clk_allow_idle)(struct clk *clk);
void(*clk_deny_idle)(struct clk *clk);
void(*clk_disable_unused)(struct clk *clk);
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_OMAP2PLUS_CPUFREQ
void(*clk_init_cpufreq_table)(struct
cpufreq_frequency_table **);
void(*clk_exit_cpufreq_table)(struct
cpufreq_frequency_table **);
#endif
@@ -301,7 +301,7 @@ extern void recalculate_root_clocks(void);
extern unsigned long followparent_recalc(struct clk *clk);
extern void clk_enable_init_clocks(void);
unsigned long omap_fixed_divisor_recalc(struct clk *clk);
-#ifdef CONFIG_CPU_FREQ
+#ifdef CONFIG_ARM_OMAP2PLUS_CPUFREQ
extern void clk_init_cpufreq_table(struct cpufreq_frequency_table **table);
extern void clk_exit_cpufreq_table(struct cpufreq_frequency_table **table);
#endif
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index c8bde43..74e8b55 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -2,6 +2,11 @@
# ARM CPU Frequency scaling drivers
#
+config ARM_OMAP2PLUS_CPUFREQ
+ bool
+ depends on ARCH_OMAP2PLUS
+ select CPU_FREQ_TABLE
+
config ARM_S3C64XX_CPUFREQ
bool Samsung
Re: Lost fixes?
On Thu, Mar 15, 2012 at 10:28:45AM +, Russell King - ARM Linux wrote: These fixes are a collection from other people which resolve various issues found with the new kautobuilder. They're now a month old, and as far as I can see, have not been merged into Linus' tree. What's the status of them, and when are they going to be merged? For the drivers/mfd/da9052-spi.c part: A patch from Axel Lin has been living in my for-next branch for a while now. It's a section mismatch warning fix, so not something I consider worth sending to Linus after the merge window is closed. So it's queued for the next one. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ARM: OMAP: fix missing __devexit_p() annotations
Russell,
On Thu, Mar 15, 2012 at 11:30 AM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
Missing __devexit_p() annotations in driver structures for remove functions
marked with __devexit is waiting for build errors to happen, such as:
`omap_system_dma_remove' referenced in section `.data' of
arch/arm/plat-omap/bui
lt-in.o: defined in discarded section `.devexit.text' of
arch/arm/plat-omap/buil
t-in.o
Add the necessary annotation, and as a result of audit, fix others which
are also missing in arch/arm/*omap*.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/smartreflex.c | 2 +-
arch/arm/plat-omap/dma.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 7e755bb..47c77a1 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1012,7 +1012,7 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
}
static struct platform_driver smartreflex_driver = {
- .remove = omap_sr_remove,
+ .remove = __devexit_p(omap_sr_remove),
.driver = {
.name = smartreflex,
},
Tony already has this change in his master branch, commit
149f1d5c8d2fd6879cdf93ca70f1cb745e698a1e ('ARM: OMAP2+: Fix devexit
for smartreflex when CONFIG_HOTPLUG is not set').
Jean
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V3 2/3] ARM: OMAP2+: powerdomain: Add offset mask fields to struct powerdomain
In case of AM33xx device, there is no consistency between
PWRSTCTRL PWRSTST register offsets in PRM space, for example -
PRM_XXX PWRSTCTRL PWRSTST
===
PRM_PER_MOD: 0x0C, 0x08
PRM_WKUP_MOD: 0x04, 0x08
PRM_MPU_MOD: 0x00, 0x04
PRM_DEVICE_MOD: NA, NA
And also, there is no consistency between bit-offsets inside
PWRSTCTRL PWRSTST register, for example -
PRM_XXX LOGICRET MEMON MEMRET
=
GFX_PWRCTRL: 2,17,6
PER_PWRCTRL: 3,25,29
MPU_PWRCTRL: 2,18,22
WKUP_PWRCTRL: 3,NA,NA
This means, we need to maintain and pass on all this information
through powerdomain handle; so adding fields for,
- PWRSTCTRL/ST register offset
- Logic retention state mask
- mem_on/ret/pwrst/retst mask
Currently, this fields is only applicable and used for AM33XX devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/powerdomain.h | 17 +
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/powerdomain.h
b/arch/arm/mach-omap2/powerdomain.h
index 0d72a8a..8fc50b2 100644
--- a/arch/arm/mach-omap2/powerdomain.h
+++ b/arch/arm/mach-omap2/powerdomain.h
@@ -92,6 +92,15 @@ struct powerdomain;
* @pwrdm_clkdms: Clockdomains in this powerdomain
* @node: list_head linking all powerdomains
* @voltdm_node: list_head linking all powerdomains in a voltagedomain
+ * @pwrstctrl_offs: (AM33XX only) XXX_PWRSTCTRL reg offset from prcm_offs
+ * @pwrstst_offs: (AM33XX only) XXX_PWRSTST reg offset from prcm_offs
+ * @logicretstate_mask: (AM33XX only) mask for logic retention bitfield
+ * in @pwrstctrl_offs
+ * @mem_on_mask: (AM33XX only) mask for mem on bitfield in @pwrstctrl_offs
+ * @mem_ret_mask: (AM33XX only) mask for mem retention bitfield in
@pwrstctrl_offs
+ * @mem_pwrst_mask: (AM33XX only) mask for mem state bitfield in @pwrstst_offs
+ * @mem_retst_mask: (AM33XX only) mask for mem retention state bitfield
+ * in @pwrstctrl_offs
* @state:
* @state_counter:
* @timer:
@@ -121,6 +130,14 @@ struct powerdomain {
unsigned ret_logic_off_counter;
unsigned ret_mem_off_counter[PWRDM_MAX_MEM_BANKS];
+ const u8 pwrstctrl_offs;
+ const u8 pwrstst_offs;
+ const u32 logicretstate_mask;
+ const u32 mem_on_mask[PWRDM_MAX_MEM_BANKS];
+ const u32 mem_ret_mask[PWRDM_MAX_MEM_BANKS];
+ const u32 mem_pwrst_mask[PWRDM_MAX_MEM_BANKS];
+ const u32 mem_retst_mask[PWRDM_MAX_MEM_BANKS];
+
#ifdef CONFIG_PM_DEBUG
s64 timer;
s64 state_timer[PWRDM_MAX_PWRSTS];
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V3 1/3] ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm
In case of AM33XX device, XXX_RSTST register offset is not
consistent across PRM modules/instances,
PRM_XXXRSTST
=
PRM_PER_MOD: 0x04
PRM_WKUP_MOD: 0x0C
PRM_MPU_MOD: NA
PRM_DEVICE_MOD:0x08
This means, we need to pass on XXX_RSTST register offset
information through omap_hwmod data, similar to XXX_RSTCTRL.
Currently, this field is only applicable and used for AM33XX devices.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index ce75c30..1cfa008 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -377,11 +377,13 @@ struct omap_hwmod_omap2_prcm {
* struct omap_hwmod_omap4_prcm - OMAP4-specific PRCM data
* @clkctrl_reg: PRCM address of the clock control register
* @rstctrl_reg: address of the XXX_RSTCTRL register located in the PRM
+ * @rstst_reg: (AM33XX Only) address of the XXX_RSTST register located in the
PRM
* @submodule_wkdep_bit: bit shift of the WKDEP range
*/
struct omap_hwmod_omap4_prcm {
u16 clkctrl_offs;
u16 rstctrl_offs;
+ u16 rstst_offs;
u16 context_offs;
u8 submodule_wkdep_bit;
u8 modulemode;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V3 0/3] ARM: OMAP2+: Add powerdomain PRM support for AM33XX device
After going round-n-round on how to add support for AM33XX family of device into kernel, especially for PRM and CM support, we have decided to handle it separately; as AM33XX-PRCM module is different than OMAP3 and OMAP4 architecture. The difference becomes very interesting/weird when it comes to the consistency for register offsets in PRM address space and bit-field offsets inside PRM registers, So along with Powerdomain data and PRM api's required for AM33XX device, this patch series adds, - XXX_RSTST register offset to struct omap_hwmod_omap4_prcm - PWRSTCTRL PWRSTST register offsets to struct powerdomain - Logicretstate and mem_on/ret/pwrst/retst mask to struct powerdomain Testing: This patch series has been boot tested on AM37xEVM and AM335x based BeagleBone community board. THANKS TO PAUL HERE...for helping and concluding on this, soon I will have similar patch for CM support, then clock-tree and hwmod will follow... Changes from V1 V2: - Rolled back to my original approach, where AM33xx device was handled separately (RFC version). - As per Paul's comments, added Register offsets bit-fields masks. Vaibhav Hiremath (3): ARM: OMAP3/4: omap_hwmod: Add rstst_off field to struct omap_hwmod_omap4_prcm ARM: OMAP2+: powerdomain: Add offset mask fields to struct powerdomain ARM: OMAP3+: am33xx: Add power domain data arch/arm/mach-omap2/Makefile |4 + arch/arm/mach-omap2/io.c |1 + arch/arm/mach-omap2/omap_hwmod.c | 32 ++- arch/arm/mach-omap2/powerdomain.h| 23 ++- arch/arm/mach-omap2/powerdomain33xx.c| 230 + arch/arm/mach-omap2/powerdomains33xx_data.c | 185 + arch/arm/mach-omap2/prm-regbits-33xx.h | 357 ++ arch/arm/mach-omap2/prm33xx.c| 134 ++ arch/arm/mach-omap2/prm33xx.h| 129 + arch/arm/plat-omap/include/plat/omap_hwmod.h |2 + 10 files changed, 1092 insertions(+), 5 deletions(-) create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h create mode 100644 arch/arm/mach-omap2/prm33xx.c create mode 100644 arch/arm/mach-omap2/prm33xx.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH-V3 3/3] ARM: OMAP3+: am33xx: Add powerdomain PRM support
As far as PRM/CM/PRCM modules are concerned, AM33XX device is
different than OMAP3 and OMAP4 architectures; so we need to
handle it separately.
This patch adds support for, Powerdomain, Powerdomain data,
PRM api's required for AM33XX device.
And also, hooks up AM33XX powerdomain to existing OMAP framework.
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Afzal Mohammed af...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Rajendra Nayak rna...@ti.com
---
arch/arm/mach-omap2/Makefile|4 +
arch/arm/mach-omap2/io.c|1 +
arch/arm/mach-omap2/omap_hwmod.c| 32 +++-
arch/arm/mach-omap2/powerdomain.h |6 +-
arch/arm/mach-omap2/powerdomain33xx.c | 230 +
arch/arm/mach-omap2/powerdomains33xx_data.c | 185 ++
arch/arm/mach-omap2/prm-regbits-33xx.h | 357 +++
arch/arm/mach-omap2/prm33xx.c | 134 ++
arch/arm/mach-omap2/prm33xx.h | 129 ++
9 files changed, 1073 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/mach-omap2/powerdomain33xx.c
create mode 100644 arch/arm/mach-omap2/powerdomains33xx_data.c
create mode 100644 arch/arm/mach-omap2/prm-regbits-33xx.h
create mode 100644 arch/arm/mach-omap2/prm33xx.c
create mode 100644 arch/arm/mach-omap2/prm33xx.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index b4ac21e..fd130e5 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -114,6 +114,10 @@ obj-$(CONFIG_ARCH_OMAP3) +=
$(powerdomain-common) \
powerdomain2xxx_3xxx.o \
powerdomains3xxx_data.o \
powerdomains2xxx_3xxx_data.o
+obj-$(CONFIG_SOC_OMAPAM33XX) += $(powerdomain-common) \
+ prm33xx.o \
+ powerdomain33xx.o \
+ powerdomains33xx_data.o
obj-$(CONFIG_ARCH_OMAP4) += $(powerdomain-common) \
powerdomain44xx.o \
powerdomains44xx_data.o
diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
index 11d53df..b594918 100644
--- a/arch/arm/mach-omap2/io.c
+++ b/arch/arm/mach-omap2/io.c
@@ -473,6 +473,7 @@ void __init am33xx_init_early(void)
omap2_set_globals_am33xx();
omap_common_init_early();
am33xx_voltagedomains_init();
+ am33xx_powerdomains_init();
omap3xxx_clk_init();
}
#endif
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 26928c6..d698010 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -151,6 +151,7 @@
#include cminst44xx.h
#include prm2xxx_3xxx.h
#include prm44xx.h
+#include prm33xx.h
#include prminst44xx.h
#include mux.h
@@ -1418,7 +1419,15 @@ static int _assert_hardreset(struct omap_hwmod *oh,
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
- if (cpu_is_omap24xx() || cpu_is_omap34xx())
+ /*
+* cpu_is_omap34xx() is true for am33xx device as well, so
+* fist check for cpu_is_am33xx().
+*/
+ if (cpu_is_am33xx())
+ return am33xx_prm_assert_hardreset(ohri.rst_shift,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.rstctrl_offs);
+ else if (cpu_is_omap24xx() || cpu_is_omap34xx())
return omap2_prm_assert_hardreset(oh-prcm.omap2.module_offs,
ohri.rst_shift);
else if (cpu_is_omap44xx())
@@ -1452,7 +1461,16 @@ static int _deassert_hardreset(struct omap_hwmod *oh,
const char *name)
if (IS_ERR_VALUE(ret))
return ret;
- if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
+ /*
+* cpu_is_omap34xx() is true for am33xx device as well, so
+* fist check for cpu_is_am33xx().
+*/
+ if (cpu_is_am33xx()) {
+ return am33xx_prm_deassert_hardreset(ohri.rst_shift,
+ oh-clkdm-pwrdm.ptr-prcm_offs,
+ oh-prcm.omap4.rstctrl_offs,
+ oh-prcm.omap4.rstst_offs);
+ } else if (cpu_is_omap24xx() || cpu_is_omap34xx()) {
ret = omap2_prm_deassert_hardreset(oh-prcm.omap2.module_offs,
ohri.rst_shift,
ohri.st_shift);
@@ -1494,7 +1512,15 @@ static int _read_hardreset(struct omap_hwmod *oh, const
char *name)
if (IS_ERR_VALUE(ret))
return ret;
- if (cpu_is_omap24xx() ||
[PATCH 0/2] OMAPDSS: DISPC: Enable predecimation for DMA and VRFB
Hi everyone, the following patch set directs to enable predecimation for DMA and VRFB which consists of two pacthes. The first patch is based on code written by Lajos Molnar la...@ti.com in Android Kernel, which updates the code with predecimation logic thereby increasing the downscaling ability of the DISPC module. The second patch is based on code written by Ville Syrjälä ville.syrj...@nokia.com which aims to avoid synclost errors occurring in OMAP3 due to some undocumented horizontal position and timing related limitations which I faced during testing of the previous patch. I have tested these patches successfully on OMAP2, OMAP3 AND OMAP4 on the mainline kernel v3.3-rc5. Horizontal and vertical predecimation worked fine but skewed images along with underflow errors were seen on OMAP2 and OMAP3 during horizontal predecimation which will be addressed in the future patches. All your comments and suggestions are welcome. Regards, Chandrabhanu Chandrabhanu Mahapatra (2): OMAPDSS: DISPC: Enable predecimation OMAPDSS: DISPC: Handle synclost errors in OMAP3 drivers/video/omap2/dss/dispc.c | 323 +-- 1 files changed, 242 insertions(+), 81 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAPDSS: DISPC: Enable predecimation
In OMAP3 and OMAP4, the DISPC Scaler can downscale an image up to 4 times, and
up to 2 times in OMAP2. However, with predecimation, the image can be reduced
to 16 times by fetching only the necessary pixels in memory. Then this
predecimated image can be downscaled further by the DISPC scaler.
Based on the downscaling required, a prior calculation of predecimation values
for width and height of an image is done. Since, Predecimation reduces quality
of an image higher priorty is given to DISPC Scaler for downscaling.
This code was successfully tested on OMAP2, OMAP3 and OMAP4. Horizontal and
vertical predecimation worked fine except for some synclost errors due to
undocumented errata in OMAP3 which are fixed later and skewed images were seen
on OMAP2 and OMAP3 during horizontal predecimation which will be addressed in
the future patches.
This code is based on code written by Lajos Molnar la...@ti.com who had added
predecimation support for NV12/YUV/rotated/SDMA buffers.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 262 +++
1 files changed, 181 insertions(+), 81 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index e1626a1..5a1963e 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1389,7 +1389,7 @@ static void calc_vrfb_rotation_offset(u8 rotation, bool
mirror,
enum omap_color_mode color_mode, bool fieldmode,
unsigned int field_offset,
unsigned *offset0, unsigned *offset1,
- s32 *row_inc, s32 *pix_inc)
+ s32 *row_inc, s32 *pix_inc, int x_predecim, int y_predecim)
{
u8 ps;
@@ -1435,10 +1435,10 @@ static void calc_vrfb_rotation_offset(u8 rotation, bool
mirror,
else
*offset0 = 0;
- *row_inc = pixinc(1 + (screen_width - width) +
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(1, ps);
+ *row_inc = pixinc(1 +
+ (y_predecim * screen_width - x_predecim * width) +
+ (fieldmode ? screen_width : 0), ps);
+ *pix_inc = pixinc(x_predecim, ps);
break;
case OMAP_DSS_ROT_0 + 4:
@@ -1456,10 +1456,10 @@ static void calc_vrfb_rotation_offset(u8 rotation, bool
mirror,
*offset0 = field_offset * screen_width * ps;
else
*offset0 = 0;
- *row_inc = pixinc(1 - (screen_width + width) -
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(1, ps);
+ *row_inc = pixinc(1 -
+ (y_predecim * screen_width + x_predecim * width) -
+ (fieldmode ? screen_width : 0), ps);
+ *pix_inc = pixinc(x_predecim, ps);
break;
default:
@@ -1473,7 +1473,7 @@ static void calc_dma_rotation_offset(u8 rotation, bool
mirror,
enum omap_color_mode color_mode, bool fieldmode,
unsigned int field_offset,
unsigned *offset0, unsigned *offset1,
- s32 *row_inc, s32 *pix_inc)
+ s32 *row_inc, s32 *pix_inc, int x_predecim, int y_predecim)
{
u8 ps;
u16 fbw, fbh;
@@ -1515,10 +1515,14 @@ static void calc_dma_rotation_offset(u8 rotation, bool
mirror,
*offset0 = *offset1 + field_offset * screen_width * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(1 + (screen_width - fbw) +
- (fieldmode ? screen_width : 0),
- ps);
- *pix_inc = pixinc(1, ps);
+ *row_inc = pixinc(1 +
+ (y_predecim * screen_width - fbw * x_predecim) +
+ (fieldmode ? screen_width : 0), ps);
+ if (color_mode == OMAP_DSS_COLOR_YUV2 ||
+ color_mode == OMAP_DSS_COLOR_UYVY)
+ *pix_inc = pixinc(x_predecim, 2 * ps);
+ else
+ *pix_inc = pixinc(x_predecim, ps);
break;
case OMAP_DSS_ROT_90:
*offset1 = screen_width * (fbh - 1) * ps;
@@ -1526,9 +1530,9 @@ static void calc_dma_rotation_offset(u8 rotation, bool
mirror,
*offset0 = *offset1 + field_offset * ps;
else
*offset0 = *offset1;
- *row_inc = pixinc(screen_width * (fbh - 1) + 1 +
- (fieldmode ? 1 : 0), ps);
- *pix_inc = pixinc(-screen_width, ps);
+ *row_inc = pixinc(screen_width * (fbh * x_predecim - 1) +
+ y_predecim + (fieldmode ?
[PATCH 2/2] OMAPDSS: DISPC: Handle synclost errors in OMAP3
In OMAP3 DISPC video overlays suffer from some undocumented horizontal position
and timing related limitations leading to SYNCLOST errors. Whenever the image
window is moved towards the right of the screen SYNCLOST errors become
frequent. Checks have been implemented to see that DISPC driver rejects
configuration exceeding above limitations.
This code was successfully tested on OMAP3. This code is written based on code
written by Ville Syrjälä ville.syrj...@nokia.com in Linux OMAP kernel. Ville
Syrjälä ville.syrj...@nokia.com had added checks for video overlay horizontal
timing and DISPC horizontal blanking length limitations.
Signed-off-by: Chandrabhanu Mahapatra cmahapa...@ti.com
---
drivers/video/omap2/dss/dispc.c | 67 +--
1 files changed, 64 insertions(+), 3 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 5a1963e..ebfa613 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -1622,6 +1622,58 @@ static void calc_dma_rotation_offset(u8 rotation, bool
mirror,
}
}
+static int check_horiz_timing(enum omap_channel channel, u16 pos_x,
+ u16 width, u16 height, u16 out_width, u16 out_height)
+{
+ int DS = DIV_ROUND_UP(height, out_height);
+ struct omap_dss_device *dssdev = dispc_mgr_get_device(channel);
+ struct omap_video_timings t = dssdev-panel.timings;
+ int pcd = REG_GET(DISPC_DIVISORo(channel), 7, 0);
+ unsigned long nonactive, val, blank;
+ static const u8 limits[3] = { 8, 10, 20 };
+ int i;
+
+ nonactive = t.x_res + t.hfp + t.hsw + t.hbp - out_width;
+
+ /*
+* Atleast DS-2 lines must have already been fetched
+* before the display active video period starts.
+*/
+ val = (nonactive - pos_x) * pcd;
+ DSSDBG((nonactive - pos_x) * pcd = %lu,
+max(0, DS - 2) * width = %d\n,
+ val, max(0, DS - 2) * width);
+ if (val max(0, DS - 2) * width)
+ return -EINVAL;
+
+ /*
+* Only one line can be fetched during the overlay active
+* period, the rest have to be fetched during the inactive
+* period.
+*/
+ val = nonactive * pcd;
+ DSSDBG(nonactive * pcd = %lu, max(0, DS - 1) * width = %d\n,
+ val, max(0, DS - 1) * width);
+ if (val max(0, DS - 1) * width)
+ return -EINVAL;
+
+ /*
+* Atleast Ceil(DS) lines should have been loaded during
+* PPL (screen width) + blanking period.
+*/
+ i = 0;
+ if (out_height height)
+ i++;
+ if (out_width width)
+ i++;
+ blank = (t.hbp + t.hsw + t.hfp) * pcd;
+ DSSDBG(blanking period + ppl = %lu (limit = %u)\n, blank, limits[i]);
+ if (blank = limits[i])
+ return -EINVAL;
+
+ return 0;
+}
+
static unsigned long calc_fclk_five_taps(enum omap_channel channel, u16 width,
u16 height, u16 out_width, u16 out_height,
enum omap_color_mode color_mode)
@@ -1702,7 +1754,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
enum omap_channel channel, u16 width, u16 height,
u16 out_width, u16 out_height,
enum omap_color_mode color_mode, bool *five_taps,
- int *x_predecim, int *y_predecim)
+ int *x_predecim, int *y_predecim, u16 pos_x)
{
struct omap_overlay *ovl = omap_dss_get_overlay(plane);
const int maxdownscale = dss_feat_get_param_max(FEAT_PARAM_DOWNSCALE);
@@ -1778,6 +1830,9 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
fclk = calc_fclk_five_taps(channel, in_width, in_height,
out_width, out_height, color_mode);
+ error = check_horiz_timing(channel, pos_x, in_width,
+ in_height, out_width, out_height);
+
if (in_width maxsinglelinewidth)
if (in_height out_height
in_height out_height * 2)
@@ -1785,7 +1840,7 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
if (!*five_taps)
fclk = calc_fclk(channel, in_width, in_height,
out_width, out_height);
- error = (in_width maxsinglelinewidth * 2 ||
+ error = (error || in_width maxsinglelinewidth * 2 ||
(in_width maxsinglelinewidth *five_taps) ||
!fclk || fclk dispc_fclk_rate());
if (error) {
@@ -1801,6 +1856,12 @@ static int dispc_ovl_calc_scaling(enum omap_plane plane,
} while (decim_x = *x_predecim decim_y = *y_predecim
error);
+
Re: [PATCH] omap2+: add drm device
On Thu, Mar 15, 2012 at 3:46 AM, Tomi Valkeinen tomi.valkei...@ti.com wrote: On Wed, 2012-03-14 at 10:06 -0500, Rob Clark wrote: Well, as I said, it's not an issue for me and from my side it can be improved later. yeah, when CMA is actually merged, there are a few other things I'd like to do to, incl converting omapfb over to use CMA and remove omap_vram.. but I guess those will be other patches. Right, I just realized CMA is not in the kernel, nor does it seem to be in the linux-next. Is there a reason why you want it already merged? Wouldn't it be easier to get it in only when it can actually be used. Especially if there's room for improvement. Some folks are already pulling CMA into product kernels for various reasons.. keeping this w/ #ifdef CONFIG_CMA guards seemed like it would make their life a bit easier. But if people feel strongly about it, I can strip that out. BR, -R Tomi ___ dri-devel mailing list dri-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] mmc: host: omap_hsmmc: trivial cleanups
On Wed, Mar 14, 2012 at 2:48 PM, Felipe Balbi ba...@ti.com wrote:
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneded
dereferences and drop unneded accesses to the platform_device
structure.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 147
-
1 file changed, 70 insertions(+), 77 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..11fef49 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2104,30 +2104,28 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
struct resource *res;
- if (host) {
- pm_runtime_get_sync(host-dev);
- mmc_remove_host(host-mmc);
- if (host-use_reg)
- omap_hsmmc_reg_put(host);
- if (host-pdata-cleanup)
- host-pdata-cleanup(pdev-dev);
- free_irq(host-irq, host);
- if (mmc_slot(host).card_detect_irq)
- free_irq(mmc_slot(host).card_detect_irq, host);
-
- pm_runtime_put_sync(host-dev);
- pm_runtime_disable(host-dev);
- clk_put(host-fclk);
- if (host-got_dbclk) {
- clk_disable(host-dbclk);
- clk_put(host-dbclk);
- }
Hi,
Checking for host NULL is added in suspend/resume, however it is missing in
.remove, is it intentional ?
+ pm_runtime_get_sync(host-dev);
+ mmc_remove_host(host-mmc);
+ if (host-use_reg)
+ omap_hsmmc_reg_put(host);
+ if (host-pdata-cleanup)
+ host-pdata-cleanup(pdev-dev);
+ free_irq(host-irq, host);
+ if (mmc_slot(host).card_detect_irq)
+ free_irq(mmc_slot(host).card_detect_irq, host);
- mmc_free_host(host-mmc);
- iounmap(host-base);
- omap_hsmmc_gpio_free(pdev-dev.platform_data);
+ pm_runtime_put_sync(host-dev);
+ pm_runtime_disable(host-dev);
+ clk_put(host-fclk);
+ if (host-got_dbclk) {
+ clk_disable(host-dbclk);
+ clk_put(host-dbclk);
}
+ mmc_free_host(host-mmc);
+ iounmap(host-base);
+ omap_hsmmc_gpio_free(pdev-dev.platform_data);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res)
release_mem_region(res-start, resource_size(res));
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] mmc: host: omap_hsmmc: trivial cleanups
Hi,
On Thu, Mar 15, 2012 at 07:20:22PM +0530, T Krishnamoorthy, Balaji wrote:
On Wed, Mar 14, 2012 at 2:48 PM, Felipe Balbi ba...@ti.com wrote:
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneded
dereferences and drop unneded accesses to the platform_device
structure.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 147
-
1 file changed, 70 insertions(+), 77 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..11fef49 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2104,30 +2104,28 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
struct resource *res;
- if (host) {
- pm_runtime_get_sync(host-dev);
- mmc_remove_host(host-mmc);
- if (host-use_reg)
- omap_hsmmc_reg_put(host);
- if (host-pdata-cleanup)
- host-pdata-cleanup(pdev-dev);
- free_irq(host-irq, host);
- if (mmc_slot(host).card_detect_irq)
- free_irq(mmc_slot(host).card_detect_irq, host);
-
- pm_runtime_put_sync(host-dev);
- pm_runtime_disable(host-dev);
- clk_put(host-fclk);
- if (host-got_dbclk) {
- clk_disable(host-dbclk);
- clk_put(host-dbclk);
- }
Hi,
Checking for host NULL is added in suspend/resume, however it is missing in
.remove, is it intentional ?
you mean:
if (!host)
return 0;
???
That's intentional. We know platform_set_drvdata() is called on probe,
and we can only reach .remove if .probe was called first. So we can make
the assumption that dev-p-driver_data will always be valid on .remove.
If it isn't, it's a bug on driver core which we want to catch ASAP, so
it deserves to oops.
--
balbi
signature.asc
Description: Digital signature
Re: [GIT PULL] cpufreq: OMAP updates for v3.4
Grazvydas Ignotas nota...@gmail.com writes: On Wed, Mar 14, 2012 at 7:22 PM, Kevin Hilman khil...@ti.com wrote: Grazvydas Ignotas nota...@gmail.com writes: [...] Russell King (1): cpufreq: OMAP driver depends CPUfreq tables It seems this one got messed up, it says default ARCH_OMAP2PLUS instead of depends. That was intentional. What do you think is messed up about it? It's the same as saying: depends on ARCH_OMAP2PLUS default y Hm, somehow I've never encountered this syntax, but it more looks like it means default y if ARCH_OMAP2PLUS instead of that. Checked this with menuconfig now: default ARCH_OMAP2PLUS resolves to: ARCH_HAS_CPUFREQ [=y] CPU_FREQ [=y] ARM [=y] ..which might cause build break when OMAP is not selected, and depends on ARCH_OMAP2PLUS default y resolves to: ARCH_HAS_CPUFREQ [=y] CPU_FREQ [=y] ARM [=y] ARCH_OMAP2PLUS [=y] ..which should be randconfig friendly. Yeah, you're right. Feel free to send a patch using your comments above to describe that the current form is not randconfig friendly. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/6] mmc: host: omap_hsmmc: trivial cleanups
On Thu, Mar 15, 2012 at 7:30 PM, Felipe Balbi ba...@ti.com wrote:
Hi,
On Thu, Mar 15, 2012 at 07:20:22PM +0530, T Krishnamoorthy, Balaji wrote:
On Wed, Mar 14, 2012 at 2:48 PM, Felipe Balbi ba...@ti.com wrote:
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneded
dereferences and drop unneded accesses to the platform_device
structure.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 147
-
1 file changed, 70 insertions(+), 77 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fd0c661..11fef49 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2104,30 +2104,28 @@ static int omap_hsmmc_remove(struct
platform_device *pdev)
struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
struct resource *res;
- if (host) {
- pm_runtime_get_sync(host-dev);
- mmc_remove_host(host-mmc);
- if (host-use_reg)
- omap_hsmmc_reg_put(host);
- if (host-pdata-cleanup)
- host-pdata-cleanup(pdev-dev);
- free_irq(host-irq, host);
- if (mmc_slot(host).card_detect_irq)
- free_irq(mmc_slot(host).card_detect_irq, host);
-
- pm_runtime_put_sync(host-dev);
- pm_runtime_disable(host-dev);
- clk_put(host-fclk);
- if (host-got_dbclk) {
- clk_disable(host-dbclk);
- clk_put(host-dbclk);
- }
Hi,
Checking for host NULL is added in suspend/resume, however it is missing in
.remove, is it intentional ?
you mean:
if (!host)
return 0;
???
That's intentional. We know platform_set_drvdata() is called on probe,
and we can only reach .remove if .probe was called first. So we can make
the assumption that dev-p-driver_data will always be valid on .remove.
If it isn't, it's a bug on driver core which we want to catch ASAP, so
it deserves to oops.
Agreed.
--
balbi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/8][git pull] mmc: omap: Assorted fixes for 3.4 merge window
Chris, Here are a group of fixes posted by Felipe and Balaji for the OMAP hsmmc driver in the past few days. I've rebased them to the lastest mmc-next and posted them here again. These have also been tested on OMAP4 development platform. Please feel to apply directly or pull if that's convenient. The following changes since commit 5f0390f10c0e9c9c504cdbf4af802252628a2490: mmc: omap_hsmmc: Avoid a regulator voltage change with dt (2012-03-14 11:33:20 -0400) are available in the git repository at: git://github.com/svenkatr/linux.git omap-mmc-pending-for-3.4 for you to fetch changes up to a6caaa13374ab72e37f9cb2e4cebfe3d266fbaf3: mmc: omap4: hsmmc: fix module re-insertion (2012-03-15 19:45:49 +0530) Balaji T K (5): mmc: omap: Enable Auto CMD12 mmc: omap: add DDR support to omap_hsmmc mmc: omap: use runtime put sync in probe error patch mmc: omap: context save after enabling runtime pm mmc: omap4: hsmmc: fix module re-insertion Felipe Balbi (3): mmc: host: omap_hsmmc: trivial cleanups mmc: host: omap_hsmmc: make it behave well as a module mmc: host: omap_hsmmc: convert to module_platform_driver drivers/mmc/host/omap_hsmmc.c | 203 ++--- 1 file changed, 98 insertions(+), 105 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 1/8] mmc: omap: Enable Auto CMD12
From: Balaji T K balaj...@ti.com
Enable Auto-CMD12 for multi block read/write on HSMMC
Tested on OMAP4430, OMAP3430 and OMAP2430 SDP
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f29e1a2..b1e9be7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -85,6 +85,7 @@
#define BRR_ENABLE (1 5)
#define DTO_ENABLE (1 20)
#define INIT_STREAM(1 1)
+#define ACEN_ACMD12(1 2)
#define DP_SELECT (1 21)
#define DDIR (1 4)
#define DMA_EN 0x1
@@ -115,6 +116,7 @@
#define OMAP_MMC_MAX_CLOCK 5200
#define DRIVER_NAMEomap_hsmmc
+#define AUTO_CMD12 (1 0)/* Auto CMD12 support */
/*
* One controller can have multiple slots, like on some omap boards using
* omap.c controller driver. Luckily this is not currently done on any known
@@ -175,6 +177,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ unsigned intflags;
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
@@ -766,6 +769,8 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
cmdtype = 0x3;
cmdreg = (cmd-opcode 24) | (resptype 16) | (cmdtype 22);
+ if ((host-flags AUTO_CMD12) mmc_op_multi(cmd-opcode))
+ cmdreg |= ACEN_ACMD12;
if (data) {
cmdreg |= DP_SELECT | MSBS | BCE;
@@ -837,11 +842,16 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host, struct
mmc_data *data)
else
data-bytes_xfered = 0;
- if (!data-stop) {
+ if (data-stop ((!(host-flags AUTO_CMD12)) || data-error))
+ omap_hsmmc_start_command(host, data-stop, NULL);
+ else {
+ if (data-stop)
+ data-stop-resp[0] = OMAP_HSMMC_READ(host-base,
+ RSP76);
omap_hsmmc_request_done(host, data-mrq);
- return;
}
- omap_hsmmc_start_command(host, data-stop, NULL);
+
+ return;
}
/*
@@ -1826,6 +1836,7 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
host-mapbase = res-start;
host-base = ioremap(host-mapbase, SZ_4K);
host-power_mode = MMC_POWER_OFF;
+ host-flags = AUTO_CMD12;
host-next_data.cookie = 1;
platform_set_drvdata(pdev, host);
--
1.7.10.rc0.41.gfa678
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 2/8] mmc: omap: add DDR support to omap_hsmmc
From: Balaji T K balaj...@ti.com
Add Dual data rate support for omap_hsmmc
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b1e9be7..db8af43 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -92,6 +92,7 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define DDR(1 19)
#define DW8(1 5)
#define CC 0x1
#define TC 0x02
@@ -523,6 +524,10 @@ static void omap_hsmmc_set_bus_width(struct
omap_hsmmc_host *host)
u32 con;
con = OMAP_HSMMC_READ(host-base, CON);
+ if (ios-timing == MMC_TIMING_UHS_DDR50)
+ con |= DDR; /* configure in DDR mode */
+ else
+ con = ~DDR;
switch (ios-bus_width) {
case MMC_BUS_WIDTH_8:
OMAP_HSMMC_WRITE(host-base, CON, con | DW8);
--
1.7.10.rc0.41.gfa678
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 3/8] mmc: omap: use runtime put sync in probe error patch
From: Balaji T K balaj...@ti.com
pm_runtime_put_sync instead of autosuspend pm runtime API
because iounmap(host-base) follows immediately.
Reported-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index db8af43..0f8d34b 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2014,8 +2014,7 @@ err_reg:
err_irq_cd_init:
free_irq(host-irq, host);
err_irq:
- pm_runtime_mark_last_busy(host-dev);
- pm_runtime_put_autosuspend(host-dev);
+ pm_runtime_put_sync(host-dev);
pm_runtime_disable(host-dev);
clk_put(host-fclk);
if (host-got_dbclk) {
--
1.7.10.rc0.41.gfa678
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 4/8] mmc: omap: context save after enabling runtime pm
From: Balaji T K balaj...@ti.com
call context save api after enabling runtime pm
to make sure register access in context save api happens with clk enabled.
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0f8d34b..9fa2f39 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1871,8 +1871,6 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
goto err1;
}
- omap_hsmmc_context_save(host);
-
if (host-pdata-controller_flags OMAP_HSMMC_BROKEN_MULTIBLOCK_READ) {
dev_info(pdev-dev, multiblock reads disabled due to 35xx
erratum 2.1.1.128; MMC read performance may suffer\n);
mmc-caps2 |= MMC_CAP2_NO_MULTI_READ;
@@ -1883,6 +1881,8 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
pm_runtime_set_autosuspend_delay(host-dev, MMC_AUTOSUSPEND_DELAY);
pm_runtime_use_autosuspend(host-dev);
+ omap_hsmmc_context_save(host);
+
if (cpu_is_omap2430()) {
host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
/*
--
1.7.10.rc0.41.gfa678
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 5/8] mmc: host: omap_hsmmc: trivial cleanups
From: Felipe Balbi ba...@ti.com
a bunch of non-functional cleanups to the omap_hsmmc
driver.
It basically decreases indentation level, drop unneded
dereferences and drop unneded accesses to the platform_device
structure.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 147 -
1 file changed, 70 insertions(+), 77 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 9fa2f39..6b30782 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2037,30 +2037,28 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
struct resource *res;
- if (host) {
- pm_runtime_get_sync(host-dev);
- mmc_remove_host(host-mmc);
- if (host-use_reg)
- omap_hsmmc_reg_put(host);
- if (host-pdata-cleanup)
- host-pdata-cleanup(pdev-dev);
- free_irq(host-irq, host);
- if (mmc_slot(host).card_detect_irq)
- free_irq(mmc_slot(host).card_detect_irq, host);
-
- pm_runtime_put_sync(host-dev);
- pm_runtime_disable(host-dev);
- clk_put(host-fclk);
- if (host-got_dbclk) {
- clk_disable(host-dbclk);
- clk_put(host-dbclk);
- }
+ pm_runtime_get_sync(host-dev);
+ mmc_remove_host(host-mmc);
+ if (host-use_reg)
+ omap_hsmmc_reg_put(host);
+ if (host-pdata-cleanup)
+ host-pdata-cleanup(pdev-dev);
+ free_irq(host-irq, host);
+ if (mmc_slot(host).card_detect_irq)
+ free_irq(mmc_slot(host).card_detect_irq, host);
- mmc_free_host(host-mmc);
- iounmap(host-base);
- omap_hsmmc_gpio_free(pdev-dev.platform_data);
+ pm_runtime_put_sync(host-dev);
+ pm_runtime_disable(host-dev);
+ clk_put(host-fclk);
+ if (host-got_dbclk) {
+ clk_disable(host-dbclk);
+ clk_put(host-dbclk);
}
+ mmc_free_host(host-mmc);
+ iounmap(host-base);
+ omap_hsmmc_gpio_free(pdev-dev.platform_data);
+
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res)
release_mem_region(res-start, resource_size(res));
@@ -2073,49 +2071,45 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
static int omap_hsmmc_suspend(struct device *dev)
{
int ret = 0;
- struct platform_device *pdev = to_platform_device(dev);
- struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
+ struct omap_hsmmc_host *host = dev_get_drvdata(dev);
- if (host host-suspended)
+ if (!host)
return 0;
- if (host) {
- pm_runtime_get_sync(host-dev);
- host-suspended = 1;
- if (host-pdata-suspend) {
- ret = host-pdata-suspend(pdev-dev,
- host-slot_id);
- if (ret) {
- dev_dbg(mmc_dev(host-mmc),
- Unable to handle MMC board
-level suspend\n);
- host-suspended = 0;
- return ret;
- }
- }
- ret = mmc_suspend_host(host-mmc);
+ if (host host-suspended)
+ return 0;
+ pm_runtime_get_sync(host-dev);
+ host-suspended = 1;
+ if (host-pdata-suspend) {
+ ret = host-pdata-suspend(dev, host-slot_id);
if (ret) {
+ dev_dbg(dev, Unable to handle MMC board
+level suspend\n);
host-suspended = 0;
- if (host-pdata-resume) {
- ret = host-pdata-resume(pdev-dev,
- host-slot_id);
- if (ret)
- dev_dbg(mmc_dev(host-mmc),
- Unmask interrupt failed\n);
- }
- goto err;
+ return ret;
}
+ }
+ ret = mmc_suspend_host(host-mmc);
- if (!(host-mmc-pm_flags MMC_PM_KEEP_POWER)) {
- omap_hsmmc_disable_irq(host);
- OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) ~SDBP);
+ if (ret) {
+ host-suspended = 0;
+ if (host-pdata-resume) {
+ ret = host-pdata-resume(dev, host-slot_id);
+
[PATCH RESEND 6/8] mmc: host: omap_hsmmc: make it behave well as a module
From: Felipe Balbi ba...@ti.com
if we put probe() on __init section, that will never
work for multiple module insertions/removals.
In order to make it work properly, move probe to
__devinit section and use platform_driver_register()
instead of platform_driver_probe().
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 6b30782..67cb63e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1780,7 +1780,7 @@ static inline struct omap_mmc_platform_data
}
#endif
-static int __init omap_hsmmc_probe(struct platform_device *pdev)
+static int __devinit omap_hsmmc_probe(struct platform_device *pdev)
{
struct omap_mmc_platform_data *pdata = pdev-dev.platform_data;
struct mmc_host *mmc;
@@ -2032,7 +2032,7 @@ err:
return ret;
}
-static int omap_hsmmc_remove(struct platform_device *pdev)
+static int __devexit omap_hsmmc_remove(struct platform_device *pdev)
{
struct omap_hsmmc_host *host = platform_get_drvdata(pdev);
struct resource *res;
@@ -2190,7 +2190,8 @@ static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
};
static struct platform_driver omap_hsmmc_driver = {
- .remove = omap_hsmmc_remove,
+ .probe = omap_hsmmc_probe,
+ .remove = __devexit_p(omap_hsmmc_remove),
.driver = {
.name = DRIVER_NAME,
.owner = THIS_MODULE,
@@ -2202,7 +2203,7 @@ static struct platform_driver omap_hsmmc_driver = {
static int __init omap_hsmmc_init(void)
{
/* Register the MMC driver */
- return platform_driver_probe(omap_hsmmc_driver, omap_hsmmc_probe);
+ return platform_driver_register(omap_hsmmc_driver);
}
static void __exit omap_hsmmc_cleanup(void)
--
1.7.10.rc0.41.gfa678
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 7/8] mmc: host: omap_hsmmc: convert to module_platform_driver
From: Felipe Balbi ba...@ti.com
this will delete some boilerplate code, no functional
changes.
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mmc/host/omap_hsmmc.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 67cb63e..4476b26 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2200,21 +2200,7 @@ static struct platform_driver omap_hsmmc_driver = {
},
};
-static int __init omap_hsmmc_init(void)
-{
- /* Register the MMC driver */
- return platform_driver_register(omap_hsmmc_driver);
-}
-
-static void __exit omap_hsmmc_cleanup(void)
-{
- /* Unregister MMC driver */
- platform_driver_unregister(omap_hsmmc_driver);
-}
-
-module_init(omap_hsmmc_init);
-module_exit(omap_hsmmc_cleanup);
-
+module_platform_driver(omap_hsmmc_driver);
MODULE_DESCRIPTION(OMAP High Speed Multimedia Card driver);
MODULE_LICENSE(GPL);
MODULE_ALIAS(platform: DRIVER_NAME);
--
1.7.10.rc0.41.gfa678
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RESEND 8/8] mmc: omap4: hsmmc: fix module re-insertion
From: Balaji T K balaj...@ti.com OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due to incorrect register base. Fix this by updating the ioremap base address only. Signed-off-by: Balaji T K balaj...@ti.com --- drivers/mmc/host/omap_hsmmc.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 4476b26..f324cf4 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1813,8 +1813,6 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev) if (res == NULL || irq 0) return -ENXIO; - res-start += pdata-reg_offset; - res-end += pdata-reg_offset; res = request_mem_region(res-start, resource_size(res), pdev-name); if (res == NULL) return -EBUSY; @@ -1838,7 +1836,7 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev) host-dma_ch= -1; host-irq = irq; host-slot_id = 0; - host-mapbase = res-start; + host-mapbase = res-start + pdata-reg_offset; host-base = ioremap(host-mapbase, SZ_4K); host-power_mode = MMC_POWER_OFF; host-flags = AUTO_CMD12; -- 1.7.10.rc0.41.gfa678 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND 1/8] mmc: omap: Enable Auto CMD12
Hi,
On Thu, Mar 15, 2012 at 08:03:35PM +0530, Venkatraman S wrote:
From: Balaji T K balaj...@ti.com
@@ -766,6 +769,8 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
cmdtype = 0x3;
cmdreg = (cmd-opcode 24) | (resptype 16) | (cmdtype 22);
+ if ((host-flags AUTO_CMD12) mmc_op_multi(cmd-opcode))
This should have braces too.
@@ -837,11 +842,16 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host,
struct mmc_data *data)
else
data-bytes_xfered = 0;
- if (!data-stop) {
+ if (data-stop ((!(host-flags AUTO_CMD12)) || data-error))
+ omap_hsmmc_start_command(host, data-stop, NULL);
+ else {
+ if (data-stop)
+ data-stop-resp[0] = OMAP_HSMMC_READ(host-base,
+ RSP76);
omap_hsmmc_request_done(host, data-mrq);
- return;
}
- omap_hsmmc_start_command(host, data-stop, NULL);
+
+ return;
return is unnecessary.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH RESEND 1/8] mmc: omap: Enable Auto CMD12
On Thu, Mar 15, 2012 at 08:03:35PM +0530, Venkatraman S wrote: From: Balaji T K balaj...@ti.com Enable Auto-CMD12 for multi block read/write on HSMMC Tested on OMAP4430, OMAP3430 and OMAP2430 SDP Signed-off-by: Balaji T K balaj...@ti.com BTW, since patches are flowing through you now, they should have your SoB line. -- balbi signature.asc Description: Digital signature
Re: [PATCH RESEND 4/8] mmc: omap: context save after enabling runtime pm
On Thu, Mar 15, 2012 at 08:03:38PM +0530, Venkatraman S wrote: From: Balaji T K balaj...@ti.com call context save api after enabling runtime pm to make sure register access in context save api happens with clk enabled. Signed-off-by: Balaji T K balaj...@ti.com Cc stable ? -- balbi signature.asc Description: Digital signature
Re: [PATCH RESEND 3/8] mmc: omap: use runtime put sync in probe error patch
On Thu, Mar 15, 2012 at 08:03:37PM +0530, Venkatraman S wrote: From: Balaji T K balaj...@ti.com pm_runtime_put_sync instead of autosuspend pm runtime API because iounmap(host-base) follows immediately. Reported-by: Rajendra Nayak rna...@ti.com Signed-off-by: Balaji T K balaj...@ti.com should this one go to stable too ? -- balbi signature.asc Description: Digital signature
Re: [PATCH RESEND 8/8] mmc: omap4: hsmmc: fix module re-insertion
Hi, On Thu, Mar 15, 2012 at 08:03:42PM +0530, Venkatraman S wrote: From: Balaji T K balaj...@ti.com OMAP4 and OMAP3 HSMMC IP registers differ by 0x100 offset. Addng the offset to platform_device resource structure increments the start address for every insmod operation. MMC command fails on re-insertion as module due to incorrect register base. Fix this by updating the ioremap base address only. Signed-off-by: Balaji T K balaj...@ti.com --- drivers/mmc/host/omap_hsmmc.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 4476b26..f324cf4 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1813,8 +1813,6 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev) if (res == NULL || irq 0) return -ENXIO; - res-start += pdata-reg_offset; - res-end += pdata-reg_offset; res = request_mem_region(res-start, resource_size(res), pdev-name); if (res == NULL) return -EBUSY; @@ -1838,7 +1836,7 @@ static int __devinit omap_hsmmc_probe(struct platform_device *pdev) host-dma_ch= -1; host-irq = irq; host-slot_id = 0; - host-mapbase = res-start; + host-mapbase = res-start + pdata-reg_offset; could this be done with a revision check at some point so we drop the pdata requirement ? Not part of $SUBJECT though, because you're just moving the increment. -- balbi signature.asc Description: Digital signature
Re: [PATCH RESEND 4/8] mmc: omap: context save after enabling runtime pm
On Thursday 15 March 2012 08:03 PM, Venkatraman S wrote:
From: Balaji T K balaj...@ti.com
call context save api after enabling runtime pm
to make sure register access in context save api
If I am not mistaken the api would
store the number of power state changes and accesses no registers.
Am I missing something?
happens with clk enabled.
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 0f8d34b..9fa2f39 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1871,8 +1871,6 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
goto err1;
}
- omap_hsmmc_context_save(host);
-
if (host-pdata-controller_flags OMAP_HSMMC_BROKEN_MULTIBLOCK_READ) {
dev_info(pdev-dev, multiblock reads disabled due to 35xx
erratum 2.1.1.128; MMC read performance may suffer\n);
mmc-caps2 |= MMC_CAP2_NO_MULTI_READ;
@@ -1883,6 +1881,8 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
pm_runtime_set_autosuspend_delay(host-dev, MMC_AUTOSUSPEND_DELAY);
pm_runtime_use_autosuspend(host-dev);
+ omap_hsmmc_context_save(host);
+
if (cpu_is_omap2430()) {
host-dbclk = clk_get(pdev-dev, mmchsdb_fck);
/*
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 5/8] ARM: OMAP2+: hwmod: ensure that SYSCONFIG bits are reprogrammed after a reset
On Thu, Mar 15, 2012 at 1:25 AM, Paul Walmsley p...@pwsan.com wrote: Hola Omar, Hola :) On Wed, 14 Mar 2012, Ramirez Luna, Omar wrote: If we reached here the reset lines will be asserted, and then the code below touches sysc registers on a module under reset. Do you know of any case where this would be a problem? Seems like it would only affect IP blocks that have both hard reset lines and SYSCONFIG registers, and as far as I know, we don't have any of those defined? MMU (not yet mainlined) has both, a reset line and a sysconfig. I have been holding the hwmod for some time, but now that rpmsg/remoteproc is going to mainline it could make use of it along with omap3isp, however now I need to define functions to handle the reset lines (although I was fine with hwmod handling it). AFAIKnew, hwmod handling the reset line was fine (IMHO), the only 2 things were: - For the drivers to somehow make use of shutdown/enable if they needed they hwmod under reset and out. - The annoying: hwmod XX failed to hardreset because of the wrong reset sequence but causing no functional issues. Regards, Omar -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517evm
On Mon, Mar 12, 2012 at 02:55:02PM +0100, Yegor Yefremov wrote: Am 09.03.2012 18:22, schrieb George C. Huntington, III: I would like to make the newer kernel (3.x) work with the AM3517EVM. I have a 2.6.32 and a 2.6.33 that run well on the board, but the recent kernels have kernel panics before even running init. where should I start? is there a better place to pursue this? Have you tried this one? http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=summary I have this one booting one month ago, but I checked out the kernel today and it hangs somewhere: Starting kernel ... Uncompressing Linux... done, booting the kernel. This looks like you have your console device set to ttyS2 instead of ttyO2. Which branch of that repository did you use? Mark -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517evm
Am 15.03.2012 16:43, schrieb Mark A. Greer: On Mon, Mar 12, 2012 at 02:55:02PM +0100, Yegor Yefremov wrote: Am 09.03.2012 18:22, schrieb George C. Huntington, III: I would like to make the newer kernel (3.x) work with the AM3517EVM. I have a 2.6.32 and a 2.6.33 that run well on the board, but the recent kernels have kernel panics before even running init. where should I start? is there a better place to pursue this? Have you tried this one? http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=summary I have this one booting one month ago, but I checked out the kernel today and it hangs somewhere: Starting kernel ... Uncompressing Linux... done, booting the kernel. This looks like you have your console device set to ttyS2 instead of ttyO2. Which branch of that repository did you use? My kernel params: CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 and I force them, so bootloader has nothing to say. I'm using master branch. Yegor -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
arm: omap3: pm34xx.c: Some minor fixups
I found a some minor issues when looking through pm34xx.c recently so these patches try to address them. My apologies if they are already fixed in another branch somewhere. Based on latest k.o. master branch. Mark -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] arm: omap3: pm34xx.c: Fix :omap3_pm_init() error out paths
It appears that the error paths were overlooked when the
omap3_pm_init() routine had the prcm chain handler code
added. Fix this by adding a goto target and reordering
the error handling code. Also fix how the irq argument
for free_irq() is determined.
CC: Tero Kristo t-kri...@ti.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/pm34xx.c | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 27fc7a2..af8d741 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -817,13 +817,13 @@ static int __init omap3_pm_init(void)
if (ret) {
pr_err(pm: Failed to request pm_io irq\n);
- goto err1;
+ goto err2;
}
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
printk(KERN_ERR Failed to setup powerdomains\n);
- goto err2;
+ goto err3;
}
(void) clkdm_for_each(clkdms_setup, NULL);
@@ -831,7 +831,8 @@ static int __init omap3_pm_init(void)
mpu_pwrdm = pwrdm_lookup(mpu_pwrdm);
if (mpu_pwrdm == NULL) {
printk(KERN_ERR Failed to get mpu_pwrdm\n);
- goto err2;
+ ret = -EINVAL;
+ goto err3;
}
neon_pwrdm = pwrdm_lookup(neon_pwrdm);
@@ -879,14 +880,17 @@ static int __init omap3_pm_init(void)
}
omap3_save_scratchpad_contents();
-err1:
return ret;
-err2:
- free_irq(INT_34XX_PRCM_MPU_IRQ, NULL);
+
+err3:
list_for_each_entry_safe(pwrst, tmp, pwrst_list, node) {
list_del(pwrst-node);
kfree(pwrst);
}
+ free_irq(omap_prcm_event_to_irq(io), omap3_pm_init);
+err2:
+ free_irq(omap_prcm_event_to_irq(wkup), NULL);
+err1:
return ret;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] arm: omap3: pm34xx.c: Replace printk() with appropriate pr_*()
Currently, pm34xx.c has a mix of printk() and pr_*() statements
so replace the printk() statements with the equivalent pr_*()
statements.
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/pm34xx.c | 17 -
1 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index af8d741..495e509 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -166,8 +166,7 @@ static void omap3_save_secure_ram_context(void)
pwrdm_set_next_pwrst(mpu_pwrdm, mpu_next_state);
/* Following is for error tracking, it should not happen */
if (ret) {
- printk(KERN_ERR save_secure_sram() returns %08x\n,
- ret);
+ pr_err(save_secure_sram() returns %08x\n, ret);
while (1)
;
}
@@ -307,7 +306,7 @@ void omap_sram_idle(void)
break;
default:
/* Invalid state */
- printk(KERN_ERR Invalid mpu state in sram_idle\n);
+ pr_err(Invalid mpu state in sram_idle\n);
return;
}
@@ -463,7 +462,7 @@ restore:
list_for_each_entry(pwrst, pwrst_list, node) {
state = pwrdm_read_prev_pwrst(pwrst-pwrdm);
if (state pwrst-next_state) {
- printk(KERN_INFO Powerdomain (%s) didn't enter
+ pr_info(Powerdomain (%s) didn't enter
target state %d\n,
pwrst-pwrdm-name, pwrst-next_state);
ret = -1;
@@ -471,9 +470,9 @@ restore:
omap_set_pwrdm_state(pwrst-pwrdm, pwrst-saved_state);
}
if (ret)
- printk(KERN_ERR Could not enter target state in pm_suspend\n);
+ pr_err(Could not enter target state in pm_suspend\n);
else
- printk(KERN_INFO Successfully put all powerdomains
+ pr_info(Successfully put all powerdomains
to target state\n);
return ret;
@@ -822,7 +821,7 @@ static int __init omap3_pm_init(void)
ret = pwrdm_for_each(pwrdms_setup, NULL);
if (ret) {
- printk(KERN_ERR Failed to setup powerdomains\n);
+ pr_err(Failed to setup powerdomains\n);
goto err3;
}
@@ -830,7 +829,7 @@ static int __init omap3_pm_init(void)
mpu_pwrdm = pwrdm_lookup(mpu_pwrdm);
if (mpu_pwrdm == NULL) {
- printk(KERN_ERR Failed to get mpu_pwrdm\n);
+ pr_err(Failed to get mpu_pwrdm\n);
ret = -EINVAL;
goto err3;
}
@@ -865,7 +864,7 @@ static int __init omap3_pm_init(void)
omap3_secure_ram_storage =
kmalloc(0x803F, GFP_KERNEL);
if (!omap3_secure_ram_storage)
- printk(KERN_ERR Memory allocation failed when
+ pr_err(Memory allocation failed when
allocating for secure sram context\n);
local_irq_disable();
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Add generic device tree DMA helpers
On 3/15/2012 10:22 AM, Arnd Bergmann wrote:
On Thursday 15 March 2012, Nicolas Ferre wrote:
Add some basic helpers to retrieve a DMA controller device_node and the
DMA request specifications. By making DMA controllers register a generic
translation function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be implemented
by the DMA controller can carry any type of dma-request argument.
The DMA client will search its associated DMA controller in the list and
call the registered of_dam_xlate() function to retrieve the request values.
One simple xlate function is provided for the single number type of
request binding.
This implementation is independent from dmaengine so it can also be used
by legacy drivers.
For legacy reason another API will export the DMA request number into a
Linux resource of type IORESOURCE_DMA.
This looks very good. I missed the first version of this patch, but was
thinking of very similar bindings.
+Client drivers should specify the DMA request property using a phandle to
+the controller. If needed, the DMA request identity on that controller is then
+added followed by optional request specifications.
+
+Required property:
+- dma-request: List of phandle + dma-request + request specifications,
+ one group per request line.
+Optional property:
+- dma-request-names: list of strings in the same order as the dma-request
+ in the dma-request property.
+
+
+Example:
+
+ i2c1: i2c@1 {
+ ...
+ dma-request =sdma 2sdma 3;
+ dma-request-names = tx, rx;
+ ...
+ };
This is slightly different from how the proposed pwm binding works that
Thierry is working on, which uses an arbitrary property name instead of
requiring the use of a specific property but then allowing to give names
in another property.
I don't care much which way it's done, but please try to agree on one
approach that is used for both.
The one you have here is already used by reg and irq, while the other
one is used in gpio.
This was done like IRQ on purpose, because an Interrupt ReQuest line and
a DMA Request line are really similar for the HW point of view at IP level.
I'm not sure what Thierry have done for pwm, but I thing that having the
same scheme for reg, irq and dma was what we agreed with Grant during
Plumbers.
GPIO scheme will be probably good enough as well, but the idea was to be
consistent in the binding for similar information.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517evm
On Thu, Mar 15, 2012 at 04:52:40PM +0100, Yegor Yefremov wrote:
Am 15.03.2012 16:43, schrieb Mark A. Greer:
On Mon, Mar 12, 2012 at 02:55:02PM +0100, Yegor Yefremov wrote:
Am 09.03.2012 18:22, schrieb George C. Huntington, III:
I would like to make the newer kernel (3.x) work with the AM3517EVM.
I have a 2.6.32 and a 2.6.33 that run well on the board, but the
recent kernels have kernel panics before even running init. where
should I start? is there a better place to pursue this?
Have you tried this one?
http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=summary
I have this one booting one month ago, but I checked out the kernel today
and it hangs somewhere:
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
This looks like you have your console device set to ttyS2 instead of ttyO2.
Which branch of that repository did you use?
My kernel params: CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait
console=ttyO2,115200 and I force them, so bootloader has nothing to say.
I'm using master branch.
I just booted the latest master branch (b8fe178) with the hack below.
(Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw
rootfstype=ext3 rootwait)
Note that it is a ***HACK*** and should only be used temporarily.
Also note that I've been working on fixing up some of the am35x issues
including PM related ones that I'm in the middle of right now. If all goes
to plan, the am35x code will work better in the community in the
not-too-distant future.
Mark
--
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 027a537..5d1952b 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -397,7 +397,7 @@ static void omap3_pm_idle(void)
{
local_fiq_disable();
- if (omap_irq_pending())
+ if (omap_irq_pending() || !omap3_has_io_wakeup())
goto out;
trace_power_start(POWER_CSTATE, 1, smp_processor_id());
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] PM: Create the AVS class of drivers
From: Jean Pihet j-pi...@ti.com AVS is a power management technique which controls the operating voltage of a device in order to optimize (i.e. reduce) its power consumption. The voltage is adapted depending on static factors (chip manufacturing process) and dynamic factors (temperature depending performance). AVS is also called SmartReflex on OMAP devices. To that end, create the AVS framework in drivers/power/avs and move the OMAP SmartReflex code to the new directory. In preparation to the move of the OMAP code the following changes have been made: - split the include files into generic and platform specific code, - fill in platform data from the device initialization code and pass it to the driver, - create CONFIG_AVS* config options accordingly. The platform integration data for SmartReflex is passed from hwmod and the voltage layer to the driver using pdata. Tested on OMAP3 Beagleboard using omap2plus_defconfig with the CONFIG_POWER_AVS* options set. Based on master branch of the l-o git tree (3.3.0-rc6) [1], commit 85244e0edd240da2004bb2ab7cbcbc67a336f20d. [1] git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git Jean Pihet (10): ARM: OMAP3+: voltage: export functions to plat/voltage.h ARM: OMAP2+: SmartReflex: move the platform specific macros in plat-omap ARM: OMAP3+: SmartReflex: class drivers should use struct omap_sr * ARM: OMAP2+: smartreflex: Use the names from hwmod data instead of voltage domains. ARM: OMAP3: hwmod: rename the smartreflex entries ARM: OMAP2+: SmartReflex: use the platform header file for voltage functions ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro ARM: OMAP2+: SmartReflex: Use per-OPP data structure ARM: OMAP2+: SmartReflex: add POWER_AVS Kconfig options ARM: OMAP: SmartReflex: Move smartreflex driver to drivers/ arch/arm/mach-omap2/Makefile |4 +- arch/arm/mach-omap2/omap_hwmod_3xxx_data.c| 11 +- arch/arm/mach-omap2/omap_hwmod_44xx_data.c|3 +- arch/arm/mach-omap2/pm.h |2 +- arch/arm/mach-omap2/smartreflex-class3.c | 60 -- arch/arm/mach-omap2/smartreflex.c | 1165 - arch/arm/mach-omap2/smartreflex.h | 256 -- arch/arm/mach-omap2/sr_device.c | 38 +- arch/arm/mach-omap2/voltage.h |1 - arch/arm/mach-omap2/vp.h |2 - arch/arm/plat-omap/Kconfig| 31 - arch/arm/plat-omap/include/plat/smartreflex.h | 95 ++ arch/arm/plat-omap/include/plat/voltage.h |3 + drivers/power/Kconfig |2 + drivers/power/Makefile|2 + drivers/power/avs/Kconfig | 45 + drivers/power/avs/Makefile|2 + drivers/power/avs/smartreflex-class3.c| 60 ++ drivers/power/avs/smartreflex.c | 1117 drivers/power/avs/smartreflex.h | 238 + 20 files changed, 1604 insertions(+), 1533 deletions(-) delete mode 100644 arch/arm/mach-omap2/smartreflex-class3.c delete mode 100644 arch/arm/mach-omap2/smartreflex.c delete mode 100644 arch/arm/mach-omap2/smartreflex.h create mode 100644 arch/arm/plat-omap/include/plat/smartreflex.h create mode 100644 drivers/power/avs/Kconfig create mode 100644 drivers/power/avs/Makefile create mode 100644 drivers/power/avs/smartreflex-class3.c create mode 100644 drivers/power/avs/smartreflex.c create mode 100644 drivers/power/avs/smartreflex.h -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] ARM: OMAP2+: SmartReflex: move the platform specific macros in plat-omap
From: Jean Pihet j-pi...@ti.com
Move the platform specific macros from the smartreflex header file
(arch/arm/mach-omap2/smartreflex.h) in a new header file in plat-omap
(arch/arm/plat-omap/include/plat/smartreflex.h).
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c|3 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c|3 +-
arch/arm/mach-omap2/smartreflex.h | 42
arch/arm/mach-omap2/sr_device.c |2 +-
arch/arm/plat-omap/include/plat/smartreflex.h | 65 +
5 files changed, 68 insertions(+), 47 deletions(-)
create mode 100644 arch/arm/plat-omap/include/plat/smartreflex.h
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 0cc6a40..1f681e8 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -26,10 +26,9 @@
#include plat/mcbsp.h
#include plat/mcspi.h
#include plat/dmtimer.h
+#include plat/smartreflex.h
#include omap_hwmod_common_data.h
-
-#include smartreflex.h
#include prm-regbits-34xx.h
#include cm-regbits-34xx.h
#include wd_timer.h
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 48e5834..a1e359f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -30,10 +30,9 @@
#include plat/mmc.h
#include plat/dmtimer.h
#include plat/common.h
+#include plat/smartreflex.h
#include omap_hwmod_common_data.h
-
-#include smartreflex.h
#include cm1_44xx.h
#include cm2_44xx.h
#include prm44xx.h
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index 5809141..cb8d98a 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -152,14 +152,6 @@ struct omap_sr_pmic_data {
void (*sr_pmic_init) (void);
};
-/**
- * struct omap_smartreflex_dev_attr - Smartreflex Device attribute.
- *
- * @sensor_voltdm_name: Name of voltdomain of SR instance
- */
-struct omap_smartreflex_dev_attr {
- const char *sensor_voltdm_name;
-};
#ifdef CONFIG_OMAP_SMARTREFLEX
/*
@@ -194,40 +186,6 @@ struct omap_sr_class_data {
u8 class_type;
};
-/**
- * struct omap_sr_nvalue_table - Smartreflex n-target value info
- *
- * @efuse_offs:The offset of the efuse where n-target values are
stored.
- * @nvalue:The n-target value.
- */
-struct omap_sr_nvalue_table {
- u32 efuse_offs;
- u32 nvalue;
-};
-
-/**
- * struct omap_sr_data - Smartreflex platform data.
- *
- * @ip_type: Smartreflex IP type.
- * @senp_mod: SENPENABLE value for the sr
- * @senn_mod: SENNENABLE value for sr
- * @nvalue_count: Number of distinct nvalues in the nvalue table
- * @enable_on_init:whether this sr module needs to enabled at
- * boot up or not.
- * @nvalue_table: table containing the efuse offsets and nvalues
- * corresponding to them.
- * @voltdm:Pointer to the voltage domain associated with the SR
- */
-struct omap_sr_data {
- int ip_type;
- u32 senp_mod;
- u32 senn_mod;
- int nvalue_count;
- boolenable_on_init;
- struct omap_sr_nvalue_table *nvalue_table;
- struct voltagedomain*voltdm;
-};
-
/* Smartreflex module enable/disable interface */
void omap_sr_enable(struct voltagedomain *voltdm);
void omap_sr_disable(struct voltagedomain *voltdm);
diff --git a/arch/arm/mach-omap2/sr_device.c b/arch/arm/mach-omap2/sr_device.c
index a503e1e..dad1473 100644
--- a/arch/arm/mach-omap2/sr_device.c
+++ b/arch/arm/mach-omap2/sr_device.c
@@ -23,8 +23,8 @@
#include linux/io.h
#include plat/omap_device.h
+#include plat/smartreflex.h
-#include smartreflex.h
#include voltage.h
#include control.h
#include pm.h
diff --git a/arch/arm/plat-omap/include/plat/smartreflex.h
b/arch/arm/plat-omap/include/plat/smartreflex.h
new file mode 100644
index 000..baa296f
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/smartreflex.h
@@ -0,0 +1,65 @@
+/*
+ * OMAP Platform Smartreflex Defines and Routines
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ * Jean Pihet j-pi...@ti.com
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Kalle Jokiniemi
+ *
+ * Copyright (C) 2007 Texas Instruments, Inc.
+ * Lesly A M x0080...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __ASM_ARM_PLATOMAP_SMARTREFLEX_H
+#define __ASM_ARM_PLATOMAP_SMARTREFLEX_H
+
+#include voltage.h
+
+/**
+ *
[PATCH 04/10] ARM: OMAP2+: smartreflex: Use the names from hwmod data instead of voltage domains.
From: Jean Pihet j-pi...@ti.com
Associate a name with each SmartReflex instance from the hwmod data,
rather than attempting to reuse the name of a voltage domain. The name
from hwmod better reflects the smartreflex integration in the system.
Also have the name passed to the drivers using pdata, which helps to remove
any dependencies on SoC-specific structures.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c |4 +-
arch/arm/mach-omap2/smartreflex.c | 65 ++---
arch/arm/mach-omap2/sr_device.c |1 +
arch/arm/plat-omap/include/plat/smartreflex.h |3 +
4 files changed, 32 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index a105077..9a19ce7 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -18,8 +18,8 @@ static int sr_class3_enable(struct omap_sr *sr)
unsigned long volt = voltdm_get_voltage(sr-voltdm);
if (!volt) {
- pr_warning(%s: Curr voltage unknown. Cannot enable sr_%s\n,
- __func__, sr-voltdm-name);
+ pr_warning(%s: Curr voltage unknown. Cannot enable %s\n,
+ __func__, sr-name);
return -ENODATA;
}
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 57a484d..8e3ef66 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -184,7 +184,7 @@ static void sr_set_regfields(struct omap_sr *sr)
sr-err_weight = OMAP3430_SR_ERRWEIGHT;
sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
sr-accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr-voltdm-name, mpu))) {
+ if (!(strcmp(sr-name, sr1))) {
sr-senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
sr-senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
} else {
@@ -235,19 +235,13 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
*/
static int sr_late_init(struct omap_sr *sr_info)
{
- char *name;
struct omap_sr_data *pdata = sr_info-pdev-dev.platform_data;
struct resource *mem;
int ret = 0;
if (sr_class-notify sr_class-notify_flags sr_info-irq) {
- name = kasprintf(GFP_KERNEL, sr_%s, sr_info-voltdm-name);
- if (name == NULL) {
- ret = -ENOMEM;
- goto error;
- }
ret = request_irq(sr_info-irq, sr_interrupt,
- 0, name, sr_info);
+ 0, sr_info-name, sr_info);
if (ret)
goto error;
disable_irq(sr_info-irq);
@@ -266,7 +260,6 @@ error:
dev_err(sr_info-pdev-dev, %s: ERROR in registering
interrupt handler. Smartreflex will
not function as desired\n, __func__);
- kfree(name);
kfree(sr_info);
return ret;
@@ -396,8 +389,7 @@ int sr_configure_errgen(struct voltagedomain *voltdm)
struct omap_sr *sr = _sr_lookup(voltdm);
if (IS_ERR(sr)) {
- pr_warning(%s: omap_sr struct for sr_%s not found\n,
- __func__, voltdm-name);
+ pr_warning(%s: omap_sr struct for voltdm not found\n,
__func__);
return PTR_ERR(sr);
}
@@ -464,8 +456,7 @@ int sr_disable_errgen(struct voltagedomain *voltdm)
struct omap_sr *sr = _sr_lookup(voltdm);
if (IS_ERR(sr)) {
- pr_warning(%s: omap_sr struct for sr_%s not found\n,
- __func__, voltdm-name);
+ pr_warning(%s: omap_sr struct for voltdm not found\n,
__func__);
return PTR_ERR(sr);
}
@@ -515,8 +506,7 @@ int sr_configure_minmax(struct voltagedomain *voltdm)
struct omap_sr *sr = _sr_lookup(voltdm);
if (IS_ERR(sr)) {
- pr_warning(%s: omap_sr struct for sr_%s not found\n,
- __func__, voltdm-name);
+ pr_warning(%s: omap_sr struct for voltdm not found\n,
__func__);
return PTR_ERR(sr);
}
@@ -601,8 +591,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long
volt)
int ret;
if (IS_ERR(sr)) {
- pr_warning(%s: omap_sr struct for sr_%s not found\n,
- __func__, voltdm-name);
+ pr_warning(%s: omap_sr struct for voltdm not found\n,
__func__);
return PTR_ERR(sr);
}
@@ -655,8 +644,7 @@ void sr_disable(struct voltagedomain *voltdm)
struct omap_sr *sr = _sr_lookup(voltdm);
if (IS_ERR(sr)) {
- pr_warning(%s: omap_sr struct for sr_%s not found\n,
- __func__, voltdm-name);
[PATCH 08/10] ARM: OMAP2+: SmartReflex: Use per-OPP data structure
From: Jean Pihet j-pi...@ti.com
The SmartReflex driver incorrectly treats some per-OPP data as data
common to all OPPs (e.g., ERRMINLIMIT). Move this data into a per-OPP
data structure.
The SmartReflex driver should not be dependent on whether the host SoC
uses eFuses to store SmartReflex parameters or not. (Even SoCs that
do store SR data in eFuses often need to override that data with
software-defined values.) So, convert sr_retrieve_nvalue() to look up
per-OPP data by the OPP's nominal voltage, rather than by the eFuse
offset.
While at it:
. tidy up the code wrt default values in the data tables,
. remove the global errminlimit debugfs entry and create per-voltage
entries from the data tables.
Furthermore, in order to make the SmartReflex implementation ready for
the move to drivers/, remove the dependency from the SR driver code
to the voltage layer by querying the data tables only from the SR device
init code.
Based on Paul's original code for the SmartReflex driver conversion.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Thara Gopinath th...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 57 ++--
arch/arm/mach-omap2/sr_device.c | 35 +---
arch/arm/plat-omap/include/plat/smartreflex.h |8 +++-
3 files changed, 59 insertions(+), 41 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index ceb50b5..52950a1 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -348,22 +348,24 @@ static void sr_v2_disable(struct omap_sr *sr)
sr_write_reg(sr, IRQSTATUS, IRQSTATUS_MCUDISABLEACKINT);
}
-static u32 sr_retrieve_nvalue(struct omap_sr *sr, u32 efuse_offs)
+static struct omap_sr_nvalue_table *sr_retrieve_nvalue_row(
+ struct omap_sr *sr,
+ unsigned long volt_nominal)
{
int i;
if (!sr-nvalue_table) {
dev_warn(sr-pdev-dev, %s: Missing ntarget value table\n,
__func__);
- return 0;
+ return NULL;
}
for (i = 0; i sr-nvalue_count; i++) {
- if (sr-nvalue_table[i].efuse_offs == efuse_offs)
- return sr-nvalue_table[i].nvalue;
+ if (sr-nvalue_table[i].volt_nominal == volt_nominal)
+ return sr-nvalue_table[i];
}
- return 0;
+ return NULL;
}
/* Public Functions */
@@ -585,9 +587,8 @@ int sr_configure_minmax(struct voltagedomain *voltdm)
*/
int sr_enable(struct voltagedomain *voltdm, unsigned long volt)
{
- struct omap_volt_data *volt_data;
struct omap_sr *sr = _sr_lookup(voltdm);
- u32 nvalue_reciprocal;
+ struct omap_sr_nvalue_table *nvalue_row;
int ret;
if (IS_ERR(sr)) {
@@ -595,24 +596,16 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long
volt)
return PTR_ERR(sr);
}
- volt_data = omap_voltage_get_voltdata(sr-voltdm, volt);
-
- if (IS_ERR(volt_data)) {
- dev_warn(sr-pdev-dev, %s: Unable to get voltage table
- for nominal voltage %ld\n, __func__, volt);
- return PTR_ERR(volt_data);
- }
-
- nvalue_reciprocal = sr_retrieve_nvalue(sr, volt_data-sr_efuse_offs);
-
- if (!nvalue_reciprocal) {
- dev_warn(sr-pdev-dev, %s: NVALUE = 0 at voltage %ld\n,
- __func__, volt);
+ nvalue_row = sr_retrieve_nvalue_row(sr, volt);
+ if (!nvalue_row) {
+ dev_warn(sr-pdev-dev, %s: failure getting SR data for this
voltage %ld\n,
+__func__, volt);
return -ENODATA;
}
+
/* errminlimit is opp dependent and hence linked to voltage */
- sr-err_minlimit = volt_data-sr_errminlimit;
+ sr-err_minlimit = nvalue_row-errminlimit;
pm_runtime_get_sync(sr-pdev-dev);
@@ -625,7 +618,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long
volt)
if (ret)
return ret;
- sr_write_reg(sr, NVALUERECIPROCAL, nvalue_reciprocal);
+ sr_write_reg(sr, NVALUERECIPROCAL, nvalue_row-nvalue);
/* SRCONFIG - enable SR */
sr_modify_reg(sr, SRCONFIG, SRCONFIG_SRENABLE, SRCONFIG_SRENABLE);
@@ -873,7 +866,6 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
struct omap_sr_data *pdata = pdev-dev.platform_data;
struct resource *mem, *irq;
struct dentry *nvalue_dir;
- struct omap_volt_data *volt_data;
int i, ret = 0;
sr_info = kzalloc(sizeof(struct omap_sr), GFP_KERNEL);
@@ -980,8 +972,6 @@ static int __init omap_sr_probe(struct platform_device
*pdev)
sr_info-err_weight);
(void)
[PATCH 03/10] ARM: OMAP3+: SmartReflex: class drivers should use struct omap_sr *
From: Jean Pihet j-pi...@ti.com
Convert SmartReflex class functions to take a struct omap_sr *, rather than
a struct voltagedomain *. SmartReflex code should be driver code and not
tightly coupled to OMAP subarchitecture-specific structures.
Based on Paul's original code for the SmartReflex driver conversion.
Signed-off-by: Jean Pihet j-pi...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Thara Gopinath th...@ti.com
Cc: Nishanth Menon n...@ti.com
Cc: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/smartreflex-class3.c | 24
arch/arm/mach-omap2/smartreflex.c | 37 +
arch/arm/mach-omap2/smartreflex.h |8 +++---
arch/arm/plat-omap/include/plat/smartreflex.h | 23 +++
4 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex-class3.c
b/arch/arm/mach-omap2/smartreflex-class3.c
index 955566e..a105077 100644
--- a/arch/arm/mach-omap2/smartreflex-class3.c
+++ b/arch/arm/mach-omap2/smartreflex-class3.c
@@ -13,34 +13,34 @@
#include smartreflex.h
-static int sr_class3_enable(struct voltagedomain *voltdm)
+static int sr_class3_enable(struct omap_sr *sr)
{
- unsigned long volt = voltdm_get_voltage(voltdm);
+ unsigned long volt = voltdm_get_voltage(sr-voltdm);
if (!volt) {
pr_warning(%s: Curr voltage unknown. Cannot enable sr_%s\n,
- __func__, voltdm-name);
+ __func__, sr-voltdm-name);
return -ENODATA;
}
- omap_vp_enable(voltdm);
- return sr_enable(voltdm, volt);
+ omap_vp_enable(sr-voltdm);
+ return sr_enable(sr-voltdm, volt);
}
-static int sr_class3_disable(struct voltagedomain *voltdm, int is_volt_reset)
+static int sr_class3_disable(struct omap_sr *sr, int is_volt_reset)
{
- sr_disable_errgen(voltdm);
- omap_vp_disable(voltdm);
- sr_disable(voltdm);
+ sr_disable_errgen(sr-voltdm);
+ omap_vp_disable(sr-voltdm);
+ sr_disable(sr-voltdm);
if (is_volt_reset)
- voltdm_reset(voltdm);
+ voltdm_reset(sr-voltdm);
return 0;
}
-static int sr_class3_configure(struct voltagedomain *voltdm)
+static int sr_class3_configure(struct omap_sr *sr)
{
- return sr_configure_errgen(voltdm);
+ return sr_configure_errgen(sr-voltdm);
}
/* SR class3 structure */
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 008fbd7..57a484d 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -35,29 +35,6 @@
#define NVALUE_NAME_LEN40
#define SR_DISABLE_TIMEOUT 200
-struct omap_sr {
- struct list_headnode;
- struct platform_device *pdev;
- struct omap_sr_nvalue_table *nvalue_table;
- struct voltagedomain*voltdm;
- struct dentry *dbg_dir;
- unsigned intirq;
- int srid;
- int ip_type;
- int nvalue_count;
- boolautocomp_active;
- u32 clk_length;
- u32 err_weight;
- u32 err_minlimit;
- u32 err_maxlimit;
- u32 accum_data;
- u32 senn_avgweight;
- u32 senp_avgweight;
- u32 senp_mod;
- u32 senn_mod;
- void __iomem*base;
-};
-
/* sr_list contains all the instances of smartreflex module */
static LIST_HEAD(sr_list);
@@ -148,7 +125,7 @@ static irqreturn_t sr_interrupt(int irq, void *data)
}
if (sr_class-notify)
- sr_class-notify(sr_info-voltdm, status);
+ sr_class-notify(sr_info, status);
return IRQ_HANDLED;
}
@@ -226,7 +203,7 @@ static void sr_start_vddautocomp(struct omap_sr *sr)
return;
}
- if (!sr_class-enable(sr-voltdm))
+ if (!sr_class-enable(sr))
sr-autocomp_active = true;
}
@@ -240,7 +217,7 @@ static void sr_stop_vddautocomp(struct omap_sr *sr)
}
if (sr-autocomp_active) {
- sr_class-disable(sr-voltdm, 1);
+ sr_class-disable(sr, 1);
sr-autocomp_active = false;
}
}
@@ -655,7 +632,7 @@ int sr_enable(struct voltagedomain *voltdm, unsigned long
volt)
return 0;
/* Configure SR */
- ret = sr_class-configure(voltdm);
+ ret = sr_class-configure(sr);
if (ret)
return ret;
@@ -773,7 +750,7 @@ void omap_sr_enable(struct voltagedomain *voltdm)
[PATCH 05/10] ARM: OMAP3: hwmod: rename the smartreflex entries
From: Jean Pihet j-pi...@ti.com
Change the name field value to better reflect the smartreflex
integration in the system
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8
arch/arm/mach-omap2/smartreflex.c |2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 1f681e8..728740d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -2750,7 +2750,7 @@ static struct omap_hwmod_ocp_if *omap34xx_sr1_slaves[] = {
};
static struct omap_hwmod omap34xx_sr1_hwmod = {
- .name = sr1,
+ .name = mpu_iva,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
.prcm = {
@@ -2774,7 +2774,7 @@ static struct omap_hwmod_ocp_if *omap36xx_sr1_slaves[] = {
};
static struct omap_hwmod omap36xx_sr1_hwmod = {
- .name = sr1,
+ .name = mpu_iva,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr1_fck,
.prcm = {
@@ -2802,7 +2802,7 @@ static struct omap_hwmod_ocp_if *omap34xx_sr2_slaves[] = {
};
static struct omap_hwmod omap34xx_sr2_hwmod = {
- .name = sr2,
+ .name = core,
.class = omap34xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
.prcm = {
@@ -2826,7 +2826,7 @@ static struct omap_hwmod_ocp_if *omap36xx_sr2_slaves[] = {
};
static struct omap_hwmod omap36xx_sr2_hwmod = {
- .name = sr2,
+ .name = core,
.class = omap36xx_smartreflex_hwmod_class,
.main_clk = sr2_fck,
.prcm = {
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 8e3ef66..dd80fde 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -184,7 +184,7 @@ static void sr_set_regfields(struct omap_sr *sr)
sr-err_weight = OMAP3430_SR_ERRWEIGHT;
sr-err_maxlimit = OMAP3430_SR_ERRMAXLIMIT;
sr-accum_data = OMAP3430_SR_ACCUMDATA;
- if (!(strcmp(sr-name, sr1))) {
+ if (!(strcmp(sr-name, sr_mpu_iva))) {
sr-senn_avgweight = OMAP3430_SR1_SENNAVGWEIGHT;
sr-senp_avgweight = OMAP3430_SR1_SENPAVGWEIGHT;
} else {
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/10] ARM: OMAP2+: SmartReflex: add POWER_AVS Kconfig options
From: Jean Pihet j-pi...@ti.com
Add a Kconfig menu (POWER_AVS) and rename the Kconfig options
for the OMAP SmartReflex implementation:
CONFIG_OMAP_SMARTREFLEX renames to CONFIG_POWER_AVS_OMAP
CONFIG_OMAP_SMARTREFLEX_CLASS3 renames to CONFIG_POWER_AVS_OMAP_CLASS3
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/Makefile |5 ++-
arch/arm/mach-omap2/pm.h |2 +-
arch/arm/mach-omap2/smartreflex.h |6 ++--
arch/arm/plat-omap/Kconfig| 45
4 files changed, 37 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 9746529..30666fd 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -68,8 +68,9 @@ obj-$(CONFIG_ARCH_OMAP3) += pm34xx.o sleep34xx.o
\
obj-$(CONFIG_ARCH_OMAP4) += pm44xx.o omap-mpuss-lowpower.o \
cpuidle44xx.o
obj-$(CONFIG_PM_DEBUG) += pm-debug.o
-obj-$(CONFIG_OMAP_SMARTREFLEX) += sr_device.o smartreflex.o
-obj-$(CONFIG_OMAP_SMARTREFLEX_CLASS3) += smartreflex-class3.o
+
+obj-$(CONFIG_POWER_AVS_OMAP) += sr_device.o smartreflex.o
+obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o
AFLAGS_sleep24xx.o :=-Wa,-march=armv6
AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec)
diff --git a/arch/arm/mach-omap2/pm.h b/arch/arm/mach-omap2/pm.h
index a051431..1a2d483 100644
--- a/arch/arm/mach-omap2/pm.h
+++ b/arch/arm/mach-omap2/pm.h
@@ -110,7 +110,7 @@ extern void enable_omap3630_toggle_l2_on_restore(void);
static inline void enable_omap3630_toggle_l2_on_restore(void) { }
#endif /* defined(CONFIG_PM) defined(CONFIG_ARCH_OMAP3) */
-#ifdef CONFIG_OMAP_SMARTREFLEX
+#ifdef CONFIG_POWER_AVS_OMAP
extern int omap_devinit_smartreflex(void);
extern void omap_enable_smartreflex_on_init(void);
#else
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index 3bd4fee..dbfb554 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -17,8 +17,8 @@
* published by the Free Software Foundation.
*/
-#ifndef __ASM_ARM_OMAP_SMARTREFLEX_H
-#define __ASM_ARM_OMAP_SMARTREFLEX_H
+#ifndef __DRIVERS_POWER_AVS_SMARTREFLEX_H
+#define __DRIVERS_POWER_AVS_SMARTREFLEX_H
#include linux/platform_device.h
#include linux/delay.h
@@ -177,7 +177,7 @@ struct omap_sr_pmic_data {
};
-#ifdef CONFIG_OMAP_SMARTREFLEX
+#ifdef CONFIG_POWER_AVS_OMAP
/*
* The smart reflex driver supports CLASS1 CLASS2 and CLASS3 SR.
* The smartreflex class driver should pass the class type.
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index f419a08..6ec9237 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -44,37 +44,52 @@ config OMAP_DEBUG_LEDS
depends on OMAP_DEBUG_DEVICES
default y if LEDS_CLASS
-config OMAP_SMARTREFLEX
- bool SmartReflex support
- depends on (ARCH_OMAP3 || ARCH_OMAP4) PM
+menuconfig POWER_AVS
+ tristate Adaptive Voltage Scaling class support
help
- Say Y if you want to enable SmartReflex.
+ AVS is a power management technique which finely controls the
+ operating voltage of a device in order to optimize (i.e. reduce)
+ its power consumption.
+ At a given operating point the voltage is adapted depending on
+ static factors (chip manufacturing process) and dynamic factors
+ (temperature depending performance).
+ AVS is also called SmartReflex on OMAP devices.
+
+ Say Y here to enable Adaptive Voltage Scaling class support.
+
+if POWER_AVS
- SmartReflex can perform continuous dynamic voltage
- scaling around the nominal operating point voltage
- according to silicon characteristics and operating
- conditions. Enabling SmartReflex reduces power
- consumption.
+config POWER_AVS_OMAP
+ bool AVS support for the OMAP IP versions 12
+ depends on (ARCH_OMAP3 || ARCH_OMAP4) PM
+ help
+ Say Y to enable AVS support on OMAP containing the version 1 or
+ version 2 of the SmartReflex IP.
+ V1 is the 65nm version used in OMAP3430.
+ V2 is the update for the 45nm version of the IP used in OMAP3630
+ and OMAP4430
Please note, that by default SmartReflex is only
- initialized. To enable the automatic voltage
- compensation for vdd mpu and vdd core from user space,
+ initialized and not enabled. To enable the automatic voltage
+ compensation for vdd mpu and vdd core from user space,
user must write 1 to
- /debug/voltage/vdd_X/smartreflex/autocomp,
- where X is mpu or core for OMAP3.
+
[PATCH 07/10] ARM: OMAP2+: SmartReflex: introduce a busy loop condition test macro
From: Jean Pihet j-pi...@ti.com
Now that omap_test_timeout is only accessible from mach-omap2/,
introduce a similar function for SR.
This change makes the SmartReflex implementation ready for the move
to drivers/.
Signed-off-by: Jean Pihet j-pi...@ti.com
---
arch/arm/mach-omap2/smartreflex.c | 12 ++--
arch/arm/mach-omap2/smartreflex.h | 23 +++
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index dd80fde..ceb50b5 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -290,9 +290,9 @@ static void sr_v1_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until ERRCONFIG.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, ERRCONFIG_V1)
- ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, ERRCONFIG_V1)
+ERRCONFIG_MCUDISACKINTST), SR_DISABLE_TIMEOUT,
+timeout);
if (timeout = SR_DISABLE_TIMEOUT)
dev_warn(sr-pdev-dev, %s: Smartreflex disable timedout\n,
@@ -335,9 +335,9 @@ static void sr_v2_disable(struct omap_sr *sr)
* Wait for SR to be disabled.
* wait until IRQSTATUS.MCUDISACKINTST = 1. Typical latency is 1us.
*/
- omap_test_timeout((sr_read_reg(sr, IRQSTATUS)
- IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
- timeout);
+ sr_test_cond_timeout((sr_read_reg(sr, IRQSTATUS)
+IRQSTATUS_MCUDISABLEACKINT), SR_DISABLE_TIMEOUT,
+timeout);
if (timeout = SR_DISABLE_TIMEOUT)
dev_warn(sr-pdev-dev, %s: Smartreflex disable timedout\n,
diff --git a/arch/arm/mach-omap2/smartreflex.h
b/arch/arm/mach-omap2/smartreflex.h
index 8d3e3c2..3bd4fee 100644
--- a/arch/arm/mach-omap2/smartreflex.h
+++ b/arch/arm/mach-omap2/smartreflex.h
@@ -21,6 +21,7 @@
#define __ASM_ARM_OMAP_SMARTREFLEX_H
#include linux/platform_device.h
+#include linux/delay.h
#include plat/smartreflex.h
#include plat/voltage.h
@@ -144,6 +145,28 @@
#define OMAP3430_SR_ERRMAXLIMIT0x02
/**
+ * test_cond_timeout - busy-loop, testing a condition
+ * @cond: condition to test until it evaluates to true
+ * @timeout: maximum number of microseconds in the timeout
+ * @index: loop index (integer)
+ *
+ * Loop waiting for @cond to become true or until at least @timeout
+ * microseconds have passed. To use, define some integer @index in the
+ * calling code. After running, if @index == @timeout, then the loop has
+ * timed out.
+ *
+ * Copied from omap_test_timeout
+ */
+#define sr_test_cond_timeout(cond, timeout, index) \
+({ \
+ for (index = 0; index timeout; index++) { \
+ if (cond) \
+ break; \
+ udelay(1); \
+ } \
+})
+
+/**
* struct omap_sr_pmic_data - Strucutre to be populated by pmic code to pass
* pmic specific info to smartreflex driver
*
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/10] ARM: OMAP2+: SmartReflex: use the platform header file for voltage functions
From: Jean Pihet j-pi...@ti.com Signed-off-by: Jean Pihet j-pi...@ti.com --- arch/arm/mach-omap2/smartreflex.h |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/smartreflex.h b/arch/arm/mach-omap2/smartreflex.h index f12ebde..8d3e3c2 100644 --- a/arch/arm/mach-omap2/smartreflex.h +++ b/arch/arm/mach-omap2/smartreflex.h @@ -22,7 +22,8 @@ #include linux/platform_device.h -#include voltage.h +#include plat/smartreflex.h +#include plat/voltage.h /* * Different Smartreflex IPs version. The v1 is the 65nm version used in -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] ARM: OMAP3+: voltage: export functions to plat/voltage.h
From: Jean Pihet j-pi...@ti.com Move some functions from mach-omap2/ dir to the plat/ dir. The SmartReflex class driver is a user of the basic voltage domains functions (enable, disable, reset). Signed-off-by: Jean Pihet j-pi...@ti.com Cc: Kevin Hilman khil...@ti.com --- arch/arm/mach-omap2/voltage.h |1 - arch/arm/mach-omap2/vp.h |2 -- arch/arm/plat-omap/include/plat/voltage.h |3 +++ 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h index 16a1b09..a81dea8 100644 --- a/arch/arm/mach-omap2/voltage.h +++ b/arch/arm/mach-omap2/voltage.h @@ -167,6 +167,5 @@ int voltdm_for_each_pwrdm(struct voltagedomain *voltdm, int (*fn)(struct voltagedomain *voltdm, struct powerdomain *pwrdm)); int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt); -void voltdm_reset(struct voltagedomain *voltdm); unsigned long voltdm_get_voltage(struct voltagedomain *voltdm); #endif diff --git a/arch/arm/mach-omap2/vp.h b/arch/arm/mach-omap2/vp.h index 7c155d2..837cb8d 100644 --- a/arch/arm/mach-omap2/vp.h +++ b/arch/arm/mach-omap2/vp.h @@ -118,8 +118,6 @@ extern struct omap_vp_instance omap4_vp_iva; extern struct omap_vp_instance omap4_vp_core; void omap_vp_init(struct voltagedomain *voltdm); -void omap_vp_enable(struct voltagedomain *voltdm); -void omap_vp_disable(struct voltagedomain *voltdm); int omap_vp_forceupdate_scale(struct voltagedomain *voltdm, unsigned long target_volt); int omap_vp_update_errorgain(struct voltagedomain *voltdm, diff --git a/arch/arm/plat-omap/include/plat/voltage.h b/arch/arm/plat-omap/include/plat/voltage.h index 0a6a482..1842709 100644 --- a/arch/arm/plat-omap/include/plat/voltage.h +++ b/arch/arm/plat-omap/include/plat/voltage.h @@ -16,5 +16,8 @@ struct voltagedomain; struct voltagedomain *voltdm_lookup(const char *name); int voltdm_scale(struct voltagedomain *voltdm, unsigned long target_volt); unsigned long voltdm_get_voltage(struct voltagedomain *voltdm); +void voltdm_reset(struct voltagedomain *voltdm); +void omap_vp_enable(struct voltagedomain *voltdm); +void omap_vp_disable(struct voltagedomain *voltdm); #endif -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM3517evm
On Thu, Mar 15, 2012 at 09:42:21AM -0700, Mark A. Greer wrote: On Thu, Mar 15, 2012 at 04:52:40PM +0100, Yegor Yefremov wrote: Am 15.03.2012 16:43, schrieb Mark A. Greer: On Mon, Mar 12, 2012 at 02:55:02PM +0100, Yegor Yefremov wrote: Am 09.03.2012 18:22, schrieb George C. Huntington, III: I would like to make the newer kernel (3.x) work with the AM3517EVM. I have a 2.6.32 and a 2.6.33 that run well on the board, but the recent kernels have kernel panics before even running init. where should I start? is there a better place to pursue this? Have you tried this one? http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;a=summary I have this one booting one month ago, but I checked out the kernel today and it hangs somewhere: Starting kernel ... Uncompressing Linux... done, booting the kernel. This looks like you have your console device set to ttyS2 instead of ttyO2. Which branch of that repository did you use? My kernel params: CONFIG_CMDLINE=root=/dev/mmcblk0p2 rootwait console=ttyO2,115200 and I force them, so bootloader has nothing to say. I'm using master branch. I just booted the latest master branch (b8fe178) with the hack below. (Kernel command line: console=ttyO2,115200n8 root=/dev/mmcblk0p2 rw rootfstype=ext3 rootwait) I meant to add that I booted an am3517evm. Mark -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: OMAP2+: I2C: always compile I2C reset code, even if I2C driver is not built
* Paul Walmsley p...@pwsan.com [120315 03:33]: During kernel init, we reset all IP blocks on the OMAP that we can, even if there is no driver compiled for that IP block. Unlike most IP blocks, the I2C block requires some extra programming for this to work. This reset code is incorrectly omitted when the I2C driver is deselected. In this circumstance, the build breaks. Fix by compiling the I2C reset code unconditionally. This one is commit ed8dfd22ea2533a1b169881c3de94be8daa0e297 in arm-soc/for-next. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] ARM: OMAP: fix missing __devexit_p() annotations
* Jean Pihet jean.pi...@newoldbits.com [120315 04:09]:
Russell,
On Thu, Mar 15, 2012 at 11:30 AM, Russell King
rmk+ker...@arm.linux.org.uk wrote:
Missing __devexit_p() annotations in driver structures for remove functions
marked with __devexit is waiting for build errors to happen, such as:
`omap_system_dma_remove' referenced in section `.data' of
arch/arm/plat-omap/bui
lt-in.o: defined in discarded section `.devexit.text' of
arch/arm/plat-omap/buil
t-in.o
Add the necessary annotation, and as a result of audit, fix others which
are also missing in arch/arm/*omap*.
Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/smartreflex.c | 2 +-
arch/arm/plat-omap/dma.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/smartreflex.c
b/arch/arm/mach-omap2/smartreflex.c
index 7e755bb..47c77a1 100644
--- a/arch/arm/mach-omap2/smartreflex.c
+++ b/arch/arm/mach-omap2/smartreflex.c
@@ -1012,7 +1012,7 @@ static int __devexit omap_sr_remove(struct
platform_device *pdev)
}
static struct platform_driver smartreflex_driver = {
- .remove = omap_sr_remove,
+ .remove = __devexit_p(omap_sr_remove),
.driver = {
.name = smartreflex,
},
Tony already has this change in his master branch, commit
149f1d5c8d2fd6879cdf93ca70f1cb745e698a1e ('ARM: OMAP2+: Fix devexit
for smartreflex when CONFIG_HOTPLUG is not set').
Also same commit in arm-soc/for-next.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] cpufreq: OMAP updates for v3.4
Hi Dave, On 03/07/2012 12:30 PM, Dave Jones wrote: On Wed, Mar 07, 2012 at 12:20:41PM -0800, Kevin Hilman wrote: Dave, Please pull the following OMAP CPUfreq driver changes for v3.4. pulled, thanks. Looks like these got pulled into your fixes branch, but I don't see them in linux-next? Are these on their way upstream? Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] ARM: OMAP: fix cpufreq build
Russell King rmk+ker...@arm.linux.org.uk writes: OMAPs cpufreq requires the frequency table support, but nothing ensures that this is selected. This can result in configurations which fail to build: drivers/built-in.o:(.data+0x5238): undefined reference to `cpufreq_freq_attr_scaling_available_freqs' drivers/cpufreq/omap-cpufreq.c:88: undefined reference to `cpufreq_frequency_table_target' drivers/cpufreq/omap-cpufreq.c:60: undefined reference to `cpufreq_frequency_table_verify' drivers/cpufreq/omap-cpufreq.c:186: undefined reference to `cpufreq_frequency_table_cpuinfo' drivers/cpufreq/omap-cpufreq.c:190: undefined reference to `cpufreq_frequency_table_get_attr' Fix this by introducing a new configuration variable and having that select CPU_FREQ_TABLE. Signed-off-by: Russell King rmk+ker...@arm.linux.org.uk --- arch/arm/mach-omap2/clkt2xxx_virt_prcm_set.c |2 +- arch/arm/mach-omap2/clock.c |2 +- arch/arm/mach-omap2/clock.h |2 +- arch/arm/plat-omap/clock.c |2 +- arch/arm/plat-omap/include/plat/clock.h |4 ++-- The arch/arm/* stuff is all code that has been removed, but the pull request didn't make it in time for v3.4: http://www.spinics.net/lists/arm-kernel/msg164545.html Initially, this was intended as a cleanup because it was just dead code removal, but since we missed v3.4, maybe we should pull out ARM: OMAP: clock: cleanup CPUfreq leftovers and submit for 3.4-rc. drivers/cpufreq/Kconfig.arm |5 + drivers/cpufreq/Makefile |2 +- This change was included in my CPUfreq pull request to Dave Jones. He has pulled it into his fixes branch[1], but I don't see it upstream. I've just sent a mail to Dave asking about it. Kevin [1] git://git.kernel.org/pub/scm/linux/kernel/git/davej/cpufreq.git fixes -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/10] ARM: OMAP2+: SmartReflex: move the platform specific macros in plat-omap
* jean.pi...@newoldbits.com jean.pi...@newoldbits.com [120315 09:47]: From: Jean Pihet j-pi...@ti.com Move the platform specific macros from the smartreflex header file (arch/arm/mach-omap2/smartreflex.h) in a new header file in plat-omap (arch/arm/plat-omap/include/plat/smartreflex.h). This change makes the SmartReflex implementation ready for the move to drivers/. Glad to see this happening! This would be better located in linux/power/smartreflex.h rather than plat/smartreflex.h. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arm: omap3: pm34xx.c: Some minor fixups
Hi Mark, Mark A. Greer mgree...@gmail.com writes: found a some minor issues when looking through pm34xx.c recently so these patches try to address them. My apologies if they are already fixed in another branch somewhere. Based on latest k.o. master branch. Thanks for the fixes, they look right. Minor nit: can you resend with linux-arm-kernel in Cc? Any upstream-bound patches need to be Cc'd there so the maintainers don't have to resend them there before submitting a pull request. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()
On Mon, 12 Mar 2012, Santosh Shilimkar wrote:
Commit b1cbdb00d{OMAP: clockdomain: Wait for powerdomain to be ON
when using clockdomain force wakeup} was assuming that pwrdm_state_switch()
does wait for the powerdomain transition which is not the case.
Fix this API by adding the pwrdm_wait_transition().
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Rajendra Nayak rna...@ti.com
CC: Paul Walmsley p...@pwsan.com
Acked-by: Paul Walmsley p...@pwsan.com
Sounds like this fixes a major kernel oops bug for Tony so this should go
in ASAP to v3.3-rc series.
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPIO abort on 3630/Zoom3
DebBarma, Tarun Kanti tarun.ka...@ti.com writes: On Thu, Mar 15, 2012 at 3:35 AM, Kevin Hilman khil...@ti.com wrote: Tarun, Can you investigate an abort during boot on 3630/Zoom3? Both Tony and I are seeing the abort below on 3630/Zoom3. I'm using arm-soc/for-next and Tony is using linux-next, but we see the same abort. The crash looks very similar to what we fixed yesterday. The problem was basically due to usage of OMAP_GPIO_IRQ macro instead of gpio_to_irq() which came as part of Benoit's dynamic irq allocation change. The fix is to replace those macros in the board files. (The same problem is seen on OMAP3430 SDP as well.) Anyways, I will confirm. Adding in your latest fixes series doesn't make the problem go away, but backing out the GPIO runtime PM series does make the problem go away. Because of dynamic irq allocation we end up into wrong GPIO Bank unless we use the new gpio_to_irq(). As a result _set_gpio_triggering() tries to operate on a GPIO Bank whose clock was not turned on using omap_gpio_request(). Probably, that is why we do not see the problem when the runtime PM series is removed because in this case all the GPIO banks are turned on. Yeah, this sounds like the same bug. Thanks for investigating. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arm: omap3: pm34xx.c: Some minor fixups
On Thu, Mar 15, 2012 at 10:27:57AM -0700, Kevin Hilman wrote: Hi Mark, Mark A. Greer mgree...@gmail.com writes: found a some minor issues when looking through pm34xx.c recently so these patches try to address them. My apologies if they are already fixed in another branch somewhere. Based on latest k.o. master branch. Thanks for the fixes, they look right. Minor nit: can you resend with linux-arm-kernel in Cc? Any upstream-bound patches need to be Cc'd there so the maintainers don't have to resend them there before submitting a pull request. Sure. I also have a stray ':' in the Subject of one of them so I'll fix and resend (with fixed 'From:' line too). Mark -- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP: powerdomain: Wait for powerdomain transition in pwrdm_state_switch()
* Paul Walmsley p...@pwsan.com [120315 10:35]:
On Mon, 12 Mar 2012, Santosh Shilimkar wrote:
Commit b1cbdb00d{OMAP: clockdomain: Wait for powerdomain to be ON
when using clockdomain force wakeup} was assuming that pwrdm_state_switch()
does wait for the powerdomain transition which is not the case.
Fix this API by adding the pwrdm_wait_transition().
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
CC: Rajendra Nayak rna...@ti.com
CC: Paul Walmsley p...@pwsan.com
Acked-by: Paul Walmsley p...@pwsan.com
Sounds like this fixes a major kernel oops bug for Tony so this should go
in ASAP to v3.3-rc series.
Got a random oops with this one applied still, just happened
to take longer this time :(
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAPDSS: provide default get_timings function for panels
With this we can eliminate some duplicate code in panel drivers.
Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
tpo-td043mtea1 gain support of reading timings over sysfs.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
drivers/video/omap2/displays/panel-acx565akm.c |7 ---
drivers/video/omap2/displays/panel-generic-dpi.c |7 ---
drivers/video/omap2/displays/panel-n8x0.c|8
drivers/video/omap2/displays/panel-taal.c|8
drivers/video/omap2/dss/core.c |2 ++
drivers/video/omap2/dss/display.c|7 +++
drivers/video/omap2/dss/venc.c |7 ---
include/video/omapdss.h |2 ++
8 files changed, 11 insertions(+), 37 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-acx565akm.c
b/drivers/video/omap2/displays/panel-acx565akm.c
index dbd59b8..d82f09b 100644
--- a/drivers/video/omap2/displays/panel-acx565akm.c
+++ b/drivers/video/omap2/displays/panel-acx565akm.c
@@ -738,12 +738,6 @@ static void acx_panel_set_timings(struct omap_dss_device
*dssdev,
}
}
-static void acx_panel_get_timings(struct omap_dss_device *dssdev,
- struct omap_video_timings *timings)
-{
- *timings = dssdev-panel.timings;
-}
-
static int acx_panel_check_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
@@ -761,7 +755,6 @@ static struct omap_dss_driver acx_panel_driver = {
.resume = acx_panel_resume,
.set_timings= acx_panel_set_timings,
- .get_timings= acx_panel_get_timings,
.check_timings = acx_panel_check_timings,
.get_recommended_bpp = acx_get_recommended_bpp,
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 519c47d..445ea2d 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -460,12 +460,6 @@ static void generic_dpi_panel_set_timings(struct
omap_dss_device *dssdev,
dpi_set_timings(dssdev, timings);
}
-static void generic_dpi_panel_get_timings(struct omap_dss_device *dssdev,
- struct omap_video_timings *timings)
-{
- *timings = dssdev-panel.timings;
-}
-
static int generic_dpi_panel_check_timings(struct omap_dss_device *dssdev,
struct omap_video_timings *timings)
{
@@ -482,7 +476,6 @@ static struct omap_dss_driver dpi_driver = {
.resume = generic_dpi_panel_resume,
.set_timings= generic_dpi_panel_set_timings,
- .get_timings= generic_dpi_panel_get_timings,
.check_timings = generic_dpi_panel_check_timings,
.driver = {
diff --git a/drivers/video/omap2/displays/panel-n8x0.c
b/drivers/video/omap2/displays/panel-n8x0.c
index 150e8ba..eba98a0 100644
--- a/drivers/video/omap2/displays/panel-n8x0.c
+++ b/drivers/video/omap2/displays/panel-n8x0.c
@@ -610,12 +610,6 @@ static int n8x0_panel_resume(struct omap_dss_device
*dssdev)
return 0;
}
-static void n8x0_panel_get_timings(struct omap_dss_device *dssdev,
- struct omap_video_timings *timings)
-{
- *timings = dssdev-panel.timings;
-}
-
static void n8x0_panel_get_resolution(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres)
{
@@ -678,8 +672,6 @@ static struct omap_dss_driver n8x0_panel_driver = {
.get_resolution = n8x0_panel_get_resolution,
.get_recommended_bpp = omapdss_default_get_recommended_bpp,
- .get_timings= n8x0_panel_get_timings,
-
.driver = {
.name = n8x0_panel,
.owner = THIS_MODULE,
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 80c3f6a..174c004 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -583,12 +583,6 @@ static const struct backlight_ops taal_bl_ops = {
.update_status = taal_bl_update_status,
};
-static void taal_get_timings(struct omap_dss_device *dssdev,
- struct omap_video_timings *timings)
-{
- *timings = dssdev-panel.timings;
-}
-
static void taal_get_resolution(struct omap_dss_device *dssdev,
u16 *xres, u16 *yres)
{
@@ -1899,8 +1893,6 @@ static struct omap_dss_driver taal_driver = {
.run_test = taal_run_test,
.memory_read= taal_memory_read,
- .get_timings= taal_get_timings,
-
.driver = {
.name = taal,
.owner = THIS_MODULE,
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 86ec12e..767e132 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -434,6 +434,8 @@ int omap_dss_register_driver(struct omap_dss_driver
*dssdriver)
if (dssdriver-get_recommended_bpp ==
[PATCH 2/2] OMAPDSS: TPO-TD03MTEA1: add set/check timing functions
On pandora we use .set_timings to alter refresh rate,
so add .check_timings/.set_timings functions.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
.../video/omap2/displays/panel-tpo-td043mtea1.c| 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
index bb3da0b..be89801 100644
--- a/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
+++ b/drivers/video/omap2/displays/panel-tpo-td043mtea1.c
@@ -477,6 +477,18 @@ static void tpo_td043_remove(struct omap_dss_device
*dssdev)
gpio_free(nreset_gpio);
}
+static void tpo_td043_set_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ dpi_set_timings(dssdev, timings);
+}
+
+static int tpo_td043_check_timings(struct omap_dss_device *dssdev,
+ struct omap_video_timings *timings)
+{
+ return dpi_check_timings(dssdev, timings);
+}
+
static struct omap_dss_driver tpo_td043_driver = {
.probe = tpo_td043_probe,
.remove = tpo_td043_remove,
@@ -488,6 +500,9 @@ static struct omap_dss_driver tpo_td043_driver = {
.set_mirror = tpo_td043_set_hmirror,
.get_mirror = tpo_td043_get_hmirror,
+ .set_timings= tpo_td043_set_timings,
+ .check_timings = tpo_td043_check_timings,
+
.driver = {
.name = tpo_td043mtea1_panel,
.owner = THIS_MODULE,
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/7] Add TI EMIF SDRAM controller driver
Add a driver for the EMIF SDRAM controller used in TI SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up - Temperature alert configuration and handling of temperature alerts, if any for LPDDR2 devices * temperature alert is based on periodic polling of MR4 mode register in DDR devices automatically performed by hardware * timings are de-rated and brought back to nominal when temperature raises and falls respectively - Cache of calculated register values to avoid re-calculating them The driver will need some minor updates when it is eventually integrated with Dynamic Voltage and Frequency Scaling (DVFS). This can not be done now as DVFS support is not available in the mainline yet. Discussions with Santosh Shilimkar santosh.shilim...@ti.com were immensely helpful in shaping up the interfaces. Vibhore Vardhan vvard...@gmail.com did the initial code snippet for thermal handling. Testing: - The driver is tested on OMAP4430 SDP. - The driver in a slightly adapted form is also tested on OMAP5. - Since mainline kernel doesn't have DVFS support yet, testing was done using a test module. - Temperature alert handling was tested with simulated interrupts and faked temperature values as testing all cases in real-life scenarios is difficult. - Tested the driver as a module Cc: Greg KH g...@kroah.com v2: - Fixed a bug found in the implementation of errata i728 workaround - Fixed the value of frequency printed in debugfs - Dropped the hwmod patch as Paul has already posted a a hwmod series [1] that adds hwmod for EMIF - Converted instances of __init to __init_or_module [1] http://thread.gmane.org/gmane.linux.ports.arm.omap/72855 Aneesh V (7): misc: ddr: add LPDDR2 data from JESD209-2 misc: emif: add register definitions for EMIF misc: emif: add basic infrastructure for EMIF driver misc: emif: handle frequency and voltage change events misc: emif: add interrupt and temperature handling misc: emif: add one-time settings misc: emif: add debugfs entries for emif Documentation/misc-devices/ti-emif.txt | 58 ++ drivers/misc/Kconfig| 12 + drivers/misc/Makefile |1 + drivers/misc/emif.c | 1670 +++ drivers/misc/emif.h | 589 +++ include/linux/platform_data/emif_plat.h | 128 +++ include/misc/jedec_ddr.h| 177 lib/Kconfig |8 + lib/Makefile|3 + lib/jedec_ddr_data.c| 135 +++ 10 files changed, 2781 insertions(+), 0 deletions(-) create mode 100644 Documentation/misc-devices/ti-emif.txt create mode 100644 drivers/misc/emif.c create mode 100644 drivers/misc/emif.h create mode 100644 include/linux/platform_data/emif_plat.h create mode 100644 include/misc/jedec_ddr.h create mode 100644 lib/jedec_ddr_data.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/7] misc: ddr: add LPDDR2 data from JESD209-2
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data will useful for memory controller device drivers
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V ane...@ti.com
---
v1:
- Moved to /lib from /drivers/misc
- Corrected Copyright year
---
include/misc/jedec_ddr.h | 177 ++
lib/Kconfig |8 ++
lib/Makefile |3 +
lib/jedec_ddr_data.c | 135 +++
4 files changed, 323 insertions(+), 0 deletions(-)
create mode 100644 include/misc/jedec_ddr.h
create mode 100644 lib/jedec_ddr_data.c
diff --git a/include/misc/jedec_ddr.h b/include/misc/jedec_ddr.h
new file mode 100644
index 000..93ffd4a
--- /dev/null
+++ b/include/misc/jedec_ddr.h
@@ -0,0 +1,177 @@
+/*
+ * Definitions for DDR memories based on JEDEC specs
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Aneesh V ane...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef __LINUX_JEDEC_DDR_H
+#define __LINUX_JEDEC_DDR_H
+
+#ifndef __ASSEMBLY__
+#include linux/types.h
+
+/* DDR Densities */
+#define DDR_DENSITY_64Mb 1
+#define DDR_DENSITY_128Mb 2
+#define DDR_DENSITY_256Mb 3
+#define DDR_DENSITY_512Mb 4
+#define DDR_DENSITY_1Gb5
+#define DDR_DENSITY_2Gb6
+#define DDR_DENSITY_4Gb7
+#define DDR_DENSITY_8Gb8
+#define DDR_DENSITY_16Gb 9
+#define DDR_DENSITY_32Gb 10
+
+/* DDR type */
+#define DDR_TYPE_DDR2 1
+#define DDR_TYPE_DDR3 2
+#define DDR_TYPE_LPDDR2_S4 3
+#define DDR_TYPE_LPDDR2_S2 4
+#define DDR_TYPE_LPDDR2_NVM5
+
+/* DDR IO width */
+#define DDR_IO_WIDTH_4 1
+#define DDR_IO_WIDTH_8 2
+#define DDR_IO_WIDTH_163
+#define DDR_IO_WIDTH_324
+
+/* Number of Row bits */
+#define R9 9
+#define R1010
+#define R1111
+#define R1212
+#define R1313
+#define R1414
+#define R1515
+#define R1616
+
+/* Number of Column bits */
+#define C7 7
+#define C8 8
+#define C9 9
+#define C1010
+#define C1111
+#define C1212
+
+/* Number of Banks */
+#define B1 0
+#define B2 1
+#define B4 2
+#define B8 3
+
+/* Refresh rate in nano-seconds */
+#define T_REFI_15_615600
+#define T_REFI_7_8 7800
+#define T_REFI_3_9 3900
+
+/* tRFC values */
+#define T_RFC_90 9
+#define T_RFC_110 11
+#define T_RFC_130 13
+#define T_RFC_160 16
+#define T_RFC_210 21
+#define T_RFC_300 30
+#define T_RFC_350 35
+
+/* Mode register numbers */
+#define DDR_MR00
+#define DDR_MR11
+#define DDR_MR22
+#define DDR_MR33
+#define DDR_MR44
+#define DDR_MR55
+#define DDR_MR66
+#define DDR_MR77
+#define DDR_MR88
+#define DDR_MR99
+#define DDR_MR10 10
+#define DDR_MR11 11
+#define DDR_MR16 16
+#define DDR_MR17 17
+#define DDR_MR18 18
+
+/*
+ * LPDDR2 related defines
+ */
+
+/* MR4 register fields */
+#define MR4_SDRAM_REF_RATE_SHIFT 0
+#define MR4_SDRAM_REF_RATE_MASK7
+#define MR4_TUF_SHIFT 7
+#define MR4_TUF_MASK (1 7)
+
+/* MR4 SDRAM Refresh Rate field values */
+#define SDRAM_TEMP_NOMINAL 0x3
+#define SDRAM_TEMP_RESERVED_4 0x4
+#define SDRAM_TEMP_HIGH_DERATE_REFRESH 0x5
+#define SDRAM_TEMP_HIGH_DERATE_REFRESH_AND_TIMINGS 0x6
+#define SDRAM_TEMP_VERY_HIGH_SHUTDOWN 0x7
+
+#define NUM_DDR_ADDR_TABLE_ENTRIES 11
+#define NUM_DDR_TIMING_TABLE_ENTRIES 4
+
+/* Structure for DDR addressing info from the JEDEC spec */
+struct lpddr2_addressing {
+ u32 num_banks;
+ u32 tREFI_ns;
+ u32 tRFCab_ps;
+};
+
+/*
+ * Structure for timings from the LPDDR2 datasheet
+ * All parameters are in pico seconds(ps) unless explicitly indicated
+ * with a suffix like tRAS_max_ns below
+ */
[PATCH v2 3/7] misc: emif: add basic infrastructure for EMIF driver
EMIF is an SDRAM controller used in various Texas Instruments SoCs. EMIF supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols. Add the basic infrastructure for EMIF driver that includes driver registration, probe, parsing of platform data etc. Cc: Greg KH g...@kroah.com Signed-off-by: Aneesh V ane...@ti.com --- v2: - replaced __init with __init_or_module v1: - Removed emif_cleanup() function and instead used devm_* variant of APIs for resource allocations - Split include/linux/emif.h into two parts. The first part now becomes include/linux/platform_data/emif_plat.h and the other part is now merged in drivers/misc/emif.h - Made error messages more verbose - Corrected copyright year - Fixed other coding style comments - Minor adjustments to patch organization. Moved some definitions to a subsequent patch that uses them - Added a list a of devices. This is needed for errata i728 workaround and for the new locking scheme - Added documentation for driver --- Documentation/misc-devices/ti-emif.txt | 58 ++ drivers/misc/Kconfig| 12 ++ drivers/misc/Makefile |1 + drivers/misc/emif.c | 289 +++ drivers/misc/emif.h |7 + include/linux/platform_data/emif_plat.h | 128 ++ 6 files changed, 495 insertions(+), 0 deletions(-) create mode 100644 Documentation/misc-devices/ti-emif.txt create mode 100644 drivers/misc/emif.c create mode 100644 include/linux/platform_data/emif_plat.h diff --git a/Documentation/misc-devices/ti-emif.txt b/Documentation/misc-devices/ti-emif.txt new file mode 100644 index 000..a9238c1 --- /dev/null +++ b/Documentation/misc-devices/ti-emif.txt @@ -0,0 +1,58 @@ +TI EMIF SDRAM Controller Driver: + +Author + +Aneesh V ane...@ti.com + +Location + +driver/misc/emif.c + +Supported SoCs: +=== +TI OMAP44xx +TI OMAP54xx + +Menuconfig option: +== +Device Drivers + Misc devices + Texas Instruments EMIF driver + +Description +=== +This driver is for the EMIF module available in Texas Instruments +SoCs. EMIF is an SDRAM controller that, based on its revision, +supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols. +This driver takes care of only LPDDR2 memories presently. The +functions of the driver includes re-configuring AC timing +parameters and other settings during frequency, voltage and +temperature changes + +Platform Data (see include/linux/platform_data/emif_plat.h): += +DDR device details and other board dependent and SoC dependent +information can be passed through platform data (struct emif_platform_data) +- DDR device details: 'struct ddr_device_info' +- Device AC timings: 'struct lpddr2_timings' and 'struct lpddr2_min_tck' +- Custom configurations: customizable policy options through + 'struct emif_custom_configs' +- IP revision +- PHY type + +Interface to the external world: + +EMIF driver registers notifiers for voltage and frequency changes +affecting EMIF and takes appropriate actions when these are invoked. +- freq_pre_notify_handling() +- freq_post_notify_handling() +- volt_notify_handling() + +Debugfs + +The driver creates two debugfs entries per device. +- regcache_dump : dump of register values calculated and saved for all + frequencies used so far. +- mr4 : last polled value of MR4 register in the LPDDR2 device. MR4 + indicates the current temperature level of the device. + diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig index c779509..847a936 100644 --- a/drivers/misc/Kconfig +++ b/drivers/misc/Kconfig @@ -441,6 +441,18 @@ config VMWARE_BALLOON To compile this driver as a module, choose M here: the module will be called vmw_balloon. +config TI_EMIF + tristate Texas Instruments EMIF driver + select DDR + help + This driver is for the EMIF module available in Texas Instruments + SoCs. EMIF is an SDRAM controller that, based on its revision, + supports one or more of DDR2, DDR3, and LPDDR2 SDRAM protocols. + This driver takes care of only LPDDR2 memories presently. The + functions of the driver includes re-configuring AC timing + parameters and other settings during frequency, voltage and + temperature changes + config ARM_CHARLCD bool ARM Ltd. Character LCD Driver depends on PLAT_VERSATILE diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index 3e1d801..75ab920 100644 --- a/drivers/misc/Makefile +++ b/drivers/misc/Makefile @@ -36,6 +36,7 @@ obj-$(CONFIG_TI_DAC7512) += ti_dac7512.o obj-$(CONFIG_C2PORT) += c2port/ obj-$(CONFIG_IWMC3200TOP) += iwmc3200top/ obj-$(CONFIG_HMC6352) += hmc6352.o +obj-$(CONFIG_TI_EMIF) += emif.o obj-y
[PATCH v2 2/7] misc: emif: add register definitions for EMIF
Add register offsets and bit field definitions for EMIF module in TI SoCs Cc: Greg KH g...@kroah.com Signed-off-by: Aneesh V ane...@ti.com --- v1: - Improved commit log - Corrected copyright year - Changed file name in order to add other defines needed by the driver in the same file in subsequent patches --- drivers/misc/emif.h | 454 +++ 1 files changed, 454 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/emif.h diff --git a/drivers/misc/emif.h b/drivers/misc/emif.h new file mode 100644 index 000..44b97df --- /dev/null +++ b/drivers/misc/emif.h @@ -0,0 +1,454 @@ +/* + * Defines for the EMIF driver + * + * Copyright (C) 2012 Texas Instruments, Inc. + * + * Benoit Cousson (b-cous...@ti.com) + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#ifndef __EMIF_H +#define __EMIF_H + +/* Registers offset */ +#define EMIF_MODULE_ID_AND_REVISION0x +#define EMIF_STATUS0x0004 +#define EMIF_SDRAM_CONFIG 0x0008 +#define EMIF_SDRAM_CONFIG_20x000c +#define EMIF_SDRAM_REFRESH_CONTROL 0x0010 +#define EMIF_SDRAM_REFRESH_CTRL_SHDW 0x0014 +#define EMIF_SDRAM_TIMING_10x0018 +#define EMIF_SDRAM_TIMING_1_SHDW 0x001c +#define EMIF_SDRAM_TIMING_20x0020 +#define EMIF_SDRAM_TIMING_2_SHDW 0x0024 +#define EMIF_SDRAM_TIMING_30x0028 +#define EMIF_SDRAM_TIMING_3_SHDW 0x002c +#define EMIF_LPDDR2_NVM_TIMING 0x0030 +#define EMIF_LPDDR2_NVM_TIMING_SHDW0x0034 +#define EMIF_POWER_MANAGEMENT_CONTROL 0x0038 +#define EMIF_POWER_MANAGEMENT_CTRL_SHDW0x003c +#define EMIF_LPDDR2_MODE_REG_DATA 0x0040 +#define EMIF_LPDDR2_MODE_REG_CONFIG0x0050 +#define EMIF_OCP_CONFIG0x0054 +#define EMIF_OCP_CONFIG_VALUE_10x0058 +#define EMIF_OCP_CONFIG_VALUE_20x005c +#define EMIF_IODFT_TEST_LOGIC_GLOBAL_CONTROL 0x0060 +#define EMIF_IODFT_TEST_LOGIC_CTRL_MISR_RESULT 0x0064 +#define EMIF_IODFT_TEST_LOGIC_ADDRESS_MISR_RESULT 0x0068 +#define EMIF_IODFT_TEST_LOGIC_DATA_MISR_RESULT_1 0x006c +#define EMIF_IODFT_TEST_LOGIC_DATA_MISR_RESULT_2 0x0070 +#define EMIF_IODFT_TEST_LOGIC_DATA_MISR_RESULT_3 0x0074 +#define EMIF_PERFORMANCE_COUNTER_1 0x0080 +#define EMIF_PERFORMANCE_COUNTER_2 0x0084 +#define EMIF_PERFORMANCE_COUNTER_CONFIG0x0088 +#define EMIF_PERFORMANCE_COUNTER_MASTER_REGION_SELECT 0x008c +#define EMIF_PERFORMANCE_COUNTER_TIME 0x0090 +#define EMIF_MISC_REG 0x0094 +#define EMIF_DLL_CALIB_CTRL0x0098 +#define EMIF_DLL_CALIB_CTRL_SHDW 0x009c +#define EMIF_END_OF_INTERRUPT 0x00a0 +#define EMIF_SYSTEM_OCP_INTERRUPT_RAW_STATUS 0x00a4 +#define EMIF_LL_OCP_INTERRUPT_RAW_STATUS 0x00a8 +#define EMIF_SYSTEM_OCP_INTERRUPT_STATUS 0x00ac +#define EMIF_LL_OCP_INTERRUPT_STATUS 0x00b0 +#define EMIF_SYSTEM_OCP_INTERRUPT_ENABLE_SET 0x00b4 +#define EMIF_LL_OCP_INTERRUPT_ENABLE_SET 0x00b8 +#define EMIF_SYSTEM_OCP_INTERRUPT_ENABLE_CLEAR 0x00bc +#define EMIF_LL_OCP_INTERRUPT_ENABLE_CLEAR 0x00c0 +#define EMIF_SDRAM_OUTPUT_IMPEDANCE_CALIBRATION_CONFIG 0x00c8 +#define EMIF_TEMPERATURE_ALERT_CONFIG 0x00cc +#define EMIF_OCP_ERROR_LOG 0x00d0 +#define EMIF_READ_WRITE_LEVELING_RAMP_WINDOW 0x00d4 +#define EMIF_READ_WRITE_LEVELING_RAMP_CONTROL 0x00d8 +#define EMIF_READ_WRITE_LEVELING_CONTROL 0x00dc +#define EMIF_DDR_PHY_CTRL_10x00e4 +#define EMIF_DDR_PHY_CTRL_1_SHDW 0x00e8 +#define EMIF_DDR_PHY_CTRL_20x00ec +#define EMIF_PRIORITY_TO_CLASS_OF_SERVICE_MAPPING 0x0100 +#define EMIF_CONNECTION_ID_TO_CLASS_OF_SERVICE_1_MAPPING 0x0104 +#define EMIF_CONNECTION_ID_TO_CLASS_OF_SERVICE_2_MAPPING 0x0108 +#define EMIF_READ_WRITE_EXECUTION_THRESHOLD0x0120 +#define EMIF_COS_CONFIG0x0124 +#define EMIF_PHY_STATUS_1 0x0140 +#define EMIF_PHY_STATUS_2 0x0144 +#define EMIF_PHY_STATUS_3 0x0148 +#define EMIF_PHY_STATUS_4 0x014c
[PATCH v2 4/7] misc: emif: handle frequency and voltage change events
Change SDRAM timings and other settings as necessary
on voltage and frequency changes. We calculate these
register settings based on data from the device data
sheet and inputs such a frequency, voltage state(stable
or ramping), temperature level etc.
TODO: frequency and voltage change handling needs to
be integrated with clock framework and regulator
framework respectively. This is not done today
due to missing pieces in the kernel.
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V ane...@ti.com
---
v1:
- Added comment in commit log as well as code about
missing integration part that needs to be done in
future
- Removed some settings that were relevant only for
DDR3
- Correction in temperature derated value of tim3
- Added errata i735 and i728 workarounds. As part of
this we need to now maintain a list of all devices
in the driver and iterate through them in some cases
- Improved synchronization. Added protection for newly
identified cases of potential race conditions.
- Minor changes in patch organization. struct members
needed by this patch now defined here.
---
drivers/misc/emif.c | 894 ++-
drivers/misc/emif.h | 130 -
2 files changed, 1020 insertions(+), 4 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index f864640..1ca8165 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -21,6 +21,7 @@
#include linux/seq_file.h
#include linux/module.h
#include linux/list.h
+#include linux/spinlock.h
#include misc/jedec_ddr.h
#include emif.h
@@ -37,20 +38,595 @@
* @node: node in the device list
* @base: base address of memory-mapped IO registers.
* @dev: device pointer.
+ * @addressing table with addressing information from the spec
+ * @regs_cache:An array of 'struct emif_regs' that
stores
+ * calculated register values for different
+ * frequencies, to avoid re-calculating them on
+ * each DVFS transition.
+ * @curr_regs: The set of register values used in the last
+ * frequency change (i.e. corresponding to the
+ * frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
*/
struct emif_data {
u8 duplicate;
u8 temperature_level;
+ u8 lpmode;
struct list_headnode;
+ unsigned long irq_state;
void __iomem*base;
struct device *dev;
+ const struct lpddr2_addressing *addressing;
+ struct emif_regs*regs_cache[EMIF_MAX_NUM_FREQUENCIES];
+ struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
};
static struct emif_data *emif1;
+static spinlock_t emif_lock;
+static unsigned long irq_state;
+static u32 t_ck; /* DDR clock period in ps */
static LIST_HEAD(device_list);
+/*
+ * Calculate the period of DDR clock from frequency value
+ */
+static void set_ddr_clk_period(u32 freq)
+{
+ /* Divide 10^12 by frequency to get period in ps */
+ t_ck = (u32)DIV_ROUND_UP_ULL(1ull, freq);
+}
+
+/*
+ * Get the CL from SDRAM_CONFIG register
+ */
+static u32 get_cl(struct emif_data *emif)
+{
+ u32 cl;
+ void __iomem*base = emif-base;
+
+ cl = (readl(base + EMIF_SDRAM_CONFIG) CL_MASK) CL_SHIFT;
+
+ return cl;
+}
+
+static void set_lpmode(struct emif_data *emif, u8 lpmode)
+{
+ u32 temp;
+ void __iomem *base = emif-base;
+
+ temp = readl(base + EMIF_POWER_MANAGEMENT_CONTROL);
+ temp = ~LP_MODE_MASK;
+ temp |= (lpmode LP_MODE_SHIFT);
+ writel(temp, base + EMIF_POWER_MANAGEMENT_CONTROL);
+}
+
+static void do_freq_update(void)
+{
+ struct emif_data *emif;
+
+ /*
+* Workaround for errata i728: Disable LPMODE during FREQ_UPDATE
+*
+* i728 DESCRIPTION:
+* The EMIF automatically puts the SDRAM into self-refresh mode
+* after the EMIF has not performed accesses during
+* EMIF_PWR_MGMT_CTRL[7:4] REG_SR_TIM number of DDR clock cycles
+* and the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set
+* to 0x2. If during a small window the following three events
+* occur:
+* - The SR_TIMING counter expires
+* - And frequency change is requested
+* - And OCP access is requested
+* Then it causes instable clock on the DDR interface.
+*
+* WORKAROUND
+* To avoid the occurrence of the three events, the workaround
+* is to disable the self-refresh when requesting a frequency
+*
[PATCH v2 5/7] misc: emif: add interrupt and temperature handling
Add an ISR for EMIF that:
1. reports details of access errors
2. takes action on thermal events
Also clear all interrupts on shut-down. Pending IRQs
may casue problems during warm-reset.
Temperature handling:
EMIF can be configured to poll the temperature level
of an LPDDR2 device from the MR4 mode register in the
device. EMIF generates an interrupt whenever it identifies
a temperature level change between two consecutive pollings.
Some of the timing parameters need to be de-rated at high
temperatures. The interrupt handler takes care of doing
this and also takes care of going back to nominal settings
when temperature falls back to nominal levels.
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V ane...@ti.com
---
v2:
- replaced __init with __init_or_module
v1:
- Improved commit log
- Improved synchronization with thread context
---
drivers/misc/emif.c | 211 ++-
1 files changed, 209 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index 1ca8165..52048f4 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -545,6 +545,42 @@ static u32 get_pwr_mgmt_ctrl(u32 freq, struct emif_data
*emif, u32 ip_rev)
}
/*
+ * Get the temperature level of the EMIF instance:
+ * Reads the MR4 register of attached SDRAM parts to find out the temperature
+ * level. If there are two parts attached(one on each CS), then the temperature
+ * level for the EMIF instance is the higher of the two temperatures.
+ */
+static void get_temperature_level(struct emif_data *emif)
+{
+ u32 temp, temperature_level;
+ void __iomem*base;
+
+ base = emif-base;
+
+ /* Read mode register 4 */
+ writel(DDR_MR4, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temperature_level = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temperature_level = (temperature_level MR4_SDRAM_REF_RATE_MASK)
+ MR4_SDRAM_REF_RATE_SHIFT;
+
+ if (emif-plat_data-device_info-cs1_used) {
+ writel(DDR_MR4 | CS_MASK, base + EMIF_LPDDR2_MODE_REG_CONFIG);
+ temp = readl(base + EMIF_LPDDR2_MODE_REG_DATA);
+ temp = (temp MR4_SDRAM_REF_RATE_MASK)
+MR4_SDRAM_REF_RATE_SHIFT;
+ temperature_level = max(temp, temperature_level);
+ }
+
+ /* treat everything less than nominal(3) in MR4 as nominal */
+ if (unlikely(temperature_level SDRAM_TEMP_NOMINAL))
+ temperature_level = SDRAM_TEMP_NOMINAL;
+
+ /* if we get reserved value in MR4 persist with the existing value */
+ if (likely(temperature_level != SDRAM_TEMP_RESERVED_4))
+ emif-temperature_level = temperature_level;
+}
+
+/*
* Program EMIF shadow registers that are not dependent on temperature
* or voltage
*/
@@ -627,6 +663,158 @@ out:
writel(ref_ctrl, base + EMIF_SDRAM_REFRESH_CTRL_SHDW);
}
+static irqreturn_t handle_temp_alert(void __iomem *base, struct emif_data
*emif)
+{
+ u32 old_temp_level;
+ irqreturn_t ret = IRQ_HANDLED;
+
+ spin_lock_irqsave(emif_lock, irq_state);
+ old_temp_level = emif-temperature_level;
+ get_temperature_level(emif);
+
+ if (unlikely(emif-temperature_level == old_temp_level)) {
+ goto out;
+ } else if (!emif-curr_regs) {
+ dev_err(emif-dev, temperature alert before registers are
calculated, not de-rating timings\n);
+ goto out;
+ }
+
+ if (emif-temperature_level old_temp_level ||
+ emif-temperature_level == SDRAM_TEMP_VERY_HIGH_SHUTDOWN) {
+ /*
+* Temperature coming down - defer handling to thread OR
+* Temperature far too high - do kernel_power_off() from
+* thread context
+*/
+ ret = IRQ_WAKE_THREAD;
+ } else {
+ /* Temperature is going up - handle immediately */
+ setup_temperature_sensitive_regs(emif, emif-curr_regs);
+ do_freq_update();
+ }
+
+out:
+ spin_unlock_irqrestore(emif_lock, irq_state);
+ return ret;
+}
+
+static irqreturn_t emif_interrupt_handler(int irq, void *dev_id)
+{
+ u32 interrupts;
+ struct emif_data*emif = dev_id;
+ void __iomem*base = emif-base;
+ struct device *dev = emif-dev;
+ irqreturn_t ret = IRQ_HANDLED;
+
+ /* Save the status and clear it */
+ interrupts = readl(base + EMIF_SYSTEM_OCP_INTERRUPT_STATUS);
+ writel(interrupts, base + EMIF_SYSTEM_OCP_INTERRUPT_STATUS);
+
+ /*
+* Handle temperature alert
+* Temperature alert should be same for all ports
+* So, it's enough to process it only for one of the ports
+*/
+ if (interrupts TA_SYS_MASK)
+ ret =
[PATCH v2 7/7] misc: emif: add debugfs entries for emif
Add debug entries for:
1. calculated registers per frequency
2. last polled value of MR4(temperature level
of LPDDR2 memory)
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V ane...@ti.com
---
v2:
- Corrected the frequency value shown in
register cache dump
- replaced __init with __init_or_module
---
drivers/misc/emif.c | 138 +++
1 files changed, 138 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index 270a0e4..6d2f776 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
#include linux/list.h
@@ -47,6 +48,7 @@
* frequency change (i.e. corresponding to the
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
+ * @debugfs_root: dentry to the root folder for EMIF in debugfs
*/
struct emif_data {
u8 duplicate;
@@ -60,6 +62,7 @@ struct emif_data {
struct emif_regs*regs_cache[EMIF_MAX_NUM_FREQUENCIES];
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
+ struct dentry *debugfs_root;
};
static struct emif_data *emif1;
@@ -68,6 +71,130 @@ static unsigned longirq_state;
static u32 t_ck; /* DDR clock period in ps */
static LIST_HEAD(device_list);
+static void do_emif_regdump_show(struct seq_file *s, struct emif_data *emif,
+ struct emif_regs *regs)
+{
+ u32 type = emif-plat_data-device_info-type;
+ u32 ip_rev = emif-plat_data-ip_rev;
+
+ seq_printf(s, EMIF register cache dump for %dMHz\n,
+ regs-freq/100);
+
+ seq_printf(s, ref_ctrl_shdw\t: 0x%08x\n, regs-ref_ctrl_shdw);
+ seq_printf(s, sdram_tim1_shdw\t: 0x%08x\n, regs-sdram_tim1_shdw);
+ seq_printf(s, sdram_tim2_shdw\t: 0x%08x\n, regs-sdram_tim2_shdw);
+ seq_printf(s, sdram_tim3_shdw\t: 0x%08x\n, regs-sdram_tim3_shdw);
+
+ if (ip_rev == EMIF_4D) {
+ seq_printf(s, read_idle_ctrl_shdw_normal\t: 0x%08x\n,
+ regs-read_idle_ctrl_shdw_normal);
+ seq_printf(s, read_idle_ctrl_shdw_volt_ramp\t: 0x%08x\n,
+ regs-read_idle_ctrl_shdw_volt_ramp);
+ } else if (ip_rev == EMIF_4D5) {
+ seq_printf(s, dll_calib_ctrl_shdw_normal\t: 0x%08x\n,
+ regs-dll_calib_ctrl_shdw_normal);
+ seq_printf(s, dll_calib_ctrl_shdw_volt_ramp\t: 0x%08x\n,
+ regs-dll_calib_ctrl_shdw_volt_ramp);
+ }
+
+ if (type == DDR_TYPE_LPDDR2_S2 || type == DDR_TYPE_LPDDR2_S4) {
+ seq_printf(s, ref_ctrl_shdw_derated\t: 0x%08x\n,
+ regs-ref_ctrl_shdw_derated);
+ seq_printf(s, sdram_tim1_shdw_derated\t: 0x%08x\n,
+ regs-sdram_tim1_shdw_derated);
+ seq_printf(s, sdram_tim3_shdw_derated\t: 0x%08x\n,
+ regs-sdram_tim3_shdw_derated);
+ }
+}
+
+static int emif_regdump_show(struct seq_file *s, void *unused)
+{
+ struct emif_data*emif = s-private;
+ struct emif_regs**regs_cache;
+ int i;
+
+ if (emif-duplicate)
+ regs_cache = emif1-regs_cache;
+ else
+ regs_cache = emif-regs_cache;
+
+ for (i = 0; i EMIF_MAX_NUM_FREQUENCIES regs_cache[i]; i++) {
+ do_emif_regdump_show(s, emif, regs_cache[i]);
+ seq_printf(s, \n);
+ }
+
+ return 0;
+}
+
+static int emif_regdump_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, emif_regdump_show, inode-i_private);
+}
+
+static const struct file_operations emif_regdump_fops = {
+ .open = emif_regdump_open,
+ .read = seq_read,
+ .release= single_release,
+};
+
+static int emif_mr4_show(struct seq_file *s, void *unused)
+{
+ struct emif_data *emif = s-private;
+
+ seq_printf(s, MR4=%d\n, emif-temperature_level);
+ return 0;
+}
+
+static int emif_mr4_open(struct inode *inode, struct file *file)
+{
+ return single_open(file, emif_mr4_show, inode-i_private);
+}
+
+static const struct file_operations emif_mr4_fops = {
+ .open = emif_mr4_open,
+ .read = seq_read,
+ .release= single_release,
+};
+
+static int __init_or_module emif_debugfs_init(struct emif_data *emif)
+{
+ struct dentry *dentry;
+ int ret;
+
+ dentry = debugfs_create_dir(dev_name(emif-dev), NULL);
+ if (IS_ERR(dentry)) {
+
[PATCH v2 6/7] misc: emif: add one-time settings
Add settings that are not dependent on frequency
or any other transient parameters. This includes
- power managment control init
- impedence calibration control
- frequency independent phy configuration registers
- initialization of temperature polling
Cc: Greg KH g...@kroah.com
Signed-off-by: Aneesh V ane...@ti.com
---
v2:
- replaced __init with __init_or_module
- fixed bug in the implementation of i728 errata workaround
v1:
- Improved commit log
- Changes for errata i728 workaround
---
drivers/misc/emif.c | 148 +++
1 files changed, 148 insertions(+), 0 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index 52048f4..270a0e4 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -78,6 +78,24 @@ static void set_ddr_clk_period(u32 freq)
}
/*
+ * Get bus width used by EMIF. Note that this may be different from the
+ * bus width of the DDR devices used. For instance two 16-bit DDR devices
+ * may be connected to a given CS of EMIF. In this case bus width as far
+ * as EMIF is concerned is 32, where as the DDR bus width is 16 bits.
+ */
+static u32 get_emif_bus_width(struct emif_data *emif)
+{
+ u32 width;
+ void __iomem*base = emif-base;
+
+ width = (readl(base + EMIF_SDRAM_CONFIG) NARROW_MODE_MASK)
+NARROW_MODE_SHIFT;
+ width = width == 0 ? 32 : 16;
+
+ return width;
+}
+
+/*
* Get the CL from SDRAM_CONFIG register
*/
static u32 get_cl(struct emif_data *emif)
@@ -372,6 +390,70 @@ static u32 get_sdram_tim_3_shdw(const struct
lpddr2_timings *timings,
return tim3;
}
+static u32 get_zq_config_reg(const struct lpddr2_addressing *addressing,
+ bool cs1_used, bool cal_resistors_per_cs)
+{
+ u32 zq = 0, val = 0;
+
+ val = EMIF_ZQCS_INTERVAL_US * 1000 / addressing-tREFI_ns;
+ zq |= val ZQ_REFINTERVAL_SHIFT;
+
+ val = DIV_ROUND_UP(T_ZQCL_DEFAULT_NS, T_ZQCS_DEFAULT_NS) - 1;
+ zq |= val ZQ_ZQCL_MULT_SHIFT;
+
+ val = DIV_ROUND_UP(T_ZQINIT_DEFAULT_NS, T_ZQCL_DEFAULT_NS) - 1;
+ zq |= val ZQ_ZQINIT_MULT_SHIFT;
+
+ zq |= ZQ_SFEXITEN_ENABLE ZQ_SFEXITEN_SHIFT;
+
+ if (cal_resistors_per_cs)
+ zq |= ZQ_DUALCALEN_ENABLE ZQ_DUALCALEN_SHIFT;
+ else
+ zq |= ZQ_DUALCALEN_DISABLE ZQ_DUALCALEN_SHIFT;
+
+ zq |= ZQ_CS0EN_MASK; /* CS0 is used for sure */
+
+ val = cs1_used ? 1 : 0;
+ zq |= val ZQ_CS1EN_SHIFT;
+
+ return zq;
+}
+
+static u32 get_temp_alert_config(const struct lpddr2_addressing *addressing,
+ const struct emif_custom_configs *custom_configs, bool cs1_used,
+ u32 sdram_io_width, u32 emif_bus_width)
+{
+ u32 alert = 0, interval, devcnt;
+
+ if (custom_configs (custom_configs-mask
+ EMIF_CUSTOM_CONFIG_TEMP_ALERT_POLL_INTERVAL))
+ interval = custom_configs-temp_alert_poll_interval_ms;
+ else
+ interval = TEMP_ALERT_POLL_INTERVAL_DEFAULT_MS;
+
+ interval *= 100;/* Convert to ns */
+ interval /= addressing-tREFI_ns; /* Convert to refresh cycles */
+ alert |= (interval TA_REFINTERVAL_SHIFT);
+
+ /*
+* sdram_io_width is in 'log2(x) - 1' form. Convert emif_bus_width
+* also to this form and subtract to get TA_DEVCNT, which is
+* in log2(x) form.
+*/
+ emif_bus_width = __fls(emif_bus_width) - 1;
+ devcnt = emif_bus_width - sdram_io_width;
+ alert |= devcnt TA_DEVCNT_SHIFT;
+
+ /* DEVWDT is in 'log2(x) - 3' form */
+ alert |= (sdram_io_width - 2) TA_DEVWDT_SHIFT;
+
+ alert |= 1 TA_SFEXITEN_SHIFT;
+ alert |= 1 TA_CS0EN_SHIFT;
+ alert |= (cs1_used ? 1 : 0) TA_CS1EN_SHIFT;
+
+ return alert;
+}
+
static u32 get_read_idle_ctrl_shdw(u8 volt_ramp)
{
u32 idle = 0, val = 0;
@@ -815,6 +897,71 @@ static int __init_or_module setup_interrupts(struct
emif_data *emif, u32 irq)
}
+static void __init_or_module emif_onetime_settings(struct emif_data *emif)
+{
+ u32 pwr_mgmt_ctrl, zq, temp_alert_cfg;
+ void __iomem*base = emif-base;
+ const struct lpddr2_addressing *addressing;
+ const struct ddr_device_info*device_info;
+
+ device_info = emif-plat_data-device_info;
+ addressing = get_addressing_table(device_info);
+
+ /*
+* Init power management settings
+* We don't know the frequency yet. Use a high frequency
+* value for a conservative timeout setting
+*/
+ pwr_mgmt_ctrl = get_pwr_mgmt_ctrl(10, emif,
+ emif-plat_data-ip_rev);
+ emif-lpmode = (pwr_mgmt_ctrl LP_MODE_MASK) LP_MODE_SHIFT;
+ writel(pwr_mgmt_ctrl, base + EMIF_POWER_MANAGEMENT_CONTROL);
+
+ /* Init ZQ calibration settings */
+ zq =
[PATCH] OMAP: clock: fix race in disable all clocks
clk_disable_unused is invoked when CONFIG_OMAP_RESET_CLOCKS=y.
Since clk_disable_unused is called as lateinitcall, there can
be more than a few workqueues executing off secondary CPU(s).
The current code does the following:
a) checks if clk is unused
b) holds lock
c) disables clk
d) unlocks
Between (a) and (b) being executed on CPU0, It is possible to
have a driver executing on CPU1 which could do a get_sync-clk_get
(and increase the use_count) of the clock which was just about
to be disabled by clk_disable_unused.
We ensure instead that the entire list traversal is protected by
the lock allowing for parent child clock traversal which could be
potentially be done by runtime operations to be safe as well.
Reported-by: Todd Poynor toddpoy...@google.com
Signed-off-by: Nishanth Menon n...@ti.com
---
To confirm this in reality happens, I setup a trap as follows:
@@ -450,6 +450,8 @@ static int __init clk_disable_unused(void)
continue;
spin_lock_irqsave(clockfw_lock, flags);
+ WARN(ck-usecount, -RACECONDITION FOR CLOCK %s\n,
+ ck-name);
arch_clock-clk_disable_unused(ck);
spin_unlock_irqrestore(clockfw_lock, flags);
}
Resultant log: http://pastebin.pandaboard.org/index.php/view/66400792
arch/arm/plat-omap/clock.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/clock.c b/arch/arm/plat-omap/clock.c
index 567e4b5..8030cc1 100644
--- a/arch/arm/plat-omap/clock.c
+++ b/arch/arm/plat-omap/clock.c
@@ -442,6 +442,8 @@ static int __init clk_disable_unused(void)
return 0;
pr_info(clock: disabling unused clocks to save power\n);
+
+ spin_lock_irqsave(clockfw_lock, flags);
list_for_each_entry(ck, clocks, node) {
if (ck-ops == clkops_null)
continue;
@@ -449,10 +451,9 @@ static int __init clk_disable_unused(void)
if (ck-usecount 0 || !ck-enable_reg)
continue;
- spin_lock_irqsave(clockfw_lock, flags);
arch_clock-clk_disable_unused(ck);
- spin_unlock_irqrestore(clockfw_lock, flags);
}
+ spin_unlock_irqrestore(clockfw_lock, flags);
return 0;
}
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] dt: device tree support for TI EMIF driver
This series adds device tree support for TI EMIF SDRAM controller driver. For this, a binding has been added for representing AC timing parameters and other details of LPDDR2 memories. This series depends v2 of my series for adding EMIF driver [1] [1] http://marc.info/?l=linux-omapm=133183554007498w=2 Cc: Rajendra Nayak rna...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Grant Likely grant.lik...@secretlab.ca Aneesh V (4): dt: device tree bindings for LPDDR2 memories dt: emif: device tree bindings for TI's EMIF sdram controller arm: dts: EMIF and LPDDR2 device tree data for OMAP4 boards misc: emif: add device tree support to emif driver .../devicetree/bindings/lpddr2/lpddr2-timings.txt | 52 .../devicetree/bindings/lpddr2/lpddr2.txt | 102 +++ .../bindings/memory-controllers/ti/emif.txt| 55 arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 67 + arch/arm/boot/dts/omap4-panda.dts | 13 + arch/arm/boot/dts/omap4-sdp.dts| 13 + arch/arm/boot/dts/omap4.dtsi | 18 ++ drivers/misc/emif.c| 285 +++- 8 files changed, 604 insertions(+), 1 deletions(-) create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2.txt create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti/emif.txt create mode 100644 arch/arm/boot/dts/elpida_ecb240abacn.dtsi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] dt: device tree bindings for LPDDR2 memories
device tree bindings for LPDDR2 SDRAM memories compliant
to JESD209-2 standard.
The 'lpddr2' binding in-turn uses another binding 'lpddr2-timings'
for specifying the AC timing parameters of the memory device at
different speed-bins.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Aneesh V ane...@ti.com
---
v1:
- Removed two DDR3 only timing parameters that were
inadvertently added in the binding
---
.../devicetree/bindings/lpddr2/lpddr2-timings.txt | 52 ++
.../devicetree/bindings/lpddr2/lpddr2.txt | 102
2 files changed, 154 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
create mode 100644 Documentation/devicetree/bindings/lpddr2/lpddr2.txt
diff --git a/Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
b/Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
new file mode 100644
index 000..a48f698
--- /dev/null
+++ b/Documentation/devicetree/bindings/lpddr2/lpddr2-timings.txt
@@ -0,0 +1,52 @@
+* AC timing parameters of LPDDR2(JESD209-2) memories for a given speed-bin
+
+Required properties:
+- compatible : Should be jedec,lpddr2-timings
+- min-freq : minimum DDR clock frequency for the speed-bin. Type is u32
+- max-freq : maximum DDR clock frequency for the speed-bin. Type is u32
+
+Optional properties:
+
+The following properties represent AC timing parameters from the memory
+data-sheet of the device for a given speed-bin. All these properties are
+of type u32 and the default unit is ps (pico seconds). Parameters with
+a different unit have a suffix indicating the unit such as 'tRAS-max-ns'
+- tRCD
+- tWR
+- tRAS-min
+- tRRD
+- tWTR
+- tXP
+- tRTP
+- tDQSCK-max
+- tFAW
+- tZQCS
+- tZQinit
+- tRPab
+- tZQCL
+- tCKESR
+- tRAS-max-ns
+- tDQSCK-max-derated
+
+Example:
+
+timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 4;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+};
diff --git a/Documentation/devicetree/bindings/lpddr2/lpddr2.txt
b/Documentation/devicetree/bindings/lpddr2/lpddr2.txt
new file mode 100644
index 000..a2ab203
--- /dev/null
+++ b/Documentation/devicetree/bindings/lpddr2/lpddr2.txt
@@ -0,0 +1,102 @@
+* LPDDR2 SDRAM memories compliant to JEDEC JESD209-2
+
+Required properties:
+- compatible : Should be one of - jedec,lpddr2-nvm, jedec,lpddr2-s2,
+ jedec,lpddr2-s4
+
+ ti,jedec-lpddr2-s2 should be listed if the memory part is LPDDR2-S2 type
+
+ ti,jedec-lpddr2-s4 should be listed if the memory part is LPDDR2-S4 type
+
+ ti,jedec-lpddr2-nvm should be listed if the memory part is LPDDR2-NVM type
+
+- density : u32 representing density in Mb (Mega bits)
+
+- io-width : u32 representing bus width. Possible values are 8, 16, and 32
+
+Optional properties:
+
+The following optional properties represent the minimum value of some AC
+timing parameters of the DDR device in terms of number of clock cycles.
+These values shall be obtained from the device data-sheet.
+- tRRD-min-tck
+- tWTR-min-tck
+- tXP-min-tck
+- tRTP-min-tck
+- tCKE-min-tck
+- tRPab-min-tck
+- tRCD-min-tck
+- tWR-min-tck
+- tRASmin-min-tck
+- tCKESR-min-tck
+- tFAW-min-tck
+
+Child nodes:
+- The lpddr2 node may have one or more child nodes of type lpddr2-timings.
+ lpddr2-timings provides AC timing parameters of the device for
+ a given speed-bin. The user may provide the timings for as many
+ speed-bins as is required. Please see Documentation/devicetree/
+ bindings/lpddr2/lpddr2-timings.txt for more information on lpddr2-timings
+
+Example:
+
+elpida_ECB240ABACN : lpddr2 {
+ compatible = Elpida,ECB240ABACN,jedec,lpddr2-s4;
+ density = 2048;
+ io-width= 32;
+
+ tRPab-min-tck = 3;
+ tRCD-min-tck= 3;
+ tWR-min-tck = 3;
+ tRASmin-min-tck = 3;
+ tRRD-min-tck= 2;
+ tWTR-min-tck= 2;
+ tXP-min-tck = 2;
+ tRTP-min-tck= 2;
+ tCKE-min-tck= 3;
+ tCKESR-min-tck = 3;
+ tFAW-min-tck= 8;
+
+ timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 4;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+
[PATCH v2 2/4] dt: emif: device tree bindings for TI's EMIF sdram controller
EMIF - External Memory Interface - is an SDRAM controller used in
TI SoCs. EMIF supports, based on the IP revision, one or more of
DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
of the EMIF IP and memory parts attached to it.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Aneesh V ane...@ti.com
---
---
.../bindings/memory-controllers/ti/emif.txt| 55
1 files changed, 55 insertions(+), 0 deletions(-)
create mode 100644
Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
new file mode 100644
index 000..938f8e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti/emif.txt
@@ -0,0 +1,55 @@
+* EMIF family of TI SDRAM controllers
+
+EMIF - External Memory Interface - is an SDRAM controller used in
+TI SoCs. EMIF supports, based on the IP revision, one or more of
+DDR2/DDR3/LPDDR2 protocols. This binding describes a given instance
+of the EMIF IP and memory parts attached to it.
+
+Required properties:
+- compatible : Should be of the form ti,emif-ip-rev where ip-rev
+ is the IP revision of the specific EMIF instance.
+
+- phy-type : u32 indicating the DDR phy type. Following are the
+ allowed values
+ 1 : Attila PHY
+ 2 : Intelli PHY
+
+- device-handle: phandle to a lpddr2 node representing the memory
part
+
+- ti,hwmods: For TI hwmods processing and omap device creation
+ the value shall be emifn where n is the number of the EMIF
+ instance with base 1.
+
+Optional properties:
+- cs1-used : Have this property if CS1 of this EMIF
+ instance has a memory part attached to it. If there is a memory
+ part attached to CS1, it should be the same type as the one on CS0,
+ so there is no need to give the details of this memory part.
+
+- cal-resistor-per-cs : Have this property if the board has one
+ calibration resistor per chip-select.
+
+- hw-caps-read-idle-ctrl: Have this property if the controller
+ supports read idle window programming
+
+- hw-caps-dll-calib-ctrl: Have this property if the controller
+ supports dll calibration control
+
+- hw-caps-ll-interface : Have this property if the controller
+ has a low latency interface and corresponding interrupt events
+
+- hw-caps-temp-alert : Have this property if the controller
+ has capability for generating SDRAM temperature alerts
+
+Example:
+
+emif1: emif@0x4c00 {
+ compatible = ti,emif-4d;
+ ti,hwmods = emif2;
+ phy-type= 1;
+ device-handle = elpida_ECB240ABACN;
+ cs1-used;
+ hw-caps-read-idle-ctrl;
+ hw-caps-ll-interface;
+ hw-caps-temp-alert;
+};
--
1.7.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 3/4] arm: dts: EMIF and LPDDR2 device tree data for OMAP4 boards
Device tree data for the EMIF sdram controllers in OMAP4
and LPDDR2 memory devices attached to OMAP4 boards.
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Aneesh V ane...@ti.com
---
v1:
- Removed DDR3 only parameters from
elpida_ecb240abacn.dtsi
---
arch/arm/boot/dts/elpida_ecb240abacn.dtsi | 67 +
arch/arm/boot/dts/omap4-panda.dts | 13 ++
arch/arm/boot/dts/omap4-sdp.dts | 13 ++
arch/arm/boot/dts/omap4.dtsi | 18
4 files changed, 111 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/elpida_ecb240abacn.dtsi
diff --git a/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
b/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
new file mode 100644
index 000..34b9f72
--- /dev/null
+++ b/arch/arm/boot/dts/elpida_ecb240abacn.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Common devices used in different OMAP boards
+ */
+
+/ {
+ elpida_ECB240ABACN: lpddr2 {
+ compatible = Elpida,ECB240ABACN,jedec,lpddr2-s4;
+ density = 2048;
+ io-width= 32;
+
+ tRPab-min-tck = 3;
+ tRCD-min-tck= 3;
+ tWR-min-tck = 3;
+ tRASmin-min-tck = 3;
+ tRRD-min-tck= 2;
+ tWTR-min-tck= 2;
+ tXP-min-tck = 2;
+ tRTP-min-tck= 2;
+ tCKE-min-tck= 3;
+ tCKESR-min-tck = 3;
+ tFAW-min-tck= 8;
+
+ timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 4;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 7500;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 6000;
+ };
+
+ timings_elpida_ECB240ABACN_200mhz: lpddr2-timings@1 {
+ compatible = jedec,lpddr2-timings;
+ min-freq= 1000;
+ max-freq= 2;
+ tRPab = 21000;
+ tRCD= 18000;
+ tWR = 15000;
+ tRAS-min= 42000;
+ tRRD= 1;
+ tWTR= 1;
+ tXP = 7500;
+ tRTP= 7500;
+ tCKESR = 15000;
+ tDQSCK-max = 5500;
+ tFAW= 5;
+ tZQCS = 9;
+ tZQCL = 36;
+ tZQinit = 100;
+ tRAS-max-ns = 7;
+ tDQSCK-max-derated = 6000;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 9755ad5..f548523 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ omap4.dtsi
+/include/ elpida_ecb240abacn.dtsi
/ {
model = TI OMAP4 PandaBoard;
@@ -17,4 +18,16 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ ocp {
+ emif1: emif@0x4c00 {
+ cs1-used;
+ device-handle = elpida_ECB240ABACN;
+ };
+
+ emif2: emif@0x4d00 {
+ cs1-used;
+ device-handle = elpida_ECB240ABACN;
+ };
+ };
};
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 63c6b2b..6dc08bc 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -8,6 +8,7 @@
/dts-v1/;
/include/ omap4.dtsi
+/include/ elpida_ecb240abacn.dtsi
/ {
model = TI OMAP4 SDP board;
@@ -17,4 +18,16 @@
device_type = memory;
reg = 0x8000 0x4000; /* 1 GB */
};
+
+ ocp {
+ emif1: emif@0x4c00 {
+
[PATCH v2 4/4] misc: emif: add device tree support to emif driver
Cc: Rajendra Nayak rna...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Grant Likely grant.lik...@secretlab.ca
Signed-off-by: Aneesh V ane...@ti.com
---
v2:
- Addressed comments from Grant Likely:
Converted occurences of __init to __init_or_module
Removed un-necessary instances of #ifdef CONFIG_OF
- Rebased to v2 of EMIF driver series
v1:
- Rebased to the latest version of EMIF series
- Replace kzalloc()/kfree() with devm_* variants
---
drivers/misc/emif.c | 285 ++-
1 files changed, 284 insertions(+), 1 deletions(-)
diff --git a/drivers/misc/emif.c b/drivers/misc/emif.c
index 6d2f776..75f21d2 100644
--- a/drivers/misc/emif.c
+++ b/drivers/misc/emif.c
@@ -18,6 +18,7 @@
#include linux/platform_device.h
#include linux/interrupt.h
#include linux/slab.h
+#include linux/of.h
#include linux/debugfs.h
#include linux/seq_file.h
#include linux/module.h
@@ -49,6 +50,7 @@
* frequency in effect at the moment)
* @plat_data: Pointer to saved platform data.
* @debugfs_root: dentry to the root folder for EMIF in debugfs
+ * @np_ddr:Pointer to ddr device tree node
*/
struct emif_data {
u8 duplicate;
@@ -63,6 +65,7 @@ struct emif_data {
struct emif_regs*curr_regs;
struct emif_platform_data *plat_data;
struct dentry *debugfs_root;
+ struct device_node *np_ddr;
};
static struct emif_data *emif1;
@@ -1148,6 +1151,270 @@ static int is_custom_config_valid(struct
emif_custom_configs *cust_cfgs,
return valid;
}
+#if defined(CONFIG_OF)
+static void __init_or_module of_get_custom_configs(struct device_node *np_emif,
+ struct emif_data *emif)
+{
+ struct emif_custom_configs *cust_cfgs = NULL;
+ int len;
+ const int *lpmode, *poll_intvl;
+
+ lpmode = of_get_property(np_emif, low-power-mode, len);
+ poll_intvl = of_get_property(np_emif, temp-alert-poll-interval, len);
+
+ if (lpmode || poll_intvl)
+ cust_cfgs = devm_kzalloc(emif-dev, sizeof(*cust_cfgs),
+ GFP_KERNEL);
+
+ if (!cust_cfgs)
+ return;
+
+ if (lpmode) {
+ cust_cfgs-mask |= EMIF_CUSTOM_CONFIG_LPMODE;
+ cust_cfgs-lpmode = *lpmode;
+ of_property_read_u32(np_emif,
+ low-power-mode-timeout-performance,
+ cust_cfgs-lpmode_timeout_performance);
+ of_property_read_u32(np_emif,
+ low-power-mode-timeout-power,
+ cust_cfgs-lpmode_timeout_power);
+ of_property_read_u32(np_emif,
+ low-power-mode-freq-threshold,
+ cust_cfgs-lpmode_freq_threshold);
+ }
+
+ if (poll_intvl) {
+ cust_cfgs-mask |=
+ EMIF_CUSTOM_CONFIG_TEMP_ALERT_POLL_INTERVAL;
+ cust_cfgs-temp_alert_poll_interval_ms = *poll_intvl;
+ }
+
+ if (!is_custom_config_valid(cust_cfgs, emif-dev)) {
+ devm_kfree(emif-dev, cust_cfgs);
+ return;
+ }
+
+ emif-plat_data-custom_configs = cust_cfgs;
+}
+
+static void __init_or_module of_get_min_tck(struct device_node *np,
+ struct emif_data *emif)
+{
+ int ret = 0;
+ struct lpddr2_min_tck *min;
+
+ min = devm_kzalloc(emif-dev, sizeof(*min), GFP_KERNEL);
+ if (!min)
+ goto default_min_tck;
+
+ ret |= of_property_read_u32(np, tRPab-min-tck, min-tRPab);
+ ret |= of_property_read_u32(np, tRCD-min-tck, min-tRCD);
+ ret |= of_property_read_u32(np, tWR-min-tck, min-tWR);
+ ret |= of_property_read_u32(np, tRASmin-min-tck, min-tRASmin);
+ ret |= of_property_read_u32(np, tRRD-min-tck, min-tRRD);
+ ret |= of_property_read_u32(np, tWTR-min-tck, min-tWTR);
+ ret |= of_property_read_u32(np, tXP-min-tck, min-tXP);
+ ret |= of_property_read_u32(np, tRTP-min-tck, min-tRTP);
+ ret |= of_property_read_u32(np, tCKE-min-tck, min-tCKE);
+ ret |= of_property_read_u32(np, tCKESR-min-tck, min-tCKESR);
+ ret |= of_property_read_u32(np, tFAW-min-tck, min-tFAW);
+
+ if (ret) {
+ devm_kfree(emif-dev, min);
+ goto default_min_tck;
+ }
+
+ emif-plat_data-min_tck = min;
+ return;
+
+default_min_tck:
+ dev_warn(emif-dev, %s: using default min-tck values\n, __func__);
+ emif-plat_data-min_tck = lpddr2_jedec_min_tck;
+}
+
+static int __init_or_module of_do_get_timings(struct device_node *np,
+ struct lpddr2_timings *tim)
+{
+ int ret;
+
+ ret = of_property_read_u32(np, max-freq,
Re: [PATCH] OMAP: clock: fix race in disable all clocks
Hi adding Todd to cc On Thu, 15 Mar 2012, Nishanth Menon wrote: clk_disable_unused is invoked when CONFIG_OMAP_RESET_CLOCKS=y. Since clk_disable_unused is called as lateinitcall, there can be more than a few workqueues executing off secondary CPU(s). The current code does the following: a) checks if clk is unused b) holds lock c) disables clk d) unlocks Between (a) and (b) being executed on CPU0, It is possible to have a driver executing on CPU1 which could do a get_sync-clk_get (and increase the use_count) of the clock which was just about to be disabled by clk_disable_unused. We ensure instead that the entire list traversal is protected by the lock allowing for parent child clock traversal which could be potentially be done by runtime operations to be safe as well. Reported-by: Todd Poynor toddpoy...@google.com Signed-off-by: Nishanth Menon n...@ti.com Thanks, I'll queue this for v3.4-rc1. In the medium term, we should get rid of CONFIG_OMAP_RESET_CLOCKS, at least for the OMAP2+ chips, and just do this by default. But this will need to wait until all of the OMAP2+ devices and drivers have been converted to use hwmod. Patches to that end are also gladly accepted :-) In 3.5 we should be in pretty good shape for OMAP4, but OMAP2/3 will still need some work. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 6/6] ARM: OMAP: fix cpufreq build
On Thu, 15 Mar 2012, Kevin Hilman wrote: Initially, this was intended as a cleanup because it was just dead code removal, but since we missed v3.4, maybe we should pull out ARM: OMAP: clock: cleanup CPUfreq leftovers and submit for 3.4-rc. If it doesn't go upstream for the 3.4 merge window, I'll submit it for 3.4-rc. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] misc: ddr: add LPDDR2 data from JESD209-2
On Thu, Mar 15, 2012 at 11:47:31PM +0530, Aneesh V wrote:
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data will useful for memory controller device drivers
Right now, only one driver, right?
+#ifndef __ASSEMBLY__
Why is this needed?
+/* Structure for DDR addressing info from the JEDEC spec */
+struct lpddr2_addressing {
+ u32 num_banks;
+ u32 tREFI_ns;
+ u32 tRFCab_ps;
+};
Do these structures cross the user/kernel boundry somehow? If so,
please use the proper kernel types for this.
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -123,6 +123,9 @@ obj-$(CONFIG_SIGNATURE) += digsig.o
obj-$(CONFIG_CLZ_TAB) += clz_tab.o
+obj-$(CONFIG_DDR) += jedec_ddr_data.o
+
+
Why the extra line?
hostprogs-y := gen_crc32table
clean-files := crc32table.h
diff --git a/lib/jedec_ddr_data.c b/lib/jedec_ddr_data.c
new file mode 100644
index 000..fc223d6
--- /dev/null
+++ b/lib/jedec_ddr_data.c
@@ -0,0 +1,135 @@
+/*
+ * DDR addressing details and AC timing parameters from JEDEC specs
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Aneesh V ane...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include misc/jedec_ddr.h
+#include linux/module.h
+
+/* LPDDR2 addressing details from JESD209-2 section 2.4 */
+const struct lpddr2_addressing
+ lpddr2_jedec_addressing_table[NUM_DDR_ADDR_TABLE_ENTRIES] = {
+ {B4, T_REFI_15_6, T_RFC_90}, /* 64M */
+ {B4, T_REFI_15_6, T_RFC_90}, /* 128M */
+ {B4, T_REFI_7_8, T_RFC_90}, /* 256M */
+ {B4, T_REFI_7_8, T_RFC_90}, /* 512M */
+ {B8, T_REFI_7_8, T_RFC_130}, /* 1GS4 */
+ {B8, T_REFI_3_9, T_RFC_130}, /* 2GS4 */
+ {B8, T_REFI_3_9, T_RFC_130}, /* 4G */
+ {B8, T_REFI_3_9, T_RFC_210}, /* 8G */
+ {B4, T_REFI_7_8, T_RFC_130}, /* 1GS2 */
+ {B4, T_REFI_3_9, T_RFC_130}, /* 2GS2 */
+};
+EXPORT_SYMBOL(lpddr2_jedec_addressing_table);
EXPORT_SYMBOL_GPL for these and the others?
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] Add TI EMIF SDRAM controller driver
On Thu, Mar 15, 2012 at 11:47:30PM +0530, Aneesh V wrote: Add a driver for the EMIF SDRAM controller used in TI SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up Is this a kernel/user API, or just an in-kernel API? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] misc: ddr: add LPDDR2 data from JESD209-2
On Friday 16 March 2012 12:32 AM, Greg KH wrote:
On Thu, Mar 15, 2012 at 11:47:31PM +0530, Aneesh V wrote:
add LPDDR2 data from the JEDEC spec JESD209-2. The data
includes:
1. Addressing information for LPDDR2 memories of different
densities and types(S2/S4)
2. AC timing data.
This data will useful for memory controller device drivers
Right now, only one driver, right?
Yes, should that be documented?
+#ifndef __ASSEMBLY__
Why is this needed?
IIRC, this header file was getting included in an omap specific header
file that was in turn included from an assembly file. I will check if
this is still the case. If not, I will remove it.
+/* Structure for DDR addressing info from the JEDEC spec */
+struct lpddr2_addressing {
+ u32 num_banks;
+ u32 tREFI_ns;
+ u32 tRFCab_ps;
+};
Do these structures cross the user/kernel boundry somehow? If so,
please use the proper kernel types for this.
No. These structures are meant for use by device drivers.
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -123,6 +123,9 @@ obj-$(CONFIG_SIGNATURE) += digsig.o
obj-$(CONFIG_CLZ_TAB) += clz_tab.o
+obj-$(CONFIG_DDR) += jedec_ddr_data.o
+
+
Why the extra line?
Un-intentional. Will remove.
hostprogs-y := gen_crc32table
clean-files := crc32table.h
diff --git a/lib/jedec_ddr_data.c b/lib/jedec_ddr_data.c
new file mode 100644
index 000..fc223d6
--- /dev/null
+++ b/lib/jedec_ddr_data.c
@@ -0,0 +1,135 @@
+/*
+ * DDR addressing details and AC timing parameters from JEDEC specs
+ *
+ * Copyright (C) 2012 Texas Instruments, Inc.
+ *
+ * Aneesh Vane...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#includemisc/jedec_ddr.h
+#includelinux/module.h
+
+/* LPDDR2 addressing details from JESD209-2 section 2.4 */
+const struct lpddr2_addressing
+ lpddr2_jedec_addressing_table[NUM_DDR_ADDR_TABLE_ENTRIES] = {
+ {B4, T_REFI_15_6, T_RFC_90}, /* 64M */
+ {B4, T_REFI_15_6, T_RFC_90}, /* 128M */
+ {B4, T_REFI_7_8, T_RFC_90}, /* 256M */
+ {B4, T_REFI_7_8, T_RFC_90}, /* 512M */
+ {B8, T_REFI_7_8, T_RFC_130}, /* 1GS4 */
+ {B8, T_REFI_3_9, T_RFC_130}, /* 2GS4 */
+ {B8, T_REFI_3_9, T_RFC_130}, /* 4G */
+ {B8, T_REFI_3_9, T_RFC_210}, /* 8G */
+ {B4, T_REFI_7_8, T_RFC_130}, /* 1GS2 */
+ {B4, T_REFI_3_9, T_RFC_130}, /* 2GS2 */
+};
+EXPORT_SYMBOL(lpddr2_jedec_addressing_table);
EXPORT_SYMBOL_GPL for these and the others?
Will fix all.
Thanks,
Aneesh
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Add generic device tree DMA helpers
On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote: This was done like IRQ on purpose, because an Interrupt ReQuest line and a DMA Request line are really similar for the HW point of view at IP level. I'm not sure about that at all levels. Sure, at hardware level they're the same, but I think the flat numeric namespace for IRQs has been proven to be a problem when there's multiple IRQ controllers in the system. I'm not sure what Thierry have done for pwm, but I thing that having the same scheme for reg, irq and dma was what we agreed with Grant during Plumbers. I really don't like these behind-the-scenes discussions which never then get followed up in public, and people then start quoting what was agreed as that's the way things must be done. It's a bit like folk at the recent Linaro Connect apparantly discussing my machine registry and deciding that it should be shut down. No one has yet talked to me about that or even done the curtesy of asking me what my view is. As far as I'm concerned for DMA stuff, there is currently no real solution for a DT representation; TI have asked me to take over the conversion of OMAP DMA support to the DMA engine API, and I'm not yet convinced that the existing numbering system is the right solution - especially as there's several overlapping numberspaces for OMAP DMA numbers which are SoC specific. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 0/7] Add TI EMIF SDRAM controller driver
On Friday 16 March 2012 12:34 AM, Greg KH wrote: On Thu, Mar 15, 2012 at 11:47:30PM +0530, Aneesh V wrote: Add a driver for the EMIF SDRAM controller used in TI SoCs EMIF is an SDRAM controller that supports, based on its revision, one or more of LPDDR2/DDR2/DDR3 protocols.This driver adds support for LPDDR2. The driver supports the following features: - Calculates the DDR AC timing parameters to be set in EMIF registers using data from the device data-sheets and based on the DDR frequency. If data from data-sheets is not available default timing values from the JEDEC spec are used. These will be safe, but not necessarily optimal - API for changing timings during DVFS or at boot-up Is this a kernel/user API, or just an in-kernel API? That's just an in-kernel API or more precisely callbacks to be registered for DDR frequency change events. thanks, Aneesh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Add generic device tree DMA helpers
On Thursday 15 March 2012, Russell King - ARM Linux wrote: On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote: This was done like IRQ on purpose, because an Interrupt ReQuest line and a DMA Request line are really similar for the HW point of view at IP level. I'm not sure about that at all levels. Sure, at hardware level they're the same, but I think the flat numeric namespace for IRQs has been proven to be a problem when there's multiple IRQ controllers in the system. In the DT bindings, both IRQ and the suggested DMA are not flat number spaces, but instead can be of arbitrarly length defined by the controller. As far as I'm concerned for DMA stuff, there is currently no real solution for a DT representation; TI have asked me to take over the conversion of OMAP DMA support to the DMA engine API, and I'm not yet convinced that the existing numbering system is the right solution - especially as there's several overlapping numberspaces for OMAP DMA numbers which are SoC specific. The numbers definitely need to become local to each of the controllers, but that is the case pretty much automatically using the proposed binding, because each dma request identifier starts with the phandle of the controller. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/10] ARM: OMAP: SmartReflex: Move smartreflex driver to drivers/
On Thursday, March 15, 2012, jean.pi...@newoldbits.com wrote: From: Jean Pihet j-pi...@ti.com After a clean-up of the interfaces the OMAP IP driver and class support code is now a generic driver. Move it to drivers/power/avs/. The build is controlled by the following Kconfig options: . CONFIG_POWER_AVS: general knob for Adaptive Voltage Scaling support, . CONFIG_POWER_AVS_OMAP: AVS support on OMAP containing the version 1 or version 2 of the SmartReflex IP, . CONFIG_POWER_AVS_OMAP_CLASS3: Class 3 implementation of Smartreflex. Signed-off-by: Jean Pihet j-pi...@ti.com --- [...] diff --git a/drivers/power/Makefile b/drivers/power/Makefile index e429008..e4a8fd2 100644 --- a/drivers/power/Makefile +++ b/drivers/power/Makefile @@ -41,3 +41,5 @@ obj-$(CONFIG_CHARGER_GPIO) += gpio-charger.o obj-$(CONFIG_CHARGER_MANAGER)+= charger-manager.o obj-$(CONFIG_CHARGER_MAX8997)+= max8997_charger.o obj-$(CONFIG_CHARGER_MAX8998)+= max8998_charger.o + +obj-$(CONFIG_POWER_AVS) += avs/ diff --git a/drivers/power/avs/Kconfig b/drivers/power/avs/Kconfig new file mode 100644 index 000..35b21c4 --- /dev/null +++ b/drivers/power/avs/Kconfig @@ -0,0 +1,45 @@ +menuconfig POWER_AVS + tristate Adaptive Voltage Scaling class support + help + AVS is a power management technique which finely controls the + operating voltage of a device in order to optimize (i.e. reduce) + its power consumption. + At a given operating point the voltage is adapted depending on + static factors (chip manufacturing process) and dynamic factors + (temperature depending performance). + AVS is also called SmartReflex on OMAP devices. + + Say Y here to enable Adaptive Voltage Scaling class support. + +if POWER_AVS + +config POWER_AVS_OMAP I think it would be better to keep this and the next one in the OMAP arch Kconfig. + bool AVS support for the OMAP IP versions 12 + depends on (ARCH_OMAP3 || ARCH_OMAP4) PM + help + Say Y to enable AVS support on OMAP containing the version 1 or + version 2 of the SmartReflex IP. + V1 is the 65nm version used in OMAP3430. + V2 is the update for the 45nm version of the IP used in OMAP3630 + and OMAP4430 + + Please note, that by default SmartReflex is only + initialized and not enabled. To enable the automatic voltage + compensation for vdd mpu and vdd core from user space, + user must write 1 to + /debug/smartreflex/sr_X/autocomp, + where X is mpu_iva or core for OMAP3. + Optionally autocompensation can be enabled in the kernel + by default during system init via the enable_on_init flag + which an be passed as platform data to the smartreflex driver. + +config POWER_AVS_OMAP_CLASS3 + bool Class 3 mode of Smartreflex Implementation + depends on POWER_AVS_OMAP TWL4030_CORE + help + Say Y to enable Class 3 implementation of Smartreflex + + Class 3 implementation of Smartreflex employs continuous hardware + voltage calibration. + +endif # POWER_AVS Thanks, Rafael -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Add generic device tree DMA helpers
On 3/15/2012 9:41 PM, Arnd Bergmann wrote: On Thursday 15 March 2012, Russell King - ARM Linux wrote: On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote: This was done like IRQ on purpose, because an Interrupt ReQuest line and a DMA Request line are really similar for the HW point of view at IP level. I'm not sure about that at all levels. Sure, at hardware level they're the same, but I think the flat numeric namespace for IRQs has been proven to be a problem when there's multiple IRQ controllers in the system. In the DT bindings, both IRQ and the suggested DMA are not flat number spaces, but instead can be of arbitrarly length defined by the controller. As far as I'm concerned for DMA stuff, there is currently no real solution for a DT representation; TI have asked me to take over the conversion of OMAP DMA support to the DMA engine API, and I'm not yet convinced that the existing numbering system is the right solution - especially as there's several overlapping numberspaces for OMAP DMA numbers which are SoC specific. The numbers definitely need to become local to each of the controllers, but that is the case pretty much automatically using the proposed binding, because each dma request identifier starts with the phandle of the controller. Indeed, and in the case of the OMAP SDMA controller, it can handle up to 127 DMA request lines numbered from 0 to 126... So a local number seems to be a good representation... especially for a number. I'm not sure to understand the issue with this binding. And AFAIK, there is the only one general purpose DMA controller in OMAP so far. The other ones are private to some IPs like MMC or USB, so they do not need necessarily need any DT representation. But anyway, since the controller phandle is mandatory, it will be able to handle even several instances of this DMA controller without any issue. Regards Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] of: Add generic device tree DMA helpers
On Thu, Mar 15, 2012 at 10:39:12PM +0100, Cousson, Benoit wrote: On 3/15/2012 9:41 PM, Arnd Bergmann wrote: On Thursday 15 March 2012, Russell King - ARM Linux wrote: On Thu, Mar 15, 2012 at 05:30:49PM +0100, Cousson, Benoit wrote: This was done like IRQ on purpose, because an Interrupt ReQuest line and a DMA Request line are really similar for the HW point of view at IP level. I'm not sure about that at all levels. Sure, at hardware level they're the same, but I think the flat numeric namespace for IRQs has been proven to be a problem when there's multiple IRQ controllers in the system. In the DT bindings, both IRQ and the suggested DMA are not flat number spaces, but instead can be of arbitrarly length defined by the controller. As far as I'm concerned for DMA stuff, there is currently no real solution for a DT representation; TI have asked me to take over the conversion of OMAP DMA support to the DMA engine API, and I'm not yet convinced that the existing numbering system is the right solution - especially as there's several overlapping numberspaces for OMAP DMA numbers which are SoC specific. The numbers definitely need to become local to each of the controllers, but that is the case pretty much automatically using the proposed binding, because each dma request identifier starts with the phandle of the controller. Indeed, and in the case of the OMAP SDMA controller, it can handle up to 127 DMA request lines numbered from 0 to 126... So a local number seems to be a good representation... especially for a number. I'm not sure to understand the issue with this binding. And AFAIK, there is the only one general purpose DMA controller in OMAP so far. The other ones are private to some IPs like MMC or USB, so they do not need necessarily need any DT representation. But anyway, since the controller phandle is mandatory, it will be able to handle even several instances of this DMA controller without any issue. Thank you both for missing my point. #define OMAP24XX_DMA_SHA1MD5_RX 13 /* S_DMA_12 */ #define OMAP34XX_DMA_SHA2MD5_RX 13 /* S_DMA_12 */ #define OMAP242X_DMA_EXT_DMAREQ214 /* S_DMA_13 */ #define OMAP243X_DMA_EXT_DMAREQ314 /* S_DMA_13 */ #define OMAP242X_DMA_EXT_DMAREQ315 /* S_DMA_14 */ #define OMAP24XX_DMA_SPI3_TX0 15 /* S_DMA_14 */ #define OMAP242X_DMA_EXT_DMAREQ416 /* S_DMA_15 */ #define OMAP24XX_DMA_SPI3_RX0 16 /* S_DMA_15 */ #define OMAP242X_DMA_EAC_BT_DL_RD 25 /* S_DMA_24 */ #define OMAP243X_DMA_EXT_DMAREQ425 /* S_DMA_24 */ #define OMAP34XX_DMA_I2C3_TX25 /* S_DMA_24 */ Notice the overlap between the different SoCs for the same number on the same DMA controller. This shouldn't cause problems when all users are within the SoC specific file, but those EXT ones would probably be platform specific, and so you immediately have a dependence between the platform and the SoC there. That dependence can be completely eliminated by other matching schemes which are supportable via the DMA engine API. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAPDSS: DISPC: Enable predecimation
On Thu, Mar 15, 2012 at 05:18:28PM +0530, Chandrabhanu Mahapatra wrote: In OMAP3 and OMAP4, the DISPC Scaler can downscale an image up to 4 times, and up to 2 times in OMAP2. However, with predecimation, the image can be reduced to 16 times by fetching only the necessary pixels in memory. Then this predecimated image can be downscaled further by the DISPC scaler. Now, where does that number 16 come from? IIRC the hardware can skip basically any number of pixels/rows. I certainly didn't add any such limit to the code in the harmattan kernel, and distinctly remember being able to downscale the N9/N950 UI even down to 1 pixel size :) Based on the downscaling required, a prior calculation of predecimation values for width and height of an image is done. Since, Predecimation reduces quality of an image higher priorty is given to DISPC Scaler for downscaling. This code was successfully tested on OMAP2, OMAP3 and OMAP4. Horizontal and vertical predecimation worked fine except for some synclost errors due to undocumented errata in OMAP3 which are fixed later and skewed images were seen on OMAP2 and OMAP3 during horizontal predecimation which will be addressed in the future patches. All the rotation offset calculations still look suspiciously different to what is in the harmattan kernel. I remember that the original code was quite broken, and I fixed a lot of things when I was implementing pre-decimation and some rotation stuff for the N9/N950. Too bad I never managed to push that stuff upstream... -- Ville Syrjälä syrj...@sci.fi http://www.sci.fi/~syrjala/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
