* [PATCH/RFC] mm: add vm_area_add_early()
From: Nicolas Pitre @ 2011-09-14 18:35 UTC (permalink / raw)
To: linux-arm-kernel
The existing vm_area_register_early() allows for early vmalloc space
allocation. However upcoming cleanups in the ARM architecture require
that some fixed locations in the vmalloc area be reserved also very early.
The name "vm_area_register_early" would have been a good name for the
reservation part without the allocation. Since it is already in use with
different semantics, let's create vm_area_add_early() instead.
Both vm_area_register_early() and vm_area_add_early() can be used together
meaning that the former is now implemented using the later where it is
ensured that no conflicting areas are added, but no attempt is made to
make the allocation scheme in vm_area_register_early() more sophisticated.
After all, you must know what you're doing when using those functions.
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
---
Comments / ACKs appreciated.
diff --git a/include/linux/vmalloc.h b/include/linux/vmalloc.h
index 9332e52ea8..e7d2cba995 100644
--- a/include/linux/vmalloc.h
+++ b/include/linux/vmalloc.h
@@ -130,6 +130,7 @@ extern long vwrite(char *buf, char *addr, unsigned long count);
*/
extern rwlock_t vmlist_lock;
extern struct vm_struct *vmlist;
+extern __init void vm_area_add_early(struct vm_struct *vm);
extern __init void vm_area_register_early(struct vm_struct *vm, size_t align);
#ifdef CONFIG_SMP
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 7ef0903058..bf20a0ff95 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1118,6 +1118,31 @@ void *vm_map_ram(struct page **pages, unsigned int count, int node, pgprot_t pro
EXPORT_SYMBOL(vm_map_ram);
/**
+ * vm_area_add_early - add vmap area early during boot
+ * @vm: vm_struct to add
+ *
+ * This function is used to add fixed kernel vm area to vmlist before
+ * vmalloc_init() is called. @vm->addr, @vm->size, and @vm->flags
+ * should contain proper values and the other fields should be zero.
+ *
+ * DO NOT USE THIS FUNCTION UNLESS YOU KNOW WHAT YOU'RE DOING.
+ */
+void __init vm_area_add_early(struct vm_struct *vm)
+{
+ struct vm_struct *tmp, **p;
+
+ for (p = &vmlist; (tmp = *p) != NULL; p = &tmp->next) {
+ if (tmp->addr >= vm->addr) {
+ BUG_ON(tmp->addr < vm->addr + vm->size);
+ break;
+ } else
+ BUG_ON(tmp->addr + tmp->size > vm->addr);
+ }
+ vm->next = *p;
+ *p = vm;
+}
+
+/**
* vm_area_register_early - register vmap area early during boot
* @vm: vm_struct to register
* @align: requested alignment
@@ -1139,8 +1164,7 @@ void __init vm_area_register_early(struct vm_struct *vm, size_t align)
vm->addr = (void *)addr;
- vm->next = vmlist;
- vmlist = vm;
+ vm_area_add_early(vm);
}
void __init vmalloc_init(void)
^ permalink raw reply related
* [RFC 7/8] drivers: introduce rpmsg, a remote-processor messaging bus
From: Ohad Ben-Cohen @ 2011-09-14 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <BANLkTi=7TBMqnEf2qustrmSaubtTam79Bw@mail.gmail.com>
Hi Rusty,
On Wed, Jun 22, 2011 at 1:46 PM, Ohad Ben-Cohen <ohad@wizery.com> wrote:
> On Wed, Jun 22, 2011 at 5:42 AM, Rusty Russell <rusty@rustcorp.com.au> wrote:
>> On Tue, 21 Jun 2011 10:18:33 +0300, Ohad Ben-Cohen <ohad@wizery.com> wrote:
>>> +#define VIRTIO_ID_RPMSG ? ? ? ? ? ? ?10 /* virtio remote processor messaging */
>>
>> I think you want 6. ?Plan 9 jumped ahead to grab 9 :)
>
> 6 it is :)
Looking at the virtio-spec, it seems that 6 is taken by 'ioMemory'.
There's no indication for it in virtio_ids.h though, and the
virtio-spec has no appendix for this id, so maybe it's available after
all ?
If it is available, I'll take it for rpmsg, and will also update
virtio-spec appropriately. Otherwise, we'll settle on 7 ? :)
Thanks,
Ohad.
^ permalink raw reply
* [PATCH v2] i2c: QUP based bus driver for Qualcomm MSM chipsets
From: Kenneth Heitke @ 2011-09-14 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1308018114-19709-1-git-send-email-kheitke@codeaurora.org>
On 06/13/2011 08:21 PM, Kenneth Heitke wrote:
> This bus driver supports the QUP i2c hardware controller in the Qualcomm
> MSM SOCs. The Qualcomm Universal Peripheral Engine (QUP) is a general
> purpose data path engine with input/output FIFOs and an embedded i2c
> mini-core. The driver supports FIFO mode (for low bandwidth applications)
> and block mode (interrupt generated for each block-size data transfer).
> The driver currently does not support DMA transfers.
>
> Signed-off-by: Kenneth Heitke<kheitke@codeaurora.org>
> ---
> v2: updates to runtime PM calls (addresses comments from Mark Brown).
> Disable interrupts before setting completion object to NULL (bug fix).
> ---
> drivers/i2c/busses/Kconfig | 11 +
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-qup.c | 1175 +++++++++++++++++++++++++++++
> include/linux/platform_data/msm_qup_i2c.h | 24 +
> 4 files changed, 1211 insertions(+), 0 deletions(-)
> create mode 100644 drivers/i2c/busses/i2c-qup.c
> create mode 100644 include/linux/platform_data/msm_qup_i2c.h
>
Hi Ben,
Would it be possible to pull this driver into your tree? If not, please
let me know of any concerns that need to be addresses.
thanks,
Ken
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* [PATCH 5/5] ARM: gic: add OF based initialization
From: Rob Herring @ 2011-09-14 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E70F3C9.2010202@arm.com>
On 09/14/2011 01:34 PM, Marc Zyngier wrote:
> Hi Rob,
>
> On 14/09/11 18:57, Rob Herring wrote:
>> Marc,
>>
>> On 09/14/2011 12:46 PM, Marc Zyngier wrote:
>>> On 14/09/11 17:31, Rob Herring wrote:
>>>> From: Rob Herring <rob.herring@calxeda.com>
>>>>
>>>> This adds gic initialization using device tree data. The initialization
>>>> functions are intended to be called by a generic OF interrupt
>>>> controller parsing function once the right pieces are in place.
>>>>
>>>> PPIs are handled using 3rd cell of interrupts properties to specify the cpu
>>>> mask the PPI is assigned to.
>>>>
>>>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>>>> ---
>>>> Documentation/devicetree/bindings/arm/gic.txt | 53 ++++++++++++++++++++++++
>>>> arch/arm/common/gic.c | 55 +++++++++++++++++++++++--
>>>> arch/arm/include/asm/hardware/gic.h | 10 +++++
>>>> 3 files changed, 114 insertions(+), 4 deletions(-)
>>>> create mode 100644 Documentation/devicetree/bindings/arm/gic.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
>>>> new file mode 100644
>>>> index 0000000..6c513de
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/arm/gic.txt
>>>> @@ -0,0 +1,53 @@
>>>> +* ARM Generic Interrupt Controller
>>>> +
>>>> +ARM SMP cores are often associated with a GIC, providing per processor
>>>> +interrupts (PPI), shared processor interrupts (SPI) and software
>>>> +generated interrupts (SGI).
>>>> +
>>>> +Primary GIC is attached directly to the CPU and typically has PPIs and SGIs.
>>>> +Secondary GICs are cascaded into the upward interrupt controller and do not
>>>> +have PPIs or SGIs.
>>>> +
>>>> +Main node required properties:
>>>> +
>>>> +- compatible : should be one of:
>>>> + "arm,cortex-a9-gic"
>>>> + "arm,arm11mp-gic"
>>>> +- interrupt-controller : Identifies the node as an interrupt controller
>>>> +- #interrupt-cells : Specifies the number of cells needed to encode an
>>>> + interrupt source. The type shall be a <u32> and the value shall be 3.
>>>> +
>>>> + The 1st cell is the interrupt number. 0-15 are reserved for SGIs. 16-31 are
>>>> + for PPIs.
>>>> +
>>>> + The 2nd cell is the level-sense information, encoded as follows:
>>>> + 1 = low-to-high edge triggered
>>>> + 2 = high-to-low edge triggered
>>>> + 4 = active high level-sensitive
>>>> + 8 = active low level-sensitive
>>>> +
>>>> + Only values of 1 and 4 are valid for GIC 1.0 spec.
>>>> +
>>>> + The 3rd cell contains the mask of the cpu number for the interrupt source.
>>>> + The cpu mask is only valid for PPIs and shall be 0 for SPIs. This value shall
>>>> + be 0 for PPIs.
>>> ^^^^^^^^^^^^^
>>>
>>> Typo here ? The way I understand it, it should read "For PPIs, this
>>> value shall be the mask of the possible CPU numbers for the interrupt
>>> source" (or something to similar effect...).
>>>
>>
>> Cut and paste error. This sentence goes in the previous paragraph. What
>> I meant is the 2nd cell should contain 0 for PPIs as you cannot set the
>> edge/level on PPIs (that is always true, right?). I probably should also
>> add 0 in the list of values.
>
> Ah, right. It makes sense indeed. You're correct about PPIs polarity,
> this is defined by the hardware and cannot be configured. But it may be
> interesting to have the DT to reflect the way the hardware is actually
> configured (on the Cortex-A9, some PPIs are configured active-low, and
> others are rising-edge).
So we should allow specifying what it is as the OS may need to know that.
>
>> I take it you are otherwise fine with this binding?
>
> I very much like the fact that it (or at least that's the way I
> understand it...) allows for a very compact expression of peripherals
> connected to PPIs.
>
> What I'd like to write is the following:
>
> twd at 1f000600 {
> compatible = "arm,11mpcore-twd";
> reg = <0x1f000600 0x100>;
> interrupt-parent = <&intc>;
> interrupt = <29 0 0xf>;
> }
>
> where 0xf would indicate that the TWD is connected to all four cores. Is
> that correct?
>
Yes, that's exactly why I did a mask and is what I have for twd on
highbank. Also, I specified SPIs as 0 specifically so no one gets the
idea to use the mask to set the affinity.
Rob
^ permalink raw reply
* [PATCH 13/25] OMAP4: PM: Add WakeupGen module as OMAP gic_arch_extn
From: Tony Lindgren @ 2011-09-14 19:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E70E2DE.2030006@ti.com>
* Santosh <santosh.shilimkar@ti.com> [110914 09:49]:
> On Wednesday 14 September 2011 10:48 PM, Tony Lindgren wrote:
> >* Santosh<santosh.shilimkar@ti.com> [110914 09:40]:
> >>On Wednesday 14 September 2011 10:38 PM, Tony Lindgren wrote:
> >>>* Santosh<santosh.shilimkar@ti.com> [110914 09:16]:
> >>>
> >>>Thanks for the clarification. It seems to me the spec is most likely
> >>>wrong as we've had the GIC working for over two years now without
> >>>doing anything with the wakeup gen registers :)
> >>>
> >>It's working because CPU clockdomain are never put under HW
> >>supervised mode and they are kept in force wakeup. Clock-domain
> >>never idles on mainline code. PM series will put the clock-domains
> >>under HW supervison as needed to achieve any low power states and
> >>then all sorts of corner cases will come out.
> >
> >But again the wakeup gen triggers only do something when hitting
> >idle. There should be no use for them during runtime, right?
> >
> You missed my point in the description. Clockdomain inactive
> doesn't depend on idle or WFI execution. Under HW supervison
> CPU clock domain can get into inactive when CPU is stalled and
> waiting for a read response from slow interconnect.
Ah OK. If it's needed during runtime too then that explains why
the registers need to be kept in sync.
> One thing for sure. Designers has chosen a wrong name to this
> IP. Wakeugen apears like needed only for low power wakeup which
> not seems to be entirely correct as per specs
Yes it's not obvious reading the TRM either. Maybe add some
comment about that to the patch?
Regards,
Tony
^ permalink raw reply
* [PATCH v2 1/2] ARM: cache-l2x0: remove __init annotation from initialization functions
From: Russell King - ARM Linux @ 2011-09-14 19:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E706BA2.5060804@ti.com>
On Wed, Sep 14, 2011 at 02:23:54PM +0530, Santosh wrote:
> As mentioned earlier, you need to save only once since non of the L2
> configuration values will change. So 'save ones' and 'restore always
> when context lost' should be the right way to go about it.
Might as well arrange for the save to be at initialization time -
there's no point saving the configuration at every suspend.
^ permalink raw reply
* [PATCH v2 0/2] make reinitialization of ARM core components possible
From: Russell King - ARM Linux @ 2011-09-14 19:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110912054140.GE1258@S2100-06.ap.freescale.net>
On Mon, Sep 12, 2011 at 01:41:41PM +0800, Shawn Guo wrote:
> OMAP and IMX6Q retains L2 cache, we have to go save/restore approach
> to work with generic cpu_suspend/resume routines. But for platforms
> that will power off L2 during suspend, I think re-init is the easiest
> way for them get L2 back to work.
It would be much better to re-init with the same configuration values
used during the initial init - rather than using the mask + values
method which preserves whatever the boot loader gave us.
We know with quite a bit of experience that we can't rely on boot loaders
setting things up in the same way on initial boot and resume, so we should
not rely on the boot loader setting the same L2 configuration on resume
as was set during boot.
^ permalink raw reply
* [PATCH 2/2] input: samsung-keypad: Add device tree support
From: Grant Likely @ 2011-09-14 19:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJuYYwRP2DGge1aHz-CWMnUrdz686s6X5Fp=LvRkM35VQS1XYw@mail.gmail.com>
On Wed, Sep 14, 2011 at 12:09 PM, Thomas Abraham
<thomas.abraham@linaro.org> wrote:
> On 14 September 2011 22:43, Grant Likely <grant.likely@secretlab.ca> wrote:
>> On Wed, Sep 14, 2011 at 10:19:22PM +0530, Thomas Abraham wrote:
>>> On 14 September 2011 21:41, Grant Likely <grant.likely@secretlab.ca> wrote:
>>> > On Tue, Sep 13, 2011 at 05:56:19PM +0530, Thomas Abraham wrote:
>>> >> +- Keys represented as child nodes: Each key connected to the keypad
>>> >> + ?controller is represented as a child node to the keypad controller
>>> >> + ?device node and should include the following properties.
>>> >> + ?- keypad,row: the row number to which the key is connected.
>>> >> + ?- keypad,column: the column number to which the key is connected.
>>> >> + ?- keypad,key-code: the key-code to be reported when the key is pressed
>>> >> + ? ?and released.
>>> >
>>> > What defines the meanings of the key codes?
>>>
>>> The key-code could be any value which the system would want the keypad
>>> driver to report when that key is pressed.
>>
>> Are they linux keycodes? ?If so, then this property name can
>> probably be linux,code. ?There is already precedence for that
>> usage in Documentation/devicetree/bindings/gpio/gpio-keys.txt. ?(I
>> would personally prefer "linux,key-code", but sometimes it is better
>> to go with existing precidence) You could also use linux,input-type as
>> specified in that binding.
>
> Ok. For linux, "keypad,key-code" would mean linux keycodes. The
> property name 'keypad,key-code' was chosen since it can be reused on
> non-linux platforms as well. I did have a look at
> Documentation/devicetree/bindings/gpio/gpio-keys.txt while doing this,
> but preferred using 'keypad,key-code' since it would be generic. Given
> a choice, I would like to retain this.
This was debated a bit on the gpio-keys binding. The binding *must*
specify where it is getting the keycodes from. For the gpio-keys
binding, it was decided that the Linux keycodes were sufficient since
they are exported to userspace, and therefore part of the stable
kernel ABI (they will never change). "keypad,key-code" is completely
useless as a generic binding since it doesn't specify where the
keycode meanings come from. Besides, "linux,code" can be reused on
non-linux platforms too, it just means that the authoritative source
of the keycodes is the Linux kernel.
g
^ permalink raw reply
* [PATCH v4] power: bq20z75: devicetree init support
From: Grant Likely @ 2011-09-14 19:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1316023462-3287-1-git-send-email-rklein@nvidia.com>
On Wed, Sep 14, 2011 at 12:04 PM, Rhyland Klein <rklein@nvidia.com> wrote:
> Adding support to generate platform data when kernel is configured
> through device tree.
>
> Also adding the binding for the TI bq20z75 fuel gadge and the
> bq20z75 driver.
>
> Signed-off-by: Rhyland Klein <rklein@nvidia.com>
> ---
> ? ? ? ?v2: Fixed typo in binding description
> ? ? ? ?v3: Changed to use "ti," for properties
> ? ? ? ? ? ?Changed to use single gpio entry for battery detect info.
> ? ? ? ? ? ?Removed unnecessary call to of_match_device.
> ? ? ? ?v4: squashed bindings and drivers changes together.
> ? ? ? ? ? ?fixed case where CONFIG_OF is not selected, to return existing
> ? ? ? ? ? ?pdata pointer if it exists.
Nit: Personally, I'm much happier when the revision list is above the
--- line so it appears in the linux commit text. That helps when
trying to figure out exactly which posting of a patch got merged.
>
> diff --git a/drivers/power/bq20z75.c b/drivers/power/bq20z75.c
> index 9c5e5be..4c4669e 100644
> --- a/drivers/power/bq20z75.c
> +++ b/drivers/power/bq20z75.c
> @@ -613,6 +613,78 @@ static void bq20z75_delayed_work(struct work_struct *work)
> ? ? ? ?}
> ?}
>
> +#if defined(CONFIG_OF)
> +#include <linux/of_device.h>
> +static const struct of_device_id bq20z75_dt_ids[] = {
> + ? ? ? { .compatible = "ti,bq20z75" },
> + ? ? ? { }
> +};
> +MODULE_DEVICE_TABLE(platform, bq20z75_dt_ids);
MODULE_DEVICE_TABLE(of, ...)
It's not a platform_device_id table.
Otherwise:
Acked-by: Grant Likely <grant.likely@secretlab.ca>
^ permalink raw reply
* [PATCH v5] power: bq20z75: devicetree init support
From: Rhyland Klein @ 2011-09-14 20:19 UTC (permalink / raw)
To: linux-arm-kernel
Adding support to generate platform data when kernel is configured
through device tree.
Also adding the binding for the TI bq20z75 fuel gadge and the
bq20z75 driver.
v2: Fixed typo in binding description.
v3: Changed to use "ti," properties
Changed to use single gpio property for battery detect info
Removed unnecessary call to of_match_device
v4: Squashed Binding and driver changes together.
Fixed case where CONFIG_OF is not selected, return existing pdata pointer
v5: Fixed MODULE_DEVICE_TABLE to be i2c instead of platform
Acked-by: Grant Likely <grant.likely@secretlab.ca>
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
---
.../bindings/power_supply/ti_bq20z75.txt | 23 ++++++
drivers/power/bq20z75.c | 75 ++++++++++++++++++++
2 files changed, 98 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/power_supply/ti_bq20z75.txt
diff --git a/Documentation/devicetree/bindings/power_supply/ti_bq20z75.txt b/Documentation/devicetree/bindings/power_supply/ti_bq20z75.txt
new file mode 100644
index 0000000..7571294
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ti_bq20z75.txt
@@ -0,0 +1,23 @@
+TI bq20z75
+~~~~~~~~~~
+
+Required properties :
+ - compatible : "ti,bq20z75"
+
+Optional properties :
+ - ti,i2c-retry-count : The number of times to retry i2c transactions on i2c
+ IO failure.
+ - ti,poll-retry-count : The number of times to try looking for new status
+ after an external change notification.
+ - ti,battery-detect-gpios : The gpio which signals battery detection and
+ a flag specifying its polarity.
+
+Example:
+
+ bq20z75 at b {
+ compatible = "ti,bq20z75";
+ reg = < 0xb >;
+ ti,i2c-retry-count = <2>;
+ ti,poll-retry-count = <10>;
+ ti,battery-detect-gpios = <&gpio-controller 122 1>;
+ }
diff --git a/drivers/power/bq20z75.c b/drivers/power/bq20z75.c
index 9c5e5be..4014a2c 100644
--- a/drivers/power/bq20z75.c
+++ b/drivers/power/bq20z75.c
@@ -613,6 +613,78 @@ static void bq20z75_delayed_work(struct work_struct *work)
}
}
+#if defined(CONFIG_OF)
+#include <linux/of_device.h>
+static const struct of_device_id bq20z75_dt_ids[] = {
+ { .compatible = "ti,bq20z75" },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, bq20z75_dt_ids);
+
+static struct bq20z75_platform_data *bq20z75_of_populate_pdata(
+ struct i2c_client *client)
+{
+ const struct of_device_id *dtid;
+ struct device_node *of_node = client->dev.of_node;
+ struct bq20z75_platform_data *pdata = client->dev.platform_data;
+ enum of_gpio_flags gpio_flags;
+ int rc;
+ u32 prop;
+
+ /* verify this driver matches this device */
+ if (!of_node)
+ return NULL;
+
+ /* if platform data is set, honor it */
+ if (pdata)
+ return pdata;
+
+ /* first make sure at least one property is set, otherwise
+ * it won't change behavior from running without pdata.
+ */
+ if (!of_get_property(of_node, "ti,i2c-retry-count", NULL) &&
+ !of_get_property(of_node, "ti,poll-retry-count", NULL) &&
+ !of_get_property(of_node, "ti,battery-detect-gpios", NULL))
+ goto of_out;
+
+ pdata = devm_kzalloc(&client->dev, sizeof(struct bq20z75_platform_data),
+ GFP_KERNEL);
+ if (!pdata)
+ goto of_out;
+
+ rc = of_property_read_u32(of_node, "ti,i2c-retry-count", &prop);
+ if (!rc)
+ pdata->i2c_retry_count = prop;
+
+ rc = of_property_read_u32(of_node, "ti,poll-retry-count", &prop);
+ if (!rc)
+ pdata->poll_retry_count = prop;
+
+ if (!of_get_property(of_node, "ti,battery-detect-gpios", NULL)) {
+ pdata->battery_detect = -1;
+ goto of_out;
+ }
+
+ pdata->battery_detect = of_get_named_gpio_flags(of_node,
+ "ti,battery-detect-gpios", 0, &gpio_flags);
+
+ if (gpio_flags & OF_GPIO_ACTIVE_LOW)
+ pdata->battery_detect_present = 0;
+ else
+ pdata->battery_detect_present = 1;
+
+of_out:
+ return pdata;
+}
+#else
+#define bq20z75_dt_ids NULL
+static struct bq20z75_platform_data *bq20z75_of_populate_pdata(
+ struct i2c_client *client)
+{
+ return client->dev.platform_data;
+}
+#endif
+
static int __devinit bq20z75_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
@@ -642,6 +714,8 @@ static int __devinit bq20z75_probe(struct i2c_client *client,
bq20z75_device->power_supply.external_power_changed =
bq20z75_external_power_changed;
+ pdata = bq20z75_of_populate_pdata(client);
+
if (pdata) {
bq20z75_device->gpio_detect =
gpio_is_valid(pdata->battery_detect);
@@ -775,6 +849,7 @@ static struct i2c_driver bq20z75_battery_driver = {
.id_table = bq20z75_id,
.driver = {
.name = "bq20z75-battery",
+ .of_match_table = bq20z75_dt_ids,
},
};
--
1.7.6
^ permalink raw reply related
* [PATCH v3 0/2] Add device tree support for Samsung's I2C driver
From: Ben Dooks @ 2011-09-14 21:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315887365-30532-1-git-send-email-thomas.abraham@linaro.org>
On Tue, Sep 13, 2011 at 09:46:03AM +0530, Thomas Abraham wrote:
> This patchset adds device tree support for Samsung's I2C driver.
I've applied these after a brief review. I'll give them a better
review before the weekend.
^ permalink raw reply
* [PATCH V4 RESEND 1/6] video: s3c-fb: Add S5P64X0 specific s3c_fb_driverdata
From: Florian Tobias Schandinat @ 2011-09-14 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315591251-17071-1-git-send-email-ajaykumar.rs@samsung.com>
On 09/09/2011 06:00 PM, Ajay Kumar wrote:
> This patch:
> -- Adds s3c_fb_driverdata for S5P64X0, which supports 3 windows.
> -- Also, register "s5p64x0-fb" type driver_data.
>
> Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
> Acked-by: Jingoo Han <jg1.han@samsung.com>
> Acked-by: Kukjin Kim <kgene.kim@samsung.com>
Applied.
Thanks,
Florian Tobias Schandinat
> ---
> drivers/video/s3c-fb.c | 27 +++++++++++++++++++++++++++
> 1 files changed, 27 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/video/s3c-fb.c b/drivers/video/s3c-fb.c
> index 4aecf21..0fda252 100644
> --- a/drivers/video/s3c-fb.c
> +++ b/drivers/video/s3c-fb.c
> @@ -1859,6 +1859,30 @@ static struct s3c_fb_driverdata s3c_fb_data_s3c2443 = {
> },
> };
>
> +static struct s3c_fb_driverdata s3c_fb_data_s5p64x0 = {
> + .variant = {
> + .nr_windows = 3,
> + .vidtcon = VIDTCON0,
> + .wincon = WINCON(0),
> + .winmap = WINxMAP(0),
> + .keycon = WKEYCON,
> + .osd = VIDOSD_BASE,
> + .osd_stride = 16,
> + .buf_start = VIDW_BUF_START(0),
> + .buf_size = VIDW_BUF_SIZE(0),
> + .buf_end = VIDW_BUF_END(0),
> +
> + .palette = {
> + [0] = 0x2400,
> + [1] = 0x2800,
> + [2] = 0x2c00,
> + },
> + },
> + .win[0] = &s3c_fb_data_s5p_wins[0],
> + .win[1] = &s3c_fb_data_s5p_wins[1],
> + .win[2] = &s3c_fb_data_s5p_wins[2],
> +};
> +
> static struct platform_device_id s3c_fb_driver_ids[] = {
> {
> .name = "s3c-fb",
> @@ -1872,6 +1896,9 @@ static struct platform_device_id s3c_fb_driver_ids[] = {
> }, {
> .name = "s3c2443-fb",
> .driver_data = (unsigned long)&s3c_fb_data_s3c2443,
> + }, {
> + .name = "s5p64x0-fb",
> + .driver_data = (unsigned long)&s3c_fb_data_s5p64x0,
> },
> {},
> };
^ permalink raw reply
* [PATCH] ARM: EXYNOS4: Enable double linefill in PL310 Prefetch Control Register
From: Siarhei Siamashka @ 2011-09-14 21:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <007501cc72d0$b0778a50$11669ef0$%kim@samsung.com>
On Wed, Sep 14, 2011 at 2:23 PM, Kukjin Kim <kgene.kim@samsung.com> wrote:
> Siarhei Siamashka wrote:
>> By the way, does anybody have L2C-310 errata list? Is double linefill
>> actually safe to use in r3p0?
>>
> No. it is _not_ safe on EXYNOS4210.
>
> Since L2C-310 ERRTA, current EXYNOS4210 cannot enable double linefill feature
Thanks for this information. It's a pity, because double linefill
could provide a really serious memory performance boost. Looks like we
have to wait for EXYNOS4212 and/or OMAP4460 to really see how
Cortex-A9 is actually supposed to perform on memory intensive tasks.
However I really appreciate that with EXYNOS4210 you are not shoving
some hardcoded configuration down our throats and not restricting
access to the relevant Cortex-A9 and L2C-310 configuration registers.
So it is still possible to temporarily enable double linefill and use
origenboard for benchmarking purposes to estimate how EXYNOS4212 is
going to perform when it becomes available.
> and as Siarhei said, need to check its version of L2C-310 in Cache ID register before enabling it.
If EXYNOS4212 has a bugfree double linefill support, then enabling it
based on checking L2C-310 revision looks like a good idea.
> As a note, it's possible to enable it on EXYNOS4212 SoC and in opposite of Siarhei's patch, enabling WRAP read is better on it. Actually my colleague, Boojin Kim is testing it so that can submit it soon.
If you have some benchmark results with all these options, they would
be very interesting for me.
As for the general memory performance tuning, there are more things to
try (carefully watching for possible errata):
- SCU Speculative linefills enable bit in SCU Control Register as
described in http://infocenter.arm.com/help/topic/com.arm.doc.ddi0407f/BABEBFBH.html
(this seems to be a good tweak and it really reduces L2 access latency
a bit in my tests)
- Exclusive cache configuration (should increase effective L1/L2 cache
size, but seems to make L2 cache access latency worse in my tests)
- Tune L2C-310 Prefetch offset (without double linefill, the value 6
or even 5 seems to be a bit better than 7)
- 'Alloc in one way', 'Write full line of zeros mode' and maybe something else
Thank you for your replies and the interest in this subject.
--
Best regards,
Siarhei Siamashka
^ permalink raw reply
* [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver
From: Tony Lindgren @ 2011-09-14 21:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1315516098-29761-7-git-send-email-tarun.kanti@ti.com>
Hi,
* Tarun Kanti DebBarma <tarun.kanti@ti.com> [110908 13:36]:
> Register timer devices by going through hwmod database using
> hwmod API. The driver probes each of the registered devices.
> Functionality which are already performed by hwmod framework
> are removed from timer code. New set of timers present on
> OMAP4 are now supported.
Adding the support for the different offsets on some omap4
timers should be a separate patch.
Also, as we don't need the support for different register offsets
for the first two omap4 timers, please rather implement support
for the new timers and the timeouts directly in plat-omap/dmtimer.c.
That way we can still keep the minimal timer support simple
for clocksource and clockevent. Of course this means that we'll
be only supporting the first two timers as system timers on
omap4, but that's fine.
> static inline u32 __omap_dm_timer_read(void __iomem *base, u32 reg,
> - int posted)
> + int posted, u8 func_offset)
> {
> if (posted)
> - while (__raw_readl(base + (OMAP_TIMER_WRITE_PEND_REG & 0xff))
> + while (__raw_readl(base +
> + ((OMAP_TIMER_WRITE_PEND_REG + func_offset) & 0xff))
> & (reg >> WPSHIFT))
> cpu_relax();
>
> @@ -264,10 +263,11 @@ static inline u32 __omap_dm_timer_read(void __iomem *base, u32 reg,
> }
>
> static inline void __omap_dm_timer_write(void __iomem *base, u32 reg, u32 val,
> - int posted)
> + int posted, u8 func_offset)
> {
> if (posted)
> - while (__raw_readl(base + (OMAP_TIMER_WRITE_PEND_REG & 0xff))
> + while (__raw_readl(base +
> + ((OMAP_TIMER_WRITE_PEND_REG + func_offset) & 0xff))
> & (reg >> WPSHIFT))
> cpu_relax();
Otherwise our inline functions just get too messed up with these func_offset
hacks. These need to be minimal as they're being called contantly for the
system timers. We can still recycle the inline functions if we pass the
correct WRITE_PEND_REG to them instead of the func_offset.
Regards,
Tony
^ permalink raw reply
* [PATCH v4] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
From: Rob Clark @ 2011-09-14 21:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4E705E4D.5030206@shipmail.org>
On Wed, Sep 14, 2011 at 2:57 AM, Thomas Hellstrom <thomas@shipmail.org> wrote:
>>>>>>>>>
>>>>>>>>> +static struct drm_ioctl_desc samsung_ioctls[] = {
>>>>>>>>> + ? ? ? DRM_IOCTL_DEF_DRV(SAMSUNG_GEM_CREATE,
>>>>>>>>> samsung_drm_gem_create_ioctl,
>>>>>>>>> + ? ? ? ? ? ? ? ? ? ? ? DRM_UNLOCKED | DRM_AUTH),
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hi!
>>>>>>>>
>>>>>>>> With reference my previous security comment.
>>>>>>>>
>>>>>>>> Let's say you have a compromised video player running as a DRM
>>>>>>>> client, that
>>>>>>>> tries to repeatedly allocate huge GEM buffers...
>>>>>>>>
>>>>>>>> What will happen when all DMA memory is exhausted? Will this cause
>>>>>>>> other
>>>>>>>> device drivers to see an OOM, or only DRM?
>>>>>>>>
>>>>>>>> The old DRI model basically allowed any authorized DRI client to
>>>>>>>> exhaust
>>>>>>>> video ram or AGP memory, but never system memory. Newer DRI drivers
>>>>>>>> typically only allow DRI masters to do that.
>>>>>>>> as
>>>>>>>>
>>>>>>>> I don't think an authorized DRI client should be able to easily
>>>>>>>>
>>>>>
>>>>> exhaust
>>>>>
>>>>>>>>
>>>>>>>> resources (DMA memory) used by other device drivers causing them to
>>>>>>>> fail.
>>>>>>>>
>>>>>>>
>>>>>>> I'm not entirely sure what else can be done, other than have a
>>>>>>> threshold on max MB allocatable of buffer memory..
>>>>>>>
>>>>>>
>>>>>> Yes, I think that's what needs to be done, and that threshold should
>>>>>> be low enough to keep other device drivers running in the worst
>>>>>> allocation case.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> In the samsung driver case, he is only allocating scanout memory
>>>>>>>
>>>
>>> from
>>>
>>>>>>>
>>>>>>> CMA, so the limit will be the CMA region size.. beyond that you
>>>>>>>
>>>
>>> can't
>>>
>>>>>>>
>>>>>>> get physically contiguous memory. ?So I think this driver is safe.
>>>>>>>
>>>>>>
>>>>>> It's not really what well-behaved user-space drivers do that should
>>>>>>
>>>
>>> be
>>>
>>>>>>
>>>>>> a concern, but what compromized application *might* do that is a
>>>>>>
>>>>
>>>> concern.
>>>>
>>>>>
>>>>> Hmm. I might have missed your point here. If the buffer allocation
>>>>>
>>>
>>> ioctl
>>>
>>>>>
>>>>> only allows allocating CMA memory, then I agree the driver fits the old
>>>>> DRI security model, as long as no other devices on the platform will
>>>>> ever use CMA.
>>>>>
>>>>> But in that case, there really should be a way for the driver to say
>>>>> "Hey, all CMA memory on this system is mine", in the same way
>>>>> traditional video drivers can claim the VRAM PCI resource.
>>>>>
>>>>>
>>>>
>>>> CMA could reserve memory region for a specific driver so DRM Client
>>>>
>>>
>>> could
>>>
>>>>
>>>> request memory allocation from only the region.
>>>>
>>>>
>>>>>
>>>>> This is to avoid the possibility that future drivers that need CMA will
>>>>> be vulnerable to DOS-attacks from ill-behaved DRI clients.
>>>>>
>>>>>
>>>>
>>>> Thomas, if any application has root authority for ill-purpose then isn't
>>>>
>>>
>>> it
>>>
>>>>
>>>> possible to be vulnerable to DOS-attacks? I think DRM_AUTH means root
>>>> authority. I know DRM Framework gives any root application DRM_AUTH
>>>> authority for compatibility.
>>>>
>>>
>>> DRM_AUTH just means that the client has authenticated w/ X11 (meaning
>>> that it has permission to connect to x server)..
>>>
>>>
>>
>> Yes, I understood so. but see drm_open_helper() of drm_fops.c file please.
>> in this function, you can see a line below.
>> /* for compatibility root is always authenticated */
>> priv->authenticated = capable(CAP_SYS_ADMIN)
>>
>> I think the code above says that any application with root permission is
>> authenticated.
>>
>>
>
> Yes, that is true. A root client may be assumed to have AUTH permissions,
> but the inverse does not hold, meaning that an AUTH client may *not* be
> assumed to have root permissions. I think there is a ROOT_ONLY ioctl flag
> for that.
>
> The problem I'm seeing compared to other drivers is the following:
>
> Imagine for example that you have a disc driver that allocates temporary
> memory out of the same DMA pool as the DRM driver.
>
> Now you have a video player that is a DRM client. It contains a security
> flaw and is compromized by somebody trying to play a specially crafted video
> stream. The video player starts to allocate gem buffers until it receives an
> -ENOMEM. Then it stops allocating and does nothing.
>
> Now the system tries an important disc access (paging for example). This
> fails, because the video player has exhausted all DMA memory and the disc
> driver fails to allocate.
>
> The system is dead.
>
> The point is:
>
> If there is a chance that other drivers will use the same DMA/CMA pool as
> the DRM driver, DRM must leave enough DMA/CMA memory for those drivers to
> work.
ah, ok, I get your point
> The difference compared to other drm drivers:
>
> There are other drm drivers that work the same way, with a static allocator.
> For example "via" and "sis". But those drivers completely claim the
> resources they are using. Nobody else is expected to use VRAM / AGP.
>
> In the Samsung case, it's not clear to me whether the DMA/CMA pool *can* be
> shared with other devices.
> If it is, IMHO you must implement an allocation limit in DRM, if not, the
> driver should probably be safe.
It is possible to create a device private CMA pool.. although OTOH it
might be desirable to let some other drivers (like v4l2) use buffers
from the same pool..
I'm not entirely sure what will happen w/ dma_alloc_coherent, etc, if
the global CMA pool is exhausted.
Marek? I guess you know what would happen?
BR,
-R
> Thanks,
> Thomas
^ permalink raw reply
* [PATCH v3 0/6] OMAP2+: id: cleanup for 3.2
From: Paul Walmsley @ 2011-09-14 21:58 UTC (permalink / raw)
To: linux-arm-kernel
Clean up the SoC detection code for some OMAP3 devices. The main goal
is to make the AM3517 family detection code work like the rest of the
OMAP3 SoCs, although this series does some other cleanup of this code
at the same time. This patch series will be a prerequisite for the
OMAP_CHIP removal series.
Tested locally on an OMAP3530ES2 BeagleBoard C2 and a OMAP3730ES1
BeagleBoard A2. These are the only OMAP3 boards I have access to
right now - testing welcomed from people with other OMAP3 families or
ES levels. Thanks to Igor Grinberg <grinberg@compulab.co.il> and
Abhilash Koyamangalath <abhilash.kv@ti.com> for their help testing
these patches on AM3517 boards.
This third version fixes another 3517/3505 bug in the first patch.
- Paul
---
id_3517_cleanup_3.2
text data bss dec hex filename
6330180 656956 5591124 12578260 bfedd4 vmlinux.omap2plus_defconfig.orig
6329924 656956 5591124 12578004 bfecd4 vmlinux.omap2plus_defconfig.patched
Paul Walmsley (6):
OMAP3: id: remove identification codes that only correspond to marketing names
OMAP3: id: remove useless strcpy()s
OMAP3: id: use explicit omap_revision codes for 3505/3517 ES levels
OMAP3: id: add fallthrough warning; fix some CodingStyle issues
OMAP3: id: remove duplicate code for testing SoC ES level
OMAP2+: id: remove OMAP_REVBITS_* macros
arch/arm/mach-omap2/clock3xxx_data.c | 11 ++-
arch/arm/mach-omap2/id.c | 136 ++++++++++++---------------------
arch/arm/plat-omap/include/plat/cpu.h | 46 ++++-------
3 files changed, 76 insertions(+), 117 deletions(-)
^ permalink raw reply
* [PATCH v3 1/6] OMAP3: id: remove identification codes that only correspond to marketing names
From: Paul Walmsley @ 2011-09-14 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914215512.4790.34446.stgit@dusk>
The OMAP3505/AM3505 appears to be based on the same silicon as the
OMAP3517/AM3517, with some features disabled via eFuse bits. Follow
the same practice as OMAP3430 and identify these devices internally as
part of the OMAP3517/AM3517 family.
The OMAP3503/3515/3525/3530 chips appear to be based on the same silicon
as the OMAP3430, with some features disabled via eFuse bits. Identify
these devices internally as part of the OMAP3430 family.
Remove the old OMAP35XX_CLASS, which actually covered two very different
chip families. The OMAP3503/3515/3525/3530 chips will now be covered by
OMAP343X_CLASS, since the silicon appears to be identical. For the
OMAP3517/AM3517 family, create a new class, OMAP3517_CLASS.
Thanks to Tony Lindgren <tony@atomide.com> for some help with the second
revision of this patch.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
---
arch/arm/mach-omap2/clock3xxx_data.c | 11 ++++++++++-
arch/arm/mach-omap2/id.c | 19 +++++++------------
arch/arm/plat-omap/include/plat/cpu.h | 14 +++++---------
3 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c b/arch/arm/mach-omap2/clock3xxx_data.c
index b9b8446..dadb8c6 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3472,7 +3472,16 @@ int __init omap3xxx_clk_init(void)
struct omap_clk *c;
u32 cpu_clkflg = 0;
- if (cpu_is_omap3517()) {
+ /*
+ * 3505 must be tested before 3517, since 3517 returns true
+ * for both AM3517 chips and AM3517 family chips, which
+ * includes 3505. Unfortunately there's no obvious family
+ * test for 3517/3505 :-(
+ */
+ if (cpu_is_omap3505()) {
+ cpu_mask = RATE_IN_34XX;
+ cpu_clkflg = CK_3505;
+ } else if (cpu_is_omap3517()) {
cpu_mask = RATE_IN_34XX;
cpu_clkflg = CK_3517;
} else if (cpu_is_omap3505()) {
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 37efb86..3f3f998 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -304,14 +304,15 @@ static void __init omap3_check_revision(void)
}
break;
case 0xb868:
- /* Handle OMAP35xx/AM35xx devices
+ /*
+ * Handle OMAP/AM 3505/3517 devices
*
- * Set the device to be OMAP3505 here. Actual device
+ * Set the device to be OMAP3517 here. Actual device
* is identified later based on the features.
*
* REVISIT: AM3505/AM3517 should have their own CHIP_IS
*/
- omap_revision = OMAP3505_REV(rev);
+ omap_revision = OMAP3517_REV(rev);
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
break;
case 0xb891:
@@ -438,30 +439,24 @@ static void __init omap3_cpuinfo(void)
*/
if (cpu_is_omap3630()) {
strcpy(cpu_name, "OMAP3630");
- } else if (cpu_is_omap3505()) {
+ } else if (cpu_is_omap3517()) {
/*
* AM35xx devices
*/
- if (omap3_has_sgx()) {
- omap_revision = OMAP3517_REV(rev);
+ if (omap3_has_sgx())
strcpy(cpu_name, "AM3517");
- } else {
- /* Already set in omap3_check_revision() */
+ else
strcpy(cpu_name, "AM3505");
- }
} else if (cpu_is_ti816x()) {
strcpy(cpu_name, "TI816X");
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
strcpy(cpu_name, "OMAP3430/3530");
} else if (omap3_has_iva()) {
- omap_revision = OMAP3525_REV(rev);
strcpy(cpu_name, "OMAP3525");
} else if (omap3_has_sgx()) {
- omap_revision = OMAP3515_REV(rev);
strcpy(cpu_name, "OMAP3515");
} else {
- omap_revision = OMAP3503_REV(rev);
strcpy(cpu_name, "OMAP3503");
}
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 67b3d75..34df171 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -262,7 +262,7 @@ IS_OMAP_TYPE(2422, 0x2422)
IS_OMAP_TYPE(2423, 0x2423)
IS_OMAP_TYPE(2430, 0x2430)
IS_OMAP_TYPE(3430, 0x3430)
-IS_OMAP_TYPE(3505, 0x3505)
+IS_OMAP_TYPE(3505, 0x3517)
IS_OMAP_TYPE(3517, 0x3517)
#define cpu_is_omap310() 0
@@ -354,8 +354,9 @@ IS_OMAP_TYPE(3517, 0x3517)
(!omap3_has_sgx()) && \
(omap3_has_iva()))
# define cpu_is_omap3530() (cpu_is_omap3430())
-# define cpu_is_omap3505() is_omap3505()
# define cpu_is_omap3517() is_omap3517()
+# define cpu_is_omap3505() (cpu_is_omap3517() && \
+ !omap3_has_sgx())
# undef cpu_is_omap3630
# define cpu_is_omap3630() is_omap363x()
# define cpu_is_ti816x() is_ti816x()
@@ -397,13 +398,8 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3630_REV_ES1_1 (OMAP363X_CLASS | (OMAP_REVBITS_01 << 8))
#define OMAP3630_REV_ES1_2 (OMAP363X_CLASS | (OMAP_REVBITS_02 << 8))
-#define OMAP35XX_CLASS 0x35000034
-#define OMAP3503_REV(v) (OMAP35XX_CLASS | (0x3503 << 16) | (v << 8))
-#define OMAP3515_REV(v) (OMAP35XX_CLASS | (0x3515 << 16) | (v << 8))
-#define OMAP3525_REV(v) (OMAP35XX_CLASS | (0x3525 << 16) | (v << 8))
-#define OMAP3530_REV(v) (OMAP35XX_CLASS | (0x3530 << 16) | (v << 8))
-#define OMAP3505_REV(v) (OMAP35XX_CLASS | (0x3505 << 16) | (v << 8))
-#define OMAP3517_REV(v) (OMAP35XX_CLASS | (0x3517 << 16) | (v << 8))
+#define OMAP3517_CLASS 0x35170034
+#define OMAP3517_REV(v) (OMAP3517_CLASS | (v << 8))
#define TI816X_CLASS 0x81600034
#define TI8168_REV_ES1_0 TI816X_CLASS
^ permalink raw reply related
* [PATCH v3 2/6] OMAP3: id: remove useless strcpy()s
From: Paul Walmsley @ 2011-09-14 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914215512.4790.34446.stgit@dusk>
omap3_cpuinfo() is filled with useless strcpy() calls; remove them.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
---
arch/arm/mach-omap2/id.c | 48 +++++++++++++++++++++-------------------------
1 files changed, 22 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 3f3f998..9fae4de 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -429,84 +429,80 @@ static void __init omap4_check_revision(void)
static void __init omap3_cpuinfo(void)
{
u8 rev = GET_OMAP_REVISION();
- char cpu_name[16], cpu_rev[16];
+ const char *cpu_name, *cpu_rev;
- /* OMAP3430 and OMAP3530 are assumed to be same.
+ /*
+ * OMAP3430 and OMAP3530 are assumed to be same.
*
* OMAP3525, OMAP3515 and OMAP3503 can be detected only based
* on available features. Upon detection, update the CPU id
* and CPU class bits.
*/
if (cpu_is_omap3630()) {
- strcpy(cpu_name, "OMAP3630");
+ cpu_name = "OMAP3630";
} else if (cpu_is_omap3517()) {
- /*
- * AM35xx devices
- */
- if (omap3_has_sgx())
- strcpy(cpu_name, "AM3517");
- else
- strcpy(cpu_name, "AM3505");
+ /* AM35xx devices */
+ cpu_name = (omap3_has_sgx()) ? "AM3517" : "AM3505";
} else if (cpu_is_ti816x()) {
- strcpy(cpu_name, "TI816X");
+ cpu_name = "TI816X";
} else if (omap3_has_iva() && omap3_has_sgx()) {
/* OMAP3430, OMAP3525, OMAP3515, OMAP3503 devices */
- strcpy(cpu_name, "OMAP3430/3530");
+ cpu_name = "OMAP3430/3530";
} else if (omap3_has_iva()) {
- strcpy(cpu_name, "OMAP3525");
+ cpu_name = "OMAP3525";
} else if (omap3_has_sgx()) {
- strcpy(cpu_name, "OMAP3515");
+ cpu_name = "OMAP3515";
} else {
- strcpy(cpu_name, "OMAP3503");
+ cpu_name = "OMAP3503";
}
if (cpu_is_omap3630() || cpu_is_ti816x()) {
switch (rev) {
case OMAP_REVBITS_00:
- strcpy(cpu_rev, "1.0");
+ cpu_rev = "1.0";
break;
case OMAP_REVBITS_01:
- strcpy(cpu_rev, "1.1");
+ cpu_rev = "1.1";
break;
case OMAP_REVBITS_02:
/* FALLTHROUGH */
default:
/* Use the latest known revision as default */
- strcpy(cpu_rev, "1.2");
+ cpu_rev = "1.2";
}
} else if (cpu_is_omap3505() || cpu_is_omap3517()) {
switch (rev) {
case OMAP_REVBITS_00:
- strcpy(cpu_rev, "1.0");
+ cpu_rev = "1.0";
break;
case OMAP_REVBITS_01:
/* FALLTHROUGH */
default:
/* Use the latest known revision as default */
- strcpy(cpu_rev, "1.1");
+ cpu_rev = "1.1";
}
} else {
switch (rev) {
case OMAP_REVBITS_00:
- strcpy(cpu_rev, "1.0");
+ cpu_rev = "1.0";
break;
case OMAP_REVBITS_01:
- strcpy(cpu_rev, "2.0");
+ cpu_rev = "2.0";
break;
case OMAP_REVBITS_02:
- strcpy(cpu_rev, "2.1");
+ cpu_rev = "2.1";
break;
case OMAP_REVBITS_03:
- strcpy(cpu_rev, "3.0");
+ cpu_rev = "3.0";
break;
case OMAP_REVBITS_04:
- strcpy(cpu_rev, "3.1");
+ cpu_rev = "3.1";
break;
case OMAP_REVBITS_05:
/* FALLTHROUGH */
default:
/* Use the latest known revision as default */
- strcpy(cpu_rev, "3.1.2");
+ cpu_rev = "3.1.2";
}
}
^ permalink raw reply related
* [PATCH v3 3/6] OMAP3: id: use explicit omap_revision codes for 3505/3517 ES levels
From: Paul Walmsley @ 2011-09-14 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914215512.4790.34446.stgit@dusk>
Use explicit revision codes for OMAP/AM 3505/3517 ES levels, as the rest
of the OMAP2+ SoCs do in mach-omap2/cpu.c.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
---
arch/arm/mach-omap2/id.c | 10 +++++++++-
arch/arm/plat-omap/include/plat/cpu.h | 3 ++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 9fae4de..94a51cf 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -312,7 +312,15 @@ static void __init omap3_check_revision(void)
*
* REVISIT: AM3505/AM3517 should have their own CHIP_IS
*/
- omap_revision = OMAP3517_REV(rev);
+ switch (rev) {
+ case 0:
+ omap_revision = OMAP3517_REV_ES1_0;
+ break;
+ case 1:
+ /* FALLTHROUGH */
+ default:
+ omap_revision = OMAP3517_REV_ES1_1;
+ }
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
break;
case 0xb891:
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 34df171..1debee9 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -399,7 +399,8 @@ IS_OMAP_TYPE(3517, 0x3517)
#define OMAP3630_REV_ES1_2 (OMAP363X_CLASS | (OMAP_REVBITS_02 << 8))
#define OMAP3517_CLASS 0x35170034
-#define OMAP3517_REV(v) (OMAP3517_CLASS | (v << 8))
+#define OMAP3517_REV_ES1_0 OMAP3517_CLASS
+#define OMAP3517_REV_ES1_1 (OMAP3517_CLASS | (OMAP_REVBITS_01 << 8))
#define TI816X_CLASS 0x81600034
#define TI8168_REV_ES1_0 TI816X_CLASS
^ permalink raw reply related
* [PATCH v3 4/6] OMAP3: id: add fallthrough warning; fix some CodingStyle issues
From: Paul Walmsley @ 2011-09-14 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914215512.4790.34446.stgit@dusk>
Emit a warning to the console in omap3_check_revision() if that code
cannot determine what type of SoC the system is currently running on.
Remove some extra whitespace, remove some duplicate code, and
add an appropriate comment to a fallthrough case.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Hemant Pedanekar <hemantp@ti.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
---
arch/arm/mach-omap2/id.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 94a51cf..3f4a0d0 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -336,8 +336,9 @@ static void __init omap3_check_revision(void)
omap_chip.oc |= CHIP_IS_OMAP3630ES1_1;
break;
case 2:
+ /* FALLTHROUGH */
default:
- omap_revision = OMAP3630_REV_ES1_2;
+ omap_revision = OMAP3630_REV_ES1_2;
omap_chip.oc |= CHIP_IS_OMAP3630ES1_2;
}
break;
@@ -349,16 +350,16 @@ static void __init omap3_check_revision(void)
omap_revision = TI8168_REV_ES1_0;
break;
case 1:
- omap_revision = TI8168_REV_ES1_1;
- break;
+ /* FALLTHROUGH */
default:
- omap_revision = TI8168_REV_ES1_1;
+ omap_revision = TI8168_REV_ES1_1;
}
break;
default:
- /* Unknown default to latest silicon rev as default*/
+ /* Unknown default to latest silicon rev as default */
omap_revision = OMAP3630_REV_ES1_2;
omap_chip.oc |= CHIP_IS_OMAP3630ES1_2;
+ pr_warn("Warning: unknown chip type; assuming OMAP3630ES1.2\n");
}
}
^ permalink raw reply related
* [PATCH v3 5/6] OMAP3: id: remove duplicate code for testing SoC ES level
From: Paul Walmsley @ 2011-09-14 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914215512.4790.34446.stgit@dusk>
omap3_cpuinfo() contains essentially duplicated code from
omap3_check_revision(), just for the purpose of determining the chip ES level.
Set the cpu_rev char array pointer in omap3_check_revision() instead,
and drop the now-useless code from omap3_cpuinfo().
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
---
arch/arm/mach-omap2/id.c | 80 +++++++++++++---------------------------------
1 files changed, 23 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index 3f4a0d0..ed1d439 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -242,7 +242,7 @@ static void __init ti816x_check_features(void)
omap_features = OMAP3_HAS_NEON;
}
-static void __init omap3_check_revision(void)
+static void __init omap3_check_revision(const char **cpu_rev)
{
u32 cpuid, idcode;
u16 hawkeye;
@@ -259,6 +259,7 @@ static void __init omap3_check_revision(void)
if ((((cpuid >> 4) & 0xfff) == 0xc08) && ((cpuid & 0xf) == 0x0)) {
omap_revision = OMAP3430_REV_ES1_0;
omap_chip.oc |= CHIP_IS_OMAP3430ES1;
+ *cpu_rev = "1.0";
return;
}
@@ -280,18 +281,22 @@ static void __init omap3_check_revision(void)
case 1:
omap_revision = OMAP3430_REV_ES2_0;
omap_chip.oc |= CHIP_IS_OMAP3430ES2;
+ *cpu_rev = "2.0";
break;
case 2:
omap_revision = OMAP3430_REV_ES2_1;
omap_chip.oc |= CHIP_IS_OMAP3430ES2;
+ *cpu_rev = "2.1";
break;
case 3:
omap_revision = OMAP3430_REV_ES3_0;
omap_chip.oc |= CHIP_IS_OMAP3430ES3_0;
+ *cpu_rev = "3.0";
break;
case 4:
omap_revision = OMAP3430_REV_ES3_1;
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
+ *cpu_rev = "3.1";
break;
case 7:
/* FALLTHROUGH */
@@ -301,6 +306,7 @@ static void __init omap3_check_revision(void)
/* REVISIT: Add CHIP_IS_OMAP3430ES3_1_2? */
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
+ *cpu_rev = "3.1.2";
}
break;
case 0xb868:
@@ -315,11 +321,13 @@ static void __init omap3_check_revision(void)
switch (rev) {
case 0:
omap_revision = OMAP3517_REV_ES1_0;
+ *cpu_rev = "1.0";
break;
case 1:
/* FALLTHROUGH */
default:
omap_revision = OMAP3517_REV_ES1_1;
+ *cpu_rev = "1.1";
}
omap_chip.oc |= CHIP_IS_OMAP3430ES3_1;
break;
@@ -330,16 +338,19 @@ static void __init omap3_check_revision(void)
switch(rev) {
case 0: /* Take care of early samples */
omap_revision = OMAP3630_REV_ES1_0;
+ *cpu_rev = "1.0";
break;
case 1:
omap_revision = OMAP3630_REV_ES1_1;
omap_chip.oc |= CHIP_IS_OMAP3630ES1_1;
+ *cpu_rev = "1.1";
break;
case 2:
/* FALLTHROUGH */
default:
omap_revision = OMAP3630_REV_ES1_2;
omap_chip.oc |= CHIP_IS_OMAP3630ES1_2;
+ *cpu_rev = "1.2";
}
break;
case 0xb81e:
@@ -348,17 +359,21 @@ static void __init omap3_check_revision(void)
switch (rev) {
case 0:
omap_revision = TI8168_REV_ES1_0;
+ *cpu_rev = "1.0";
break;
case 1:
/* FALLTHROUGH */
default:
omap_revision = TI8168_REV_ES1_1;
+ *cpu_rev = "1.1";
+ break;
}
break;
default:
/* Unknown default to latest silicon rev as default */
- omap_revision = OMAP3630_REV_ES1_2;
+ omap_revision = OMAP3630_REV_ES1_2;
omap_chip.oc |= CHIP_IS_OMAP3630ES1_2;
+ *cpu_rev = "1.2";
pr_warn("Warning: unknown chip type; assuming OMAP3630ES1.2\n");
}
}
@@ -435,10 +450,9 @@ static void __init omap4_check_revision(void)
if (omap3_has_ ##feat()) \
printk(#feat" ");
-static void __init omap3_cpuinfo(void)
+static void __init omap3_cpuinfo(const char *cpu_rev)
{
- u8 rev = GET_OMAP_REVISION();
- const char *cpu_name, *cpu_rev;
+ const char *cpu_name;
/*
* OMAP3430 and OMAP3530 are assumed to be same.
@@ -465,56 +479,6 @@ static void __init omap3_cpuinfo(void)
cpu_name = "OMAP3503";
}
- if (cpu_is_omap3630() || cpu_is_ti816x()) {
- switch (rev) {
- case OMAP_REVBITS_00:
- cpu_rev = "1.0";
- break;
- case OMAP_REVBITS_01:
- cpu_rev = "1.1";
- break;
- case OMAP_REVBITS_02:
- /* FALLTHROUGH */
- default:
- /* Use the latest known revision as default */
- cpu_rev = "1.2";
- }
- } else if (cpu_is_omap3505() || cpu_is_omap3517()) {
- switch (rev) {
- case OMAP_REVBITS_00:
- cpu_rev = "1.0";
- break;
- case OMAP_REVBITS_01:
- /* FALLTHROUGH */
- default:
- /* Use the latest known revision as default */
- cpu_rev = "1.1";
- }
- } else {
- switch (rev) {
- case OMAP_REVBITS_00:
- cpu_rev = "1.0";
- break;
- case OMAP_REVBITS_01:
- cpu_rev = "2.0";
- break;
- case OMAP_REVBITS_02:
- cpu_rev = "2.1";
- break;
- case OMAP_REVBITS_03:
- cpu_rev = "3.0";
- break;
- case OMAP_REVBITS_04:
- cpu_rev = "3.1";
- break;
- case OMAP_REVBITS_05:
- /* FALLTHROUGH */
- default:
- /* Use the latest known revision as default */
- cpu_rev = "3.1.2";
- }
- }
-
/* Print verbose information */
pr_info("%s ES%s (", cpu_name, cpu_rev);
@@ -533,6 +497,8 @@ static void __init omap3_cpuinfo(void)
*/
void __init omap2_check_revision(void)
{
+ const char *cpu_rev;
+
/*
* At this point we have an idea about the processor revision set
* earlier with omap2_set_globals_tap().
@@ -540,7 +506,7 @@ void __init omap2_check_revision(void)
if (cpu_is_omap24xx()) {
omap24xx_check_revision();
} else if (cpu_is_omap34xx()) {
- omap3_check_revision();
+ omap3_check_revision(&cpu_rev);
/* TI816X doesn't have feature register */
if (!cpu_is_ti816x())
@@ -548,7 +514,7 @@ void __init omap2_check_revision(void)
else
ti816x_check_features();
- omap3_cpuinfo();
+ omap3_cpuinfo(cpu_rev);
return;
} else if (cpu_is_omap44xx()) {
omap4_check_revision();
^ permalink raw reply related
* [PATCH v3 6/6] OMAP2+: id: remove OMAP_REVBITS_* macros
From: Paul Walmsley @ 2011-09-14 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914215512.4790.34446.stgit@dusk>
The OMAP_REVBITS_* macros are just used as otherwise meaningless
aliases for the numbers zero through five, so remove these macros.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Tested-by: Igor Grinberg <grinberg@compulab.co.il>
Tested-by: Abhilash Koyamangalath <abhilash.kv@ti.com>
---
arch/arm/plat-omap/include/plat/cpu.h | 33 ++++++++++-----------------------
1 files changed, 10 insertions(+), 23 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/cpu.h b/arch/arm/plat-omap/include/plat/cpu.h
index 1debee9..ddbc025 100644
--- a/arch/arm/plat-omap/include/plat/cpu.h
+++ b/arch/arm/plat-omap/include/plat/cpu.h
@@ -60,19 +60,6 @@ struct omap_chip_id {
unsigned int omap_rev(void);
/*
- * Define CPU revision bits
- *
- * Verbose meaning of the revision bits may be different for a silicon
- * family. This difference can be handled separately.
- */
-#define OMAP_REVBITS_00 0x00
-#define OMAP_REVBITS_01 0x01
-#define OMAP_REVBITS_02 0x02
-#define OMAP_REVBITS_03 0x03
-#define OMAP_REVBITS_04 0x04
-#define OMAP_REVBITS_05 0x05
-
-/*
* Get the CPU revision for OMAP devices
*/
#define GET_OMAP_REVISION() ((omap_rev() >> 8) & 0xff)
@@ -380,31 +367,31 @@ IS_OMAP_TYPE(3517, 0x3517)
/* Various silicon revisions for omap2 */
#define OMAP242X_CLASS 0x24200024
#define OMAP2420_REV_ES1_0 OMAP242X_CLASS
-#define OMAP2420_REV_ES2_0 (OMAP242X_CLASS | (OMAP_REVBITS_01 << 8))
+#define OMAP2420_REV_ES2_0 (OMAP242X_CLASS | (0x1 << 8))
#define OMAP243X_CLASS 0x24300024
#define OMAP2430_REV_ES1_0 OMAP243X_CLASS
#define OMAP343X_CLASS 0x34300034
#define OMAP3430_REV_ES1_0 OMAP343X_CLASS
-#define OMAP3430_REV_ES2_0 (OMAP343X_CLASS | (OMAP_REVBITS_01 << 8))
-#define OMAP3430_REV_ES2_1 (OMAP343X_CLASS | (OMAP_REVBITS_02 << 8))
-#define OMAP3430_REV_ES3_0 (OMAP343X_CLASS | (OMAP_REVBITS_03 << 8))
-#define OMAP3430_REV_ES3_1 (OMAP343X_CLASS | (OMAP_REVBITS_04 << 8))
-#define OMAP3430_REV_ES3_1_2 (OMAP343X_CLASS | (OMAP_REVBITS_05 << 8))
+#define OMAP3430_REV_ES2_0 (OMAP343X_CLASS | (0x1 << 8))
+#define OMAP3430_REV_ES2_1 (OMAP343X_CLASS | (0x2 << 8))
+#define OMAP3430_REV_ES3_0 (OMAP343X_CLASS | (0x3 << 8))
+#define OMAP3430_REV_ES3_1 (OMAP343X_CLASS | (0x4 << 8))
+#define OMAP3430_REV_ES3_1_2 (OMAP343X_CLASS | (0x5 << 8))
#define OMAP363X_CLASS 0x36300034
#define OMAP3630_REV_ES1_0 OMAP363X_CLASS
-#define OMAP3630_REV_ES1_1 (OMAP363X_CLASS | (OMAP_REVBITS_01 << 8))
-#define OMAP3630_REV_ES1_2 (OMAP363X_CLASS | (OMAP_REVBITS_02 << 8))
+#define OMAP3630_REV_ES1_1 (OMAP363X_CLASS | (0x1 << 8))
+#define OMAP3630_REV_ES1_2 (OMAP363X_CLASS | (0x2 << 8))
#define OMAP3517_CLASS 0x35170034
#define OMAP3517_REV_ES1_0 OMAP3517_CLASS
-#define OMAP3517_REV_ES1_1 (OMAP3517_CLASS | (OMAP_REVBITS_01 << 8))
+#define OMAP3517_REV_ES1_1 (OMAP3517_CLASS | (0x1 << 8))
#define TI816X_CLASS 0x81600034
#define TI8168_REV_ES1_0 TI816X_CLASS
-#define TI8168_REV_ES1_1 (TI816X_CLASS | (OMAP_REVBITS_01 << 8))
+#define TI8168_REV_ES1_1 (TI816X_CLASS | (0x1 << 8))
#define OMAP443X_CLASS 0x44300044
#define OMAP4430_REV_ES1_0 (OMAP443X_CLASS | (0x10 << 8))
^ permalink raw reply related
* [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver
From: Tony Lindgren @ 2011-09-14 22:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914214533.GA30941@atomide.com>
* Tony Lindgren <tony@atomide.com> [110914 14:12]:
>
> Also, as we don't need the support for different register offsets
> for the first two omap4 timers, please rather implement support
> for the new timers and the timeouts directly in plat-omap/dmtimer.c.
>
> That way we can still keep the minimal timer support simple
> for clocksource and clockevent. Of course this means that we'll
> be only supporting the first two timers as system timers on
> omap4, but that's fine.
Since you already have the struct timer_regs, you can make use
of that in dmtimer.c. Then maybe make the inline functions to
something like this instead:
static inline u32 __omap_dm_timer_read(void __iomem *base, u8 reg,
u8 pend, int posted);
Where you pass the timer->context.pend depending on the pending
register offset for the timer.
Regards,
Tony
^ permalink raw reply
* [PATCH v2 0/4] OMAP2: clockdomain/powerdomain: remove OMAP_CHIP bitmasks
From: Paul Walmsley @ 2011-09-14 22:45 UTC (permalink / raw)
To: linux-arm-kernel
Remove the OMAP_CHIP bitmasks from the powerdomain and clockdomain
code. In their place, use lists of powerdomains and clockdomains to
register for particular chips and chip families.
The intention of this change is to reduce the number of lines that
need to be patched to add support for new SoCs that are similar to
previous SoCs.
This series has been boot-tested on a 2430SDP, BeagleBoard 35xx and
37xx, and PandaBoard 44xxES2, but I don't have boards for all of the
different variants needed for a complete test.
A git branch 'pwrdm_clkdm_remove_omap_chip_cleanup_3.2' is available
at git://git.pwsan.com/linux-2.6 based on v3.1-rc4 with
prcm-fixes-a-3.1rc and id_3517_cleanup_3.2.
This second version is updated to apply on the id_3517_cleanup_3.2
branch, and the 3517/3505 revision test code has been appropriately
updated.
- Paul
---
pwrdm_clkdm_remove_omap_chip_cleanup_3.2
text data bss dec hex filename
6329924 656956 5591124 12578004 bfecd4 vmlinux.omap2plus_defconfig.orig
6330120 656044 5591124 12577288 bfea08 vmlinux.omap2plus_defconfig.patched
Paul Walmsley (4):
OMAP: clockdomain: split clkdm_init()
OMAP: clockdomain code/data: remove omap_chip bitmask from struct clockdomain
OMAP: powerdomain: split pwrdm_init() into two functions
OMAP: powerdomain: remove omap_chip bitmasks
arch/arm/mach-omap2/Makefile | 5
arch/arm/mach-omap2/clockdomain.c | 149 +++-
arch/arm/mach-omap2/clockdomain.h | 22 -
arch/arm/mach-omap2/clockdomain2xxx_3xxx.c | 4
arch/arm/mach-omap2/clockdomain44xx.c | 2
arch/arm/mach-omap2/clockdomains2420_data.c | 155 ++++
arch/arm/mach-omap2/clockdomains2430_data.c | 181 +++++
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 803 ----------------------
arch/arm/mach-omap2/clockdomains3xxx_data.c | 398 +++++++++++
arch/arm/mach-omap2/clockdomains44xx_data.c | 409 ++---------
arch/arm/mach-omap2/io.c | 8
arch/arm/mach-omap2/powerdomain-common.c | 7
arch/arm/mach-omap2/powerdomain.c | 87 ++
arch/arm/mach-omap2/powerdomain.h | 9
arch/arm/mach-omap2/powerdomains2xxx_3xxx_data.c | 19 -
arch/arm/mach-omap2/powerdomains2xxx_data.c | 44 +
arch/arm/mach-omap2/powerdomains3xxx_data.c | 81 +-
arch/arm/mach-omap2/powerdomains44xx_data.c | 20 -
18 files changed, 1104 insertions(+), 1299 deletions(-)
create mode 100644 arch/arm/mach-omap2/clockdomains2420_data.c
create mode 100644 arch/arm/mach-omap2/clockdomains2430_data.c
create mode 100644 arch/arm/mach-omap2/clockdomains3xxx_data.c
--
Signature
^ permalink raw reply
* [PATCH v2 1/4] OMAP: clockdomain: split clkdm_init()
From: Paul Walmsley @ 2011-09-14 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110914220723.12067.99495.stgit@dusk>
In preparation for OMAP_CHIP() removal, split clkdm_init() into four
functions. This allows some of them to be called multiple times: for
example, clkdm_register_clkdms() can be called once to register
clockdomains that are common to a group of SoCs, and once to register
clockdomains that are specific to a single SoC.
The appropriate order to call these functions - which is enforced
by the code - is:
1. clkdm_register_platform_funcs()
2. clkdm_register_clkdms() (can be called multiple times)
3. clkdm_register_autodeps() (optional; deprecated)
4. clkdm_complete_init()
Convert the OMAP2, 3, and 4 clockdomain init code to use these new
functions.
While here, improve documentation, and increase CodingStyle
conformance by shortening some local variable names.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
---
arch/arm/mach-omap2/clockdomain.c | 130 +++++++++++++++++-----
arch/arm/mach-omap2/clockdomain.h | 7 +
arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c | 13 ++
arch/arm/mach-omap2/clockdomains44xx_data.c | 5 +
4 files changed, 121 insertions(+), 34 deletions(-)
diff --git a/arch/arm/mach-omap2/clockdomain.c b/arch/arm/mach-omap2/clockdomain.c
index 8f08906..b73a1dc 100644
--- a/arch/arm/mach-omap2/clockdomain.c
+++ b/arch/arm/mach-omap2/clockdomain.c
@@ -257,43 +257,113 @@ static void _resolve_clkdm_deps(struct clockdomain *clkdm,
/* Public functions */
/**
- * clkdm_init - set up the clockdomain layer
- * @clkdms: optional pointer to an array of clockdomains to register
- * @init_autodeps: optional pointer to an array of autodeps to register
- * @custom_funcs: func pointers for arch specific implementations
- *
- * Set up internal state. If a pointer to an array of clockdomains
- * @clkdms was supplied, loop through the list of clockdomains,
- * register all that are available on the current platform. Similarly,
- * if a pointer to an array of clockdomain autodependencies
- * @init_autodeps was provided, register those. No return value.
+ * clkdm_register_platform_funcs - register clockdomain implementation fns
+ * @co: func pointers for arch specific implementations
+ *
+ * Register the list of function pointers used to implement the
+ * clockdomain functions on different OMAP SoCs. Should be called
+ * before any other clkdm_register*() function. Returns -EINVAL if
+ * @co is null, -EEXIST if platform functions have already been
+ * registered, or 0 upon success.
+ */
+int clkdm_register_platform_funcs(struct clkdm_ops *co)
+{
+ if (!co)
+ return -EINVAL;
+
+ if (arch_clkdm)
+ return -EEXIST;
+
+ arch_clkdm = co;
+
+ return 0;
+};
+
+/**
+ * clkdm_register_clkdms - register SoC clockdomains
+ * @cs: pointer to an array of struct clockdomain to register
+ *
+ * Register the clockdomains available on a particular OMAP SoC. Must
+ * be called after clkdm_register_platform_funcs(). May be called
+ * multiple times. Returns -EACCES if called before
+ * clkdm_register_platform_funcs(); -EINVAL if the argument @cs is
+ * null; or 0 upon success.
*/
-void clkdm_init(struct clockdomain **clkdms,
- struct clkdm_autodep *init_autodeps,
- struct clkdm_ops *custom_funcs)
+int clkdm_register_clkdms(struct clockdomain **cs)
{
struct clockdomain **c = NULL;
- struct clockdomain *clkdm;
- struct clkdm_autodep *autodep = NULL;
- if (!custom_funcs)
- WARN(1, "No custom clkdm functions registered\n");
- else
- arch_clkdm = custom_funcs;
+ if (!arch_clkdm)
+ return -EACCES;
+
+ if (!cs)
+ return -EINVAL;
+
+ for (c = cs; *c; c++)
+ _clkdm_register(*c);
- if (clkdms)
- for (c = clkdms; *c; c++)
- _clkdm_register(*c);
+ return 0;
+}
+
+/**
+ * clkdm_register_autodeps - register autodeps (if required)
+ * @ia: pointer to a static array of struct clkdm_autodep to register
+ *
+ * Register clockdomain "automatic dependencies." These are
+ * clockdomain wakeup and sleep dependencies that are automatically
+ * added whenever the first clock inside a clockdomain is enabled, and
+ * removed whenever the last clock inside a clockdomain is disabled.
+ * These are currently only used on OMAP3 devices, and are deprecated,
+ * since they waste energy. However, until the OMAP2/3 IP block
+ * enable/disable sequence can be converted to match the OMAP4
+ * sequence, they are needed.
+ *
+ * Must be called only after all of the SoC clockdomains are
+ * registered, since the function will resolve autodep clockdomain
+ * names into clockdomain pointers.
+ *
+ * The struct clkdm_autodep @ia array must be static, as this function
+ * does not copy the array elements.
+ *
+ * Returns -EACCES if called before any clockdomains have been
+ * registered, -EINVAL if called with a null @ia argument, -EEXIST if
+ * autodeps have already been registered, or 0 upon success.
+ */
+int clkdm_register_autodeps(struct clkdm_autodep *ia)
+{
+ struct clkdm_autodep *a = NULL;
+
+ if (list_empty(&clkdm_list))
+ return -EACCES;
+
+ if (!ia)
+ return -EINVAL;
- autodeps = init_autodeps;
if (autodeps)
- for (autodep = autodeps; autodep->clkdm.ptr; autodep++)
- _autodep_lookup(autodep);
+ return -EEXIST;
+
+ autodeps = ia;
+ for (a = autodeps; a->clkdm.ptr; a++)
+ _autodep_lookup(a);
+
+ return 0;
+}
+
+/**
+ * clkdm_complete_init - set up the clockdomain layer
+ *
+ * Put all clockdomains into software-supervised mode; PM code should
+ * later enable hardware-supervised mode as appropriate. Must be
+ * called after clkdm_register_clkdms(). Returns -EACCES if called
+ * before clkdm_register_clkdms(), or 0 upon success.
+ */
+int clkdm_complete_init(void)
+{
+ struct clockdomain *clkdm;
+
+ if (list_empty(&clkdm_list))
+ return -EACCES;
- /*
- * Put all clockdomains into software-supervised mode; PM code
- * should later enable hardware-supervised mode as appropriate
- */
list_for_each_entry(clkdm, &clkdm_list, node) {
if (clkdm->flags & CLKDM_CAN_FORCE_WAKEUP)
clkdm_wakeup(clkdm);
@@ -306,6 +376,8 @@ void clkdm_init(struct clockdomain **clkdms,
_resolve_clkdm_deps(clkdm, clkdm->sleepdep_srcs);
clkdm_clear_all_sleepdeps(clkdm);
}
+
+ return 0;
}
/**
diff --git a/arch/arm/mach-omap2/clockdomain.h b/arch/arm/mach-omap2/clockdomain.h
index 1e50c88..0d879ff 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -166,8 +166,11 @@ struct clkdm_ops {
int (*clkdm_clk_disable)(struct clockdomain *clkdm);
};
-void clkdm_init(struct clockdomain **clkdms, struct clkdm_autodep *autodeps,
- struct clkdm_ops *custom_funcs);
+int clkdm_register_platform_funcs(struct clkdm_ops *co);
+int clkdm_register_autodeps(struct clkdm_autodep *ia);
+int clkdm_register_clkdms(struct clockdomain **c);
+int clkdm_complete_init(void);
+
struct clockdomain *clkdm_lookup(const char *name);
int clkdm_for_each(int (*fn)(struct clockdomain *clkdm, void *user),
diff --git a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
index 13bde95..148a3e8 100644
--- a/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains2xxx_3xxx_data.c
@@ -857,12 +857,21 @@ static struct clockdomain *clockdomains_omap2[] __initdata = {
NULL,
};
+static void __init omap2_3_clockdomains_init(void)
+{
+ clkdm_register_clkdms(clockdomains_omap2);
+ clkdm_register_autodeps(clkdm_autodeps);
+ clkdm_complete_init();
+}
+
void __init omap2xxx_clockdomains_init(void)
{
- clkdm_init(clockdomains_omap2, clkdm_autodeps, &omap2_clkdm_operations);
+ clkdm_register_platform_funcs(&omap2_clkdm_operations);
+ omap2_3_clockdomains_init();
}
void __init omap3xxx_clockdomains_init(void)
{
- clkdm_init(clockdomains_omap2, clkdm_autodeps, &omap3_clkdm_operations);
+ clkdm_register_platform_funcs(&omap3_clkdm_operations);
+ omap2_3_clockdomains_init();
}
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c b/arch/arm/mach-omap2/clockdomains44xx_data.c
index dccc651..c75411a 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -685,7 +685,10 @@ static struct clockdomain *clockdomains_omap44xx[] __initdata = {
NULL
};
+
void __init omap44xx_clockdomains_init(void)
{
- clkdm_init(clockdomains_omap44xx, NULL, &omap4_clkdm_operations);
+ clkdm_register_platform_funcs(&omap4_clkdm_operations);
+ clkdm_register_clkdms(clockdomains_omap44xx);
+ clkdm_complete_init();
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox