Re: [PATCH v9 5/9] dmaengine: edma: Add TI EDMA device tree binding
On 3/6/2013 9:45 PM, Matt Porter wrote:
> The binding definition is based on the generic DMA controller
> binding.
>
> Signed-off-by: Matt Porter
Okay the bindings the documented after they are used leading to some
confusion. This patch should be moved up the series. As I noted in my
other e-mail, some of these bindings are not really hardware description
and need to be re-looked.
Thanks,
Sekhar
> ---
> Documentation/devicetree/bindings/dma/ti-edma.txt | 49
> +
> 1 file changed, 49 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/ti-edma.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt
> b/Documentation/devicetree/bindings/dma/ti-edma.txt
> new file mode 100644
> index 000..075a60e3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
> @@ -0,0 +1,49 @@
> +TI EDMA
> +
> +Required properties:
> +- compatible : "ti,edma3"
> +- ti,hwmods: Name of the hwmods associated to the EDMA
> +- ti,edma-regions: Number of regions
> +- ti,edma-slots: Number of slots
> +- ti,edma-queue-tc-map: List of transfer control to queue mappings
> +- ti,edma-queue-priority-map: List of queue priority mappings
> +- ti,edma-default-queue: Default queue value
> +
> +Optional properties:
> +- ti,edma-reserved-channels: List of reserved channel regions
> +- ti,edma-reserved-slots: List of reserved slot regions
> +- ti,edma-xbar-event-map: Crossbar event to channel map
> +
> +Example:
> +
> +edma: edma@4900 {
> + reg = <0x4900 0x1>;
> + interrupt-parent = <&intc>;
> + interrupts = <12 13 14>;
> + compatible = "ti,edma3";
> + ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
> + #dma-cells = <1>;
> + dma-channels = <64>;
> + ti,edma-regions = <4>;
> + ti,edma-slots = <256>;
> + ti,edma-reserved-channels = <0 2
> + 14 2
> + 26 6
> + 48 4
> + 56 8>;
> + ti,edma-reserved-slots = <0 2
> + 14 2
> + 26 6
> + 48 4
> + 56 8
> + 64 127>;
> + ti,edma-queue-tc-map = <0 0
> + 1 1
> + 2 2>;
> + ti,edma-queue-priority-map = <0 0
> + 1 1
> + 2 2>;
> + ti,edma-default-queue = <0>;
> + ti,edma-xbar-event-map = <1 12
> + 2 13>;
> +};
>
--
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 v9 3/9] ARM: edma: add AM33XX support to the private EDMA API
On 3/6/2013 9:45 PM, Matt Porter wrote:
> Adds support for parsing the TI EDMA DT data into the
> required EDMA private API platform data. Enables runtime
> PM support to initialize the EDMA hwmod. Adds AM33XX EDMA
> crossbar event mux support. Enables build on OMAP.
>
> Signed-off-by: Matt Porter
> Acked-by: Sekhar Nori
> ---
> arch/arm/common/edma.c | 300
> ++--
> arch/arm/mach-omap2/Kconfig|1 +
> include/linux/platform_data/edma.h |1 +
> 3 files changed, 292 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
> index a1db6cd..e68ac38 100644
> --- a/arch/arm/common/edma.c
> +++ b/arch/arm/common/edma.c
> @@ -24,6 +24,13 @@
> #include
> #include
> #include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
>
> #include
>
> @@ -1369,31 +1376,278 @@ void edma_clear_event(unsigned channel)
> EXPORT_SYMBOL(edma_clear_event);
>
> /*---*/
> +static int edma_of_read_u32_to_s8_array(const struct device_node *np,
> + const char *propname, s8 *out_values,
> + size_t sz)
> +{
> + int ret;
> +
> + ret = of_property_read_u8_array(np, propname, out_values, sz);
> + if (ret)
> + return ret;
> +
> + /* Terminate it */
> + *out_values++ = -1;
> + *out_values++ = -1;
> +
> + return 0;
> +}
> +
> +static int edma_of_read_u32_to_s16_array(const struct device_node *np,
> + const char *propname, s16 *out_values,
> + size_t sz)
> +{
> + int ret;
> +
> + ret = of_property_read_u16_array(np, propname, out_values, sz);
> + if (ret)
> + return ret;
> +
> + /* Terminate it */
> + *out_values++ = -1;
> + *out_values++ = -1;
> +
> + return 0;
> +}
> +
> +static int edma_xbar_event_map(struct device *dev,
> +struct device_node *node,
> +struct edma_soc_info *pdata, int len)
> +{
It will be nice to separate the xbar feature from DT'fication of the
existing driver. Right now because of the mix the patch has become
pretty big and its becoming tough to review in isolation.
> + int ret = 0;
> + int i;
> + struct resource res;
> + void *xbar;
> + const s16 (*xbar_chans)[2];
> + u32 shift, offset, mux;
> +
> + xbar_chans = devm_kzalloc(dev,
> + len/sizeof(s16) + 2*sizeof(s16),
> + GFP_KERNEL);
> + if (!xbar_chans)
> + return -ENOMEM;
> +
> + ret = of_address_to_resource(node, 1, &res);
> + if (ret)
> + return -EIO;
> +
> + xbar = devm_ioremap(dev, res.start, resource_size(&res));
> + if (!xbar)
> + return -ENOMEM;
> +
> + ret = edma_of_read_u32_to_s16_array(node,
> + "ti,edma-xbar-event-map",
> + (s16 *)xbar_chans,
> + len/sizeof(u32));
> + if (ret)
> + return -EIO;
> +
> + for (i = 0; xbar_chans[i][0] != -1; i++) {
> + shift = (xbar_chans[i][1] % 4) * 8;
> + offset = xbar_chans[i][1] >> 2;
> + offset <<= 2;
> + mux = readl((void *)((u32)xbar + offset));
> + mux &= ~(0xff << shift);
> + mux |= xbar_chans[i][0] << shift;
> + writel(mux, (void *)((u32)xbar + offset));
> + }
> +
> + pdata->xbar_chans = xbar_chans;
> +
> + return 0;
> +}
> +
> +static int edma_of_parse_dt(struct device *dev,
> + struct device_node *node,
> + struct edma_soc_info *pdata)
> +{
> + int ret = 0;
> + u32 value;
> + struct property *prop;
> + size_t sz;
> + struct edma_rsv_info *rsv_info;
> + const s16 (*rsv_chans)[2], (*rsv_slots)[2];
> + const s8 (*queue_tc_map)[2], (*queue_priority_map)[2];
> +
> + memset(pdata, 0, sizeof(struct edma_soc_info));
> +
> + ret = of_property_read_u32(node, "dma-channels", &value);
> + if (ret < 0)
> + return ret;
> + pdata->n_channel = value;
> +
> + ret = of_property_read_u32(node, "ti,edma-regions", &value);
> + if (ret < 0)
> + return ret;
> + pdata->n_region = value;
> +
> + ret = of_property_read_u32(node, "ti,edma-slots", &value);
> + if (ret < 0)
> + return ret;
> + pdata->n_slot = value;
> +
> + pdata->n_cc = 1;
> + pdata->n_tc = 3;
Will this mean the DT portion of this driver cannot be used on SoCs
where there are two CCs like DA850? If you are hard-coding this, will it
make sense to set to to EDMA_MAX_CC instead? Okay I see a comment down
below saying DT will support only one
Re: [PATCH 4/4] omapdss: features: fixed supported outputs for OMAP4
On Monday 11 March 2013 05:58 PM, Tomi Valkeinen wrote:
On 2013-03-05 16:17, Archit Taneja wrote:
The support outputs struct for overlay managers is incorrect for OMAP4. Make
these changes:
- DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
output.
- the TV manager can suppport DPI, but the omapdss driver doesn't support that
yet, we require some muxing at the DSS level, and we also need to configure
the hdmi pll in the DPI driver so that the TV manager has a pixel clock. We
don't support that yet.
Signed-off-by: Archit Taneja
---
drivers/video/omap2/dss/dss_features.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dss_features.c
b/drivers/video/omap2/dss/dss_features.c
index d7d66ef..7f791ae 100644
--- a/drivers/video/omap2/dss/dss_features.c
+++ b/drivers/video/omap2/dss/dss_features.c
@@ -202,12 +202,10 @@ static const enum omap_dss_output_id
omap3630_dss_supported_outputs[] = {
static const enum omap_dss_output_id omap4_dss_supported_outputs[] = {
/* OMAP_DSS_CHANNEL_LCD */
- OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
- OMAP_DSS_OUTPUT_DSI1,
+ OMAP_DSS_OUTPUT_DBI | OMAP_DSS_OUTPUT_DSI1,
/* OMAP_DSS_CHANNEL_DIGIT */
- OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI |
- OMAP_DSS_OUTPUT_DPI,
+ OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI,
/* OMAP_DSS_CHANNEL_LCD2 */
OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
Thanks, I'll apply this to omapdss fixes branch.
Hi, just one point here, this patch is a prerequisite for the patch 2/4
in this series. So we need to make sure that the 2/4 patch is not
without this one in a kernel.
Tomi,
About patch '2/4', could you have a look at it too? It basically tries
to do a dynamic assignment of channels to outputs. I worked on this
before you posted the misc series with recommended_channel for outputs.
This patch tries to figure out managers with supported_outputs. It isn't
the most optimal way, as it can't back track and chose a better manager,
but it still seems to do a reasonable job.
We could also use the recommended channel way for omapdrm, I can't
figure out what's the better approach at the moment.
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: [PATCH 2/2] cpufreq: cpufreq-cpu0: provide compatibility string for DT matchup
On Tuesday 12 March 2013 04:35 AM, Nishanth Menon wrote: > commit 5553f9e (cpufreq: instantiate cpufreq-cpu0 as a platform_driver) > now forces platform device to be registered for allowing cpufreq-cpu0 > to be used by SoCs. example: drivers/cpufreq/highbank-cpufreq.c > > However, for SoCs that wish to link up using device tree, instead > of platform device, provide compatibility string match: > compatible = "cpufreq,cpu0"; > > Cc: "Rafael J. Wysocki" > Cc: Santosh Shilimkar > Cc: Shawn Guo > Cc: linux-ker...@vger.kernel.org > Cc: cpuf...@vger.kernel.org > Cc: linux...@vger.kernel.org > Cc: linux-omap@vger.kernel.org > > Signed-off-by: Nishanth Menon > --- > .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |3 +++ > drivers/cpufreq/cpufreq-cpu0.c |6 ++ > 2 files changed, 9 insertions(+) > Looks fine to me. CC'ing dt list in case some one has comments on binding updates. Acked-by: Santosh Shilimkar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] cpufreq: cpufreq-cpu0: support for clock which are not in DT yet.
On Tuesday 12 March 2013 04:35 AM, Nishanth Menon wrote:
> On certain SoCs like variants of OMAP, the clock conversion to DT
> is not complete. In short, the ability to:
> cpus {
> cpu@0 {
> clocks = <&cpuclk 0>;
> };
> };
> is not possible. However, the clock node is registered.
> Allow for clk names to be provided as string so as to be used when needed.
> Example (for OMAP3630):
> cpus {
> cpu@0 {
> clock-name = "cpufreq_ck";
> };
> };
>
> Cc: "Rafael J. Wysocki"
> Cc: Santosh Shilimkar
> Cc: Shawn Guo
> Cc: linux-ker...@vger.kernel.org
> Cc: cpuf...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: linux-omap@vger.kernel.org
>
> Signed-off-by: Nishanth Menon
> ---
Seems a reasonable to me.
Acked-by: Santosh Shilimkar
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
On Mon, Mar 11, 2013 at 23:23:32, Hunter, Jon wrote:
>
> On 03/08/2013 08:25 PM, Anil Kumar wrote:
> > Hi Jon,
> >
> > On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter wrote:
> >> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
> >> of RAM and uses the TWL4030 power management IC.
> >
> > I think this board support should be in separate patch series with
> > related patches.
>
> Well I wanted to keep them altogether so that I can send a pull request
> to Benoit and Tony.
Sorry, but can you please tell what makes you to think that you
can send pull request only when they are altogether ?
Is there any logical dependency with other patches except
"[PATCH 6/9] ARM: dts: Add OMAP3430 SDP flash memory bindings" is on
top of this patch ?
>
> >>
> >> Signed-off-by: Jon Hunter
> >> ---
> >> arch/arm/boot/dts/Makefile |1 +
> >> arch/arm/boot/dts/omap3430-sdp.dts | 46
> >>
> >> 2 files changed, 47 insertions(+)
> >> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
> >>
> >> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> index 9c62558..89013ed 100644
> >> --- a/arch/arm/boot/dts/Makefile
> >> +++ b/arch/arm/boot/dts/Makefile
> >> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
> >> omap3-beagle-xm.dtb \
> >> omap3-evm.dtb \
> >> omap3-tobi.dtb \
> >> + omap3430-sdp.dtb \
> >> omap4-panda.dtb \
> >> omap4-panda-a4.dtb \
> >> omap4-panda-es.dtb \
> >> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
> >> b/arch/arm/boot/dts/omap3430-sdp.dts
> >> new file mode 100644
> >> index 000..be0650d
> >> --- /dev/null
> >> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
> >> @@ -0,0 +1,46 @@
> >> +/*
> >> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + */
> >> +/dts-v1/;
> >> +
> >> +/include/ "omap3.dtsi"
> >> +
> >> +/ {
> >> + model = "TI OMAP3430 SDP";
> >> + compatible = "ti,omap3430-sdp", "ti,omap3";
> >
> > I have not seen any related changes in "board-generic.c" for your board.
> > So just wanted know, how this board is booting ?
>
> If you look at board-generic.c you will see that "ti,omap3" will match
> the OMAP3 generic machine. So you don't need to modify the board-generic.c.
According to this omap3-beagle.dts and omap3-beagle-xm.dts are also
booting in some way. So it is not clear to me, why there two
"DT_MACHINE_START" for omap3. I have seen there is only one
different in "init_time" for the same.
>
> >> +
> >> + memory {
> >> + device_type = "memory";
> >> + reg = <0x8000 0x1000>; /* 256 MB */
> >> + };
> >> +};
> >> +
> >> +&i2c1 {
> >> + clock-frequency = <260>;
> >> +
> >> + twl: twl@48 {
> >> + reg = <0x48>;
> >> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
> >> + interrupt-parent = <&intc>;
> >> + };
> >> +};
> >> +
> >> +/include/ "twl4030.dtsi"
> >> +
> >> +&mmc1 {
> >> + vmmc-supply = <&vmmc1>;
> >> + vmmc_aux-supply = <&vsim>;
> >> + bus-width = <8>;
> >> +};
> >> +
> >> +&mmc2 {
> >> + status = "disabled";
> >> +};
> >> +
> >> +&mmc3 {
> >> + status = "disabled";
> >> +};
> >
> > I think you should disable modules those are not currently used
> > as they are enabled by default in omap3.dtsi.
> >
> > exp:-
> >
> > &mcbsp2 {
> > status = "disabled";
> > };
>
> Well may be we could do that in a follow-up patch. If you look at other
> omap3 boards we have not gone through and disabled all unused modules
> either. So although I agree, right now I just want to get minimal
> support added.
>
Hmm... But it makes the kernel to call unused driver probe and get failed
those required some platform date from DT? you can see the kernel boot logs.
Thanks,
Anil
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew
---
This patch, along with many more soon to follow, attempts to satisfy the new
mandatory regulator that pwm-backlight will grab during probe. The only
board in mach-omap2 to use the pwm-backlight appears to be the 4430sdp.
I thought I'd start small and use this board as an example.
I tested similar code in my Tegra board, so it should be okay. Of course,
I don't have a 4430sdp to test with.
arch/arm/mach-omap2/board-4430sdp.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 35f3ad0..62022c0 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -291,6 +291,10 @@ static struct platform_device sdp4430_leds_pwm = {
},
};
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+ REGULATOR_SUPPLY("enable", NULL);
+
static struct platform_pwm_backlight_data sdp4430_backlight_data = {
.max_brightness = 127,
.dft_brightness = 127,
@@ -718,6 +722,7 @@ static void __init omap_4430sdp_init(void)
omap4_i2c_init();
omap_sfh7741prox_init();
+ regulator_register_always_on(-1, "bl-enable", &backlight_supply, 1, 0);
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap_sdrc_init(NULL, NULL);
--
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
[PATCH 2/2] cpufreq: cpufreq-cpu0: provide compatibility string for DT matchup
commit 5553f9e (cpufreq: instantiate cpufreq-cpu0 as a platform_driver)
now forces platform device to be registered for allowing cpufreq-cpu0
to be used by SoCs. example: drivers/cpufreq/highbank-cpufreq.c
However, for SoCs that wish to link up using device tree, instead
of platform device, provide compatibility string match:
compatible = "cpufreq,cpu0";
Cc: "Rafael J. Wysocki"
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: linux-ker...@vger.kernel.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon
---
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |3 +++
drivers/cpufreq/cpufreq-cpu0.c |6 ++
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index f180963..a5699f0 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -10,6 +10,8 @@ under node /cpus/cpu@0.
Required properties:
- operating-points: Refer to Documentation/devicetree/bindings/power/opp.txt
for details
+- compatible: if platform_device is *not* used, should be:
+ "cpufreq,cpu0"
Optional properties:
- clock-name: If the clock is not converted to device tree, then describe
@@ -24,6 +26,7 @@ Examples:
cpus {
#address-cells = <1>;
#size-cells = <0>;
+ compatible = "cpufreq,cpu0";
cpu@0 {
compatible = "arm,cortex-a9";
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 28223c9..a6f0a9b 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -277,9 +277,15 @@ static int cpu0_cpufreq_remove(struct platform_device
*pdev)
return 0;
}
+static struct of_device_id of_cpu0_cpufreq_match[] = {
+ { .compatible = "cpufreq,cpu0", },
+ { /* end */ }
+};
+
static struct platform_driver cpu0_cpufreq_platdrv = {
.driver = {
.name = "cpufreq-cpu0",
+ .of_match_table = of_cpu0_cpufreq_match,
.owner = THIS_MODULE,
},
.probe = cpu0_cpufreq_probe,
--
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
[PATCH 1/2] cpufreq: cpufreq-cpu0: support for clock which are not in DT yet.
On certain SoCs like variants of OMAP, the clock conversion to DT
is not complete. In short, the ability to:
cpus {
cpu@0 {
clocks = <&cpuclk 0>;
};
};
is not possible. However, the clock node is registered.
Allow for clk names to be provided as string so as to be used when needed.
Example (for OMAP3630):
cpus {
cpu@0 {
clock-name = "cpufreq_ck";
};
};
Cc: "Rafael J. Wysocki"
Cc: Santosh Shilimkar
Cc: Shawn Guo
Cc: linux-ker...@vger.kernel.org
Cc: cpuf...@vger.kernel.org
Cc: linux...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Signed-off-by: Nishanth Menon
---
.../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |3 +++
drivers/cpufreq/cpufreq-cpu0.c |6 +-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 4416ccc..f180963 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -12,6 +12,9 @@ Required properties:
for details
Optional properties:
+- clock-name: If the clock is not converted to device tree, then describe
+ the clock name as a string. This may also be replaced with clocks=<&cpuclk>
+ cpu clocks has already been converted to device tree.
- clock-latency: Specify the possible maximum transition latency for clock,
in unit of nanoseconds.
- voltage-tolerance: Specify the CPU voltage tolerance in percentage.
diff --git a/drivers/cpufreq/cpufreq-cpu0.c b/drivers/cpufreq/cpufreq-cpu0.c
index 4e5b7fb..28223c9 100644
--- a/drivers/cpufreq/cpufreq-cpu0.c
+++ b/drivers/cpufreq/cpufreq-cpu0.c
@@ -180,6 +180,7 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
{
struct device_node *np;
int ret;
+ const char *clk_name = NULL;
for_each_child_of_node(of_find_node_by_path("/cpus"), np) {
if (of_get_property(np, "operating-points", NULL))
@@ -194,7 +195,10 @@ static int cpu0_cpufreq_probe(struct platform_device *pdev)
cpu_dev = &pdev->dev;
cpu_dev->of_node = np;
- cpu_clk = devm_clk_get(cpu_dev, NULL);
+ /* If clocks are not in DT yet, allow to define it part of CPU node */
+ of_property_read_string(np, "clock-name", &clk_name);
+
+ cpu_clk = devm_clk_get(cpu_dev, clk_name);
if (IS_ERR(cpu_clk)) {
ret = PTR_ERR(cpu_clk);
pr_err("failed to get cpu0 clock: %d\n", ret);
--
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
[PATCH 0/2] cpufreq: cpufreq-cpu0: cleanups around DT usage
The following series arose from trying to use BeagleBoard-XM (OMAP3 variant) for doing CPU DVFS using cpufreq-cpu0. This is also an attempt to slowly remove the dependence on omap-cpufreq driver and be entirely driven off cpufreq-cpu0 driver. Somewhere in the future, when we have regulators driven off CCF and OMAP converted to CCF, we could remove the DT regulator requirements as well. Based on v3.9-rc2 tag Nishanth Menon (2): cpufreq: cpufreq-cpu0: support for clock which are not in DT yet. cpufreq: cpufreq-cpu0: provide compatibility string for DT matchup .../devicetree/bindings/cpufreq/cpufreq-cpu0.txt |6 ++ drivers/cpufreq/cpufreq-cpu0.c | 12 +++- 2 files changed, 17 insertions(+), 1 deletion(-) Cc: "Rafael J. Wysocki" Cc: Santosh Shilimkar Cc: Shawn Guo Cc: linux-ker...@vger.kernel.org Cc: cpuf...@vger.kernel.org Cc: linux...@vger.kernel.org Cc: linux-omap@vger.kernel.org This series in addition to the following DT changes (temporary): http://pastebin.com/h5uysj0i Screen shot of the voltage changes using cpufreq-cpu0 on Xm: http://goo.gl/vVEjd OMAP Caveat: AVS+ABB still wont work with just these changes. More to come as we progress. -- 1.7.9.5 Regards, Nishanth Menon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP3: hwmod data: keep MIDLEMODE in force-standby for musb
For some unknown reason, allowing hwmod to control MIDLEMODE causes
core_pwrdm to not hit idle states for musb in DM3730 at least.
I've verified that setting any MIDLEMODE value other than "force
standby" before enabling the device causes subsequent suspend
attempts to fail with core_pwrdm not entering idle states, even
if the driver is unloaded and "force standby" is restored before
suspend attempt. To recover from this, soft reset can be used, but
that's not suitable solution for suspend.
Keeping the register set at force standby (reset value) makes it work
and device still functions properly, as musb has driver-controlled
OTG_FORCESTDBY register that controls MSTANDBY signal.
Note that TI PSP kernels also have similar workarounds.
This patch also fixes HWMOD_SWSUP_MSTANDBY documentation to match the
actual flag name.
Signed-off-by: Grazvydas Ignotas
---
arch/arm/mach-omap2/omap_hwmod.c |7 +--
arch/arm/mach-omap2/omap_hwmod.h |9 +++--
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |7 ++-
3 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index c2c798c..a202a47 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -1368,7 +1368,9 @@ static void _enable_sysc(struct omap_hwmod *oh)
}
if (sf & SYSC_HAS_MIDLEMODE) {
- if (oh->flags & HWMOD_SWSUP_MSTANDBY) {
+ if (oh->flags & HWMOD_FORCE_MSTANDBY) {
+ idlemode = HWMOD_IDLEMODE_FORCE;
+ } else if (oh->flags & HWMOD_SWSUP_MSTANDBY) {
idlemode = HWMOD_IDLEMODE_NO;
} else {
if (sf & SYSC_HAS_ENAWAKEUP)
@@ -1440,7 +1442,8 @@ static void _idle_sysc(struct omap_hwmod *oh)
}
if (sf & SYSC_HAS_MIDLEMODE) {
- if (oh->flags & HWMOD_SWSUP_MSTANDBY) {
+ if ((oh->flags & HWMOD_SWSUP_MSTANDBY) ||
+ (oh->flags & HWMOD_FORCE_MSTANDBY)) {
idlemode = HWMOD_IDLEMODE_FORCE;
} else {
if (sf & SYSC_HAS_ENAWAKEUP)
diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index d43d9b6..d5dc935 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -427,8 +427,8 @@ struct omap_hwmod_omap4_prcm {
*
* HWMOD_SWSUP_SIDLE: omap_hwmod code should manually bring module in and out
* of idle, rather than relying on module smart-idle
- * HWMOD_SWSUP_MSTDBY: omap_hwmod code should manually bring module in and out
- * of standby, rather than relying on module smart-standby
+ * HWMOD_SWSUP_MSTANDBY: omap_hwmod code should manually bring module in and
+ * out of standby, rather than relying on module smart-standby
* HWMOD_INIT_NO_RESET: don't reset this module at boot - important for
* SDRAM controller, etc. XXX probably belongs outside the main hwmod file
* XXX Should be HWMOD_SETUP_NO_RESET
@@ -459,6 +459,10 @@ struct omap_hwmod_omap4_prcm {
* correctly, or this is being abused to deal with some PM latency
* issues -- but we're currently suffering from a shortage of
* folks who are able to track these issues down properly.
+ * HWMOD_FORCE_MSTANDBY: Always keep MIDLEMODE bits cleared so that device
+ * is kept in force-standby mode. Failing to do so causes PM problems
+ * with musb on OMAP3630 at least. Note that musb has a dedicated register
+ * to control MSTANDBY signal when MIDLEMODE is set to force-standby.
*/
#define HWMOD_SWSUP_SIDLE (1 << 0)
#define HWMOD_SWSUP_MSTANDBY (1 << 1)
@@ -471,6 +475,7 @@ struct omap_hwmod_omap4_prcm {
#define HWMOD_16BIT_REG(1 << 8)
#define HWMOD_EXT_OPT_MAIN_CLK (1 << 9)
#define HWMOD_BLOCK_WFI(1 << 10)
+#define HWMOD_FORCE_MSTANDBY (1 << 11)
/*
* omap_hwmod._int_flags definitions
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index ac7e03e..5112d04 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1707,9 +1707,14 @@ static struct omap_hwmod omap3xxx_usbhsotg_hwmod = {
* Erratum ID: i479 idle_req / idle_ack mechanism potentially
* broken when autoidle is enabled
* workaround is to disable the autoidle bit at module level.
+*
+* Enabling the device in any other MIDLEMODE setting but force-idle
+* causes core_pwrdm not enter idle states at least on OMAP3630.
+* Note that musb has OTG_FORCESTDBY register that controls MSTANDBY
+* signal when MIDLEMODE is set to force-idle.
*/
.flags = HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE
- | HWMOD_SWSU
Re: [PATCH] omap: convert to devm_ioremap_resource()
Hi On 03/11/2013 05:58 PM, Silviu-Mihai Popescu wrote: > Convert all uses of devm_request_and_ioremap() to the newly introduced > devm_ioremap_resource() which provides more consistent error handling. > > devm_ioremap_resource() provides its own error messages so all explicit > error messages can be removed from the failure code paths. > > Signed-off-by: Silviu-Mihai Popescu > --- > sound/soc/omap/omap-dmic.c |9 +++-- > sound/soc/omap/omap-mcpdm.c |8 +++- > 2 files changed, 6 insertions(+), 11 deletions(-) > Acked-by: Jarkko Nikula -- 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 2/2] ASoC: OMAP2+: Move McBSP, DMIC and McPDM to generic DMA DT binding
On 03/11/2013 04:18 PM, Peter Ujfalusi wrote: > On 03/11/2013 08:50 AM, Sebastien Guiriec wrote: >> Update OMAP2+ driver in order to use OMAP DMA DT binding for OMAP2+. >> In case of DT boot snd_dmaengine_generic_pcm_open function is used. > > Acked-by: Peter Ujfalusi > Acked-by: Jarkko Nikula -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] ARM: dts: OMAP2+: Add SDMA Audio IPs bindings
On 03/11/2013 04:19 PM, Peter Ujfalusi wrote: > On 03/11/2013 08:50 AM, Sebastien Guiriec wrote: >> Populate DMA client information for McBSP DMIC and McPDM periperhal on >> OMAP2+ devices. > > Looks good to me: > Reviewed-by: Peter Ujfalusi > Reviewed-by: Jarkko Nikula -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] ARM: OMAP: gpmc: request CS address space for ethernet chips
On 03/11/2013 07:11 PM, Jon Hunter wrote:
>
> On 03/11/2013 12:57 PM, Javier Martinez Canillas wrote:
>> On 03/11/2013 06:13 PM, Jon Hunter wrote:
>>>
>>
>> Hi Jon, thanks a lot for your feedback.
>>
>>> On 03/10/2013 12:18 PM, Javier Martinez Canillas wrote:
Besides being used to interface with external memory devices,
the General-Purpose Memory Controller can be used to connect
Pseudo-SRAM devices such as ethernet controllers to OMAP2+
processors using the GPMC as a data bus.
The actual mapping between the GPMC address space and OMAP2+
address space is made using the GPMC DT "ranges" property.
But also a explicit call to gpmc_cs_request() is needed.
>>>
>>> One problem with gpmc_cs_request() is that it will map the chip-select
>>> to any physical location in the 1GB address space for the gpmc
>>> controller. So in other words, it will ignore the ranges property
>>> altogether. If you look at my code for NOR, I have added a
>>> gpmc_cs_remap() function to remap the cs to the location as specified by
>>> the device-tree.
>>>
>>
>> I see, thanks for pointing this out.
>>
>>> Ideally we should change gpmc_cs_request() so we can pass the desire
>>> base address that we want to map the gpmc cs too. I had started out that
>>> way but it made the code some what messy and so I opted to create a
>>> gpmc_cs_remap() function instead. The goal will be to get rid of
>>> gpmc_cs_remap() once DT migration is completed and we can change
>>> gpmc_cs_request() to map the cs to a specific address (see my FIXME
>>> comment).
>>>
>>
>> By looking at gpmc_probe_onenand_child() and gpmc_probe_nand_child() I see
>> that
>> these functions just allocates platform data and call gpmc_onenand_init() and
>> gpmc_nand_init() accordingly. So if I understood right these functions have
>> the
>> same issue and need to call gpmc_cs_remap() too in order to map to the
>> location
>> specified on the DT.
>
> Ideally they should but it is not critical.
>
> So today for NAND and ONENAND the ranges property is completely ignored
> (I just came to realise this recently). However, this works because the
> address mapped by gpmc_cs_request() is passed to the NAND/ONENAND
> drivers via the platform data. However, NOR (and your ethernet patch) we
> can't pass via platform data and therefore we must remap.
>
> This needs to be fixed, but it is not critical in terms that it won't
> crash. However, I fear your ethernet patch could :-o
>
>>> Your code probably works today because the cs is setup by the bootloader
>>> and so when you request the cs in the kernel the mapping is not changed
>>> from the bootloader settings. However, if the mapping in DT (ranges
>>> property) is different from that setup by the bootloader then the kernel
>>> would probably crash because the kernel would not remap it as expected.
>>>
So, this patch allows an ethernet chip to be defined as an
GPMC child node an its chip-select memory address be requested.
Signed-off-by: Javier Martinez Canillas
---
Jon,
This patch assumes that we have solved somehow the issue that a
call to request_irq() is needed before before using a GPIO as an
IRQ and this is no longer the case when using from Device Trees.
Anyway, this is independent as how we solve this, whether is
using Jan's patch [1], adding a .request function pointer to
irq_chip as suggested by Stephen [2], or any other approach.
[1]: https://patchwork.kernel.org/patch/2009331/
[2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html
arch/arm/mach-omap2/gpmc.c | 45
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 4fe9ee7..d1bf48b 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1296,6 +1297,42 @@ static int gpmc_probe_onenand_child(struct
platform_device *pdev,
}
#endif
+static int gpmc_probe_ethernet_child(struct platform_device *pdev,
+ struct device_node *child)
+{
+ int ret, cs;
+ unsigned long base;
+ struct resource res;
+ struct platform_device *of_dev;
+
+ if (of_property_read_u32(child, "reg", &cs) < 0) {
+ dev_err(&pdev->dev, "%s has no 'reg' property\n",
+ child->full_name);
+ return -ENODEV;
+ }
+
+ if (of_address_to_resource(child, 0, &res)) {
+ dev_err(&pdev->dev, "%s has malformed 'reg' property\n",
+ child->full_name);
+ return -ENODEV;
+ }
+
+ ret = gpmc_cs_request(cs, resource_size(&res), &base);
>>
Re: [PATCH 1/1] ARM: OMAP: gpmc: request CS address space for ethernet chips
On 03/11/2013 12:57 PM, Javier Martinez Canillas wrote:
> On 03/11/2013 06:13 PM, Jon Hunter wrote:
>>
>
> Hi Jon, thanks a lot for your feedback.
>
>> On 03/10/2013 12:18 PM, Javier Martinez Canillas wrote:
>>> Besides being used to interface with external memory devices,
>>> the General-Purpose Memory Controller can be used to connect
>>> Pseudo-SRAM devices such as ethernet controllers to OMAP2+
>>> processors using the GPMC as a data bus.
>>>
>>> The actual mapping between the GPMC address space and OMAP2+
>>> address space is made using the GPMC DT "ranges" property.
>>> But also a explicit call to gpmc_cs_request() is needed.
>>
>> One problem with gpmc_cs_request() is that it will map the chip-select
>> to any physical location in the 1GB address space for the gpmc
>> controller. So in other words, it will ignore the ranges property
>> altogether. If you look at my code for NOR, I have added a
>> gpmc_cs_remap() function to remap the cs to the location as specified by
>> the device-tree.
>>
>
> I see, thanks for pointing this out.
>
>> Ideally we should change gpmc_cs_request() so we can pass the desire
>> base address that we want to map the gpmc cs too. I had started out that
>> way but it made the code some what messy and so I opted to create a
>> gpmc_cs_remap() function instead. The goal will be to get rid of
>> gpmc_cs_remap() once DT migration is completed and we can change
>> gpmc_cs_request() to map the cs to a specific address (see my FIXME
>> comment).
>>
>
> By looking at gpmc_probe_onenand_child() and gpmc_probe_nand_child() I see
> that
> these functions just allocates platform data and call gpmc_onenand_init() and
> gpmc_nand_init() accordingly. So if I understood right these functions have
> the
> same issue and need to call gpmc_cs_remap() too in order to map to the
> location
> specified on the DT.
Ideally they should but it is not critical.
So today for NAND and ONENAND the ranges property is completely ignored
(I just came to realise this recently). However, this works because the
address mapped by gpmc_cs_request() is passed to the NAND/ONENAND
drivers via the platform data. However, NOR (and your ethernet patch) we
can't pass via platform data and therefore we must remap.
This needs to be fixed, but it is not critical in terms that it won't
crash. However, I fear your ethernet patch could :-o
>> Your code probably works today because the cs is setup by the bootloader
>> and so when you request the cs in the kernel the mapping is not changed
>> from the bootloader settings. However, if the mapping in DT (ranges
>> property) is different from that setup by the bootloader then the kernel
>> would probably crash because the kernel would not remap it as expected.
>>
>>> So, this patch allows an ethernet chip to be defined as an
>>> GPMC child node an its chip-select memory address be requested.
>>>
>>> Signed-off-by: Javier Martinez Canillas
>>> ---
>>>
>>> Jon,
>>>
>>> This patch assumes that we have solved somehow the issue that a
>>> call to request_irq() is needed before before using a GPIO as an
>>> IRQ and this is no longer the case when using from Device Trees.
>>>
>>> Anyway, this is independent as how we solve this, whether is
>>> using Jan's patch [1], adding a .request function pointer to
>>> irq_chip as suggested by Stephen [2], or any other approach.
>>>
>>> [1]: https://patchwork.kernel.org/patch/2009331/
>>> [2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html
>>>
>>> arch/arm/mach-omap2/gpmc.c | 45
>>>
>>> 1 files changed, 45 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
>>> index 4fe9ee7..d1bf48b 100644
>>> --- a/arch/arm/mach-omap2/gpmc.c
>>> +++ b/arch/arm/mach-omap2/gpmc.c
>>> @@ -29,6 +29,7 @@
>>> #include
>>> #include
>>> #include
>>> +#include
>>> #include
>>>
>>> #include
>>> @@ -1296,6 +1297,42 @@ static int gpmc_probe_onenand_child(struct
>>> platform_device *pdev,
>>> }
>>> #endif
>>>
>>> +static int gpmc_probe_ethernet_child(struct platform_device *pdev,
>>> +struct device_node *child)
>>> +{
>>> + int ret, cs;
>>> + unsigned long base;
>>> + struct resource res;
>>> + struct platform_device *of_dev;
>>> +
>>> + if (of_property_read_u32(child, "reg", &cs) < 0) {
>>> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
>>> + child->full_name);
>>> + return -ENODEV;
>>> + }
>>> +
>>> + if (of_address_to_resource(child, 0, &res)) {
>>> + dev_err(&pdev->dev, "%s has malformed 'reg' property\n",
>>> + child->full_name);
>>> + return -ENODEV;
>>> + }
>>> +
>>> + ret = gpmc_cs_request(cs, resource_size(&res), &base);
>>> + if (IS_ERR_VALUE(ret)) {
>>> + dev_err(&pdev->dev, "cannot request GPMC CS %d\n", cs);
>>> + return ret;
>>> + }
>>> +
>>> + of_dev
Re: [PATCH 1/1] ARM: OMAP: gpmc: request CS address space for ethernet chips
On 03/11/2013 06:13 PM, Jon Hunter wrote:
>
Hi Jon, thanks a lot for your feedback.
> On 03/10/2013 12:18 PM, Javier Martinez Canillas wrote:
>> Besides being used to interface with external memory devices,
>> the General-Purpose Memory Controller can be used to connect
>> Pseudo-SRAM devices such as ethernet controllers to OMAP2+
>> processors using the GPMC as a data bus.
>>
>> The actual mapping between the GPMC address space and OMAP2+
>> address space is made using the GPMC DT "ranges" property.
>> But also a explicit call to gpmc_cs_request() is needed.
>
> One problem with gpmc_cs_request() is that it will map the chip-select
> to any physical location in the 1GB address space for the gpmc
> controller. So in other words, it will ignore the ranges property
> altogether. If you look at my code for NOR, I have added a
> gpmc_cs_remap() function to remap the cs to the location as specified by
> the device-tree.
>
I see, thanks for pointing this out.
> Ideally we should change gpmc_cs_request() so we can pass the desire
> base address that we want to map the gpmc cs too. I had started out that
> way but it made the code some what messy and so I opted to create a
> gpmc_cs_remap() function instead. The goal will be to get rid of
> gpmc_cs_remap() once DT migration is completed and we can change
> gpmc_cs_request() to map the cs to a specific address (see my FIXME
> comment).
>
By looking at gpmc_probe_onenand_child() and gpmc_probe_nand_child() I see that
these functions just allocates platform data and call gpmc_onenand_init() and
gpmc_nand_init() accordingly. So if I understood right these functions have the
same issue and need to call gpmc_cs_remap() too in order to map to the location
specified on the DT.
> Your code probably works today because the cs is setup by the bootloader
> and so when you request the cs in the kernel the mapping is not changed
> from the bootloader settings. However, if the mapping in DT (ranges
> property) is different from that setup by the bootloader then the kernel
> would probably crash because the kernel would not remap it as expected.
>
>> So, this patch allows an ethernet chip to be defined as an
>> GPMC child node an its chip-select memory address be requested.
>>
>> Signed-off-by: Javier Martinez Canillas
>> ---
>>
>> Jon,
>>
>> This patch assumes that we have solved somehow the issue that a
>> call to request_irq() is needed before before using a GPIO as an
>> IRQ and this is no longer the case when using from Device Trees.
>>
>> Anyway, this is independent as how we solve this, whether is
>> using Jan's patch [1], adding a .request function pointer to
>> irq_chip as suggested by Stephen [2], or any other approach.
>>
>> [1]: https://patchwork.kernel.org/patch/2009331/
>> [2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html
>>
>> arch/arm/mach-omap2/gpmc.c | 45
>>
>> 1 files changed, 45 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
>> index 4fe9ee7..d1bf48b 100644
>> --- a/arch/arm/mach-omap2/gpmc.c
>> +++ b/arch/arm/mach-omap2/gpmc.c
>> @@ -29,6 +29,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #include
>> @@ -1296,6 +1297,42 @@ static int gpmc_probe_onenand_child(struct
>> platform_device *pdev,
>> }
>> #endif
>>
>> +static int gpmc_probe_ethernet_child(struct platform_device *pdev,
>> + struct device_node *child)
>> +{
>> +int ret, cs;
>> +unsigned long base;
>> +struct resource res;
>> +struct platform_device *of_dev;
>> +
>> +if (of_property_read_u32(child, "reg", &cs) < 0) {
>> +dev_err(&pdev->dev, "%s has no 'reg' property\n",
>> +child->full_name);
>> +return -ENODEV;
>> +}
>> +
>> +if (of_address_to_resource(child, 0, &res)) {
>> +dev_err(&pdev->dev, "%s has malformed 'reg' property\n",
>> +child->full_name);
>> +return -ENODEV;
>> +}
>> +
>> +ret = gpmc_cs_request(cs, resource_size(&res), &base);
>> +if (IS_ERR_VALUE(ret)) {
>> +dev_err(&pdev->dev, "cannot request GPMC CS %d\n", cs);
>> +return ret;
>> +}
>> +
>> +of_dev = of_platform_device_create(child, NULL, &pdev->dev);
>> +if (!of_dev) {
>> +dev_err(&pdev->dev, "cannot create platform device for %s\n",
>> +child->full_name);
>> +return -ENODEV;
>> +}
>> +
>> +return 0;
>> +}
>
> So this function does not setup the cs at all and so that means you are
> dependent on having the bootloader configure the cs. I would really like
> to get away from that sort of dependency. In fact I am wondering if we
> could make the gpmc_probe_nor() function a gpmc_probe_generic() that we
> can use for both nor and ethernet as we are doing very similar things
> (if we add the timings and
Re: [PATCH 5/9] ARM: dts: Add GPMC node for OMAP2, OMAP4 and OMAP5
On 03/09/2013 06:42 AM, Ezequiel Garcia wrote: > On Fri, Mar 8, 2013 at 10:25 PM, Javier Martinez Canillas > wrote: >> On Fri, Mar 8, 2013 at 10:41 PM, Jon Hunter wrote: >>> >>> Yes you are correct. In general, I have been trying to stay some-what >>> consistent with what hwmod was doing as this was being auto-generated by >>> some hardware design specs and I believe they wanted to eventually get >>> to the point where DT files would be auto-generated too for OMAP. >>> Furthermore my understanding is that the smallest page that can be >>> mapped by the kernel for ARM is 4kB. So if you declare it as 0x2d0 or >>> 0x1000 it will map a 4kB page (I could be wrong here). >>> >>> I don't have any strong feelings here but will do what the consensus >>> prefers. >>> >> >> Yes, you are right here. >> >> I forget that ioremap() does a page-aligned mapping and since the >> minimum page size for ARM is 4KB as you said, there is no difference >> between using 0x2d0 and 0x1000. Sorry for the noise. >> > > Certainly, I don't have strong feelings about this. > FWIW, mvebu maintainers imposes a "minimal" address space request > policy. > > On the other side, it seems to me we shouldn't look at internal kernel > implementation (i.e. ioremap page-alignment) to make this decision. I agree with that. I am not sure if Tony/Benoit have any comments on what they would like to do here to be consistent for the omap bindings. > Somehow, I feel this is almost a nitpick, so don't take this too seriously. No problem. Probably good to align on something sooner rather than later. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
On 03/10/2013 09:45 PM, Anil Kumar wrote:
> Hi Jon,
>
> On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter wrote:
>> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
>> of RAM and uses the TWL4030 power management IC.
>>
>> Signed-off-by: Jon Hunter
>> ---
>> arch/arm/boot/dts/Makefile |1 +
>> arch/arm/boot/dts/omap3430-sdp.dts | 46
>>
>> 2 files changed, 47 insertions(+)
>> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 9c62558..89013ed 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>> omap3-beagle-xm.dtb \
>> omap3-evm.dtb \
>> omap3-tobi.dtb \
>> + omap3430-sdp.dtb \
>> omap4-panda.dtb \
>> omap4-panda-a4.dtb \
>> omap4-panda-es.dtb \
>> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
>> b/arch/arm/boot/dts/omap3430-sdp.dts
>> new file mode 100644
>> index 000..be0650d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
>> @@ -0,0 +1,46 @@
>> +/*
>> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +/dts-v1/;
>> +
>> +/include/ "omap3.dtsi"
>> +
>> +/ {
>> + model = "TI OMAP3430 SDP";
>> + compatible = "ti,omap3430-sdp", "ti,omap3";
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x8000 0x1000>; /* 256 MB */
>> + };
>> +};
>> +
>> +&i2c1 {
>> + clock-frequency = <260>;
>> +
>> + twl: twl@48 {
>> + reg = <0x48>;
>> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>> + interrupt-parent = <&intc>;
>
> No need of "interrupt-parent = <&intc>" as it is with root node
> already.
Yes you are correct. Will update.
Thanks
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/9] ARM: dts: OMAP3: Add support for OMAP3430 SDP board
On 03/08/2013 08:25 PM, Anil Kumar wrote:
> Hi Jon,
>
> On Fri, Mar 8, 2013 at 10:57 PM, Jon Hunter wrote:
>> Adds basic device-tree support for OMAP3430 SDP board which has 256MB
>> of RAM and uses the TWL4030 power management IC.
>
> I think this board support should be in separate patch series with
> related patches.
Well I wanted to keep them altogether so that I can send a pull request
to Benoit and Tony.
>>
>> Signed-off-by: Jon Hunter
>> ---
>> arch/arm/boot/dts/Makefile |1 +
>> arch/arm/boot/dts/omap3430-sdp.dts | 46
>>
>> 2 files changed, 47 insertions(+)
>> create mode 100644 arch/arm/boot/dts/omap3430-sdp.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 9c62558..89013ed 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -119,6 +119,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>> omap3-beagle-xm.dtb \
>> omap3-evm.dtb \
>> omap3-tobi.dtb \
>> + omap3430-sdp.dtb \
>> omap4-panda.dtb \
>> omap4-panda-a4.dtb \
>> omap4-panda-es.dtb \
>> diff --git a/arch/arm/boot/dts/omap3430-sdp.dts
>> b/arch/arm/boot/dts/omap3430-sdp.dts
>> new file mode 100644
>> index 000..be0650d
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/omap3430-sdp.dts
>> @@ -0,0 +1,46 @@
>> +/*
>> + * Copyright (C) 2013 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +/dts-v1/;
>> +
>> +/include/ "omap3.dtsi"
>> +
>> +/ {
>> + model = "TI OMAP3430 SDP";
>> + compatible = "ti,omap3430-sdp", "ti,omap3";
>
> I have not seen any related changes in "board-generic.c" for your board.
> So just wanted know, how this board is booting ?
If you look at board-generic.c you will see that "ti,omap3" will match
the OMAP3 generic machine. So you don't need to modify the board-generic.c.
>> +
>> + memory {
>> + device_type = "memory";
>> + reg = <0x8000 0x1000>; /* 256 MB */
>> + };
>> +};
>> +
>> +&i2c1 {
>> + clock-frequency = <260>;
>> +
>> + twl: twl@48 {
>> + reg = <0x48>;
>> + interrupts = <7>; /* SYS_NIRQ cascaded to intc */
>> + interrupt-parent = <&intc>;
>> + };
>> +};
>> +
>> +/include/ "twl4030.dtsi"
>> +
>> +&mmc1 {
>> + vmmc-supply = <&vmmc1>;
>> + vmmc_aux-supply = <&vsim>;
>> + bus-width = <8>;
>> +};
>> +
>> +&mmc2 {
>> + status = "disabled";
>> +};
>> +
>> +&mmc3 {
>> + status = "disabled";
>> +};
>
> I think you should disable modules those are not currently used
> as they are enabled by default in omap3.dtsi.
>
> exp:-
>
> &mcbsp2 {
> status = "disabled";
> };
Well may be we could do that in a follow-up patch. If you look at other
omap3 boards we have not gone through and disabled all unused modules
either. So although I agree, right now I just want to get minimal
support added.
Jon
--
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] usb: musb: log VBUS error
* Grazvydas Ignotas [130311 10:12]: > On Mon, Mar 11, 2013 at 6:24 PM, Tony Lindgren wrote: > > * Grazvydas Ignotas [130309 16:53]: > >> VBUS_ERROR is a serious error that the driver often doesn't recover from > >> in my tests, so we should at least inform the user about it. > > > > Patch makes sens to me, just a related question.. > > > > Do you get this when trying to enable the host mode, right? Or have you seen > > this in other situations too? > > I sometimes see it when booting with cable connected to PC or > connecting cable to PC after using a host adapter. In those cases OTG > port dies completely until a powercycle :( Hmm OK. I suspect there's some kernel bug currently with the OTG id pin detection where it's initial state during the boot is ignored. But replugging the cable should fix that, and in your case it sounds like that's not the case. > > If the error happens when enabling the host mode, my experience is that > > the VBUS_ERROR is caused by the musb trying to be too smart and doing the > > timeouts automatically. If the VBUS on the hardware does not raise fast > > enough to the right range for whatever reason, musb can produce this > > error. > > Yeah the driver seems to expect that and has a "ignore" variable, I > use KERN_DEBUG level in case it's set. Yes in the host case I think we then just retry enabling the session bit and don't have anything in place to check that the VBUS regulator is ready or not. Have not looked at that code for a while though. 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 1/1] ARM: OMAP: gpmc: request CS address space for ethernet chips
On 03/10/2013 12:18 PM, Javier Martinez Canillas wrote:
> Besides being used to interface with external memory devices,
> the General-Purpose Memory Controller can be used to connect
> Pseudo-SRAM devices such as ethernet controllers to OMAP2+
> processors using the GPMC as a data bus.
>
> The actual mapping between the GPMC address space and OMAP2+
> address space is made using the GPMC DT "ranges" property.
> But also a explicit call to gpmc_cs_request() is needed.
One problem with gpmc_cs_request() is that it will map the chip-select
to any physical location in the 1GB address space for the gpmc
controller. So in other words, it will ignore the ranges property
altogether. If you look at my code for NOR, I have added a
gpmc_cs_remap() function to remap the cs to the location as specified by
the device-tree.
Ideally we should change gpmc_cs_request() so we can pass the desire
base address that we want to map the gpmc cs too. I had started out that
way but it made the code some what messy and so I opted to create a
gpmc_cs_remap() function instead. The goal will be to get rid of
gpmc_cs_remap() once DT migration is completed and we can change
gpmc_cs_request() to map the cs to a specific address (see my FIXME
comment).
Your code probably works today because the cs is setup by the bootloader
and so when you request the cs in the kernel the mapping is not changed
from the bootloader settings. However, if the mapping in DT (ranges
property) is different from that setup by the bootloader then the kernel
would probably crash because the kernel would not remap it as expected.
> So, this patch allows an ethernet chip to be defined as an
> GPMC child node an its chip-select memory address be requested.
>
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Jon,
>
> This patch assumes that we have solved somehow the issue that a
> call to request_irq() is needed before before using a GPIO as an
> IRQ and this is no longer the case when using from Device Trees.
>
> Anyway, this is independent as how we solve this, whether is
> using Jan's patch [1], adding a .request function pointer to
> irq_chip as suggested by Stephen [2], or any other approach.
>
> [1]: https://patchwork.kernel.org/patch/2009331/
> [2]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85592.html
>
> arch/arm/mach-omap2/gpmc.c | 45
>
> 1 files changed, 45 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 4fe9ee7..d1bf48b 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include
> @@ -1296,6 +1297,42 @@ static int gpmc_probe_onenand_child(struct
> platform_device *pdev,
> }
> #endif
>
> +static int gpmc_probe_ethernet_child(struct platform_device *pdev,
> + struct device_node *child)
> +{
> + int ret, cs;
> + unsigned long base;
> + struct resource res;
> + struct platform_device *of_dev;
> +
> + if (of_property_read_u32(child, "reg", &cs) < 0) {
> + dev_err(&pdev->dev, "%s has no 'reg' property\n",
> + child->full_name);
> + return -ENODEV;
> + }
> +
> + if (of_address_to_resource(child, 0, &res)) {
> + dev_err(&pdev->dev, "%s has malformed 'reg' property\n",
> + child->full_name);
> + return -ENODEV;
> + }
> +
> + ret = gpmc_cs_request(cs, resource_size(&res), &base);
> + if (IS_ERR_VALUE(ret)) {
> + dev_err(&pdev->dev, "cannot request GPMC CS %d\n", cs);
> + return ret;
> + }
> +
> + of_dev = of_platform_device_create(child, NULL, &pdev->dev);
> + if (!of_dev) {
> + dev_err(&pdev->dev, "cannot create platform device for %s\n",
> + child->full_name);
> + return -ENODEV;
> + }
> +
> + return 0;
> +}
So this function does not setup the cs at all and so that means you are
dependent on having the bootloader configure the cs. I would really like
to get away from that sort of dependency. In fact I am wondering if we
could make the gpmc_probe_nor() function a gpmc_probe_generic() that we
can use for both nor and ethernet as we are doing very similar things
(if we add the timings and gpmc settings to the ethernet binding).
Also I think we need to add some DT binding documentation for this as well.
Cheers
Jon
--
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] usb: musb: log VBUS error
On Mon, Mar 11, 2013 at 6:24 PM, Tony Lindgren wrote: > * Grazvydas Ignotas [130309 16:53]: >> VBUS_ERROR is a serious error that the driver often doesn't recover from >> in my tests, so we should at least inform the user about it. > > Patch makes sens to me, just a related question.. > > Do you get this when trying to enable the host mode, right? Or have you seen > this in other situations too? I sometimes see it when booting with cable connected to PC or connecting cable to PC after using a host adapter. In those cases OTG port dies completely until a powercycle :( > If the error happens when enabling the host mode, my experience is that > the VBUS_ERROR is caused by the musb trying to be too smart and doing the > timeouts automatically. If the VBUS on the hardware does not raise fast > enough to the right range for whatever reason, musb can produce this > error. Yeah the driver seems to expect that and has a "ignore" variable, I use KERN_DEBUG level in case it's set. > > Regards, > > Tony > -- 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: omapdss wakeup issues
On Tue, Mar 5, 2013 at 7:44 PM, Andreas Müller wrote: > On Fri, Mar 1, 2013 at 10:07 PM, Andreas Müller > wrote: >> On Thu, Feb 28, 2013 at 5:27 PM, Andreas Müller >> wrote: >>> Hi, >>> >>> I am preparing 3.8 mainline for gumstix overo and have the following >>> issue: waking Monitor connected by HDMI from power save makes Monitor >>> complain for unsupported frequency and console says: >>> >>> | omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay >>> >>> Is this a known issue? >>> >> Sorry for the noise but this is the only issue I have with 3.8.1 >> stable (currently). Some further notes: >> >> * with old OMAP 3530 (only 600MHz capable) the HDMI does not work for >> warm restart and not for pressing reset. The only way out is power-off >> / power on. This I saw with 3.6 the first time but I did not follow it >> at that time. >> * My kernel command line is >> console=ttyO2,115200n8 mpurate=800 vram=12M >> omapfb.mode=dvi:1280x1024MR-24@60 omapdss.def_disp=dvi >> root=/dev/mmcblk0p2 rw rootfstype=ext4 rootwait >> I added omapdss.debug=y and omapdss.debug=1 but that did give me >> further information. Are there other settings available helping to >> debug this? >> * I attached kernel config and bootlog for proper start - maybe this >> gives some hint. >> * Monitor power down is caused by XFCE power management >> >> Is there any other information I can give to solve this? >> > FWIW DM3730 (Overo fire storm) the wakeup causes some additional warning > > omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay > [ cut here ] > WARNING: at drivers/video/omap2/dss/dispc.c:543 dispc_mgr_go+0x20/0x54() > Modules linked in: libertas_sdio libertas lib80211 cfg80211 rfkill > ads7846 gpio_keys > [] (unwind_backtrace+0x0/0xe0) from [] > (warn_slowpath_common+0x4c/0x64) > [] (warn_slowpath_common+0x4c/0x64) from [] > (warn_slowpath_null+0x18/0x1c) > [] (warn_slowpath_null+0x18/0x1c) from [] > (dispc_mgr_go+0x20/0x54) > [] (dispc_mgr_go+0x20/0x54) from [] > (dispc_error_worker+0x6c/0x18c) > [] (dispc_error_worker+0x6c/0x18c) from [] > (process_one_work+0x1fc/0x3dc) > [] (process_one_work+0x1fc/0x3dc) from [] > (worker_thread+0x238/0x34c) > [] (worker_thread+0x238/0x34c) from [] (kthread+0xa0/0xb0) > [] (kthread+0xa0/0xb0) from [] (ret_from_fork+0x14/0x3c) > ---[ end trace 40fcd9df3dd2aaf5 ]--- > > Andreas FWIW taken on DM3730 @ 800MHz 1. All OK root@overo:~# cat /sys/kernel/debug/omapdss/dispc_irq period 34640 ms irqs 0 FRAMEDONE 0 VSYNC 0 EVSYNC_EVEN 0 EVSYNC_ODD0 ACBIAS_COUNT_STAT 0 PROG_LINE_NUM 0 GFX_FIFO_UNDERFLOW0 GFX_END_WIN 0 PAL_GAMMA_MASK0 OCP_ERR 0 VID1_FIFO_UNDERFLOW 0 VID1_END_WIN 0 VID2_FIFO_UNDERFLOW 0 VID2_END_WIN 0 SYNC_LOST 0 SYNC_LOST_DIGIT 0 WAKEUP0 2. Monitor off cat /sys/kernel/debug/omapdss/dispc_irq period 652843 ms irqs 1 FRAMEDONE 1 VSYNC 1 EVSYNC_EVEN 0 EVSYNC_ODD0 ACBIAS_COUNT_STAT 0 PROG_LINE_NUM 1 GFX_FIFO_UNDERFLOW0 GFX_END_WIN 1 PAL_GAMMA_MASK0 OCP_ERR 0 VID1_FIFO_UNDERFLOW 0 VID1_END_WIN 0 VID2_FIFO_UNDERFLOW 0 VID2_END_WIN 0 SYNC_LOST 0 SYNC_LOST_DIGIT 0 WAKEUP1 3. Wakeup root@overo:~# omapdss APPLY error: FIFO UNDERFLOW on gfx, disabling the overlay cat /sys/kernel/debug/omapdss/dispc_irq period 42140 ms irqs 1 FRAMEDONE 0 VSYNC 0 EVSYNC_EVEN 0 EVSYNC_ODD0 ACBIAS_COUNT_STAT 0 PROG_LINE_NUM 1 GFX_FIFO_UNDERFLOW1 GFX_END_WIN 0 PAL_GAMMA_MASK0 OCP_ERR 0 VID1_FIFO_UNDERFLOW 0 VID1_END_WIN 0 VID2_FIFO_UNDERFLOW 0 VID2_END_WIN 0 SYNC_LOST 0 SYNC_LOST_DIGIT 0 WAKEUP0 Is there some other information which might be helpful to solve this? Andreas -- 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: OMAP3: hwmod data: disable MIDLEMODE control for musb
Hello Gražvydas, On Mon, 11 Mar 2013, Grazvydas Ignotas wrote: > Soft reset seems to recover from this so there is no problem, but you > can't reset before every suspend so a workaround is still needed.. OK, that's good. > Well as long as it works it's good for me, although it'll bloat the > code a bit compared to just changing the data. Should I attempt an > implementation? Please do. I'd be shocked if it comes out to more than four or five extra ARM instructions... - Paul
Re: [PATCH] ARM: OMAP3: hwmod data: disable MIDLEMODE control for musb
On Mon, Mar 11, 2013 at 1:15 AM, Paul Walmsley wrote: > Hi Gražvydas, > > On Sun, 10 Mar 2013, Grazvydas Ignotas wrote: > >> For some unknown reason, allowing hwmod to control MIDLEMODE causes >> core_pwrdm to not hit idle states for musb in DM3730 at least. >> I've verified that setting any MIDLEMODE value other than "force >> standby" before enabling the device causes subsequent suspend >> attempts to fail with core_pwrdm not entering idle states, even >> if the driver is unloaded and "force standby" is restored before >> suspend attempt. > > Ugh sounds like a broken bootloader/previous OS could easily block full > chip idle in this case :-( Does that match your understanding? That, even > if the new kernel does everything right in terms of initialization and > reset, the PRCM's perception of whether the device is in STANDBY is > permanently stuck? Soft reset seems to recover from this so there is no problem, but you can't reset before every suspend so a workaround is still needed.. >> Keeping the register set at force standby (reset value) makes it work >> and device still functions properly. musb has driver-controlled >> OTG_FORCESTDBY register that controls MSTANDBY signal, so perhaps >> MIDLEMODE is not even needed? Note that TI PSP kernels also have >> similar workarounds. > > Would like to get your opinion on a different implementation. For other > situations where IP blocks don't work in the standard, expected way, we've > defined hwmod flags for those situations, like HWMOD_SWSUP_*, and > HWMOD_NO_OCP_AUTOIDLE. The motivation is to affirmatively mark IP > blocks that don't work as expected, rather than changing the existing, > documented hardware bits, which are ideally autogenerated. > > So what do you think about adding a hwmod flag, HWMOD_FORCE_MSTDBY, and > using that in the hwmod code to program the MSTDBYMODE to FORCE_STANDBY > and then skipping all other attempts to write to it? Well as long as it works it's good for me, although it'll bloat the code a bit compared to just changing the data. Should I attempt an implementation? -- 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 V2 2/2] ASoC: OMAP2+: Move McBSP, DMIC and McPDM to generic DMA DT binding
* Mark Brown [130311 09:32]: > On Mon, Mar 11, 2013 at 09:27:00AM -0700, Tony Lindgren wrote: > > > I suggest you take the driver changes and Benoit takes the .dts > > changes as those should be queued separately to avoid unnecessary > > merge conflicts with the .dts files. > > Won't that cause a bisect issue if the driver starts looking for generic > DT stuff that's not in the DTS files? It should only affect additional features being enabled. When the .dts changes get merged the new features just starts working. Or if the .dts changes go in first, the driver starts working when the driver changes go in. If there's some dependency between the driver and the .dts changes breaking booting etc, that should be fixed in the patches by for example removing old legacy code later on in a separate series. This allows us to break the dependency between arch/arm code and drivers in most cases to keep things simpler. 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: OMAP: drop "select MACH_NOKIA_RM696"
* Paul Bolle [130309 11:52]: > On Sat, 2013-03-09 at 00:01 +, Russell King - ARM Linux wrote: > > > However, going back to that MACH_NOKIA_RM696. If there exists only a > > select of this symbol and no "config MACH_NOKIA_RM696" entry, then the > > symbol will never be generated in the output .config file. > > > >[...] > > > > My conclusion is... it's a mess. > > That mess can only be fully cleaned up if the code for the RM-696 that > now is maintained in some unknown to me repository gets merged into > mainline, can't it? > > In the meantime, how do you prefer I solve the (trivial) issue of an > useless select for MACH_NOKIA_RM696? Drop that select or add an (equally > useless) config entry for MACH_NOKIA_RM696? Or should I try to ignore it > for the time being? Just adding the config MACH_NOKIA_RM696 to Kconfig as bool should fix this unless I'm missing something here. 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 V2 2/2] ASoC: OMAP2+: Move McBSP, DMIC and McPDM to generic DMA DT binding
On Mon, Mar 11, 2013 at 09:27:00AM -0700, Tony Lindgren wrote: > I suggest you take the driver changes and Benoit takes the .dts > changes as those should be queued separately to avoid unnecessary > merge conflicts with the .dts files. Won't that cause a bisect issue if the driver starts looking for generic DT stuff that's not in the DTS files? signature.asc Description: Digital signature
Re: [PATCH V2 2/2] ASoC: OMAP2+: Move McBSP, DMIC and McPDM to generic DMA DT binding
* Mark Brown [130311 07:37]: > On Mon, Mar 11, 2013 at 08:50:22AM +0100, Sebastien Guiriec wrote: > > Update OMAP2+ driver in order to use OMAP DMA DT binding for OMAP2+. > > In case of DT boot snd_dmaengine_generic_pcm_open function is used. > > Acked-by: Mark Brown > > or I can apply to ASoC if people prefer, I don't think it makes much > difference either way. I suggest you take the driver changes and Benoit takes the .dts changes as those should be queued separately to avoid unnecessary merge conflicts with the .dts files. 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] usb: musb: log VBUS error
* Grazvydas Ignotas [130309 16:53]:
> VBUS_ERROR is a serious error that the driver often doesn't recover from
> in my tests, so we should at least inform the user about it.
Patch makes sens to me, just a related question..
Do you get this when trying to enable the host mode, right? Or have you seen
this in other situations too?
If the error happens when enabling the host mode, my experience is that
the VBUS_ERROR is caused by the musb trying to be too smart and doing the
timeouts automatically. If the VBUS on the hardware does not raise fast
enough to the right range for whatever reason, musb can produce this
error.
Regards,
Tony
> Signed-off-by: Grazvydas Ignotas
> ---
> drivers/usb/musb/musb_core.c |3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
> index f95404e..df6a54e 100644
> --- a/drivers/usb/musb/musb_core.c
> +++ b/drivers/usb/musb/musb_core.c
> @@ -602,7 +602,8 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8
> int_usb,
> break;
> }
>
> - dev_dbg(musb->controller, "VBUS_ERROR in %s (%02x, %s), retry
> #%d, port1 %08x\n",
> + dev_printk(ignore ? KERN_DEBUG : KERN_ERR, musb->controller,
> +"VBUS_ERROR in %s (%02x, %s), retry #%d, port1
> %08x\n",
> otg_state_string(musb->xceiv->state),
> devctl,
> ({ char *s;
> --
> 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
--
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] omap: convert to devm_ioremap_resource()
Convert all uses of devm_request_and_ioremap() to the newly introduced
devm_ioremap_resource() which provides more consistent error handling.
devm_ioremap_resource() provides its own error messages so all explicit
error messages can be removed from the failure code paths.
Signed-off-by: Silviu-Mihai Popescu
---
sound/soc/omap/omap-dmic.c |9 +++--
sound/soc/omap/omap-mcpdm.c |8 +++-
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index 77e9e7e..8ebaf11 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -493,12 +493,9 @@ static int asoc_dmic_probe(struct platform_device *pdev)
goto err_put_clk;
}
- dmic->io_base = devm_request_and_ioremap(&pdev->dev, res);
- if (!dmic->io_base) {
- dev_err(&pdev->dev, "cannot remap\n");
- ret = -ENOMEM;
- goto err_put_clk;
- }
+ dmic->io_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(dmic->io_base))
+ return PTR_ERR(dmic->io_base);
ret = snd_soc_register_dai(&pdev->dev, &omap_dmic_dai);
if (ret)
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index 079f277..ddfcc18 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -464,11 +464,9 @@ static int asoc_mcpdm_probe(struct platform_device *pdev)
if (res == NULL)
return -ENOMEM;
- mcpdm->io_base = devm_request_and_ioremap(&pdev->dev, res);
- if (!mcpdm->io_base) {
- dev_err(&pdev->dev, "cannot remap\n");
- return -ENOMEM;
- }
+ mcpdm->io_base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(mcpdm->io_base))
+ return PTR_ERR(mcpdm->io_base);
mcpdm->irq = platform_get_irq(pdev, 0);
if (mcpdm->irq < 0)
--
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: [PATCH 02/13] USB: phy: nop: Defer probe if device needs VCC/RESET
On 02/05/2013 10:43 AM, Roger Quadros wrote:
> On 02/05/2013 11:09 AM, Felipe Balbi wrote:
>> On Tue, Feb 05, 2013 at 10:44:05AM +0200, Roger Quadros wrote:
> diff --git a/include/linux/usb/nop-usb-xceiv.h
> b/include/linux/usb/nop-usb-xceiv.h
> index 3265b61..148d351 100644
> --- a/include/linux/usb/nop-usb-xceiv.h
> +++ b/include/linux/usb/nop-usb-xceiv.h
> @@ -6,6 +6,10 @@
> struct nop_usb_xceiv_platform_data {
> enum usb_phy_type type;
> unsigned long clk_rate;
> +
> +/* if set fails with -EPROBE_DEFER if can't get regulator */
> +unsigned int needs_vcc:1;
> +unsigned int needs_reset:1;
how about u8 here?
>>>
>>> Not sure. Bitfields are usually defined as unsigned int.
>>
>> IIRC the benefit is that compiler can try to optimize those flags. I
>> mean, if you have 32 1-bit flags, compiler will combine those in a
>> single u32. Someone correct me if I'm wrong.
>>
>
> Yes you are right. Kishon was asking me to use u8 instead of unsigned int,
> which
> I don't think is necessary. AFAIK, it is a norm to use unsigned int when
> defining
> a bitfield. Compilers are known to behave funny with bitfields. I don't mind
> using bool for each.
In the current version (rogerq/v3.8-usbhost17-dt) of this patch you've
put both needs_* into the private data struct and the pdata, but it's
only used inside the probe function.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 01/13] usb: phy: nop: Add device tree support and binding information
On 03/11/2013 09:40 AM, Roger Quadros wrote:
> On 03/08/2013 05:45 PM, Marc Kleine-Budde wrote:
>> On 03/08/2013 11:46 AM, Marc Kleine-Budde wrote:
>>> On 02/04/2013 04:58 PM, Roger Quadros wrote:
The PHY clock, clock rate, VCC regulator and RESET regulator
can now be provided via device tree.
Signed-off-by: Roger Quadros
---
.../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
drivers/usb/otg/nop-usb-xceiv.c| 31
++
2 files changed, 65 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
new file mode 100644
index 000..d7e2726
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -0,0 +1,34 @@
+USB NOP PHY
+
+Required properties:
+- compatible: should be usb-nop-xceiv
+
+Optional properties:
+- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
+ /bindings/clock/clock-bindings.txt
+ This property is required if clock-frequency is specified.
+
+- clock-names: Should be "main_clk"
+
+- clock-frequency: the clock frequency (in Hz) that the PHY clock must
+ be configured to.
+
+- vcc-supply: phandle to the regulator that provides RESET to the PHY.
+
+- reset-supply: phandle to the regulator that provides power to the PHY.
+
+Example:
+
+ hsusb1_phy {
+ compatible = "usb-nop-xceiv";
+ clock-frequency = <1920>;
>>>
>>> Why do you hardcode the clock frequency here? You should use
>>> clk_get_rate() to get the frequency from the clock tree.
>>
>> What about declaring a "fixed-clock" node in the device tree? Then it
>> should be possible to keep the driver free of any omap specific code.
>>
>
> The current implementation is not OMAP specific and is not limited to a
> fixed frequency clock. The PHY driver is using standard clock APIs to set
> the clock rate 'only' if the 'clock-frequency' property is present in the
> device tree node.
>
> What is the benefit of declaring it as a "fixed-clock"?
> FYI. The clock may not necessarily be a fixed frequency clock and someone
> needs to program the rate.
Okay, now I got it.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 01/13] usb: phy: nop: Add device tree support and binding information
On 02/05/2013 08:26 AM, Felipe Balbi wrote:
> Hi,
>
> On Mon, Feb 04, 2013 at 05:58:48PM +0200, Roger Quadros wrote:
>> The PHY clock, clock rate, VCC regulator and RESET regulator
>> can now be provided via device tree.
>>
>> Signed-off-by: Roger Quadros
>> ---
>> .../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
>>
>> drivers/usb/otg/nop-usb-xceiv.c| 31 ++
>> 2 files changed, 65 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>
>> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> new file mode 100644
>> index 000..d7e2726
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>> @@ -0,0 +1,34 @@
>> +USB NOP PHY
>> +
>> +Required properties:
>> +- compatible: should be usb-nop-xceiv
>> +
>> +Optional properties:
>> +- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
>> + /bindings/clock/clock-bindings.txt
>> + This property is required if clock-frequency is specified.
>> +
>> +- clock-names: Should be "main_clk"
>> +
>> +- clock-frequency: the clock frequency (in Hz) that the PHY clock must
>> + be configured to.
>> +
>> +- vcc-supply: phandle to the regulator that provides RESET to the PHY.
>> +
>> +- reset-supply: phandle to the regulator that provides power to the PHY.
>> +
>> +Example:
>> +
>> +hsusb1_phy {
>> +compatible = "usb-nop-xceiv";
>> +clock-frequency = <1920>;
>> +clocks = <&osc 0>;
>> +clock-names = "main_clk";
>> +vcc-supply = <&hsusb1_vcc_regulator>;
>> +reset-supply = <&hsusb1_reset_regulator>;
>> +};
>> +
>> +hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
>> +and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
>> +hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
>> +controls RESET.
>> diff --git a/drivers/usb/otg/nop-usb-xceiv.c
>> b/drivers/usb/otg/nop-usb-xceiv.c
>> index ac027a1..adbb7ab 100644
>> --- a/drivers/usb/otg/nop-usb-xceiv.c
>> +++ b/drivers/usb/otg/nop-usb-xceiv.c
>> @@ -34,6 +34,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> struct nop_usb_xceiv {
>> struct usb_phy phy;
>> @@ -138,8 +139,19 @@ static int nop_set_host(struct usb_otg *otg, struct
>> usb_bus *host)
>> return 0;
>> }
>>
>> +static void nop_xeiv_get_dt_pdata(struct device *dev,
>
> asking to remove, but xeiv != xceiv :-)
>
>> +struct nop_usb_xceiv_platform_data *pdata)
>> +{
>> +struct device_node *node = dev->of_node;
>> +u32 clk_rate;
>> +
>> +if (!of_property_read_u32(node, "clock-frequency", &clk_rate))
>> +pdata->clk_rate = clk_rate;
>> +}
>> +
>> static int nop_usb_xceiv_probe(struct platform_device *pdev)
>> {
>> +struct device *dev = &pdev->dev;
>> struct nop_usb_xceiv_platform_data *pdata = pdev->dev.platform_data;
>> struct nop_usb_xceiv*nop;
>> enum usb_phy_type type = USB_PHY_TYPE_USB2;
>> @@ -153,6 +165,17 @@ static int nop_usb_xceiv_probe(struct platform_device
>> *pdev)
>> if (!nop->phy.otg)
>> return -ENOMEM;
>>
>> +if (dev->of_node) {
>> +pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
>> +if (!pdata) {
>> +dev_err(dev, "Memory allocation failure\n");
>> +return -ENOMEM;
>> +}
>> +nop_xeiv_get_dt_pdata(dev, pdata);
>
> actually, I would prefer to not create pdata at all. I mean, ideally
> pdata would be used to initialize fields in your own structure, so first
> move clk_rate to your own private structure, copy pdata's clk_rate value
> to that, then you don't need this hackery when using DT.
As far as I can see, clk_rate is never used, but in the probe function.
Why should it be saved into the private data structure at all?
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
Re: [Resend/PATCH 0/5] omap4/5: i2c/spi: device tree data
On Monday 11 March 2013 08:02 PM, Benoit Cousson wrote: Hi Sourav, On 03/11/2013 02:44 PM, Sourav Poddar wrote: Hi Tony/Benoit, These patches had been sent couple of times before, but there were no comments on it. Sorry for that. I got a big flu in Jan and was in Linaro Connect last week. Patches look good, I just have to check that they apply nicely to the dts/for_3.9 I already prepared. Ok. Thanks!! I still have to rebase that branch on top of a recent master branch and then check your branch. If there are no comments, Can these be picked ? Cc: Andrew Morton The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: g...@gitorious.org:linux-connectivity/linux-connectivity.git omap_i2c_spi_dts_data Felipe Balbi (1): arm: dts: omap5: add SPI devices to OMAP5 DeviceTree file Sourav Poddar (4): arm: dts: omap4-sdp: Add I2c pinctrl data arm: dts: omap5-evm: Add I2c pinctrl data arm: dts: omap4-panda: Add I2c pinctrl data arm: dts: omap5-evm: Add mcspi data Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] ASoC: OMAP2+: Move McBSP, DMIC and McPDM to generic DMA DT binding
On Mon, Mar 11, 2013 at 08:50:22AM +0100, Sebastien Guiriec wrote: > Update OMAP2+ driver in order to use OMAP DMA DT binding for OMAP2+. > In case of DT boot snd_dmaengine_generic_pcm_open function is used. Acked-by: Mark Brown or I can apply to ASoC if people prefer, I don't think it makes much difference either way. signature.asc Description: Digital signature
Re: [Resend/PATCH 0/5] omap4/5: i2c/spi: device tree data
Hi Sourav, On 03/11/2013 02:44 PM, Sourav Poddar wrote: > Hi Tony/Benoit, > > These patches had been sent couple of times before, but there were no > comments on it. Sorry for that. I got a big flu in Jan and was in Linaro Connect last week. Patches look good, I just have to check that they apply nicely to the dts/for_3.9 I already prepared. I still have to rebase that branch on top of a recent master branch and then check your branch. > If there are no comments, Can these be picked ? > > Cc: Andrew Morton > > The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: > > Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) > > are available in the git repository at: > g...@gitorious.org:linux-connectivity/linux-connectivity.git > omap_i2c_spi_dts_data > > Felipe Balbi (1): > arm: dts: omap5: add SPI devices to OMAP5 DeviceTree file > > Sourav Poddar (4): > arm: dts: omap4-sdp: Add I2c pinctrl data > arm: dts: omap5-evm: Add I2c pinctrl data > arm: dts: omap4-panda: Add I2c pinctrl data > arm: dts: omap5-evm: Add mcspi data Thanks, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 1/2] ARM: dts: OMAP2+: Add SDMA Audio IPs bindings
On 03/11/2013 08:50 AM, Sebastien Guiriec wrote:
> Populate DMA client information for McBSP DMIC and McPDM periperhal on
> OMAP2+ devices.
Looks good to me:
Reviewed-by: Peter Ujfalusi
>
> Signed-off-by: Sebastien Guiriec
> ---
> arch/arm/boot/dts/omap2420.dtsi |6 ++
> arch/arm/boot/dts/omap2430.dtsi | 15 +++
> arch/arm/boot/dts/omap3.dtsi| 15 +++
> arch/arm/boot/dts/omap4.dtsi| 17 +
> arch/arm/boot/dts/omap5.dtsi| 14 ++
> 5 files changed, 67 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
> index af65609..45930f2 100644
> --- a/arch/arm/boot/dts/omap2420.dtsi
> +++ b/arch/arm/boot/dts/omap2420.dtsi
> @@ -37,6 +37,9 @@
><60>; /* RX interrupt */
> interrupt-names = "tx", "rx";
> ti,hwmods = "mcbsp1";
> + dmas = <&sdma 31>,
> +<&sdma 32>;
> + dma-names = "tx", "rx";
> };
>
> mcbsp2: mcbsp@48076000 {
> @@ -47,6 +50,9 @@
><63>; /* RX interrupt */
> interrupt-names = "tx", "rx";
> ti,hwmods = "mcbsp2";
> + dmas = <&sdma 33>,
> +<&sdma 34>;
> + dma-names = "tx", "rx";
> };
>
> timer1: timer@48028000 {
> diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
> index c392445..cfe7ed9 100644
> --- a/arch/arm/boot/dts/omap2430.dtsi
> +++ b/arch/arm/boot/dts/omap2430.dtsi
> @@ -40,6 +40,9 @@
> interrupt-names = "common", "tx", "rx", "rx_overflow";
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp1";
> + dmas = <&sdma 31>,
> +<&sdma 32>;
> + dma-names = "tx", "rx";
> };
>
> mcbsp2: mcbsp@48076000 {
> @@ -52,6 +55,9 @@
> interrupt-names = "common", "tx", "rx";
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp2";
> + dmas = <&sdma 33>,
> +<&sdma 34>;
> + dma-names = "tx", "rx";
> };
>
> mcbsp3: mcbsp@4808c000 {
> @@ -64,6 +70,9 @@
> interrupt-names = "common", "tx", "rx";
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp3";
> + dmas = <&sdma 17>,
> +<&sdma 18>;
> + dma-names = "tx", "rx";
> };
>
> mcbsp4: mcbsp@4808e000 {
> @@ -76,6 +85,9 @@
> interrupt-names = "common", "tx", "rx";
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp4";
> + dmas = <&sdma 19>,
> +<&sdma 20>;
> + dma-names = "tx", "rx";
> };
>
> mcbsp5: mcbsp@48096000 {
> @@ -88,6 +100,9 @@
> interrupt-names = "common", "tx", "rx";
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp5";
> + dmas = <&sdma 21>,
> +<&sdma 22>;
> + dma-names = "tx", "rx";
> };
>
> timer1: timer@49018000 {
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 4e7acb6..f901404 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -289,6 +289,9 @@
> interrupt-names = "common", "tx", "rx";
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp1";
> + dmas = <&sdma 31>,
> +<&sdma 32>;
> + dma-names = "tx", "rx";
> };
>
> mcbsp2: mcbsp@49022000 {
> @@ -303,6 +306,9 @@
> interrupt-names = "common", "tx", "rx", "sidetone";
> ti,buffer-size = <1280>;
> ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
> + dmas = <&sdma 33>,
> +<&sdma 34>;
> + dma-names = "tx", "rx";
> };
>
> mcbsp3: mcbsp@49024000 {
> @@ -317,6 +323,9 @@
> interrupt-names = "common", "tx", "rx", "sidetone";
> ti,buffer-size = <128>;
> ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
> + dmas = <&sdma 17>,
> +<&sdma 18>;
> + dma-names = "tx", "rx";
> };
>
> mcbsp4: mcbsp@49026000 {
> @@ -329,6 +338,9 @@
>
Re: [PATCH V2 2/2] ASoC: OMAP2+: Move McBSP, DMIC and McPDM to generic DMA DT binding
On 03/11/2013 08:50 AM, Sebastien Guiriec wrote:
> Update OMAP2+ driver in order to use OMAP DMA DT binding for OMAP2+.
> In case of DT boot snd_dmaengine_generic_pcm_open function is used.
Acked-by: Peter Ujfalusi
>
> Signed-off-by: Sebastien Guiriec
> ---
> sound/soc/omap/mcbsp.c | 26 --
> sound/soc/omap/omap-dmic.c | 15 +--
> sound/soc/omap/omap-mcpdm.c | 22 ++
> sound/soc/omap/omap-pcm.c | 12 ++--
> sound/soc/omap/omap-pcm.h |1 +
> 5 files changed, 50 insertions(+), 26 deletions(-)
>
> diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
> index 285c836..16936493 100644
> --- a/sound/soc/omap/mcbsp.c
> +++ b/sound/soc/omap/mcbsp.c
> @@ -1012,24 +1012,30 @@ int omap_mcbsp_init(struct platform_device *pdev)
> }
> }
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
> - if (!res) {
> - dev_err(&pdev->dev, "invalid rx DMA channel\n");
> - return -ENODEV;
> + if (!pdev->dev.of_node) {
> + res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
> + if (!res) {
> + dev_err(&pdev->dev, "invalid rx DMA channel\n");
> + return -ENODEV;
> + }
> + mcbsp->dma_data[1].dma_req = res->start;
> }
> /* RX DMA request number, and port address configuration */
> mcbsp->dma_data[1].name = "Audio Capture";
> - mcbsp->dma_data[1].dma_req = res->start;
> + mcbsp->dma_data[1].dma_name = "rx";
> mcbsp->dma_data[1].port_addr = omap_mcbsp_dma_reg_params(mcbsp, 1);
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
> - if (!res) {
> - dev_err(&pdev->dev, "invalid tx DMA channel\n");
> - return -ENODEV;
> + if (!pdev->dev.of_node) {
> + res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
> + if (!res) {
> + dev_err(&pdev->dev, "invalid tx DMA channel\n");
> + return -ENODEV;
> + }
> + mcbsp->dma_data[0].dma_req = res->start;
> }
> /* TX DMA request number, and port address configuration */
> mcbsp->dma_data[0].name = "Audio Playback";
> - mcbsp->dma_data[0].dma_req = res->start;
> + mcbsp->dma_data[0].dma_name = "tx";
> mcbsp->dma_data[0].port_addr = omap_mcbsp_dma_reg_params(mcbsp, 0);
>
> mcbsp->fclk = clk_get(&pdev->dev, "fck");
> diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
> index ba49ccd..8695b32 100644
> --- a/sound/soc/omap/omap-dmic.c
> +++ b/sound/soc/omap/omap-dmic.c
> @@ -62,6 +62,7 @@ struct omap_dmic {
> */
> static struct omap_pcm_dma_data omap_dmic_dai_dma_params = {
> .name = "DMIC capture",
> + .dma_name = "up_link",
> };
>
> static inline void omap_dmic_write(struct omap_dmic *dmic, u16 reg, u32 val)
> @@ -478,13 +479,15 @@ static int asoc_dmic_probe(struct platform_device *pdev)
> }
> omap_dmic_dai_dma_params.port_addr = res->start + OMAP_DMIC_DATA_REG;
>
> - res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
> - if (!res) {
> - dev_err(dmic->dev, "invalid dma resource\n");
> - ret = -ENODEV;
> - goto err_put_clk;
> + if (!pdev->dev.of_node) {
> + res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
> + if (!res) {
> + dev_err(dmic->dev, "invalid dma resource\n");
> + ret = -ENODEV;
> + goto err_put_clk;
> + }
> + omap_dmic_dai_dma_params.dma_req = res->start;
> }
> - omap_dmic_dai_dma_params.dma_req = res->start;
>
> res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mpu");
> if (!res) {
> diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
> index 5ca11bd..f41bac8 100644
> --- a/sound/soc/omap/omap-mcpdm.c
> +++ b/sound/soc/omap/omap-mcpdm.c
> @@ -71,9 +71,11 @@ struct omap_mcpdm {
> static struct omap_pcm_dma_data omap_mcpdm_dai_dma_params[] = {
> {
> .name = "Audio playback",
> + .dma_name = "dn_link",
> },
> {
> .name = "Audio capture",
> + .dma_name = "up_link",
> },
> };
>
> @@ -449,17 +451,21 @@ static int asoc_mcpdm_probe(struct platform_device
> *pdev)
> omap_mcpdm_dai_dma_params[0].port_addr = res->start + MCPDM_REG_DN_DATA;
> omap_mcpdm_dai_dma_params[1].port_addr = res->start + MCPDM_REG_UP_DATA;
>
> - res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "dn_link");
> - if (!res)
> - return -ENODEV;
> + if (!pdev->dev.of_node) {
> + res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
> +"dn_link");
> + if (!res)
> +
[Resend/PATCH 5/5] arm: dts: omap5-evm: Add mcspi data
Add mcspi node and pinmux data for omap5 mcspi controller.
Tested on omap5430 evm with 3.9-rc2 custom kernel.
Cc: Andrew Morton
Signed-off-by: Sourav Poddar
---
arch/arm/boot/dts/omap5-evm.dts | 46 +++
1 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index a4784be..d0ea53c 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -115,6 +115,33 @@
0x186 0x100 /* i2c5_sda INPUTENABLE | MODE0 */
>;
};
+
+ mcspi2_pins: pinmux_mcspi2_pins {
+ pinctrl-single,pins = <
+ 0xbc 0x100 /* MCSPI2_CLK INPUTENABLE | MODE0 */
+ 0xbe 0x100 /* MCSPI2_SIMO INPUTENABLE | MODE0 */
+ 0xc0 0x118 /* MCSPI2_SOMI PULLUP | INPUTENABLE |
MODE0 */
+ 0xc2 0x0/* MCSPI2_CS MODE0 */
+ >;
+ };
+
+ mcspi3_pins: pinmux_mcspi3_pins {
+ pinctrl-single,pins = <
+ 0x78 0x101 /* MCSPI2_SOMI INPUTENABLE | MODE1 */
+ 0x7a 0x101 /* MCSPI2_CS INPUTENABLE | MODE1 */
+ 0x7c 0x101 /* MCSPI2_SIMO INPUTENABLE | MODE1 */
+ 0x7e 0x101 /* MCSPI2_CLK INPUTENABLE | MODE1 */
+ >;
+ };
+
+ mcspi4_pins: pinmux_mcspi4_pins {
+ pinctrl-single,pins = <
+ 0x164 0x101 /* MCSPI2_CLK INPUTENABLE | MODE1 */
+ 0x168 0x101 /* MCSPI2_SIMO INPUTENABLE | MODE1 */
+ 0x16a 0x101 /* MCSPI2_SOMI INPUTENABLE | MODE1 */
+ 0x16c 0x101 /* MCSPI2_CS INPUTENABLE | MODE1 */
+ >;
+ };
};
&mmc1 {
@@ -213,3 +240,22 @@
cs1-used;
device-handle = <&samsung_K3PE0E000B>;
};
+
+&mcspi1 {
+
+};
+
+&mcspi2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcspi2_pins>;
+};
+
+&mcspi3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcspi3_pins>;
+};
+
+&mcspi4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&mcspi4_pins>;
+};
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resend/PATCH 4/5] arm: dts: omap5: add SPI devices to OMAP5 DeviceTree file
From: Felipe Balbi
Add all 4 mcspi instances to omap5.dtsi file.
Cc: Andrew Morton
Signed-off-by: Felipe Balbi
Signed-off-by: Sourav Poddar
---
arch/arm/boot/dts/omap5.dtsi | 40
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 790bb2a..9e182a9 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -241,6 +241,46 @@
ti,hwmods = "i2c5";
};
+ mcspi1: spi@48098000 {
+ compatible = "ti,omap4-mcspi";
+ reg = <0x48098000 0x200>;
+ interrupts = <0 65 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "mcspi1";
+ ti,spi-num-cs = <4>;
+ };
+
+ mcspi2: spi@4809a000 {
+ compatible = "ti,omap4-mcspi";
+ reg = <0x4809a000 0x200>;
+ interrupts = <0 66 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "mcspi2";
+ ti,spi-num-cs = <2>;
+ };
+
+ mcspi3: spi@480b8000 {
+ compatible = "ti,omap4-mcspi";
+ reg = <0x480b8000 0x200>;
+ interrupts = <0 91 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "mcspi3";
+ ti,spi-num-cs = <2>;
+ };
+
+ mcspi4: spi@480ba000 {
+ compatible = "ti,omap4-mcspi";
+ reg = <0x480ba000 0x200>;
+ interrupts = <0 48 0x4>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ti,hwmods = "mcspi4";
+ ti,spi-num-cs = <1>;
+ };
+
uart1: serial@4806a000 {
compatible = "ti,omap4-uart";
reg = <0x4806a000 0x100>;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resend/PATCH 2/5] arm: dts: omap5-evm: Add I2c pinctrl data
Booting 3.9-rc2 on omap 5430evm results in the following error
omap_i2c 4807.i2c: did not get pins for i2c error: -19
[1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz
[1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[1.043762] omap_i2c 4806.i2c: did not get pins for i2c error: -19
[1.050964] omap_i2c 4806.i2c: bus 2 rev0.12 at 100 kHz
[1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
[1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
This happens because omap5 dts file is not adapted to use i2c through pinctrl
framework. Populating i2c pinctrl data to get rid of the error.
Tested on omap5430 evm with 3.9-rc2 kernel.
Cc: Andrew Morton
Signed-off-by: Sourav Poddar
---
arch/arm/boot/dts/omap5-evm.dts | 62 +++
1 files changed, 62 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts b/arch/arm/boot/dts/omap5-evm.dts
index 8722c15..a4784be 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -80,6 +80,41 @@
0x15a 0x100 /* abemcbsp2_clkx.abemcbsp2_clkx INPUT
| MODE0 */
>;
};
+
+i2c1_pins: pinmux_i2c1_pins {
+pinctrl-single,pins = <
+0x1b2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
MODE0 */
+0x1b4 0x118/* i2c1_sda PULLUP | INPUTENABLE |
MODE0 */
+>;
+};
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0x178 0x100/* i2c2_scl INPUTENABLE | MODE0 */
+ 0x17a 0x100/* i2c2_sda INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ 0x13a 0x100/* i2c3_scl INPUTENABLE | MODE0 */
+ 0x13c 0x100 /* i2c3_sda INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c4_pins: pinmux_i2c4_pins {
+ pinctrl-single,pins = <
+ 0xb8 0x100/* i2c4_scl INPUTENABLE | MODE0 */
+ 0xba 0x100 /* i2c4_sda INPUTENABLE | MODE0 */
+ >;
+ };
+
+ i2c5_pins: pinmux_i2c5_pins {
+ pinctrl-single,pins = <
+ 0x184 0x100/* i2c5_scl INPUTENABLE | MODE0 */
+ 0x186 0x100 /* i2c5_sda INPUTENABLE | MODE0 */
+ >;
+ };
};
&mmc1 {
@@ -106,7 +141,17 @@
status = "disabled";
};
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+
+ clock-frequency = <40>;
+};
+
&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
clock-frequency = <40>;
/* Pressure Sensor */
@@ -116,7 +161,17 @@
};
};
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
+
+ clock-frequency = <40>;
+};
+
&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4_pins>;
+
clock-frequency = <40>;
/* Temperature Sensor */
@@ -126,6 +181,13 @@
};
};
+&i2c5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c5_pins>;
+
+ clock-frequency = <40>;
+};
+
&keypad {
keypad,num-rows = <8>;
keypad,num-columns = <8>;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resend/PATCH 3/5] arm: dts: omap4-panda: Add I2c pinctrl data
Booting 3.9-rc2 on omap4 panda results in the following error
[0.27] omap_i2c 4807.i2c: did not get pins for i2c error: -19
[0.445770] omap_i2c 4807.i2c: bus 0 rev0.11 at 400 kHz
[0.473937] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[0.474670] omap_i2c 48072000.i2c: bus 1 rev0.11 at 400 kHz
[0.474822] omap_i2c 4806.i2c: did not get pins for i2c error: -19
[0.476379] omap_i2c 4806.i2c: bus 2 rev0.11 at 100 kHz
[0.477294] omap_i2c 4835.i2c: did not get pins for i2c error: -19
[0.477996] omap_i2c 4835.i2c: bus 3 rev0.11 at 400 kHz
[0.483398] Switching to clocksource 32k_counter
This happens because omap4 panda dts file is not adapted to use i2c through
pinctrl framework. Populating i2c pinctrl data to get rid of the error.
Tested on omap4460 panda with 3.9-rc2 kernel.
Cc: Andrew Morton
Signed-off-by: Sourav Poddar
Reported-by: Luciano Coelho
---
arch/arm/boot/dts/omap4-panda.dts | 40 +
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..f951e6b 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -110,9 +110,40 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
>;
};
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ 0xe2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xe4 0x118/* i2c1_sda PULLUP | INPUTENABLE |
MODE0 */
+ >;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+ 0xe6 0x118/* i2c2_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xe8 0x118/* i2c2_sda PULLUP | INPUTENABLE |
MODE0 */
+ >;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ 0xea 0x118/* i2c3_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xec 0x118 /* i2c3_sda PULLUP | INPUTENABLE | MODE0
*/
+ >;
+ };
+
+ i2c4_pins: pinmux_i2c4_pins {
+ pinctrl-single,pins = <
+ 0xee 0x118/* i2c4_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
+ >;
+ };
};
&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+
clock-frequency = <40>;
twl: twl@48 {
@@ -139,10 +170,16 @@
/include/ "twl6030.dtsi"
&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
clock-frequency = <40>;
};
&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
+
clock-frequency = <10>;
/*
@@ -156,6 +193,9 @@
};
&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4_pins>;
+
clock-frequency = <40>;
};
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resend/PATCH 1/5] arm: dts: omap4-sdp: Add I2c pinctrl data
Booting 3.9-rc2 on omap 4430sdp results in the following error
omap_i2c 4807.i2c: did not get pins for i2c error: -19
[1.024261] omap_i2c 4807.i2c: bus 0 rev0.12 at 100 kHz
[1.030181] omap_i2c 48072000.i2c: did not get pins for i2c error: -19
[1.037384] omap_i2c 48072000.i2c: bus 1 rev0.12 at 400 kHz
[1.043762] omap_i2c 4806.i2c: did not get pins for i2c error: -19
[1.050964] omap_i2c 4806.i2c: bus 2 rev0.12 at 100 kHz
[1.056823] omap_i2c 4807a000.i2c: did not get pins for i2c error: -19
[1.064025] omap_i2c 4807a000.i2c: bus 3 rev0.12 at 400 kHz
This happens because omap4 dts file is not adapted to use i2c through pinctrl
framework. Populating i2c pinctrl data to get rid of the error.
Tested on omap4430 sdp with 3.9-rc2 kernel.
Cc: Andrew Morton
Signed-off-by: Sourav Poddar
Reported-by: Santosh Shilimkar
---
arch/arm/boot/dts/omap4-sdp.dts | 40 +++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..40a04c9 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -212,9 +212,40 @@
0x58 0x10b /* hdmi_hpd.gpio_63 INPUT PULLDOWN |
MODE3 */
>;
};
+
+ i2c1_pins: pinmux_i2c1_pins {
+ pinctrl-single,pins = <
+ 0xe2 0x118/* i2c1_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xe4 0x118 /* i2c1_sda PULLUP | INPUTENABLE |
MODE0 */
+ >;
+ };
+
+ i2c2_pins: pinmux_i2c2_pins {
+ pinctrl-single,pins = <
+0xe6 0x118/* i2c2_scl PULLUP | INPUTENABLE |
MODE0 */
+0xe8 0x118/* i2c2_sda PULLUP | INPUTENABLE |
MODE0 */
+ >;
+ };
+
+ i2c3_pins: pinmux_i2c3_pins {
+ pinctrl-single,pins = <
+ 0xea 0x118/* i2c3_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xec 0x118 /* i2c3_sda PULLUP | INPUTENABLE | MODE0
*/
+ >;
+ };
+
+ i2c4_pins: pinmux_i2c4_pins {
+ pinctrl-single,pins = <
+ 0xee 0x118/* i2c4_scl PULLUP | INPUTENABLE |
MODE0 */
+ 0xf0 0x118 /* i2c4_sda PULLUP | INPUTENABLE | MODE0
*/
+ >;
+ };
};
&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins>;
+
clock-frequency = <40>;
twl: twl@48 {
@@ -253,10 +284,16 @@
/include/ "twl6030.dtsi"
&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2_pins>;
+
clock-frequency = <40>;
};
&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3_pins>;
+
clock-frequency = <40>;
/*
@@ -279,6 +316,9 @@
};
&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4_pins>;
+
clock-frequency = <40>;
/*
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Resend/PATCH 0/5] omap4/5: i2c/spi: device tree data
Hi Tony/Benoit, These patches had been sent couple of times before, but there were no comments on it. If there are no comments, Can these be picked ? Cc: Andrew Morton The following changes since commit f6161aa153581da4a3867a2d1a7caf4be19b6ec9: Linux 3.9-rc2 (2013-03-10 16:54:19 -0700) are available in the git repository at: g...@gitorious.org:linux-connectivity/linux-connectivity.git omap_i2c_spi_dts_data Felipe Balbi (1): arm: dts: omap5: add SPI devices to OMAP5 DeviceTree file Sourav Poddar (4): arm: dts: omap4-sdp: Add I2c pinctrl data arm: dts: omap5-evm: Add I2c pinctrl data arm: dts: omap4-panda: Add I2c pinctrl data arm: dts: omap5-evm: Add mcspi data arch/arm/boot/dts/omap4-panda.dts | 40 ++ arch/arm/boot/dts/omap4-sdp.dts | 40 ++ arch/arm/boot/dts/omap5-evm.dts | 108 + arch/arm/boot/dts/omap5.dtsi | 40 ++ 4 files changed, 228 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] omapdss: features: fixed supported outputs for OMAP4
On 2013-03-05 16:17, Archit Taneja wrote:
> The support outputs struct for overlay managers is incorrect for OMAP4. Make
> these changes:
>
> - DPI isn't supported via the LCD1 overlay manager, remove DPI as a supported
> output.
> - the TV manager can suppport DPI, but the omapdss driver doesn't support that
> yet, we require some muxing at the DSS level, and we also need to configure
> the hdmi pll in the DPI driver so that the TV manager has a pixel clock. We
> don't support that yet.
>
> Signed-off-by: Archit Taneja
> ---
> drivers/video/omap2/dss/dss_features.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dss_features.c
> b/drivers/video/omap2/dss/dss_features.c
> index d7d66ef..7f791ae 100644
> --- a/drivers/video/omap2/dss/dss_features.c
> +++ b/drivers/video/omap2/dss/dss_features.c
> @@ -202,12 +202,10 @@ static const enum omap_dss_output_id
> omap3630_dss_supported_outputs[] = {
>
> static const enum omap_dss_output_id omap4_dss_supported_outputs[] = {
> /* OMAP_DSS_CHANNEL_LCD */
> - OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
> - OMAP_DSS_OUTPUT_DSI1,
> + OMAP_DSS_OUTPUT_DBI | OMAP_DSS_OUTPUT_DSI1,
>
> /* OMAP_DSS_CHANNEL_DIGIT */
> - OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI |
> - OMAP_DSS_OUTPUT_DPI,
> + OMAP_DSS_OUTPUT_VENC | OMAP_DSS_OUTPUT_HDMI,
>
> /* OMAP_DSS_CHANNEL_LCD2 */
> OMAP_DSS_OUTPUT_DPI | OMAP_DSS_OUTPUT_DBI |
>
Thanks, I'll apply this to omapdss fixes branch.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 2/2] omapfb: fix broken build on Amstrad E3/Delta
On 2013-03-05 00:39, Tony Lindgren wrote: > Hi, > > * Aaro Koskinen [130304 13:08]: >> Fix the following build regression in 3.9-rc1 by including >> : >> >> drivers/video/omap/lcd_ams_delta.c: In function 'ams_delta_lcd_set_power': >> drivers/video/omap/lcd_ams_delta.c:48:4: error: implicit declaration of >> function 'omap_writeb' [-Werror=implicit-function-declaration] >> drivers/video/omap/lcd_ams_delta.c:49:6: error: 'OMAP_PWL_ENABLE' undeclared >> (first use in this function) >> drivers/video/omap/lcd_ams_delta.c:49:6: note: each undeclared identifier is >> reported only once for each function it appears in >> drivers/video/omap/lcd_ams_delta.c:50:19: error: 'OMAP_PWL_CLK_ENABLE' >> undeclared (first use in this function) >> drivers/video/omap/lcd_ams_delta.c: In function 'ams_delta_lcd_set_contrast': >> drivers/video/omap/lcd_ams_delta.c:66:22: error: 'OMAP_PWL_ENABLE' >> undeclared (first use in this function) > > I have this already queued up in omap-for-v3.9-rc1/fixes as 0adcbaf78 > (ARM: OMAP1: Fix build related to kgdb.h no longer including serial_8250.h) > and for lcd_osk.c as omap1_defconfig was broken. > > I don't anything for the first patch you posted, so I suggest > Tomi applies that one. Ok, I'll take the first patch. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
On Monday 11 March 2013 05:35 PM, Tomi Valkeinen wrote:
On 2013-03-11 07:35, Archit Taneja wrote:
Hi,
On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
The DISPC channel used for each output is currently passed in panel
platform data from the board files.
To simplify this, and to make the panel drivers less dependent on OMAP,
this patch changes omapdss to resolve the channel independently. The
channel is resolved based on the OMAP version and, in case of DSI, the
DSI module id.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dpi.c | 37 ++-
drivers/video/omap2/dss/dsi.c | 48
drivers/video/omap2/dss/rfbi.c |2 ++
drivers/video/omap2/dss/sdi.c |2 ++
4 files changed, 84 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c
b/drivers/video/omap2/dss/dpi.c
index e282456..3261644 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
platform_device *dsidev)
return 0;
}
+/*
+ * Return a hardcoded channel for the DPI output. This should work for
+ * current use cases, but this can be later expanded to either resolve
+ * the channel in some more dynamic manner, or get the channel as a user
+ * parameter.
+ */
+static enum omap_channel dpi_get_channel(void)
+{
+switch (omapdss_get_version()) {
+case OMAPDSS_VER_OMAP24xx:
+case OMAPDSS_VER_OMAP34xx_ES1:
+case OMAPDSS_VER_OMAP34xx_ES3:
+case OMAPDSS_VER_OMAP3630:
+case OMAPDSS_VER_AM35xx:
+return OMAP_DSS_CHANNEL_LCD;
+
+case OMAPDSS_VER_OMAP4430_ES1:
+case OMAPDSS_VER_OMAP4430_ES2:
+case OMAPDSS_VER_OMAP4:
+return OMAP_DSS_CHANNEL_LCD2;
+
+case OMAPDSS_VER_OMAP5:
+return OMAP_DSS_CHANNEL_LCD2;
+
+default:
+DSSWARN("unsupported DSS version\n");
+return OMAP_DSS_CHANNEL_LCD;
+}
+}
+
static int __init dpi_init_display(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev;
DSSDBG("init_display\n");
+dssdev->channel = dpi_get_channel();
In patch 14 of the series, we remove these dssdev->channel assignments.
I don't see the point of adding them in this patch in the first place.
The dssdev->channel assignments will not be modified in this series, so
we don't need to worry about a kernel crash or something after this patch.
I feel this patch should only add the dpi_get_channel and
dsi_get_channel funcs.
Here's the combined patch. I changed the recommended_channel to dispc_channel.
"recommended" was not that good name, as currently the channel cannot be changed
later, because, for example in DPI case, we store the DSI PLL which is based on
the channel.
The patch looks fine now.
Reviewed-by: Archit Taneja
Archit
Author: Tomi Valkeinen
Date: Wed Feb 13 11:23:54 2013 +0200
OMAPDSS: add output->dispc_channel
The DISPC channel used for each output is currently passed in panel
platform data from the board files.
To simplify this, and to make the panel drivers less dependent on OMAP,
this patch changes omapdss to resolve the channel independently. The
channel is resolved based on the OMAP version and, in case of DSI, the
DSI module id. This resolved channel is stored into a new field in
output, dispc_channel.
The few places where dssdev->channel was used are changed to use
output->recommended_channel. After this patch, dssdev->channel is
obsolete.
Signed-off-by: Tomi Valkeinen
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e282456..409e53b 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -396,6 +396,36 @@ static int __init dpi_verify_dsi_pll(struct
platform_device *dsidev)
return 0;
}
+/*
+ * Return a hardcoded channel for the DPI output. This should work for
+ * current use cases, but this can be later expanded to either resolve
+ * the channel in some more dynamic manner, or get the channel as a user
+ * parameter.
+ */
+static enum omap_channel dpi_get_channel(void)
+{
+ switch (omapdss_get_version()) {
+ case OMAPDSS_VER_OMAP24xx:
+ case OMAPDSS_VER_OMAP34xx_ES1:
+ case OMAPDSS_VER_OMAP34xx_ES3:
+ case OMAPDSS_VER_OMAP3630:
+ case OMAPDSS_VER_AM35xx:
+ return OMAP_DSS_CHANNEL_LCD;
+
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ return OMAP_DSS_CHANNEL_LCD2;
+
+ case OMAPDSS_VER_OMAP5:
+ return OMAP_DSS_CHANNEL_LCD3;
+
+ default:
+ DSSWARN("unsupported DSS version\n");
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+}
+
static int __init dpi_init_display(struct omap_dss_device *dssdev)
{
struct platform_device *dsidev;
@@ -416,12 +446,7 @@ static int __init dpi_init_displa
Re: [PATCH] ARM: OMAP: zoom: Use pwm stack for lcd and keyboard backlight
On 2013-03-11 13:57, Peter Ujfalusi wrote: > Use pwm_leds driver for the keyboard light and pwm-backlight for the lcd > backlight control (instead of implementing the PWM driver part in the board > file). > > Signed-off-by: Peter Ujfalusi > --- > arch/arm/mach-omap2/board-zoom-display.c | 56 > > arch/arm/mach-omap2/board-zoom-peripherals.c | 53 +- > 2 files changed, 52 insertions(+), 57 deletions(-) I can't test this, but looks fine to me. Good to get rid of the hacky backlight code in board-zoom-display.c. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
On 2013-03-11 07:35, Archit Taneja wrote:
> Hi,
>
> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>> The DISPC channel used for each output is currently passed in panel
>> platform data from the board files.
>>
>> To simplify this, and to make the panel drivers less dependent on OMAP,
>> this patch changes omapdss to resolve the channel independently. The
>> channel is resolved based on the OMAP version and, in case of DSI, the
>> DSI module id.
>>
>> Signed-off-by: Tomi Valkeinen
>> ---
>> drivers/video/omap2/dss/dpi.c | 37 ++-
>> drivers/video/omap2/dss/dsi.c | 48
>>
>> drivers/video/omap2/dss/rfbi.c |2 ++
>> drivers/video/omap2/dss/sdi.c |2 ++
>> 4 files changed, 84 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dpi.c
>> b/drivers/video/omap2/dss/dpi.c
>> index e282456..3261644 100644
>> --- a/drivers/video/omap2/dss/dpi.c
>> +++ b/drivers/video/omap2/dss/dpi.c
>> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
>> platform_device *dsidev)
>> return 0;
>> }
>>
>> +/*
>> + * Return a hardcoded channel for the DPI output. This should work for
>> + * current use cases, but this can be later expanded to either resolve
>> + * the channel in some more dynamic manner, or get the channel as a user
>> + * parameter.
>> + */
>> +static enum omap_channel dpi_get_channel(void)
>> +{
>> +switch (omapdss_get_version()) {
>> +case OMAPDSS_VER_OMAP24xx:
>> +case OMAPDSS_VER_OMAP34xx_ES1:
>> +case OMAPDSS_VER_OMAP34xx_ES3:
>> +case OMAPDSS_VER_OMAP3630:
>> +case OMAPDSS_VER_AM35xx:
>> +return OMAP_DSS_CHANNEL_LCD;
>> +
>> +case OMAPDSS_VER_OMAP4430_ES1:
>> +case OMAPDSS_VER_OMAP4430_ES2:
>> +case OMAPDSS_VER_OMAP4:
>> +return OMAP_DSS_CHANNEL_LCD2;
>> +
>> +case OMAPDSS_VER_OMAP5:
>> +return OMAP_DSS_CHANNEL_LCD2;
>> +
>> +default:
>> +DSSWARN("unsupported DSS version\n");
>> +return OMAP_DSS_CHANNEL_LCD;
>> +}
>> +}
>> +
>> static int __init dpi_init_display(struct omap_dss_device *dssdev)
>> {
>> struct platform_device *dsidev;
>>
>> DSSDBG("init_display\n");
>>
>> +dssdev->channel = dpi_get_channel();
>
> In patch 14 of the series, we remove these dssdev->channel assignments.
> I don't see the point of adding them in this patch in the first place.
> The dssdev->channel assignments will not be modified in this series, so
> we don't need to worry about a kernel crash or something after this patch.
>
> I feel this patch should only add the dpi_get_channel and
> dsi_get_channel funcs.
Here's the combined patch. I changed the recommended_channel to dispc_channel.
"recommended" was not that good name, as currently the channel cannot be changed
later, because, for example in DPI case, we store the DSI PLL which is based on
the channel.
Author: Tomi Valkeinen
Date: Wed Feb 13 11:23:54 2013 +0200
OMAPDSS: add output->dispc_channel
The DISPC channel used for each output is currently passed in panel
platform data from the board files.
To simplify this, and to make the panel drivers less dependent on OMAP,
this patch changes omapdss to resolve the channel independently. The
channel is resolved based on the OMAP version and, in case of DSI, the
DSI module id. This resolved channel is stored into a new field in
output, dispc_channel.
The few places where dssdev->channel was used are changed to use
output->recommended_channel. After this patch, dssdev->channel is
obsolete.
Signed-off-by: Tomi Valkeinen
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index e282456..409e53b 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -396,6 +396,36 @@ static int __init dpi_verify_dsi_pll(struct
platform_device *dsidev)
return 0;
}
+/*
+ * Return a hardcoded channel for the DPI output. This should work for
+ * current use cases, but this can be later expanded to either resolve
+ * the channel in some more dynamic manner, or get the channel as a user
+ * parameter.
+ */
+static enum omap_channel dpi_get_channel(void)
+{
+ switch (omapdss_get_version()) {
+ case OMAPDSS_VER_OMAP24xx:
+ case OMAPDSS_VER_OMAP34xx_ES1:
+ case OMAPDSS_VER_OMAP34xx_ES3:
+ case OMAPDSS_VER_OMAP3630:
+ case OMAPDSS_VER_AM35xx:
+ return OMAP_DSS_CHANNEL_LCD;
+
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ return OMAP_DSS_CHANNEL_LCD2;
+
+ case OMAPDSS_VER_OMAP5:
+ return OMAP_DSS_CHANNEL_LCD3;
+
+ default:
+ DSSWARN("unsupported DSS version\n");
+ return OMAP_DSS_CHANNEL_LCD;
+ }
+}
+
static int __init dpi_init_display(struct omap_dss_device *dssdev)
{
struct platform_
Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
On 2013-03-11 07:53, Archit Taneja wrote:
> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>> The DISPC channel used for each output is currently passed in panel
>> platform data from the board files.
>>
>> To simplify this, and to make the panel drivers less dependent on OMAP,
>> this patch changes omapdss to resolve the channel independently. The
>> channel is resolved based on the OMAP version and, in case of DSI, the
>> DSI module id.
>>
>> Signed-off-by: Tomi Valkeinen
>> ---
>> drivers/video/omap2/dss/dpi.c | 37 ++-
>> drivers/video/omap2/dss/dsi.c | 48
>>
>> drivers/video/omap2/dss/rfbi.c |2 ++
>> drivers/video/omap2/dss/sdi.c |2 ++
>> 4 files changed, 84 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dpi.c
>> b/drivers/video/omap2/dss/dpi.c
>> index e282456..3261644 100644
>> --- a/drivers/video/omap2/dss/dpi.c
>> +++ b/drivers/video/omap2/dss/dpi.c
>> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
>> platform_device *dsidev)
>> return 0;
>> }
>>
>> +/*
>> + * Return a hardcoded channel for the DPI output. This should work for
>> + * current use cases, but this can be later expanded to either resolve
>> + * the channel in some more dynamic manner, or get the channel as a user
>> + * parameter.
>> + */
>> +static enum omap_channel dpi_get_channel(void)
>> +{
>> +switch (omapdss_get_version()) {
>> +case OMAPDSS_VER_OMAP24xx:
>> +case OMAPDSS_VER_OMAP34xx_ES1:
>> +case OMAPDSS_VER_OMAP34xx_ES3:
>> +case OMAPDSS_VER_OMAP3630:
>> +case OMAPDSS_VER_AM35xx:
>> +return OMAP_DSS_CHANNEL_LCD;
>> +
>> +case OMAPDSS_VER_OMAP4430_ES1:
>> +case OMAPDSS_VER_OMAP4430_ES2:
>> +case OMAPDSS_VER_OMAP4:
>> +return OMAP_DSS_CHANNEL_LCD2;
>> +
>> +case OMAPDSS_VER_OMAP5:
>> +return OMAP_DSS_CHANNEL_LCD2;
>> +
>> +default:
>> +DSSWARN("unsupported DSS version\n");
>> +return OMAP_DSS_CHANNEL_LCD;
>> +}
>> +}
>
> I had another comment for this patch. On OMAP5, it makes sense for us to
> not use LCD2 as the recommended channel. LCD2_CLK's only source is
> DSS_CLK from PRCM. So it's not a very flexible channel to use. We could
> use LCD3 (at the cost of not using DSI2).
>
> We also need to fix dpi_get_dsidev() for OMAP5. Currently, it assumes
> that LCD2_CLK can be sourced from DSI2 PLL, we need to ensure DPI has a
> dsidev only if it's LCD1 or LCD3.
I fixed it this way:
Author: Tomi Valkeinen
Date: Mon Mar 11 13:57:38 2013 +0200
OMAPDSS: DPI: fix dpi_get_dsidev() for omap5
On OMAP5 the DISPC channels and DSI PLLs are not connected the same way.
LCD2 on OMAP5 cannot use any DSI PLL as a source clock, but LCD3 can use
DSI2's PLL.
This patch fixes dpi_get_dsidev() by adding separate case for OMAP5 to
handle the difference.
Signed-off-by: Tomi Valkeinen
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 409e53b..433eff7 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -63,15 +63,29 @@ static struct platform_device *dpi_get_dsidev(enum
omap_channel channel)
case OMAPDSS_VER_OMAP3630:
case OMAPDSS_VER_AM35xx:
return NULL;
- default:
- break;
- }
- switch (channel) {
- case OMAP_DSS_CHANNEL_LCD:
- return dsi_get_dsidev_from_id(0);
- case OMAP_DSS_CHANNEL_LCD2:
- return dsi_get_dsidev_from_id(1);
+ case OMAPDSS_VER_OMAP4430_ES1:
+ case OMAPDSS_VER_OMAP4430_ES2:
+ case OMAPDSS_VER_OMAP4:
+ switch (channel) {
+ case OMAP_DSS_CHANNEL_LCD:
+ return dsi_get_dsidev_from_id(0);
+ case OMAP_DSS_CHANNEL_LCD2:
+ return dsi_get_dsidev_from_id(1);
+ default:
+ return NULL;
+ }
+
+ case OMAPDSS_VER_OMAP5:
+ switch (channel) {
+ case OMAP_DSS_CHANNEL_LCD:
+ return dsi_get_dsidev_from_id(0);
+ case OMAP_DSS_CHANNEL_LCD3:
+ return dsi_get_dsidev_from_id(1);
+ default:
+ return NULL;
+ }
+
default:
return NULL;
}
signature.asc
Description: OpenPGP digital signature
[PATCH] ARM: OMAP: zoom: Use pwm stack for lcd and keyboard backlight
Use pwm_leds driver for the keyboard light and pwm-backlight for the lcd
backlight control (instead of implementing the PWM driver part in the board
file).
Signed-off-by: Peter Ujfalusi
---
arch/arm/mach-omap2/board-zoom-display.c | 56
arch/arm/mach-omap2/board-zoom-peripherals.c | 53 +-
2 files changed, 52 insertions(+), 57 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-display.c
b/arch/arm/mach-omap2/board-zoom-display.c
index 8cef477..9a7174f 100644
--- a/arch/arm/mach-omap2/board-zoom-display.c
+++ b/arch/arm/mach-omap2/board-zoom-display.c
@@ -12,7 +12,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -49,59 +48,6 @@ static void zoom_panel_disable_lcd(struct omap_dss_device
*dssdev)
{
}
-/* Register offsets in TWL4030_MODULE_INTBR */
-#define TWL_INTBR_PMBR10xD
-#define TWL_INTBR_GPBR10xC
-
-/* Register offsets in TWL_MODULE_PWM */
-#define TWL_LED_PWMON 0x3
-#define TWL_LED_PWMOFF 0x4
-
-static int zoom_set_bl_intensity(struct omap_dss_device *dssdev, int level)
-{
-#ifdef CONFIG_TWL4030_CORE
- unsigned char c;
- u8 mux_pwm, enb_pwm;
-
- if (level > 100)
- return -1;
-
- twl_i2c_read_u8(TWL4030_MODULE_INTBR, &mux_pwm, TWL_INTBR_PMBR1);
- twl_i2c_read_u8(TWL4030_MODULE_INTBR, &enb_pwm, TWL_INTBR_GPBR1);
-
- if (level == 0) {
- /* disable pwm1 output and clock */
- enb_pwm = enb_pwm & 0xF5;
- /* change pwm1 pin to gpio pin */
- mux_pwm = mux_pwm & 0xCF;
- twl_i2c_write_u8(TWL4030_MODULE_INTBR,
- enb_pwm, TWL_INTBR_GPBR1);
- twl_i2c_write_u8(TWL4030_MODULE_INTBR,
- mux_pwm, TWL_INTBR_PMBR1);
- return 0;
- }
-
- if (!((enb_pwm & 0xA) && (mux_pwm & 0x30))) {
- /* change gpio pin to pwm1 pin */
- mux_pwm = mux_pwm | 0x30;
- /* enable pwm1 output and clock*/
- enb_pwm = enb_pwm | 0x0A;
- twl_i2c_write_u8(TWL4030_MODULE_INTBR,
- mux_pwm, TWL_INTBR_PMBR1);
- twl_i2c_write_u8(TWL4030_MODULE_INTBR,
- enb_pwm, TWL_INTBR_GPBR1);
- }
-
- c = ((50 * (100 - level)) / 100) + 1;
- twl_i2c_write_u8(TWL_MODULE_PWM, 0x7F, TWL_LED_PWMOFF);
- twl_i2c_write_u8(TWL_MODULE_PWM, c, TWL_LED_PWMON);
-#else
- pr_warn("Backlight not enabled\n");
-#endif
-
- return 0;
-}
-
static struct omap_dss_device zoom_lcd_device = {
.name = "lcd",
.driver_name= "NEC_8048_panel",
@@ -109,8 +55,6 @@ static struct omap_dss_device zoom_lcd_device = {
.phy.dpi.data_lines = 24,
.platform_enable= zoom_panel_enable_lcd,
.platform_disable = zoom_panel_disable_lcd,
- .max_backlight_level= 100,
- .set_backlight = zoom_set_bl_intensity,
};
static struct omap_dss_device *zoom_dss_devices[] = {
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index cdc0c10..a90375d 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -22,6 +22,9 @@
#include
#include
#include
+#include
+#include
+#include
#include
#include
@@ -193,6 +196,53 @@ static struct platform_device omap_vwlan_device = {
},
};
+static struct pwm_lookup zoom_pwm_lookup[] = {
+ PWM_LOOKUP("twl-pwm", 0, "leds_pwm", "zoom::keypad"),
+ PWM_LOOKUP("twl-pwm", 1, "pwm-backlight", "backlight"),
+};
+
+static struct led_pwm zoom_pwm_leds[] = {
+ {
+ .name = "zoom::keypad",
+ .max_brightness = 127,
+ .pwm_period_ns = 7812500,
+ },
+};
+
+static struct led_pwm_platform_data zoom_pwm_data = {
+ .num_leds = ARRAY_SIZE(zoom_pwm_leds),
+ .leds = zoom_pwm_leds,
+};
+
+static struct platform_device zoom_leds_pwm = {
+ .name = "leds_pwm",
+ .id = -1,
+ .dev= {
+ .platform_data = &zoom_pwm_data,
+ },
+};
+
+static struct platform_pwm_backlight_data zoom_backlight_data = {
+ .pwm_id = 1,
+ .max_brightness = 127,
+ .dft_brightness = 127,
+ .pwm_period_ns = 7812500,
+};
+
+static struct platform_device zoom_backlight_pwm = {
+ .name = "pwm-backlight",
+ .id = -1,
+ .dev= {
+ .platform_data = &zoom_backlight_data,
+ },
+};
+
+static struct platform_device *zoom_devices[] __initdata = {
+ &omap_vwlan_device,
+ &zoom_leds_pwm,
+ &zoom_backlight_pwm,
+};
+
static struct wl12xx_platform_data omap_zoom_wlan_data __initdata = {
.board_ref_clock = WL12XX_REFCLOCK_26, /* 26 MHz
Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
On 2013-03-11 07:53, Archit Taneja wrote:
> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>> The DISPC channel used for each output is currently passed in panel
>> platform data from the board files.
>>
>> To simplify this, and to make the panel drivers less dependent on OMAP,
>> this patch changes omapdss to resolve the channel independently. The
>> channel is resolved based on the OMAP version and, in case of DSI, the
>> DSI module id.
>>
>> Signed-off-by: Tomi Valkeinen
>> ---
>> drivers/video/omap2/dss/dpi.c | 37 ++-
>> drivers/video/omap2/dss/dsi.c | 48
>>
>> drivers/video/omap2/dss/rfbi.c |2 ++
>> drivers/video/omap2/dss/sdi.c |2 ++
>> 4 files changed, 84 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dpi.c
>> b/drivers/video/omap2/dss/dpi.c
>> index e282456..3261644 100644
>> --- a/drivers/video/omap2/dss/dpi.c
>> +++ b/drivers/video/omap2/dss/dpi.c
>> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
>> platform_device *dsidev)
>> return 0;
>> }
>>
>> +/*
>> + * Return a hardcoded channel for the DPI output. This should work for
>> + * current use cases, but this can be later expanded to either resolve
>> + * the channel in some more dynamic manner, or get the channel as a user
>> + * parameter.
>> + */
>> +static enum omap_channel dpi_get_channel(void)
>> +{
>> +switch (omapdss_get_version()) {
>> +case OMAPDSS_VER_OMAP24xx:
>> +case OMAPDSS_VER_OMAP34xx_ES1:
>> +case OMAPDSS_VER_OMAP34xx_ES3:
>> +case OMAPDSS_VER_OMAP3630:
>> +case OMAPDSS_VER_AM35xx:
>> +return OMAP_DSS_CHANNEL_LCD;
>> +
>> +case OMAPDSS_VER_OMAP4430_ES1:
>> +case OMAPDSS_VER_OMAP4430_ES2:
>> +case OMAPDSS_VER_OMAP4:
>> +return OMAP_DSS_CHANNEL_LCD2;
>> +
>> +case OMAPDSS_VER_OMAP5:
>> +return OMAP_DSS_CHANNEL_LCD2;
>> +
>> +default:
>> +DSSWARN("unsupported DSS version\n");
>> +return OMAP_DSS_CHANNEL_LCD;
>> +}
>> +}
>
> I had another comment for this patch. On OMAP5, it makes sense for us to
> not use LCD2 as the recommended channel. LCD2_CLK's only source is
> DSS_CLK from PRCM. So it's not a very flexible channel to use. We could
> use LCD3 (at the cost of not using DSI2).
Ok. Yes, this looks to be the case. I'll use LCD3 for DPI for now. In
the worst case we may need to pass some channel setup parameters via
omapdss DT data or platform data, but I'd really much like the driver to
be able to resolve the dispc channels by itself...
> We also need to fix dpi_get_dsidev() for OMAP5. Currently, it assumes
> that LCD2_CLK can be sourced from DSI2 PLL, we need to ensure DPI has a
> dsidev only if it's LCD1 or LCD3.
Right. I'll add if (OMAP5) there, and return DSI2 PLL for LCD3, and NULL
for LCD2.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 7/8] memory: emif: errata i743: Prohibit usage of Power-Down mode
Hi,
On Monday 11 March 2013 11:20 AM, Santosh Shilimkar wrote:
On Monday 11 March 2013 10:36 AM, Lokesh Vutla wrote:
From: Grygorii Strashko
ERRATA DESCRIPTION :
The EMIF supports power-down state for low power. The EMIF
automatically puts the SDRAM into power-down after the memory is
not accessed for a defined number of cycles and the
EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set to 0x4.
As the EMIF supports automatic output impedance calibration, a ZQ
calibration long command is issued every time it exits active
power-down and precharge power-down modes. The EMIF waits and
blocks any other command during this calibration.
The EMIF does not allow selective disabling of ZQ calibration upon
exit of power-down mode. Due to very short periods of power-down
cycles, ZQ calibration overhead creates bandwidth issues and
increases overall system power consumption. On the other hand,
issuing ZQ calibration long commands when exiting self-refresh is
still required.
WORKAROUND :
Because there is no power consumption benefit of the power-down due
to the calibration and there is a performance risk, the guideline
is to not allow power-down state and, therefore, to not have set
the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field to 0x4.
Signed-off-by: Grygorii Strashko
Signed-off-by: Vitaly Chernooky
Signed-off-by: Oleksandr Dmytryshyn
Signed-off-by: Lokesh Vutla
---
Nice changelog.
drivers/memory/emif.c | 35 +++
1 file changed, 35 insertions(+)
diff --git a/drivers/memory/emif.c b/drivers/memory/emif.c
index f75806a..119503a 100644
--- a/drivers/memory/emif.c
+++ b/drivers/memory/emif.c
@@ -257,6 +257,41 @@ static void set_lpmode(struct emif_data *emif, u8 lpmode)
u32 temp;
void __iomem *base = emif->base;
+ /*
+* Workaround for errata i743 - LPDDR2 Power-Down State is Not
+* Efficient
+*
+* i743 DESCRIPTION:
+* The EMIF supports power-down state for low power. The EMIF
+* automatically puts the SDRAM into power-down after the memory is
+* not accessed for a defined number of cycles and the
+* EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field is set to 0x4.
+* As the EMIF supports automatic output impedance calibration, a ZQ
+* calibration long command is issued every time it exits active
+* power-down and precharge power-down modes. The EMIF waits and
+* blocks any other command during this calibration.
+* The EMIF does not allow selective disabling of ZQ calibration upon
+* exit of power-down mode. Due to very short periods of power-down
+* cycles, ZQ calibration overhead creates bandwidth issues and
+* increases overall system power consumption. On the other hand,
+* issuing ZQ calibration long commands when exiting self-refresh is
+* still required.
+*
+* WORKAROUND
+* Because there is no power consumption benefit of the power-down due
+* to the calibration and there is a performance risk, the guideline
+* is to not allow power-down state and, therefore, to not have set
+* the EMIF_PWR_MGMT_CTRL[10:8] REG_LP_MODE bit field to 0x4.
+*/
+ if ((emif->plat_data->ip_rev == EMIF_4D) &&
+ (EMIF_LP_MODE_PWR_DN == lpmode)) {
Ok. So the errata is limited to only 'EMIF_4D' version and not applicable
for next EMIF version used in OMAP5 devices, right ? If yes, would be good
to just mention that in already good changelog.
Yes, it is not applicable for EMIF_4D5 used in OMAP5 ES2.0 Soc's.
Ill update this in change log.
Thanks
Lokesh
+ WARN_ONCE(1,
+ "REG_LP_MODE = LP_MODE_PWR_DN(4) is prohibited by"
+ "erratum i743 switch to LP_MODE_SELF_REFRESH(2)\n");
+ /* rallback LP_MODE to Self-refresh mode */
s/rallback/rollback ?
With above updates,
Acked-by: Santosh Shilimkar
--
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] ARM: OMAP4: PM: Avoid expensive cpu_suspend() path for all CPU power states except off
Kevin, On Wednesday 13 February 2013 02:25 PM, Santosh Shilimkar wrote: > Current CPU PM code code make use of common cpu_suspend() path for all the > CPU power states which is not optimal. In fact cpu_suspend() path is needed > only when we put CPU power domain to off state where the CPU context is lost. > > Update the code accordingly so that the expensive cpu_suspend() path > can be avoided for the shallow CPU power states like CPU PD INA/CSWR. > > The patch has been tested on OMAP4430 and OMAP5430(with few out of tree > patches) > devices for suspend and CPUidle. > > Cc: Kevin Hilman > > Reported-by: Richard Woodruff > Signed-off-by: Santosh Shilimkar > --- > Update changelog to include testing details as suggested > by Kevin Hilman. > Ping. It can get into rc's but since it is not strict regression, and if it has to wait for 3.10 then I can add this one along with rest of the PM patches posted towards 3.10 Either way, let me know. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/20] OMAPDSS: Resolve channels for outputs
On 2013-03-11 07:35, Archit Taneja wrote:
> Hi,
>
> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>> The DISPC channel used for each output is currently passed in panel
>> platform data from the board files.
>>
>> To simplify this, and to make the panel drivers less dependent on OMAP,
>> this patch changes omapdss to resolve the channel independently. The
>> channel is resolved based on the OMAP version and, in case of DSI, the
>> DSI module id.
>>
>> Signed-off-by: Tomi Valkeinen
>> ---
>> drivers/video/omap2/dss/dpi.c | 37 ++-
>> drivers/video/omap2/dss/dsi.c | 48
>>
>> drivers/video/omap2/dss/rfbi.c |2 ++
>> drivers/video/omap2/dss/sdi.c |2 ++
>> 4 files changed, 84 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/video/omap2/dss/dpi.c
>> b/drivers/video/omap2/dss/dpi.c
>> index e282456..3261644 100644
>> --- a/drivers/video/omap2/dss/dpi.c
>> +++ b/drivers/video/omap2/dss/dpi.c
>> @@ -396,12 +396,44 @@ static int __init dpi_verify_dsi_pll(struct
>> platform_device *dsidev)
>> return 0;
>> }
>>
>> +/*
>> + * Return a hardcoded channel for the DPI output. This should work for
>> + * current use cases, but this can be later expanded to either resolve
>> + * the channel in some more dynamic manner, or get the channel as a user
>> + * parameter.
>> + */
>> +static enum omap_channel dpi_get_channel(void)
>> +{
>> +switch (omapdss_get_version()) {
>> +case OMAPDSS_VER_OMAP24xx:
>> +case OMAPDSS_VER_OMAP34xx_ES1:
>> +case OMAPDSS_VER_OMAP34xx_ES3:
>> +case OMAPDSS_VER_OMAP3630:
>> +case OMAPDSS_VER_AM35xx:
>> +return OMAP_DSS_CHANNEL_LCD;
>> +
>> +case OMAPDSS_VER_OMAP4430_ES1:
>> +case OMAPDSS_VER_OMAP4430_ES2:
>> +case OMAPDSS_VER_OMAP4:
>> +return OMAP_DSS_CHANNEL_LCD2;
>> +
>> +case OMAPDSS_VER_OMAP5:
>> +return OMAP_DSS_CHANNEL_LCD2;
>> +
>> +default:
>> +DSSWARN("unsupported DSS version\n");
>> +return OMAP_DSS_CHANNEL_LCD;
>> +}
>> +}
>> +
>> static int __init dpi_init_display(struct omap_dss_device *dssdev)
>> {
>> struct platform_device *dsidev;
>>
>> DSSDBG("init_display\n");
>>
>> +dssdev->channel = dpi_get_channel();
>
> In patch 14 of the series, we remove these dssdev->channel assignments.
> I don't see the point of adding them in this patch in the first place.
> The dssdev->channel assignments will not be modified in this series, so
> we don't need to worry about a kernel crash or something after this patch.
>
> I feel this patch should only add the dpi_get_channel and
> dsi_get_channel funcs.
Yes, you're right. It's just extra going back and forth. I think I'll
merge this with the patch adding recommended channel.
>> +
>> if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI) &&
>> dpi.vdds_dsi_reg == NULL) {
>> struct regulator *vdds_dsi;
>> @@ -416,11 +448,6 @@ static int __init dpi_init_display(struct
>> omap_dss_device *dssdev)
>> dpi.vdds_dsi_reg = vdds_dsi;
>> }
>>
>> -/*
>> - * XXX We shouldn't need dssdev->channel for this. The dsi pll clock
>> - * source for DPI is SoC integration detail, not something that
>> should
>> - * be configured in the dssdev
>> - */
>> dsidev = dpi_get_dsidev(dssdev->channel);
>>
>> if (dsidev && dpi_verify_dsi_pll(dsidev)) {
>> diff --git a/drivers/video/omap2/dss/dsi.c
>> b/drivers/video/omap2/dss/dsi.c
>> index 1a6ad6f..c39ca86 100644
>> --- a/drivers/video/omap2/dss/dsi.c
>> +++ b/drivers/video/omap2/dss/dsi.c
>> @@ -4946,6 +4946,52 @@ void omapdss_dsi_set_videomode_timings(struct
>> omap_dss_device *dssdev,
>> }
>> EXPORT_SYMBOL(omapdss_dsi_set_videomode_timings);
>>
>> +/*
>> + * Return a hardcoded channel for the DSI output. This should work for
>> + * current use cases, but this can be later expanded to either resolve
>> + * the channel in some more dynamic manner, or get the channel as a user
>> + * parameter.
>> + */
>> +static enum omap_channel dsi_get_channel(int module_id)
>> +{
>> +switch (omapdss_get_version()) {
>> +case OMAPDSS_VER_OMAP24xx:
>
> We should remove the above case so that we hit the default case and get
> a warning about omap2 not having DSI.
Yep, I'll fix that.
Tomi
signature.asc
Description: OpenPGP digital signature
[PATCH] ARM: dts: omap2plus: remove interrupt-parent property
Removed interrupt-parent property from dts file as it is already
with root node in dtsi file.
Signed-off-by: Vishwanathrao Badarkhe, Manish
---
:100644 100644 f624dc8... 36e839a... M arch/arm/boot/dts/omap3-beagle.dts
:100644 100644 e8ba1c2... a5375fd... M arch/arm/boot/dts/omap3-evm.dts
:100644 100644 4122efe... 389c9c7... M arch/arm/boot/dts/omap4-panda.dts
:100644 100644 43e5258... cdf5dfd... M arch/arm/boot/dts/omap4-sdp.dts
:100644 100644 6601e6a... 1d4a9d4... M arch/arm/boot/dts/omap4-var-som.dts
arch/arm/boot/dts/omap3-beagle.dts |1 -
arch/arm/boot/dts/omap3-evm.dts |1 -
arch/arm/boot/dts/omap4-panda.dts |2 --
arch/arm/boot/dts/omap4-sdp.dts |2 --
arch/arm/boot/dts/omap4-var-som.dts |1 -
5 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts
b/arch/arm/boot/dts/omap3-beagle.dts
index f624dc8..36e839a 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -46,7 +46,6 @@
twl: twl@48 {
reg = <0x48>;
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
- interrupt-parent = <&intc>;
};
};
diff --git a/arch/arm/boot/dts/omap3-evm.dts b/arch/arm/boot/dts/omap3-evm.dts
index e8ba1c2..a5375fd 100644
--- a/arch/arm/boot/dts/omap3-evm.dts
+++ b/arch/arm/boot/dts/omap3-evm.dts
@@ -34,7 +34,6 @@
twl: twl@48 {
reg = <0x48>;
interrupts = <7>; /* SYS_NIRQ cascaded to intc */
- interrupt-parent = <&intc>;
};
};
diff --git a/arch/arm/boot/dts/omap4-panda.dts
b/arch/arm/boot/dts/omap4-panda.dts
index 4122efe..389c9c7 100644
--- a/arch/arm/boot/dts/omap4-panda.dts
+++ b/arch/arm/boot/dts/omap4-panda.dts
@@ -119,7 +119,6 @@
reg = <0x48>;
/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
- interrupt-parent = <&gic>;
};
twl6040: twl@4b {
@@ -127,7 +126,6 @@
reg = <0x4b>;
/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
interrupts = <0 119 4>; /* IRQ_SYS_2N cascaded to gic */
- interrupt-parent = <&gic>;
ti,audpwron-gpio = <&gpio4 31 0>; /* gpio line 127 */
vio-supply = <&v1v8>;
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 43e5258..cdf5dfd 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -221,7 +221,6 @@
reg = <0x48>;
/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
- interrupt-parent = <&gic>;
};
twl6040: twl@4b {
@@ -229,7 +228,6 @@
reg = <0x4b>;
/* SPI = 0, IRQ# = 119, 4 = active high level-sensitive */
interrupts = <0 119 4>; /* IRQ_SYS_2N cascaded to gic */
- interrupt-parent = <&gic>;
ti,audpwron-gpio = <&gpio4 31 0>; /* gpio line 127 */
vio-supply = <&v1v8>;
diff --git a/arch/arm/boot/dts/omap4-var-som.dts
b/arch/arm/boot/dts/omap4-var-som.dts
index 6601e6a..1d4a9d4 100644
--- a/arch/arm/boot/dts/omap4-var-som.dts
+++ b/arch/arm/boot/dts/omap4-var-som.dts
@@ -35,7 +35,6 @@
reg = <0x48>;
/* SPI = 0, IRQ# = 7, 4 = active high level-sensitive */
interrupts = <0 7 4>; /* IRQ_SYS_1N cascaded to gic */
- interrupt-parent = <&gic>;
};
};
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap4 pandaboard: clock input for TiWi module inactive
On 03/11/2013 09:58 AM, Roger Quadros wrote: > (+ Peter, Luca, Balaji) > > else your e-mail might just go unnoticed ;) > > On 03/07/2013 10:37 PM, Levi Pearson wrote: >> I recently upgraded from a 3.4 kernel to a 3.8 kernel and found that >> the drivers for the functionality provided by the TiWi module on the >> pandaboard (Bluetooth, WiFI, etc.) could no longer probe the device. >> After some investigation, it turned out that the TiWi clock is >> provided by the twl6030 PMIC chip. >> >> The clock output of the twl6030 was first enabled via these commits: >> >> https://patchwork.kernel.org/patch/546381/ >> https://patchwork.kernel.org/patch/546401/ >> >> Since most of the functionality of the TWL6030 is power regulation and >> the clock is enabled via a similar mechanism to the power outputs, the >> clock was added as a 'pseudo-regulator' to >> drivers/regulator/twl-regulator.c. >> >> Some time later, a series of commits removed the clock functionality >> from twl-regulator.c, apparently due to being out-of-place in the >> Device Tree listings or something. >> >> The first of these is recorded here: https://lkml.org/lkml/2012/6/4/330 >> The next two just clean up the code that was orphaned by the previous: >> e76ab829 "regulator: twl: Remove references to the twl4030 regulator" >> 029dd3ce "regulator: twl: Remove another unused variable warning" >> >> Luciano Cuelho, who maintains the driver for the WiFi portion of the >> TiWi modules, reported the resulting breakage some time later on the >> LKML: https://lkml.org/lkml/2012/11/15/72 >> >> Despite the protestation of Mark Brown that his code removal wasn't >> the cause of the problem, reverting his changes does indeed enable the >> clock. However, it also seems to be the case that there ought to be a >> better home for the clock than twl-regulator.c. At the time of the >> previous discussion, it wasn't clear if the framework was in place to >> support a clock driver for the twl6030's clock, but it seems like the >> support exists now, since there's a clock driver for the twl6030's >> companion, the twl6040 audio chip. IMHO the 'hack' in the twl-regulator should not have been removed before we provide proper support for the clocks via the common clock framework. >> So: Is there any chance of simply reverting the 3 commits that broke >> the clock? I have done this locally, but I hate to see pandaboard >> support in the mainstream kernel continue to be broken in this way. We should have the clock driver under drivers/clk/ via clk-twl6030.c driver for all the clocks twl6030 provides and use that in drivers (updating the clock tree as well). >> If for whatever reason the commits cannot be reverted, would creating >> a driver like drivers/clk/clk-twl6040.c that enabled the twl6030's >> clock output be a suitable alternative? I'd be willing to take a stab >> at writing it if there's not something like that in the works already. If you can take this it would be great. It is still in my to-do list to integrate the clk-twl6040 clock with the omap-mcpdm driver. I already got working code, but it is not working in a way I would really wanted to be. Integrating external clock to the SoC's clock tree does not seams to be that straight forward: at boot time when the clock tree is initialized the external chip is yet to be probed -> the root clock is not there, but later on for some reason I can not get the CCF to enable the clock tree correctly. -- Péter -- 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: omap4 pandaboard: clock input for TiWi module inactive
(+ Peter, Luca, Balaji) else your e-mail might just go unnoticed ;) On 03/07/2013 10:37 PM, Levi Pearson wrote: > I recently upgraded from a 3.4 kernel to a 3.8 kernel and found that > the drivers for the functionality provided by the TiWi module on the > pandaboard (Bluetooth, WiFI, etc.) could no longer probe the device. > After some investigation, it turned out that the TiWi clock is > provided by the twl6030 PMIC chip. > > The clock output of the twl6030 was first enabled via these commits: > > https://patchwork.kernel.org/patch/546381/ > https://patchwork.kernel.org/patch/546401/ > > Since most of the functionality of the TWL6030 is power regulation and > the clock is enabled via a similar mechanism to the power outputs, the > clock was added as a 'pseudo-regulator' to > drivers/regulator/twl-regulator.c. > > Some time later, a series of commits removed the clock functionality > from twl-regulator.c, apparently due to being out-of-place in the > Device Tree listings or something. > > The first of these is recorded here: https://lkml.org/lkml/2012/6/4/330 > The next two just clean up the code that was orphaned by the previous: > e76ab829 "regulator: twl: Remove references to the twl4030 regulator" > 029dd3ce "regulator: twl: Remove another unused variable warning" > > Luciano Cuelho, who maintains the driver for the WiFi portion of the > TiWi modules, reported the resulting breakage some time later on the > LKML: https://lkml.org/lkml/2012/11/15/72 > > Despite the protestation of Mark Brown that his code removal wasn't > the cause of the problem, reverting his changes does indeed enable the > clock. However, it also seems to be the case that there ought to be a > better home for the clock than twl-regulator.c. At the time of the > previous discussion, it wasn't clear if the framework was in place to > support a clock driver for the twl6030's clock, but it seems like the > support exists now, since there's a clock driver for the twl6030's > companion, the twl6040 audio chip. > > So: Is there any chance of simply reverting the 3 commits that broke > the clock? I have done this locally, but I hate to see pandaboard > support in the mainstream kernel continue to be broken in this way. > > If for whatever reason the commits cannot be reverted, would creating > a driver like drivers/clk/clk-twl6040.c that enabled the twl6030's > clock output be a suitable alternative? I'd be willing to take a stab > at writing it if there's not something like that in the works already. > > --- > Levi Pearson > -- > 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 > -- 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 01/13] usb: phy: nop: Add device tree support and binding information
On 03/08/2013 05:45 PM, Marc Kleine-Budde wrote:
> On 03/08/2013 11:46 AM, Marc Kleine-Budde wrote:
>> On 02/04/2013 04:58 PM, Roger Quadros wrote:
>>> The PHY clock, clock rate, VCC regulator and RESET regulator
>>> can now be provided via device tree.
>>>
>>> Signed-off-by: Roger Quadros
>>> ---
>>> .../devicetree/bindings/usb/usb-nop-xceiv.txt | 34
>>>
>>> drivers/usb/otg/nop-usb-xceiv.c| 31
>>> ++
>>> 2 files changed, 65 insertions(+), 0 deletions(-)
>>> create mode 100644 Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>> b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>> new file mode 100644
>>> index 000..d7e2726
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
>>> @@ -0,0 +1,34 @@
>>> +USB NOP PHY
>>> +
>>> +Required properties:
>>> +- compatible: should be usb-nop-xceiv
>>> +
>>> +Optional properties:
>>> +- clocks: phandle to the PHY clock. Use as per Documentation/devicetree
>>> + /bindings/clock/clock-bindings.txt
>>> + This property is required if clock-frequency is specified.
>>> +
>>> +- clock-names: Should be "main_clk"
>>> +
>>> +- clock-frequency: the clock frequency (in Hz) that the PHY clock must
>>> + be configured to.
>>> +
>>> +- vcc-supply: phandle to the regulator that provides RESET to the PHY.
>>> +
>>> +- reset-supply: phandle to the regulator that provides power to the PHY.
>>> +
>>> +Example:
>>> +
>>> + hsusb1_phy {
>>> + compatible = "usb-nop-xceiv";
>>> + clock-frequency = <1920>;
>>
>> Why do you hardcode the clock frequency here? You should use
>> clk_get_rate() to get the frequency from the clock tree.
>
> What about declaring a "fixed-clock" node in the device tree? Then it
> should be possible to keep the driver free of any omap specific code.
>
The current implementation is not OMAP specific and is not limited to a
fixed frequency clock. The PHY driver is using standard clock APIs to set
the clock rate 'only' if the 'clock-frequency' property is present in the
device tree node.
What is the benefit of declaring it as a "fixed-clock"?
FYI. The clock may not necessarily be a fixed frequency clock and someone
needs to program the rate.
cheers,
-roger
--
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 19/20] OMAPDSS: DSI: fix DSI channel source initialization
On 2013-03-11 10:15, Archit Taneja wrote:
> On Monday 11 March 2013 12:32 PM, Tomi Valkeinen wrote:
>> On 2013-03-11 08:10, Archit Taneja wrote:
>>> Hi,
>>>
>>> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
During the initialization of the DSI protocol registers, we always set
the sources of all DSI channels to L4. However, we don't update the
value in the dsi_data, so we may end up with a different value in the
register and in the dsi_data, leading to DSI problems.
This patch fixes the issue by initializing also the channel source in
the dsi_data.
>>>
>>> We set in omap_dsihw_probe:
>>>
>>> static int __init omap_dsihw_probe(struct platform_device *dsidev)
>>> {
>>> ...
>>> ...
>>> /* DSI VCs initialization */
>>> for (i = 0; i < ARRAY_SIZE(dsi->vc); i++) {
>>> dsi->vc[i].source = DSI_VC_SOURCE_L4;
>>> dsi->vc[i].dssdev = NULL;
>>> dsi->vc[i].vc_id = 0;
>>> }
>>> ...
>>> ...
>>> }
>>
>> Hmm... I did have a bug related to this when prototyping CDF. Ah.
>> Consider this:
>>
>> Panel powers up and uses DSI normally. A DSI VC is set to video mode.
>> Then the panel power down. Then it powers up again, and enables DSI. At
>> this time, dsi_vc_initial_config() is called again, setting the source
>> in the registers to L4. But the source in dsi_data is still VP.
>
> Oh ok.
>
>>
>> So perhaps the whole piece of code from omap_dsihw_probe should be moved
>> to somewhere else (dsi_vc_initial_config() sounds like a good place), so
>> that they are initialized each time the registers are initialized.
>
> VC source is something which seems fine to do in
> dsi_vc_initial_config(). I'm not sure about the dssdev and vc_id fields
> though, we would need to call omap_dsi_request_vc() and
> omap_dsi_set_vc_id() again after a power off. Currently, we do it only
> once in taal_probe().
Oh, right. Well, neither dssdev nor vc_id is written to registers, so
they won't have similar issues in any case. So I guess this patch is
fine as it is, and we do not need to touch dssdev nor vc_id.
Tomi
signature.asc
Description: OpenPGP digital signature
Re: [PATCH 19/20] OMAPDSS: DSI: fix DSI channel source initialization
On Monday 11 March 2013 12:32 PM, Tomi Valkeinen wrote:
On 2013-03-11 08:10, Archit Taneja wrote:
Hi,
On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
During the initialization of the DSI protocol registers, we always set
the sources of all DSI channels to L4. However, we don't update the
value in the dsi_data, so we may end up with a different value in the
register and in the dsi_data, leading to DSI problems.
This patch fixes the issue by initializing also the channel source in
the dsi_data.
We set in omap_dsihw_probe:
static int __init omap_dsihw_probe(struct platform_device *dsidev)
{
...
...
/* DSI VCs initialization */
for (i = 0; i < ARRAY_SIZE(dsi->vc); i++) {
dsi->vc[i].source = DSI_VC_SOURCE_L4;
dsi->vc[i].dssdev = NULL;
dsi->vc[i].vc_id = 0;
}
...
...
}
Hmm... I did have a bug related to this when prototyping CDF. Ah.
Consider this:
Panel powers up and uses DSI normally. A DSI VC is set to video mode.
Then the panel power down. Then it powers up again, and enables DSI. At
this time, dsi_vc_initial_config() is called again, setting the source
in the registers to L4. But the source in dsi_data is still VP.
Oh ok.
So perhaps the whole piece of code from omap_dsihw_probe should be moved
to somewhere else (dsi_vc_initial_config() sounds like a good place), so
that they are initialized each time the registers are initialized.
VC source is something which seems fine to do in
dsi_vc_initial_config(). I'm not sure about the dssdev and vc_id fields
though, we would need to call omap_dsi_request_vc() and
omap_dsi_set_vc_id() again after a power off. Currently, we do it only
once in taal_probe().
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
[PATCH V2 2/2] ASoC: OMAP2+: Move McBSP, DMIC and McPDM to generic DMA DT binding
Update OMAP2+ driver in order to use OMAP DMA DT binding for OMAP2+.
In case of DT boot snd_dmaengine_generic_pcm_open function is used.
Signed-off-by: Sebastien Guiriec
---
sound/soc/omap/mcbsp.c | 26 --
sound/soc/omap/omap-dmic.c | 15 +--
sound/soc/omap/omap-mcpdm.c | 22 ++
sound/soc/omap/omap-pcm.c | 12 ++--
sound/soc/omap/omap-pcm.h |1 +
5 files changed, 50 insertions(+), 26 deletions(-)
diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
index 285c836..16936493 100644
--- a/sound/soc/omap/mcbsp.c
+++ b/sound/soc/omap/mcbsp.c
@@ -1012,24 +1012,30 @@ int omap_mcbsp_init(struct platform_device *pdev)
}
}
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
- if (!res) {
- dev_err(&pdev->dev, "invalid rx DMA channel\n");
- return -ENODEV;
+ if (!pdev->dev.of_node) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx");
+ if (!res) {
+ dev_err(&pdev->dev, "invalid rx DMA channel\n");
+ return -ENODEV;
+ }
+ mcbsp->dma_data[1].dma_req = res->start;
}
/* RX DMA request number, and port address configuration */
mcbsp->dma_data[1].name = "Audio Capture";
- mcbsp->dma_data[1].dma_req = res->start;
+ mcbsp->dma_data[1].dma_name = "rx";
mcbsp->dma_data[1].port_addr = omap_mcbsp_dma_reg_params(mcbsp, 1);
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
- if (!res) {
- dev_err(&pdev->dev, "invalid tx DMA channel\n");
- return -ENODEV;
+ if (!pdev->dev.of_node) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx");
+ if (!res) {
+ dev_err(&pdev->dev, "invalid tx DMA channel\n");
+ return -ENODEV;
+ }
+ mcbsp->dma_data[0].dma_req = res->start;
}
/* TX DMA request number, and port address configuration */
mcbsp->dma_data[0].name = "Audio Playback";
- mcbsp->dma_data[0].dma_req = res->start;
+ mcbsp->dma_data[0].dma_name = "tx";
mcbsp->dma_data[0].port_addr = omap_mcbsp_dma_reg_params(mcbsp, 0);
mcbsp->fclk = clk_get(&pdev->dev, "fck");
diff --git a/sound/soc/omap/omap-dmic.c b/sound/soc/omap/omap-dmic.c
index ba49ccd..8695b32 100644
--- a/sound/soc/omap/omap-dmic.c
+++ b/sound/soc/omap/omap-dmic.c
@@ -62,6 +62,7 @@ struct omap_dmic {
*/
static struct omap_pcm_dma_data omap_dmic_dai_dma_params = {
.name = "DMIC capture",
+ .dma_name = "up_link",
};
static inline void omap_dmic_write(struct omap_dmic *dmic, u16 reg, u32 val)
@@ -478,13 +479,15 @@ static int asoc_dmic_probe(struct platform_device *pdev)
}
omap_dmic_dai_dma_params.port_addr = res->start + OMAP_DMIC_DATA_REG;
- res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
- if (!res) {
- dev_err(dmic->dev, "invalid dma resource\n");
- ret = -ENODEV;
- goto err_put_clk;
+ if (!pdev->dev.of_node) {
+ res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
+ if (!res) {
+ dev_err(dmic->dev, "invalid dma resource\n");
+ ret = -ENODEV;
+ goto err_put_clk;
+ }
+ omap_dmic_dai_dma_params.dma_req = res->start;
}
- omap_dmic_dai_dma_params.dma_req = res->start;
res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "mpu");
if (!res) {
diff --git a/sound/soc/omap/omap-mcpdm.c b/sound/soc/omap/omap-mcpdm.c
index 5ca11bd..f41bac8 100644
--- a/sound/soc/omap/omap-mcpdm.c
+++ b/sound/soc/omap/omap-mcpdm.c
@@ -71,9 +71,11 @@ struct omap_mcpdm {
static struct omap_pcm_dma_data omap_mcpdm_dai_dma_params[] = {
{
.name = "Audio playback",
+ .dma_name = "dn_link",
},
{
.name = "Audio capture",
+ .dma_name = "up_link",
},
};
@@ -449,17 +451,21 @@ static int asoc_mcpdm_probe(struct platform_device *pdev)
omap_mcpdm_dai_dma_params[0].port_addr = res->start + MCPDM_REG_DN_DATA;
omap_mcpdm_dai_dma_params[1].port_addr = res->start + MCPDM_REG_UP_DATA;
- res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "dn_link");
- if (!res)
- return -ENODEV;
+ if (!pdev->dev.of_node) {
+ res = platform_get_resource_byname(pdev, IORESOURCE_DMA,
+ "dn_link");
+ if (!res)
+ return -ENODEV;
- omap_mcpdm_dai_dma_params[0].dma_req = res->start;
+ omap_mcpdm_dai_dma_params[0].dma_req = res->start;
- res =
[PATCH V2 1/2] ARM: dts: OMAP2+: Add SDMA Audio IPs bindings
Populate DMA client information for McBSP DMIC and McPDM periperhal on
OMAP2+ devices.
Signed-off-by: Sebastien Guiriec
---
arch/arm/boot/dts/omap2420.dtsi |6 ++
arch/arm/boot/dts/omap2430.dtsi | 15 +++
arch/arm/boot/dts/omap3.dtsi| 15 +++
arch/arm/boot/dts/omap4.dtsi| 17 +
arch/arm/boot/dts/omap5.dtsi| 14 ++
5 files changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/omap2420.dtsi b/arch/arm/boot/dts/omap2420.dtsi
index af65609..45930f2 100644
--- a/arch/arm/boot/dts/omap2420.dtsi
+++ b/arch/arm/boot/dts/omap2420.dtsi
@@ -37,6 +37,9 @@
<60>; /* RX interrupt */
interrupt-names = "tx", "rx";
ti,hwmods = "mcbsp1";
+ dmas = <&sdma 31>,
+ <&sdma 32>;
+ dma-names = "tx", "rx";
};
mcbsp2: mcbsp@48076000 {
@@ -47,6 +50,9 @@
<63>; /* RX interrupt */
interrupt-names = "tx", "rx";
ti,hwmods = "mcbsp2";
+ dmas = <&sdma 33>,
+ <&sdma 34>;
+ dma-names = "tx", "rx";
};
timer1: timer@48028000 {
diff --git a/arch/arm/boot/dts/omap2430.dtsi b/arch/arm/boot/dts/omap2430.dtsi
index c392445..cfe7ed9 100644
--- a/arch/arm/boot/dts/omap2430.dtsi
+++ b/arch/arm/boot/dts/omap2430.dtsi
@@ -40,6 +40,9 @@
interrupt-names = "common", "tx", "rx", "rx_overflow";
ti,buffer-size = <128>;
ti,hwmods = "mcbsp1";
+ dmas = <&sdma 31>,
+ <&sdma 32>;
+ dma-names = "tx", "rx";
};
mcbsp2: mcbsp@48076000 {
@@ -52,6 +55,9 @@
interrupt-names = "common", "tx", "rx";
ti,buffer-size = <128>;
ti,hwmods = "mcbsp2";
+ dmas = <&sdma 33>,
+ <&sdma 34>;
+ dma-names = "tx", "rx";
};
mcbsp3: mcbsp@4808c000 {
@@ -64,6 +70,9 @@
interrupt-names = "common", "tx", "rx";
ti,buffer-size = <128>;
ti,hwmods = "mcbsp3";
+ dmas = <&sdma 17>,
+ <&sdma 18>;
+ dma-names = "tx", "rx";
};
mcbsp4: mcbsp@4808e000 {
@@ -76,6 +85,9 @@
interrupt-names = "common", "tx", "rx";
ti,buffer-size = <128>;
ti,hwmods = "mcbsp4";
+ dmas = <&sdma 19>,
+ <&sdma 20>;
+ dma-names = "tx", "rx";
};
mcbsp5: mcbsp@48096000 {
@@ -88,6 +100,9 @@
interrupt-names = "common", "tx", "rx";
ti,buffer-size = <128>;
ti,hwmods = "mcbsp5";
+ dmas = <&sdma 21>,
+ <&sdma 22>;
+ dma-names = "tx", "rx";
};
timer1: timer@49018000 {
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 4e7acb6..f901404 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -289,6 +289,9 @@
interrupt-names = "common", "tx", "rx";
ti,buffer-size = <128>;
ti,hwmods = "mcbsp1";
+ dmas = <&sdma 31>,
+ <&sdma 32>;
+ dma-names = "tx", "rx";
};
mcbsp2: mcbsp@49022000 {
@@ -303,6 +306,9 @@
interrupt-names = "common", "tx", "rx", "sidetone";
ti,buffer-size = <1280>;
ti,hwmods = "mcbsp2", "mcbsp2_sidetone";
+ dmas = <&sdma 33>,
+ <&sdma 34>;
+ dma-names = "tx", "rx";
};
mcbsp3: mcbsp@49024000 {
@@ -317,6 +323,9 @@
interrupt-names = "common", "tx", "rx", "sidetone";
ti,buffer-size = <128>;
ti,hwmods = "mcbsp3", "mcbsp3_sidetone";
+ dmas = <&sdma 17>,
+ <&sdma 18>;
+ dma-names = "tx", "rx";
};
mcbsp4: mcbsp@49026000 {
@@ -329,6 +338,9 @@
interrupt-names = "common", "tx", "rx";
ti,buffer-size = <128>;
ti,hwmods = "mcbsp4";
+ dmas =
[PATCH V2 0/2] ASoC: OMAP2+: Update Audio IP with sDMA binding for DT boot
This patch serie is converting OMAP Audio IPs in order to use OMAP sDMA DT binding in case of DT boot on OMAP2+ platforms. It is depending on the next patches: [1] http://www.spinics.net/lists/arm-kernel/msg227836.html [2] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg84668.html It has been tested on: - OMAP5 (sEVM/panda)in DT boot (McPDM/DMIC). - OMAP4 (SDP4430/Panda) in both DT/non DT boot (McPDM/DMIC) - OMAP3 (Beagle XM) in both DT/non DT boot (McBSP) Update since v1: - Put DTS patch in first. - Squash all OMAP IPs patch together. Sebastien Guiriec (2): ARM: dts: OMAP2+: Add SDMA Audio IPs bindings ASoC: OMAP2+: Move McBSP, DMIC and McPDM to generic DMA DT binding arch/arm/boot/dts/omap2420.dtsi |6 ++ arch/arm/boot/dts/omap2430.dtsi | 15 +++ arch/arm/boot/dts/omap3.dtsi| 15 +++ arch/arm/boot/dts/omap4.dtsi| 17 + arch/arm/boot/dts/omap5.dtsi| 14 ++ sound/soc/omap/mcbsp.c | 26 -- sound/soc/omap/omap-dmic.c | 15 +-- sound/soc/omap/omap-mcpdm.c | 22 ++ sound/soc/omap/omap-pcm.c | 12 ++-- sound/soc/omap/omap-pcm.h |1 + 10 files changed, 117 insertions(+), 26 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: [PATCH 19/20] OMAPDSS: DSI: fix DSI channel source initialization
On 2013-03-11 08:10, Archit Taneja wrote:
> Hi,
>
> On Friday 08 March 2013 05:21 PM, Tomi Valkeinen wrote:
>> During the initialization of the DSI protocol registers, we always set
>> the sources of all DSI channels to L4. However, we don't update the
>> value in the dsi_data, so we may end up with a different value in the
>> register and in the dsi_data, leading to DSI problems.
>>
>> This patch fixes the issue by initializing also the channel source in
>> the dsi_data.
>
> We set in omap_dsihw_probe:
>
> static int __init omap_dsihw_probe(struct platform_device *dsidev)
> {
> ...
> ...
> /* DSI VCs initialization */
> for (i = 0; i < ARRAY_SIZE(dsi->vc); i++) {
> dsi->vc[i].source = DSI_VC_SOURCE_L4;
> dsi->vc[i].dssdev = NULL;
> dsi->vc[i].vc_id = 0;
> }
> ...
> ...
> }
Hmm... I did have a bug related to this when prototyping CDF. Ah.
Consider this:
Panel powers up and uses DSI normally. A DSI VC is set to video mode.
Then the panel power down. Then it powers up again, and enables DSI. At
this time, dsi_vc_initial_config() is called again, setting the source
in the registers to L4. But the source in dsi_data is still VP.
So perhaps the whole piece of code from omap_dsihw_probe should be moved
to somewhere else (dsi_vc_initial_config() sounds like a good place), so
that they are initialized each time the registers are initialized.
Tomi
signature.asc
Description: OpenPGP digital signature
