Re: [PATCH] clk: prevent erronous parsing of children during rate change
On 09/26/2014 04:35 AM, Stephen Boyd wrote: On 09/23/14 06:38, Tero Kristo wrote: On 09/22/2014 10:18 PM, Stephen Boyd wrote: On 08/21, Tero Kristo wrote: /* Skip children who will be reparented to another clock */ if (child-new_parent child-new_parent != clk) continue; Are we not hitting the new_parent check here? I don't understand how we can be changing parents here unless the check is being avoided, in which case I wonder why determine_rate isn't being used. It depends how the clock underneath handles the situation. The error I am seeing actually happens with a SoC specific compound clock (DPLL) which integrates set_rate + mux functionality into a single clock node. A call to the clk_set_rate changes the parent of this clock (from bypass clock to reference clock), in addition to changing the rate (tune the mul+div.) I looked at using the determine rate call with this type but it breaks everything up... the parent gets changed but not the clock rate, in addition to some other issues. Ok. Is this omap3_noncore_dpll_set_rate()? Yes. Can we use determine_rate + clk_set_parent_and_rate()? At least clk_set_parent_and_rate() would allow us to do the mult+div and the parent in the same op call, although I don't understand why setting the parent and then setting the rate is not going to work. Well, setting parent first, then rate later causes problems with the DPLL ending up running with illegal (non-specified) rate, the M+N values are most likely wrong if you just switch from bypass clock to reference clock first without programming the M+N first. I'm interested in the other issues that you mentioned too. Mostly these were side-effects from the illegal DPLL setup I guess, like boot hang, failed drivers etc. I didn't really investigate this that much as it is much more simpler just to use safe list iteration here. -Tero -- 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] ARM: dts: dra7-evm: Fix interrupt line of pcf@i2c1:0x21
The interrupt line of pcf I/O expander chip @i2c1:0x21 is tied to gpio6_11 and not gpio6_14. Fix that. Without this USB_ID detection will not work and I2C3 bus activity will cause spurious interrupts for the I/O expander chip. Fixes: 87991e7b4dd4 (ARM: dts: dra7-evm: Add extcon nodes for USB) Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/dra7-evm.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 8ddd012..53b6fba 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -606,7 +606,7 @@ gpio-controller; #gpio-cells = 2; interrupt-parent = gpio6; - interrupts = 14 IRQ_TYPE_EDGE_FALLING; + interrupts = 11 IRQ_TYPE_EDGE_FALLING; interrupt-controller; #interrupt-cells = 2; }; -- 1.8.3.2 -- 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] ARM: dts: dra7-evm: Fix interrupt line of pcf@i2c1:0x21
Oops. send to the wrong mailing list. Please ignore. cheers, -roger On 09/26/2014 04:02 PM, Roger Quadros wrote: The interrupt line of pcf I/O expander chip @i2c1:0x21 is tied to gpio6_11 and not gpio6_14. Fix that. Without this USB_ID detection will not work and I2C3 bus activity will cause spurious interrupts for the I/O expander chip. Fixes: 87991e7b4dd4 (ARM: dts: dra7-evm: Add extcon nodes for USB) Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/dra7-evm.dts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts index 8ddd012..53b6fba 100644 --- a/arch/arm/boot/dts/dra7-evm.dts +++ b/arch/arm/boot/dts/dra7-evm.dts @@ -606,7 +606,7 @@ gpio-controller; #gpio-cells = 2; interrupt-parent = gpio6; - interrupts = 14 IRQ_TYPE_EDGE_FALLING; + interrupts = 11 IRQ_TYPE_EDGE_FALLING; interrupt-controller; #interrupt-cells = 2; }; -- 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: [PATCHv4 4/7] hwspinlock/core: add common OF helpers
On Mon, Jan 13, 2014 at 4:19 PM, Suman Anna s-a...@ti.com wrote: This patch adds three new OF helper functions to use/request locks from a hwspinlock device instantiated through a device-tree blob. Hi Ohad, Suman I'm about to send out some patches that depends on this functionality, how do we move forward? I still think it's wrong to not return -EPROBE_DEFER, but I much rather have the code returning NULL than not having it in the tree (we can always argue about it later...). @Suman, do you remember if there was any other comments on the patch? @Ohad, do you object merging Suman's patch in it's current form? I think it should still apply cleanly. Regards, Bjorn -- 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 00/16 v9] omap 8250 based uart + DMA
On Wed, Sep 17, 2014 at 11:05:06AM +0200, Sebastian Andrzej Siewior wrote: On 2014-09-10 21:29:55 [+0200], Sebastian Andrzej Siewior wrote: the diff of v8…v9 is small: Greg, do you mind taking patches from this series up to [PATCH 05/16]? Nobody complained about those so far and it would keep v10 a little smaller. I have changes to #6 (the omap driver) and need to do some DMA related changes in the following Now applied, 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: [PATCHv4 4/7] hwspinlock/core: add common OF helpers
Hi Bjorn, On 09/26/2014 09:40 AM, Bjorn Andersson wrote: On Mon, Jan 13, 2014 at 4:19 PM, Suman Anna s-a...@ti.com wrote: This patch adds three new OF helper functions to use/request locks from a hwspinlock device instantiated through a device-tree blob. Hi Ohad, Suman I'm about to send out some patches that depends on this functionality, how do we move forward? I still think it's wrong to not return -EPROBE_DEFER, but I much rather have the code returning NULL than not having it in the tree (we can always argue about it later...). @Suman, do you remember if there was any other comments on the patch? I have posted two further revisions of this series, the latest is v6 [1]. I added additional patches in v5 that added the concept of reserved locks, and I have posted them as a separate RFC [2] for v6 so as to not block the core DT support. In anycase, the latest v6 version does not define the of_hwspin_lock_request_specific() function anymore, and it is replaced with of_hwspin_lock_get_id() function, based on Ohad's review comments on v5, and I did add the support for -EPROBE_DEFER in this API, without changing any of the existing return code conventions. I am yet to receive any comments on v6, but that series should address both your need for a probe deferral and Ohad's request to not change any return types. Please give it a try and let me know if you have any comments. regards Suman [1] http://marc.info/?l=linux-arm-kernelm=141055365513902w=2 [2] http://marc.info/?l=linux-arm-kernelm=14104214657w=2 @Ohad, do you object merging Suman's patch in it's current form? I think it should still apply cleanly. Regards, Bjorn -- 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] clk: prevent erronous parsing of children during rate change
Quoting Tero Kristo (2014-09-26 00:18:55) On 09/26/2014 04:35 AM, Stephen Boyd wrote: On 09/23/14 06:38, Tero Kristo wrote: On 09/22/2014 10:18 PM, Stephen Boyd wrote: On 08/21, Tero Kristo wrote: /* Skip children who will be reparented to another clock */ if (child-new_parent child-new_parent != clk) continue; Are we not hitting the new_parent check here? I don't understand how we can be changing parents here unless the check is being avoided, in which case I wonder why determine_rate isn't being used. It depends how the clock underneath handles the situation. The error I am seeing actually happens with a SoC specific compound clock (DPLL) which integrates set_rate + mux functionality into a single clock node. A call to the clk_set_rate changes the parent of this clock (from bypass clock to reference clock), in addition to changing the rate (tune the mul+div.) I looked at using the determine rate call with this type but it breaks everything up... the parent gets changed but not the clock rate, in addition to some other issues. Ok. Is this omap3_noncore_dpll_set_rate()? Yes. Can we use determine_rate + clk_set_parent_and_rate()? At least clk_set_parent_and_rate() would allow us to do the mult+div and the parent in the same op call, although I don't understand why setting the parent and then setting the rate is not going to work. Well, setting parent first, then rate later causes problems with the DPLL ending up running with illegal (non-specified) rate, the M+N values are most likely wrong if you just switch from bypass clock to reference clock first without programming the M+N first. I took a quick look and it still seems to me that the OMAP DPLLs are still not modeled properly as mux clocks. Is this correct? This issue has been lingering for a long time and we can't use determine_rate unless that clock has multiple parents. Simply hacking knowledge of the parent bypass clock into the .set_rate callback is not enough. Regards, Mike I'm interested in the other issues that you mentioned too. Mostly these were side-effects from the illegal DPLL setup I guess, like boot hang, failed drivers etc. I didn't really investigate this that much as it is much more simpler just to use safe list iteration here. -Tero -- 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] clk: add gpio gated clock
Quoting Jyri Sarha (2014-09-11 01:44:24) On 09/10/2014 01:14 AM, Mike Turquette wrote: Quoting Jyri Sarha (2014-09-05 05:21:34) The added gpio-gate-clock is a basic clock that can be enabled and disabled trough a gpio output. The DT binding document for the clock is also added. For EPROBE_DEFER handling the registering of the clock has to be delayed until of_clk_get() call time. Signed-off-by: Jyri Sarha jsa...@ti.com --- This is my final attempt to get this generic gpio controlled basic clock into mainline. Of course I gladly fix any issues that the patch may have. However, if there is no response, I give up and move it to TI specific clocks. I searched through my archives and found a post from January. You Cc'd me as mturque...@linaro.org. Note that the address is wrapped in chevrons but there is no name string (e.g. Mike Turquette). My mailer doesn't parse this well it was not flagged as to:me in my filters. Maybe other mailers handle this better? If you leave out the name string in the future then it would probably be best to drop the chevrons. Then git send-email adds the chevrons, but in the future I'll put the name string there too. I've been sending this patch as a part of Beaglebone-Black HDMI audio patch series since last autumn. Since the previous version I have done some minor cleanups and changed the clock's compatible property from gpio-clock to gpio-gate-clock. All the file names, comments, etc. have also been changed accordingly. Is your platform the only one to take advantage of this clock type so far? I feel that it is esoteric enough that it shouldn't be made generic. The main reason is that all of the generic clock types needs to be overhauled at some point. E.g. the clk-gate should have its machine-specific logic separated from its machine-independent logic. If the gate clock were to populate .enable and .disable callbacks and then leave the actual register banging, or regmap'ing, or gpio'ing up to your backend driver then that would be a big improvement and would avoid the need to create this new clock type outright. So that's on my todo list, but it's not done yet. For your patch I think that putting this code into drivers/clk/ti would probably be best, unless other folks could use it as-is. Even if others could use it today I would want to remove it eventually for the reasons stated in the paragraph above. Ok, I see. I do not know of anybody else needing a gpio gate clock at the moment. I'll put the driver under drivers/clk/ti unless someone comes forward soon. Well nobody came forward but after thinking about it I've seen this design elsewhere, so it should probably be generic. And the underlying machine-specific ops are less relevant to this type since most of that is abstracted away behind the GPIO api. Applied to clk-next. Let me know if that causes a problem for you if you have merged this into the TI clk stuff. Regards, Mike Thanks, Jyri -- 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 v3 1/5] clk: ti: add ti,gpio-gate-clock controlled clock
Quoting Tomi Valkeinen (2014-09-19 06:25:48) On 19/09/14 16:12, Nishanth Menon wrote: On 09/19/2014 08:07 AM, Tomi Valkeinen wrote: On 16/09/14 23:40, Jyri Sarha wrote: The added ti,gpio-gate-clock is a basic clock that can be enabled and disabled trough a gpio output. The DT binding document for the clock is also added. For EPROBE_DEFER handling the registering of the clock has to be delayed until of_clk_get() call time. Signed-off-by: Jyri Sarha jsa...@ti.com --- .../bindings/clock/ti/gpio-gate-clock.txt | 21 ++ drivers/clk/ti/Makefile|2 +- drivers/clk/ti/gpio.c | 202 3 files changed, 224 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/clock/ti/gpio-gate-clock.txt create mode 100644 drivers/clk/ti/gpio.c Why is this a TI clock? Sounds like a generic one to me. Like thread: https://lkml.org/lkml/2014/9/5/284 ? Right, I should've read the earlier versions before making any smart comments =). No supporters cropped up for the generic gpio clock, but the design is common enough to merit a common clock type. And all of that stuff I said about the machine-specific ops isn't that relevant since it is hidden behing the gpio api. Regards, Mike Tomi -- 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] clk, ti, LLVMLinux: Move __init outside of type definition
As written, the __init for ti_clk_get_div_table is in the middle of the return
type.
The gcc documentation indicates that section attributes should be added to the
end of the function declaration:
extern void foobar (void) __attribute__ ((section (bar)));
However gcc seems to be very permissive with where attributes can be placed.
clang on the other hand isn't so permissive, and fails if you put the section
definition in the middle of the return type:
drivers/clk/ti/divider.c:298:28: error: expected ';' after struct
static struct clk_div_table
^
;
drivers/clk/ti/divider.c:298:1: warning: 'static' ignored on this
declaration [-Wmissing-declarations]
static struct clk_div_table
^
drivers/clk/ti/divider.c:299:9: error: type specifier missing,
defaults to 'int' [-Werror,-Wimplicit-int]
__init *ti_clk_get_div_table(struct device_node *node)
~~ ^
drivers/clk/ti/divider.c:345:9: warning: incompatible pointer types
returning 'struct clk_div_table *' from a function with result type 'int
*' [-Wincompatible-pointer-types]
return table;
^
drivers/clk/ti/divider.c:419:9: warning: incompatible pointer types
assigning to 'const struct clk_div_table *' from 'int *'
[-Wincompatible-pointer-types]
*table = ti_clk_get_div_table(node);
^ ~~
3 warnings and 2 errors generated.
By convention, most of the kernel code puts section attributes between the
return type and function name. In the case where the return type is a pointer,
it's important to place the '*' on left of the __init.
This updated code works for both gcc and clang.
Signed-off-by: Behan Webster beh...@converseincode.com
Reviewed-by: Mark Charlebois charl...@gmail.com
---
drivers/clk/ti/divider.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/ti/divider.c b/drivers/clk/ti/divider.c
index a837f70..bff2b5b 100644
--- a/drivers/clk/ti/divider.c
+++ b/drivers/clk/ti/divider.c
@@ -300,8 +300,8 @@ static struct clk *_register_divider(struct device *dev,
const char *name,
return clk;
}
-static struct clk_div_table
-__init *ti_clk_get_div_table(struct device_node *node)
+static struct clk_div_table *
+__init ti_clk_get_div_table(struct device_node *node)
{
struct clk_div_table *table;
const __be32 *divspec;
--
1.9.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
Re: [PATCH] clk, ti, LLVMLinux: Move __init outside of type definition
On Fri, Sep 26, 2014 at 05:31:48PM -0700, Behan Webster wrote: As written, the __init for ti_clk_get_div_table is in the middle of the return type. The gcc documentation indicates that section attributes should be added to the end of the function declaration: extern void foobar (void) __attribute__ ((section (bar))); However gcc seems to be very permissive with where attributes can be placed. clang on the other hand isn't so permissive, and fails if you put the section definition in the middle of the return type: drivers/clk/ti/divider.c:298:28: error: expected ';' after struct static struct clk_div_table ^ ; drivers/clk/ti/divider.c:298:1: warning: 'static' ignored on this declaration [-Wmissing-declarations] static struct clk_div_table ^ drivers/clk/ti/divider.c:299:9: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int] __init *ti_clk_get_div_table(struct device_node *node) ~~ ^ drivers/clk/ti/divider.c:345:9: warning: incompatible pointer types returning 'struct clk_div_table *' from a function with result type 'int *' [-Wincompatible-pointer-types] return table; ^ drivers/clk/ti/divider.c:419:9: warning: incompatible pointer types assigning to 'const struct clk_div_table *' from 'int *' [-Wincompatible-pointer-types] *table = ti_clk_get_div_table(node); ^ ~~ 3 warnings and 2 errors generated. By convention, most of the kernel code puts section attributes between the return type and function name. In the case where the return type is a pointer, it's important to place the '*' on left of the __init. This updated code works for both gcc and clang. Signed-off-by: Behan Webster beh...@converseincode.com Reviewed-by: Mark Charlebois charl...@gmail.com makes sense to me: Reviewed-by: Felipe Balbi ba...@ti.com I wonder if we should add this a Sparse or Coccinelle rule. -- balbi signature.asc Description: Digital signature
Re: [PATCH] clk, ti, LLVMLinux: Move __init outside of type definition
On 09/26/14 17:55, Felipe Balbi wrote: On Fri, Sep 26, 2014 at 05:31:48PM -0700, Behan Webster wrote: As written, the __init for ti_clk_get_div_table is in the middle of the return type. The gcc documentation indicates that section attributes should be added to the end of the function declaration: extern void foobar (void) __attribute__ ((section (bar))); However gcc seems to be very permissive with where attributes can be placed. clang on the other hand isn't so permissive, and fails if you put the section definition in the middle of the return type: drivers/clk/ti/divider.c:298:28: error: expected ';' after struct static struct clk_div_table ^ ; drivers/clk/ti/divider.c:298:1: warning: 'static' ignored on this declaration [-Wmissing-declarations] static struct clk_div_table ^ drivers/clk/ti/divider.c:299:9: error: type specifier missing, defaults to 'int' [-Werror,-Wimplicit-int] __init *ti_clk_get_div_table(struct device_node *node) ~~ ^ drivers/clk/ti/divider.c:345:9: warning: incompatible pointer types returning 'struct clk_div_table *' from a function with result type 'int *' [-Wincompatible-pointer-types] return table; ^ drivers/clk/ti/divider.c:419:9: warning: incompatible pointer types assigning to 'const struct clk_div_table *' from 'int *' [-Wincompatible-pointer-types] *table = ti_clk_get_div_table(node); ^ ~~ 3 warnings and 2 errors generated. By convention, most of the kernel code puts section attributes between the return type and function name. In the case where the return type is a pointer, it's important to place the '*' on left of the __init. This updated code works for both gcc and clang. Signed-off-by: Behan Webster beh...@converseincode.com Reviewed-by: Mark Charlebois charl...@gmail.com makes sense to me: Reviewed-by: Felipe Balbi ba...@ti.com Thank you. I wonder if we should add this a Sparse or Coccinelle rule. +1 I'm hoping it can be added to checkpatch as well. Behan -- Behan Webster beh...@converseincode.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
[PATCH 0/2] LLVMLinux: Patches to enable the kernel to be compiled with clang/LLVM
Replace the use of nested functions where a normal function will suffice. Nested functions are not liked by upstream kernel developers in general. Their use breaks the use of clang as a compiler, and doesn't make the code any better. This code now works for both gcc and clang. The LLVMLinux project aims to fully build the Linux kernel using both gcc and clang (the C front end for the LLVM compiler infrastructure project). Behan Webster (2): arm, fbdev, omap2, LLVMLinux: Remove nested function from omap2 dss arm, fbdev, omap2, LLVMLinux: Remove nested function from omapfb drivers/video/fbdev/omap2/dss/dispc-compat.c | 9 + drivers/video/fbdev/omap2/dss/manager-sysfs.c | 16 +--- drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 14 +++--- 3 files changed, 21 insertions(+), 18 deletions(-) -- 1.9.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 1/2] arm, fbdev, omap2, LLVMLinux: Remove nested function from omap2 dss
Replace the use of nested functions where a normal function will suffice.
Nested functions are not liked by upstream kernel developers in general. Their
use breaks the use of clang as a compiler, and doesn't make the code any
better.
This code now works for both gcc and clang.
Signed-off-by: Behan Webster beh...@converseincode.com
Suggested-by: Arnd Bergmann a...@arndb.de
Cc: Arnd Bergmann a...@arndb.de
---
drivers/video/fbdev/omap2/dss/dispc-compat.c | 9 +
drivers/video/fbdev/omap2/dss/manager-sysfs.c | 16 +---
2 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/video/fbdev/omap2/dss/dispc-compat.c
b/drivers/video/fbdev/omap2/dss/dispc-compat.c
index 83779c2..633c461 100644
--- a/drivers/video/fbdev/omap2/dss/dispc-compat.c
+++ b/drivers/video/fbdev/omap2/dss/dispc-compat.c
@@ -634,13 +634,14 @@ void dispc_mgr_disable_sync(enum omap_channel channel)
WARN_ON(1);
}
+static inline void dispc_irq_wait_handler(void *data, u32 mask)
+{
+ complete((struct completion *)data);
+}
+
int omap_dispc_wait_for_irq_interruptible_timeout(u32 irqmask,
unsigned long timeout)
{
- void dispc_irq_wait_handler(void *data, u32 mask)
- {
- complete((struct completion *)data);
- }
int r;
DECLARE_COMPLETION_ONSTACK(completion);
diff --git a/drivers/video/fbdev/omap2/dss/manager-sysfs.c
b/drivers/video/fbdev/omap2/dss/manager-sysfs.c
index 37b59fe..a7414fb 100644
--- a/drivers/video/fbdev/omap2/dss/manager-sysfs.c
+++ b/drivers/video/fbdev/omap2/dss/manager-sysfs.c
@@ -44,6 +44,13 @@ static ssize_t manager_display_show(struct
omap_overlay_manager *mgr, char *buf)
dssdev-name : none);
}
+static int manager_display_match(struct omap_dss_device *dssdev, void *data)
+{
+ const char *str = data;
+
+ return sysfs_streq(dssdev-name, str);
+}
+
static ssize_t manager_display_store(struct omap_overlay_manager *mgr,
const char *buf, size_t size)
{
@@ -52,17 +59,12 @@ static ssize_t manager_display_store(struct
omap_overlay_manager *mgr,
struct omap_dss_device *dssdev = NULL;
struct omap_dss_device *old_dssdev;
- int match(struct omap_dss_device *dssdev, void *data)
- {
- const char *str = data;
- return sysfs_streq(dssdev-name, str);
- }
-
if (buf[size-1] == '\n')
--len;
if (len 0)
- dssdev = omap_dss_find_device((void *)buf, match);
+ dssdev = omap_dss_find_device((void *)buf,
+ manager_display_match);
if (len 0 dssdev == NULL)
return -EINVAL;
--
1.9.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 2/2] arm, fbdev, omap2, LLVMLinux: Remove nested function from omapfb
Replace the use of nested functions where a normal function will suffice.
Nested functions are not liked by upstream kernel developers in general. Their
use breaks the use of clang as a compiler, and doesn't make the code any
better.
This code now works for both gcc and clang.
Signed-off-by: Behan Webster beh...@converseincode.com
Suggested-by: Arnd Bergmann a...@arndb.de
Cc: Arnd Bergmann a...@arndb.de
---
drivers/video/fbdev/omap2/omapfb/omapfb-main.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
index ec2d132..1587243 100644
--- a/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/fbdev/omap2/omapfb/omapfb-main.c
@@ -273,16 +273,16 @@ static struct omapfb_colormode omapfb_colormodes[] = {
},
};
+static bool cmp_component(struct fb_bitfield *f1, struct fb_bitfield *f2)
+{
+ return f1-length == f2-length
+ f1-offset == f2-offset
+ f1-msb_right == f2-msb_right;
+}
+
static bool cmp_var_to_colormode(struct fb_var_screeninfo *var,
struct omapfb_colormode *color)
{
- bool cmp_component(struct fb_bitfield *f1, struct fb_bitfield *f2)
- {
- return f1-length == f2-length
- f1-offset == f2-offset
- f1-msb_right == f2-msb_right;
- }
-
if (var-bits_per_pixel == 0 ||
var-red.length == 0 ||
var-blue.length == 0 ||
--
1.9.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
