Re: [PATCHv10 01/41] clk: add support for platform specific clock I/O wrapper functions
On 12/15/2013 02:48 AM, Mike Turquette wrote:
Quoting Tero Kristo (2013-11-26 00:05:42)
Current clock wrappers assume simple and direct mapped hardware register
access. Improve this support by adding functionality for registering
platform specific clock I/O wrappers, which can be used to support
various features needed like endianess conversions, indexed regmap support,
etc. Default I/O wrapper provided also which uses the existing direct
I/O mapped behavior.
Signed-off-by: Tero Kristo t-kri...@ti.com
There is a separate discussion on removing regmap for reading omap clk
registers. I guess this patch is not needed in that case?
Actually, this is still needed, as I need to map the clocks according to
their parent nodes.
-Tero
Regards,
Mike
---
drivers/clk/clk.c| 68 ++
include/linux/clk-provider.h | 15 +-
2 files changed, 75 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 2cf2ea6..c331386 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -34,6 +34,74 @@ static HLIST_HEAD(clk_root_list);
static HLIST_HEAD(clk_orphan_list);
static LIST_HEAD(clk_notifier_list);
+/**
+ * clk_readl_default - default clock register read support function
+ * @reg: register to read
+ *
+ * Default implementation for reading a clock register.
+ */
+static u32 clk_readl_default(u32 __iomem *reg)
+{
+ return readl(reg);
+}
+
+/**
+ * clk_writel_default - default clock register write support function
+ * @val: value to write
+ * @reg: register to write to
+ *
+ * Default implementation for writing a clock register.
+ */
+static void clk_writel_default(u32 val, u32 __iomem *reg)
+{
+ writel(val, reg);
+}
+
+struct clk_reg_ops clk_reg_ops_default = {
+ .clk_readl = clk_readl_default,
+ .clk_writel = clk_writel_default
+};
+
+static struct clk_reg_ops *clk_reg_ops = clk_reg_ops_default;
+
+/**
+ * clk_register_reg_ops - register access functions for clock registers
+ * @ops: register level ops
+ *
+ * Registers platform or SoC specific operations for reading / writing
+ * clock registers.
+ */
+int clk_register_reg_ops(struct clk_reg_ops *ops)
+{
+ if (!ops)
+ return -EINVAL;
+ clk_reg_ops = ops;
+ return 0;
+}
+
+/**
+ * clk_readl - read a clock register value from hardware
+ * @reg: register to read
+ *
+ * Uses the registered clk_reg_ops to read a hardware clock register value.
+ */
+u32 clk_readl(u32 __iomem *reg)
+{
+ return clk_reg_ops-clk_readl(reg);
+}
+
+/**
+ * clk_writel - write a clock register value to hardware
+ * @val: value to write
+ * @reg: register to write
+ *
+ * Uses the registered clk_reg_ops to write a hardware clock register value.
+ */
+void clk_writel(u32 val, u32 __iomem *reg)
+{
+ clk_reg_ops-clk_writel(val, reg);
+}
+
/*** locking ***/
static void clk_prepare_lock(void)
{
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 7e59253..16e4df2 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -512,15 +512,14 @@ static inline const char *of_clk_get_parent_name(struct
device_node *np,
* for improved portability across platforms
*/
-static inline u32 clk_readl(u32 __iomem *reg)
-{
- return readl(reg);
-}
+struct clk_reg_ops {
+ u32 (*clk_readl)(u32 __iomem *reg);
+ void (*clk_writel)(u32 val, u32 __iomem *reg);
+};
-static inline void clk_writel(u32 val, u32 __iomem *reg)
-{
- writel(val, reg);
-}
+u32 clk_readl(u32 __iomem *reg);
+void clk_writel(u32 val, u32 __iomem *reg);
+int clk_register_reg_ops(struct clk_reg_ops *ops);
#endif /* CONFIG_COMMON_CLK */
#endif /* CLK_PROVIDER_H */
--
1.7.9.5
--
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: [PATCHv10 00/41] ARM: TI SoC clock DT conversion
On 12/15/2013 06:35 AM, Mike Turquette wrote:
Quoting Tero Kristo (2013-11-26 00:05:41)
Hi,
Hi Tero,
Thanks for your long suffering patience on this series. The clock
patches look very good to me with exception of a few small comments. Let
me know how I can help with the hierarchal DT stuff since I think that
has been the gating factor for this series for the past few revisions.
Changes compared to v9:
- rebased on top of 3.13-rc1
- modified the low level clk register API to provide SoC specific clk_readl
and clk_writel support which can be registered during boot, TI SoC variant
uses regmap on low level
Regarding regmap, will that be dropped for V11? I don't care whether it
stays or goes but the approach you took is probably too top-level. Patch
#1 sets clk_reg_ops system-wide which probably isn't right. Different
clock drivers might compete to set those ops and the last one to write
wins.
I will be dropping regmap for v11. However...
A better approach is to support regmap ops on a per-clock basis (for
clocks that use the generic implementations like clk-divider and
clk-gate; obviously this is overkill for entirely hardware-specific
clocks). Stephen Boyd's approach is a better solution[1][2] but
unfortunately that approach dumps crap into struct clk_hw which is bad.
Anyways if you decide against regmap for V11 then the whole issue is
avoided.
Not avoided, some sort of solution is still needed to wrap the register
reads/writes. Alternatives are basically top level clk_ops or some stuff
like the patches you referred to, however it needs to be expanded to
support also the basic clock types.
-Tero
Regards,
Mike
[1] http://article.gmane.org/gmane.linux.ports.arm.kernel/273742
[2] http://article.gmane.org/gmane.linux.ports.arm.kernel/273744
- dropped regmap parameter from clock init calls, instead a helper is used
for getting regmap index along with the register offset from DT
- dropped regmap parameter from clock structs, instead platform specific
clk_readl / clk_writel are used to parse reg parameter according to
platform, for TI SoC:s, this is encoded as:
struct clk_omap_reg {
u16 offset; /* register offset */
u16 index; /* regmap index */
}
- Nishanth's comments to v9 mostly addressed, except for the CLK_OF_DECLARE
tweak which I would actually want some feedback upon, basically the problem
is I need to return status from the clk init functions so I can see if
-EAGAIN is passed, in which case init will be retried later, maybe some of
this can be made generic, like converting all the CLK_OF_DECLARE type
functions to return status
Testing done:
- omap3-beagle : boot + suspend/resume
- omap3-beagle-xm : boot (thanks to Nishanth)
- omap4-panda-es : boot + suspend/resume
- omap5-uevm : boot
- dra7-evm : boot
- am335x-bone : boot
Separate branches available at https://github.com/t-kristo/linux-pm.git
- full: 3.13-rc1-dt-clks-v10 (should be merged last, contains everything)
- clk driver only: 3.13-rc1-dt-clks-v10-for-mike
- DT data only: 3.13-rc1-dt-clks-v10-for-benoit
-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: [PATCHv10 10/41] CLK: TI: add support for clockdomain binding
On 12/15/2013 06:23 AM, Mike Turquette wrote:
Quoting Tero Kristo (2013-11-26 00:05:51)
Some OMAP clocks require knowledge about their parent clockdomain for
book keeping purposes. This patch creates a new DT binding for TI
clockdomains, which act as a collection of device clocks.
Signed-off-by: Tero Kristo t-kri...@ti.com
---
.../devicetree/bindings/clock/ti/clockdomain.txt | 21 ++
arch/arm/mach-omap2/clock.h|1 -
drivers/clk/ti/Makefile|3 +-
drivers/clk/ti/clockdomain.c | 70
include/linux/clk/ti.h |3 +
5 files changed, 96 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/ti/clockdomain.txt
create mode 100644 drivers/clk/ti/clockdomain.c
diff --git a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
new file mode 100644
index 000..45e6f7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
@@ -0,0 +1,21 @@
+Binding for Texas Instruments clockdomain.
+
+Binding status: Unstable - ABI compatibility may be broken in the future
+
+This binding uses the common clock binding[1]. Every clock on
The patch looks fine to me but I think that the binding description
should capture the fact that you are re-using the common clock binding
but that this binding definition does not define any new clocks or clock
controllers in the way that a typical clock binding would.
This code uses the 'clocks' property the same way that any other
consumer binding definition would, such as an MMC controller or UART.
Those bindings do not say that they are based on the common clock
binding AFAIK.
Ok, will modify the doc accordingly.
-Tero
Regards,
Mike
+TI SoC belongs to one clockdomain, but software only needs this
+information for specific clocks which require their parent
+clockdomain to be controlled when the clock is enabled/disabled.
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be ti,clockdomain
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of clocks within this domain
+
+Examples:
+ dss_clkdm: dss_clkdm {
+ compatible = ti,clockdomain;
+ clocks = dss1_alwon_fck_3430es2, dss_ick_3430es2;
+ };
diff --git a/arch/arm/mach-omap2/clock.h b/arch/arm/mach-omap2/clock.h
index bc0f9fc..6bd72b5 100644
--- a/arch/arm/mach-omap2/clock.h
+++ b/arch/arm/mach-omap2/clock.h
@@ -38,7 +38,6 @@ struct omap_clk {
}
struct clockdomain;
-#define to_clk_hw_omap(_hw) container_of(_hw, struct clk_hw_omap, hw)
#define DEFINE_STRUCT_CLK(_name, _parent_array_name, _clkops_name) \
static struct clk _name = { \
diff --git a/drivers/clk/ti/Makefile b/drivers/clk/ti/Makefile
index 7cba389..67056fb 100644
--- a/drivers/clk/ti/Makefile
+++ b/drivers/clk/ti/Makefile
@@ -1,4 +1,5 @@
ifneq ($(CONFIG_OF),)
obj-y += clk.o dpll.o autoidle.o divider.o \
- fixed-factor.o gate.o composite.o
+ fixed-factor.o gate.o clockdomain.o \
+ composite.o
endif
diff --git a/drivers/clk/ti/clockdomain.c b/drivers/clk/ti/clockdomain.c
new file mode 100644
index 000..f1e0038
--- /dev/null
+++ b/drivers/clk/ti/clockdomain.c
@@ -0,0 +1,70 @@
+/*
+ * OMAP clockdomain support
+ *
+ * Copyright (C) 2013 Texas Instruments, Inc.
+ *
+ * Tero Kristo t-kri...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed as is WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/slab.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/clk/ti.h
+
+#undef pr_fmt
+#define pr_fmt(fmt) %s: fmt, __func__
+
+static void __init of_ti_clockdomain_setup(struct device_node *node)
+{
+ struct clk *clk;
+ struct clk_hw *clk_hw;
+ const char *clkdm_name = node-name;
+ int i;
+ int num_clks;
+
+ num_clks = of_count_phandle_with_args(node, clocks, #clock-cells);
+
+ for (i = 0; i num_clks; i++) {
+ clk = of_clk_get(node, i);
+ if (__clk_get_flags(clk) CLK_IS_BASIC) {
+ pr_warn(can't setup clkdm for basic clk %s\n,
+ __clk_get_name(clk));
+ continue;
+ }
+ clk_hw
Re: [PATCH] omap: twl-common: Fix musb-hdrc device name.
Hi, On Friday 13 December 2013 11:06 PM, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [131213 03:57]: On Friday 13 December 2013 04:57 PM, Belisko Marek wrote: Kishon can you please comment on that? Would be possible to get your patch to 3.13 (I seen some comments from Felipe). I'm not sure as my patch modifies all the board files. There was initially some confusion w.r.t when the board files will be dropped. But since board files will still be there in 3.13, I'd recommend my patch [1] to be taken. Anyways if you have tested my patch (series), pls give your Tested-by. Tony, summary of the issue.. After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. So had to make the corresponding changes in board files. OK. Can you please repost with a proper commit id for what caused the regression and summararize why it should be fixed this way. Something like: Commit abcd1234 (usb: blah foo bar) caused blah blah blah. Fix the issue with blah blah blah. Note that the board-*.c files will be removed soon, but for v3.13 we still support both legacy booting and device tree based booting and need to fix it. huh.. I think we can have a much simpler fix. All this binding in board file was introduced to support platforms that has multiple PHYs of the same type. But musb/omap2430.c serves platforms that has only one PHY of a particular type. We can just go back to usb_get_phy(enum usb_phy_type type) instead of 'usb_get_phy_dev' in omap2430.c. Felipe, what do you think? Cheers Kishon Regards, Tony [1] - http://lists.scusting.com/index.php?t=msgth=375579start=0S=Google -- 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] cpufreq: omap: clk_round_rate() can return a zero upon error
On 10 December 2013 07:48, Paul Walmsley pwalms...@nvidia.com wrote: Treat both negative and zero return values from clk_round_rate() as errors. This is needed since subsequent patches will convert clk_round_rate()'s return value to be an unsigned type, rather than a signed type, since some clock sources can generate rates higher than (2^31)-1 Hz. Eventually, when calling clk_round_rate(), only a return value of zero will be considered a error. All other values will be considered valid rates. The comparison against values less than 0 is kept to preserve the correct behavior in the meantime. This patch also removes a bogus usage of IS_ERR_VALUE(), which is intended to be used only on combination pointer/error code return values; a side-benefit. Signed-off-by: Paul Walmsley pwalms...@nvidia.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Viresh Kumar viresh.ku...@linaro.org Acked-by: Viresh Kumar viresh.ku...@linaro.org -- 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: [RFCv4 06/11] misc: Introduce Nokia CMT driver
On Mon, Dec 16, 2013 at 12:27 AM, Sebastian Reichel s...@debian.org wrote:
Add driver handling GPIO pins of Nokia modems. The
driver provides reset notifications, so that SSI
clients can subscribe to them easily.
Signed-off-by: Sebastian Reichel s...@debian.org
If the driver provides reset notifications, should it rather be
in drivers/reset?
I'm thinking of a generic GPIO reset driver with a generic
notification mechanism, which seems to be what this is.
I.e. it doesn't look device-specific at all, just like some
generic glue code that could be useful to many such
scenarios.
+config NOKIA_CMT
+ tristate Enable CMT support
+ help
+ If you say Y here, you will enable CMT support.
+
+ If unsure, say Y, or else you will not be able to use the CMT.
None of this explains what this driver actually does and what
CMT means, so please rewrite this a bit to be more helpful.
The way it is written it could as well say enable FOO support.
+++ b/drivers/misc/nokia-cmt.c
@@ -0,0 +1,298 @@
+/*
+ * CMT support.
So CMT = ...?
+/**
+ * struct cmt_device - CMT device data
+ * @cmt_rst_ind_tasklet: Bottom half for CMT reset line events
+ * @cmt_rst_ind_irq: IRQ number of the CMT reset line
+ * @n_head: List of notifiers registered to get CMT events
+ * @node: Link on the list of available CMTs
+ * @device: Reference to the CMT platform device
+ */
+struct cmt_device {
+ struct tasklet_struct cmt_rst_ind_tasklet;
+ unsigned intcmt_rst_ind_irq;
+ struct atomic_notifier_head n_head;
+ struct list_headnode;
+ struct device *device;
+ struct cmt_gpio *gpios;
+ int gpio_amount;
+};
The kerneldoc and and the struct are not in sync. Look
this over.
+static LIST_HEAD(cmt_list);/* List of CMT devices */
(...)
+struct cmt_device *cmt_get(const char *name)
+{
+ struct cmt_device *p, *cmt = ERR_PTR(-ENODEV);
+
+ list_for_each_entry(p, cmt_list, node)
+ if (strcmp(name, dev_name(p-device)) == 0) {
+ cmt = p;
+ break;
+ }
+
+ return cmt;
+}
+EXPORT_SYMBOL_GPL(cmt_get);
Is this driver used on non-DT platforms, or can we skip this
struct device * referencing altogether?
I would feel better if this driver looked more like
drivers/mfd/syscon.c
+static irqreturn_t cmt_rst_ind_isr(int irq, void *cmtdev)
+{
+ struct cmt_device *cmt = (struct cmt_device *)cmtdev;
+
+ tasklet_schedule(cmt-cmt_rst_ind_tasklet);
+
+ return IRQ_HANDLED;
+}
Why are you using a tasklet rather than a work
for this?
Yours,
Linus Walleij
--
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: WG: [PATCH] usb: musb: omap2430: fix occasional musb breakage on boot
On Fri, Dec 13, 2013 at 6:27 PM, Andreas Naumann d...@andin.de wrote: On 13.12.2013 13:34, Grazvydas Ignotas wrote: Hmm I don't know about that, this would be inconsistent with what all other OMAP drivers do. Maybe we should do what musb_core.c does just Ok, thats cool. to be consistent and add a similar comment. Only the static variable could be avoided in favor of struct omap2430_glue member. Whats wrong with the static? Well besides minor memory wastage when the driver is compiled in but not used, you'd cause problems if TI makes a SoC with multiple musb instances. Yes this driver already contains global variables, but still we can avoid adding more easily. GraÅžvydas -- 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 13/26] ARM: omap3.dtsi: add omapdss information
On 2013-12-13 05:24, Laurent Pinchart wrote:
Then DPI, which I think is mostly just level shifters. It's really just
a port, as you say.
SDI is a bit unclear to me. The registers for it are in the dss_core.
There's only a few registers, but it does have a PHY and a PLL. But I
guess it's also more of a port than a separate module.
After a quick look at the documentation I would say so. I would be tempted to
consider RFBI as part of the DSS core, but that's less clear.
I had a look at this, mainly the DPI side so far. There's one extra
complication, which actually affects all other outputs also (and CDF):
pinctrl.
In the current series, I just have pinctrl for each device, with
default name, which ends up being used by default without any code on
my part.
However, if DPI is no longer a device, it can't have pinctrl entry. But
this is a wider issue, as the pinctrl should really be per endpoint, not
per device. When an endpoint is selected to be used, a particular
pinmuxing should be taken into use.
I'm not sure what would be the cleanest solution to this. I currently
have this working:
dss {
pinctrl-names = default-0-0;
pinctrl-0 = dss_dpi_pins;
port@0 {
dpi_out: endpoint {
remote-endpoint = tfp410_in;
data-lines = 24;
};
};
};
So here I have 'port@0' for DSS, which is the DPI output, and it has a
single endpoint. For DSS device, I have pinctrl data.
When the DPI endpoint is initialized, the code looks for pinctrl with
name default-portnum-endpointnum. As the DPI is port 0, and just
one endpoint, the code looks for default-0-0.
For omap3 board with both DPI and SDI as options (they can't be used at
the same time, though), I imagine it'd be like:
dss {
vdds_dsi-supply = vpll2;
vdds_sdi-supply = vpll2;
pinctrl-names = default-0-0, default-1-0;
pinctrl-0 = dss_dpi_pins;
pinctrl-1 = dss_sdi_pins;
ports {
#address-cells = 1;
#size-cells = 0;
port@0 {
reg = 0;
dpi_out: endpoint {
};
};
port@1 {
reg = 1;
sdi_out: endpoint {
};
};
};
};
Any thoughts?
Every time I work with ports/endpoints, I feel that this is needlessly
complex. But I have never come up with any cleaner or simpler way to
handle this.
I also think this multiple-peripherals-per-single-port is not really
display related, although, for some reason, it seems like display is the
most abused hardware. Maybe ports/endpoints or similar should be in the
common driver framework?
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCHv10 22/41] ARM: dts: omap5 clock data
On Tue, 26 Nov 2013, Tero Kristo wrote:
This patch creates a unique node for each clock in the OMAP5 power,
reset and clock manager (PRCM).
...
+cm_core_aon {
+ pad_clks_src_ck: pad_clks_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+ };
+
+ pad_clks_ck: pad_clks_ck {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = pad_clks_src_ck;
+ ti,bit-shift = 8;
+ reg = 0x0108;
+ };
All of the clock data should be underneath a clocks { node, for all of
the chips. Please see the Calxeda ECX clocks DT data as an example of how
this should look:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/ecx-common.dtsi#n141
- Paul
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv10 22/41] ARM: dts: omap5 clock data
On 12/16/2013 12:51 PM, Paul Walmsley wrote:
On Tue, 26 Nov 2013, Tero Kristo wrote:
This patch creates a unique node for each clock in the OMAP5 power,
reset and clock manager (PRCM).
...
+cm_core_aon {
+ pad_clks_src_ck: pad_clks_src_ck {
+ #clock-cells = 0;
+ compatible = fixed-clock;
+ clock-frequency = 1200;
+ };
+
+ pad_clks_ck: pad_clks_ck {
+ #clock-cells = 0;
+ compatible = ti,gate-clock;
+ clocks = pad_clks_src_ck;
+ ti,bit-shift = 8;
+ reg = 0x0108;
+ };
All of the clock data should be underneath a clocks { node, for all of
the chips. Please see the Calxeda ECX clocks DT data as an example of how
this should look:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/ecx-common.dtsi#n141
Any reason why?
Should be relatively trivial to change though, however I am not too sure
if this works:
core_core_aon {
clocks {
pad_clks_src_ck: ...
};
};
... as I want to modify nodes under the structure. Does it?
-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 2/5] phy: add support for indexed lookup
Hi,
On Monday 09 December 2013 08:38 PM, Heikki Krogerus wrote:
Removes the need for the consumer drivers requesting the
phys to provide name for the phy. This should ease the use
of the framework considerable when using only one phy, which
is usually the case when except with USB, but it can also
be useful with multiple phys.
If index has to be used with multiple PHYs, the controller should be aware of
the order in which it is populated in dt data. That's not good.
This will also reduce noise from the framework when there is
no phy by changing warnings to debug messages.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/phy-core.c | 106
++--
include/linux/phy/phy.h | 14 +++
2 files changed, 89 insertions(+), 31 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 1102aef..99dc046 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -53,7 +53,8 @@ static int devm_phy_match(struct device *dev, void *res,
void *match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *con_id)
+static struct phy *phy_lookup(struct device *device, const char *con_id,
+ unsigned int idx)
{
unsigned int count;
struct phy *phy;
@@ -67,6 +68,10 @@ static struct phy *phy_lookup(struct device *device, const
char *con_id)
count = phy-init_data-num_consumers;
consumers = phy-init_data-consumers;
while (count--) {
+ /* index must always match exactly */
+ if (!con_id)
+ if (idx != count)
+ continue;
if (!strcmp(consumers-dev_name, dev_name(device))
!strcmp(consumers-port, con_id)) {
class_dev_iter_exit(iter);
@@ -242,7 +247,8 @@ EXPORT_SYMBOL_GPL(phy_power_off);
/**
* of_phy_get() - lookup and obtain a reference to a phy by phandle
* @dev: device that requests this phy
- * @index: the index of the phy
+ * @con_id: name of the phy from device's point of view
+ * @idx: the index of the phy if name is not used
*
* Returns the phy associated with the given phandle value,
* after getting a refcount to it or -ENODEV if there is no such phy or
@@ -250,12 +256,20 @@ EXPORT_SYMBOL_GPL(phy_power_off);
* not yet loaded. This function uses of_xlate call back function provided
* while registering the phy_provider to find the phy instance.
*/
-static struct phy *of_phy_get(struct device *dev, int index)
+static struct phy *of_phy_get(struct device *dev, const char *con_id,
+ unsigned int idx)
{
int ret;
struct phy_provider *phy_provider;
struct phy *phy = NULL;
struct of_phandle_args args;
+ int index;
+
+ if (!con_id)
+ index = idx;
+ else
+ index = of_property_match_string(dev-of_node, phy-names,
+ con_id);
ret = of_parse_phandle_with_args(dev-of_node, phys, #phy-cells,
index, args);
@@ -348,38 +362,36 @@ struct phy *of_phy_simple_xlate(struct device *dev,
struct of_phandle_args
EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
/**
- * phy_get() - lookup and obtain a reference to a phy.
+ * phy_get_index() - obtain a phy based on index
NAK. It still takes a 'char' argument and the name is misleading.
Btw are you replacing phy_get() or adding a new API in addition to phy_get()?
* @dev: device that requests this phy
* @con_id: name of the phy from device's point of view
+ * @idx: index of the phy to obtain in the consumer
*
- * Returns the phy driver, after getting a refcount to it; or
- * -ENODEV if there is no such phy. The caller is responsible for
- * calling phy_put() to release that count.
+ * This variant of phy_get() allows to access PHYs other than the first
+ * defined one for functions that define several PHYs.
*/
-struct phy *phy_get(struct device *dev, const char *con_id)
+struct phy *phy_get_index(struct device *dev, const char *con_id,
+ unsigned int idx)
{
- int index = 0;
struct phy *phy = NULL;
- if (con_id == NULL) {
- dev_WARN(dev, missing string\n);
- return ERR_PTR(-EINVAL);
+ if (dev-of_node) {
+ dev_dbg(dev, using device tree for PHY lookup\n);
+ phy = of_phy_get(dev, con_id, idx);
}
- if (dev-of_node) {
- index = of_property_match_string(dev-of_node, phy-names,
- con_id);
- phy = of_phy_get(dev, index);
- if (IS_ERR(phy)) {
- dev_err(dev, unable to find phy\n);
-
Re: [PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy
Hi,
On Monday 09 December 2013 08:38 PM, Heikki Krogerus wrote:
Provide a complete association for the phy and it's user
(musb) with the new phy_lookup_table.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
arch/arm/mach-omap2/twl-common.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index b0d54da..972430b 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
-};
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
+static struct phy_lookup_table twl4030_usb_lookup = {
+ .dev_id = musb-hdrc.0,
+ .table = PHY_LOOKUP(phy-twl4030_usb.0, NULL),
};
had a similar approach during the initial version of phy framework [1] (see
phy_bind) but changed it later [2] . Here you should know the device names of
two devices and even if one of them started using DEVID_AUTO, it'll start
breaking. Such an approach needs to reviewed carefully.
[1] - https://lkml.org/lkml/2013/4/3/258
[2] - http://www.spinics.net/lists/linux-usb/msg85299.html (removed phy_bind)
Cheers
Kishon
static struct twl4030_usb_data omap3_usb_pdata = {
.usb_mode = T2_USB_MODE_ULPI,
- .init_data = init_data,
};
static int omap3_batt_table[] = {
@@ -225,8 +220,10 @@ void __init omap3_pmic_get_config(struct
twl4030_platform_data *pmic_data,
}
/* Common platform data configurations */
- if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb)
+ if (pdata_flags TWL_COMMON_PDATA_USB !pmic_data-usb) {
+ phy_add_lookup_table(twl4030_usb_lookup);
pmic_data-usb = omap3_usb_pdata;
+ }
if (pdata_flags TWL_COMMON_PDATA_BCI !pmic_data-bci)
pmic_data-bci = omap3_bci_pdata;
--
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 v6 1/3] mmc: omap_hsmmc: Enable SDIO IRQ.
For now, only support SDIO interrupt if we are booted with
DT. This is because some platforms need special quirks. And
we don't want to add new legacy mux platform init code
callbacks any longer as we are moving to DT based booting
anyways.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 109
include/linux/platform_data/mmc-omap.h |1 +
2 files changed, 97 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8be5c9f..c197028 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -131,6 +131,7 @@ static void apply_clk_hack(struct device *dev)
#define TC_EN (1 1)
#define BWR_EN (1 4)
#define BRR_EN (1 5)
+#define CIRQ_EN(1 8)
#define ERR_EN (1 15)
#define CTO_EN (1 16)
#define CCRC_EN(1 17)
@@ -215,6 +216,9 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int flags;
+#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+
struct omap_hsmmc_next next_data;
struct omap_mmc_platform_data *pdata;
};
@@ -495,27 +499,40 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
{
- unsigned int irq_mask;
+ u32 irq_mask = INT_EN_MASK;
+ unsigned long flags;
if (host-use_dma)
- irq_mask = INT_EN_MASK ~(BRR_EN | BWR_EN);
- else
- irq_mask = INT_EN_MASK;
+ irq_mask = ~(BRR_EN | BWR_EN);
/* Disable timeout for erases */
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_EN;
+ spin_lock_irqsave(host-irq_lock, flags);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* latch pending CIRQ, but don't signal */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
static void omap_hsmmc_disable_irq(struct omap_hsmmc_host *host)
{
- OMAP_HSMMC_WRITE(host-base, ISE, 0);
- OMAP_HSMMC_WRITE(host-base, IE, 0);
+ u32 irq_mask = 0;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ /* no transfer running, need to signal cirq if enabled */
+ if (host-flags HSMMC_SDIO_IRQ_ENABLED)
+ irq_mask |= CIRQ_EN;
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+ OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
+ spin_unlock_irqrestore(host-irq_lock, flags);
}
/* Calculate divisor for the given clock frequency */
@@ -1078,8 +1095,12 @@ static irqreturn_t omap_hsmmc_irq(int irq, void *dev_id)
int status;
status = OMAP_HSMMC_READ(host-base, STAT);
- while (status INT_EN_MASK host-req_in_progress) {
- omap_hsmmc_do_irq(host, status);
+ while (status (INT_EN_MASK | CIRQ_EN)) {
+ if (host-req_in_progress)
+ omap_hsmmc_do_irq(host, status);
+
+ if (status CIRQ_EN)
+ mmc_signal_sdio_irq(host-mmc);
/* Flush posted write */
status = OMAP_HSMMC_READ(host-base, STAT);
@@ -1591,6 +1612,37 @@ static void omap_hsmmc_init_card(struct mmc_host *mmc,
struct mmc_card *card)
mmc_slot(host).init_card(card);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+ u32 irq_mask;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+
+ irq_mask = OMAP_HSMMC_READ(host-base, ISE);
+ if (enable) {
+ host-flags |= HSMMC_SDIO_IRQ_ENABLED;
+ irq_mask |= CIRQ_EN;
+ } else {
+ host-flags = ~HSMMC_SDIO_IRQ_ENABLED;
+ irq_mask = ~CIRQ_EN;
+ }
+ OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
+
+ /*
+* if enable, piggy back detection on current request
+* but always disable immediately
+*/
+ if (!host-req_in_progress || !enable)
+ OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
+
+ /* flush posted write */
+ OMAP_HSMMC_READ(host-base, IE);
+
+ spin_unlock_irqrestore(host-irq_lock, flags);
+}
+
static void omap_hsmmc_conf_bus_power(struct omap_hsmmc_host *host)
{
u32 hctl, capa, value;
@@ -1643,7 +1695,7 @@ static const struct mmc_host_ops omap_hsmmc_ops = {
[PATCH v6 2/3] mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x.
The am335x can't detect pending cirq in PM runtime suspend. This
patch reconfigures dat1 as a GPIO before going to suspend. SDIO
interrupts are detected with the GPIO, the GPIO will only wake
the module from suspend, SDIO irq detection will still happen
through the IP block.
Idea of remuxing the pins by Tony Lindgren as well as the implementation
of omap_hsmmc_pin_init.
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
.../devicetree/bindings/mmc/ti-omap-hsmmc.txt | 50 ++
drivers/mmc/host/omap_hsmmc.c | 184 ++--
2 files changed, 222 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index 8c8908a..8e1195e 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -55,3 +55,53 @@ Examples:
edma 25;
dma-names = tx, rx;
};
+
+[workaround for missing swakeup on am33xx]
+
+This SOC is missing the swakeup line, it will not detect SDIO irq
+while in suspend.
+
+ --
+ | PRCM |
+ --
+ ^ |
+ swakeup | | fclk
+ | v
+ ----- -
+ | card | -- CIRQ -- | hsmmc | -- IRQ -- | CPU |
+ ----- -
+
+In suspend the fclk is off and the module is disfunctional. Even
+register reads will fail. A small logic in the host will request
+fclk restore, when an external event is detected. Once the clock
+is restored, the host detects the event normally. Since am33xx
+doesn't have this line it never wakes from suspend.
+
+The workaround is to reconfigure the dat1 line as a GPIO upon
+suspend. To make this work, we need to set 1) the named pinctrl
+states default, active and idle, 2) the gpio detecting
+sdio irq in suspend and 3) compatibe section, see example below.
+The MMC driver will then toggle between active and idle during
+the runtime. If configuration is incomplete, a warning message is
+emitted falling back to polling. Mind not every application
+needs SDIO irq, e.g. MMC cards Affected chips are am335x,
+probably others
+
+
+ mmc1: mmc@48060100 {
+ compatible = ti,am33xx-hsmmc;
+ ...
+ interrupts-extended = intc 64 gpio2 28 0;
+ ...
+ pinctrl-names = default, active, idle
+ pinctrl-0 = mmc1_pins;
+ pinctrl-1 = mmc1_pins;
+ pinctrl-2 = mmc1_cirq_pin;
+ ...
+ };
+
+ mmc1_cirq_pin: pinmux_cirq_pin {
+ pinctrl-single,pins =
+ 0x0f8 0x3f /* GPIO2_28 */
+ ;
+ };
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index c197028..bb01d86 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -29,6 +29,7 @@
#include linux/timer.h
#include linux/clk.h
#include linux/of.h
+#include linux/of_irq.h
#include linux/of_gpio.h
#include linux/of_device.h
#include linux/omap-dma.h
@@ -36,6 +37,7 @@
#include linux/mmc/core.h
#include linux/mmc/mmc.h
#include linux/io.h
+#include linux/irq.h
#include linux/gpio.h
#include linux/regulator/consumer.h
#include linux/pinctrl/consumer.h
@@ -206,6 +208,7 @@ struct omap_hsmmc_host {
u32 sysctl;
u32 capa;
int irq;
+ int gpio_sdio_irq;
int use_dma, dma_ch;
struct dma_chan *tx_chan;
struct dma_chan *rx_chan;
@@ -218,11 +221,32 @@ struct omap_hsmmc_host {
int req_in_progress;
int flags;
#define HSMMC_SDIO_IRQ_ENABLED (1 0)/* SDIO irq enabled */
+#define HSMMC_SWAKEUP_QUIRK(1 1)
+#define HSMMC_CIRQ_GPIO_ENABLED (1 2)
struct omap_hsmmc_next next_data;
+ struct pinctrl *pinctrl;
+ struct pinctrl_state*fixed, *active, *idle;
struct omap_mmc_platform_data *pdata;
};
+static irqreturn_t omap_hsmmc_cirq(int irq, void *dev_id)
+{
+ struct omap_hsmmc_host *host = dev_id;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-irq_lock, flags);
+ if (host-flags HSMMC_CIRQ_GPIO_ENABLED) {
+ disable_irq_nosync(host-gpio_sdio_irq);
+ host-flags = ~HSMMC_CIRQ_GPIO_ENABLED;
+ }
+ spin_unlock_irqrestore(host-irq_lock, flags);
+
+ pm_request_resume(host-dev); /* no use counter */
+
+ return IRQ_HANDLED;
+}
+
static int omap_hsmmc_card_detect(struct device *dev, int slot)
{
struct omap_hsmmc_host *host = dev_get_drvdata(dev);
@@ -476,6 +500,67
[PATCH v6 3/3] mmc: omap_hsmmc: Extend debugfs for SDIO IRQ, GPIO and pinmux.
Add SDIO IRQ entries to debugfs entry. Note that PSTATE shows current
state of data lines, incl. SDIO IRQ pending
Signed-off-by: Andreas Fenkart afenk...@gmail.com
---
drivers/mmc/host/omap_hsmmc.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index bb01d86..1037b7d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -82,6 +82,7 @@ static void apply_clk_hack(struct device *dev)
#define OMAP_HSMMC_RSP54 0x0118
#define OMAP_HSMMC_RSP76 0x011C
#define OMAP_HSMMC_DATA0x0120
+#define OMAP_HSMMC_PSTATE 0x0124
#define OMAP_HSMMC_HCTL0x0128
#define OMAP_HSMMC_SYSCTL 0x012C
#define OMAP_HSMMC_STAT0x0130
@@ -1789,14 +1790,24 @@ static int omap_hsmmc_regs_show(struct seq_file *s,
void *data)
{
struct mmc_host *mmc = s-private;
struct omap_hsmmc_host *host = mmc_priv(mmc);
+ bool suspended;
- seq_printf(s, mmc%d:\n ctx_loss:\t%d\n\nregs:\n,
- mmc-index, host-context_loss);
- pm_runtime_get_sync(host-dev);
+ seq_printf(s, mmc%d:\n, mmc-index);
+ seq_printf(s, sdio irq\t%s\n, ((host-flags HSMMC_SDIO_IRQ_ENABLED)
+? enabled : disabled));
+ suspended = host-dev-power.runtime_status != RPM_ACTIVE;
+ if (host-flags HSMMC_SWAKEUP_QUIRK)
+ seq_printf(s, pinmux config\t%s\n, (suspended ?
+ gpio : sdio));
+ seq_printf(s, ctx_loss:\t%d\n, host-context_loss);
+ pm_runtime_get_sync(host-dev);
+ seq_puts(s, \nregs:\n);
seq_printf(s, CON:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, CON));
+ seq_printf(s, PSTATE:\t\t0x%08x\n,
+ OMAP_HSMMC_READ(host-base, PSTATE));
seq_printf(s, HCTL:\t\t0x%08x\n,
OMAP_HSMMC_READ(host-base, HCTL));
seq_printf(s, SYSCTL:\t\t0x%08x\n,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv4 06/11] misc: Introduce Nokia CMT driver
Hi Linus,
On Mon, Dec 16, 2013 at 10:48:06AM +0100, Linus Walleij wrote:
On Mon, Dec 16, 2013 at 12:27 AM, Sebastian Reichel s...@debian.org wrote:
Add driver handling GPIO pins of Nokia modems. The
driver provides reset notifications, so that SSI
clients can subscribe to them easily.
Signed-off-by: Sebastian Reichel s...@debian.org
If the driver provides reset notifications, should it rather be
in drivers/reset?
I'm thinking of a generic GPIO reset driver with a generic
notification mechanism, which seems to be what this is.
I.e. it doesn't look device-specific at all, just like some
generic glue code that could be useful to many such
scenarios.
I like the idea.
Probably the remaining gpio exporting code can be converted into
some generic gpio-sysfs-export driver as well.
What do you think about the following?
/*
* driver, which provides generic reset notifications
*/
cmt_reset: reset-notifier {
compatible = linux,reset-notification;
interrupts = gpio;
};
/*
* driver, which exports the specified gpios in sysfs with the
* supplied names. The device will be named according to the
* label
*/
cmt_gpios: gpio-sysfs-export {
compatible = linux,gpio-sysfs-export;
label = nokia-cmt;
gpios = A, B, ...;
gpio-names = A, B, ...;
};
+config NOKIA_CMT
+ tristate Enable CMT support
+ help
+ If you say Y here, you will enable CMT support.
+
+ If unsure, say Y, or else you will not be able to use the CMT.
None of this explains what this driver actually does and what
CMT means, so please rewrite this a bit to be more helpful.
The way it is written it could as well say enable FOO support.
I probably should have reviewed this better. This is the original
text from Nokia's driver.
+++ b/drivers/misc/nokia-cmt.c
@@ -0,0 +1,298 @@
+/*
+ * CMT support.
So CMT = ...?
CMT = Cellular Modem
+/**
+ * struct cmt_device - CMT device data
+ * @cmt_rst_ind_tasklet: Bottom half for CMT reset line events
+ * @cmt_rst_ind_irq: IRQ number of the CMT reset line
+ * @n_head: List of notifiers registered to get CMT events
+ * @node: Link on the list of available CMTs
+ * @device: Reference to the CMT platform device
+ */
+struct cmt_device {
+ struct tasklet_struct cmt_rst_ind_tasklet;
+ unsigned intcmt_rst_ind_irq;
+ struct atomic_notifier_head n_head;
+ struct list_headnode;
+ struct device *device;
+ struct cmt_gpio *gpios;
+ int gpio_amount;
+};
The kerneldoc and and the struct are not in sync. Look
this over.
I will fix this in v5 (in case that its not removed completly).
+static LIST_HEAD(cmt_list);/* List of CMT devices */
(...)
+struct cmt_device *cmt_get(const char *name)
+{
+ struct cmt_device *p, *cmt = ERR_PTR(-ENODEV);
+
+ list_for_each_entry(p, cmt_list, node)
+ if (strcmp(name, dev_name(p-device)) == 0) {
+ cmt = p;
+ break;
+ }
+
+ return cmt;
+}
+EXPORT_SYMBOL_GPL(cmt_get);
Is this driver used on non-DT platforms, or can we skip this
struct device * referencing altogether?
I would feel better if this driver looked more like
drivers/mfd/syscon.c
Will be removed in v5.
+static irqreturn_t cmt_rst_ind_isr(int irq, void *cmtdev)
+{
+ struct cmt_device *cmt = (struct cmt_device *)cmtdev;
+
+ tasklet_schedule(cmt-cmt_rst_ind_tasklet);
+
+ return IRQ_HANDLED;
+}
Why are you using a tasklet rather than a work
for this?
No particular reason. I just took this over from Nokia's code.
-- Sebastian
signature.asc
Description: Digital signature
Re: [RFCv4 06/11] misc: Introduce Nokia CMT driver
On Mon, Dec 16, 2013 at 1:15 PM, Sebastian Reichel s...@debian.org wrote:
On Mon, Dec 16, 2013 at 10:48:06AM +0100, Linus Walleij wrote:
I.e. it doesn't look device-specific at all, just like some
generic glue code that could be useful to many such
scenarios.
I like the idea.
Probably the remaining gpio exporting code can be converted into
some generic gpio-sysfs-export driver as well.
I am very reluctant in letting device trees specify exports of GPIOs
to userspace, not so much because it's Linux-specific but for
the fact that people are doing things in userspace that should not
be done in userspace.
Last time it was proposed I asked to the specific usecase,
exactly why userspace needed this handle on a physical
GPIO line, and why it can't use another userspace interface
(example: leds, keys etc.)
What do you think about the following?
/*
* driver, which provides generic reset notifications
*/
cmt_reset: reset-notifier {
compatible = linux,reset-notification;
interrupts = gpio;
};
Looks good to me.
/*
* driver, which exports the specified gpios in sysfs with the
* supplied names. The device will be named according to the
* label
*/
cmt_gpios: gpio-sysfs-export {
compatible = linux,gpio-sysfs-export;
label = nokia-cmt;
gpios = A, B, ...;
gpio-names = A, B, ...;
};
Please follow the discussion on this topic:
http://marc.info/?l=linux-gpiom=138201170431416w=2
Why are you using a tasklet rather than a work
for this?
No particular reason. I just took this over from Nokia's code.
Can you try to use a work instead?
Yours,
Linus Walleij
--
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 13/26] ARM: omap3.dtsi: add omapdss information
Hi Tomi,
On Monday 16 December 2013 12:49:03 Tomi Valkeinen wrote:
On 2013-12-13 05:24, Laurent Pinchart wrote:
Then DPI, which I think is mostly just level shifters. It's really just
a port, as you say.
SDI is a bit unclear to me. The registers for it are in the dss_core.
There's only a few registers, but it does have a PHY and a PLL. But I
guess it's also more of a port than a separate module.
After a quick look at the documentation I would say so. I would be tempted
to consider RFBI as part of the DSS core, but that's less clear.
I had a look at this, mainly the DPI side so far. There's one extra
complication, which actually affects all other outputs also (and CDF):
pinctrl.
In the current series, I just have pinctrl for each device, with
default name, which ends up being used by default without any code on
my part.
However, if DPI is no longer a device, it can't have pinctrl entry. But
this is a wider issue, as the pinctrl should really be per endpoint, not
per device. When an endpoint is selected to be used, a particular
pinmuxing should be taken into use.
I'm not sure what would be the cleanest solution to this. I currently
have this working:
dss {
pinctrl-names = default-0-0;
pinctrl-0 = dss_dpi_pins;
port@0 {
dpi_out: endpoint {
remote-endpoint = tfp410_in;
data-lines = 24;
};
};
};
So here I have 'port@0' for DSS, which is the DPI output, and it has a
single endpoint. For DSS device, I have pinctrl data.
When the DPI endpoint is initialized, the code looks for pinctrl with
name default-portnum-endpointnum. As the DPI is port 0, and just
one endpoint, the code looks for default-0-0.
For omap3 board with both DPI and SDI as options (they can't be used at
the same time, though), I imagine it'd be like:
dss {
vdds_dsi-supply = vpll2;
vdds_sdi-supply = vpll2;
pinctrl-names = default-0-0, default-1-0;
pinctrl-0 = dss_dpi_pins;
pinctrl-1 = dss_sdi_pins;
ports {
#address-cells = 1;
#size-cells = 0;
port@0 {
reg = 0;
dpi_out: endpoint {
};
};
port@1 {
reg = 1;
sdi_out: endpoint {
};
};
};
};
Any thoughts?
Would it be feasible to put the pinctrl properties in the port or endpoint
nodes ? That could require changes to the pinctrl core, most probably just
exporting a few internal functions (possibly requiring a bit of refactoring),
but it might make the result simpler.
Every time I work with ports/endpoints, I feel that this is needlessly
complex. But I have never come up with any cleaner or simpler way to
handle this.
I also think this multiple-peripherals-per-single-port is not really
display related, although, for some reason, it seems like display is the
most abused hardware. Maybe ports/endpoints or similar should be in the
common driver framework?
Ports and endpoints is the way we have come up with to describe a graph in DT.
I wouldn't call it needlessly complex, as I believe it's both generic and
simple, but I agree it's a bit on the verbose side. Omitting the ports and
port nodes as a shortcut might be a good way to reduce the verbosity.
Regarding moving this to the device core, I'm not opposed to it, but I'd like
to see interest from other users first.
--
Regards,
Laurent Pinchart
signature.asc
Description: This is a digitally signed message part.
Re: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
Hi Tony,
On 12/13/13 21:22, Tony Lindgren wrote:
This adds support for CompuLab SBC-T3530, also known as cm-t3730:
http://compulab.co.il/products/sbcs/sbc-t3530/
It seems that with the sbc-3xxx mainboard is also used on
SBC-T3517 and SBC-T3730 with just a different CPU module:
http://compulab.co.il/products/sbcs/sbc-t3517/
http://compulab.co.il/products/sbcs/sbc-t3730/
So let's add a common omap3-sb-t35.dtsi and then separate SoC
specific omap3-sbc-t3730.dts, omap3-sbc-t3530.dts and
omap3-sbc-t3517.dts.
I've tested this with SBC-T3730 as that's the only one I have.
At least serial, both Ethernet controllers, MMC, and wl12xx WLAN
work.
Note that WLAN seems to be different for SBC-T3530.
Yes, it is Marvell 8686 chipset using the libertas driver.
And SBC-T3517
may need some changes for the EMAC Ethernet if that's used
instead of the smsc911x.
Cc: devicet...@vger.kernel.org
Cc: Igor Grinberg grinb...@compulab.co.il
Cc: Mike Rapoport m...@compulab.co.il
Signed-off-by: Tony Lindgren t...@atomide.com
Great job!
I'm sorry I couldn't make it in time with the conversion... :-(
---
arch/arm/boot/dts/Makefile| 3 +
arch/arm/boot/dts/omap3-sb-t35.dtsi | 135
++
arch/arm/boot/dts/omap3-sbc-t3517.dts | 18 +
arch/arm/boot/dts/omap3-sbc-t3530.dts | 18 +
arch/arm/boot/dts/omap3-sbc-t3730.dts | 130
arch/arm/mach-omap2/pdata-quirks.c| 7 ++
6 files changed, 311 insertions(+)
create mode 100644 arch/arm/boot/dts/omap3-sb-t35.dtsi
create mode 100644 arch/arm/boot/dts/omap3-sbc-t3517.dts
create mode 100644 arch/arm/boot/dts/omap3-sbc-t3530.dts
create mode 100644 arch/arm/boot/dts/omap3-sbc-t3730.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index fc37bca..41370d2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -179,6 +179,9 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap2420-n810-wimax.dtb \
omap3430-sdp.dtb \
omap3-beagle.dtb \
+ omap3-sbc-t3530.dtb \
+ omap3-sbc-t3730.dtb \
+ omap3-sbc-t3517.dtb \
omap3-devkit8000.dtb \
omap3-beagle-xm.dtb \
omap3-evm.dtb \
diff --git a/arch/arm/boot/dts/omap3-sb-t35.dtsi
b/arch/arm/boot/dts/omap3-sb-t35.dtsi
new file mode 100644
index 000..fc676c5
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-sb-t35.dtsi
@@ -0,0 +1,135 @@
+/*
+ * Common support for CompuLab SB-T35 used on SBC-T3530, SBC-T3517 and
SBC-T3730
+ */
+
+/ {
+ aliases {
+ ethernet0 = smsc1;
+ ethernet1 = smsc2;
+ };
SB-T35 has only one SMSC Ethernet on-board (smsc2),
while the first one is on the cm-t3530 and cm-t3730 modules.
SBC-T3517 has only one _SMSC_ Ethernet and it is on the SB-T35 base board.
cm-t3517 has EMAC Ethernet on-board instead of the SMSC.
There is also another base board - CB-T3, which turns into
EM-T3530 and EM-T3730 once you plug the cm-t3530 or cm-t3730 into CB-T3.
http://compulab.co.il/products/handheld-computers/em-t3730/
http://compulab.co.il/products/handheld-computers/em-t3530/
The CB-T3 base board does not have any Ethernet controllers on it,
so the EM-T3x systems have only one Ethernet controller - the one on the
CPU board - SMSC.
This makes it four boards:
sb-t35 - base board has only one Ethernet controller (SMSC)
cb-t3 - base board has no Ethernet controllers
cm-t3530 - CPU board (plugged into sb-t35) has only one Ethernet controller
(SMSC)
cm-t3730 - CPU board (plugged into sb-t35) has only one Ethernet controller
(SMSC)
cm-t3537 - CPU board (plugged into sb-t35) has only one Ethernet controller
(EMAC)
The SBC-Txxx and EM-Txxx- means both boards connected (base board with CPU
board).
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ leds {
+ compatible = gpio-leds;
+ ledb {
+ label = cm-t35:green;
+ gpios = gpio6 26 GPIO_ACTIVE_HIGH; /* gpio186 */
+ linux,default-trigger = heartbeat;
Although all CPU boards have the same GPIO routed to the heartbeat LED,
this property is related to the CPU board and not to the base (mother) board.
The same GPIO is used intensionally for s/w simplicity.
If we are about to save code duplication, I'd like to have a common
to CPU boards file, say omap3-cm-t3x.dtsi - that way it will better reflect
the actual hardware.
+ };
+ };
+
+ vddvario: regulator-vddvario {
+ compatible = regulator-fixed;
+ regulator-name = vddvario;
+ regulator-always-on;
+ };
+
+ vdd33a: regulator-vdd33a {
+ compatible = regulator-fixed;
+ regulator-name = vdd33a;
+ regulator-always-on;
+ };
+};
+
+gpmc {
+ ranges = 5 0 0x2c00 0x0100,
+ 4 0
Re: [PATCH 2/5] phy: add support for indexed lookup
Hi Kishon,
On Mon, Dec 16, 2013 at 04:32:58PM +0530, Kishon Vijay Abraham I wrote:
On Monday 09 December 2013 08:38 PM, Heikki Krogerus wrote:
Removes the need for the consumer drivers requesting the
phys to provide name for the phy. This should ease the use
of the framework considerable when using only one phy, which
is usually the case when except with USB, but it can also
be useful with multiple phys.
If index has to be used with multiple PHYs, the controller should be aware of
the order in which it is populated in dt data. That's not good.
The Idea is not to replace the name based lookup. Just to provide
possibility for index based lookup.
With ACPI, if we get the device entries for PHYs, the order will be
fixed and we will not have any other reference to the phys. In case
of USB, the first one should always be USB2 PHY and the second the
USB3 PHY.
This will also reduce noise from the framework when there is
no phy by changing warnings to debug messages.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
drivers/phy/phy-core.c | 106
++--
include/linux/phy/phy.h | 14 +++
2 files changed, 89 insertions(+), 31 deletions(-)
diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
index 1102aef..99dc046 100644
--- a/drivers/phy/phy-core.c
+++ b/drivers/phy/phy-core.c
@@ -53,7 +53,8 @@ static int devm_phy_match(struct device *dev, void *res,
void *match_data)
return res == match_data;
}
-static struct phy *phy_lookup(struct device *device, const char *con_id)
+static struct phy *phy_lookup(struct device *device, const char *con_id,
+ unsigned int idx)
{
unsigned int count;
struct phy *phy;
@@ -67,6 +68,10 @@ static struct phy *phy_lookup(struct device *device,
const char *con_id)
count = phy-init_data-num_consumers;
consumers = phy-init_data-consumers;
while (count--) {
+ /* index must always match exactly */
+ if (!con_id)
+ if (idx != count)
+ continue;
if (!strcmp(consumers-dev_name, dev_name(device))
!strcmp(consumers-port, con_id)) {
class_dev_iter_exit(iter);
@@ -242,7 +247,8 @@ EXPORT_SYMBOL_GPL(phy_power_off);
/**
* of_phy_get() - lookup and obtain a reference to a phy by phandle
* @dev: device that requests this phy
- * @index: the index of the phy
+ * @con_id: name of the phy from device's point of view
+ * @idx: the index of the phy if name is not used
*
* Returns the phy associated with the given phandle value,
* after getting a refcount to it or -ENODEV if there is no such phy or
@@ -250,12 +256,20 @@ EXPORT_SYMBOL_GPL(phy_power_off);
* not yet loaded. This function uses of_xlate call back function provided
* while registering the phy_provider to find the phy instance.
*/
-static struct phy *of_phy_get(struct device *dev, int index)
+static struct phy *of_phy_get(struct device *dev, const char *con_id,
+ unsigned int idx)
{
int ret;
struct phy_provider *phy_provider;
struct phy *phy = NULL;
struct of_phandle_args args;
+ int index;
+
+ if (!con_id)
+ index = idx;
+ else
+ index = of_property_match_string(dev-of_node, phy-names,
+con_id);
ret = of_parse_phandle_with_args(dev-of_node, phys, #phy-cells,
index, args);
@@ -348,38 +362,36 @@ struct phy *of_phy_simple_xlate(struct device *dev,
struct of_phandle_args
EXPORT_SYMBOL_GPL(of_phy_simple_xlate);
/**
- * phy_get() - lookup and obtain a reference to a phy.
+ * phy_get_index() - obtain a phy based on index
NAK. It still takes a 'char' argument and the name is misleading.
Btw are you replacing phy_get() or adding a new API in addition to phy_get()?
Additional API. The phy_get() would in practice act as a wrapper after
this. It could actually be just a #define macro in the include file.
The function naming I just copied straight from gpiolib.c. I did not
have the imagination for anything fancier.
I would like to be able to use some function like phy_get_index() and
be able to deliver it both the name and the index. With DT you guys
will always be able to use the name (and the string will always
supersede the index if we do it like this), but with ACPI, and possibly
the platform lookup tables, the index can be used...
phy2 = phy_get_index(dev, usb2-phy, 0);
phy3 = phy_get_index(dev, usb3-phy, 1);
* @dev: device that requests this phy
* @con_id: name of the phy from device's point of view
+ * @idx: index of the phy to obtain in the consumer
*
- * Returns the phy driver, after
Re: [PATCH 4/5] arm: omap3: twl: use the new lookup method with usb phy
Hi,
On Mon, Dec 16, 2013 at 04:34:35PM +0530, Kishon Vijay Abraham I wrote:
On Monday 09 December 2013 08:38 PM, Heikki Krogerus wrote:
Provide a complete association for the phy and it's user
(musb) with the new phy_lookup_table.
Signed-off-by: Heikki Krogerus heikki.kroge...@linux.intel.com
---
arch/arm/mach-omap2/twl-common.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-omap2/twl-common.c
b/arch/arm/mach-omap2/twl-common.c
index b0d54da..972430b 100644
--- a/arch/arm/mach-omap2/twl-common.c
+++ b/arch/arm/mach-omap2/twl-common.c
@@ -91,18 +91,13 @@ void __init omap_pmic_late_init(void)
}
#if defined(CONFIG_ARCH_OMAP3)
-struct phy_consumer consumers[] = {
- PHY_CONSUMER(musb-hdrc.0, usb),
-};
-
-struct phy_init_data init_data = {
- .consumers = consumers,
- .num_consumers = ARRAY_SIZE(consumers),
+static struct phy_lookup_table twl4030_usb_lookup = {
+ .dev_id = musb-hdrc.0,
+ .table = PHY_LOOKUP(phy-twl4030_usb.0, NULL),
};
had a similar approach during the initial version of phy framework [1] (see
phy_bind) but changed it later [2] . Here you should know the device names of
two devices and even if one of them started using DEVID_AUTO, it'll start
breaking. Such an approach needs to reviewed carefully.
If somebody creates a regression by changing something like the
platform device id without checking all the users, he deserves to get
into big trouble. I don't see why an individual framework should
provide protection against such cases.
In any case, having two device names to deal with does not add any
more risk. These associations should always be made in the place where
the phy device is created so you will always know it's device name.
Normally the platform code creates these associations in the same
place it creates the platform devices, so you definitely know what the
device names will be.
In this case it's actually created in drivers/mfd/twl-core.c, so I do
need to update this and move the lookup table there. We can still
deliver the user name as platform data, though I believe it's always
musb. Maybe we could actually skip that and just hard code the name?
The name of the phy we will of course know as the platform device is
created there and then, so the two device names don't create any more
risk even in this case.
Thanks,
--
heikki
--
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
[PATCHv2 13/27] ARM: omap3.dtsi: add omapdss information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3.dtsi | 35 +++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index daabf99d402a..c646fa9ae5d3 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -630,5 +630,40 @@
num-eps = 16;
ram-bits = 12;
};
+
+ dss: dss@4805 {
+ compatible = ti,omap3-dss, simple-bus;
+ reg = 0x4805 0x200;
+ ti,hwmods = dss_core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@48050400 {
+ compatible = ti,omap3-dispc;
+ reg = 0x48050400 0x400;
+ interrupts = 25;
+ ti,hwmods = dss_dispc;
+ };
+
+ dsi: encoder@4804fc00 {
+ compatible = ti,omap3-dsi;
+ reg = 0x4804fc00 0x400;
+ interrupts = 25;
+ ti,hwmods = dss_dsi1;
+ };
+
+ rfbi: encoder@48050800 {
+ compatible = ti,omap3-rfbi;
+ reg = 0x48050800 0x100;
+ ti,hwmods = dss_rfbi;
+ };
+
+ venc: encoder@48050c00 {
+ compatible = ti,omap3-venc;
+ reg = 0x48050c00 0x100;
+ ti,hwmods = dss_venc;
+ };
+ };
};
};
--
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
[PATCHv2 05/27] OMAPDSS: get dssdev-alias from DT alias
We currently create a displayX style alias name for all displays,
using a number that is incremented for each registered display. With the
new DSS device model there is no clear order in which the displays are
registered, and thus the numbering is somewhat random.
This patch improves the behavior for DT case so that if the displays
have been assigned DT aliases, those aliases will be used as DSS
aliases.
This means that display0 is always the one specified in the DT alias,
and thus display0 can be used as default display in case the user didn't
specify a default display.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/display.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 012ada38a29d..21080f9dae87 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -134,9 +134,24 @@ static int disp_num_counter;
int omapdss_register_display(struct omap_dss_device *dssdev)
{
struct omap_dss_driver *drv = dssdev-driver;
+ int id;
- snprintf(dssdev-alias, sizeof(dssdev-alias),
- display%d, disp_num_counter++);
+ /*
+* Note: this presumes all the displays are either using DT or non-DT,
+* which normally should be the case. This also presumes that all
+* displays either have an DT alias, or none has.
+*/
+
+ if (dssdev-dev-of_node) {
+ id = of_alias_get_id(dssdev-dev-of_node, display);
+
+ if (id 0)
+ id = disp_num_counter++;
+ } else {
+ id = disp_num_counter++;
+ }
+
+ snprintf(dssdev-alias, sizeof(dssdev-alias), display%d, id);
/* Use 'label' property for name, if it exists */
if (dssdev-dev-of_node)
--
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
[PATCHv2 15/27] ARM: omap4-panda.dts: add display information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 121 +-
1 file changed, 117 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 88c6a05cab41..dc71645dee9b 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -112,10 +112,6 @@
twl6040_pins
mcpdm_pins
mcbsp1_pins
- dss_dpi_pins
- tfp410_pins
- dss_hdmi_pins
- tpd12s015_pins
hsusbb1_pins
;
@@ -409,3 +405,120 @@
usbhsehci {
phys = hsusb1_phy;
};
+
+dss {
+ pinctrl-names = default;
+ pinctrl-0 = dss_dpi_pins;
+
+ dpi_out: endpoint {
+ remote-endpoint = tfp410_in;
+ data-lines = 24;
+ };
+};
+
+dsi1 {
+ vdds_dsi-supply = vcxio;
+};
+
+dsi2 {
+ vdds_dsi-supply = vcxio;
+};
+
+hdmi {
+ vdda_hdmi_dac-supply = vdac;
+
+ pinctrl-names = default;
+ pinctrl-0 = dss_hdmi_pins;
+
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+};
+
+/ {
+ aliases {
+ display0 = dvi0;
+ display1 = hdmi0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ gpios = gpio1 0 GPIO_ACTIVE_LOW; /* 0, power-down */
+
+ pinctrl-names = default;
+ pinctrl-0 = tfp410_pins;
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = dvi_connector_in;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = dvi-connector;
+ label = dvi;
+
+ i2c-bus = i2c3;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = tfp410_out;
+ };
+ };
+
+ tpd12s015: encoder@1 {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = gpio2 28 GPIO_ACTIVE_HIGH, /* 60, CT CP HPD */
+ gpio2 9 GPIO_ACTIVE_HIGH,/* 41, LS OE */
+ gpio2 31 GPIO_ACTIVE_HIGH; /* 63, HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint@0 {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@1 {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+};
--
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
[PATCHv2 09/27] OMAPDSS: Add DT support to DSS, DISPC, DPI and SDI.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dispc.c | 7 +
drivers/video/omap2/dss/dpi.c | 47 ++
drivers/video/omap2/dss/dss.c | 63 +
drivers/video/omap2/dss/dss.h | 6
drivers/video/omap2/dss/sdi.c | 45 +
5 files changed, 168 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 4ec59ca72e5d..b702369fc895 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3744,12 +3744,19 @@ static const struct dev_pm_ops dispc_pm_ops = {
.runtime_resume = dispc_runtime_resume,
};
+static const struct of_device_id dispc_of_match[] = {
+ { .compatible = ti,omap3-dispc, },
+ { .compatible = ti,omap4-dispc, },
+ {},
+};
+
static struct platform_driver omap_dispchw_driver = {
.remove = __exit_p(omap_dispchw_remove),
.driver = {
.name = omapdss_dispc,
.owner = THIS_MODULE,
.pm = dispc_pm_ops,
+ .of_match_table = dispc_of_match,
},
};
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index bd48cde53561..cc452796b734 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -30,6 +30,7 @@
#include linux/platform_device.h
#include linux/regulator/consumer.h
#include linux/string.h
+#include linux/of.h
#include video/omapdss.h
@@ -49,6 +50,8 @@ static struct {
int data_lines;
struct omap_dss_device output;
+
+ bool port_initialized;
} dpi;
static struct platform_device *dpi_get_dsidev(enum omap_channel channel)
@@ -726,3 +729,47 @@ void __exit dpi_uninit_platform_driver(void)
{
platform_driver_unregister(omap_dpi_driver);
}
+
+int __init dpi_init_port(struct platform_device *pdev, struct device_node
*port)
+{
+ struct device_node *ep;
+ u32 datalines;
+ int r;
+
+ ep = omapdss_of_get_next_endpoint(port, NULL);
+ if (!ep)
+ return 0;
+
+ r = of_property_read_u32(ep, data-lines, datalines);
+ if (r) {
+ DSSERR(failed to parse datalines\n);
+ goto err_datalines;
+ }
+
+ dpi.data_lines = datalines;
+
+ of_node_put(ep);
+
+ dpi.pdev = pdev;
+
+ mutex_init(dpi.lock);
+
+ dpi_init_output(pdev);
+
+ dpi.port_initialized = true;
+
+ return 0;
+
+err_datalines:
+ of_node_put(ep);
+
+ return r;
+}
+
+void __exit dpi_uninit_port(void)
+{
+ if (!dpi.port_initialized)
+ return;
+
+ dpi_uninit_output(dpi.pdev);
+}
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index bd01608e67e2..1082fadd004f 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -23,6 +23,7 @@
#define DSS_SUBSYS_NAME DSS
#include linux/kernel.h
+#include linux/module.h
#include linux/io.h
#include linux/export.h
#include linux/err.h
@@ -33,6 +34,7 @@
#include linux/pm_runtime.h
#include linux/gfp.h
#include linux/sizes.h
+#include linux/of.h
#include video/omapdss.h
@@ -841,6 +843,54 @@ static int __init dss_init_features(struct platform_device
*pdev)
return 0;
}
+static int dss_init_ports(struct platform_device *pdev)
+{
+ struct device_node *parent = pdev-dev.of_node;
+ struct device_node *port;
+ int r;
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (!port) {
+
+#ifdef CONFIG_OMAP2_DSS_DPI
+ dpi_init_port(pdev, parent);
+#endif
+ return 0;
+ }
+
+ do {
+ u32 reg;
+
+ r = of_property_read_u32(port, reg, reg);
+ if (r)
+ reg = 0;
+
+#ifdef CONFIG_OMAP2_DSS_DPI
+ if (reg == 0)
+ dpi_init_port(pdev, port);
+#endif
+
+#ifdef CONFIG_OMAP2_DSS_SDI
+ if (reg == 1)
+ sdi_init_port(pdev, port);
+#endif
+
+ } while ((port = omapdss_of_get_next_port(parent, port)) != NULL);
+
+ return 0;
+}
+
+static void dss_uninit_ports(void)
+{
+#ifdef CONFIG_OMAP2_DSS_DPI
+ dpi_uninit_port();
+#endif
+
+#ifdef CONFIG_OMAP2_DSS_SDI
+ sdi_uninit_port();
+#endif
+}
+
/* DSS HW IP initialisation */
static int __init omap_dsshw_probe(struct platform_device *pdev)
{
@@ -899,6 +949,8 @@ static int __init omap_dsshw_probe(struct platform_device
*pdev)
dss.lcd_clk_source[0] = OMAP_DSS_CLK_SRC_FCK;
dss.lcd_clk_source[1] = OMAP_DSS_CLK_SRC_FCK;
+ dss_init_ports(pdev);
+
rev = dss_read_reg(DSS_REVISION);
printk(KERN_INFO OMAP DSS rev %d.%d\n,
FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
@@ -918,6 +970,8 @@ err_setup_clocks:
static int __exit omap_dsshw_remove(struct platform_device *pdev)
{
+
[PATCHv2 23/27] OMAPDSS: connector-dvi: Add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/connector-dvi.c | 43
1 file changed, 43 insertions(+)
diff --git a/drivers/video/omap2/displays-new/connector-dvi.c
b/drivers/video/omap2/displays-new/connector-dvi.c
index b6c50904038e..d1204b1c5182 100644
--- a/drivers/video/omap2/displays-new/connector-dvi.c
+++ b/drivers/video/omap2/displays-new/connector-dvi.c
@@ -277,6 +277,37 @@ static int dvic_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int dvic_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ struct device_node *adapter_node;
+ struct i2c_adapter *adapter;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ adapter_node = of_parse_phandle(node, i2c-bus, 0);
+ if (adapter_node) {
+ adapter = of_find_i2c_adapter_by_node(adapter_node);
+ if (adapter == NULL) {
+ dev_err(pdev-dev, failed to parse i2c-bus\n);
+ omap_dss_put_device(ddata-in);
+ return -EPROBE_DEFER;
+ }
+
+ ddata-i2c_adapter = adapter;
+ }
+
+ return 0;
+}
+
static int dvic_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -293,6 +324,10 @@ static int dvic_probe(struct platform_device *pdev)
r = dvic_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = dvic_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -342,12 +377,20 @@ static int __exit dvic_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id dvic_of_match[] = {
+ { .compatible = dvi-connector, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, dvic_of_match);
+
static struct platform_driver dvi_connector_driver = {
.probe = dvic_probe,
.remove = __exit_p(dvic_remove),
.driver = {
.name = connector-dvi,
.owner = THIS_MODULE,
+ .of_match_table = dvic_of_match,
},
};
--
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
[PATCHv2 12/27] OMAPDSS: Add DT support to DSI
Add the code to make the DSI driver work with device tree on OMAP3 and
OMAP4.
A minor hack is needed at the moment in the DSI driver: the DSS driver
needs to know the ID number of a DSI device, as clocks are routed in
different ways to the DSI devices. At the moment we don't have any
proper way to manage this, so this patchs adds a simple lookup table
that is used to deduce the ID from the DSI device's base address.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 136 +-
1 file changed, 135 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 18b5e84165bb..46edec82c502 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -38,6 +38,8 @@
#include linux/slab.h
#include linux/debugfs.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_platform.h
#include video/omapdss.h
#include video/mipi_display.h
@@ -374,6 +376,13 @@ struct dsi_packet_sent_handler_data {
struct completion *completion;
};
+struct dsi_module_id_data {
+ u32 address;
+ int id;
+};
+
+static const struct of_device_id dsi_of_match[];
+
#ifdef DSI_PERF_MEASURE
static bool dsi_perf;
module_param(dsi_perf, bool, 0644);
@@ -5336,6 +5345,62 @@ static void dsi_uninit_output(struct platform_device
*dsidev)
omapdss_unregister_output(out);
}
+static int dsi_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct dsi_data *dsi = dsi_get_dsidrv_data(pdev);
+ struct property *prop;
+ u32 lane_arr[10];
+ int len, num_pins;
+ int r, i;
+ struct device_node *ep;
+ struct omap_dsi_pin_config pin_cfg;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return 0;
+
+ prop = of_find_property(ep, lanes, len);
+ if (prop == NULL) {
+ dev_err(pdev-dev, failed to find lane data\n);
+ r = -EINVAL;
+ goto err;
+ }
+
+ num_pins = len / sizeof(u32);
+
+ if (num_pins 4 || num_pins % 2 != 0
+ || num_pins dsi-num_lanes_supported * 2) {
+ dev_err(pdev-dev, bad number of lanes\n);
+ r = -EINVAL;
+ goto err;
+ }
+
+ r = of_property_read_u32_array(ep, lanes, lane_arr, num_pins);
+ if (r) {
+ dev_err(pdev-dev, failed to read lane data\n);
+ goto err;
+ }
+
+ pin_cfg.num_pins = num_pins;
+ for (i = 0; i num_pins; ++i)
+ pin_cfg.pins[i] = (int)lane_arr[i];
+
+ r = dsi_configure_pins(dsi-output, pin_cfg);
+ if (r) {
+ dev_err(pdev-dev, failed to configure pins);
+ goto err;
+ }
+
+ of_node_put(ep);
+
+ return 0;
+
+err:
+ of_node_put(ep);
+ return r;
+}
+
/* DSI1 HW IP initialisation */
static int omap_dsihw_probe(struct platform_device *dsidev)
{
@@ -5348,7 +5413,6 @@ static int omap_dsihw_probe(struct platform_device
*dsidev)
if (!dsi)
return -ENOMEM;
- dsi-module_id = dsidev-id;
dsi-pdev = dsidev;
dev_set_drvdata(dsidev-dev, dsi);
@@ -5398,6 +5462,31 @@ static int omap_dsihw_probe(struct platform_device
*dsidev)
return r;
}
+ if (dsidev-dev.of_node) {
+ const struct of_device_id *match;
+ const struct dsi_module_id_data *d;
+
+ match = of_match_node(dsi_of_match, dsidev-dev.of_node);
+ if (!match) {
+ DSSERR(unsupported DSI module\n);
+ return -ENODEV;
+ }
+
+ d = match-data;
+
+ while (d-address != 0 d-address != dsi_mem-start)
+ d++;
+
+ if (d-address == 0) {
+ DSSERR(unsupported DSI module\n);
+ return -ENODEV;
+ }
+
+ dsi-module_id = d-id;
+ } else {
+ dsi-module_id = dsidev-id;
+ }
+
/* DSI VCs initialization */
for (i = 0; i ARRAY_SIZE(dsi-vc); i++) {
dsi-vc[i].source = DSI_VC_SOURCE_L4;
@@ -5433,6 +5522,19 @@ static int omap_dsihw_probe(struct platform_device
*dsidev)
dsi_init_output(dsidev);
+ if (dsidev-dev.of_node) {
+ r = dsi_probe_of(dsidev);
+ if (r) {
+ DSSERR(Invalid DSI DT data\n);
+ goto err_probe_of;
+ }
+
+ r = of_platform_populate(dsidev-dev.of_node, NULL, NULL,
+ dsidev-dev);
+ if (r)
+ DSSERR(Failed to populate DSI child devices: %d\n, r);
+ }
+
dsi_runtime_put(dsidev);
if (dsi-module_id == 0)
@@ -5446,17 +5548,31 @@ static int
[PATCHv2 01/27] ARM: OMAP: remove DSS DT hack
As a temporary solution to enable DSS for selected boards when booting
with DT, a hack was added to board-generic.c in
63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable
DSS for panda sdp boards).
We're now adding proper DT support, so the hack can be removed.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/dss-common.c | 259 -
arch/arm/mach-omap2/dss-common.h | 13 --
arch/arm/mach-omap2/pdata-quirks.c | 4 -
4 files changed, 1 insertion(+), 277 deletions(-)
delete mode 100644 arch/arm/mach-omap2/dss-common.c
delete mode 100644 arch/arm/mach-omap2/dss-common.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index adcef406ff0a..e81dbf202a6d 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -296,4 +296,4 @@ endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
-obj-y += common-board-devices.o twl-common.o
dss-common.o
+obj-y += common-board-devices.o twl-common.o
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
deleted file mode 100644
index dadccc91488c..
--- a/arch/arm/mach-omap2/dss-common.c
+++ /dev/null
@@ -1,259 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments, Inc..
- * Author: Tomi Valkeinen tomi.valkei...@ti.com
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * version 2 as published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-/*
- * NOTE: this is a transitional file to help with DT adaptation.
- * This file will be removed when DSS supports DT.
- */
-
-#include linux/kernel.h
-#include linux/gpio.h
-#include linux/platform_device.h
-
-#include video/omapdss.h
-#include video/omap-panel-data.h
-
-#include soc.h
-#include dss-common.h
-#include mux.h
-
-#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
-#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
-#define HDMI_GPIO_HPD 63 /* Hotplug detect */
-
-#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
-
-/* DVI Connector */
-static struct connector_dvi_platform_data omap4_panda_dvi_connector_pdata = {
- .name = dvi,
- .source = tfp410.0,
- .i2c_bus_num= 2,
-};
-
-static struct platform_device omap4_panda_dvi_connector_device = {
- .name = connector-dvi,
- .id = 0,
- .dev.platform_data = omap4_panda_dvi_connector_pdata,
-};
-
-/* TFP410 DPI-to-DVI chip */
-static struct encoder_tfp410_platform_data omap4_panda_tfp410_pdata = {
- .name = tfp410.0,
- .source = dpi.0,
- .data_lines = 24,
- .power_down_gpio= PANDA_DVI_TFP410_POWER_DOWN_GPIO,
-};
-
-static struct platform_device omap4_panda_tfp410_device = {
- .name = tfp410,
- .id = 0,
- .dev.platform_data = omap4_panda_tfp410_pdata,
-};
-
-/* HDMI Connector */
-static struct connector_hdmi_platform_data omap4_panda_hdmi_connector_pdata = {
- .name = hdmi,
- .source = tpd12s015.0,
-};
-
-static struct platform_device omap4_panda_hdmi_connector_device = {
- .name = connector-hdmi,
- .id = 0,
- .dev.platform_data = omap4_panda_hdmi_connector_pdata,
-};
-
-/* TPD12S015 HDMI ESD protection level shifter chip */
-static struct encoder_tpd12s015_platform_data omap4_panda_tpd_pdata = {
- .name = tpd12s015.0,
- .source = hdmi.0,
-
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct platform_device omap4_panda_tpd_device = {
- .name = tpd12s015,
- .id = 0,
- .dev.platform_data = omap4_panda_tpd_pdata,
-};
-
-static struct omap_dss_board_info omap4_panda_dss_data = {
- .default_display_name = dvi,
-};
-
-void __init omap4_panda_display_init_of(void)
-{
- omap_display_init(omap4_panda_dss_data);
-
- platform_device_register(omap4_panda_tfp410_device);
-
[PATCHv2 10/27] OMAPDSS: Add DT support to HDMI
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/hdmi4.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/omap2/dss/hdmi4.c b/drivers/video/omap2/dss/hdmi4.c
index 16e598787522..97dd05f602f7 100644
--- a/drivers/video/omap2/dss/hdmi4.c
+++ b/drivers/video/omap2/dss/hdmi4.c
@@ -671,6 +671,11 @@ static const struct dev_pm_ops hdmi_pm_ops = {
.runtime_resume = hdmi_runtime_resume,
};
+static const struct of_device_id hdmi_of_match[] = {
+ { .compatible = ti,omap4-hdmi, },
+ {},
+};
+
static struct platform_driver omapdss_hdmihw_driver = {
.probe = omapdss_hdmihw_probe,
.remove = __exit_p(omapdss_hdmihw_remove),
@@ -678,6 +683,7 @@ static struct platform_driver omapdss_hdmihw_driver = {
.name = omapdss_hdmi,
.owner = THIS_MODULE,
.pm = hdmi_pm_ops,
+ .of_match_table = hdmi_of_match,
},
};
--
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
[PATCHv2 17/27] ARM: omap3-tobi.dts: add lcd (TEST)
This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
it as a test.
Not to be merged.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3-tobi.dts | 47
1 file changed, 47 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
index 7e4ad2aec37a..3baf3a286435 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -81,3 +81,50 @@
mmc3 {
status = disabled;
};
+
+dss {
+ /* XXX add pinctrl */
+ /*
+ pinctrl-names = default;
+ pinctrl-0 = dss_dpi_pins;
+ */
+
+ vdds_dsi-supply = vpll2;
+
+ dpi_out: endpoint {
+ remote-endpoint = lcd_in;
+ data-lines = 24;
+ };
+};
+
+/ {
+ aliases {
+ display0 = lcd0;
+ };
+
+ lcd0: display@0 {
+ compatible = samsung,lte430wq-f0c, panel-dpi;
+ label = lcd;
+
+ lcd_in: endpoint {
+ remote-endpoint = dpi_out;
+ };
+
+ panel-timing {
+ clock-frequency = 920;
+ hactive = 480;
+ vactive = 272;
+ hfront-porch = 8;
+ hback-porch = 4;
+ hsync-len = 41;
+ vback-porch = 2;
+ vfront-porch = 4;
+ vsync-len = 10;
+
+ hsync-active = 0;
+ vsync-active = 0;
+ de-active = 1;
+ pixelclk-active = 1;
+ };
+ };
+};
--
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
[PATCHv2 02/27] OMAPDSS: remove DT hacks for regulators
For booting Panda and 4430SDP with DT, while DSS did not support DT, we
had to had small hacks in the omapdss driver to get the regulators. With
DT now supported in DSS, we can remove those hacks.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c | 5 -
drivers/video/omap2/dss/hdmi4.c | 4
2 files changed, 9 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 1cd3e47fd43f..18b5e84165bb 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1124,11 +1124,6 @@ static int dsi_regulator_init(struct platform_device
*dsidev)
return 0;
vdds_dsi = devm_regulator_get(dsi-pdev-dev, vdds_dsi);
-
- /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
- if (IS_ERR(vdds_dsi))
- vdds_dsi = devm_regulator_get(dsi-pdev-dev, VCXIO);
-
if (IS_ERR(vdds_dsi)) {
DSSERR(can't get VDDS_DSI regulator\n);
return PTR_ERR(vdds_dsi);
diff --git a/drivers/video/omap2/dss/hdmi4.c b/drivers/video/omap2/dss/hdmi4.c
index e14009614338..16e598787522 100644
--- a/drivers/video/omap2/dss/hdmi4.c
+++ b/drivers/video/omap2/dss/hdmi4.c
@@ -90,10 +90,6 @@ static int hdmi_init_regulator(void)
reg = devm_regulator_get(hdmi.pdev-dev, vdda_hdmi_dac);
- /* DT HACK: try VDAC to make omapdss work for o4 sdp/panda */
- if (IS_ERR(reg))
- reg = devm_regulator_get(hdmi.pdev-dev, VDAC);
-
if (IS_ERR(reg)) {
DSSERR(can't get VDDA_HDMI_DAC regulator\n);
return PTR_ERR(reg);
--
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
[PATCHv2 06/27] OMAPFB: clean up default display search
Separate the code for finding the default display into a function for
clarity and to make it easier to extend it in the future.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c | 46
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 27d6905683f3..8bfe973e55ec 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2407,6 +2407,34 @@ static int omapfb_init_connections(struct omapfb2_device
*fbdev,
return 0;
}
+static struct omap_dss_device *
+omapfb_find_default_display(struct omapfb2_device *fbdev)
+{
+ const char *def_name;
+ int i;
+
+ /* search with the display name from the user or the board file */
+
+ def_name = omapdss_get_default_display_name();
+
+ if (def_name) {
+ for (i = 0; i fbdev-num_displays; ++i) {
+ struct omap_dss_device *dssdev;
+
+ dssdev = fbdev-displays[i].dssdev;
+
+ if (dssdev-name strcmp(def_name, dssdev-name) == 0)
+ return dssdev;
+ }
+
+ /* def_name given but not found */
+ return NULL;
+ }
+
+ /* return the first display we have in the list */
+ return fbdev-displays[0].dssdev;
+}
+
static int omapfb_probe(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = NULL;
@@ -2484,23 +2512,7 @@ static int omapfb_probe(struct platform_device *pdev)
for (i = 0; i fbdev-num_managers; i++)
fbdev-managers[i] = omap_dss_get_overlay_manager(i);
- def_display = NULL;
-
- for (i = 0; i fbdev-num_displays; ++i) {
- struct omap_dss_device *dssdev;
- const char *def_name;
-
- def_name = omapdss_get_default_display_name();
-
- dssdev = fbdev-displays[i].dssdev;
-
- if (def_name == NULL ||
- (dssdev-name strcmp(def_name, dssdev-name) == 0)) {
- def_display = dssdev;
- break;
- }
- }
-
+ def_display = omapfb_find_default_display(fbdev);
if (def_display == NULL) {
dev_err(fbdev-dev, failed to find default display\n);
r = -EPROBE_DEFER;
--
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
[PATCHv2 18/27] ARM: omap3-beagle.dts: add display information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3-beagle.dts | 115 +
1 file changed, 115 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index 3ba4a625ea5b..b4057762cedd 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -119,6 +119,45 @@
0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx */
;
};
+
+ tfp410_pins: pinmux_tfp410_pins {
+ pinctrl-single,pins =
+ 0x194 (PIN_OUTPUT | MUX_MODE4) /* hdq_sio.gpio_170 */
+ ;
+ };
+
+ dss_dpi_pins: pinmux_dss_dpi_pins {
+ pinctrl-single,pins =
+ 0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
+ 0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync
*/
+ 0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync
*/
+ 0x0aa (PIN_OUTPUT | MUX_MODE0) /*
dss_acbias.dss_acbias */
+ 0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0
*/
+ 0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1
*/
+ 0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2
*/
+ 0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3
*/
+ 0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4
*/
+ 0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5
*/
+ 0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6
*/
+ 0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7
*/
+ 0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8
*/
+ 0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9
*/
+ 0x0c0 (PIN_OUTPUT | MUX_MODE0) /*
dss_data10.dss_data10 */
+ 0x0c2 (PIN_OUTPUT | MUX_MODE0) /*
dss_data11.dss_data11 */
+ 0x0c4 (PIN_OUTPUT | MUX_MODE0) /*
dss_data12.dss_data12 */
+ 0x0c6 (PIN_OUTPUT | MUX_MODE0) /*
dss_data13.dss_data13 */
+ 0x0c8 (PIN_OUTPUT | MUX_MODE0) /*
dss_data14.dss_data14 */
+ 0x0ca (PIN_OUTPUT | MUX_MODE0) /*
dss_data15.dss_data15 */
+ 0x0cc (PIN_OUTPUT | MUX_MODE0) /*
dss_data16.dss_data16 */
+ 0x0ce (PIN_OUTPUT | MUX_MODE0) /*
dss_data17.dss_data17 */
+ 0x0d0 (PIN_OUTPUT | MUX_MODE0) /*
dss_data18.dss_data18 */
+ 0x0d2 (PIN_OUTPUT | MUX_MODE0) /*
dss_data19.dss_data19 */
+ 0x0d4 (PIN_OUTPUT | MUX_MODE0) /*
dss_data20.dss_data20 */
+ 0x0d6 (PIN_OUTPUT | MUX_MODE0) /*
dss_data21.dss_data21 */
+ 0x0d8 (PIN_OUTPUT | MUX_MODE0) /*
dss_data22.dss_data22 */
+ 0x0da (PIN_OUTPUT | MUX_MODE0) /*
dss_data23.dss_data23 */
+ ;
+ };
};
i2c1 {
@@ -199,3 +238,79 @@
regulator-max-microvolt = 180;
regulator-always-on;
};
+
+dss {
+ pinctrl-names = default;
+ pinctrl-0 = dss_dpi_pins;
+
+ vdds_dsi-supply = vpll2;
+
+ dpi_out: endpoint {
+ remote-endpoint = tfp410_in;
+ data-lines = 24;
+ };
+};
+
+venc {
+ vdda_dac-supply = vdac;
+
+ venc_out: endpoint {
+ remote-endpoint = tv_connector_in;
+ };
+};
+
+/ {
+ aliases {
+ display0 = dvi0;
+ display1 = tv0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ gpios = gpio6 10 GPIO_ACTIVE_LOW;/* 170, power-down */
+
+ pinctrl-names = default;
+ pinctrl-0 = tfp410_pins;
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = dvi_connector_in;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = dvi-connector;
+ label = dvi;
+
+ i2c-bus = i2c3;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = tfp410_out;
+ };
+ };
+
+ tv0: connector@1 {
+
[PATCHv2 27/27] OMAPDSS: connector-analog-tv: Add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../video/omap2/displays-new/connector-analog-tv.c | 66 +-
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/connector-analog-tv.c
b/drivers/video/omap2/displays-new/connector-analog-tv.c
index ccd9073f706f..ebed25a86487 100644
--- a/drivers/video/omap2/displays-new/connector-analog-tv.c
+++ b/drivers/video/omap2/displays-new/connector-analog-tv.c
@@ -12,6 +12,7 @@
#include linux/slab.h
#include linux/module.h
#include linux/platform_device.h
+#include linux/of.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -42,6 +43,12 @@ static const struct omap_video_timings tvc_pal_timings = {
.interlace = true,
};
+static const struct of_device_id tvc_of_match[];
+
+struct tvc_of_data {
+ enum omap_dss_venc_type connector_type;
+};
+
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
static int tvc_connect(struct omap_dss_device *dssdev)
@@ -92,7 +99,10 @@ static int tvc_enable(struct omap_dss_device *dssdev)
in-ops.atv-set_timings(in, ddata-timings);
in-ops.atv-set_type(in, ddata-connector_type);
- in-ops.atv-invert_vid_out_polarity(in, ddata-invert_polarity);
+
+ if (!ddata-dev-of_node)
+ in-ops.atv-invert_vid_out_polarity(in,
+ ddata-invert_polarity);
r = in-ops.atv-enable(in);
if (r)
@@ -205,6 +215,35 @@ static int tvc_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tvc_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ const struct of_device_id *match;
+ const struct tvc_of_data *data;
+
+ match = of_match_node(tvc_of_match, pdev-dev.of_node);
+ if (!match) {
+ dev_err(pdev-dev, unsupported device\n);
+ return -ENODEV;
+ }
+
+ data = match-data;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ ddata-connector_type = data-connector_type;
+
+ return 0;
+}
+
static int tvc_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -222,6 +261,10 @@ static int tvc_probe(struct platform_device *pdev)
r = tvc_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = tvc_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -263,12 +306,33 @@ static int __exit tvc_remove(struct platform_device *pdev)
return 0;
}
+static const struct tvc_of_data tv_svideo_data = {
+ .connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static const struct tvc_of_data tv_composite_video_data = {
+ .connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+};
+
+static const struct of_device_id tvc_of_match[] = {
+ {
+ .compatible = svideo-connector,
+ .data = tv_svideo_data,
+ },
+ {
+ .compatible = composite-video-connector,
+ .data = tv_composite_video_data,
+ },
+ {},
+};
+
static struct platform_driver tvc_connector_driver = {
.probe = tvc_probe,
.remove = __exit_p(tvc_remove),
.driver = {
.name = connector-analog-tv,
.owner = THIS_MODULE,
+ .of_match_table = tvc_of_match,
},
};
--
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
[PATCHv2 25/27] OMAPDSS: hdmi-connector: Add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/connector-hdmi.c | 30 +++
1 file changed, 30 insertions(+)
diff --git a/drivers/video/omap2/displays-new/connector-hdmi.c
b/drivers/video/omap2/displays-new/connector-hdmi.c
index 9abe2c039ae9..12246b5841c0 100644
--- a/drivers/video/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/omap2/displays-new/connector-hdmi.c
@@ -12,6 +12,7 @@
#include linux/slab.h
#include linux/module.h
#include linux/platform_device.h
+#include linux/of.h
#include drm/drm_edid.h
@@ -301,6 +302,23 @@ static int hdmic_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int hdmic_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ return 0;
+}
+
static int hdmic_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -318,6 +336,10 @@ static int hdmic_probe(struct platform_device *pdev)
r = hdmic_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = hdmic_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -359,12 +381,20 @@ static int __exit hdmic_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id hdmic_of_match[] = {
+ { .compatible = hdmi-connector, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, hdmic_of_match);
+
static struct platform_driver hdmi_connector_driver = {
.probe = hdmic_probe,
.remove = __exit_p(hdmic_remove),
.driver = {
.name = connector-hdmi,
.owner = THIS_MODULE,
+ .of_match_table = hdmic_of_match,
},
};
--
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
[PATCHv2 24/27] OMAPDSS: encoder-tpd12s015: Add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
.../video/omap2/displays-new/encoder-tpd12s015.c | 56 ++
1 file changed, 56 insertions(+)
diff --git a/drivers/video/omap2/displays-new/encoder-tpd12s015.c
b/drivers/video/omap2/displays-new/encoder-tpd12s015.c
index d5c936cb217f..6529a4ff50ca 100644
--- a/drivers/video/omap2/displays-new/encoder-tpd12s015.c
+++ b/drivers/video/omap2/displays-new/encoder-tpd12s015.c
@@ -15,6 +15,7 @@
#include linux/slab.h
#include linux/gpio.h
#include linux/platform_device.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -289,6 +290,49 @@ static int tpd_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tpd_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ int gpio;
+
+ /* CT CP HPD GPIO */
+ gpio = of_get_gpio(node, 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(pdev-dev, failed to parse CT CP HPD gpio\n);
+ return gpio;
+ }
+ ddata-ct_cp_hpd_gpio = gpio;
+
+ /* LS OE GPIO */
+ gpio = of_get_gpio(node, 1);
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata-ls_oe_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse LS OE gpio\n);
+ return gpio;
+ }
+
+ /* HPD GPIO */
+ gpio = of_get_gpio(node, 2);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(pdev-dev, failed to parse HPD gpio\n);
+ return gpio;
+ }
+ ddata-hpd_gpio = gpio;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ return 0;
+}
+
static int tpd_probe(struct platform_device *pdev)
{
struct omap_dss_device *in, *dssdev;
@@ -307,6 +351,10 @@ static int tpd_probe(struct platform_device *pdev)
r = tpd_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = tpd_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -379,12 +427,20 @@ static int __exit tpd_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id tpd_of_match[] = {
+ { .compatible = ti,tpd12s015, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, tpd_of_match);
+
static struct platform_driver tpd_driver = {
.probe = tpd_probe,
.remove = __exit_p(tpd_remove),
.driver = {
.name = tpd12s015,
.owner = THIS_MODULE,
+ .of_match_table = tpd_of_match,
},
};
--
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
[PATCHv2 20/27] ARM: omap3-igep0020.dts: add display information
From: Javier Martinez Canillas javier.marti...@collabora.co.uk
The IGEPv2 has a TFP410 DPI-to-DVI encoder attached
to OMAP's Display SubSystem (DSS). Add DeviceTree
nodes for these devices.
Signed-off-by: Javier Martinez Canillas javier.marti...@collabora.co.uk
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3-igep0020.dts | 64 +---
1 file changed, 60 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index b9a9e17acb58..6d34abf5b421 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -67,8 +67,6 @@
pinctrl-names = default;
pinctrl-0 =
hsusbb1_pins
- tfp410_pins
- dss_pins
;
hsusbb1_pins: pinmux_hsusbb1_pins {
@@ -88,13 +86,13 @@
;
};
- tfp410_pins: tfp410_dvi_pins {
+ tfp410_pins: pinmux_tfp410_pins {
pinctrl-single,pins =
0x196 (PIN_OUTPUT | MUX_MODE4) /* hdq_sio.gpio_170 */
;
};
- dss_pins: pinmux_dss_dvi_pins {
+ dss_dpi_pins: pinmux_dss_dpi_pins {
pinctrl-single,pins =
0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync
*/
@@ -215,3 +213,61 @@
usbhsehci {
phys = hsusb1_phy;
};
+
+dss {
+ pinctrl-names = default;
+ pinctrl-0 = dss_dpi_pins;
+
+ vdds_dsi-supply = vpll2;
+
+ dpi_out: endpoint {
+ remote-endpoint = tfp410_in;
+ data-lines = 24;
+ };
+};
+
+/ {
+ aliases {
+ display0 = dvi0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ gpios = gpio6 10 GPIO_ACTIVE_LOW; /* 170, power-down */
+
+ pinctrl-names = default;
+ pinctrl-0 = tfp410_pins;
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = dvi_connector_in;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = dvi-connector;
+ label = dvi;
+
+ i2c-bus = i2c3;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = tfp410_out;
+ };
+ };
+};
--
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
[PATCHv2 14/27] ARM: omap4.dtsi: add omapdss information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 54
1 file changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a1e05853afcd..a515f524ef3a 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -705,5 +705,59 @@
dmas = sdma 117, sdma 116;
dma-names = tx, rx;
};
+
+ dss: dss@5800 {
+ compatible = ti,omap4-dss, simple-bus;
+ reg = 0x5800 0x80;
+ ti,hwmods = dss_core;
+ #address-cells = 1;
+ #size-cells = 1;
+ ranges;
+
+ dispc@58001000 {
+ compatible = ti,omap4-dispc;
+ reg = 0x58001000 0x1000;
+ interrupts = GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dispc;
+ };
+
+ rfbi: encoder@58002000 {
+ compatible = ti,omap4-rfbi;
+ reg = 0x58002000 0x1000;
+ ti,hwmods = dss_rfbi;
+ };
+
+ /*
+* Accessing venc registers cause a crash on omap4, so
+* this is disabled for now.
+*/
+ venc: encoder@58003000 {
+ compatible = ti,omap4-venc;
+ reg = 0x58003000 0x1000;
+ ti,hwmods = dss_venc;
+ status = disabled;
+ };
+
+ dsi1: encoder@58004000 {
+ compatible = ti,omap4-dsi;
+ reg = 0x58004000 0x200;
+ interrupts = GIC_SPI 53 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dsi1;
+ };
+
+ dsi2: encoder@58005000 {
+ compatible = ti,omap4-dsi;
+ reg = 0x58005000 0x200;
+ interrupts = GIC_SPI 84 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_dsi2;
+ };
+
+ hdmi: encoder@58006000 {
+ compatible = ti,omap4-hdmi;
+ reg = 0x58006000 0x1000;
+ interrupts = GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = dss_hdmi;
+ };
+ };
};
};
--
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
[PATCHv2 19/27] ARM: omap3-beagle-xm.dts: add display information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 118 ++
1 file changed, 118 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index df33a50bc070..60430e8229a9 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -94,6 +94,17 @@
0x0e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE4) /*
sys_boot2.gpio_4 */
;
};
+
+ dss_dpi_pins2: pinmux_dss_dpi_pins {
+ pinctrl-single,pins =
+ 0x0a (PIN_OUTPUT | MUX_MODE3) /* sys_boot0.dss_data18
*/
+ 0x0c (PIN_OUTPUT | MUX_MODE3) /* sys_boot1.dss_data19
*/
+ 0x10 (PIN_OUTPUT | MUX_MODE3) /* sys_boot3.dss_data20
*/
+ 0x12 (PIN_OUTPUT | MUX_MODE3) /* sys_boot4.dss_data21
*/
+ 0x14 (PIN_OUTPUT | MUX_MODE3) /* sys_boot5.dss_data22
*/
+ 0x16 (PIN_OUTPUT | MUX_MODE3) /* sys_boot6.dss_data23
*/
+ ;
+ };
};
omap3_pmx_core {
@@ -125,6 +136,35 @@
0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
;
};
+
+ dss_dpi_pins1: pinmux_dss_dpi_pins {
+ pinctrl-single,pins =
+ 0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
+ 0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync
*/
+ 0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync
*/
+ 0x0aa (PIN_OUTPUT | MUX_MODE0) /*
dss_acbias.dss_acbias */
+
+ 0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6
*/
+ 0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7
*/
+ 0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8
*/
+ 0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9
*/
+ 0x0c0 (PIN_OUTPUT | MUX_MODE0) /*
dss_data10.dss_data10 */
+ 0x0c2 (PIN_OUTPUT | MUX_MODE0) /*
dss_data11.dss_data11 */
+ 0x0c4 (PIN_OUTPUT | MUX_MODE0) /*
dss_data12.dss_data12 */
+ 0x0c6 (PIN_OUTPUT | MUX_MODE0) /*
dss_data13.dss_data13 */
+ 0x0c8 (PIN_OUTPUT | MUX_MODE0) /*
dss_data14.dss_data14 */
+ 0x0ca (PIN_OUTPUT | MUX_MODE0) /*
dss_data15.dss_data15 */
+ 0x0cc (PIN_OUTPUT | MUX_MODE0) /*
dss_data16.dss_data16 */
+ 0x0ce (PIN_OUTPUT | MUX_MODE0) /*
dss_data17.dss_data17 */
+
+ 0x0d0 (PIN_OUTPUT | MUX_MODE3) /*
dss_data18.dss_data0 */
+ 0x0d2 (PIN_OUTPUT | MUX_MODE3) /*
dss_data19.dss_data1 */
+ 0x0d4 (PIN_OUTPUT | MUX_MODE3) /*
dss_data20.dss_data2 */
+ 0x0d6 (PIN_OUTPUT | MUX_MODE3) /*
dss_data21.dss_data3 */
+ 0x0d8 (PIN_OUTPUT | MUX_MODE3) /*
dss_data22.dss_data4 */
+ 0x0da (PIN_OUTPUT | MUX_MODE3) /*
dss_data23.dss_data5 */
+ ;
+ };
};
i2c1 {
@@ -222,3 +262,81 @@
regulator-max-microvolt = 180;
regulator-always-on;
};
+
+dss {
+ pinctrl-names = default;
+ pinctrl-0 =
+ dss_dpi_pins1
+ dss_dpi_pins2
+ ;
+
+ vdds_dsi-supply = vpll2;
+
+ dpi_out: endpoint {
+ remote-endpoint = tfp410_in;
+ data-lines = 24;
+ };
+};
+
+venc {
+ vdda_dac-supply = vdac;
+
+ venc_out: endpoint {
+ remote-endpoint = tv_connector_in;
+ };
+};
+
+/ {
+ aliases {
+ display0 = dvi0;
+ display1 = tv0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = ti,tfp410;
+ gpios = twl_gpio 2 GPIO_ACTIVE_LOW;
+
+ /* XXX pinctrl from twl */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = dpi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tfp410_out: endpoint@0 {
+ remote-endpoint = dvi_connector_in;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = dvi-connector;
+ label = dvi;
+
+ i2c-bus = i2c3;
+
+ dvi_connector_in: endpoint {
+
[PATCHv2 00/27] OMAPDSS: DT support v2
Hi, Here's version 2 of the DSS DT series. Hopefully I have fixed all the issues that were found with v1 (http://article.gmane.org/gmane.linux.ports.arm.omap/108249), except missing binding documentation and lacking patch descriptions. The main changes are: - DPI and SDI are no longer dummy devices, but ports on the DSS node. This reflects better the actual hardware. - Pinmuxing - Labels for displays Additionally smaller changes, like using symbolic names in the .dts files, fixing endpoint numbering, etc. This series can also be found from: git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-review-2 Tomi Javier Martinez Canillas (1): ARM: omap3-igep0020.dts: add display information Tomi Valkeinen (26): ARM: OMAP: remove DSS DT hack OMAPDSS: remove DT hacks for regulators ARM: OMAP2+: add omapdss_init_of() OMAPDSS: add 'label' support for DT OMAPDSS: get dssdev-alias from DT alias OMAPFB: clean up default display search OMAPFB: search for default display with DT alias OMAPDSS: add of helpers OMAPDSS: Add DT support to DSS, DISPC, DPI and SDI. OMAPDSS: Add DT support to HDMI OMAPDSS: Add DT support to VENC OMAPDSS: Add DT support to DSI ARM: omap3.dtsi: add omapdss information ARM: omap4.dtsi: add omapdss information ARM: omap4-panda.dts: add display information ARM: omap4-sdp.dts: add display information ARM: omap3-tobi.dts: add lcd (TEST) ARM: omap3-beagle.dts: add display information ARM: omap3-beagle-xm.dts: add display information OMAPDSS: panel-dsi-cm: Add DT support OMAPDSS: encoder-tfp410: Add DT support OMAPDSS: connector-dvi: Add DT support OMAPDSS: encoder-tpd12s015: Add DT support OMAPDSS: hdmi-connector: Add DT support OMAPDSS: panel-dpi: Add DT support OMAPDSS: connector-analog-tv: Add DT support arch/arm/boot/dts/omap3-beagle-xm.dts | 118 ++ arch/arm/boot/dts/omap3-beagle.dts | 115 + arch/arm/boot/dts/omap3-igep0020.dts | 64 - arch/arm/boot/dts/omap3-tobi.dts | 47 arch/arm/boot/dts/omap3.dtsi | 35 +++ arch/arm/boot/dts/omap4-panda-common.dtsi | 121 +- arch/arm/boot/dts/omap4-sdp.dts| 116 + arch/arm/boot/dts/omap4.dtsi | 54 + arch/arm/mach-omap2/Makefile | 2 +- arch/arm/mach-omap2/board-generic.c| 2 + arch/arm/mach-omap2/common.h | 2 + arch/arm/mach-omap2/display.c | 62 + arch/arm/mach-omap2/dss-common.c | 259 - arch/arm/mach-omap2/dss-common.h | 13 -- arch/arm/mach-omap2/pdata-quirks.c | 4 - .../video/omap2/displays-new/connector-analog-tv.c | 66 +- drivers/video/omap2/displays-new/connector-dvi.c | 43 drivers/video/omap2/displays-new/connector-hdmi.c | 30 +++ drivers/video/omap2/displays-new/encoder-tfp410.c | 43 +++- .../video/omap2/displays-new/encoder-tpd12s015.c | 56 + drivers/video/omap2/displays-new/panel-dpi.c | 64 - drivers/video/omap2/displays-new/panel-dsi-cm.c| 65 +- drivers/video/omap2/dss/Makefile | 2 +- drivers/video/omap2/dss/dispc.c| 7 + drivers/video/omap2/dss/display.c | 28 ++- drivers/video/omap2/dss/dpi.c | 47 drivers/video/omap2/dss/dsi.c | 141 ++- drivers/video/omap2/dss/dss-of.c | 162 + drivers/video/omap2/dss/dss.c | 63 + drivers/video/omap2/dss/dss.h | 6 + drivers/video/omap2/dss/hdmi4.c| 10 +- drivers/video/omap2/dss/sdi.c | 45 drivers/video/omap2/dss/venc.c | 34 +++ drivers/video/omap2/omapfb/omapfb-main.c | 67 -- include/video/omapdss.h| 14 ++ 35 files changed, 1685 insertions(+), 322 deletions(-) delete mode 100644 arch/arm/mach-omap2/dss-common.c delete mode 100644 arch/arm/mach-omap2/dss-common.h create mode 100644 drivers/video/omap2/dss/dss-of.c -- 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
[PATCHv2 11/27] OMAPDSS: Add DT support to VENC
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/venc.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 5f88ac47b7fa..12185fb6da0e 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -34,6 +34,7 @@
#include linux/platform_device.h
#include linux/regulator/consumer.h
#include linux/pm_runtime.h
+#include linux/of.h
#include video/omapdss.h
@@ -804,6 +805,22 @@ static void __exit venc_uninit_output(struct
platform_device *pdev)
omapdss_unregister_output(out);
}
+static int venc_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct device_node *ep;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return 0;
+
+ venc.invert_polarity = of_property_read_bool(ep, invert-polarity);
+
+ of_node_put(ep);
+
+ return 0;
+}
+
/* VENC HW IP initialisation */
static int omap_venchw_probe(struct platform_device *pdev)
{
@@ -845,12 +862,21 @@ static int omap_venchw_probe(struct platform_device *pdev)
venc_runtime_put();
+ if (pdev-dev.of_node) {
+ r = venc_probe_of(pdev);
+ if (r) {
+ DSSERR(Invalid DT data\n);
+ goto err_probe_of;
+ }
+ }
+
dss_debugfs_create_file(venc, venc_dump_regs);
venc_init_output(pdev);
return 0;
+err_probe_of:
err_runtime_get:
pm_runtime_disable(pdev-dev);
return r;
@@ -894,6 +920,13 @@ static const struct dev_pm_ops venc_pm_ops = {
.runtime_resume = venc_runtime_resume,
};
+
+static const struct of_device_id venc_of_match[] = {
+ { .compatible = ti,omap3-venc, },
+ { .compatible = ti,omap4-venc, },
+ {},
+};
+
static struct platform_driver omap_venchw_driver = {
.probe = omap_venchw_probe,
.remove = __exit_p(omap_venchw_remove),
@@ -901,6 +934,7 @@ static struct platform_driver omap_venchw_driver = {
.name = omapdss_venc,
.owner = THIS_MODULE,
.pm = venc_pm_ops,
+ .of_match_table = venc_of_match,
},
};
--
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
[PATCHv2 26/27] OMAPDSS: panel-dpi: Add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/panel-dpi.c | 64 +++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/panel-dpi.c
b/drivers/video/omap2/displays-new/panel-dpi.c
index 5f8f7e7c81ef..f1653042c21d 100644
--- a/drivers/video/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/omap2/displays-new/panel-dpi.c
@@ -13,9 +13,12 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
+#include linux/of.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-data.h
+#include video/of_display_timing.h
struct panel_drv_data {
struct omap_dss_device dssdev;
@@ -70,7 +73,8 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in-ops.dpi-set_data_lines(in, ddata-data_lines);
+ if (ddata-data_lines)
+ in-ops.dpi-set_data_lines(in, ddata-data_lines);
in-ops.dpi-set_timings(in, ddata-videomode);
r = in-ops.dpi-enable(in);
@@ -182,6 +186,52 @@ static int panel_dpi_probe_pdata(struct platform_device
*pdev)
return 0;
}
+static int panel_dpi_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ int r;
+ struct display_timing timing;
+ struct videomode vm;
+ int gpio;
+
+ gpio = of_get_gpio(node, 0);
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata-enable_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse enable gpio\n);
+ return gpio;
+ }
+
+ gpio = of_get_gpio(node, 1);
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata-backlight_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse backlight gpio\n);
+ return gpio;
+ }
+
+ r = of_get_display_timing(node, panel-timing, timing);
+ if (r) {
+ dev_err(pdev-dev, failed to get video timing\n);
+ return r;
+ }
+
+ videomode_from_timing(timing, vm);
+ videomode_to_omap_video_timings(vm, ddata-videomode);
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ return 0;
+}
+
static int panel_dpi_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -198,6 +248,10 @@ static int panel_dpi_probe(struct platform_device *pdev)
r = panel_dpi_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = panel_dpi_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -254,12 +308,20 @@ static int __exit panel_dpi_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id panel_dpi_of_match[] = {
+ { .compatible = panel-dpi, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, panel_dpi_of_match);
+
static struct platform_driver panel_dpi_driver = {
.probe = panel_dpi_probe,
.remove = __exit_p(panel_dpi_remove),
.driver = {
.name = panel-dpi,
.owner = THIS_MODULE,
+ .of_match_table = panel_dpi_of_match,
},
};
--
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
[PATCHv2 22/27] OMAPDSS: encoder-tfp410: Add DT support
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/encoder-tfp410.c | 43 ++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/encoder-tfp410.c
b/drivers/video/omap2/displays-new/encoder-tfp410.c
index 4a291e756be9..2c664d476788 100644
--- a/drivers/video/omap2/displays-new/encoder-tfp410.c
+++ b/drivers/video/omap2/displays-new/encoder-tfp410.c
@@ -13,6 +13,7 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -82,7 +83,8 @@ static int tfp410_enable(struct omap_dss_device *dssdev)
return 0;
in-ops.dpi-set_timings(in, ddata-timings);
- in-ops.dpi-set_data_lines(in, ddata-data_lines);
+ if (ddata-data_lines)
+ in-ops.dpi-set_data_lines(in, ddata-data_lines);
r = in-ops.dpi-enable(in);
if (r)
@@ -179,6 +181,33 @@ static int tfp410_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tfp410_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev-dev.of_node;
+ struct omap_dss_device *in;
+ int gpio;
+
+ gpio = of_get_gpio(node, 0);
+
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata-pd_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse PD gpio\n);
+ return gpio;
+ }
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ return 0;
+}
+
static int tfp410_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -195,6 +224,10 @@ static int tfp410_probe(struct platform_device *pdev)
r = tfp410_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = tfp410_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -251,12 +284,20 @@ static int __exit tfp410_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id tfp410_of_match[] = {
+ { .compatible = ti,tfp410, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, tfp410_of_match);
+
static struct platform_driver tfp410_driver = {
.probe = tfp410_probe,
.remove = __exit_p(tfp410_remove),
.driver = {
.name = tfp410,
.owner = THIS_MODULE,
+ .of_match_table = tfp410_of_match,
},
};
--
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
[PATCHv2 08/27] OMAPDSS: add of helpers
Add helpers to get ports and endpoints from DT data.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/Makefile | 2 +-
drivers/video/omap2/dss/dss-of.c | 162 +++
include/video/omapdss.h | 14
3 files changed, 177 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/omap2/dss/dss-of.c
diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index d3aa91bdd6a8..8aec8bda27cc 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -1,7 +1,7 @@
obj-$(CONFIG_OMAP2_DSS) += omapdss.o
# Core DSS files
omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
- output.o
+ output.o dss-of.o
# DSS compat layer files
omapdss-y += manager.o manager-sysfs.o overlay.o overlay-sysfs.o apply.o \
dispc-compat.o display-sysfs.o
diff --git a/drivers/video/omap2/dss/dss-of.c b/drivers/video/omap2/dss/dss-of.c
new file mode 100644
index ..59213cf2ffa2
--- /dev/null
+++ b/drivers/video/omap2/dss/dss-of.c
@@ -0,0 +1,162 @@
+/*
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Tomi Valkeinen tomi.valkei...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include linux/device.h
+#include linux/err.h
+#include linux/module.h
+#include linux/of.h
+#include linux/seq_file.h
+
+#include video/omapdss.h
+
+#include dss.h
+#include dss_features.h
+
+struct device_node *
+omapdss_of_get_next_port(const struct device_node *parent,
+struct device_node *prev)
+{
+ struct device_node *port = NULL;
+
+ if (!parent)
+ return NULL;
+
+ if (!prev) {
+ struct device_node *ports;
+ /*
+* It's the first call, we have to find a port subnode
+* within this node or within an optional 'ports' node.
+*/
+ ports = of_get_child_by_name(parent, ports);
+ if (ports)
+ parent = ports;
+
+ port = of_get_child_by_name(parent, port);
+
+ /* release the 'ports' node */
+ of_node_put(ports);
+ } else {
+ struct device_node *ports;
+
+ ports = of_get_parent(prev);
+ if (!ports)
+ return NULL;
+
+ do {
+ port = of_get_next_child(ports, prev);
+ if (!port) {
+ of_node_put(ports);
+ return NULL;
+ }
+ prev = port;
+ } while (of_node_cmp(port-name, port) != 0);
+ }
+
+ return port;
+}
+EXPORT_SYMBOL_GPL(omapdss_of_get_next_port);
+
+struct device_node *
+omapdss_of_get_next_endpoint(const struct device_node *parent,
+struct device_node *prev)
+{
+ struct device_node *ep = NULL;
+
+ if (!parent)
+ return NULL;
+
+ do {
+ ep = of_get_next_child(parent, prev);
+ if (!ep)
+ return NULL;
+ prev = ep;
+ } while (of_node_cmp(ep-name, endpoint) != 0);
+
+ return ep;
+}
+EXPORT_SYMBOL_GPL(omapdss_of_get_next_endpoint);
+
+static struct device_node *
+omapdss_of_get_remote_device_node(const struct device_node *node)
+{
+ struct device_node *np;
+ int i;
+
+ np = of_parse_phandle(node, remote-endpoint, 0);
+
+ if (!np)
+ return NULL;
+
+ np = of_get_next_parent(np);
+
+ for (i = 0; i 3 np; ++i) {
+ struct property *prop;
+
+ prop = of_find_property(np, compatible, NULL);
+
+ if (prop)
+ return np;
+
+ np = of_get_next_parent(np);
+ }
+
+ return NULL;
+}
+
+struct device_node *
+omapdss_of_get_first_endpoint(const struct device_node *parent)
+{
+ struct device_node *port;
+ struct device_node *ep;
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (port) {
+ ep = omapdss_of_get_next_endpoint(port, NULL);
+ of_node_put(port);
+ } else {
+ ep = omapdss_of_get_next_endpoint(parent, NULL);
+ }
+
+ return ep;
+}
+EXPORT_SYMBOL_GPL(omapdss_of_get_first_endpoint);
+
+struct omap_dss_device *
+omapdss_of_find_source_for_first_ep(struct device_node *node)
+{
+ struct device_node *ep;
+ struct device_node *src_node;
+ struct
[PATCHv2 04/27] OMAPDSS: add 'label' support for DT
Add support to get the label (i.e. a nickname) for a display from the DT data. If there is no label defined, use the display's alias (e.g. 'display0') as a name. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/display.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c index 669a81fdf58e..012ada38a29d 100644 --- a/drivers/video/omap2/dss/display.c +++ b/drivers/video/omap2/dss/display.c @@ -26,6 +26,7 @@ #include linux/module.h #include linux/jiffies.h #include linux/platform_device.h +#include linux/of.h #include video/omapdss.h #include dss.h @@ -137,6 +138,14 @@ int omapdss_register_display(struct omap_dss_device *dssdev) snprintf(dssdev-alias, sizeof(dssdev-alias), display%d, disp_num_counter++); + /* Use 'label' property for name, if it exists */ + if (dssdev-dev-of_node) + of_property_read_string(dssdev-dev-of_node, label, + dssdev-name); + + if (dssdev-name == NULL) + dssdev-name = dssdev-alias; + if (drv drv-get_resolution == NULL) drv-get_resolution = omapdss_default_get_resolution; if (drv drv-get_recommended_bpp == NULL) -- 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] cpufreq: omap: clk_round_rate() can return a zero upon error
On Monday 09 December 2013 09:18 PM, Paul Walmsley wrote: Treat both negative and zero return values from clk_round_rate() as errors. This is needed since subsequent patches will convert clk_round_rate()'s return value to be an unsigned type, rather than a signed type, since some clock sources can generate rates higher than (2^31)-1 Hz. Eventually, when calling clk_round_rate(), only a return value of zero will be considered a error. All other values will be considered valid rates. The comparison against values less than 0 is kept to preserve the correct behavior in the meantime. This patch also removes a bogus usage of IS_ERR_VALUE(), which is intended to be used only on combination pointer/error code return values; a side-benefit. Signed-off-by: Paul Walmsley pwalms...@nvidia.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Viresh Kumar viresh.ku...@linaro.org --- Acked-by: Santosh Shilimkar santosh.shilim...@ti.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
[PATCHv2 03/27] ARM: OMAP2+: add omapdss_init_of()
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-generic.c | 2 ++
arch/arm/mach-omap2/common.h| 2 ++
arch/arm/mach-omap2/display.c | 62 +
3 files changed, 66 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 8d972ff18c56..842e4f21ab09 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -36,6 +36,8 @@ static struct of_device_id omap_dt_match_table[] __initdata =
{
static void __init omap_generic_init(void)
{
pdata_quirks_init(omap_dt_match_table);
+
+ omapdss_init_of();
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index e30ef6797c63..04a4d360dd20 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -307,5 +307,7 @@ extern int omap_dss_reset(struct omap_hwmod *);
/* SoC specific clock initializer */
extern int (*omap_clk_init)(void);
+int __init omapdss_init_of(void);
+
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 58347bb874a0..197f431ae279 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
#include linux/clk.h
#include linux/err.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_platform.h
#include video/omapdss.h
#include omap_hwmod.h
@@ -514,3 +516,63 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
+
+int __init omapdss_init_of(void)
+{
+ int r;
+ enum omapdss_version ver;
+
+ static struct omap_dss_board_info board_data = {
+ .dsi_enable_pads = omap_dsi_enable_pads,
+ .dsi_disable_pads = omap_dsi_disable_pads,
+ .get_context_loss_count = omap_pm_get_dev_context_loss_count,
+ .set_min_bus_tput = omap_dss_set_min_bus_tput,
+ };
+
+ ver = omap_display_get_version();
+
+ if (ver == OMAPDSS_VER_UNKNOWN) {
+ pr_err(DSS not supported on this SoC\n);
+ return -ENODEV;
+ }
+
+ board_data.version = ver;
+
+ omap_display_device.dev.platform_data = board_data;
+
+ r = platform_device_register(omap_display_device);
+ if (r 0) {
+ pr_err(Unable to register omapdss device\n);
+ return r;
+ }
+
+ /* create DRM device */
+ r = omap_init_drm();
+ if (r 0) {
+ pr_err(Unable to register omapdrm device\n);
+ return r;
+ }
+
+ /* create vrfb device */
+ r = omap_init_vrfb();
+ if (r 0) {
+ pr_err(Unable to register omapvrfb device\n);
+ return r;
+ }
+
+ /* create FB device */
+ r = omap_init_fb();
+ if (r 0) {
+ pr_err(Unable to register omapfb device\n);
+ return r;
+ }
+
+ /* create V4L2 display device */
+ r = omap_init_vout();
+ if (r 0) {
+ pr_err(Unable to register omap_vout device\n);
+ return r;
+ }
+
+ return 0;
+}
--
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
[PATCHv2 16/27] ARM: omap4-sdp.dts: add display information
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/boot/dts/omap4-sdp.dts | 116
1 file changed, 116 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index c13ada99e0bc..bdfab844533b 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -309,6 +309,22 @@
0x112 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc5_dat3.sdmmc5_dat3 */
;
};
+
+ dss_hdmi_pins: pinmux_dss_hdmi_pins {
+ pinctrl-single,pins =
+ 0x5a (PIN_INPUT_PULLUP | MUX_MODE0) /*
hdmi_cec.hdmi_cec */
+ 0x5c (PIN_INPUT_PULLUP | MUX_MODE0) /*
hdmi_scl.hdmi_scl */
+ 0x5e (PIN_INPUT_PULLUP | MUX_MODE0) /*
hdmi_sda.hdmi_sda */
+ ;
+ };
+
+ tpd12s015_pins: pinmux_tpd12s015_pins {
+ pinctrl-single,pins =
+ 0x22 (PIN_OUTPUT | MUX_MODE3) /*
gpmc_a17.gpio_41 */
+ 0x48 (PIN_OUTPUT | MUX_MODE3) /*
gpmc_nbe1.gpio_60 */
+ 0x58 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
hdmi_hpd.gpio_63 */
+ ;
+ };
};
i2c1 {
@@ -551,3 +567,103 @@
mode = 3;
power = 50;
};
+
+dsi1 {
+ vdds_dsi-supply = vcxio;
+
+ dsi1_out_ep: endpoint {
+ remote-endpoint = lcd0_in;
+ lanes = 0 1 2 3 4 5;
+ };
+
+ lcd0: display {
+ compatible = tpo,taal, panel-dsi-cm;
+ label = lcd0;
+
+ gpios = gpio4 6 GPIO_ACTIVE_HIGH;/* 102, reset */
+
+ lcd0_in: endpoint {
+ remote-endpoint = dsi1_out_ep;
+ };
+ };
+};
+
+dsi2 {
+ vdds_dsi-supply = vcxio;
+
+ dsi2_out_ep: endpoint {
+ remote-endpoint = lcd1_in;
+ lanes = 0 1 2 3 4 5;
+ };
+
+ lcd1: display {
+ compatible = tpo,taal, panel-dsi-cm;
+ label = lcd1;
+
+ gpios = gpio4 8 GPIO_ACTIVE_HIGH;/* 104, reset */
+
+ lcd1_in: endpoint {
+ remote-endpoint = dsi2_out_ep;
+ };
+ };
+};
+
+hdmi {
+ vdda_hdmi_dac-supply = vdac;
+
+ pinctrl-names = default;
+ pinctrl-0 = dss_hdmi_pins;
+
+ hdmi_out: endpoint {
+ remote-endpoint = tpd12s015_in;
+ };
+};
+
+/ {
+ aliases {
+ display0 = lcd0;
+ display1 = lcd1;
+ display2 = hdmi0;
+ };
+
+ tpd12s015: encoder@0 {
+ compatible = ti,tpd12s015;
+
+ pinctrl-names = default;
+ pinctrl-0 = tpd12s015_pins;
+
+ gpios = gpio2 28 GPIO_ACTIVE_HIGH, /* 60, CT CP HPD */
+ gpio2 9 GPIO_ACTIVE_HIGH,/* 41, LS OE */
+ gpio2 31 GPIO_ACTIVE_HIGH; /* 63, HPD */
+
+ ports {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ port@0 {
+ reg = 0;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = hdmi_out;
+ };
+ };
+
+ port@1 {
+ reg = 1;
+
+ tpd12s015_out: endpoint@0 {
+ remote-endpoint = hdmi_connector_in;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@0 {
+ compatible = hdmi-connector;
+ label = hdmi;
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = tpd12s015_out;
+ };
+ };
+};
--
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
[PATCHv2 07/27] OMAPFB: search for default display with DT alias
Improve the search for the default display in two ways:
* compare the given display name to the display's alias
* if no display name is given, look for display0 DT alias
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 8bfe973e55ec..961c5c251f63 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2413,7 +2413,10 @@ omapfb_find_default_display(struct omapfb2_device *fbdev)
const char *def_name;
int i;
- /* search with the display name from the user or the board file */
+ /*
+* Search with the display name from the user or the board file,
+* comparing to display names and aliases
+*/
def_name = omapdss_get_default_display_name();
@@ -2425,12 +2428,30 @@ omapfb_find_default_display(struct omapfb2_device
*fbdev)
if (dssdev-name strcmp(def_name, dssdev-name) == 0)
return dssdev;
+
+ if (strcmp(def_name, dssdev-alias) == 0)
+ return dssdev;
}
/* def_name given but not found */
return NULL;
}
+ /* then look for DT alias display0 */
+ for (i = 0; i fbdev-num_displays; ++i) {
+ struct omap_dss_device *dssdev;
+ int id;
+
+ dssdev = fbdev-displays[i].dssdev;
+
+ if (dssdev-dev-of_node == NULL)
+ continue;
+
+ id = of_alias_get_id(dssdev-dev-of_node, display);
+ if (id == 0)
+ return dssdev;
+ }
+
/* return the first display we have in the list */
return fbdev-displays[0].dssdev;
}
--
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
[PATCHv2 21/27] OMAPDSS: panel-dsi-cm: Add DT support
XXX ULPS and backlight missing.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/panel-dsi-cm.c | 65 +++--
1 file changed, 61 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/displays-new/panel-dsi-cm.c
b/drivers/video/omap2/displays-new/panel-dsi-cm.c
index b7baafe83aa3..fda7728bdfaa 100644
--- a/drivers/video/omap2/displays-new/panel-dsi-cm.c
+++ b/drivers/video/omap2/displays-new/panel-dsi-cm.c
@@ -22,6 +22,8 @@
#include linux/sched.h
#include linux/slab.h
#include linux/workqueue.h
+#include linux/of_device.h
+#include linux/of_gpio.h
#include video/omapdss.h
#include video/omap-panel-data.h
@@ -595,10 +597,13 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
.lp_clk_max = 1000,
};
- r = in-ops.dsi-configure_pins(in, ddata-pin_config);
- if (r) {
- dev_err(ddata-pdev-dev, failed to configure DSI pins\n);
- goto err0;
+ if (ddata-pin_config.num_pins 0) {
+ r = in-ops.dsi-configure_pins(in, ddata-pin_config);
+ if (r) {
+ dev_err(ddata-pdev-dev,
+ failed to configure DSI pins\n);
+ goto err0;
+ }
}
r = in-ops.dsi-set_config(in, dsi_config);
@@ -1156,6 +1161,46 @@ static int dsicm_probe_pdata(struct platform_device
*pdev)
return 0;
}
+static int dsicm_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct omap_dss_device *in;
+ int gpio;
+
+ gpio = of_get_gpio(node, 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(pdev-dev, failed to parse reset gpio\n);
+ return gpio;
+ }
+ ddata-reset_gpio = gpio;
+
+ if (of_gpio_count(node) 1) {
+ gpio = of_get_gpio(node, 1);
+
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata-ext_te_gpio = gpio;
+ } else {
+ dev_err(pdev-dev, failed to parse TE gpio\n);
+ return gpio;
+ }
+ } else {
+ ddata-ext_te_gpio = -1;
+ }
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(pdev-dev, failed to find video source\n);
+ return PTR_ERR(in);
+ }
+
+ ddata-in = in;
+
+ /* TODO: ulps, backlight */
+
+ return 0;
+}
+
static int dsicm_probe(struct platform_device *pdev)
{
struct backlight_properties props;
@@ -1178,6 +1223,10 @@ static int dsicm_probe(struct platform_device *pdev)
r = dsicm_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev-dev.of_node) {
+ r = dsicm_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -1320,12 +1369,20 @@ static int __exit dsicm_remove(struct platform_device
*pdev)
return 0;
}
+static const struct of_device_id dsicm_of_match[] = {
+ { .compatible = panel-dsi-cm, },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, dsicm_of_match);
+
static struct platform_driver dsicm_driver = {
.probe = dsicm_probe,
.remove = __exit_p(dsicm_remove),
.driver = {
.name = panel-dsi-cm,
.owner = THIS_MODULE,
+ .of_match_table = dsicm_of_match,
},
};
--
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] omap: twl-common: Fix musb-hdrc device name.
On Monday 16 December 2013 02:22 PM, Kishon Vijay Abraham I wrote: Hi, On Friday 13 December 2013 11:06 PM, Tony Lindgren wrote: * Kishon Vijay Abraham I kis...@ti.com [131213 03:57]: On Friday 13 December 2013 04:57 PM, Belisko Marek wrote: Kishon can you please comment on that? Would be possible to get your patch to 3.13 (I seen some comments from Felipe). I'm not sure as my patch modifies all the board files. There was initially some confusion w.r.t when the board files will be dropped. But since board files will still be there in 3.13, I'd recommend my patch [1] to be taken. Anyways if you have tested my patch (series), pls give your Tested-by. Tony, summary of the issue.. After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. So had to make the corresponding changes in board files. OK. Can you please repost with a proper commit id for what caused the regression and summararize why it should be fixed this way. Something like: Commit abcd1234 (usb: blah foo bar) caused blah blah blah. Fix the issue with blah blah blah. Note that the board-*.c files will be removed soon, but for v3.13 we still support both legacy booting and device tree based booting and need to fix it. huh.. I think we can have a much simpler fix. All this binding in board file was introduced to support platforms that has multiple PHYs of the same type. But musb/omap2430.c serves platforms that has only one PHY of a particular type. We can just go back to usb_get_phy(enum usb_phy_type type) instead of 'usb_get_phy_dev' in omap2430.c. Felipe, what do you think? Never-mind, that doesn't work. I'll just re-send the patch the way you suggested. Cheers Kishon Cheers Kishon Regards, Tony [1] - http://lists.scusting.com/index.php?t=msgth=375579start=0S=Google -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 01/15] mfd: menelaus: Drop __exit section annotation
Are you planning on re-submitting this patch-set anytime soon? I thought Tony said it was important? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org â Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 2/2] arm: omap: remove *.auto* from device names given in usb_bind_phy
commit 2f7711 (usb: musb: remove hand-crafted id handling) used PLATFORM_DEVID_AUTO while creating MUSB core device. So commit 51482b (ARM: OMAP: USB: Add phy binding information) added usb_bind_phy (binds the controller with the PHY) in the board files, with *.auto* in the device name of the controller. Since other devices started using PLATFORM_DEVID_AUTO, the index in the device name given in usb_bind_phy changed making the data given in usb_bind_phy obsolete and usb_get_phy started failing. So MUSB wrapper was modified not to use PLATFORM_DEVID_AUTO. Corresponding change is done in board file here. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com --- arch/arm/mach-omap2/board-2430sdp.c|2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3logic.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3stalker.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- 12 files changed, 12 insertions(+), 12 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index c711ad6..cc679c6 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -246,7 +246,7 @@ static void __init omap_2430sdp_init(void) omap_hsmmc_init(mmc); omap_mux_init_signal(usb0hs_stp, OMAP_PULL_ENA | OMAP_PULL_UP); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); + usb_bind_phy(musb-hdrc.0, 0, twl4030_usb); usb_musb_init(NULL); board_smc91x_init(); diff --git a/arch/arm/mach-omap2/board-3430sdp.c b/arch/arm/mach-omap2/board-3430sdp.c index d95d0ef..873e463 100644 --- a/arch/arm/mach-omap2/board-3430sdp.c +++ b/arch/arm/mach-omap2/board-3430sdp.c @@ -607,7 +607,7 @@ static void __init omap_3430sdp_init(void) omap_ads7846_init(1, gpio_pendown, 310, NULL); omap_serial_init(); omap_sdrc_init(hyb18m512160af6_sdrc_params, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); + usb_bind_phy(musb-hdrc.0, 0, twl4030_usb); usb_musb_init(NULL); board_smc91x_init(); board_flash_init(sdp_flash_partitions, chip_sel_3430, 0); diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index 8dd0ec8..ddcadfa 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -725,7 +725,7 @@ static void __init cm_t3x_common_init(void) cm_t35_init_display(); omap_twl4030_audio_init(cm-t3x, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); + usb_bind_phy(musb-hdrc.0, 0, twl4030_usb); usb_musb_init(NULL); cm_t35_init_usbh(); cm_t35_init_camera(); diff --git a/arch/arm/mach-omap2/board-devkit8000.c b/arch/arm/mach-omap2/board-devkit8000.c index cdc4fb9..bb589f1 100644 --- a/arch/arm/mach-omap2/board-devkit8000.c +++ b/arch/arm/mach-omap2/board-devkit8000.c @@ -628,7 +628,7 @@ static void __init devkit8000_init(void) omap_ads7846_init(2, OMAP3_DEVKIT_TS_GPIO, 0, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); + usb_bind_phy(musb-hdrc.0, 0, twl4030_usb); usb_musb_init(NULL); usbhs_init(usbhs_bdata); board_nand_init(devkit8000_nand_partitions, diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c index 4ec8d82..ec9b349 100644 --- a/arch/arm/mach-omap2/board-ldp.c +++ b/arch/arm/mach-omap2/board-ldp.c @@ -402,7 +402,7 @@ static void __init omap_ldp_init(void) omap_ads7846_init(1, 54, 310, NULL); omap_serial_init(); omap_sdrc_init(NULL, NULL); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); + usb_bind_phy(musb-hdrc.0, 0, twl4030_usb); usb_musb_init(NULL); board_nand_init(ldp_nand_partitions, ARRAY_SIZE(ldp_nand_partitions), 0, 0, nand_default_timings); diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c index d6ed819..0cba5eb 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -561,7 +561,7 @@ static void __init omap3_beagle_init(void) omap_sdrc_init(mt46h32m32lf6_sdrc_params, mt46h32m32lf6_sdrc_params); - usb_bind_phy(musb-hdrc.0.auto, 0, twl4030_usb); + usb_bind_phy(musb-hdrc.0, 0, twl4030_usb); usb_musb_init(NULL); usbhs_init(usbhs_bdata); diff --git a/arch/arm/mach-omap2/board-omap3logic.c b/arch/arm/mach-omap2/board-omap3logic.c index bab51e6..d9a6c38 100644 --- a/arch/arm/mach-omap2/board-omap3logic.c +++
[PATCH v3 1/2] usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c
commit 2f7711 (usb: musb: remove hand-crafted id handling) used
PLATFORM_DEVID_AUTO while creating MUSB core device.
After the platform devices are created using PLATFORM_DEVID_AUTO, the
device names given in usb_bind_phy (in board file) does not match with
the actual device name causing the USB PHY library not to return the
PHY reference when the MUSB controller request for the PHY in the non-dt boot
case.
So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
drivers/usb/musb/musb_core.c | 31 ++-
drivers/usb/musb/musb_core.h |2 ++
drivers/usb/musb/omap2430.c | 19 +--
3 files changed, 49 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 0a43329..aaf734c 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -94,6 +94,7 @@
#include linux/sched.h
#include linux/slab.h
#include linux/init.h
+#include linux/idr.h
#include linux/list.h
#include linux/kobject.h
#include linux/prefetch.h
@@ -120,7 +121,7 @@ MODULE_DESCRIPTION(DRIVER_INFO);
MODULE_AUTHOR(DRIVER_AUTHOR);
MODULE_LICENSE(GPL);
MODULE_ALIAS(platform: MUSB_DRIVER_NAME);
-
+static DEFINE_IDA(musb_ida);
/*-*/
@@ -131,6 +132,34 @@ static inline struct musb *dev_to_musb(struct device *dev)
/*-*/
+int musb_get_id(struct device *dev, gfp_t gfp_mask)
+{
+ int ret;
+ int id;
+
+ ret = ida_pre_get(musb_ida, gfp_mask);
+ if (!ret) {
+ dev_err(dev, failed to reserve resource for id\n);
+ return -ENOMEM;
+ }
+
+ ret = ida_get_new(musb_ida, id);
+ if (ret 0) {
+ dev_err(dev, failed to allocate a new id\n);
+ return ret;
+ }
+
+ return id;
+}
+EXPORT_SYMBOL_GPL(musb_get_id);
+
+void musb_put_id(struct device *dev, int id)
+{
+ dev_dbg(dev, removing id %d\n, id);
+ ida_remove(musb_ida, id);
+}
+EXPORT_SYMBOL_GPL(musb_put_id);
+
#ifndef CONFIG_BLACKFIN
static int musb_ulpi_read(struct usb_phy *phy, u32 offset)
{
diff --git a/drivers/usb/musb/musb_core.h b/drivers/usb/musb/musb_core.h
index 29f7cd7..63614283 100644
--- a/drivers/usb/musb/musb_core.h
+++ b/drivers/usb/musb/musb_core.h
@@ -506,6 +506,8 @@ extern const char musb_driver_name[];
extern void musb_stop(struct musb *musb);
extern void musb_start(struct musb *musb);
+int musb_get_id(struct device *dev, gfp_t gfp_mask);
+void musb_put_id(struct device *dev, int id);
extern void musb_write_fifo(struct musb_hw_ep *ep, u16 len, const u8 *src);
extern void musb_read_fifo(struct musb_hw_ep *ep, u16 len, u8 *dst);
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index 2a408cd..14a612c 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
@@ -45,6 +45,7 @@
struct omap2430_glue {
struct device *dev;
+ int id;
struct platform_device *musb;
enum omap_musb_vbus_id_status status;
struct work_struct omap_musb_mailbox_work;
@@ -508,6 +509,7 @@ static int omap2430_probe(struct platform_device *pdev)
struct device_node *np = pdev-dev.of_node;
struct musb_hdrc_config *config;
int ret = -ENOMEM;
+ int musbid;
glue = devm_kzalloc(pdev-dev, sizeof(*glue), GFP_KERNEL);
if (!glue) {
@@ -515,10 +517,18 @@ static int omap2430_probe(struct platform_device *pdev)
goto err0;
}
- musb = platform_device_alloc(musb-hdrc, PLATFORM_DEVID_AUTO);
+ /* get the musb id */
+ musbid = musb_get_id(pdev-dev, GFP_KERNEL);
+ if (musbid 0) {
+ dev_err(pdev-dev, failed to allocate musb id\n);
+ ret = -ENOMEM;
+ goto err0;
+ }
+
+ musb = platform_device_alloc(musb-hdrc, musbid);
if (!musb) {
dev_err(pdev-dev, failed to allocate musb device\n);
- goto err0;
+ goto err1;
}
musb-dev.parent= pdev-dev;
@@ -528,6 +538,7 @@ static int omap2430_probe(struct platform_device *pdev)
glue-dev = pdev-dev;
glue-musb = musb;
glue-status= OMAP_MUSB_UNKNOWN;
+ glue-id= musbid;
glue-control_otghs = ERR_PTR(-ENODEV);
if (np) {
@@ -633,6 +644,9 @@ static int omap2430_probe(struct platform_device *pdev)
err2:
platform_device_put(musb);
+err1:
+ musb_put_id(pdev-dev, musbid);
+
err0:
return ret;
}
@@ -643,6 +657,7 @@ static int omap2430_remove(struct platform_device *pdev)
[PATCH v3 0/2] usb: fix controller-PHY binding for OMAP3 platform
After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. Did enumeration testing in omap3 beagle. Changes from v2: * Fixed the commit log Changes from v1: * refreshed to the latested mainline kernel * added musb_put_id from omap2430 remove. Kishon Vijay Abraham I (2): usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c arm: omap: remove *.auto* from device names given in usb_bind_phy arch/arm/mach-omap2/board-2430sdp.c|2 +- arch/arm/mach-omap2/board-3430sdp.c|2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-ldp.c|2 +- arch/arm/mach-omap2/board-omap3beagle.c|2 +- arch/arm/mach-omap2/board-omap3logic.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3stalker.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-overo.c |2 +- arch/arm/mach-omap2/board-rx51.c |2 +- drivers/usb/musb/musb_core.c | 31 +++- drivers/usb/musb/musb_core.h |2 ++ drivers/usb/musb/omap2430.c| 19 +++-- 15 files changed, 61 insertions(+), 15 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFCv4 06/11] misc: Introduce Nokia CMT driver
Hi,
On Mon, Dec 16, 2013 at 02:31:53PM +0100, Linus Walleij wrote:
I am very reluctant in letting device trees specify exports of GPIOs
to userspace, not so much because it's Linux-specific but for
the fact that people are doing things in userspace that should not
be done in userspace.
Last time it was proposed I asked to the specific usecase,
exactly why userspace needed this handle on a physical
GPIO line, and why it can't use another userspace interface
(example: leds, keys etc.)
There are a couple of lines (cmt_apeslpx, cmt_rst_rq, cmt_en,
cmt_rst, cmt_bsi), which are handled by ofono to do the correct
power sequence for the modem. The relevant ofono code is here:
https://git.kernel.org/cgit/network/ofono/ofono.git/tree/plugins/nokia-gpio.c
In MeeGo etc. they have a little board specific init script, which
exports the gpio lines and setups some symlinks. IMHO at least the
board specific stuff should be handled by the kernel, thus I added
this code to the driver. I guess you prefer to move the power
sequencing completly to the kernel?
What do you think about the following?
/*
* driver, which provides generic reset notifications
*/
cmt_reset: reset-notifier {
compatible = linux,reset-notification;
interrupts = gpio;
};
Looks good to me.
Ok :) I will prepare something for the next patch.
/*
* driver, which exports the specified gpios in sysfs with the
* supplied names. The device will be named according to the
* label
*/
cmt_gpios: gpio-sysfs-export {
compatible = linux,gpio-sysfs-export;
label = nokia-cmt;
gpios = A, B, ...;
gpio-names = A, B, ...;
};
Please follow the discussion on this topic:
http://marc.info/?l=linux-gpiom=138201170431416w=2
Ok.
Why are you using a tasklet rather than a work
for this?
No particular reason. I just took this over from Nokia's code.
Can you try to use a work instead?
Yes. I will have a look at this.
-- Sebastian
signature.asc
Description: Digital signature
Re: [PATCHv2 01/27] ARM: OMAP: remove DSS DT hack
* Tomi Valkeinen tomi.valkei...@ti.com [131216 06:59]: As a temporary solution to enable DSS for selected boards when booting with DT, a hack was added to board-generic.c in 63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable DSS for panda sdp boards). We're now adding proper DT support, so the hack can be removed. I guess this patch should be merged later on after we have the DT support working? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 02/27] OMAPDSS: remove DT hacks for regulators
* Tomi Valkeinen tomi.valkei...@ti.com [131216 06:59]: For booting Panda and 4430SDP with DT, while DSS did not support DT, we had to had small hacks in the omapdss driver to get the regulators. With DT now supported in DSS, we can remove those hacks. This too we should probably keep for a while and remove after we've converted DSS over to DT? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 03/27] ARM: OMAP2+: add omapdss_init_of()
* Tomi Valkeinen tomi.valkei...@ti.com [131216 07:02]:
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
...
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
#include linux/clk.h
#include linux/err.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_platform.h
#include video/omapdss.h
#include omap_hwmod.h
@@ -514,3 +516,63 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
+
+int __init omapdss_init_of(void)
+{
+ int r;
+ enum omapdss_version ver;
+
+ static struct omap_dss_board_info board_data = {
+ .dsi_enable_pads = omap_dsi_enable_pads,
+ .dsi_disable_pads = omap_dsi_disable_pads,
+ .get_context_loss_count = omap_pm_get_dev_context_loss_count,
+ .set_min_bus_tput = omap_dss_set_min_bus_tput,
+ };
+
+ ver = omap_display_get_version();
+
+ if (ver == OMAPDSS_VER_UNKNOWN) {
+ pr_err(DSS not supported on this SoC\n);
+ return -ENODEV;
+ }
+
+ board_data.version = ver;
+
+ omap_display_device.dev.platform_data = board_data;
+
+ r = platform_device_register(omap_display_device);
+ if (r 0) {
+ pr_err(Unable to register omapdss device\n);
+ return r;
+ }
You can populate the callback functions in the pdata using
OF_DEV_AUXDATA entries in the pdata-quirks.c. That way you could
instantiate the dev entry for omap_display_device using DT
and deal with it in drivers/video/omap except for the pdata
callbacks.
Of course that can be done later too.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730
* Igor Grinberg grinb...@compulab.co.il [131216 05:57]:
On 12/13/13 21:22, Tony Lindgren wrote:
SB-T35 has only one SMSC Ethernet on-board (smsc2),
while the first one is on the cm-t3530 and cm-t3730 modules.
SBC-T3517 has only one _SMSC_ Ethernet and it is on the SB-T35 base board.
cm-t3517 has EMAC Ethernet on-board instead of the SMSC.
OK, I'll move that.
There is also another base board - CB-T3, which turns into
EM-T3530 and EM-T3730 once you plug the cm-t3530 or cm-t3730 into CB-T3.
http://compulab.co.il/products/handheld-computers/em-t3730/
http://compulab.co.il/products/handheld-computers/em-t3530/
The CB-T3 base board does not have any Ethernet controllers on it,
so the EM-T3x systems have only one Ethernet controller - the one on the
CPU board - SMSC.
OK
This makes it four boards:
sb-t35 - base board has only one Ethernet controller (SMSC)
cb-t3 - base board has no Ethernet controllers
cm-t3530 - CPU board (plugged into sb-t35) has only one Ethernet controller
(SMSC)
cm-t3730 - CPU board (plugged into sb-t35) has only one Ethernet controller
(SMSC)
cm-t3537 - CPU board (plugged into sb-t35) has only one Ethernet controller
(EMAC)
The SBC-Txxx and EM-Txxx- means both boards connected (base board with CPU
board).
OK
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ leds {
+ compatible = gpio-leds;
+ ledb {
+ label = cm-t35:green;
+ gpios = gpio6 26 GPIO_ACTIVE_HIGH; /* gpio186 */
+ linux,default-trigger = heartbeat;
Although all CPU boards have the same GPIO routed to the heartbeat LED,
this property is related to the CPU board and not to the base (mother) board.
The same GPIO is used intensionally for s/w simplicity.
If we are about to save code duplication, I'd like to have a common
to CPU boards file, say omap3-cm-t3x.dtsi - that way it will better reflect
the actual hardware.
OK will move.
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
This one should be a part of the common file.
OK
+#include twl4030.dtsi
+#include twl4030_omap3.dtsi
+
+i2c3 {
+ clock-frequency = 40;
+};
+
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
Is it essential to always provide vmmc_aux-supply property?
In fact, the TPS65930 does not have the VSIM supply...
It is a mistake in the upstream board file.
OK
I fixed this locally a while ago, but haven't submitted upstream...
So we should either leave this property unpopulated (if we can...) or
provide a fixed regulator to populate it.
+ bus-width = 8;
I'm not sure what this property should reflect.
Both cm-t3530 and cm-t3730 use 4 bit MMC1 bus.
Hmm except with the muxing it seems to work just fine with 8-bit :)
I noticed that by accident as I copied the entry from omap3-evm.
So it seems that all the 8 lines are available for the MMC1, but can
be optionally also routed somewhere else?
+++ b/arch/arm/boot/dts/omap3-sbc-t3517.dts
@@ -0,0 +1,18 @@
+/*
+ * Suppport for CompuLab SBC-T3517 with CM-T3517
+ */
+/dts-v1/;
+
+#include am3517.dtsi
+#include omap3-sb-t35.dtsi
+
+
+/ {
+ model = CompuLab SBC-T3517 with CM-T3517;
+ compatible = compulab,omap3-sbc-t3517, ti,am3517, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
Can we support multiple memory sizes through static DT, or
the only way is to update this property in the bootloader?
Well we should probably have a minimal .dts file for the variants
too that can include omap3-cm-t37.dts and so on. I guess some
bootloaders are capable of rewriting the .dtb too.
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0) /*
sdmmc1_clk.sdmmc1_clk */
+ 0x116 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_cmd.sdmmc1_cmd */
+ 0x118 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat0.sdmmc1_dat0 */
+ 0x11a (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat1.sdmmc1_dat1 */
+ 0x11c (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat2.sdmmc1_dat2 */
+ 0x11e (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat3.sdmmc1_dat3 */
+ 0x120 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat4.sdmmc1_dat4 */
+ 0x122 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat5.sdmmc1_dat5 */
+ 0x124 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat6.sdmmc1_dat6 */
+ 0x126 (PIN_INPUT_PULLUP | MUX_MODE0)/*
sdmmc1_dat7.sdmmc1_dat7 */
The dat{4,5,6,7} pins are
Re: [PATCH v3 0/2] usb: fix controller-PHY binding for OMAP3 platform
Hi, On Mon, Dec 16, 2013 at 09:23:43PM +0530, Kishon Vijay Abraham I wrote: After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. Did enumeration testing in omap3 beagle. Changes from v2: * Fixed the commit log Changes from v1: * refreshed to the latested mainline kernel * added musb_put_id from omap2430 remove. Tony, how do you want to handle this ? You want me to provide you a branch which we both merge ? cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH v3 0/2] usb: fix controller-PHY binding for OMAP3 platform
* Felipe Balbi ba...@ti.com [131216 13:31]: Hi, On Mon, Dec 16, 2013 at 09:23:43PM +0530, Kishon Vijay Abraham I wrote: After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. Did enumeration testing in omap3 beagle. Changes from v2: * Fixed the commit log Changes from v1: * refreshed to the latested mainline kernel * added musb_put_id from omap2430 remove. Tony, how do you want to handle this ? You want me to provide you a branch which we both merge ? Yes that would be great thanks. For the mach-omap2 touching parts: Acked-by: Tony Lindgren t...@atomide.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/2] usb: fix controller-PHY binding for OMAP3 platform
Hi, On Mon, Dec 16, 2013 at 02:38:27PM -0800, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [131216 13:31]: Hi, On Mon, Dec 16, 2013 at 09:23:43PM +0530, Kishon Vijay Abraham I wrote: After the platform devices are created using PLATFORM_DEVID_AUTO, the device names given in usb_bind_phy (in board file) does not match with the actual device name causing the USB PHY library not to return the PHY reference when the MUSB controller request for the PHY in the non-dt boot case. So removed creating platform devices using PLATFORM_DEVID_AUTO in omap2430.c. Did enumeration testing in omap3 beagle. Changes from v2: * Fixed the commit log Changes from v1: * refreshed to the latested mainline kernel * added musb_put_id from omap2430 remove. Tony, how do you want to handle this ? You want me to provide you a branch which we both merge ? Yes that would be great thanks. For the mach-omap2 touching parts: Acked-by: Tony Lindgren t...@atomide.com Here it is, let me know if you prefer a signed tag: The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae: Linux 3.13-rc1 (2013-11-22 11:30:55 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git usb-phy-binding-omap3 for you to fetch changes up to 23ada3130cf4e56acb86fdff4c26113188d52d18: arm: omap: remove *.auto* from device names given in usb_bind_phy (2013-12-16 17:44:43 -0600) Kishon Vijay Abraham I (2): usb: musb: omap: remove using PLATFORM_DEVID_AUTO in omap2430.c arm: omap: remove *.auto* from device names given in usb_bind_phy arch/arm/mach-omap2/board-2430sdp.c| 2 +- arch/arm/mach-omap2/board-3430sdp.c| 2 +- arch/arm/mach-omap2/board-cm-t35.c | 2 +- arch/arm/mach-omap2/board-devkit8000.c | 2 +- arch/arm/mach-omap2/board-ldp.c| 2 +- arch/arm/mach-omap2/board-omap3beagle.c| 2 +- arch/arm/mach-omap2/board-omap3logic.c | 2 +- arch/arm/mach-omap2/board-omap3pandora.c | 2 +- arch/arm/mach-omap2/board-omap3stalker.c | 2 +- arch/arm/mach-omap2/board-omap3touchbook.c | 2 +- arch/arm/mach-omap2/board-overo.c | 2 +- arch/arm/mach-omap2/board-rx51.c | 2 +- drivers/usb/musb/musb_core.c | 31 +- drivers/usb/musb/musb_core.h | 2 ++ drivers/usb/musb/omap2430.c| 19 -- 15 files changed, 61 insertions(+), 15 deletions(-) -- balbi signature.asc Description: Digital signature
[PATCH 06/10] mfd: menelaus: Limit the usage of the_menelaus
Pass a menelaus_chip pointer as argument to most functions so we can
minimize the usage of the global the_menelaus pointer. This will
help later getting of the_menelaus altogether.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 420 ++---
1 file changed, 222 insertions(+), 198 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index d3e3022..ae3209d 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -177,9 +177,9 @@ struct menelaus_chip {
static struct menelaus_chip *the_menelaus;
-static int menelaus_write_reg(int reg, u8 value)
+static int menelaus_write_reg(struct menelaus_chip *m, int reg, u8 value)
{
- int val = i2c_smbus_write_byte_data(the_menelaus-client, reg, value);
+ int val = i2c_smbus_write_byte_data(m-client, reg, value);
if (val 0) {
pr_err(DRIVER_NAME : write error);
@@ -189,9 +189,9 @@ static int menelaus_write_reg(int reg, u8 value)
return 0;
}
-static int menelaus_read_reg(int reg)
+static int menelaus_read_reg(struct menelaus_chip *m, int reg)
{
- int val = i2c_smbus_read_byte_data(the_menelaus-client, reg);
+ int val = i2c_smbus_read_byte_data(m-client, reg);
if (val 0)
pr_err(DRIVER_NAME : read error);
@@ -199,65 +199,65 @@ static int menelaus_read_reg(int reg)
return val;
}
-static int menelaus_enable_irq(int irq)
+static int menelaus_enable_irq(struct menelaus_chip *m, int irq)
{
if (irq 7) {
irq -= 8;
- the_menelaus-mask2 = ~(1 irq);
- return menelaus_write_reg(MENELAUS_INT_MASK2,
- the_menelaus-mask2);
+ m-mask2 = ~(1 irq);
+ return menelaus_write_reg(m, MENELAUS_INT_MASK2,
+ m-mask2);
} else {
- the_menelaus-mask1 = ~(1 irq);
- return menelaus_write_reg(MENELAUS_INT_MASK1,
- the_menelaus-mask1);
+ m-mask1 = ~(1 irq);
+ return menelaus_write_reg(m, MENELAUS_INT_MASK1,
+ m-mask1);
}
}
-static int menelaus_disable_irq(int irq)
+static int menelaus_disable_irq(struct menelaus_chip *m, int irq)
{
if (irq 7) {
irq -= 8;
- the_menelaus-mask2 |= (1 irq);
- return menelaus_write_reg(MENELAUS_INT_MASK2,
- the_menelaus-mask2);
+ m-mask2 |= (1 irq);
+ return menelaus_write_reg(m, MENELAUS_INT_MASK2,
+ m-mask2);
} else {
- the_menelaus-mask1 |= (1 irq);
- return menelaus_write_reg(MENELAUS_INT_MASK1,
- the_menelaus-mask1);
+ m-mask1 |= (1 irq);
+ return menelaus_write_reg(m, MENELAUS_INT_MASK1,
+ m-mask1);
}
}
-static int menelaus_ack_irq(int irq)
+static int menelaus_ack_irq(struct menelaus_chip *m, int irq)
{
if (irq 7)
- return menelaus_write_reg(MENELAUS_INT_ACK2, 1 (irq - 8));
+ return menelaus_write_reg(m, MENELAUS_INT_ACK2, 1 (irq - 8));
else
- return menelaus_write_reg(MENELAUS_INT_ACK1, 1 irq);
+ return menelaus_write_reg(m, MENELAUS_INT_ACK1, 1 irq);
}
/* Adds a handler for an interrupt. Does not run in interrupt context */
-static int menelaus_add_irq_work(int irq,
+static int menelaus_add_irq_work(struct menelaus_chip *m, int irq,
void (*handler)(struct menelaus_chip *))
{
int ret = 0;
- mutex_lock(the_menelaus-lock);
- the_menelaus-handlers[irq] = handler;
- ret = menelaus_enable_irq(irq);
- mutex_unlock(the_menelaus-lock);
+ mutex_lock(m-lock);
+ m-handlers[irq] = handler;
+ ret = menelaus_enable_irq(m, irq);
+ mutex_unlock(m-lock);
return ret;
}
/* Removes handler for an interrupt */
-static int menelaus_remove_irq_work(int irq)
+static int menelaus_remove_irq_work(struct menelaus_chip *m, int irq)
{
int ret = 0;
- mutex_lock(the_menelaus-lock);
- ret = menelaus_disable_irq(irq);
- the_menelaus-handlers[irq] = NULL;
- mutex_unlock(the_menelaus-lock);
+ mutex_lock(m-lock);
+ ret = menelaus_disable_irq(m, irq);
+ m-handlers[irq] = NULL;
+ mutex_unlock(m-lock);
return ret;
}
@@ -268,12 +268,12 @@ static int menelaus_remove_irq_work(int irq)
* in each slot. In this case the cards are not seen by menelaus.
* FIXME: Add handling for D1 too
*/
-static void menelaus_mmc_cd_work(struct menelaus_chip *menelaus_hw)
+static void menelaus_mmc_cd_work(struct menelaus_chip *m)
{
int reg;
unsigned char card_mask = 0;
-
[PATCH 05/10] mfd: menelaus: Use for_each_set_bit()
That macro just helps removing some extra line of code and hides ffs()
calls.
While at that, also fix a variable shadowing bug where 'int irq' was
being redeclared inside inner loop while it was also argument to
interrupt handler.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 87d80a8..d3e3022 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -795,24 +795,22 @@ static irqreturn_t menelaus_irq(int irq, void *_menelaus)
{
struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
- unsigned isr;
+ unsigned long isr;
+ unsigned long i;
isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
~menelaus-mask2) 8;
isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
~menelaus-mask1;
- while (isr) {
- int irq = fls(isr) - 1;
- isr = ~(1 irq);
-
+ for_each_set_bit(i, isr, 16) {
mutex_lock(menelaus-lock);
- menelaus_disable_irq(irq);
- menelaus_ack_irq(irq);
- handler = menelaus-handlers[irq];
+ menelaus_disable_irq(i);
+ menelaus_ack_irq(i);
+ handler = menelaus-handlers[i];
if (handler)
handler(menelaus);
- menelaus_enable_irq(irq);
+ menelaus_enable_irq(i);
mutex_unlock(menelaus-lock);
}
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/10] mfd: menelaus: Remove unnecessary definition
menelaus_i2c_driver isn't referenced on probe, just remove that
unnecessary line. No functional changes.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 232d037..5d106e4 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1206,8 +1206,6 @@ static inline void menelaus_rtc_init(struct menelaus_chip
*m)
/*---*/
-static struct i2c_driver menelaus_i2c_driver;
-
static int menelaus_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
--
1.8.4.GIT
--
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 10/10] mfd: menelaus: IRQ is a requirement
This driver needs IRQ to work, if client-irq isn't set properly, we
won't work. Remove check around request_threaded_irq().
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 5d106e4..b01588e 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1271,14 +1271,12 @@ static int menelaus_probe(struct i2c_client *client,
/* Set output buffer strengths */
menelaus_write_reg(m, MENELAUS_MCT_CTRL1, 0x73);
- if (client-irq 0) {
- err = devm_request_threaded_irq(client-dev, client-irq, NULL,
- menelaus_irq, IRQF_ONESHOT, DRIVER_NAME, m);
- if (err) {
- dev_dbg(client-dev, can't get IRQ %d, err %d\n,
- client-irq, err);
- goto fail;
- }
+ err = devm_request_threaded_irq(client-dev, client-irq, NULL,
+ menelaus_irq, IRQF_ONESHOT, DRIVER_NAME, m);
+ if (err) {
+ dev_dbg(client-dev, can't get IRQ %d, err %d\n,
+ client-irq, err);
+ goto fail;
}
pr_info(Menelaus rev %d.%d\n, rev 4, rev 0x0f);
--
1.8.4.GIT
--
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 07/10] mfd: menelaus: Start to use irqdomain
Introduce an irq_chip and irq_domain for menelaus driver. Following
patches will convert uses to traditional request_threaded_irq().
While at that, some better error handling had to be added, so we could
free irq descs we allocated.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 123 +++--
1 file changed, 119 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index ae3209d..838d6bf 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -34,6 +34,7 @@
#include linux/module.h
#include linux/i2c.h
#include linux/interrupt.h
+#include linux/irqdomain.h
#include linux/sched.h
#include linux/mutex.h
#include linux/delay.h
@@ -47,6 +48,7 @@
#include asm/gpio.h
#define DRIVER_NAMEmenelaus
+#define MENELAUS_NR_IRQS 16
#define MENELAUS_I2C_ADDRESS 0x72
@@ -168,11 +170,19 @@ struct menelaus_chip {
u8 rtc_control;
unsigneduie:1;
#endif
+ int irq_base;
unsignedvcore_hw_mode:1;
u8 mask1, mask2;
+ u8 ack1, ack2;
+
void(*handlers[16])(struct menelaus_chip *);
void(*mmc_callback)(void *data, u8 mask);
void*mmc_callback_data;
+
+ unsignedmask1_pending:1;
+ unsignedmask2_pending:1;
+ unsignedack1_pending:1;
+ unsignedack2_pending:1;
};
static struct menelaus_chip *the_menelaus;
@@ -235,6 +245,83 @@ static int menelaus_ack_irq(struct menelaus_chip *m, int
irq)
return menelaus_write_reg(m, MENELAUS_INT_ACK1, 1 irq);
}
+static void menelaus_irq_ack(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+ int irq = data-irq - m-irq_base;
+
+ if (irq 7) {
+ m-ack2 |= BIT(irq);
+ m-ack2_pending = true;
+ } else {
+ m-ack1 |= BIT(irq);
+ m-ack1_pending = true;
+ }
+}
+
+static void menelaus_irq_mask(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+ int irq = data-irq - m-irq_base;
+
+ if (irq 7) {
+ m-mask2 |= BIT(irq);
+ m-mask2_pending = true;
+ } else {
+ m-mask1 |= BIT(irq);
+ m-mask1_pending = true;
+ }
+}
+
+static void menelaus_irq_unmask(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+ int irq = data-irq - m-irq_base;
+
+ if (irq 7) {
+ m-mask2 = ~BIT(irq);
+ m-mask2_pending = true;
+ } else {
+ m-mask1 = ~BIT(irq);
+ m-mask1_pending = true;
+ }
+}
+
+static void menelaus_irq_bus_lock(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+
+ mutex_lock(m-lock);
+}
+
+static void menelaus_irq_bus_sync_unlock(struct irq_data *data)
+{
+ struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
+
+ if (m-ack1_pending)
+ menelaus_write_reg(m, MENELAUS_INT_ACK1, m-ack1);
+
+ if (m-ack2_pending)
+ menelaus_write_reg(m, MENELAUS_INT_ACK2, m-ack2);
+
+ if (m-mask1_pending)
+ menelaus_write_reg(m, MENELAUS_INT_MASK1, m-mask1);
+
+ if (m-mask2_pending)
+ menelaus_write_reg(m, MENELAUS_INT_MASK2, m-mask2);
+
+ mutex_unlock(m-lock);
+}
+
+static struct irq_chip menelaus_irq_chip = {
+ .name = menelaus,
+ .irq_ack= menelaus_irq_ack,
+ .irq_mask = menelaus_irq_mask,
+ .irq_unmask = menelaus_irq_unmask,
+ .irq_bus_lock = menelaus_irq_bus_lock,
+ .irq_bus_sync_unlock = menelaus_irq_bus_sync_unlock,
+};
+
/* Adds a handler for an interrupt. Does not run in interrupt context */
static int menelaus_add_irq_work(struct menelaus_chip *m, int irq,
void (*handler)(struct menelaus_chip *))
@@ -1186,8 +1273,11 @@ static int menelaus_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct menelaus_chip*m;
+ struct device_node *node = client-dev.of_node;
int rev = 0, val;
int err = 0;
+ int irq_base;
+ int i;
struct menelaus_platform_data *menelaus_pdata =
dev_get_platdata(client-dev);
@@ -1205,12 +1295,32 @@ static int menelaus_probe(struct i2c_client *client,
the_menelaus = m;
m-client = client;
+ mutex_init(m-lock);
+
+ irq_base =
[PATCH 08/10] mfd: menelaus: Switch all children to threaded_irq
Now that we have our own irq_chip, all children can use traditional
request_threaded_irq().
While at that, also remove so functions which became unused.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 161 +++--
1 file changed, 50 insertions(+), 111 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 838d6bf..232d037 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -175,7 +175,6 @@ struct menelaus_chip {
u8 mask1, mask2;
u8 ack1, ack2;
- void(*handlers[16])(struct menelaus_chip *);
void(*mmc_callback)(void *data, u8 mask);
void*mmc_callback_data;
@@ -209,42 +208,6 @@ static int menelaus_read_reg(struct menelaus_chip *m, int
reg)
return val;
}
-static int menelaus_enable_irq(struct menelaus_chip *m, int irq)
-{
- if (irq 7) {
- irq -= 8;
- m-mask2 = ~(1 irq);
- return menelaus_write_reg(m, MENELAUS_INT_MASK2,
- m-mask2);
- } else {
- m-mask1 = ~(1 irq);
- return menelaus_write_reg(m, MENELAUS_INT_MASK1,
- m-mask1);
- }
-}
-
-static int menelaus_disable_irq(struct menelaus_chip *m, int irq)
-{
- if (irq 7) {
- irq -= 8;
- m-mask2 |= (1 irq);
- return menelaus_write_reg(m, MENELAUS_INT_MASK2,
- m-mask2);
- } else {
- m-mask1 |= (1 irq);
- return menelaus_write_reg(m, MENELAUS_INT_MASK1,
- m-mask1);
- }
-}
-
-static int menelaus_ack_irq(struct menelaus_chip *m, int irq)
-{
- if (irq 7)
- return menelaus_write_reg(m, MENELAUS_INT_ACK2, 1 (irq - 8));
- else
- return menelaus_write_reg(m, MENELAUS_INT_ACK1, 1 irq);
-}
-
static void menelaus_irq_ack(struct irq_data *data)
{
struct menelaus_chip *m = irq_data_get_irq_chip_data(data);
@@ -322,47 +285,15 @@ static struct irq_chip menelaus_irq_chip = {
.irq_bus_sync_unlock = menelaus_irq_bus_sync_unlock,
};
-/* Adds a handler for an interrupt. Does not run in interrupt context */
-static int menelaus_add_irq_work(struct menelaus_chip *m, int irq,
- void (*handler)(struct menelaus_chip *))
-{
- int ret = 0;
-
- mutex_lock(m-lock);
- m-handlers[irq] = handler;
- ret = menelaus_enable_irq(m, irq);
- mutex_unlock(m-lock);
-
- return ret;
-}
-
-/* Removes handler for an interrupt */
-static int menelaus_remove_irq_work(struct menelaus_chip *m, int irq)
-{
- int ret = 0;
-
- mutex_lock(m-lock);
- ret = menelaus_disable_irq(m, irq);
- m-handlers[irq] = NULL;
- mutex_unlock(m-lock);
-
- return ret;
-}
-
-/*
- * Gets scheduled when a card detect interrupt happens. Note that in some cases
- * this line is wired to card cover switch rather than the card detect switch
- * in each slot. In this case the cards are not seen by menelaus.
- * FIXME: Add handling for D1 too
- */
-static void menelaus_mmc_cd_work(struct menelaus_chip *m)
+static irqreturn_t menelaus_mmc_cd_irq(int irq, void *_m)
{
- int reg;
+ struct menelaus_chip *m = _m;
unsigned char card_mask = 0;
+ int reg;
reg = menelaus_read_reg(m, MENELAUS_MCT_PIN_ST);
if (reg 0)
- return;
+ return IRQ_NONE;
if (!(reg 0x1))
card_mask |= MCT_PIN_ST_S1_CD_ST;
@@ -373,6 +304,8 @@ static void menelaus_mmc_cd_work(struct menelaus_chip *m)
if (m-mmc_callback)
m-mmc_callback(m-mmc_callback_data,
card_mask);
+
+ return IRQ_HANDLED;
}
/*
@@ -504,20 +437,25 @@ int menelaus_register_mmc_callback(void (*callback)(void
*data, u8 card_mask),
m-mmc_callback_data = data;
m-mmc_callback = callback;
- ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1CD_IRQ,
- menelaus_mmc_cd_work);
+
+ ret = request_threaded_irq(MENELAUS_MMC_S1CD_IRQ + m-irq_base,
+ NULL, menelaus_mmc_cd_irq, IRQF_ONESHOT,
+ mmc_s1cd, m);
if (ret 0)
return ret;
- ret = menelaus_add_irq_work(m, MENELAUS_MMC_S2CD_IRQ,
- menelaus_mmc_cd_work);
+ ret = request_threaded_irq(MENELAUS_MMC_S2CD_IRQ + m-irq_base,
+ NULL, menelaus_mmc_cd_irq, IRQF_ONESHOT,
+ mmc_s2cd, m);
if (ret 0)
return ret;
- ret = menelaus_add_irq_work(m, MENELAUS_MMC_S1D1_IRQ,
- menelaus_mmc_cd_work);
+
[PATCH 04/10] mfd: menelaus: Remove unnecessary loop
We can let irqs refire and give the scheduler a chance to choose when we
should be scheduled.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 43 +++
1 file changed, 19 insertions(+), 24 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 268e39c..87d80a8 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -795,30 +795,25 @@ static irqreturn_t menelaus_irq(int irq, void *_menelaus)
{
struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
-
- while (1) {
- unsigned isr;
-
- isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
-~menelaus-mask2) 8;
- isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
-~menelaus-mask1;
- if (!isr)
- break;
-
- while (isr) {
- int irq = fls(isr) - 1;
- isr = ~(1 irq);
-
- mutex_lock(menelaus-lock);
- menelaus_disable_irq(irq);
- menelaus_ack_irq(irq);
- handler = menelaus-handlers[irq];
- if (handler)
- handler(menelaus);
- menelaus_enable_irq(irq);
- mutex_unlock(menelaus-lock);
- }
+ unsigned isr;
+
+ isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
+~menelaus-mask2) 8;
+ isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
+~menelaus-mask1;
+
+ while (isr) {
+ int irq = fls(isr) - 1;
+ isr = ~(1 irq);
+
+ mutex_lock(menelaus-lock);
+ menelaus_disable_irq(irq);
+ menelaus_ack_irq(irq);
+ handler = menelaus-handlers[irq];
+ if (handler)
+ handler(menelaus);
+ menelaus_enable_irq(irq);
+ mutex_unlock(menelaus-lock);
}
return IRQ_HANDLED;
--
1.8.4.GIT
--
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 03/10] mfd: menelaus: Convert to threaded irq
We don't need that extra workqueue when we have generic threaded irq
handlers support. This patch just moves over to threaded irqs and
deletes the unnecessary workqueue.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 34 +-
1 file changed, 5 insertions(+), 29 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 8bd97ca..268e39c 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -36,7 +36,6 @@
#include linux/interrupt.h
#include linux/sched.h
#include linux/mutex.h
-#include linux/workqueue.h
#include linux/delay.h
#include linux/rtc.h
#include linux/bcd.h
@@ -161,12 +160,9 @@
#define MCT_PIN_ST_S1_CD_ST(1 0)
#define MCT_PIN_ST_S2_CD_ST(1 1)
-static void menelaus_work(struct work_struct *_menelaus);
-
struct menelaus_chip {
struct mutexlock;
struct i2c_client *client;
- struct work_struct work;
#ifdef CONFIG_RTC_DRV_TWL92330
struct rtc_device *rtc;
u8 rtc_control;
@@ -795,11 +791,9 @@ out:
/*---*/
-/* Handles Menelaus interrupts. Does not run in interrupt context */
-static void menelaus_work(struct work_struct *_menelaus)
+static irqreturn_t menelaus_irq(int irq, void *_menelaus)
{
- struct menelaus_chip *menelaus =
- container_of(_menelaus, struct menelaus_chip, work);
+ struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
while (1) {
@@ -826,18 +820,6 @@ static void menelaus_work(struct work_struct *_menelaus)
mutex_unlock(menelaus-lock);
}
}
- enable_irq(menelaus-client-irq);
-}
-
-/*
- * We cannot use I2C in interrupt context, so we just schedule work.
- */
-static irqreturn_t menelaus_irq(int irq, void *_menelaus)
-{
- struct menelaus_chip *menelaus = _menelaus;
-
- disable_irq_nosync(irq);
- (void)schedule_work(menelaus-work);
return IRQ_HANDLED;
}
@@ -1225,8 +1207,9 @@ static int menelaus_probe(struct i2c_client *client,
menelaus_write_reg(MENELAUS_MCT_CTRL1, 0x73);
if (client-irq 0) {
- err = request_irq(client-irq, menelaus_irq, 0,
- DRIVER_NAME, menelaus);
+ err = devm_request_threaded_irq(client-dev, client-irq, NULL,
+ menelaus_irq, IRQF_ONESHOT, DRIVER_NAME,
+ menelaus);
if (err) {
dev_dbg(client-dev, can't get IRQ %d, err %d\n,
client-irq, err);
@@ -1235,7 +1218,6 @@ static int menelaus_probe(struct i2c_client *client,
}
mutex_init(menelaus-lock);
- INIT_WORK(menelaus-work, menelaus_work);
pr_info(Menelaus rev %d.%d\n, rev 4, rev 0x0f);
@@ -1257,17 +1239,11 @@ static int menelaus_probe(struct i2c_client *client,
return 0;
fail:
- free_irq(client-irq, menelaus);
- flush_work(menelaus-work);
return err;
}
static int menelaus_remove(struct i2c_client *client)
{
- struct menelaus_chip*menelaus = i2c_get_clientdata(client);
-
- free_irq(client-irq, menelaus);
- flush_work(menelaus-work);
the_menelaus = NULL;
return 0;
}
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] mfd: menelaus: Switch over to module_i2c_driver
Just a macro to remove some boilerplate code, no functional changes.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 23 +--
1 file changed, 1 insertion(+), 22 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 975ff9e..8bd97ca 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1287,29 +1287,8 @@ static struct i2c_driver menelaus_i2c_driver = {
.id_table = menelaus_id,
};
-static int __init menelaus_init(void)
-{
- int res;
-
- res = i2c_add_driver(menelaus_i2c_driver);
- if (res 0) {
- pr_err(DRIVER_NAME : driver registration failed\n);
- return res;
- }
-
- return 0;
-}
-
-static void __exit menelaus_exit(void)
-{
- i2c_del_driver(menelaus_i2c_driver);
-
- /* FIXME: Shutdown menelaus parts that can be shut down */
-}
+module_i2c_driver(menelaus_i2c_driver);
MODULE_AUTHOR(Texas Instruments, Inc. (and others));
MODULE_DESCRIPTION(I2C interface for Menelaus.);
MODULE_LICENSE(GPL);
-
-module_init(menelaus_init);
-module_exit(menelaus_exit);
--
1.8.4.GIT
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] mfd: menelaus: Drop __exit section annotation
We could build that driver as a dynamically-linked module.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index ad25bfa..975ff9e 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -1262,7 +1262,7 @@ fail:
return err;
}
-static int __exit menelaus_remove(struct i2c_client *client)
+static int menelaus_remove(struct i2c_client *client)
{
struct menelaus_chip*menelaus = i2c_get_clientdata(client);
@@ -1283,7 +1283,7 @@ static struct i2c_driver menelaus_i2c_driver = {
.name = DRIVER_NAME,
},
.probe = menelaus_probe,
- .remove = __exit_p(menelaus_remove),
+ .remove = menelaus_remove,
.id_table = menelaus_id,
};
--
1.8.4.GIT
--
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 05/10] mfd: menelaus: Use for_each_set_bit()
On Mon, Dec 16, 2013 at 04:17:35PM -0800, Joe Perches wrote:
On Mon, 2013-12-16 at 18:08 -0600, Felipe Balbi wrote:
That macro just helps removing some extra line of code and hides ffs()
calls.
While at that, also fix a variable shadowing bug where 'int irq' was
being redeclared inside inner loop while it was also argument to
interrupt handler.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 87d80a8..d3e3022 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -795,24 +795,22 @@ static irqreturn_t menelaus_irq(int irq, void
*_menelaus)
{
struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
- unsigned isr;
+ unsigned long isr;
+ unsigned long i;
isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
~menelaus-mask2) 8;
isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
~menelaus-mask1;
- while (isr) {
- int irq = fls(isr) - 1;
- isr = ~(1 irq);
-
+ for_each_set_bit(i, isr, 16) {
mutex_lock(menelaus-lock);
- menelaus_disable_irq(irq);
- menelaus_ack_irq(irq);
- handler = menelaus-handlers[irq];
+ menelaus_disable_irq(i);
+ menelaus_ack_irq(i);
+ handler = menelaus-handlers[i];
if (handler)
handler(menelaus);
- menelaus_enable_irq(irq);
+ menelaus_enable_irq(i);
mutex_unlock(menelaus-lock);
}
This could handle the irqs in reverse order.
Does that matter?
order does not matter with this device.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 05/10] mfd: menelaus: Use for_each_set_bit()
On Mon, 2013-12-16 at 18:08 -0600, Felipe Balbi wrote:
That macro just helps removing some extra line of code and hides ffs()
calls.
While at that, also fix a variable shadowing bug where 'int irq' was
being redeclared inside inner loop while it was also argument to
interrupt handler.
Tested-by: Aaro Koskinen aaro.koski...@iki.fi
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/mfd/menelaus.c | 16 +++-
1 file changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/menelaus.c b/drivers/mfd/menelaus.c
index 87d80a8..d3e3022 100644
--- a/drivers/mfd/menelaus.c
+++ b/drivers/mfd/menelaus.c
@@ -795,24 +795,22 @@ static irqreturn_t menelaus_irq(int irq, void
*_menelaus)
{
struct menelaus_chip *menelaus = _menelaus;
void (*handler)(struct menelaus_chip *menelaus);
- unsigned isr;
+ unsigned long isr;
+ unsigned long i;
isr = (menelaus_read_reg(MENELAUS_INT_STATUS2)
~menelaus-mask2) 8;
isr |= menelaus_read_reg(MENELAUS_INT_STATUS1)
~menelaus-mask1;
- while (isr) {
- int irq = fls(isr) - 1;
- isr = ~(1 irq);
-
+ for_each_set_bit(i, isr, 16) {
mutex_lock(menelaus-lock);
- menelaus_disable_irq(irq);
- menelaus_ack_irq(irq);
- handler = menelaus-handlers[irq];
+ menelaus_disable_irq(i);
+ menelaus_ack_irq(i);
+ handler = menelaus-handlers[i];
if (handler)
handler(menelaus);
- menelaus_enable_irq(irq);
+ menelaus_enable_irq(i);
mutex_unlock(menelaus-lock);
}
This could handle the irqs in reverse order.
Does that matter?
--
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: [PATCHv2 03/27] ARM: OMAP2+: add omapdss_init_of()
On 2013-12-16 20:46, Tony Lindgren wrote:
* Tomi Valkeinen tomi.valkei...@ti.com [131216 07:02]:
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
...
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
#include linux/clk.h
#include linux/err.h
#include linux/delay.h
+#include linux/of.h
+#include linux/of_platform.h
#include video/omapdss.h
#include omap_hwmod.h
@@ -514,3 +516,63 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
+
+int __init omapdss_init_of(void)
+{
+int r;
+enum omapdss_version ver;
+
+static struct omap_dss_board_info board_data = {
+.dsi_enable_pads = omap_dsi_enable_pads,
+.dsi_disable_pads = omap_dsi_disable_pads,
+.get_context_loss_count = omap_pm_get_dev_context_loss_count,
+.set_min_bus_tput = omap_dss_set_min_bus_tput,
+};
+
+ver = omap_display_get_version();
+
+if (ver == OMAPDSS_VER_UNKNOWN) {
+pr_err(DSS not supported on this SoC\n);
+return -ENODEV;
+}
+
+board_data.version = ver;
+
+omap_display_device.dev.platform_data = board_data;
+
+r = platform_device_register(omap_display_device);
+if (r 0) {
+pr_err(Unable to register omapdss device\n);
+return r;
+}
You can populate the callback functions in the pdata using
OF_DEV_AUXDATA entries in the pdata-quirks.c. That way you could
instantiate the dev entry for omap_display_device using DT
and deal with it in drivers/video/omap except for the pdata
callbacks.
The device we are creating here is not something to be created via DT.
So in addition to the devices that match to the DSS hardware blocks, we
have a 'omapdss' platform device. That's a legacy one, and it's
virtual in the sense that it doesn't match any HW block as such.
At some point the device should be removed totally, but for now it's
there and it's a convenient way to pass the platform data.
Of course that can be done later too.
Yes, at the moment I'm trying to minimize the kind of code changes that
can be done later. It'd be great to get this into next merge window, but
time is running short if I do any bigger changes.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCHv2 02/27] OMAPDSS: remove DT hacks for regulators
On 2013-12-16 20:42, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [131216 06:59]: For booting Panda and 4430SDP with DT, while DSS did not support DT, we had to had small hacks in the omapdss driver to get the regulators. With DT now supported in DSS, we can remove those hacks. This too we should probably keep for a while and remove after we've converted DSS over to DT? Hmm, yes, this one can be moved at the end of the series, as at that point the DT is supported for Panda and 4430SDP. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCHv2 01/27] ARM: OMAP: remove DSS DT hack
On 2013-12-16 20:41, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [131216 06:59]: As a temporary solution to enable DSS for selected boards when booting with DT, a hack was added to board-generic.c in 63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable DSS for panda sdp boards). We're now adding proper DT support, so the hack can be removed. I guess this patch should be merged later on after we have the DT support working? I'll move this patch also to the end of the series. Merged later sounds like you mean this could be merged in a separate series. I think this and the other removal can be in this series, they just need to be at the end. Tomi signature.asc Description: OpenPGP digital signature
OMAP baseline test results for v3.13-rc4
Here are some basic OMAP test results for Linux v3.13-rc4. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.13-rc4/20131215195251/ Test summary Build: uImage: Pass (14/14): omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_n800_only_a, omap2plus_defconfig_n800_multi_omap2xxx, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig Build: zImage: Pass ( 2/ 2): omap2plus_defconfig, omap2plus_defconfig_am33xx_only Build: uImage+dtb: Pass ( 3/ 3): omap2plus_defconfig_am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es Boot to userspace: skip ( 1/ 1): 5912osk Pass (11/11): 2430sdp, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, am335xbonelt, cmt3517, 4460varsomom PM: chip retention via suspend: FAIL ( 3/ 7): 2430sdp, 4430es2panda, 4460varsomom Pass ( 4/ 7): 3530es3beagle, 3730beaglexm, 37xxevm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 5/ 7): 2430sdp, 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 2/ 7): 3530es3beagle, 3730beaglexm PM: chip off except CORE via suspend: Pass ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: Pass ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle PM: chip off via dynamic idle: FAIL ( 4/ 5): 37xxevm, 4430es2panda, 4460pandaes, 4460varsomom Pass ( 1/ 5): 3530es3beagle vmlinux object size (delta in bytes from test_v3.13-rc3 (374b105797c3d4f29c685f3be535c35f5689b30e)): text data bsstotal kernel -22000 -220 omap1_defconfig -22800 -228 omap1_defconfig_1510innovator_only -15600 -156 omap1_defconfig_5912osk_only +2372 +80 +64+2516 omap2plus_defconfig +1564 +320+1596 omap2plus_defconfig_2430sdp_only +2300 +208 +64+2572 omap2plus_defconfig_cpupm +908 +112 +32+1052 omap2plus_defconfig_n800_multi_omap2xxx +876 +112 +32+1020 omap2plus_defconfig_n800_only_a +2372 +1120+2484 omap2plus_defconfig_no_pm +2348 +104 +64+2516 omap2plus_defconfig_omap2_4_only +2372 +80 +64+2516 omap2plus_defconfig_omap3_4_only +2908 +240 -688+2460 rmk_omap3430_ldp_allnoconfig +828 +640 +892 rmk_omap3430_ldp_oldconfig +2740 +168 -608+2300 rmk_omap4430_sdp_allnoconfig -35200 -352 rmk_omap4430_sdp_oldnoconfig Boot-time memory difference (delta in bytes from test_v3.13-rc3 (374b105797c3d4f29c685f3be535c35f5689b30e)) avail rsrvd high freed board kconfig -8k 8k . . 2430sdpomap2plus_defconfig -8k 8k . . 3517evmomap2plus_defconfig -8k 8k . . 3530es3beagle omap2plus_defconfig -8k 8k . . 3730beaglexm omap2plus_defconfig -8k 8k . . 37xxevmomap2plus_defconfig -8k 8k . . 4430es2panda omap2plus_defconfig -8k 8k . . 4460pandaesomap2plus_defconfig -8k 8k . . 4460varsomom omap2plus_defconfig -8k 8k . . am335xbone omap2plus_defconfig_am33xx_only -8k 8k . . am335xbonelt omap2plus_defconfig -- 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: [PATCHv2 08/27] OMAPDSS: add of helpers
On 2013-12-17 09:00, Archit Taneja wrote: +#include dss.h +#include dss_features.h Minor nitpick. The above 2 headers aren't needed. Ah, thanks. Forgot to remove those =). Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCHv2 08/27] OMAPDSS: add of helpers
Hi, On Monday 16 December 2013 08:26 PM, Tomi Valkeinen wrote: Add helpers to get ports and endpoints from DT data. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/Makefile | 2 +- drivers/video/omap2/dss/dss-of.c | 162 +++ include/video/omapdss.h | 14 3 files changed, 177 insertions(+), 1 deletion(-) create mode 100644 drivers/video/omap2/dss/dss-of.c diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile index d3aa91bdd6a8..8aec8bda27cc 100644 --- a/drivers/video/omap2/dss/Makefile +++ b/drivers/video/omap2/dss/Makefile @@ -1,7 +1,7 @@ obj-$(CONFIG_OMAP2_DSS) += omapdss.o # Core DSS files omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \ - output.o + output.o dss-of.o # DSS compat layer files omapdss-y += manager.o manager-sysfs.o overlay.o overlay-sysfs.o apply.o \ dispc-compat.o display-sysfs.o diff --git a/drivers/video/omap2/dss/dss-of.c b/drivers/video/omap2/dss/dss-of.c new file mode 100644 index ..59213cf2ffa2 --- /dev/null +++ b/drivers/video/omap2/dss/dss-of.c @@ -0,0 +1,162 @@ +/* + * Copyright (C) 2013 Texas Instruments + * Author: Tomi Valkeinen tomi.valkei...@ti.com + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License version 2 as published by + * the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, but WITHOUT + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + * more details. + */ + +#include linux/device.h +#include linux/err.h +#include linux/module.h +#include linux/of.h +#include linux/seq_file.h + +#include video/omapdss.h + +#include dss.h +#include dss_features.h Minor nitpick. The above 2 headers aren't needed. Archit -- 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: [PATCHv2 23/27] OMAPDSS: connector-dvi: Add DT support
Hi Tomi,
On Mon, Dec 16, 2013 at 04:56:30PM +0200, Tomi Valkeinen wrote:
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/connector-dvi.c | 43
1 file changed, 43 insertions(+)
diff --git a/drivers/video/omap2/displays-new/connector-dvi.c
b/drivers/video/omap2/displays-new/connector-dvi.c
index b6c50904038e..d1204b1c5182 100644
+static const struct of_device_id dvic_of_match[] = {
+ { .compatible = dvi-connector, },
Either the driver is too specific or the binding is too generic, but
having such a generic name for an omap specific driver seems wrong. Same
for panel-dpi, svideo-connector, composite-video-connector and hdmi-connector,
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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: Add support for sbc-3xxx with cm-t3730
On 12/16/13 21:17, Tony Lindgren wrote:
* Igor Grinberg grinb...@compulab.co.il [131216 05:57]:
On 12/13/13 21:22, Tony Lindgren wrote:
SB-T35 has only one SMSC Ethernet on-board (smsc2),
while the first one is on the cm-t3530 and cm-t3730 modules.
SBC-T3517 has only one _SMSC_ Ethernet and it is on the SB-T35 base board.
cm-t3517 has EMAC Ethernet on-board instead of the SMSC.
OK, I'll move that.
There is also another base board - CB-T3, which turns into
EM-T3530 and EM-T3730 once you plug the cm-t3530 or cm-t3730 into CB-T3.
http://compulab.co.il/products/handheld-computers/em-t3730/
http://compulab.co.il/products/handheld-computers/em-t3530/
The CB-T3 base board does not have any Ethernet controllers on it,
so the EM-T3x systems have only one Ethernet controller - the one on the
CPU board - SMSC.
OK
This makes it four boards:
sb-t35 - base board has only one Ethernet controller (SMSC)
cb-t3 - base board has no Ethernet controllers
cm-t3530 - CPU board (plugged into sb-t35) has only one Ethernet controller
(SMSC)
cm-t3730 - CPU board (plugged into sb-t35) has only one Ethernet controller
(SMSC)
cm-t3537 - CPU board (plugged into sb-t35) has only one Ethernet controller
(EMAC)
The SBC-Txxx and EM-Txxx- means both boards connected (base board with CPU
board).
OK
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = vcc;
+ };
+ };
+
+ leds {
+ compatible = gpio-leds;
+ ledb {
+ label = cm-t35:green;
+ gpios = gpio6 26 GPIO_ACTIVE_HIGH; /* gpio186 */
+ linux,default-trigger = heartbeat;
Although all CPU boards have the same GPIO routed to the heartbeat LED,
this property is related to the CPU board and not to the base (mother) board.
The same GPIO is used intensionally for s/w simplicity.
If we are about to save code duplication, I'd like to have a common
to CPU boards file, say omap3-cm-t3x.dtsi - that way it will better reflect
the actual hardware.
OK will move.
+i2c1 {
+ clock-frequency = 260;
+
+ twl: twl@48 {
+ reg = 0x48;
+ interrupts = 7; /* SYS_NIRQ cascaded to intc */
+ interrupt-parent = intc;
+ };
+};
This one should be a part of the common file.
OK
+#include twl4030.dtsi
+#include twl4030_omap3.dtsi
+
+i2c3 {
+ clock-frequency = 40;
+};
+
+mmc1 {
+ vmmc-supply = vmmc1;
+ vmmc_aux-supply = vsim;
Is it essential to always provide vmmc_aux-supply property?
In fact, the TPS65930 does not have the VSIM supply...
It is a mistake in the upstream board file.
OK
I fixed this locally a while ago, but haven't submitted upstream...
So we should either leave this property unpopulated (if we can...) or
provide a fixed regulator to populate it.
+ bus-width = 8;
I'm not sure what this property should reflect.
Both cm-t3530 and cm-t3730 use 4 bit MMC1 bus.
Hmm except with the muxing it seems to work just fine with 8-bit :)
Yes, this is because they are just not connected on sb-t35.
I noticed that by accident as I copied the entry from omap3-evm.
So it seems that all the 8 lines are available for the MMC1, but can
be optionally also routed somewhere else?
The concept of having CPU board and base (mother) board implies
that our customers build a base board of their own.
This way, the customer decides what to do with those lines.
cm-t3x just makes them available on the connector, while
neither sb-t35, nor cb-t3 uses them.
+++ b/arch/arm/boot/dts/omap3-sbc-t3517.dts
@@ -0,0 +1,18 @@
+/*
+ * Suppport for CompuLab SBC-T3517 with CM-T3517
+ */
+/dts-v1/;
+
+#include am3517.dtsi
+#include omap3-sb-t35.dtsi
+
+
+/ {
+ model = CompuLab SBC-T3517 with CM-T3517;
+ compatible = compulab,omap3-sbc-t3517, ti,am3517, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
Can we support multiple memory sizes through static DT, or
the only way is to update this property in the bootloader?
Well we should probably have a minimal .dts file for the variants
too that can include omap3-cm-t37.dts and so on. I guess some
bootloaders are capable of rewriting the .dtb too.
Ok. So what do you think, is it fine to have something like:
omap3-cm-t3x.dtsi - common to cm-t3x cpu boards
omap3-cm-t3x30.dtsi - common to cm-t3730 and cm-t3530
omap3-cm-t3730.dtsi - cm-t3730 specific
omap3-cm-t3530.dtsi - cm-t3530 specific
omap3-cm-t3517.dtsi - cm-t3517 specific
omap3-sb-t35.dtsi - sb-t35 specific
omap3-cb-t3.dtsi- cb-t3 specific
omap3-sbc-t3730-256mb.dts - sb-t35 with cm-t3730 and 256MB memory size
omap3-sbc-t3730-128mb.dts - sb-t35 with cm-t3730 and 128MB memory size
omap3-sbc-t3730-64mb.dts- sb-t35 with cm-t3730 and 64MB memory size
omap3-sbc-t3530-256mb.dts -
Re: [PATCHv2 23/27] OMAPDSS: connector-dvi: Add DT support
On 2013-12-17 09:05, Sascha Hauer wrote:
Hi Tomi,
On Mon, Dec 16, 2013 at 04:56:30PM +0200, Tomi Valkeinen wrote:
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays-new/connector-dvi.c | 43
1 file changed, 43 insertions(+)
diff --git a/drivers/video/omap2/displays-new/connector-dvi.c
b/drivers/video/omap2/displays-new/connector-dvi.c
index b6c50904038e..d1204b1c5182 100644
+static const struct of_device_id dvic_of_match[] = {
+{ .compatible = dvi-connector, },
Either the driver is too specific or the binding is too generic, but
having such a generic name for an omap specific driver seems wrong. Same
for panel-dpi, svideo-connector, composite-video-connector and hdmi-connector,
Hmm. Good point. I was thinking that the driver is only used on OMAP,
but of course that's not true, the driver is there for all platforms if
the kernel just happens to be compiled with the driver.
And it's not just about those drivers you mention. The same issue is
there for, say, ti,tpd12s015. I have an omapdss specific driver for
that, but if some other platform uses the same chip, they'll have a
driver for it also...
Sigh. I wonder how this should be handled... The only solution that
comes to my mind is to have all the compatible strings as ti, But
that's not correct, as they are not TI components, but some are generic
ones and some from another vendor.
And even ti,... is not good, as there are other TI SoCs with other
display drivers. So I'd need to prepend the compatible strings with
omapdss,..., making the hardware components driver specific.
The long term plan is to make the drivers generic (or implement the same
driver for common display framework). But for now I need to have future
proof DT bindings with omapdss specific drivers...
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [GIT PULL] make mach-omap2 boot with device tree only for v3.14
On Fri, 13 Dec 2013, Tony Lindgren wrote: OK posted a patch for the SBC-T3730 with minimal support also for SBC-3530 and SBC-3517 that should boot far enough to start adding more devices. Paul, care to try it on the CM-T3517, the patch is: [PATCH] ARM: dts: Add support for sbc-3xxx with cm-t3730 Didn't get anything out of the serial port: http://www.pwsan.com/omap/testlogs/test_tonys_conversion_v3.14/20131215235827/boot/cmt3517/cmt3517_log.txt As a partial sanity check, AM3517 EVM was included as part of the run (with a separate uImage+dtb of course) and that seems to boot OK: http://www.pwsan.com/omap/testlogs/test_tonys_conversion_v3.14/20131215235827/boot/3517evm/3517evm_log.txt In case it's useful, here's a CM-T3517 boot log from v3.13-rc4: http://www.pwsan.com/omap/testlogs/test_v3.13-rc4/20131215195251/boot/cmt3517/cmt3517_log.txt - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] OMAPDSS: DT support for N900 panel
Hi, On 2013-12-13 20:17, Sebastian Reichel wrote: Hi, This patchset adds DT support for the N900 panel. The patchset is based on Tomi's work/dss-dt-2 branch [0]. I suggest to send the DT changes through Benoits queue, since I have more N900 DT changes for 3.14. Also the patch editing the rx51 boardcode can be dropped, since the file is removed in 3.14. I included those two with this patchset, since they are needed to test the other two patches. I did not include a documentation for the DT API, since the omapdss documentation is still missing. I have successfully tested this on the N900. [0] https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/log/?h=work/dss-dt-2 I added N900 display DT support on top of my v2 series, including pinmuxing. Can you check if it looks right and works? git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 0/2] v4l: ti-vpe: Some VPE fixes
On 12/03/2013 12:51 PM, Archit Taneja wrote: This series fixes 2 issues in the VPE driver. The first fix allows us to use UYVY color format for source and destination buffers. The second fix makes sure we don't set pixel format widths which the VPDMA HW can't support. None of these fixes are fatal, so they don't necessarily need to go in for the 3.13-rc fixes. Archit Taneja (2): v4l: ti-vpe: Fix the data_type value for UYVY VPDMA format v4l: ti-vpe: make sure VPDMA line stride constraints are met drivers/media/platform/ti-vpe/vpdma.c | 4 +-- drivers/media/platform/ti-vpe/vpdma.h | 5 ++- drivers/media/platform/ti-vpe/vpdma_priv.h | 2 +- drivers/media/platform/ti-vpe/vpe.c| 53 ++ 4 files changed, 47 insertions(+), 17 deletions(-) For this patch series: Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans -- 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
