Re: Spurious ECC errors with mtd_subpagetest (OMAP3, NAND)
On 03/02/2012 06:17 PM, Grazvydas Ignotas wrote: IIRC NAND in mainline was broken for very long time on OMAP3, I think it was only fixed in 2.6.39.1. That seems to be the case; the 2.6.39.1 diff contains the OMAP NAND sub page write fix (applied locally). Anyone else who can testify on the volatile-ness of NAND ECC errors? I.e., are they expected to be more persistent? Thanks, Orjan -- Orjan Friberg FlatFrog Laboratories AB -- 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 11/12] mfd: twl4030-irq: Return twl6030_mmc_card_detect IRQ for board setup
On Friday 02 March 2012 11:45 PM, Felipe Balbi wrote: Hi, On Fri, Mar 02, 2012 at 05:50:23PM +0100, Benoit Cousson wrote: Card detect IRQ from the TWL6030 used to be provided to the MMC controller code using a statically allocated IRQ scheme: card_detect_irq = TWL6030_IRQ_BASE + MMCDETECT_INTR_OFFSET; This is no longer valid in a SPARSE_IRQ context since there is no more pre-defined TWL6030_IRQ_BASE. Return the proper card detect IRQ value in the twl6030_mmc_card_detect_config that will be called from the MMC controller. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Felipe Balbiba...@ti.com Cc: Tony Lindgrent...@atomide.com Cc: Rajendra Nayakrna...@ti.com Reviewed-by: Felipe Balbiba...@ti.com --- drivers/mfd/twl6030-irq.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c index a1c7183..4a63de2 100644 --- a/drivers/mfd/twl6030-irq.c +++ b/drivers/mfd/twl6030-irq.c @@ -308,7 +308,8 @@ int twl6030_mmc_card_detect_config(void) ret); return ret; } - return 0; + + return twl6030_irq_base + MMCDETECT_INTR_OFFSET; } EXPORT_SYMBOL(twl6030_mmc_card_detect_config); At some point this twl6030_mmc_card_detect_config() needs to vanish in favor of a better mechanism. Maybe passing the GPIO number an requiring the driver to request the GPIO, set its direction and use it as IRQ line. the only problem would arise if we end up hooking the Card Detect pin to a real IRQ line, but then we can use a flag to differentiate. Shouldn't this be hidden from the driver completely if the card detect pin is a GPIO or connected to a real IRQ line? And the board/DT handle this instead of the driver knowing when to do a gpio_to_irq()? But I see thats not the case with most mmc drivers, not just OMAP, I wonder why. -- 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 11/12] mfd: twl4030-irq: Return twl6030_mmc_card_detect IRQ for board setup
Hi Sergei, On 3/3/2012 4:09 PM, Sergei Shtylyov wrote: Hello. On 02-03-2012 20:50, Benoit Cousson wrote: Card detect IRQ from the TWL6030 used to be provided to the MMC controller code using a statically allocated IRQ scheme: card_detect_irq = TWL6030_IRQ_BASE + MMCDETECT_INTR_OFFSET; This is no longer valid in a SPARSE_IRQ context since there is no more pre-defined TWL6030_IRQ_BASE. Return the proper card detect IRQ value in the twl6030_mmc_card_detect_config that will be called from the MMC controller. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Felipe Balbiba...@ti.com Cc: Tony Lindgrent...@atomide.com Cc: Rajendra Nayakrna...@ti.com --- drivers/mfd/twl6030-irq.c | 3 ++- Subject talks about twl4030-irq. Oops, good catch. thanks. I guess that Tony's patch (mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect) will supersede that one. 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: Spurious ECC errors with mtd_subpagetest (OMAP3, NAND)
Hi, Orjan Friberg a écrit : On 03/02/2012 06:17 PM, Grazvydas Ignotas wrote: IIRC NAND in mainline was broken for very long time on OMAP3, I think it was only fixed in 2.6.39.1. That seems to be the case; the 2.6.39.1 diff contains the OMAP NAND sub page write fix (applied locally). Note that the omap driver is still broken : http://article.gmane.org/gmane.linux.drivers.mtd/36079/match= We detected this when stressing a board. Because all of these bugs in omap driver, I wonder how many people really use the mainline version. Also if you use a nand that need 4-bit ECC, you need a better ecc than hamming. You can use the bch code ( http://article.gmane.org/gmane.linux.drivers.mtd/37864/match=omap ) Matthieu PS : why omap driver use in omap_dev_ready GPMC*IRQ_STATUS instead of GPMC_STATUS. PS2 : ecc hamming look strange. Weird isEccFF code. Doesn't seem to handle bit flip in ecc. -- 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 11/12] mfd: twl4030-irq: Return twl6030_mmc_card_detect IRQ for board setup
On 3/5/2012 9:19 AM, Rajendra Nayak wrote: On Friday 02 March 2012 11:45 PM, Felipe Balbi wrote: Hi, On Fri, Mar 02, 2012 at 05:50:23PM +0100, Benoit Cousson wrote: Card detect IRQ from the TWL6030 used to be provided to the MMC controller code using a statically allocated IRQ scheme: card_detect_irq = TWL6030_IRQ_BASE + MMCDETECT_INTR_OFFSET; This is no longer valid in a SPARSE_IRQ context since there is no more pre-defined TWL6030_IRQ_BASE. Return the proper card detect IRQ value in the twl6030_mmc_card_detect_config that will be called from the MMC controller. Signed-off-by: Benoit Coussonb-cous...@ti.com Cc: Felipe Balbiba...@ti.com Cc: Tony Lindgrent...@atomide.com Cc: Rajendra Nayakrna...@ti.com Reviewed-by: Felipe Balbiba...@ti.com --- drivers/mfd/twl6030-irq.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c index a1c7183..4a63de2 100644 --- a/drivers/mfd/twl6030-irq.c +++ b/drivers/mfd/twl6030-irq.c @@ -308,7 +308,8 @@ int twl6030_mmc_card_detect_config(void) ret); return ret; } - return 0; + + return twl6030_irq_base + MMCDETECT_INTR_OFFSET; } EXPORT_SYMBOL(twl6030_mmc_card_detect_config); At some point this twl6030_mmc_card_detect_config() needs to vanish in favor of a better mechanism. Maybe passing the GPIO number an requiring the driver to request the GPIO, set its direction and use it as IRQ line. the only problem would arise if we end up hooking the Card Detect pin to a real IRQ line, but then we can use a flag to differentiate. Shouldn't this be hidden from the driver completely if the card detect pin is a GPIO or connected to a real IRQ line? And the board/DT handle this instead of the driver knowing when to do a gpio_to_irq()? It work fine for a pure GPIO, but in this case, this is an IRQ handled by twl6030. So I'm not sure we have any API for the non-DT case. DT will clearly help getting rid of such hacks. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Spurious ECC errors with mtd_subpagetest (OMAP3, NAND)
On 03/05/2012 09:56 AM, Matthieu CASTET wrote: Note that the omap driver is still broken : http://article.gmane.org/gmane.linux.drivers.mtd/36079/match= We detected this when stressing a board. Because all of these bugs in omap driver, I wonder how many people really use the mainline version. Do you know any repo where this is working correctly (linux-omap, or one of the vendor trees etc)? Also if you use a nand that need 4-bit ECC, you need a better ecc than hamming. You can use the bch code ( http://article.gmane.org/gmane.linux.drivers.mtd/37864/match=omap ) Yes, I've been looking at the BCH 4-bit code (both generic implementations and the OMAP GPMC-enabled one) in u-boot and linux. -- Orjan Friberg FlatFrog Laboratories AB -- 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] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect
On Friday 02 March 2012 10:52 PM, Tony Lindgren wrote: BTW, with -rc5, looks like re-inserting omap_hsmmc on omap4 fails to detect any cards, and then fails to unload. This works on omap3 just fine. Any ideas why that would be? Yeah, looks like thats broken. I am not sure whats going wrong though. I just enabled CONFIG_MMC_DEBUG and saw these logs below. Venkat/Balaji, care to look at this one? # insmod omap_hsmmc.ko [ 43.358398] omap_hsmmc omap_hsmmc.0: context was not lost [ 43.364105] omap_hsmmc omap_hsmmc.0: enabled [ 44.434661] mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 44.442352] omap_hsmmc omap_hsmmc.0: Set clock to 0Hz [ 44.474365] omap_hsmmc omap_hsmmc.0: disabled [ 44.482208] omap_hsmmc omap_hsmmc.4: context was not lost [ 44.482208] omap_hsmmc omap_hsmmc.4: enabled [ 44.546600] omap_hsmmc omap_hsmmc.0: context was not lost [ 44.552276] omap_hsmmc omap_hsmmc.0: enabled [ 44.552276] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz [ 44.563720] mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 18 width 0 timing 0 [ 44.572174] omap_hsmmc omap_hsmmc.0: Set clock to 0Hz [ 44.613800] mmc0: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 18 width 0 timing 0 [ 44.621887] omap_hsmmc omap_hsmmc.0: Set clock to 40Hz [ 44.735290] mmc0: starting CMD52 arg 0c00 flags 0195 [ 44.741271] omap_hsmmc omap_hsmmc.0: mmc0: CMD52, argument 0x0c00 [ 45.560241] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 45.567871] omap_hsmmc omap_hsmmc.4: Set clock to 0Hz [ 45.591491] omap_hsmmc omap_hsmmc.4: disabled # # # rmmod omap_hsmmc [ 607.302307] omap_hsmmc omap_hsmmc.4: context was not lost [ 607.308044] omap_hsmmc omap_hsmmc.4: enabled [ 607.312591] omap_hsmmc omap_hsmmc.4: disabled [ 607.317199] omap_hsmmc omap_hsmmc.4: context was not lost [ 607.322875] omap_hsmmc omap_hsmmc.4: enabled -- 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: OMAP2+: voltage: ensure voltage used is exact voltage from OPP table
On Fri, 2012-03-02 at 14:42 -0800, Kevin Hilman wrote:
When using the SMPS regulators to scale voltages, the regulator
framework may pass a minimum voltage that is not an exact OPP voltage.
For the VC/VP controlled voltage domains, we must ensure that the
voltage requested is the exact voltage from the OPP table. This is
especially critical when using SR.
To fix, voltdm_scale() uses the target voltage passed to walk through
the OPP voltages until it finds a voltage that is = one of the OPP
voltages.
I have just one question to this, how about smartreflex class1p5? Do we
have any plans for that one? The old implementation at least was using
voltdm_scale, so if we modify this function, smartreflex class1p5
doesn't work anymore.
Otherwise this patch looks good to me.
-Tero
Cc: Tero Kristo t-kri...@ti.com
Cc: Nishanth Menon n...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Unless there are any objections, this will be queued along with the
rest of the SMPS regulator series from Tero. Currently availble in
my for_3.4/pm/smps-regulator branch at
git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git
arch/arm/mach-omap2/voltage.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.c b/arch/arm/mach-omap2/voltage.c
index 8a36342..4dc60e8 100644
--- a/arch/arm/mach-omap2/voltage.c
+++ b/arch/arm/mach-omap2/voltage.c
@@ -73,7 +73,8 @@ unsigned long voltdm_get_voltage(struct voltagedomain
*voltdm)
int voltdm_scale(struct voltagedomain *voltdm,
unsigned long target_volt)
{
- int ret;
+ int ret, i;
+ unsigned long volt = 0;
if (!voltdm || IS_ERR(voltdm)) {
pr_warning(%s: VDD specified does not exist!\n, __func__);
@@ -86,9 +87,23 @@ int voltdm_scale(struct voltagedomain *voltdm,
return -ENODATA;
}
- ret = voltdm-scale(voltdm, target_volt);
+ /* Adjust voltage to the exact voltage from the OPP table */
+ for (i = 0; voltdm-volt_data[i].volt_nominal != 0; i++) {
+ if (voltdm-volt_data[i].volt_nominal = target_volt) {
+ volt = voltdm-volt_data[i].volt_nominal;
+ break;
+ }
+ }
+
+ if (!volt) {
+ pr_warning(%s: not scaling. OPP voltage for %lu, not found.\n,
+__func__, target_volt);
+ return -EINVAL;
+ }
+
+ ret = voltdm-scale(voltdm, volt);
if (!ret)
- voltdm-nominal_volt = target_volt;
+ voltdm-nominal_volt = volt;
return ret;
}
--
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: help: BeagleBoard xM RevC ethernet port
On 02/28/2012 04:04 PM, Govindraj wrote: The issue seems to a mux conflict issue, uart2_rx mux is been taken by uart init and gpio_147 needed for usb phy init is not in mux mode4 as set by bootloader. On beagle I see no other uarts being used other than uart3 as console_uart. So I think it should be okay to init only uart3 from beagle board data. Here is the patch [1] to do the same. (Tested on Beagle Xm Rev.C) (Any other approach is welcome) Thank you, I have working ethernet port finally!!! From f1b43f983a2926c637e6bc6ab5d1e5044339ffd3 Mon Sep 17 00:00:00 2001 From: Govindraj.R govindraj.r...@ti.com Date: Tue, 28 Feb 2012 19:16:33 +0530 Subject: [PATCH] omap3_beagle: Init only uart3 used for console On beagle some of uart mux lines are used for other purpose so init only uart3. Uart2 rx line clashes with gpio_147 used for usb ehci phy reset. Tested-by: Peter Ujfalusi peter.ujfal...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 0/6] ARM: OMAP3+: IO daisychain support fixes
On Friday 02 March 2012 08:47 PM, Tero Kristo wrote: Hi, Changes compared to previous version: - patch2: * changed timeout value to 100us (from 1000) * added poll for the IO status == 0 at the end of trigger sequence - patch4: * omap3: global wakeup done in PRM init instead of OMAP3 PM init * omap4: moved global wakeup enable from trigger func to PRM init Tested on omap3beagle / omap4blaze, suspend / resume works with io chain. for the full series, Reviewed-by: Rajendra Nayak rna...@ti.com -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect
On Mon, Mar 5, 2012 at 2:46 PM, Rajendra Nayak rna...@ti.com wrote: On Friday 02 March 2012 10:52 PM, Tony Lindgren wrote: BTW, with -rc5, looks like re-inserting omap_hsmmc on omap4 fails to detect any cards, and then fails to unload. This works on omap3 just fine. Any ideas why that would be? Yeah, looks like thats broken. I am not sure whats going wrong though. I just enabled CONFIG_MMC_DEBUG and saw these logs below. Venkat/Balaji, care to look at this one? Let me check this # insmod omap_hsmmc.ko [ 43.358398] omap_hsmmc omap_hsmmc.0: context was not lost [ 43.364105] omap_hsmmc omap_hsmmc.0: enabled [ 44.434661] mmc0: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 44.442352] omap_hsmmc omap_hsmmc.0: Set clock to 0Hz [ 44.474365] omap_hsmmc omap_hsmmc.0: disabled [ 44.482208] omap_hsmmc omap_hsmmc.4: context was not lost [ 44.482208] omap_hsmmc omap_hsmmc.4: enabled [ 44.546600] omap_hsmmc omap_hsmmc.0: context was not lost [ 44.552276] omap_hsmmc omap_hsmmc.0: enabled [ 44.552276] mmc0: mmc_rescan_try_freq: trying to init card at 40 Hz [ 44.563720] mmc0: clock 0Hz busmode 2 powermode 1 cs 0 Vdd 18 width 0 timing 0 [ 44.572174] omap_hsmmc omap_hsmmc.0: Set clock to 0Hz [ 44.613800] mmc0: clock 40Hz busmode 2 powermode 2 cs 0 Vdd 18 width 0 timing 0 [ 44.621887] omap_hsmmc omap_hsmmc.0: Set clock to 40Hz [ 44.735290] mmc0: starting CMD52 arg 0c00 flags 0195 [ 44.741271] omap_hsmmc omap_hsmmc.0: mmc0: CMD52, argument 0x0c00 [ 45.560241] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 45.567871] omap_hsmmc omap_hsmmc.4: Set clock to 0Hz [ 45.591491] omap_hsmmc omap_hsmmc.4: disabled # # # rmmod omap_hsmmc [ 607.302307] omap_hsmmc omap_hsmmc.4: context was not lost [ 607.308044] omap_hsmmc omap_hsmmc.4: enabled [ 607.312591] omap_hsmmc omap_hsmmc.4: disabled [ 607.317199] omap_hsmmc omap_hsmmc.4: context was not lost [ 607.322875] omap_hsmmc omap_hsmmc.4: enabled -- 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: [RFC PATCH] of: DMA helpers: manage generic requests specification
Hi Nico,
On 2/29/2012 3:54 PM, Nicolas Ferre wrote:
By making DMA controllers register a generic translation
function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be implemented
by the DMA controller can carry any type of dma-request argument.
The DMA client will search its associated DMA controller in the list
and call the registered of_dam_xlate() function to retrieve the
request values.
One simple xlate function is provided for the single number type
of request biding.
This implementation is independent from dmaengine so it can also be
used by legacy drivers.
Signed-off-by: Nicolas Ferrenicolas.fe...@atmel.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Stephen Warrenswar...@nvidia.com
Cc: Grant Likelygrant.lik...@secretlab.ca
Cc: Russell Kingli...@arm.linux.org.uk
Cc: Rob Herringrob.herr...@calxeda.com
---
Hi all,
Here are my thoughts about the DMA helpers for device tree.
This patch goes on top of Benoit's ones. My goal was to keep this separated
from any DMA infrastructure (dmaengine not needed, nor any other DMA
implementation).
Thanks for taking the ball on that.
It is to keep the ball rolling, so do not hesitate to comment.
That looks pretty good.
My only question to the whole audience who care about that is:
Do we want to enforce the usage of dmaengine and thus add the DT support
into dmaengine or do we want to go add some infrastructure in DT core
like it is done here?
To be honest, I'm fine with that approach because OMAP DMA is still not
using dmaengine. But potentially I can easily add a dummy dmaengine into
the OMAP DMA driver just to support the OF code if needed.
Documentation/devicetree/bindings/dma/dma.txt | 29 +++--
drivers/of/dma.c | 161 ++---
include/linux/of_dma.h| 33 +-
3 files changed, 186 insertions(+), 37 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
index 7f2a301..c49e98d 100644
--- a/Documentation/devicetree/bindings/dma/dma.txt
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -6,9 +6,8 @@ DMA request line that goes from an IP to a DMA controller.
* DMA controller
-Required properties:
-- dma-controller: Mark the device as a DMA controller
-- #dma-cells: Number of cell for each DMA line, must be one.
+Required property:
+- #dma-cells: Number of cells for each DMA line.
Example:
@@ -17,7 +16,6 @@ Example:
compatible = ti,sdma-omap4
reg =0x4800 0x1000;
interrupts =12;
-dma-controller;
#dma-cells =1;
};
@@ -25,20 +23,23 @@ Example:
* DMA client
-Client drivers should specify the DMA request numbers using a phandle to
-the controller + the DMA request number on that controller.
+Client drivers should specify the DMA request property using a phandle to
+the controller. If needed, the DMA request identity on that controller is then
+added followed by optional request specifications.
-Required properties:
-- dma-request: List of pair phandle + dma-request per line
+Required property:
+- dma-request: List of phandle + dma-request + request specifications,
+ one group per request line.
+Optional property:
- dma-request-names: list of strings in the same order as the dma-request
in the dma-request property.
Example:
-i2c1: i2c@1 {
-...
-dma-request =sdma 2sdma 3;
-dma-request-names = tx, rx;
-...
-};
+ i2c1: i2c@1 {
+ ...
+ dma-request =sdma 2sdma 3;
+ dma-request-names = tx, rx;
+ ...
+ };
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
index d4927e2..e0c6fd9 100644
--- a/drivers/of/dma.c
+++ b/drivers/of/dma.c
@@ -13,41 +13,145 @@
#includelinux/device.h
#includelinux/err.h
#includelinux/module.h
+#includelinux/rculist.h
+#includelinux/slab.h
#includelinux/of.h
#includelinux/of_dma.h
+static LIST_HEAD(of_dma_list);
+
+/**
+ * of_dma_find_controller() - Find a DMA controller in DT DMA helpers list
+ * @np:device node of DMA controller
+ */
+static struct of_dma *of_dma_find_controller(struct device_node *np)
+{
+ struct of_dma *ofdma;
+
+ list_for_each_entry_rcu(ofdma,of_dma_list, of_dma_controllers) {
+ if (ofdma-of_node == np)
+ return ofdma;
+ }
+
+ return NULL;
+}
+
/**
- * of_get_dma_request() - Get a DMA request number and dma-controller node
+ * of_dma_controller_register() - Register a DMA controller to DT DMA helpers
+ * @np:device node of DMA controller
+ * @of_dma_xlate: generic translation function which converts a phandle
+ * arguments list into a generic output value
+ *
+ * Returns 0 on success or appropriate errno value
[PATCH] omap3_beagle: Init only uart3 used for console
From: Govindraj.R govindraj.r...@ti.com
On beagle some of uart mux lines are used for other
purpose so init only uart3.
Uart2 rx line clashes with gpio_147 used for usb ehci
phy reset. Initializing uart2 pad_mux lines can break
ehci module on beagle xm.
(gpio_147 is available on uart2_rx in mode4 reference
mux34xx.c - uart2_rx.gpio_147)
Cc: Tony Lindgren t...@atomide.com
Cc: Kevin Hilman khil...@ti.com
Tested-by: Peter Ujfalusi peter.ujfal...@ti.com
Tested-by: Robert Nelson robertcnel...@gmail.com
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/board-omap3beagle.c | 50 ++-
1 files changed, 49 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 817be06..a2e0052 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -493,6 +493,54 @@ static const struct usbhs_omap_board_data usbhs_bdata
__initconst = {
static struct omap_board_mux board_mux[] __initdata = {
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
+
+static struct omap_device_pad uart3_pads[] __initdata = {
+ {
+ .name = uart3_cts_rctx.uart3_cts_rctx,
+ .enable = OMAP_PIN_INPUT_PULLUP | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart3_rts_sd.uart3_rts_sd,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart3_tx_irtx.uart3_tx_irtx,
+ .enable = OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+ },
+ {
+ .name = uart3_rx_irrx.uart3_rx_irrx,
+ .flags = OMAP_DEVICE_PAD_REMUX | OMAP_DEVICE_PAD_WAKEUP,
+ .enable = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+ .idle = OMAP_PIN_INPUT | OMAP_MUX_MODE0,
+ },
+};
+
+static inline void board_serial_init(void)
+{
+ struct omap_board_data uart3_bdata;
+ uart3_bdata.flags = 0;
+ uart3_bdata.pads = uart3_pads;
+ uart3_bdata.pads_cnt = ARRAY_SIZE(uart3_pads);
+ uart3_bdata.id= 2;
+
+ /*
+* Init only uart3 used as console
+* don't init other uarts as uart mux lines
+* might be used for other purpose on beagle board
+* ex: uart2_rx used by gpio_147 for usb_ehci phy reset.
+*/
+ omap_serial_init_port(uart3_bdata, NULL);
+}
+#else
+
+/*
+ * If mux is disabled from kernel probably we
+ * are relying on boot-loaders so we init all uarts
+ */
+static inline void board_serial_init(void)
+{
+ omap_serial_init();
+}
#endif
static void __init beagle_opp_init(void)
@@ -549,7 +597,7 @@ static void __init omap3_beagle_init(void)
platform_add_devices(omap3_beagle_devices,
ARRAY_SIZE(omap3_beagle_devices));
omap_display_init(beagle_dss_data);
- omap_serial_init();
+ board_serial_init();
omap_sdrc_init(mt46h32m32lf6_sdrc_params,
mt46h32m32lf6_sdrc_params);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ARM: OMAP: USB: fix the pointer type mismatch compilation warning
From: Keshava Munegowda keshava_mgo...@ti.com
The compilation of usb-host.c file was resulting compilation warning
due to pointer type mismatch in assignment of return pointer type
of the function omap_device_build_ss to local pointer type.
This warning is fixed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 771dc78..88d4a19 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -486,7 +486,7 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
struct omap_hwmod *oh[2];
- struct omap_device *od;
+ struct platform_device *od;
int bus_id = -1;
int i;
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: USB: fix the pointer type mismatch compilation warning
On Mon, Mar 5, 2012 at 4:49 PM, Keshava Munegowda keshava_mgo...@ti.com wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The compilation of usb-host.c file was resulting compilation warning
due to pointer type mismatch in assignment of return pointer type
of the function omap_device_build_ss to local pointer type.
This warning is fixed.
Its fixed already.
https://lkml.org/lkml/2012/2/14/73
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 771dc78..88d4a19 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -486,7 +486,7 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
struct omap_hwmod *oh[2];
- struct omap_device *od;
+ struct platform_device *od;
int bus_id = -1;
int i;
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: USB: fix the pointer type mismatch compilation warning
On Mon, Mar 5, 2012 at 4:53 PM, Govindraj govindraj...@gmail.com wrote:
On Mon, Mar 5, 2012 at 4:49 PM, Keshava Munegowda keshava_mgo...@ti.com
wrote:
From: Keshava Munegowda keshava_mgo...@ti.com
The compilation of usb-host.c file was resulting compilation warning
due to pointer type mismatch in assignment of return pointer type
of the function omap_device_build_ss to local pointer type.
This warning is fixed.
Its fixed already.
https://lkml.org/lkml/2012/2/14/73
Thanks ; it by Felipe :)
regards
keshava
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 771dc78..88d4a19 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -486,7 +486,7 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
struct omap_hwmod *oh[2];
- struct omap_device *od;
+ struct platform_device *od;
int bus_id = -1;
int i;
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: Ethernet problems on AM3517, possible regression?
On 03/04/12 11:41, Igor Grinberg wrote: Hi, On 03/02/12 01:16, CF Adad wrote: We have both a CompuLab CM-T3517 and a Technexion TAM-3517 at the shop. Both boards provide dual Ethernet support in an identical fashion. One port uses the onboard EMAC tied to an SMSC LAN87xx series PHY. The other is the old trusty SMSC LAN911X hooked up to the GPMC. Both boards support both interfaces when loaded with their respective TI PSP-based images. These unfortunately date clear back to 2.6.37 or even 2.6.32 however. When upgrading to the 3.x series linux-omap kernel, we noticed we could get one or the other of these to work, _but not both simultaneously_. If both are enabled in code, neither work. Even when we can get one or the other working, we seem to be having some problems with autonegotiation and MAC addressing. MAC addresses on the SMSC are still random. On the EMAC port, as you can see from our code below, we have put a patch in that is letting us establish a fixed MAC address. However, I'm not sure this is a proper method to use at this point. We suspect issues are known to exist with the Ethernet ports as the CM-T3517 has mainlined Linux support, and its latest board file does not show any configuration for either Ethernet interface. Support from the previous kernel versions has apparently been removed, despite patches being applied to it as recently as mid-last year: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050430.html We also suspect this is being caused by an address conflict of some sort between the two ports. We are using a linux-omap kernel, version 3.2.0-rc6 that is a month or two old now. We've been monitoring this list, and have noted that some changes have been checked in for SMSC, but have not been able to update our kernel source as we were in the midst of a heavy debugging exercise that ended late last evening. We plan to migrate to the latest HEAD soon. Neverthelss, we've not seen any of these board files update. So, we're assuming there are still known issues here. I have attached the relevant sections of the board file we've created for the TAM-3517 (the one we've played with the most) below. It is based off the older board files from the TI PSP and various configurations we have seen in similar hardware board files (overo, am3517_evm, cm-t3517, etc.) If you note the configurable defines at the top, we've tied various combinations of code with no success to date. Would you folks please take a look? Any help would be appreciated. Thanks! The below two patches are needed to make the AM3517 EMAC work on CM-T3517: http://www.spinics.net/lists/linux-omap/msg65642.html http://www.spinics.net/lists/linux-omap/msg65643.html Hopefully, Tony will be kind enough to apply those for 3.4 Also, this one is needed for EMAC to function on any OMAP board: http://www.spinics.net/lists/linux-omap/msg62161.html It looks from the thread, that it has been already taken by Paul, so hopefully, it will be in 3.4 -- Regards, Igor. -- 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: USB: fix the pointer type mismatch compilation warning
Hello.
On 05-03-2012 15:19, Keshava Munegowda wrote:
From: Keshava Munegowdakeshava_mgo...@ti.com
The compilation of usb-host.c file was resulting compilation warning
due to pointer type mismatch in assignment of return pointer type
of the function omap_device_build_ss to local pointer type.
This warning is fixed.
Signed-off-by: Keshava Munegowdakeshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index 771dc78..88d4a19 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -486,7 +486,7 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
struct omap_hwmod *oh[2];
- struct omap_device *od;
+ struct platform_device *od;
Makes sense to rename variable to 'pd' then.
WBR, Sergei
--
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: [RFC PATCH] of: DMA helpers: manage generic requests specification
On 2/29/2012 9:54 PM, Stephen Warren wrote:
Nicolas Ferre wrote at Wednesday, February 29, 2012 7:54 AM:
By making DMA controllers register a generic translation
function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be implemented
by the DMA controller can carry any type of dma-request argument.
The DMA client will search its associated DMA controller in the list
and call the registered of_dam_xlate() function to retrieve the
request values.
One simple xlate function is provided for the single number type
of request biding.
This implementation is independent from dmaengine so it can also be
used by legacy drivers.
At a high level this seems along the right lines.
The big issue I see is the lack of type-safety in of_get_dma_request()'s
out_data pointer: The DMA xlate function will assume it points at some
particular type, and the client is responsible for allocating that
correct type. However, it's user-supplied device tree data that hooks
the two together, and there could easily be mismatches, thus causing
the xlate function to trash memory.
Could each DMA controller (or type of out_data) have some enum in the
kernel that the client passes in, and the DMA engine validates matches
its expectations, to prevent this kind of thing?
Beside u32 and string, do we know what kind of parameters we can expect
to retrieve?
Because we can potentially reduce the scope to these two types only.
enum DMA_PARAMS_TYPE {
FOO_DMA_PARAMS,
BAR_DMA_PARAMS,
...
};
struct foo_dma_params { ... };
struct foo_dma_params params;
of_get_dma_request(np, 0,params, FOO_DMA_PARAMS);
and inside xlate():
if (params_type != FOO_DMA_PARAMS)
return -EINVAL;
For the dmaengine case, I assume there'd be a single DMA_PARAMS_TYPE
value for the dmaengine specifier type, and the dmaengine core would
take care of making sure everything matched somehow.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: USB: fix the pointer type mismatch compilation warning
On Mon, Mar 5, 2012 at 5:13 PM, Sergei Shtylyov sshtyl...@mvista.com wrote:
Hello.
On 05-03-2012 15:19, Keshava Munegowda wrote:
From: Keshava Munegowdakeshava_mgo...@ti.com
The compilation of usb-host.c file was resulting compilation warning
due to pointer type mismatch in assignment of return pointer type
of the function omap_device_build_ss to local pointer type.
This warning is fixed.
Signed-off-by: Keshava Munegowdakeshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c
b/arch/arm/mach-omap2/usb-host.c
index 771dc78..88d4a19 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -486,7 +486,7 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
struct omap_hwmod *oh[2];
- struct omap_device *od;
+ struct platform_device *od;
Makes sense to rename variable to 'pd' then.
WBR, Sergei
ya, and its already in mainline :)
regards
keshava
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: IRQ domain support for INTC
On Wed, Feb 29, 2012 at 05:15:25PM +0100, Cousson, Benoit wrote: On 2/29/2012 12:48 AM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [120227 08:04]: Hi Tony This series is based on the lo/dt + the irqdomain/next branch merged on top of it. Grant confirmed that the irqdomain/next is a stable branch and thus can be referenced for dependency. Please note that I will need that branch to base all the remaining OMAP DT stuff. Thanks, Benoit The following changes since commit 1f52299ec000e2161635b263d81ab92ea7f1f0a7: Benoit Cousson (1): Merge branch 'irqdomain/next' of git://git.secretlab.ca/git/linux-2.6 into for_3.4/dt_irq_domain2 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.4/dt_irq_domain Benoit Cousson (3): ARM: OMAP2/3: intc: Add DT support for TI interrupt controller arm/dts: OMAP3: Add interrupt-controller bindings for INTC ARM: OMAP2+: board-generic: Use of_irq_init API .../devicetree/bindings/arm/omap/intc.txt | 27 + arch/arm/boot/dts/omap3.dtsi |6 +- arch/arm/mach-omap2/board-generic.c| 30 +- arch/arm/mach-omap2/common.h | 12 arch/arm/mach-omap2/irq.c | 60 --- 5 files changed, 109 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt Hmm, looks like this now produces the following warning at least on omap3: Yes, Rajendra has just reported that issue with linux-next. I'm getting the same warning and initialisation failure with 3.3-rc6 on overo. Are these fixes queued up for 3.3 (and not just 3.4) somewhere? Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: IRQ domain support for INTC
On 3/5/2012 2:58 PM, Johan Hovold wrote: On Wed, Feb 29, 2012 at 05:15:25PM +0100, Cousson, Benoit wrote: On 2/29/2012 12:48 AM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [120227 08:04]: Hi Tony This series is based on the lo/dt + the irqdomain/next branch merged on top of it. Grant confirmed that the irqdomain/next is a stable branch and thus can be referenced for dependency. Please note that I will need that branch to base all the remaining OMAP DT stuff. Thanks, Benoit The following changes since commit 1f52299ec000e2161635b263d81ab92ea7f1f0a7: Benoit Cousson (1): Merge branch 'irqdomain/next' of git://git.secretlab.ca/git/linux-2.6 into for_3.4/dt_irq_domain2 are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.4/dt_irq_domain Benoit Cousson (3): ARM: OMAP2/3: intc: Add DT support for TI interrupt controller arm/dts: OMAP3: Add interrupt-controller bindings for INTC ARM: OMAP2+: board-generic: Use of_irq_init API .../devicetree/bindings/arm/omap/intc.txt | 27 + arch/arm/boot/dts/omap3.dtsi |6 +- arch/arm/mach-omap2/board-generic.c| 30 +- arch/arm/mach-omap2/common.h | 12 arch/arm/mach-omap2/irq.c | 60 --- 5 files changed, 109 insertions(+), 26 deletions(-) create mode 100644 Documentation/devicetree/bindings/arm/omap/intc.txt Hmm, looks like this now produces the following warning at least on omap3: Yes, Rajendra has just reported that issue with linux-next. I'm getting the same warning and initialisation failure with 3.3-rc6 on overo. Are these fixes queued up for 3.3 (and not just 3.4) somewhere? It is under review, I posted the series last Friday: mfd: twl: Fix for irqdomain/next + SPARSE_IRQ + MMC card detect It will be anyway material for 3.4 since it is in linux-next. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/5] ARM: OMAP: TLL driver implementation for USB host driver
From: Keshava Munegowda keshava_mgo...@ti.com The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. The TLL is an has independent hardware mod structure for in OMAP3 and later chips, hence an dedicated platform driver is created. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Keshava Munegowda (5): ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Build the USB HOST TLL omap device ARM: OMAP: USB: Remove TLL specific code ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: change the USB TLL clocks device name arch/arm/mach-omap2/clock3xxx_data.c |8 +- arch/arm/mach-omap2/clock44xx_data.c |4 +- arch/arm/mach-omap2/usb-host.c| 28 ++- arch/arm/plat-omap/include/plat/usb.h |9 + drivers/mfd/Kconfig |2 +- drivers/mfd/Makefile |2 +- drivers/mfd/omap-usb-host.c | 232 + drivers/mfd/omap-usb-tll.c| 463 + 8 files changed, 513 insertions(+), 235 deletions(-) create mode 100644 drivers/mfd/omap-usb-tll.c -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] ARM: OMAP: USB: Remove TLL specific code
From: Keshava Munegowda keshava_mgo...@ti.com
The TLL specific code such as channels clocks enable/disable,
initialization functions are removed from the USBHS core
driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
drivers/mfd/omap-usb-host.c | 225 ++-
1 files changed, 8 insertions(+), 217 deletions(-)
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 9927129..4de87c6 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -34,63 +34,6 @@
/* OMAP USBHOST Register addresses */
-/* TLL Register Set */
-#defineOMAP_USBTLL_REVISION(0x00)
-#defineOMAP_USBTLL_SYSCONFIG (0x10)
-#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8)
-#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
-#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2)
-#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1)
-#defineOMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0)
-
-#defineOMAP_USBTLL_SYSSTATUS (0x14)
-#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 0)
-
-#defineOMAP_USBTLL_IRQSTATUS (0x18)
-#defineOMAP_USBTLL_IRQENABLE (0x1C)
-
-#defineOMAP_TLL_SHARED_CONF(0x30)
-#defineOMAP_TLL_SHARED_CONF_USB_90D_DDR_EN (1 6)
-#defineOMAP_TLL_SHARED_CONF_USB_180D_SDR_EN(1 5)
-#defineOMAP_TLL_SHARED_CONF_USB_DIVRATION (1 2)
-#defineOMAP_TLL_SHARED_CONF_FCLK_REQ (1 1)
-#defineOMAP_TLL_SHARED_CONF_FCLK_IS_ON (1 0)
-
-#defineOMAP_TLL_CHANNEL_CONF(num) (0x040 + 0x004
* num)
-#define OMAP_TLL_CHANNEL_CONF_FSLSMODE_SHIFT 24
-#defineOMAP_TLL_CHANNEL_CONF_ULPINOBITSTUFF(1 11)
-#defineOMAP_TLL_CHANNEL_CONF_ULPI_ULPIAUTOIDLE (1 10)
-#defineOMAP_TLL_CHANNEL_CONF_UTMIAUTOIDLE (1 9)
-#defineOMAP_TLL_CHANNEL_CONF_ULPIDDRMODE (1 8)
-#define OMAP_TLL_CHANNEL_CONF_CHANMODE_FSLS(1 1)
-#defineOMAP_TLL_CHANNEL_CONF_CHANEN(1 0)
-
-#define OMAP_TLL_FSLSMODE_6PIN_PHY_DAT_SE0 0x0
-#define OMAP_TLL_FSLSMODE_6PIN_PHY_DP_DM 0x1
-#define OMAP_TLL_FSLSMODE_3PIN_PHY 0x2
-#define OMAP_TLL_FSLSMODE_4PIN_PHY 0x3
-#define OMAP_TLL_FSLSMODE_6PIN_TLL_DAT_SE0 0x4
-#define OMAP_TLL_FSLSMODE_6PIN_TLL_DP_DM 0x5
-#define OMAP_TLL_FSLSMODE_3PIN_TLL 0x6
-#define OMAP_TLL_FSLSMODE_4PIN_TLL 0x7
-#define OMAP_TLL_FSLSMODE_2PIN_TLL_DAT_SE0 0xA
-#define OMAP_TLL_FSLSMODE_2PIN_DAT_DP_DM 0xB
-
-#defineOMAP_TLL_ULPI_FUNCTION_CTRL(num)(0x804 + 0x100
* num)
-#defineOMAP_TLL_ULPI_INTERFACE_CTRL(num) (0x807 + 0x100
* num)
-#defineOMAP_TLL_ULPI_OTG_CTRL(num) (0x80A + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_EN_RISE(num) (0x80D + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_EN_FALL(num) (0x810 + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_STATUS(num) (0x813 + 0x100
* num)
-#defineOMAP_TLL_ULPI_INT_LATCH(num)(0x814 + 0x100
* num)
-#defineOMAP_TLL_ULPI_DEBUG(num)(0x815 + 0x100
* num)
-#defineOMAP_TLL_ULPI_SCRATCH_REGISTER(num) (0x816 + 0x100
* num)
-
-#define OMAP_TLL_CHANNEL_COUNT 3
-#define OMAP_TLL_CHANNEL_1_EN_MASK (1 0)
-#define OMAP_TLL_CHANNEL_2_EN_MASK (1 1)
-#define OMAP_TLL_CHANNEL_3_EN_MASK (1 2)
-
/* UHH Register Set */
#defineOMAP_UHH_REVISION (0x00)
#defineOMAP_UHH_SYSCONFIG (0x10)
@@ -130,8 +73,6 @@
#define OMAP4_P2_MODE_TLL (1 18)
#define OMAP4_P2_MODE_HSIC (3 18)
-#define OMAP_REV2_TLL_CHANNEL_COUNT2
-
#defineOMAP_UHH_DEBUG_CSR (0x44)
/* Values of UHH_REVISION - Note: these are not given in the TRM */
@@ -151,15 +92,12 @@ struct usbhs_hcd_omap {
struct clk *xclk60mhsp2_ck;
struct clk *utmi_p1_fck;
struct clk *usbhost_p1_fck;
- struct clk *usbtll_p1_fck;
struct clk *utmi_p2_fck;
struct clk *usbhost_p2_fck;
-
[PATCH 1/5] ARM: OMAP: USB: HOST TLL platform driver
From: Keshava Munegowda keshava_mgo...@ti.com
The platform driver for the TLL component of the OMAP USB host controller
is implemented. Depending on the TLL hardware revision , the TLL channels
are configured. The USB HS core driver uses this driver through exported
APIs from the TLL platform driver.
usb_tll_enable and usb_tll_disble are the exported APIs of the USB TLL
platform driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h |8 +
drivers/mfd/Kconfig |2 +-
drivers/mfd/Makefile |2 +-
drivers/mfd/omap-usb-tll.c| 463 +
4 files changed, 473 insertions(+), 2 deletions(-)
create mode 100644 drivers/mfd/omap-usb-tll.c
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index dc864b5..eb1e47d 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -61,6 +61,10 @@ struct usbhs_omap_platform_data {
struct ehci_hcd_omap_platform_data *ehci_data;
struct ohci_hcd_omap_platform_data *ohci_data;
};
+
+struct usbtll_omap_platform_data {
+ enum usbhs_omap_port_mode port_mode[OMAP3_HS_USB_PORTS];
+};
/*-*/
#define OMAP1_OTG_BASE 0xfffb0400
@@ -105,6 +109,10 @@ extern int omap4430_phy_set_clk(struct device *dev, int
on);
extern int omap4430_phy_init(struct device *dev);
extern int omap4430_phy_exit(struct device *dev);
extern int omap4430_phy_suspend(struct device *dev, int suspend);
+
+extern int omap_tll_enable(void);
+extern int omap_tll_disable(void);
+
#endif
extern void am35x_musb_reset(void);
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index f147395..5f75ad4 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -772,7 +772,7 @@ config MFD_WL1273_CORE
audio codec.
config MFD_OMAP_USB_HOST
- bool Support OMAP USBHS core driver
+ bool Support OMAP USBHS core and TLL driver
depends on USB_EHCI_HCD_OMAP || USB_OHCI_HCD_OMAP3
default y
help
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index b953bab..4b3a8e0 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -105,7 +105,7 @@ obj-$(CONFIG_MFD_TPS6586X) += tps6586x.o
obj-$(CONFIG_MFD_VX855)+= vx855.o
obj-$(CONFIG_MFD_WL1273_CORE) += wl1273-core.o
obj-$(CONFIG_MFD_CS5535) += cs5535-mfd.o
-obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o
+obj-$(CONFIG_MFD_OMAP_USB_HOST)+= omap-usb-host.o omap-usb-tll.o
obj-$(CONFIG_MFD_PM8921_CORE) += pm8921-core.o
obj-$(CONFIG_MFD_PM8XXX_IRQ) += pm8xxx-irq.o
obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
diff --git a/drivers/mfd/omap-usb-tll.c b/drivers/mfd/omap-usb-tll.c
new file mode 100644
index 000..3da468a
--- /dev/null
+++ b/drivers/mfd/omap-usb-tll.c
@@ -0,0 +1,463 @@
+/**
+ * omap-usb-tll.c - The USB TLL driver for OMAP EHCI OHCI
+ *
+ * Copyright (C) 2011 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Keshava Munegowda keshava_mgo...@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 of
+ * the License as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+#include linux/kernel.h
+#include linux/module.h
+#include linux/types.h
+#include linux/slab.h
+#include linux/spinlock.h
+#include linux/platform_device.h
+#include linux/clk.h
+#include linux/io.h
+#include linux/err.h
+#include plat/usb.h
+#include linux/pm_runtime.h
+
+#define USBTLL_DRIVER_NAME usbhs_tll
+
+/* TLL Register Set */
+#defineOMAP_USBTLL_REVISION(0x00)
+#defineOMAP_USBTLL_SYSCONFIG (0x10)
+#defineOMAP_USBTLL_SYSCONFIG_CACTIVITY (1 8)
+#defineOMAP_USBTLL_SYSCONFIG_SIDLEMODE (1 3)
+#defineOMAP_USBTLL_SYSCONFIG_ENAWAKEUP (1 2)
+#defineOMAP_USBTLL_SYSCONFIG_SOFTRESET (1 1)
+#defineOMAP_USBTLL_SYSCONFIG_AUTOIDLE (1 0)
+
+#defineOMAP_USBTLL_SYSSTATUS (0x14)
+#defineOMAP_USBTLL_SYSSTATUS_RESETDONE (1 0)
+
+#defineOMAP_USBTLL_IRQSTATUS (0x18)
+#defineOMAP_USBTLL_IRQENABLE
[PATCH 5/5] ARM: OMAP: change the USB TLL clocks device name
From: Keshava Munegowda keshava_mgo...@ti.com
The platform device name for the functional, interface and
channel clocks of the TLL module is changed from usbhs device
to usb tll platform device name.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/clock3xxx_data.c |8
arch/arm/mach-omap2/clock44xx_data.c |4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/clock3xxx_data.c
b/arch/arm/mach-omap2/clock3xxx_data.c
index d75e5f6..9fd2242 100644
--- a/arch/arm/mach-omap2/clock3xxx_data.c
+++ b/arch/arm/mach-omap2/clock3xxx_data.c
@@ -3297,7 +3297,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, cpefuse_fck, cpefuse_fck, CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, ts_fck, ts_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, usbtll_fck, usbtll_fck,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs_omap, usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_tll,usbtll_fck, usbtll_fck,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap-mcbsp.1, prcm_fck, core_96m_fck, CK_3XXX),
CLK(omap-mcbsp.5, prcm_fck, core_96m_fck, CK_3XXX),
CLK(NULL, core_96m_fck, core_96m_fck, CK_3XXX),
@@ -,7 +,7 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(NULL, pka_ick, pka_ick, CK_34XX | CK_36XX),
CLK(NULL, core_l4_ick, core_l4_ick, CK_3XXX),
CLK(NULL, usbtll_ick, usbtll_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
- CLK(usbhs_omap, usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
+ CLK(usbhs_tll,usbtll_ick, usbtll_ick,CK_3430ES2PLUS
| CK_AM35XX | CK_36XX),
CLK(omap_hsmmc.2, ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
@@ -3388,9 +3388,9 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(usbhs_omap, xclk60mhsp2_ck, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, usb_host_hs_utmi_p1_clk, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, usb_host_hs_utmi_p2_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
- CLK(usbhs_omap, usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
CLK(usbhs_omap, init_60m_fclk,dummy_ck,
CK_3XXX),
+ CLK(usbhs_tll,usb_tll_hs_usb_ch0_clk, dummy_ck,
CK_3XXX),
+ CLK(usbhs_tll,usb_tll_hs_usb_ch1_clk, dummy_ck,
CK_3XXX),
CLK(NULL, usim_fck, usim_fck, CK_3430ES2PLUS |
CK_36XX),
CLK(NULL, gpt1_fck, gpt1_fck, CK_3XXX),
CLK(NULL, wkup_32k_fck, wkup_32k_fck, CK_3XXX),
diff --git a/arch/arm/mach-omap2/clock44xx_data.c
b/arch/arm/mach-omap2/clock44xx_data.c
index 08e86d7..3b6cf13 100644
--- a/arch/arm/mach-omap2/clock44xx_data.c
+++ b/arch/arm/mach-omap2/clock44xx_data.c
@@ -3323,7 +3323,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, usb_tll_hs_usb_ch2_clk,
usb_tll_hs_usb_ch2_clk,CK_443X),
CLK(NULL, usb_tll_hs_usb_ch0_clk,
usb_tll_hs_usb_ch0_clk,CK_443X),
CLK(NULL, usb_tll_hs_usb_ch1_clk,
usb_tll_hs_usb_ch1_clk,CK_443X),
- CLK(usbhs_omap, usbtll_ick, usb_tll_hs_ick,
CK_443X),
+ CLK(usbhs_tll,usbtll_ick, usb_tll_hs_ick,
CK_443X),
CLK(NULL, usim_ck, usim_ck,
CK_443X),
CLK(NULL, usim_fclk,usim_fclk,
CK_443X),
CLK(NULL, usim_fck, usim_fck,
CK_443X),
@@ -3384,7 +3384,7 @@ static struct omap_clk omap44xx_clks[] = {
CLK(NULL, uart3_ick,dummy_ck,
CK_443X),
CLK(NULL, uart4_ick,dummy_ck,
CK_443X),
CLK(usbhs_omap, usbhost_ick, dummy_ck,
CK_443X),
- CLK(usbhs_omap, usbtll_fck, dummy_ck,
CK_443X),
+ CLK(usbhs_tll,usbtll_fck, dummy_ck,
CK_443X),
CLK(omap_wdt, ick, dummy_ck,
CK_443X),
CLK(omap_timer.1, 32k_ck, sys_32k_ck,CK_443X),
CLK(omap_timer.2, 32k_ck, sys_32k_ck,CK_443X),
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/5] ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver
From: Keshava Munegowda keshava_mgo...@ti.com
The usbhs driver invokes the enable/disable APIs of the
usb tll driver in the runtime resume/suspend callbacks
of the runtime get sync and put sync of the usbhs driver.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/plat-omap/include/plat/usb.h |1 +
drivers/mfd/omap-usb-host.c |7 +--
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/usb.h
b/arch/arm/plat-omap/include/plat/usb.h
index eb1e47d..3b8f139 100644
--- a/arch/arm/plat-omap/include/plat/usb.h
+++ b/arch/arm/plat-omap/include/plat/usb.h
@@ -3,6 +3,7 @@
#ifndef__ASM_ARCH_OMAP_USB_H
#define__ASM_ARCH_OMAP_USB_H
+#include linux/platform_device.h
#include linux/usb/musb.h
#include plat/board.h
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 4de87c6..9d84339 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -21,7 +21,6 @@
#include linux/types.h
#include linux/slab.h
#include linux/delay.h
-#include linux/platform_device.h
#include linux/clk.h
#include linux/dma-mapping.h
#include linux/spinlock.h
@@ -285,6 +284,7 @@ static int usbhs_runtime_resume(struct device *dev)
return -ENODEV;
}
+ omap_tll_enable();
spin_lock_irqsave(omap-lock, flags);
if (omap-ehci_logic_fck !IS_ERR(omap-ehci_logic_fck))
@@ -330,6 +330,7 @@ static int usbhs_runtime_suspend(struct device *dev)
clk_disable(omap-ehci_logic_fck);
spin_unlock_irqrestore(omap-lock, flags);
+ omap_tll_disable();
return 0;
}
@@ -655,8 +656,10 @@ static int __init omap_usbhs_drvinit(void)
* init before ehci and ohci drivers;
* The usbhs core driver should be initialized much before
* the omap ehci and ohci probe functions are called.
+ * this usbhs core driver should be initialized after
+ * usb tll driver.
*/
-fs_initcall(omap_usbhs_drvinit);
+fs_initcall_sync(omap_usbhs_drvinit);
static void __exit omap_usbhs_drvexit(void)
{
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/5] ARM: OMAP: USB: Build the USB HOST TLL omap device
From: Keshava Munegowda keshava_mgo...@ti.com
The hwmod of the usb tll is retrieved and omap device build is
performed to created the platform device for the usb tll component.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
Reviewed-by: Partha Basak part...@india.ti.com
---
arch/arm/mach-omap2/usb-host.c | 28
1 files changed, 20 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index f51348d..dc6769a 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -35,10 +35,12 @@
#ifdef CONFIG_MFD_OMAP_USB_HOST
#define OMAP_USBHS_DEVICE usbhs_omap
+#define OMAP_USBTLL_DEVICE usbhs_tll
#defineUSBHS_UHH_HWMODNAME usb_host_hs
#define USBHS_TLL_HWMODNAMEusb_tll_hs
static struct usbhs_omap_platform_data usbhs_data;
+static struct usbtll_omap_platform_datausbtll_data;
static struct ehci_hcd_omap_platform_data ehci_data;
static struct ohci_hcd_omap_platform_data ohci_data;
@@ -485,7 +487,7 @@ static void setup_4430ohci_io_mux(const enum
usbhs_omap_port_mode *port_mode)
void __init usbhs_init(const struct usbhs_omap_board_data *pdata)
{
- struct omap_hwmod *oh[2];
+ struct omap_hwmod *uhh_hwm, *tll_hwm;
struct platform_device *pdev;
int bus_id = -1;
int i;
@@ -510,25 +512,35 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
setup_4430ohci_io_mux(pdata-port_mode);
}
- oh[0] = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
- if (!oh[0]) {
+ uhh_hwm = omap_hwmod_lookup(USBHS_UHH_HWMODNAME);
+ if (!uhh_hwm) {
pr_err(Could not look up %s\n, USBHS_UHH_HWMODNAME);
return;
}
- oh[1] = omap_hwmod_lookup(USBHS_TLL_HWMODNAME);
- if (!oh[1]) {
+ tll_hwm = omap_hwmod_lookup(USBHS_TLL_HWMODNAME);
+ if (!tll_hwm) {
pr_err(Could not look up %s\n, USBHS_TLL_HWMODNAME);
return;
}
- pdev = omap_device_build_ss(OMAP_USBHS_DEVICE, bus_id, oh, 2,
+ pdev = omap_device_build(OMAP_USBTLL_DEVICE, bus_id, tll_hwm,
+ (void *)usbtll_data, sizeof(usbtll_data),
+ omap_uhhtll_latency,
+ ARRAY_SIZE(omap_uhhtll_latency), false);
+ if (IS_ERR(pdev)) {
+ pr_err(Could not build hwmod device %s\n,
+ USBHS_TLL_HWMODNAME);
+ return;
+ }
+
+ pdev = omap_device_build(OMAP_USBHS_DEVICE, bus_id, uhh_hwm,
(void *)usbhs_data, sizeof(usbhs_data),
omap_uhhtll_latency,
ARRAY_SIZE(omap_uhhtll_latency), false);
if (IS_ERR(pdev)) {
- pr_err(Could not build hwmod devices %s,%s\n,
- USBHS_UHH_HWMODNAME, USBHS_TLL_HWMODNAME);
+ pr_err(Could not build hwmod devices %s\n,
+ USBHS_UHH_HWMODNAME);
return;
}
}
--
1.6.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: fix iommu, not mailbox
On Sun, Mar 04, 2012 at 12:01:11PM +0200, Ohad Ben-Cohen wrote: For some weird (freudian?) reason, commit 435792d ARM: OMAP: make iommu subsys_initcall to fix builtin omap3isp unintentionally changed the mailbox's initcall instead of the iommu's. Fix that. Applied, thanks. -- AMD Operating System Research Center Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach General Managers: Alberto Bozzo Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] ARM: OMAP: TLL driver implementation for USB host driver
On Mon, Mar 5, 2012 at 8:01 PM, Keshava Munegowda keshava_mgo...@ti.com wrote: From: Keshava Munegowda keshava_mgo...@ti.com The TLL configuration is removed from the UHH driver and implemented as a seperate platform driver. Now, the UHH driver configures the TLL through API's exported by the TLL platform driver. The TLL is an has independent hardware mod structure for in OMAP3 and later chips, hence an dedicated platform driver is created. Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com Keshava Munegowda (5): ARM: OMAP: USB: HOST TLL platform driver ARM: OMAP: USB: Build the USB HOST TLL omap device ARM: OMAP: USB: Remove TLL specific code ARM: OMAP: USB: Invoke the TLL driver from USB HS core driver ARM: OMAP: change the USB TLL clocks device name arch/arm/mach-omap2/clock3xxx_data.c | 8 +- arch/arm/mach-omap2/clock44xx_data.c | 4 +- arch/arm/mach-omap2/usb-host.c | 28 ++- arch/arm/plat-omap/include/plat/usb.h | 9 + drivers/mfd/Kconfig | 2 +- drivers/mfd/Makefile | 2 +- drivers/mfd/omap-usb-host.c | 232 + drivers/mfd/omap-usb-tll.c | 463 + 8 files changed, 513 insertions(+), 235 deletions(-) create mode 100644 drivers/mfd/omap-usb-tll.c Hi Samuel just to get your attention; I have added your mail id in the to list. please let me know your comments on this patch series; This change was strongly suggested by Paul Walmsley during the OMAP USB host runtime pm adaptations. Regards Keshava -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: IRQ domain support for INTC
On Mon, Mar 05, 2012 at 03:25:01PM +0100, Cousson, Benoit wrote: On 3/5/2012 2:58 PM, Johan Hovold wrote: On Wed, Feb 29, 2012 at 05:15:25PM +0100, Cousson, Benoit wrote: On 2/29/2012 12:48 AM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com [120227 08:04]: Hmm, looks like this now produces the following warning at least on omap3: Yes, Rajendra has just reported that issue with linux-next. I'm getting the same warning and initialisation failure with 3.3-rc6 on overo. Are these fixes queued up for 3.3 (and not just 3.4) somewhere? It is under review, I posted the series last Friday: mfd: twl: Fix for irqdomain/next + SPARSE_IRQ + MMC card detect It will be anyway material for 3.4 since it is in linux-next. Yes, I noted that there was a fix against linux-next. My question was whether any fix is planned for 3.3 as twl4030 is broken with SPARSE_IRQ enabled. Disabling SPARSE_IRQ will be the only workaround until 3.4 is out then? Thanks, Johan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP: IRQ domain support for INTC
On 3/5/2012 4:03 PM, Johan Hovold wrote: On Mon, Mar 05, 2012 at 03:25:01PM +0100, Cousson, Benoit wrote: On 3/5/2012 2:58 PM, Johan Hovold wrote: On Wed, Feb 29, 2012 at 05:15:25PM +0100, Cousson, Benoit wrote: On 2/29/2012 12:48 AM, Tony Lindgren wrote: * Cousson, Benoitb-cous...@ti.com[120227 08:04]: Hmm, looks like this now produces the following warning at least on omap3: Yes, Rajendra has just reported that issue with linux-next. I'm getting the same warning and initialisation failure with 3.3-rc6 on overo. Are these fixes queued up for 3.3 (and not just 3.4) somewhere? It is under review, I posted the series last Friday: mfd: twl: Fix for irqdomain/next + SPARSE_IRQ + MMC card detect It will be anyway material for 3.4 since it is in linux-next. Yes, I noted that there was a fix against linux-next. My question was whether any fix is planned for 3.3 as twl4030 is broken with SPARSE_IRQ enabled. Disabling SPARSE_IRQ will be the only workaround until 3.4 is out then? Mmm, but is SPARSE_IRQ used to work before on OMAP3? 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] ARM: OMAP2+: omap_device: call all suspend, resume callbacks when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set
Paul Walmsley p...@pwsan.com writes: During system suspend, when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set on an omap_device, call the corresponding driver's -suspend() and -suspend_noirq() callbacks (if present). Similarly, during resume, the driver's -resume() and -resume_noirq() callbacks must both be called, if present. (The previous code only called -suspend_noirq() and -resume_noirq().) If all of these callbacks aren't called, some important driver suspend/resume code may not get executed. In current mainline, the bug fixed by this patch is only a problem under the following conditions: - the kernel is running on an OMAP4 - an OMAP UART is used as a console - the kernel command line parameter 'no_console_suspend' is specified - and the system enters suspend (echo mem /sys/power/state). Under this combined circumstance, the system cannot be awakened via the serial port after commit be4b0281956c5cae4f63f31f11d07625a6988766c (tty: serial: OMAP: block idle while the UART is transferring data in PIO mode). This is because the OMAP UART driver's -suspend() callback is never called. The -suspend() callback would have called uart_suspend_port() which in turn would call enable_irq_wake(). Since enable_irq_wake() isn't called for the UART's IRQ, check_wakeup_irqs() would mask off the UART IRQ in the GIC. On v3.3 kernels prior to the above commit, serial resume from suspend presumably occurred via the PRCM interrupt. The UART was in smart-idle mode, so it was able to send a PRCM wakeup which in turn would be converted into a PRCM interrupt to the GIC, waking up the kernel. But after the above commit, when the system is suspended in the middle of a UART transmit, the UART IP block would be in no-idle mode. In no-idle mode, the UART won't generate wakeups to the PRCM when incoming characters are received; only GIC interrupts. But since the UART driver's -suspend() callback is never called, uart_suspend_port() and enable_irq_wake() is never called; so the UART interrupt is masked by check_wakeup_irqs() and the UART can't wake up the MPU. The remaining mechanism that could have awakened the system would have been I/O chain wakeups. These wouldn't be active because the console UART's clocks are never disabled when no_console_suspend is used, preventing the full chip from idling. Also, current mainline doesn't yet support full chip idle states for OMAP4, so I/O chain wakeups are not enabled. This patch is the result of a collaboration. John Stultz johns...@us.ibm.com and Andy Green andy.gr...@linaro.org reported the serial wakeup problem that led to the discovery of this problem. Kevin Hilman khil...@ti.com narrowed the problem down to the use of no_console_suspend. Signed-off-by: Paul Walmsley p...@pwsan.com Cc: John Stultz johns...@us.ibm.com Cc: Andy Green andy.gr...@linaro.org Cc: Kevin Hilman khil...@ti.com Looks right. Acked-by: Kevin Hilman khil...@ti.com Tony, this fix is needed for v3.3. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] of: DMA helpers: manage generic requests specification
On Wed, Feb 29, 2012 at 03:54:08PM +0100, Nicolas Ferre wrote:
By making DMA controllers register a generic translation
function, we allow the management of any type of DMA requests
specification.
The void * output of an of_dma_xlate() function that will be implemented
by the DMA controller can carry any type of dma-request argument.
The DMA client will search its associated DMA controller in the list
and call the registered of_dam_xlate() function to retrieve the
request values.
One simple xlate function is provided for the single number type
of request biding.
This implementation is independent from dmaengine so it can also be
used by legacy drivers.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Stephen Warren swar...@nvidia.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Russell King li...@arm.linux.org.uk
Cc: Rob Herring rob.herr...@calxeda.com
---
Hi all,
Here are my thoughts about the DMA helpers for device tree.
This patch goes on top of Benoit's ones. My goal was to keep this separated
from any DMA infrastructure (dmaengine not needed, nor any other DMA
implementation).
It is to keep the ball rolling, so do not hesitate to comment.
Best regards,
Documentation/devicetree/bindings/dma/dma.txt | 29 +++--
drivers/of/dma.c | 161
++---
include/linux/of_dma.h| 33 +-
3 files changed, 186 insertions(+), 37 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
index 7f2a301..c49e98d 100644
--- a/Documentation/devicetree/bindings/dma/dma.txt
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -6,9 +6,8 @@ DMA request line that goes from an IP to a DMA controller.
* DMA controller
-Required properties:
-- dma-controller: Mark the device as a DMA controller
-- #dma-cells: Number of cell for each DMA line, must be one.
+Required property:
+- #dma-cells: Number of cells for each DMA line.
Example:
@@ -17,7 +16,6 @@ Example:
compatible = ti,sdma-omap4
reg = 0x4800 0x1000;
interrupts = 12;
-dma-controller;
#dma-cells = 1;
};
@@ -25,20 +23,23 @@ Example:
* DMA client
-Client drivers should specify the DMA request numbers using a phandle to
-the controller + the DMA request number on that controller.
+Client drivers should specify the DMA request property using a phandle to
+the controller. If needed, the DMA request identity on that controller is
then
+added followed by optional request specifications.
-Required properties:
-- dma-request: List of pair phandle + dma-request per line
+Required property:
+- dma-request: List of phandle + dma-request + request specifications,
+ one group per request line.
+Optional property:
- dma-request-names: list of strings in the same order as the dma-request
in the dma-request property.
Example:
-i2c1: i2c@1 {
-...
-dma-request = sdma 2 sdma 3;
-dma-request-names = tx, rx;
-...
-};
+ i2c1: i2c@1 {
+ ...
+ dma-request = sdma 2 sdma 3;
+ dma-request-names = tx, rx;
+ ...
+ };
diff --git a/drivers/of/dma.c b/drivers/of/dma.c
index d4927e2..e0c6fd9 100644
--- a/drivers/of/dma.c
+++ b/drivers/of/dma.c
@@ -13,41 +13,145 @@
#include linux/device.h
#include linux/err.h
#include linux/module.h
+#include linux/rculist.h
+#include linux/slab.h
#include linux/of.h
#include linux/of_dma.h
+static LIST_HEAD(of_dma_list);
+
+/**
+ * of_dma_find_controller() - Find a DMA controller in DT DMA helpers list
+ * @np: device node of DMA controller
+ */
+static struct of_dma *of_dma_find_controller(struct device_node *np)
+{
+ struct of_dma *ofdma;
+
+ list_for_each_entry_rcu(ofdma, of_dma_list, of_dma_controllers) {
+ if (ofdma-of_node == np)
+ return ofdma;
+ }
+
+ return NULL;
+}
+
/**
- * of_get_dma_request() - Get a DMA request number and dma-controller node
+ * of_dma_controller_register() - Register a DMA controller to DT DMA helpers
+ * @np: device node of DMA controller
+ * @of_dma_xlate:generic translation function which converts a phandle
+ * arguments list into a generic output value
+ *
+ * Returns 0 on success or appropriate errno value on error.
+ *
+ * If #dma-cells is not specified in DMA controller device tree node, we
assume
+ * that the DMA controller phandle will come without argument.
+ *
+ * Allocated memory sould be freed with apropriate of_dma_controller_free()
+ * call.
+ */
+int of_dma_controller_register(struct device_node *np,
+ int
[PATCH v3 3/3] ASoC: OMAP: ams-delta: drop .set_bias_level callback
This functionality has already been implemented in the cx20442 codec
driver (commit f75a8ff67d161b5166a2c2360bb2ffaefd5eb853, ASoC: cx20442:
add bias control over a platform provided regulator), no need to keep
it here duplicated.
Once done, remove the no longer used AMS_DELTA_LATCH2_MODEM_NRESET
symbol from the board header file and a call to the regulator_toggle()
helper function from the old API wrapper found in the board file. While
being at it, simplify the way the modem .pm callback handles the
regulator and drop that helper function and its related consumer setup
completely.
Depends on patches 1/3 and 2/3 for clean apply and keep things working.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Tony Lindgren t...@atomide.com
---
v2 - v3 changes: none.
Changes against initial version:
* don't move consumer setup elements, now named to indicated their
modem related purpose, down the file,
* don't track the regulator enable/disable state, compare new target
power state with the old one instead; thanks to Mark Brown for
suggesting this simplification,
* actually drop all references to AMS_DELTA_LATCH2_MODEM_NRESET.
arch/arm/mach-omap1/board-ams-delta.c | 42 +++-
arch/arm/plat-omap/include/plat/board-ams-delta.h |1 -
sound/soc/omap/ams-delta.c| 32
3 files changed, 7 insertions(+), 68 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 2fb2cbb..cb6afe6 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -18,7 +18,6 @@
#include linux/input.h
#include linux/interrupt.h
#include linux/leds.h
-#include linux/mutex.h
#include linux/platform_device.h
#include linux/regulator/consumer.h
#include linux/regulator/fixed.h
@@ -291,35 +290,8 @@ static struct platform_device modem_nreset_device = {
struct modem_private_data {
struct regulator *regulator;
- struct {
- struct mutex lock;
- bool enabled;
- } consumer;
};
-static int regulator_toggle(struct modem_private_data *priv, bool enable)
-{
- int err = 0;
-
- mutex_lock(priv-consumer.lock);
- if (IS_ERR(priv-regulator)) {
- err = PTR_ERR(priv-regulator);
- } else if (enable) {
- if (!priv-consumer.enabled) {
- err = regulator_enable(priv-regulator);
- priv-consumer.enabled = true;
- }
- } else {
- if (priv-consumer.enabled) {
- err = regulator_disable(priv-regulator);
- priv-consumer.enabled = false;
- }
- }
- mutex_unlock(priv-consumer.lock);
-
- return err;
-}
-
static struct modem_private_data modem_priv;
void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
@@ -330,8 +302,6 @@ void ams_delta_latch_write(int base, int ngpio, u16 mask,
u16 value)
for (; bit ngpio; bit++, bitpos = bitpos 1) {
if (!(mask bitpos))
continue;
- else if (base + bit == AMS_DELTA_GPIO_PIN_MODEM_NRESET)
- regulator_toggle(modem_priv, (value bitpos) != 0);
else
gpio_set_value(base + bit, (value bitpos) != 0);
}
@@ -530,10 +500,16 @@ static void modem_pm(struct uart_port *port, unsigned int
state, unsigned old)
{
struct modem_private_data *priv = port-private_data;
+ if (IS_ERR(priv-regulator))
+ return;
+
if (state == old)
return;
- regulator_toggle(priv, state == 0);
+ if (state == 0)
+ regulator_enable(priv-regulator);
+ else if (old == 0)
+ regulator_disable(priv-regulator);
}
static struct plat_serial8250_port ams_delta_modem_ports[] = {
@@ -593,7 +569,6 @@ static int __init late_init(void)
gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
/* Initialize the modem_nreset regulator consumer before use */
- mutex_init(modem_priv.consumer.lock);
modem_priv.regulator = ERR_PTR(-ENODEV);
ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC,
@@ -606,9 +581,6 @@ static int __init late_init(void)
/*
* Once the modem device is registered, the modem_nreset
* regulator can be requested on behalf of that device.
-* In addition to the modem .pm callback, that regulator
-* is still used via the ams_delta_latch_write() wrapper
-* by the ASoC driver until updated.
*/
modem_priv.regulator = regulator_get(ams_delta_modem_device.dev,
RESET#);
diff --git a/arch/arm/plat-omap/include/plat/board-ams-delta.h
b/arch/arm/plat-omap/include/plat/board-ams-delta.h
index 027e79e..ad6f865 100644
---
[PATCH v3 2/3] ARM: OMAP1: ams-delta: update the modem to use regulator API
After the CX20442 codec driver already takes care of enabling the codec
power for itself (commit f75a8ff67d161b5166a2c2360bb2ffaefd5eb853,
ASoC: cx20442: add bias control over a platform provided regulator),
but before dropping the old bias control method from the Amstrad Delta
ASoC sound card file, which in fact keeps the modem power always on,
even on the ASoC device close for now, extend the modem setup with a
power management callback which toggles the regulator up to the modem's
needs, reusing the previously set up regulator consumer for this. Also,
drop the MODEM_NRESET pin setup from the modem initialization procedure,
as this operation was already ineffective since patch 1/3, and not
needed because the regulator is set up as initially enabled.
Depends on patch 1/3 ARM: OMAP1: ams-delta: set up regulator over modem
reset GPIO pin to apply cleanly.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
Cc: Tony Lindgren t...@atomide.com
---
No functional changes against initial version.
arch/arm/mach-omap1/board-ams-delta.c | 22 +-
1 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index 949997c..2fb2cbb 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -526,6 +526,16 @@ static void __init ams_delta_init(void)
omap_writew(omap_readw(ARM_RSTCT1) | 0x0004, ARM_RSTCT1);
}
+static void modem_pm(struct uart_port *port, unsigned int state, unsigned old)
+{
+ struct modem_private_data *priv = port-private_data;
+
+ if (state == old)
+ return;
+
+ regulator_toggle(priv, state == 0);
+}
+
static struct plat_serial8250_port ams_delta_modem_ports[] = {
{
.membase= IOMEM(MODEM_VIRT),
@@ -536,6 +546,8 @@ static struct plat_serial8250_port ams_delta_modem_ports[]
= {
.iotype = UPIO_MEM,
.regshift = 1,
.uartclk= BASE_BAUD * 16,
+ .pm = modem_pm,
+ .private_data = modem_priv,
},
{ },
};
@@ -584,9 +596,8 @@ static int __init late_init(void)
mutex_init(modem_priv.consumer.lock);
modem_priv.regulator = ERR_PTR(-ENODEV);
- ams_delta_latch2_write(
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC,
- AMS_DELTA_LATCH2_MODEM_NRESET | AMS_DELTA_LATCH2_MODEM_CODEC);
+ ams_delta_latch2_write(AMS_DELTA_LATCH2_MODEM_CODEC,
+ AMS_DELTA_LATCH2_MODEM_CODEC);
err = platform_device_register(ams_delta_modem_device);
if (err)
@@ -595,8 +606,9 @@ static int __init late_init(void)
/*
* Once the modem device is registered, the modem_nreset
* regulator can be requested on behalf of that device.
-* The regulator is used via ams_delta_latch_write()
-* by the modem and ASoC drivers until updated.
+* In addition to the modem .pm callback, that regulator
+* is still used via the ams_delta_latch_write() wrapper
+* by the ASoC driver until updated.
*/
modem_priv.regulator = regulator_get(ams_delta_modem_device.dev,
RESET#);
--
1.7.3.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/3] Amstrad Delta: access MODEM_RESET GPIO pin over a regulator
The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down (bring into/out of a reset state) two distinct on-board devices simultaneously: the modem, and the voice codec. As a consequence, that bit is, or can be, manipulated concurrently by two drivers, or their platform provided hooks. Instead of updating those drivers to use the gpiolib API as a new method of controlling the MODEM_NRESET pin state, like it was done to other drivers accessing latch2 pins, and still being vulnerable to potential concurrency conflicts, or trying to solve that sharing issue with a custom piece of code, set up a fixed regulator device on top of that GPIO pin and update both drivers to manipulate that regulator, not the GPIO pin directly. This is v3 of this series, with Mark's Ack for ASoC subtree touching changes already collected, rebased on top of linux-omap/ams-delta tip, commit da564a05b3aefe403062411b67d64b7e992718f7. There were initially 4 patches in the series, but patch 2/4, ASoC: cx20442: add bias control over a platform provided regulator, has been since then applied by Liam to the ASoC tree (thanks!) and is already present in mainline (commit f75a8ff67d161b5166a2c2360bb2ffaefd5eb853), hence omitted from this submission. v2 - v3 changes: * fix section mismatch issue present in previous versions of patch 1/3. v2 changes against initial version: * in both the codec and the modem callbacks, don't track the regulator enable/disable state, compare new target bias level (the codec case) or power state (the modem case) with the old value instead; thanks to Mark Brown who suggested this solution, * a few other minor changes, mostly stylistic. Janusz Krzysztofik (3): ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin ARM: OMAP1: ams-delta: update the modem to use regulator API ASoC: OMAP: ams-delta: drop .set_bias_level callback arch/arm/mach-omap1/Kconfig |2 + arch/arm/mach-omap1/board-ams-delta.c | 94 +++-- arch/arm/plat-omap/include/plat/board-ams-delta.h |1 - sound/soc/omap/ams-delta.c| 32 --- 4 files changed, 87 insertions(+), 42 deletions(-) -- 1.7.3.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/3] ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin
The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available
as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down
(bring into/out of a reset state) two distinct on-board devices
simultaneously: the modem, and the voice codec. As a consequence, that
bit is, or can be, manipulated concurrently by two drivers, or their
platform provided hooks.
Instead of updating those drivers to use the gpiolib API as a new method
of controlling the MODEM_NRESET pin state, like it was done to other
drivers accessing latch2 pins, and still being vulnerable to potential
concurrency conflicts, or trying to solve that sharing issue with a
custom piece of code, set up a fixed regulator device on top of that
GPIO pin, with the intention of updating both drivers to manipulate that
regulator, not the GPIO pin directly.
Before the ASoC driver is updated and the modem platform data expanded
with a power management callback for switching its power, the
ams_delta_latch_write() function, which still provides the old API for
accessing latch2 functionality from not updated drivers, is modified to
toggle the regulator instead of the MODEM_NRESET GPIO pin. A helper
function provided for balancing the regulator enable/disable operations,
together with the consumer data needed for tracking the regulator state,
will be removed once the drivers are updated.
Depends on patch series ARM: OMAP1: ams-delta: replace custom I/O with
GPIO.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
v2 - v3 changes:
* fix section mismatch isue.
Changes against initial version:
* rename consumer setup elements to match their final, modem only
related purpose,
* initialize the regulator pointer and mutex before first use, then
omit testing that pointer against NULL value
arch/arm/mach-omap1/Kconfig |2 +
arch/arm/mach-omap1/board-ams-delta.c | 104 +++--
2 files changed, 100 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig
index 5b1edba..4b6a774 100644
--- a/arch/arm/mach-omap1/Kconfig
+++ b/arch/arm/mach-omap1/Kconfig
@@ -157,6 +157,8 @@ config MACH_AMS_DELTA
select FIQ
select GPIO_GENERIC_PLATFORM
select LEDS_GPIO_REGISTER
+ select REGULATOR
+ select REGULATOR_FIXED_VOLTAGE
help
Support for the Amstrad E3 (codename Delta) videophone. Say Y here
if you have such a device.
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index ce50fe1..949997c 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -18,7 +18,11 @@
#include linux/input.h
#include linux/interrupt.h
#include linux/leds.h
+#include linux/mutex.h
#include linux/platform_device.h
+#include linux/regulator/consumer.h
+#include linux/regulator/fixed.h
+#include linux/regulator/machine.h
#include linux/serial_8250.h
#include linux/export.h
@@ -237,11 +241,6 @@ static const struct gpio latch_gpios[] __initconst = {
.label = scard_cmdvcc,
},
{
- .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
- .flags = GPIOF_OUT_INIT_LOW,
- .label = modem_nreset,
- },
- {
.gpio = AMS_DELTA_GPIO_PIN_MODEM_CODEC,
.flags = GPIOF_OUT_INIT_LOW,
.label = modem_codec,
@@ -258,6 +257,71 @@ static const struct gpio latch_gpios[] __initconst = {
},
};
+static struct regulator_consumer_supply modem_nreset_consumers[] = {
+ REGULATOR_SUPPLY(RESET#, serial8250.1),
+ REGULATOR_SUPPLY(POR, cx20442-codec),
+};
+
+static struct regulator_init_data modem_nreset_data = {
+ .constraints= {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ .boot_on= 1,
+ },
+ .num_consumer_supplies = ARRAY_SIZE(modem_nreset_consumers),
+ .consumer_supplies = modem_nreset_consumers,
+};
+
+static struct fixed_voltage_config modem_nreset_config = {
+ .supply_name= modem_nreset,
+ .microvolts = 330,
+ .gpio = AMS_DELTA_GPIO_PIN_MODEM_NRESET,
+ .startup_delay = 25000,
+ .enable_high= 1,
+ .enabled_at_boot= 1,
+ .init_data = modem_nreset_data,
+};
+
+static struct platform_device modem_nreset_device = {
+ .name = reg-fixed-voltage,
+ .id = -1,
+ .dev= {
+ .platform_data = modem_nreset_config,
+ },
+};
+
+struct modem_private_data {
+ struct regulator *regulator;
+ struct {
+ struct mutex lock;
+ bool enabled;
+ } consumer;
+};
+
+static int regulator_toggle(struct modem_private_data *priv, bool enable)
+{
+ int err = 0;
+
+ mutex_lock(priv-consumer.lock);
+ if
Re: [PATCH v7 0/9] Consolidate cpuidle functionality
On 03/01/2012 09:57 PM, Rob Lee wrote: On Wed, Feb 29, 2012 at 6:42 PM, Robert Leerob@linaro.org wrote: This patch series moves various functionality duplicated in platform cpuidle drivers to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). I'm told that I forgot to add the Acks from the previous v6 to this version: Acked-by: Jean Pihetj-pi...@ti.com (v6) Tested-by: Jean Pihetj-pi...@ti.com (v6, omap3) Tested-by: Amit Danielamit.kach...@linaro.org (v6, Exynos4) For the generic cpuidle changes: Reviewed-by: Deepthi Dharwardeep...@linux.vnet.ibm.com Reviewed-by: Daniel Lezcano daniel.lezc...@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/10] omapdrm patches for 3.4
From: Rob Clark r...@ti.com This is the (potentially first) batch of patches for omapdrm for 3.4. It includes some fixes for OMAP3 (without DMM), and change in how the DMM code gets it's platform data based on review comments from the first version of the patch which added the omapdrm platform dev. Also, a few cleanups, a better solution for handling fbdev calls from atomix context, deferred unpin until scanout completes, mmap of tiled buffers w/ stride larger than PAGE_SIZE. There is one additional patch to come after the platform device patch is merged (in arch/arm/plat-omap) to remove some duplicated structs. And I am still working on support for scanout and rotated scanout of tiled buffers, which may or may not be ready in time for 3.4 merge window. Andy Gross (3): staging: drm/omap: Disable DMM debugfs for OMAP3 staging: drm/omap: Validate debugfs device staging: drm/omap: Get DMM resources from hwmod Rob Clark (7): staging: drm/omap: get supported color formats from ovl staging: drm/omap: add a workqueue staging: drm/omap: call omap_gem_roll() in non-atomic ctx staging: drm/omap: some minor fb cleanups staging: drm/omap: defer unpin until scanout completes staging: drm/omap: debugfs for object and fb tracking staging: drm/omap: mmap of tiled buffers with stride 4kb drivers/staging/omapdrm/omap_debugfs.c | 97 +- drivers/staging/omapdrm/omap_dmm_tiler.c | 91 drivers/staging/omapdrm/omap_dmm_tiler.h | 15 ++-- drivers/staging/omapdrm/omap_drv.c | 16 +++ drivers/staging/omapdrm/omap_drv.h | 17 +++- drivers/staging/omapdrm/omap_fb.c| 124 +++--- drivers/staging/omapdrm/omap_fbdev.c | 26 - drivers/staging/omapdrm/omap_gem.c | 172 ++ drivers/staging/omapdrm/omap_plane.c | 161 +++- 9 files changed, 570 insertions(+), 149 deletions(-) -- 1.7.5.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/10] staging: drm/omap: get supported color formats from ovl
From: Rob Clark r...@ti.com
Get the supported formats for a plane from ovl's supported_modes
bitmask.
Signed-off-by: Rob Clark r...@ti.com
---
drivers/staging/omapdrm/omap_drv.h |2 ++
drivers/staging/omapdrm/omap_fb.c| 14 ++
drivers/staging/omapdrm/omap_plane.c | 27 +++
3 files changed, 23 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index 61fe022..d924c95 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -92,6 +92,8 @@ void omap_connector_mode_set(struct drm_connector *connector,
void omap_connector_flush(struct drm_connector *connector,
int x, int y, int w, int h);
+uint32_t omap_framebuffer_get_formats(uint32_t *pixel_formats,
+ uint32_t max_formats, enum omap_color_mode supported_modes);
struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev,
struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd);
struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
diff --git a/drivers/staging/omapdrm/omap_fb.c
b/drivers/staging/omapdrm/omap_fb.c
index d021a7e..116a8ff 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -59,6 +59,20 @@ static const struct format formats[] = {
{ OMAP_DSS_COLOR_UYVY,DRM_FORMAT_UYVY, {{2, 1}}, true },
};
+/* convert from overlay's pixel formats bitmask to an array of fourcc's */
+uint32_t omap_framebuffer_get_formats(uint32_t *pixel_formats,
+ uint32_t max_formats, enum omap_color_mode supported_modes)
+{
+ uint32_t nformats = 0;
+ int i = 0;
+
+ for (i = 0; i ARRAY_SIZE(formats) nformats max_formats; i++)
+ if (formats[i].dss_format supported_modes)
+ pixel_formats[nformats++] = formats[i].pixel_format;
+
+ return nformats;
+}
+
/* per-plane info for the fb: */
struct plane {
struct drm_gem_object *bo;
diff --git a/drivers/staging/omapdrm/omap_plane.c
b/drivers/staging/omapdrm/omap_plane.c
index 9790912..c5625e3 100644
--- a/drivers/staging/omapdrm/omap_plane.c
+++ b/drivers/staging/omapdrm/omap_plane.c
@@ -43,8 +43,10 @@ struct omap_plane {
/* last fb that we pinned: */
struct drm_framebuffer *pinned_fb;
-};
+ uint32_t nformats;
+ uint32_t formats[32];
+};
/* push changes down to dss2 */
static int commit(struct drm_plane *plane)
@@ -271,24 +273,6 @@ static const struct drm_plane_funcs omap_plane_funcs = {
.destroy = omap_plane_destroy,
};
-static const uint32_t formats[] = {
- DRM_FORMAT_RGB565,
- DRM_FORMAT_RGBX,
- DRM_FORMAT_XRGB,
- DRM_FORMAT_RGBA,
- DRM_FORMAT_ABGR,
- DRM_FORMAT_XRGB1555,
- DRM_FORMAT_ARGB1555,
- DRM_FORMAT_RGB888,
- DRM_FORMAT_RGBX,
- DRM_FORMAT_XRGB,
- DRM_FORMAT_RGBA,
- DRM_FORMAT_ARGB,
- DRM_FORMAT_NV12,
- DRM_FORMAT_YUYV,
- DRM_FORMAT_UYVY,
-};
-
/* initialize plane */
struct drm_plane *omap_plane_init(struct drm_device *dev,
struct omap_overlay *ovl, unsigned int possible_crtcs,
@@ -306,11 +290,14 @@ struct drm_plane *omap_plane_init(struct drm_device *dev,
goto fail;
}
+ omap_plane-nformats = omap_framebuffer_get_formats(
+ omap_plane-formats, ARRAY_SIZE(omap_plane-formats),
+ ovl-supported_modes);
omap_plane-ovl = ovl;
plane = omap_plane-base;
drm_plane_init(dev, plane, possible_crtcs, omap_plane_funcs,
- formats, ARRAY_SIZE(formats), priv);
+ omap_plane-formats, omap_plane-nformats, priv);
/* get our starting configuration, set defaults for parameters
* we don't currently use, etc:
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/10] staging: drm/omap: add a workqueue
From: Rob Clark r...@ti.com
Add a workqueue for omapdrm driver, which is needed for at least a
couple things currently: (1) moving omap_gem_roll() to a non-atomic
context, (2) synchronizing page flips w/ DSS scanout related irq's
(in particular not unmapping previous buffer until DSS finishes
scanout).
Signed-off-by: Rob Clark r...@ti.com
---
drivers/staging/omapdrm/omap_drv.c |8
drivers/staging/omapdrm/omap_drv.h |2 ++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 3bbea9a..7417e1f 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -570,6 +570,9 @@ static int dev_load(struct drm_device *dev, unsigned long
flags)
dev-dev_private = priv;
+ priv-wq = alloc_workqueue(omapdrm,
+ WQ_UNBOUND | WQ_NON_REENTRANT, 1);
+
omap_gem_init(dev);
ret = omap_modeset_init(dev);
@@ -598,6 +601,8 @@ static int dev_load(struct drm_device *dev, unsigned long
flags)
static int dev_unload(struct drm_device *dev)
{
+ struct omap_drm_private *priv = dev-dev_private;
+
DBG(unload: dev=%p, dev);
drm_vblank_cleanup(dev);
@@ -607,6 +612,9 @@ static int dev_unload(struct drm_device *dev)
omap_modeset_free(dev);
omap_gem_deinit(dev);
+ flush_workqueue(priv-wq);
+ destroy_workqueue(priv-wq);
+
kfree(dev-dev_private);
dev-dev_private = NULL;
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index d924c95..a84547c 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -51,6 +51,8 @@ struct omap_drm_private {
struct drm_fb_helper *fbdev;
+ struct workqueue_struct *wq;
+
bool has_dmm;
};
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/10] staging: drm/omap: call omap_gem_roll() in non-atomic ctx
From: Rob Clark r...@ti.com
If fbcon calls us from atomic context, push the work off to the
workqueue to avoid calling into the gem/dmm code in an atomic
context.
Signed-off-by: Rob Clark r...@ti.com
---
drivers/staging/omapdrm/omap_fbdev.c | 26 ++
drivers/staging/omapdrm/omap_gem.c | 14 ++
2 files changed, 24 insertions(+), 16 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_fbdev.c
b/drivers/staging/omapdrm/omap_fbdev.c
index 96940bb..11acd4c 100644
--- a/drivers/staging/omapdrm/omap_fbdev.c
+++ b/drivers/staging/omapdrm/omap_fbdev.c
@@ -37,6 +37,9 @@ struct omap_fbdev {
struct drm_framebuffer *fb;
struct drm_gem_object *bo;
bool ywrap_enabled;
+
+ /* for deferred dmm roll when getting called in atomic ctx */
+ struct work_struct work;
};
static void omap_fbdev_flush(struct fb_info *fbi, int x, int y, int w, int h);
@@ -75,12 +78,22 @@ static void omap_fbdev_imageblit(struct fb_info *fbi,
image-width, image-height);
}
+static void pan_worker(struct work_struct *work)
+{
+ struct omap_fbdev *fbdev = container_of(work, struct omap_fbdev, work);
+ struct fb_info *fbi = fbdev-base.fbdev;
+ int npages;
+
+ /* DMM roll shifts in 4K pages: */
+ npages = fbi-fix.line_length PAGE_SHIFT;
+ omap_gem_roll(fbdev-bo, fbi-var.yoffset * npages);
+}
+
static int omap_fbdev_pan_display(struct fb_var_screeninfo *var,
struct fb_info *fbi)
{
struct drm_fb_helper *helper = get_fb(fbi);
struct omap_fbdev *fbdev = to_omap_fbdev(helper);
- int npages;
if (!helper)
goto fallback;
@@ -88,9 +101,12 @@ static int omap_fbdev_pan_display(struct fb_var_screeninfo
*var,
if (!fbdev-ywrap_enabled)
goto fallback;
- /* DMM roll shifts in 4K pages: */
- npages = fbi-fix.line_length PAGE_SHIFT;
- omap_gem_roll(fbdev-bo, var-yoffset * npages);
+ if (drm_can_sleep()) {
+ pan_worker(fbdev-work);
+ } else {
+ struct omap_drm_private *priv = helper-dev-dev_private;
+ queue_work(priv-wq, fbdev-work);
+ }
return 0;
@@ -336,6 +352,8 @@ struct drm_fb_helper *omap_fbdev_init(struct drm_device
*dev)
goto fail;
}
+ INIT_WORK(fbdev-work, pan_worker);
+
helper = fbdev-base;
helper-funcs = omap_fb_helper_funcs;
diff --git a/drivers/staging/omapdrm/omap_gem.c
b/drivers/staging/omapdrm/omap_gem.c
index b7d6f88..bd35520 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -566,6 +566,8 @@ fail:
/* Set scrolling position. This allows us to implement fast scrolling
* for console.
+ *
+ * Call only from non-atomic contexts.
*/
int omap_gem_roll(struct drm_gem_object *obj, uint32_t roll)
{
@@ -580,18 +582,6 @@ int omap_gem_roll(struct drm_gem_object *obj, uint32_t
roll)
omap_obj-roll = roll;
- if (in_atomic() || mutex_is_locked(obj-dev-struct_mutex)) {
- /* this can get called from fbcon in atomic context.. so
-* just ignore it and wait for next time called from
-* interruptible context to update the PAT.. the result
-* may be that user sees wrap-around instead of scrolling
-* momentarily on the screen. If we wanted to be fancier
-* we could perhaps schedule some workqueue work at this
-* point.
-*/
- return 0;
- }
-
mutex_lock(obj-dev-struct_mutex);
/* if we aren't mapped yet, we don't need to do anything */
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/10] staging: drm/omap: some minor fb cleanups
From: Rob Clark r...@ti.com
Now that 'struct drm_plane' has a pixel_format field, use that. And
fix a minor typo.
Signed-off-by: Rob Clark r...@ti.com
---
drivers/staging/omapdrm/omap_fb.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_fb.c
b/drivers/staging/omapdrm/omap_fb.c
index 116a8ff..08e2e35 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -101,7 +101,7 @@ static int omap_framebuffer_create_handle(struct
drm_framebuffer *fb,
static void omap_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
- int i, n = drm_format_num_planes(omap_fb-format-pixel_format);
+ int i, n = drm_format_num_planes(fb-pixel_format);
DBG(destroy: FB ID: %d (%p), fb-base.id, fb);
@@ -204,7 +204,7 @@ void omap_framebuffer_update_scanout(struct drm_framebuffer
*fb, int x, int y,
struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb, int p)
{
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
- if (p = drm_format_num_planes(omap_fb-format-pixel_format))
+ if (p = drm_format_num_planes(fb-pixel_format))
return NULL;
return omap_fb-planes[p].bo;
}
@@ -351,8 +351,8 @@ struct drm_framebuffer *omap_framebuffer_init(struct
drm_device *dev,
plane-bo = bos[i];
plane-offset = mode_cmd-offsets[i];
- plane-pitch = mode_cmd-pitches[i];
- plane-paddr = pitch;
+ plane-pitch = pitch;
+ plane-paddr = 0;
}
drm_helper_mode_fill_fb_struct(fb, mode_cmd);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/10] staging: drm/omap: defer unpin until scanout completes
From: Rob Clark r...@ti.com
When flipping, defer unpinning until scanout completes, as indicated
by the appropriate END_WIN irq.
This also re-organizes things a bit, in replacing omap_fb_{pin,unpin}
with omap_fb_replace(), to make it easier to add support for scanout
synchronized DMM refill mode (flipping by just reprogramming DMM
synchronized with DSS scanout).
Signed-off-by: Rob Clark r...@ti.com
---
drivers/staging/omapdrm/omap_drv.h |5 +-
drivers/staging/omapdrm/omap_fb.c| 84 -
drivers/staging/omapdrm/omap_plane.c | 136 --
3 files changed, 181 insertions(+), 44 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index a84547c..fe4766e 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -101,8 +101,9 @@ struct drm_framebuffer *omap_framebuffer_create(struct
drm_device *dev,
struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb, int p);
-int omap_framebuffer_pin(struct drm_framebuffer *fb);
-void omap_framebuffer_unpin(struct drm_framebuffer *fb);
+int omap_framebuffer_replace(struct drm_framebuffer *a,
+ struct drm_framebuffer *b, void *arg,
+ void (*unpin)(void *arg, struct drm_gem_object *bo));
void omap_framebuffer_update_scanout(struct drm_framebuffer *fb, int x, int y,
struct omap_overlay_info *info);
struct drm_connector *omap_framebuffer_get_next_connector(
diff --git a/drivers/staging/omapdrm/omap_fb.c
b/drivers/staging/omapdrm/omap_fb.c
index 08e2e35..fcb248f 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -137,41 +137,6 @@ static const struct drm_framebuffer_funcs
omap_framebuffer_funcs = {
.dirty = omap_framebuffer_dirty,
};
-/* pins buffer in preparation for scanout */
-int omap_framebuffer_pin(struct drm_framebuffer *fb)
-{
- struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
- int ret, i, n = drm_format_num_planes(omap_fb-format-pixel_format);
-
- for (i = 0; i n; i++) {
- struct plane *plane = omap_fb-planes[i];
- ret = omap_gem_get_paddr(plane-bo, plane-paddr, true);
- if (ret)
- goto fail;
- }
-
- return 0;
-
-fail:
- while (--i 0) {
- struct plane *plane = omap_fb-planes[i];
- omap_gem_put_paddr(plane-bo);
- }
- return ret;
-}
-
-/* releases buffer when done with scanout */
-void omap_framebuffer_unpin(struct drm_framebuffer *fb)
-{
- struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
- int i, n = drm_format_num_planes(omap_fb-format-pixel_format);
-
- for (i = 0; i n; i++) {
- struct plane *plane = omap_fb-planes[i];
- omap_gem_put_paddr(plane-bo);
- }
-}
-
/* update ovl info for scanout, handles cases of multi-planar fb's, etc.
*/
void omap_framebuffer_update_scanout(struct drm_framebuffer *fb, int x, int y,
@@ -201,6 +166,55 @@ void omap_framebuffer_update_scanout(struct
drm_framebuffer *fb, int x, int y,
}
}
+/* Call for unpin 'a' (if not NULL), and pin 'b' (if not NULL). Although
+ * buffers to unpin are just just pushed to the unpin fifo so that the
+ * caller can defer unpin until vblank.
+ *
+ * Note if this fails (ie. something went very wrong!), all buffers are
+ * unpinned, and the caller disables the overlay. We could have tried
+ * to revert back to the previous set of pinned buffers but if things are
+ * hosed there is no guarantee that would succeed.
+ */
+int omap_framebuffer_replace(struct drm_framebuffer *a,
+ struct drm_framebuffer *b, void *arg,
+ void (*unpin)(void *arg, struct drm_gem_object *bo))
+{
+ int ret = 0, i, na, nb;
+ struct omap_framebuffer *ofba = to_omap_framebuffer(a);
+ struct omap_framebuffer *ofbb = to_omap_framebuffer(b);
+
+ na = a ? drm_format_num_planes(a-pixel_format) : 0;
+ nb = b ? drm_format_num_planes(b-pixel_format) : 0;
+
+ for (i = 0; i max(na, nb); i++) {
+ struct plane *pa, *pb;
+
+ pa = (i na) ? ofba-planes[i] : NULL;
+ pb = (i nb) ? ofbb-planes[i] : NULL;
+
+ if (pa) {
+ unpin(arg, pa-bo);
+ pa-paddr = 0;
+ }
+
+ if (pb !ret)
+ ret = omap_gem_get_paddr(pb-bo, pb-paddr, true);
+ }
+
+ if (ret) {
+ /* something went wrong.. unpin what has been pinned */
+ for (i = 0; i nb; i++) {
+ struct plane *pb = ofba-planes[i];
+ if (pb-paddr) {
+ unpin(arg, pb-bo);
+
[PATCH 06/10] staging: drm/omap: debugfs for object and fb tracking
From: Rob Clark r...@ti.com
Add some additional debugfs file to aid in tracking buffer usage.
Signed-off-by: Rob Clark r...@ti.com
---
drivers/staging/omapdrm/omap_debugfs.c | 98 +++-
drivers/staging/omapdrm/omap_drv.c |2 +
drivers/staging/omapdrm/omap_drv.h |8 +++
drivers/staging/omapdrm/omap_fb.c | 18 ++
drivers/staging/omapdrm/omap_gem.c | 64 -
5 files changed, 188 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_debugfs.c
b/drivers/staging/omapdrm/omap_debugfs.c
index da920df..e23f907 100644
--- a/drivers/staging/omapdrm/omap_debugfs.c
+++ b/drivers/staging/omapdrm/omap_debugfs.c
@@ -20,23 +20,119 @@
#include omap_drv.h
#include omap_dmm_tiler.h
+#include drm_fb_helper.h
+
+
#ifdef CONFIG_DEBUG_FS
+static int gem_show(struct seq_file *m, void *arg)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct omap_drm_private *priv = dev-dev_private;
+ int ret;
+
+ ret = mutex_lock_interruptible(dev-struct_mutex);
+ if (ret)
+ return ret;
+
+ seq_printf(m, All Objects:\n);
+ omap_gem_describe_objects(priv-obj_list, m);
+
+ mutex_unlock(dev-struct_mutex);
+
+ return 0;
+}
+
+static int mm_show(struct seq_file *m, void *arg)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ return drm_mm_dump_table(m, dev-mm_private);
+}
+
+static int fb_show(struct seq_file *m, void *arg)
+{
+ struct drm_info_node *node = (struct drm_info_node *) m-private;
+ struct drm_device *dev = node-minor-dev;
+ struct omap_drm_private *priv = dev-dev_private;
+ struct drm_framebuffer *fb;
+ int ret;
+
+ ret = mutex_lock_interruptible(dev-mode_config.mutex);
+ if (ret)
+ return ret;
+
+ ret = mutex_lock_interruptible(dev-struct_mutex);
+ if (ret) {
+ mutex_unlock(dev-mode_config.mutex);
+ return ret;
+ }
+
+ seq_printf(m, fbcon );
+ omap_framebuffer_describe(priv-fbdev-fb, m);
+
+ list_for_each_entry(fb, dev-mode_config.fb_list, head) {
+ if (fb == priv-fbdev-fb)
+ continue;
+
+ seq_printf(m, user );
+ omap_framebuffer_describe(fb, m);
+ }
+
+ mutex_unlock(dev-struct_mutex);
+ mutex_unlock(dev-mode_config.mutex);
+
+ return 0;
+}
+
+/* list of debufs files that are applicable to all devices */
static struct drm_info_list omap_debugfs_list[] = {
+ {gem, gem_show, 0},
+ {mm, mm_show, 0},
+ {fb, fb_show, 0},
+};
+
+/* list of debugfs files that are specific to devices with dmm/tiler */
+static struct drm_info_list omap_dmm_debugfs_list[] = {
{tiler_map, tiler_map_show, 0},
};
int omap_debugfs_init(struct drm_minor *minor)
{
- return drm_debugfs_create_files(omap_debugfs_list,
+ struct drm_device *dev = minor-dev;
+ int ret;
+
+ ret = drm_debugfs_create_files(omap_debugfs_list,
ARRAY_SIZE(omap_debugfs_list),
minor-debugfs_root, minor);
+
+ if (ret) {
+ dev_err(dev-dev, could not install omap_debugfs_list\n);
+ return ret;
+ }
+
+ /* TODO: only do this if has_dmm.. but this fxn gets called before
+* dev_load() so we don't know this yet..
+*/
+ ret = drm_debugfs_create_files(omap_dmm_debugfs_list,
+ ARRAY_SIZE(omap_dmm_debugfs_list),
+ minor-debugfs_root, minor);
+
+ if (ret) {
+ dev_err(dev-dev, could not install omap_dmm_debugfs_list\n);
+ return ret;
+ }
+
+ return ret;
}
void omap_debugfs_cleanup(struct drm_minor *minor)
{
drm_debugfs_remove_files(omap_debugfs_list,
ARRAY_SIZE(omap_debugfs_list), minor);
+ drm_debugfs_remove_files(omap_dmm_debugfs_list,
+ ARRAY_SIZE(omap_dmm_debugfs_list), minor);
}
#endif
diff --git a/drivers/staging/omapdrm/omap_drv.c
b/drivers/staging/omapdrm/omap_drv.c
index 7417e1f..e2100bb 100644
--- a/drivers/staging/omapdrm/omap_drv.c
+++ b/drivers/staging/omapdrm/omap_drv.c
@@ -573,6 +573,8 @@ static int dev_load(struct drm_device *dev, unsigned long
flags)
priv-wq = alloc_workqueue(omapdrm,
WQ_UNBOUND | WQ_NON_REENTRANT, 1);
+ INIT_LIST_HEAD(priv-obj_list);
+
omap_gem_init(dev);
ret = omap_modeset_init(dev);
diff --git a/drivers/staging/omapdrm/omap_drv.h
b/drivers/staging/omapdrm/omap_drv.h
index fe4766e..21e48cf 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -42,10 +42,13 @@
struct omap_drm_private {
unsigned int num_crtcs;
[PATCH 07/10] staging: drm/omap: Disable DMM debugfs for OMAP3
From: Andy Gross andy.gr...@ti.com
OMAP3 does not contain a DMM/Tiler block. As such, we should not
be exposing any DMM debugfs entries on OMAP3 platforms.
Added inline helper function to verify existence of DMM.
Signed-off-by: Andy Gross andy.gr...@ti.com
Signed-off-by: Rob Clark r...@ti.com
---
drivers/staging/omapdrm/omap_debugfs.c | 15 +++
drivers/staging/omapdrm/omap_dmm_tiler.h |6 ++
2 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_debugfs.c
b/drivers/staging/omapdrm/omap_debugfs.c
index e23f907..2f122e0 100644
--- a/drivers/staging/omapdrm/omap_debugfs.c
+++ b/drivers/staging/omapdrm/omap_debugfs.c
@@ -112,12 +112,10 @@ int omap_debugfs_init(struct drm_minor *minor)
return ret;
}
- /* TODO: only do this if has_dmm.. but this fxn gets called before
-* dev_load() so we don't know this yet..
-*/
- ret = drm_debugfs_create_files(omap_dmm_debugfs_list,
- ARRAY_SIZE(omap_dmm_debugfs_list),
- minor-debugfs_root, minor);
+ if (dmm_is_available())
+ ret = drm_debugfs_create_files(omap_dmm_debugfs_list,
+ ARRAY_SIZE(omap_dmm_debugfs_list),
+ minor-debugfs_root, minor);
if (ret) {
dev_err(dev-dev, could not install omap_dmm_debugfs_list\n);
@@ -131,8 +129,9 @@ void omap_debugfs_cleanup(struct drm_minor *minor)
{
drm_debugfs_remove_files(omap_debugfs_list,
ARRAY_SIZE(omap_debugfs_list), minor);
- drm_debugfs_remove_files(omap_dmm_debugfs_list,
- ARRAY_SIZE(omap_dmm_debugfs_list), minor);
+ if (dmm_is_available())
+ drm_debugfs_remove_files(omap_dmm_debugfs_list,
+ ARRAY_SIZE(omap_dmm_debugfs_list), minor);
}
#endif
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.h
b/drivers/staging/omapdrm/omap_dmm_tiler.h
index f87cb65..55ab284 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.h
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.h
@@ -16,6 +16,7 @@
#ifndef OMAP_DMM_TILER_H
#define OMAP_DMM_TILER_H
+#include plat/cpu.h
#include omap_drv.h
#include tcm.h
@@ -132,4 +133,9 @@ struct omap_dmm_platform_data {
int irq;
};
+static inline int dmm_is_available(void)
+{
+ return cpu_is_omap44xx();
+}
+
#endif
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/10] staging: drm/omap: Validate debugfs device
From: Andy Gross andy.gr...@ti.com
Added check for valid device information before dumping debugfs
information.
Signed-off-by: Andy Gross andy.gr...@ti.com
Signed-off-by: Rob Clark r...@ti.com
---
drivers/staging/omapdrm/omap_dmm_tiler.c | 12 ++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index 852d944..e4c7bb6 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -766,10 +766,18 @@ int tiler_map_show(struct seq_file *s, void *arg)
const char *a2d = special;
const char *m2dp = m2d, *a2dp = a2d;
char nice[128];
- int h_adj = omap_dmm-lut_height / ydiv;
- int w_adj = omap_dmm-lut_width / xdiv;
+ int h_adj;
+ int w_adj;
unsigned long flags;
+ if (!omap_dmm) {
+ /* early return if dmm/tiler device is not initialized */
+ return 0;
+ }
+
+ h_adj = omap_dmm-lut_height / ydiv;
+ w_adj = omap_dmm-lut_width / xdiv;
+
map = kzalloc(h_adj * sizeof(*map), GFP_KERNEL);
global_map = kzalloc((w_adj + 1) * h_adj, GFP_KERNEL);
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/10] staging: drm/omap: Get DMM resources from hwmod
From: Andy Gross andy.gr...@ti.com
This patch splits the DMM off into a separate sub-device, in order to
utilize the platform device information that was created as part of
the OMAP hwmod entry for the DMM.
The driver probe function queries the iomem resource and IRQ using
standard platform_get functions.
The OMAP DRM driver now calls the platform_driver_register() function
for the subordinate DMM driver inside its probe function. This
guarantees the required order for the DMM and ensures the DMM resources
are available for use by the DRM driver.
Signed-off-by: Andy Gross andy.gr...@ti.com
Signed-off-by: Rob Clark r...@ti.com
---
drivers/staging/omapdrm/omap_dmm_tiler.c | 79 +
drivers/staging/omapdrm/omap_dmm_tiler.h | 11 +---
drivers/staging/omapdrm/omap_drv.c |6 ++
drivers/staging/omapdrm/omap_gem.c |8 +--
4 files changed, 68 insertions(+), 36 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index e4c7bb6..1ecb6a7 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -34,6 +34,8 @@
#include omap_dmm_tiler.h
#include omap_dmm_priv.h
+#define DMM_DRIVER_NAME dmm
+
/* mappings for associating views to luts */
static struct tcm *containers[TILFMT_NFORMATS];
static struct dmm *omap_dmm;
@@ -465,7 +467,12 @@ size_t tiler_vsize(enum tiler_fmt fmt, uint16_t w,
uint16_t h)
return round_up(geom[fmt].cpp * w, PAGE_SIZE) * h;
}
-int omap_dmm_remove(void)
+bool dmm_is_initialized(void)
+{
+ return omap_dmm ? true : false;
+}
+
+static int omap_dmm_remove(struct platform_device *dev)
{
struct tiler_block *block, *_block;
int i;
@@ -499,40 +506,49 @@ int omap_dmm_remove(void)
if (omap_dmm-irq != -1)
free_irq(omap_dmm-irq, omap_dmm);
+ iounmap(omap_dmm-base);
kfree(omap_dmm);
+ omap_dmm = NULL;
}
return 0;
}
-int omap_dmm_init(struct drm_device *dev)
+static int omap_dmm_probe(struct platform_device *dev)
{
int ret = -EFAULT, i;
struct tcm_area area = {0};
u32 hwinfo, pat_geom, lut_table_size;
- struct omap_drm_platform_data *pdata = dev-dev-platform_data;
-
- if (!pdata || !pdata-dmm_pdata) {
- dev_err(dev-dev, dmm platform data not present, skipping\n);
- return ret;
- }
+ struct resource *mem;
omap_dmm = kzalloc(sizeof(*omap_dmm), GFP_KERNEL);
if (!omap_dmm) {
- dev_err(dev-dev, failed to allocate driver data section\n);
+ dev_err(dev-dev, failed to allocate driver data section\n);
goto fail;
}
/* lookup hwmod data - base address and irq */
- omap_dmm-base = pdata-dmm_pdata-base;
- omap_dmm-irq = pdata-dmm_pdata-irq;
- omap_dmm-dev = dev-dev;
+ mem = platform_get_resource(dev, IORESOURCE_MEM, 0);
+ if (!mem) {
+ dev_err(dev-dev, failed to get base address resource\n);
+ goto fail;
+ }
+
+ omap_dmm-base = ioremap(mem-start, SZ_2K);
if (!omap_dmm-base) {
- dev_err(dev-dev, failed to get dmm base address\n);
+ dev_err(dev-dev, failed to get dmm base address\n);
goto fail;
}
+ omap_dmm-irq = platform_get_irq(dev, 0);
+ if (omap_dmm-irq 0) {
+ dev_err(dev-dev, failed to get IRQ resource\n);
+ goto fail;
+ }
+
+ omap_dmm-dev = dev-dev;
+
hwinfo = readl(omap_dmm-base + DMM_PAT_HWINFO);
omap_dmm-num_engines = (hwinfo 24) 0x1F;
omap_dmm-num_lut = (hwinfo 16) 0x1F;
@@ -556,7 +572,7 @@ int omap_dmm_init(struct drm_device *dev)
omap_dmm_irq_handler, omap_dmm);
if (ret) {
- dev_err(dev-dev, couldn't register IRQ %d, error %d\n,
+ dev_err(dev-dev, couldn't register IRQ %d, error %d\n,
omap_dmm-irq, ret);
omap_dmm-irq = -1;
goto fail;
@@ -575,25 +591,30 @@ int omap_dmm_init(struct drm_device *dev)
omap_dmm-lut = vmalloc(lut_table_size * sizeof(*omap_dmm-lut));
if (!omap_dmm-lut) {
- dev_err(dev-dev, could not allocate lut table\n);
+ dev_err(dev-dev, could not allocate lut table\n);
ret = -ENOMEM;
goto fail;
}
omap_dmm-dummy_page = alloc_page(GFP_KERNEL | __GFP_DMA32);
if (!omap_dmm-dummy_page) {
- dev_err(dev-dev, could not allocate dummy page\n);
+ dev_err(dev-dev, could not allocate dummy page\n);
ret = -ENOMEM;
goto fail;
}
+
+ /* set dma mask for device */
+ /* NOTE: this is a workaround for the hwmod not initializing properly */
+
[PATCH 10/10] staging: drm/omap: mmap of tiled buffers with stride 4kb
From: Rob Clark r...@ti.com
Deal with the case of buffers with virtual stride larger than one
page in fault_2d().
Signed-off-by: Rob Clark r...@ti.com
---
drivers/staging/omapdrm/omap_gem.c | 86 ---
1 files changed, 59 insertions(+), 27 deletions(-)
diff --git a/drivers/staging/omapdrm/omap_gem.c
b/drivers/staging/omapdrm/omap_gem.c
index 5abd294..921f058 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -153,10 +153,23 @@ static void evict_entry(struct drm_gem_object *obj,
enum tiler_fmt fmt, struct usergart_entry *entry)
{
if (obj-dev-dev_mapping) {
- size_t size = PAGE_SIZE * usergart[fmt].height;
+ struct omap_gem_object *omap_obj = to_omap_bo(obj);
+ int n = usergart[fmt].height;
+ size_t size = PAGE_SIZE * n;
loff_t off = mmap_offset(obj) +
(entry-obj_pgoff PAGE_SHIFT);
- unmap_mapping_range(obj-dev-dev_mapping, off, size, 1);
+ const int m = 1 + ((omap_obj-width fmt) / PAGE_SIZE);
+ if (m 1) {
+ int i;
+ /* if stride than PAGE_SIZE then sparse mapping: */
+ for (i = n; i 0; i--) {
+ unmap_mapping_range(obj-dev-dev_mapping,
+ off, PAGE_SIZE, 1);
+ off += PAGE_SIZE * m;
+ }
+ } else {
+ unmap_mapping_range(obj-dev-dev_mapping, off, size,
1);
+ }
}
entry-obj = NULL;
@@ -342,26 +355,39 @@ static int fault_2d(struct drm_gem_object *obj,
void __user *vaddr;
int i, ret, slots;
- if (!usergart)
- return -EFAULT;
-
- /* TODO: this fxn might need a bit tweaking to deal w/ tiled buffers
-* that are wider than 4kb
+ /*
+* Note the height of the slot is also equal to the number of pages
+* that need to be mapped in to fill 4kb wide CPU page. If the slot
+* height is 64, then 64 pages fill a 4kb wide by 64 row region.
+*/
+ const int n = usergart[fmt].height;
+ const int n_shift = usergart[fmt].height_shift;
+
+ /*
+* If buffer width in bytes PAGE_SIZE then the virtual stride is
+* rounded up to next multiple of PAGE_SIZE.. this need to be taken
+* into account in some of the math, so figure out virtual stride
+* in pages
*/
+ const int m = 1 + ((omap_obj-width fmt) / PAGE_SIZE);
/* We don't use vmf-pgoff since that has the fake offset: */
pgoff = ((unsigned long)vmf-virtual_address -
vma-vm_start) PAGE_SHIFT;
- /* actual address we start mapping at is rounded down to previous slot
+ /*
+* Actual address we start mapping at is rounded down to previous slot
* boundary in the y direction:
*/
- base_pgoff = round_down(pgoff, usergart[fmt].height);
- vaddr = vmf-virtual_address - ((pgoff - base_pgoff) PAGE_SHIFT);
- entry = usergart[fmt].entry[usergart[fmt].last];
+ base_pgoff = round_down(pgoff, m n_shift);
+ /* figure out buffer width in slots */
slots = omap_obj-width usergart[fmt].slot_shift;
+ vaddr = vmf-virtual_address - ((pgoff - base_pgoff) PAGE_SHIFT);
+
+ entry = usergart[fmt].entry[usergart[fmt].last];
+
/* evict previous buffer using this usergart entry, if any: */
if (entry-obj)
evict_entry(entry-obj, fmt, entry);
@@ -369,23 +395,30 @@ static int fault_2d(struct drm_gem_object *obj,
entry-obj = obj;
entry-obj_pgoff = base_pgoff;
- /* now convert base_pgoff to phys offset from virt offset:
-*/
- base_pgoff = (base_pgoff usergart[fmt].height_shift) * slots;
-
- /* map in pages. Note the height of the slot is also equal to the
-* number of pages that need to be mapped in to fill 4kb wide CPU page.
-* If the height is 64, then 64 pages fill a 4kb wide by 64 row region.
-* Beyond the valid pixel part of the buffer, we set pages[i] to NULL to
-* get a dummy page mapped in.. if someone reads/writes it they will get
-* random/undefined content, but at least it won't be corrupting
-* whatever other random page used to be mapped in, or other undefined
-* behavior.
+ /* now convert base_pgoff to phys offset from virt offset: */
+ base_pgoff = (base_pgoff n_shift) * slots;
+
+ /* for wider-than 4k.. figure out which part of the slot-row we want: */
+ if (m 1) {
+ int off = pgoff % m;
+ entry-obj_pgoff += off;
+ base_pgoff /= m;
+ slots = min(slots - (off n_shift), n);
+ base_pgoff +=
[PATCH] omap2+: add drm device
From: Andy Gross andy.gr...@ti.com
Register OMAP DRM/KMS platform device, and reserve a CMA region for
the device to use for buffer allocation. DMM is split into a
separate device using hwmod.
Signed-off-by: Andy Gross andy.gr...@ti.com
Signed-off-by: Rob Clark r...@ti.com
---
arch/arm/plat-omap/Makefile |2 +-
arch/arm/plat-omap/common.c |3 +-
arch/arm/plat-omap/drm.c | 83 +
arch/arm/plat-omap/include/plat/drm.h | 64 +
4 files changed, 150 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/plat-omap/drm.c
create mode 100644 arch/arm/plat-omap/include/plat/drm.h
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 9a58461..b86e6cb 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -4,7 +4,7 @@
# Common support
obj-y := common.o sram.o clock.o devices.o dma.o mux.o \
-usb.o fb.o counter_32k.o
+usb.o fb.o counter_32k.o drm.o
obj-m :=
obj-n :=
obj- :=
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 06383b5..0d87dab 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -21,10 +21,10 @@
#include plat/board.h
#include plat/vram.h
#include plat/dsp.h
+#include plat/drm.h
#include plat/omap-secure.h
-
#define NO_LENGTH_CHECK 0x
struct omap_board_config_kernel *omap_board_config __initdata;
@@ -65,6 +65,7 @@ const void *__init omap_get_var_config(u16 tag, size_t *len)
void __init omap_reserve(void)
{
+ omapdrm_reserve_vram();
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
omap_dsp_reserve_sdram_memblock();
diff --git a/arch/arm/plat-omap/drm.c b/arch/arm/plat-omap/drm.c
new file mode 100644
index 000..28279df
--- /dev/null
+++ b/arch/arm/plat-omap/drm.c
@@ -0,0 +1,83 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/mm.h
+#include linux/init.h
+#include linux/platform_device.h
+#include linux/dma-mapping.h
+#ifdef CONFIG_CMA
+# include linux/dma-contiguous.h
+#endif
+
+#include plat/omap_device.h
+#include plat/omap_hwmod.h
+
+#include plat/drm.h
+
+#if defined(CONFIG_DRM_OMAP) || (CONFIG_DRM_OMAP_MODULE)
+
+static struct omap_drm_platform_data omapdrm_platdata;
+
+static struct platform_device omap_drm_device = {
+ .dev = {
+ .coherent_dma_mask = DMA_BIT_MASK(32),
+ .platform_data = omapdrm_platdata,
+ },
+ .name = omapdrm,
+ .id = 0,
+};
+
+static int __init omap_init_gpu(void)
+{
+ struct omap_hwmod *oh = NULL;
+ struct platform_device *pdev;
+
+ /* lookup and populate the DMM information, if present - OMAP4+ */
+ oh = omap_hwmod_lookup(dmm);
+
+ if (oh) {
+ pdev = omap_device_build(oh-name, -1, oh, NULL, 0, NULL, 0,
+ false);
+ WARN(IS_ERR(pdev), Could not build omap_device for %s\n,
+ oh-name);
+ }
+
+ return platform_device_register(omap_drm_device);
+
+}
+
+arch_initcall(omap_init_gpu);
+
+void omapdrm_reserve_vram(void)
+{
+#ifdef CONFIG_CMA
+ /*
+* Create private 32MiB contiguous memory area for omapdrm.0 device
+* TODO revisit size.. if uc/wc buffers are allocated from CMA pages
+* then the amount of memory we need goes up..
+*/
+ dma_declare_contiguous(omap_drm_device.dev, 32 * SZ_1M, 0, 0);
+#else
+# warning CMA is not enabled, there may be limitations about scanout buffer
allocations on OMAP3 and earlier
+#endif
+}
+
+#endif
diff --git a/arch/arm/plat-omap/include/plat/drm.h
b/arch/arm/plat-omap/include/plat/drm.h
new file mode 100644
index 000..df9bc41
--- /dev/null
+++ b/arch/arm/plat-omap/include/plat/drm.h
@@ -0,0 +1,64 @@
+/*
+ * DRM/KMS device registration for TI OMAP platforms
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark rob.cl...@linaro.org
+ *
+ * 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
[PATCH] arm: omap: add minimal support for Nokia RM-696
Add minimal support for Nokia RM-696 board. Signed-off-by: Aaro Koskinen aaro.koski...@nokia.com --- The patch is based boot-tested with 3.3-rc6. arch/arm/mach-omap2/Kconfig |3 ++- arch/arm/mach-omap2/board-rm680.c| 14 +- arch/arm/plat-omap/include/plat/uncompress.h |1 + 3 files changed, 16 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index e20c8ab..b740c2e 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -245,10 +245,11 @@ config MACH_NOKIA_N8X0 select MACH_NOKIA_N810_WIMAX config MACH_NOKIA_RM680 - bool Nokia RM-680 board + bool Nokia RM-680/696 board depends on ARCH_OMAP3 default y select OMAP_PACKAGE_CBB + select MACH_NOKIA_RM696 config MACH_NOKIA_RX51 bool Nokia RX-51 board diff --git a/arch/arm/mach-omap2/board-rm680.c b/arch/arm/mach-omap2/board-rm680.c index 8678b38..094473e 100644 --- a/arch/arm/mach-omap2/board-rm680.c +++ b/arch/arm/mach-omap2/board-rm680.c @@ -1,5 +1,5 @@ /* - * Board support file for Nokia RM-680. + * Board support file for Nokia RM-680/696. * * Copyright (C) 2010 Nokia * @@ -154,3 +154,15 @@ MACHINE_START(NOKIA_RM680, Nokia RM-680 board) .timer = omap3_timer, .restart= omap_prcm_restart, MACHINE_END + +MACHINE_START(NOKIA_RM696, Nokia RM-696 board) + .atag_offset= 0x100, + .reserve= omap_reserve, + .map_io = omap3_map_io, + .init_early = omap3630_init_early, + .init_irq = omap3_init_irq, + .handle_irq = omap3_intc_handle_irq, + .init_machine = rm680_init, + .timer = omap3_timer, + .restart= omap_prcm_restart, +MACHINE_END diff --git a/arch/arm/plat-omap/include/plat/uncompress.h b/arch/arm/plat-omap/include/plat/uncompress.h index 6ee9049..cc3f11b 100644 --- a/arch/arm/plat-omap/include/plat/uncompress.h +++ b/arch/arm/plat-omap/include/plat/uncompress.h @@ -160,6 +160,7 @@ static inline void __arch_decomp_setup(unsigned long arch_id) DEBUG_LL_OMAP3(3, igep0020); DEBUG_LL_OMAP3(3, igep0030); DEBUG_LL_OMAP3(3, nokia_rm680); + DEBUG_LL_OMAP3(3, nokia_rm696); DEBUG_LL_OMAP3(3, nokia_rx51); DEBUG_LL_OMAP3(3, omap3517evm); DEBUG_LL_OMAP3(3, omap3_beagle); -- 1.7.2.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: Ethernet problems on AM3517, possible regression?
** Sorry this is almost certainly going to the wrong place for this post to land. I'm still trying to sort out how to properly use this list. I have tried subscribing, but that tends to flood my inbox with everything going on here. That's great, but timewise I haven't been able to follow it closely enough to keep it sorted at the moment. Is there a way to simply subscribe to certain threads, like those one posts or replies to? Once I unsubscribed from the list, I started receiving no messages - even responses to questions I ask, etc. :-( Thanks. ** Hi Igor, Thanks for your reply! So are both ports working on the CM-T3517 simultaneously now? Looking at the latest board file for the CM-T3517 (arch/arm/mach-omap2/board-cm-t3517.c), I don't see either the SMSC or the EMAC ports being initialized. Has that initialization code been moved somewhere else in the kernel? Regarding the patches: I had actually seen those (in the previous version #2 I believe), and applied them to our kernel. If you take a look at my board file below, you'll notice I defined a USE_ALT__EMAC_ETH definition that causes the separate EMAC file (created by those patches) to be used. I've tried both the old and the new (separate file) way of doing this. Our EMAC does work fine, as does our SMSC, except our SMSC does not store a MAC address. They just do not work together. One or the other must be disabled (commented out of the code) or neither work. It appears to me that the problem with running both is the mdio id setting. Perhaps they're both demanding the same slot or something? Thanks again for your reply. Please let me if I'm looking in the wrong place for any of this or have this mixed up. - Original Message - From: CF Adad cfa...@rocketmail.com To: linux-omap@vger.kernel.org linux-omap@vger.kernel.org Cc: Sent: Thursday, March 1, 2012 6:16 PM Subject: Ethernet problems on AM3517, possible regression? We have both a CompuLab CM-T3517 and a Technexion TAM-3517 at the shop. Both boards provide dual Ethernet support in an identical fashion. One port uses the onboard EMAC tied to an SMSC LAN87xx series PHY. The other is the old trusty SMSC LAN911X hooked up to the GPMC. Both boards support both interfaces when loaded with their respective TI PSP-based images. These unfortunately date clear back to 2.6.37 or even 2.6.32 however. When upgrading to the 3.x series linux-omap kernel, we noticed we could get one or the other of these to work, _but not both simultaneously_. If both are enabled in code, neither work. Even when we can get one or the other working, we seem to be having some problems with autonegotiation and MAC addressing. MAC addresses on the SMSC are still random. On the EMAC port, as you can see from our code below, we have put a patch in that is letting us establish a fixed MAC address. However, I'm not sure this is a proper method to use at this point. We suspect issues are known to exist with the Ethernet ports as the CM-T3517 has mainlined Linux support, and its latest board file does not show any configuration for either Ethernet interface. Support from the previous kernel versions has apparently been removed, despite patches being applied to it as recently as mid-last year: http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050430.html We also suspect this is being caused by an address conflict of some sort between the two ports. We are using a linux-omap kernel, version 3.2.0-rc6 that is a month or two old now. We've been monitoring this list, and have noted that some changes have been checked in for SMSC, but have not been able to update our kernel source as we were in the midst of a heavy debugging exercise that ended late last evening. We plan to migrate to the latest HEAD soon. Neverthelss, we've not seen any of these board files update. So, we're assuming there are still known issues here. I have attached the relevant sections of the board file we've created for the TAM-3517 (the one we've played with the most) below. It is based off the older board files from the TI PSP and various configurations we have seen in similar hardware board files (overo, am3517_evm, cm-t3517, etc.) If you note the configurable defines at the top, we've tied various combinations of code with no success to date. Would you folks please take a look? Any help would be appreciated. Thanks! - __NOTES:__ ***When we run with just the SMSC enabled, the device works: ... [ 1.119415] smsc911x: Driver version 2008-10-21 [ 1.126739] smsc911x-mdio: probed [ 1.130554] smsc911x smsc911x: eth0: attached PHY driver [SMSC LAN8700] (mii_bus:phy_addr=:01, irq=-1) [ 1.142456] smsc911x smsc911x: eth0: MAC Address: d6:b4:7d:2c:03:40 ... root@board:~# ifdown eth0 root@board:~# ifup eth0 [ 187.145019]
Re: [PATCH] Linux OMAP: Add omap_reserve functionality
* Alex al...@meprolight.com [111214 04:23]: This patch adds omap_reserve functionality to board-omap3logic.c Thanks applying into board branch. 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] OMAP3: RX-51: add explicit mux configuration of tsc2005 control gpios
* Vladimir Zapolskiy v...@mleia.com [111214 12:02]: This change converts TSC2005 related GPIO requests to be done with gpio_request_array() method and explicitly inits mux configuration for these GPIOs. Thanks applying into board branch. 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: OMAP2+: voltage: ensure voltage used is exact voltage from OPP table
Tero Kristo t-kri...@ti.com writes: On Fri, 2012-03-02 at 14:42 -0800, Kevin Hilman wrote: When using the SMPS regulators to scale voltages, the regulator framework may pass a minimum voltage that is not an exact OPP voltage. For the VC/VP controlled voltage domains, we must ensure that the voltage requested is the exact voltage from the OPP table. This is especially critical when using SR. To fix, voltdm_scale() uses the target voltage passed to walk through the OPP voltages until it finds a voltage that is = one of the OPP voltages. I have just one question to this, how about smartreflex class1p5? Do we have any plans for that one? The old implementation at least was using voltdm_scale, so if we modify this function, smartreflex class1p5 doesn't work anymore. Since it's not in mainline, that is not my concern at the moment. We can worry about SR1.5 when I someone is motivated to push it upstream. Otherwise this patch looks good to me. Thanks for looking. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] ARM: OMAP2+: gpmc-smsc911x: add required smsc911x regulators
Felipe Balbi ba...@ti.com writes:
Hi,
On Thu, Mar 01, 2012 at 12:36:57PM -0800, Kevin Hilman wrote:
Matt Porter mpor...@ti.com writes:
This fixes smsc911x support on platforms using gpmc_smsc911x_init().
Commit c7e963f616 (net/smsc911x: Add regulator support) added
the requirement that platforms provide vdd33a and vddvario supplies.
Signed-off-by: Matt Porter mpor...@ti.com
[...]
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -55,6 +101,12 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
+ ret = platform_device_register(gpmc_smsc911x_regulator);
+ if (ret 0) {
+ pr_err(Unable to register smsc911x regulators: %d\n, ret);
+ return;
+ }
+
Boards that have more than one instance of the smsc911x (OMAP3/Overo)
barf here because of trying to register the same device twice.
We need something like the patch below to make Overo boot again.
Kevin
From 4114dea2fb897ab75d05eaa943d29454034fc025 Mon Sep 17 00:00:00 2001
From: Kevin Hilman khil...@ti.com
Date: Thu, 1 Mar 2012 12:30:42 -0800
Subject: [PATCH] ARM: OMAP2+: gpmc-smsc911x: only register regulators once
commit e4b0b2cbbb (ARM: OMAP2+: gpmc-smsc911x: add required smsc911x
regulators) added regulators which are registered during
gpmc_smsc911x_init(). However, some platforms (OMAP3/Overo) have more
than one instance of the SMSC911x and result in attempting to register
the same regulator more than once which causes a panic(). Fix this by
tracking the regulator registration ensuring only a single device is
registered.
Cc: Matt Porter mpor...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/gpmc-smsc911x.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-smsc911x.c
b/arch/arm/mach-omap2/gpmc-smsc911x.c
index bbb870c..95e6c7d 100644
--- a/arch/arm/mach-omap2/gpmc-smsc911x.c
+++ b/arch/arm/mach-omap2/gpmc-smsc911x.c
@@ -88,6 +88,8 @@ static struct platform_device gpmc_smsc911x_regulator = {
},
};
+static bool regulator_registered;
+
/*
* Initialize smsc911x device connected to the GPMC. Note that we
* assume that pin multiplexing is done in the board-*.c file,
@@ -101,10 +103,14 @@ void __init gpmc_smsc911x_init(struct
omap_smsc911x_platform_data *board_data)
gpmc_cfg = board_data;
-ret = platform_device_register(gpmc_smsc911x_regulator);
-if (ret 0) {
-pr_err(Unable to register smsc911x regulators: %d\n, ret);
-return;
+if (!regulator_registered) {
+ret = platform_device_register(gpmc_smsc911x_regulator);
+if (ret 0) {
+pr_err(Unable to register smsc911x regulators: %d\n,
+ ret);
+return;
+}
+regulator_registered = true;
Wow, this is quite a hack. Is the regulator part of the SMSC911x
device or is it outside ? If it's outside the SMSC91xx (which I
believe it is) there should be a regulator driver instead of this
hack. For boards which don't provide such a regulator (and tie the
supply pin to some constant voltage source) there should be a constant
regulator supplying the pin. But this patch is quite hacky.
Are you referring to my patch or to the original $SUBJECT patch? It's
not terribly clear.
My patch doesn't add any regulators, it just fixes a bug when this init
function is called more than once.
The addition of the regulators was done in $SUBJECT patch, not my fix.
In either case $SUBJECT patch is already in Tony's fixes queue, so if it
is going be merged, then my fix above is needed also to not break
Overo and any other platform that has more than one smsc911x instance.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/2] ARM: OMAP: move generic EMAC init to separate file
* Igor Grinberg grinb...@compulab.co.il [120301 00:47]: From: Ilya Yanok ya...@emcraft.com AM35xx SoCs include DaVinci EMAC IP. Initialization code in board-am3517evm.c is pretty board independent and will work for any AM35xx based board so move this code to it's own file to be reused by other boards. Signed-off-by: Ilya Yanok ya...@emcraft.com Signed-off-by: Igor Grinberg grinb...@compulab.co.il --- v3: - use DEFINE_RES_* macros - check error of platform_device_register() - introduce a default MDIO bus frequency define Tony, this patch has been floating for about two months: http://www.spinics.net/lists/linux-omap/msg62160.html can it be applied for 3.4? Yes sorry for the delays, applying this and the related cm-t3517 patch to board branch. 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] RM: OMAP4: board-4430sdp: don't initialize value that is never used
* Uwe Kleine-König u.kleine-koe...@pengutronix.de [120209 13:00]: sdp4430_spi_board_info.irq was initialized to ETH_KS8851_IRQ and in omap_4430sdp_init() overwritten with gpio_to_irq(ETH_KS8851_IRQ) before sdp4430_spi_board_info was registered. This is a bit confusing, so better don't initialize .irq and document that it is set later. Thanks applying into board branch. 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: help: BeagleBoard xM RevC ethernet port
* Peter Ujfalusi peter.ujfal...@ti.com [120305 01:21]: On 02/28/2012 04:04 PM, Govindraj wrote: The issue seems to a mux conflict issue, uart2_rx mux is been taken by uart init and gpio_147 needed for usb phy init is not in mux mode4 as set by bootloader. On beagle I see no other uarts being used other than uart3 as console_uart. So I think it should be okay to init only uart3 from beagle board data. Here is the patch [1] to do the same. (Tested on Beagle Xm Rev.C) (Any other approach is welcome) Thank you, I have working ethernet port finally!!! From f1b43f983a2926c637e6bc6ab5d1e5044339ffd3 Mon Sep 17 00:00:00 2001 From: Govindraj.R govindraj.r...@ti.com Date: Tue, 28 Feb 2012 19:16:33 +0530 Subject: [PATCH] omap3_beagle: Init only uart3 used for console On beagle some of uart mux lines are used for other purpose so init only uart3. Uart2 rx line clashes with gpio_147 used for usb ehci phy reset. Tested-by: Peter Ujfalusi peter.ujfal...@ti.com Thanks applying into board branch. 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: [RFC PATCH] of: DMA helpers: manage generic requests specification
Cousson, Benoit wrote at Monday, March 05, 2012 6:14 AM: On 2/29/2012 9:54 PM, Stephen Warren wrote: Nicolas Ferre wrote at Wednesday, February 29, 2012 7:54 AM: By making DMA controllers register a generic translation function, we allow the management of any type of DMA requests specification. The void * output of an of_dma_xlate() function that will be implemented by the DMA controller can carry any type of dma-request argument. The DMA client will search its associated DMA controller in the list and call the registered of_dam_xlate() function to retrieve the request values. One simple xlate function is provided for the single number type of request biding. This implementation is independent from dmaengine so it can also be used by legacy drivers. At a high level this seems along the right lines. The big issue I see is the lack of type-safety in of_get_dma_request()'s out_data pointer: The DMA xlate function will assume it points at some particular type, and the client is responsible for allocating that correct type. However, it's user-supplied device tree data that hooks the two together, and there could easily be mismatches, thus causing the xlate function to trash memory. Could each DMA controller (or type of out_data) have some enum in the kernel that the client passes in, and the DMA engine validates matches its expectations, to prevent this kind of thing? Beside u32 and string, do we know what kind of parameters we can expect to retrieve? Because we can potentially reduce the scope to these two types only. I wondered whether different drivers would return arbitrary driver-specific structs, so that the DT specific would encode not only the DMA request number, but perhaps some/all of the DMA parameters like transfer size, wrap, even DMA FIFO address, ... Still, there might not be much point in doing that, since drivers (at least on Tegra) are already manually passing this information to the DMA driver in the non-DT case, so we can just continue doing that same thing. -- nvpublic -- 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: pandora: add support for backlight and poweroff
* Grazvydas Ignotas nota...@gmail.com [120218 14:15]: Add platform data for drivers that recently appeared in kernel: backlight and TWL4030 poweroff support. Thanks applying into board branch. 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 RESEND] ARM: OMAP: enable Bluetooth on the PandaBoard
* Mircea Gherzan mgher...@gmail.com [120223 09:21]: The PandaBoard features a Texas Instruments WiLink7 Bluetooth chip, supported by the btwilink driver. Thanks applying into board branch. 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: add minimal support for Nokia RM-696
* Aaro Koskinen aaro.koski...@nokia.com [120305 08:25]: Add minimal support for Nokia RM-696 board. Thanks applying into board branch. 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: OMAP4: Add support for Variscite OMAP4460 System-On-Module
Hi, * Uri Yosef ur...@variscite.com [120118 06:13]: From: Uri Yosef u...@embedox.com Add support for Variscite OMAP4460 System-On-Module and development kit board. Working: LCD, HDMI, USB, UART, Ethernet. For reference, we're trying to remove board-*.c files by changing over to device tree. So new board-*.c files will be merged. You might want to look at booting your board using board-generic.c and a related .dts file. While this transition is happening, I can carry some board-*.c files in the testing-board branch until devices start working sufficiently for board-generic.c to be usable. 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: OMAP totally fucked?
* Russell King - ARM Linux li...@arm.linux.org.uk [120304 07:27]: On Sat, Mar 03, 2012 at 01:05:21PM -0800, Tony Lindgren wrote: * Arnd Bergmann a...@arndb.de [120303 09:57]: On Saturday 03 March 2012, Tony Lindgren wrote: Well 85631d2 builds fine, looks like now some more includes of plat/hardware.h are now needed.Have not yet tracked down which commit triggers the build errors. Eventually those should become local headers too.. I've tried building arm-soc/for-next and rmk/for-next, they are both fine, just merging the two gives me the same build errors that Russell saw. Adding plat/hardware.h in all files that break solves the problems, aside from the iommu dependency for rpmsg for which Ohad has provided a fix already that I should pull. Here's a patch for you to the cleanup branch to fix the hardware.h build errors. Right, with this applied, things are better: 1. omap3430ldp allnoconfig is the first build without warnings, congrats. 2. omap4430sdp allnoconfig has a bunch of new section mismatch warnings, a couple of compiler warnings, and builds: WARNING: arch/arm/mach-omap2/built-in.o(.text+0x183c): Section mismatch in reference from the function omap2_init_processor_devices() to the function .init.text:_init_omap_device() The function omap2_init_processor_devices() references the function __init _init_omap_device(). This is often because omap2_init_processor_devices lacks a __init annotation or the annotation of _init_omap_device is wrong. arch/arm/mach-omap2/io.c:51: warning: 'omap24xx_io_desc' defined but not used arch/arm/mach-omap2/omap-wakeupgen.c:181: warning: 'wakeupgen_irqmask_all' defined but not used 3. omap4430sdp randconfig built with these omap specific warnings (exluding ones already mentioned): arch/arm/mach-omap2/board-n8x0.c:39: warning: 'slot1_cover_open' defined but not used arch/arm/mach-omap2/board-n8x0.c:40: warning: 'slot2_cover_open' defined but not used arch/arm/mach-omap2/board-n8x0.c:41: warning: 'mmc_device' defined but not used I'll do some patches to fix these warnings. and, of course, this is with these configs building OMAP2..OMAP4 because of the config. That should get fixed soon too with revert. 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 v3 1/3] ARM: OMAP1: ams-delta: set up regulator over modem reset GPIO pin
* Janusz Krzysztofik jkrzy...@tis.icnet.pl [120305 07:35]: The Amstrad Delta on-board latch2 bit named MODEM_NRESET, now available as a GPIO pin AMS_DELTA_GPIO_PIN_NMODEM_RESET, is used to power up/down (bring into/out of a reset state) two distinct on-board devices simultaneously: the modem, and the voice codec. As a consequence, that bit is, or can be, manipulated concurrently by two drivers, or their platform provided hooks. Instead of updating those drivers to use the gpiolib API as a new method of controlling the MODEM_NRESET pin state, like it was done to other drivers accessing latch2 pins, and still being vulnerable to potential concurrency conflicts, or trying to solve that sharing issue with a custom piece of code, set up a fixed regulator device on top of that GPIO pin, with the intention of updating both drivers to manipulate that regulator, not the GPIO pin directly. Before the ASoC driver is updated and the modem platform data expanded with a power management callback for switching its power, the ams_delta_latch_write() function, which still provides the old API for accessing latch2 functionality from not updated drivers, is modified to toggle the regulator instead of the MODEM_NRESET GPIO pin. A helper function provided for balancing the regulator enable/disable operations, together with the consumer data needed for tracking the regulator state, will be removed once the drivers are updated. Depends on patch series ARM: OMAP1: ams-delta: replace custom I/O with GPIO. Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl --- v2 - v3 changes: * fix section mismatch isue. Changes against initial version: * rename consumer setup elements to match their final, modem only related purpose, * initialize the regulator pointer and mutex before first use, then omit testing that pointer against NULL value Thanks, applying all three into ams-delta branch. 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: Incorrect Register Offsets in OMAP Mailbox
Hi Henry, * Henry Chan enli.c...@gmail.com [120207 09:25]: Hi, Looks like the register offsets are incorrect in the OMAP mailbox code (arch/arm/mach-omap2/mailbox.c) for the OMAP4_MAILBOX_IRQ* macros. The discrepancy is with p.224 of TI document SPRUGX9 and p3891 of SWPU231K. Patch attached. My hardware hasn't come in yet, so I would appreciate it if anyone can share their experience using this code. Can you please reply with your Signed-off-by, it's missing from the patch. Thanks, Tony --- a/arch/arm/mach-omap2/mailbox.c +++ b/arch/arm/mach-omap2/mailbox.c @@ -26,9 +26,9 @@ #define MAILBOX_IRQSTATUS(u) (0x100 + 8 * (u)) #define MAILBOX_IRQENABLE(u) (0x104 + 8 * (u)) -#define OMAP4_MAILBOX_IRQSTATUS(u) (0x104 + 10 * (u)) -#define OMAP4_MAILBOX_IRQENABLE(u) (0x108 + 10 * (u)) -#define OMAP4_MAILBOX_IRQENABLE_CLR(u) (0x10c + 10 * (u)) +#define OMAP4_MAILBOX_IRQSTATUS(u) (0x104 + 0x10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE(u) (0x108 + 0x10 * (u)) +#define OMAP4_MAILBOX_IRQENABLE_CLR(u) (0x10c + 0x10 * (u)) #define MAILBOX_IRQ_NEWMSG(m)(1 (2 * (m))) #define MAILBOX_IRQ_NOTFULL(m) (1 (2 * (m) + 1)) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] ARM: OMAP: dmtimer: fix missing content/correction in low-power mode support
* Tarun Kanti DebBarma tarun.ka...@ti.com [111206 21:25]: Since omap_dm_timer_write_reg/__omap_dm_timer_write is now modified to use timer-func_base OCP_CFG should not use this wrapper anymore. Instead use __raw_writel() directly and use timer-io_base instead to write to OCP_CFG. The timer-sys_stat is valid only if timer-revision is 1. In the context restore function make this correction. Save the contexts and loss count when timer is stopped. Also, disable the clock. Else, clock usecount would become imbalanced. Signed-off-by: Tarun Kanti DebBarma tarun.ka...@ti.com Tested-by: Omar Ramirez Luna omar.rami...@ti.com Thanks applying this to fixes-non-critical-part2. Sorry for the delays, looks like I'm a bit behind with patches.. 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: pandora: fix usbhs platform data
* Grazvydas Ignotas nota...@gmail.com [120218 14:11]: It turned out wrong OMAP HSUSB port was configured on pandora, but still managed to work somehow. This was noticed after enabling in-kernel mux, where USB muxing was causing other devices not to work, because hsusb1 pins (instead of hsusb2) were wrongly remuxed, which are used for other things on pandora. Thanks, adding this to fixes-non-critical-part2. 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] plat-omap: mcbsp: Configure wakeup in later phase
Peter, * Peter Ujfalusi peter.ujfal...@ti.com [111215 01:03]: Configure the WAKEUPEN register at the same time we configure the rest of the McBSP registers. In case of OMAP3+, if the sysclock has been reconfigured we are going to disable McBSP for the duration of the clock change, which will reset the McBSP registers. The WAKEUPEN register need to be configured later, so the changes will be effective during runtime. Just checking.. I assume this one is already taken care of with your other McBSP changes? 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 V3 1/2] mcx: very basic support for HTKW mcx board
* Ilya Yanok ya...@emcraft.com [111221 07:22]:
Very basic support for HTKW mcx board. Able to boot via board-generic
and ramdisk/initramfs, however most of peripherals is unsupported.
Produces tons of twl4030 related errors as this board doesn't have
twl4030 installed.
Signed-off-by: Ilya Yanok ya...@emcraft.com
Grant, care to ack this one?
Regards,
Tony
---
Changes from V2:
- None
Changes from V1:
- device tree move to the separate patch
- iva node is disabled instead of using custom includes
- removed bootargs entry
arch/arm/boot/dts/mcx.dts | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/mcx.dts
diff --git a/arch/arm/boot/dts/mcx.dts b/arch/arm/boot/dts/mcx.dts
new file mode 100644
index 000..66b81bd
--- /dev/null
+++ b/arch/arm/boot/dts/mcx.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
+ *
+ * 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 = HTKW mcx;
+ compatible = htkw,mcx, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ /* AM35xx doesn't have IVA */
+ soc {
+ iva {
+ status = disabled;
+ };
+ };
+};
--
1.7.6.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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 2/2] mcx: support for HTKW mcx board
* Ilya Yanok ya...@emcraft.com [111221 07:21]: Support for the HTKW mcx board (TI AM3517 based) including serial, Ethernet, I2C, USB host, HSMMC, DSS and RTC. This one I can carry in testing-board until device tree works for us in a usable way. But probably some rebasing is needed for this after the hsmmc stuff is cleared out of the way. 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] OMAP2+: ads7846_init: put gpio_pendown into pdata if it's provided
* Ilya Yanok ya...@emcraft.com [111222 05:29]: If platform data is provided by the caller gpio_pendown is put into unused static ads7846_config structure and effectively has no effect. Of course caller can set gpio_pendown field in platform data himself but it seems natural to do this in ads7846_init to remove duplication. Thanks applying into fixes-non-critical-part2. 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: [RFC PATCH] of: DMA helpers: manage generic requests specification
On Mon, Mar 05, 2012 at 10:30:43AM -0800, Stephen Warren wrote: Cousson, Benoit wrote at Monday, March 05, 2012 6:14 AM: Beside u32 and string, do we know what kind of parameters we can expect to retrieve? Because we can potentially reduce the scope to these two types only. I wondered whether different drivers would return arbitrary driver-specific structs, so that the DT specific would encode not only the DMA request number, but perhaps some/all of the DMA parameters like transfer size, wrap, even DMA FIFO address, ... Right. The thing to consider here is: what information does the driver already have about the device? - physical address of the data register - size of the data register - it certainly should know the fifo depth (think - if it has to do PIO then it needs this information already.) so, there's no point putting that information into DT because it must be known by the driver for systems not using DMA. We have a standardized way to pass this information to DMA engine drivers from the peripheral device driver: struct dma_slave_config. What is outside of the scope of the driver is knowing how a peripheral device is connected to a set of DMA engines. That's a much harder problem to solve because there's many varied ways to do that in hardware, from a static mapping between the peripheral and a DMA engine request signal, to implementations which have some kind of front end MUX, to there being several choices of DMA engine for the peripheral (I believe some Samsung platforms fall into this category.) Some of those problems can be solved by redesigning the DMA engine drivers to have a clear way to handle DMA engines with multiple request inputs shared between multiple channels: you treat the individual request inputs as separate DMA engine channels, and when there is work to be done, you allocate the DMA engine channel to a physical DMA engine and physical channel. That's not going to be easy to do at the moment, because every DMA engine driver is custom written from the ground up with no commonality between them (I've mentioned this in previous email threads.) I think, before trying to design some kind of DT based representation of how to bind DMA stuff to peripheral drivers, the very first thing that needs to happen is the DMA engine drivers need sorting so that they all work in mostly the same way in terms of how channels are allocated to peripherals. Only once we have a consistent way that's done can we then start looking at what kind of representation is needed to bind the two together. Otherwise, we're going to end up with the OMAP way of binding channels, the PL08x way, the SA11x0 way, etc and its going to become very very unfunny to sort this out later. -- 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] omap3_beagle: Init only uart3 used for console
Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com On beagle some of uart mux lines are used for other purpose so init only uart3. OK, but you should also be clear that this patch is effectively disabling all UARTS (except UART3) by defatul, which I'm not sure all Beagle users will be happy about. Uart2 rx line clashes with gpio_147 used for usb ehci phy reset. Initializing uart2 pad_mux lines can break ehci module on beagle xm. (gpio_147 is available on uart2_rx in mode4 reference mux34xx.c - uart2_rx.gpio_147) As Koen mentioned, this conflict only exists on certain boards, so you should be clear that this is just an example. Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Tested-by: Peter Ujfalusi peter.ujfal...@ti.com Tested-by: Robert Nelson robertcnel...@gmail.com Signed-off-by: Govindraj.R govindraj.r...@ti.com [...] + +static inline void board_serial_init(void) Should be __init [...] +static inline void board_serial_init(void) here too. Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: omap_device: call all suspend, resume callbacks when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set
On Mon, 5 Mar 2012, Kevin Hilman wrote: Tony, this fix is needed for v3.3. Of course, I don't have any objection to this patch going into the v3.3-rc kernels. But given that some maintainers seem to be pushing back against late -rc patches, this one could probably be delayed to 3.4 if required. no_console_suspend is a debugging-only option and bugs involving it are unlikely to affect most users. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] OMAP: UART: Enable tx wakeup bit in wer
Hello Govindraj Do you intend to update and repost this serial patch? Or should someone else deal with it? It would be good to get support for this additional wakeup bit. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3_beagle: Init only uart3 used for console
* Kevin Hilman khil...@ti.com [120305 11:28]: Govindraj.R govindraj.r...@ti.com writes: From: Govindraj.R govindraj.r...@ti.com On beagle some of uart mux lines are used for other purpose so init only uart3. OK, but you should also be clear that this patch is effectively disabling all UARTS (except UART3) by defatul, which I'm not sure all Beagle users will be happy about. Uart2 rx line clashes with gpio_147 used for usb ehci phy reset. Initializing uart2 pad_mux lines can break ehci module on beagle xm. (gpio_147 is available on uart2_rx in mode4 reference mux34xx.c - uart2_rx.gpio_147) As Koen mentioned, this conflict only exists on certain boards, so you should be clear that this is just an example. OK, thanks for the comments. Also it's a bit clear if this really is safe to do on all beagles. Cc: Tony Lindgren t...@atomide.com Cc: Kevin Hilman khil...@ti.com Tested-by: Peter Ujfalusi peter.ujfal...@ti.com Tested-by: Robert Nelson robertcnel...@gmail.com Signed-off-by: Govindraj.R govindraj.r...@ti.com [...] + +static inline void board_serial_init(void) Should be __init [...] +static inline void board_serial_init(void) here too. ..so dropping the patch for now until these are fixed and we have some tested-bys for non-xm beagles too. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: omap_device: call all suspend, resume callbacks when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set
* Paul Walmsley p...@pwsan.com [120305 11:44]: On Mon, 5 Mar 2012, Kevin Hilman wrote: Tony, this fix is needed for v3.3. Of course, I don't have any objection to this patch going into the v3.3-rc kernels. But given that some maintainers seem to be pushing back against late -rc patches, this one could probably be delayed to 3.4 if required. no_console_suspend is a debugging-only option and bugs involving it are unlikely to affect most users. I'm fine with your queueing it for v3.4 merge window. Regards, Tomny -- 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: OMAP2+: omap_device: call all suspend, resume callbacks when OMAP_DEVICE_NO_IDLE_ON_SUSPEND is set
On Mon, 5 Mar 2012, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [120305 11:44]: On Mon, 5 Mar 2012, Kevin Hilman wrote: Tony, this fix is needed for v3.3. Of course, I don't have any objection to this patch going into the v3.3-rc kernels. But given that some maintainers seem to be pushing back against late -rc patches, this one could probably be delayed to 3.4 if required. no_console_suspend is a debugging-only option and bugs involving it are unlikely to affect most users. I'm fine with your queueing it for v3.4 merge window. Just chatted with Kevin, he's going to take this one for 3.4 with some other omap_device patches he's got queued. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 0/9] Consolidate cpuidle functionality
Robert Lee rob@linaro.org writes: This patch series moves various functionality duplicated in platform cpuidle drivers to the core cpuidle driver. Also, the platform irq disabling was removed as it appears that all calls into cpuidle_call_idle will have already called local_irq_disable(). Reviewed-by: Kevin Hilman khil...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] mcx: very basic support for HTKW mcx board
* Tony Lindgren t...@atomide.com [120305 11:21]:
* Ilya Yanok ya...@emcraft.com [111221 07:22]:
Very basic support for HTKW mcx board. Able to boot via board-generic
and ramdisk/initramfs, however most of peripherals is unsupported.
Produces tons of twl4030 related errors as this board doesn't have
twl4030 installed.
Signed-off-by: Ilya Yanok ya...@emcraft.com
Grant, care to ack this one?
Actually a version of this you already acked as
[PATCH 1/2] mt_ventoux: very basic support for TeeJet Mt.Ventoux board
so using that instead
Regards,
Tony
---
Changes from V2:
- None
Changes from V1:
- device tree move to the separate patch
- iva node is disabled instead of using custom includes
- removed bootargs entry
arch/arm/boot/dts/mcx.dts | 27 +++
1 files changed, 27 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/boot/dts/mcx.dts
diff --git a/arch/arm/boot/dts/mcx.dts b/arch/arm/boot/dts/mcx.dts
new file mode 100644
index 000..66b81bd
--- /dev/null
+++ b/arch/arm/boot/dts/mcx.dts
@@ -0,0 +1,27 @@
+/*
+ * Copyright (C) 2011 Ilya Yanok, EmCraft Systems
+ *
+ * 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 = HTKW mcx;
+ compatible = htkw,mcx, ti,omap3;
+
+ memory {
+ device_type = memory;
+ reg = 0x8000 0x1000; /* 256 MB */
+ };
+
+ /* AM35xx doesn't have IVA */
+ soc {
+ iva {
+ status = disabled;
+ };
+ };
+};
--
1.7.6.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
--
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 V2] mt_ventoux: support for TeeJet Mt.Ventoux board
* Stefano Babic sba...@denx.de [120201 02:20]: On 28/12/2011 00:09, Ilya Yanok wrote: This patch adds support for TeeJet Mt.Ventoux board based on TAM3517 SOM. Supported devices: - Serial - Ethernet - NAND - USB host - LCD - Touchscreen - CAN controller - ADC128S converter Signed-off-by: Ilya Yanok ya...@emcraft.com --- Changes from V1: - Fixed indentation (use tabs not spaces) - Fixed over 80 characters lines - Added #if defined(CONFIG_SENSORS_ADCXX_MODULE) to allow adcxx to be a module. - Fixes for compilation with CONFIG_TOUCHSCREEN_ADS7846!=y - Added defined(CONFIG_TOUCHSCREEN_ADS7846_MODULE) - Moved call to omap_ads7846_init to separate small function - Register fixed regulator used for touchscreen only if the driver is enabled - Changed board name (MT_VENTOUX - Mt.Ventoux) Hi Tony, can I ask you about the status of these patches ? I have not seen open comments, do you think they can be merged in your tree ? Yes I can carry some board-*.c files until device tree is usable for basic features. There's still some hsmmc changes pending that I'd like to get out of the way before adding new ones as then it means I have to keep updating those board files separately. 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: OMAP2+: GPMC: Export gpmc_enable_hwecc and gpmc_calculate_ecc
* Bernhard Walle wa...@corscience.de [120217 06:15]: To be able to compile kernel/drivers/mtd/nand/omap2.ko as module, that two symbols need to be exported. Otherwise, I get following error message ERROR: gpmc_calculate_ecc [drivers/mtd/nand/omap2.ko] undefined! ERROR: gpmc_enable_hwecc [drivers/mtd/nand/omap2.ko] undefined! Signed-off-by: Bernhard Walle wa...@corscience.de Thanks applying into fixes-non-critical-part2. Regards, Tony --- arch/arm/mach-omap2/gpmc.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c index dfffbbf..00d5108 100644 --- a/arch/arm/mach-omap2/gpmc.c +++ b/arch/arm/mach-omap2/gpmc.c @@ -888,6 +888,7 @@ int gpmc_enable_hwecc(int cs, int mode, int dev_width, int ecc_size) gpmc_write_reg(GPMC_ECC_CONFIG, val); return 0; } +EXPORT_SYMBOL_GPL(gpmc_enable_hwecc); /** * gpmc_calculate_ecc - generate non-inverted ecc bytes @@ -918,3 +919,4 @@ int gpmc_calculate_ecc(int cs, const u_char *dat, u_char *ecc_code) gpmc_ecc_used = -EINVAL; return 0; } +EXPORT_SYMBOL_GPL(gpmc_calculate_ecc); -- 1.7.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap: mailbox: trivial whitespace fix
* Felipe Contreras felipe.contre...@nokia.com [120124 08:32]:
Signed-off-by: Felipe Contreras felipe.contre...@nokia.com
---
arch/arm/plat-omap/mailbox.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-omap/mailbox.c b/arch/arm/plat-omap/mailbox.c
index ad80112..ad32621 100644
--- a/arch/arm/plat-omap/mailbox.c
+++ b/arch/arm/plat-omap/mailbox.c
@@ -307,7 +307,7 @@ static void omap_mbox_fini(struct omap_mbox *mbox)
if (!--mbox-use_count) {
free_irq(mbox-irq, mbox);
tasklet_kill(mbox-txq-tasklet);
- flush_work_sync(mbox-rxq-work);
+ flush_work_sync(mbox-rxq-work);
mbox_queue_free(mbox-txq);
mbox_queue_free(mbox-rxq);
}
Thanks applying into fixes-non-critical-part2.
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
[GIT PULL] ARM: OMAP: SR cleanups for v3.4
Hi Tony, Please pull the SmartReflex cleanups for v3.4. Due to a minor conflict with the devexit patches in your randconfig branch, this is based there (actually randconfig~2 which is the actual dependency.) Special thanks to Jean Pihet for collecting and coordinating all these fixups. Kevin The following changes since commit 149f1d5c8d2fd6879cdf93ca70f1cb745e698a1e: ARM: OMAP2+: Fix devexit for smartreflex when CONFIG_HOTPLUG is not set (2012-02-24 08:24:46 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm.git for_3.4/cleanup/sr for you to fetch changes up to 63371faf9198302c7ebd41e7fbe78eb6b57bba86: ARM: OMAP3+: SmartReflex: fix error handling (2012-03-05 11:29:27 -0800) Felipe Balbi (4): ARM: OMAP3+: SmartReflex: add missing platform_set_drvdata() ARM: OMAP3+: SmartReflex: move late_initcall() closer to its argument ARM: OMAP3+: SmartReflex: misc cleanups ARM: OMAP3+: SmartReflex: micro-optimization for sanity check Jean Pihet (2): ARM: OMAP3+: SmartReflex: fix the use of debugfs_create_* API ARM: OMAP3+: SmartReflex: fix error handling Nishanth Menon (6): ARM: OMAP3+: SmartReflex: fix err interrupt disable sequence ARM: OMAP3+: SmartReflex Class3: disable errorgen before disable VP ARM: OMAP3+: SmartReflex: Add a shutdown hook ARM: OMAP3+: SmartReflex: Fix status masking in ERRCONFIG register ARM: OMAP3+: SmartReflex: clear ERRCONFIG_VPBOUNDINTST only on a need ARM: OMAP3+: hwmod: add SmartReflex IRQs Shweta Gulati (1): ARM: OMAP3+: SmartReflex: use voltage domain name in device attributes arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 31 +++- arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 19 ++- arch/arm/mach-omap2/smartreflex-class3.c |1 + arch/arm/mach-omap2/smartreflex.c| 227 +++--- arch/arm/mach-omap2/smartreflex.h| 10 ++ arch/arm/mach-omap2/sr_device.c | 11 +- arch/arm/plat-omap/include/plat/omap_hwmod.h |2 - 7 files changed, 229 insertions(+), 72 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] [trivial] mach-omap1: Fix typo in lcd_dma.c
* Masanari Iida standby2...@gmail.com [120206 05:46]: Correct spelling resulotion to resolution in arch/arm/mach-omap1/lcd_dma.c Thanks applying into fixes-non-critical-part2. 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] arch/arm/mach-omap2/: included some headers twice
* Danny Kukawka danny.kuka...@bisect.de [120216 06:13]: arch/arm/mach-omap2/: included some headers tiwce: - arch/arm/mach-omap2/board-ldp.c: 'linux/gpio.h' - arch/arm/mach-omap2/io.c: 'common.h' - arch/arm/mach-omap2/omap_hwmod_44xx_data.c: 'plat/i2c.h' Remove the duplicates. Thanks applying this too. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arch/arm/plat-omap/clock.c: included linux/debugfs.h twice
* Danny Kukawka danny.kuka...@bisect.de [120216 06:12]: arch/arm/plat-omap/clock.c: included 'linux/debugfs.h' twice, remove the duplicate. Thanks, applying into fixes-non-critical-part2. 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: OMAP2+: Fix module build errors with CONFIG_OMAP4_ERRATA_I688
* R Sricharan r.sricha...@ti.com [120302 02:29]: While building modules with randconfig the below errors are observed. ERROR: omap_bus_sync [drivers/watchdog/sp805_wdt.ko] undefined! ERROR: omap_bus_sync [drivers/watchdog/dw_wdt.ko] undefined! ERROR: omap_bus_sync [drivers/virtio/virtio_ring.ko] undefined! ERROR: omap_bus_sync [drivers/video/sm501fb.ko] undefined! ERROR: omap_bus_sync [drivers/usb/mon/usbmon.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/sl811-hcd.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/ohci-hcd.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/isp1760.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/isp1362-hcd.ko] undefined! ERROR: omap_bus_sync [drivers/usb/host/isp116x-hcd.ko] undefined! ERROR: omap_bus_sync [drivers/usb/core/usbcore.ko] undefined! ERROR: omap_bus_sync [drivers/tty/serial/altera_uart.ko] undefined! ERROR: omap_bus_sync [drivers/tty/serial/altera_jtaguart.ko] undefined! ERROR: omap_bus_sync [drivers/tty/serial/8250/8250_dw.ko] undefined! ERROR: omap_bus_sync [drivers/ssb/ssb.ko] undefined! ERROR: omap_bus_sync [drivers/rtc/rtc-cmos.ko] undefined! ERROR: omap_bus_sync [drivers/rtc/rtc-bq4802.ko] undefined! ERROR: omap_bus_sync [drivers/mtd/nand/tmio_nand.ko] undefined! ERROR: omap_bus_sync [drivers/mtd/nand/omap2.ko] undefined! Thanks applying into fixes. 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/2] ARM: OMAP: DMA: Fix DMA channel end definition for OMAP36xx-PLUS devices
* Jon Hunter jon-hun...@ti.com [120302 14:47]: Oops! I see that Peter has already fixed this one [1]. Peter, looking at your fix it is good for OMAP4 but should we also fix for OMAP5 while we are at it? I checked and the register map is the same for OMAP5. Tony, I still think we should get rid of cpu_is_omap4430() altogether [2]. OK, makes sense. Applying [2] into fixes-non-critical-part2. Thanks, Tony [1] http://www.spinics.net/lists/linux-omap/msg65459.html [2] http://www.spinics.net/lists/linux-omap/msg65702.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] ARM: OMAP: don't build hwspinlock in vain
* Ohad Ben-Cohen o...@wizery.com [120304 02:34]: Cleanup: don't build mach-omap2/hwspinlock.c if the OMAP hwspinlock driver isn't configured. This will both shorten build time and avoid registering a device which isn't needed. Thanks applying into fixes-non-critical-part2. 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 0/6] gpio/omap: Cleanup and adaptation to Device Tree
Hi Grant, Do you have any comment on this latest update? I've just seen your that your gpio/next includes irqdomain/next, so I guess that I can base my pull request on it directly. Thanks, Benoit On 2/24/2012 11:21 PM, Benoit Cousson wrote: Hi Grant, Here are a couple of GPIO cleanup + the DT adaptation patches. This update (compared to v1 [1]) is adding an extra fix for SPARSE_IRQ support and add the second cell in the binding for GPIO IRQ type that was missing previously whereas the driver does support it. This series is based on 3.3-rc4 + for_3.4/dt_base branch to get the needed cleanup and fixes for OMAP. The interrupt controller support is using irq_domain_add_legacy for the moment and will be updated next to use irqchip irq_domain. It requires the irq_domain generalization and refinement series available at: git://git.secretlab.ca/git/linux-2.6 irqdomain/next It requires as well Tarun's GPIO cleanup series available at: git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev for_3.4/gpio_cleanup_fixes_v9 This series is available here for reference: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.4/dt_gpio Regards, Benoit [1] http://www.spinics.net/lists/linux-omap/msg64694.html Benoit Cousson (6): gpio/omap: Remove bank-id information and misc cleanup gpio/omap: Use devm_ API and add request_mem_region gpio/omap: Add DT support to GPIO driver gpio/omap: Fix IRQ handling for SPARSE_IRQ arm/dts: OMAP4: Add gpio nodes arm/dts: OMAP3: Add gpio nodes .../devicetree/bindings/gpio/gpio-omap.txt | 36 arch/arm/boot/dts/omap3.dtsi | 54 + arch/arm/boot/dts/omap4.dtsi | 54 + arch/arm/mach-omap2/gpio.c |8 +- arch/arm/plat-omap/include/plat/gpio.h | 22 +-- drivers/gpio/gpio-omap.c | 208 ++-- 6 files changed, 304 insertions(+), 78 deletions(-) create mode 100644 Documentation/devicetree/bindings/gpio/gpio-omap.txt -- 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/3] arm: fix build breakage in omap2plus_defconfig (linux-next)
I decided to look at why this thing was dying in linux-next for over two weeks now: http://kisskb.ellerman.id.au/kisskb/target/5581/ The git bisect led me to sfr's merge (661a40a5c8 in March5th tree) of 'arm-soc/for-next' but there was nothing suspicious there, and the fix (commit #1) was reasonably obvious, so I didn't investigate the root cause further. But that wasn't where the breakage ended... Commit #2, and especially commit #3 need to be looked at by those who know the platform. It looks like some sort of conversion to better share code was done, but the omap4panda part didn't get the full attention it needed. I did what I think looks right, based on what was done for the other board, but I've no knowledge of the platform whatsoever, and hence no confidence it would work as desired. I've hopefully put the right people on the CC list for those. Paul. --- Paul Gortmaker (3): arm: anticipate build breakages due in pending merge arm: fix compile error in mach-omap2/board-omap4panda.c arm: more fallout from i2c conversions in board-omap4panda.c arch/arm/mach-omap2/board-omap4panda.c |7 +++ arch/arm/mach-omap2/cm2xxx_3xxx.c |2 ++ arch/arm/mach-omap2/common.c |1 + arch/arm/mach-omap2/control.c |1 + arch/arm/mach-omap2/sdrc2xxx.c |1 + 5 files changed, 8 insertions(+), 4 deletions(-) -- 1.7.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] arm: anticipate build breakages due in pending merge
Testing in linux-next has revealed that the omap2plus_defconfig will fail upon the merge of arm-soc/for-next as follows: arch/arm/mach-omap2/control.c:238: error: 'OMAP343X_CTRL_BASE' undeclared (first use in this function) arch/arm/mach-omap2/common.c:48: error: 'OMAP2420_SDRC_BASE' undeclared here (not in a function) arch/arm/mach-omap2/common.c:49: error: 'OMAP2420_SMS_BASE' undeclared here (not in a function) arch/arm/mach-omap2/common.c:50: error: 'OMAP242X_CTRL_BASE' undeclared here (not in a function) [...] arch/arm/mach-omap2/common.c:167: error: 'OMAP4430_CM2_BASE' undeclared here (not in a function) arch/arm/mach-omap2/sdrc2xxx.c:108: error: 'OMAP2420_PRM_BASE' undeclared (first use in this function) arch/arm/mach-omap2/cm2xxx_3xxx.c:310: error: 'OMAP3430_CM_BASE' undeclared (first use in this function) It appears that a once implicit path to plat/hardware.h has gone away once two of the arm streams come together. Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com --- arch/arm/mach-omap2/cm2xxx_3xxx.c |2 ++ arch/arm/mach-omap2/common.c |1 + arch/arm/mach-omap2/control.c |1 + arch/arm/mach-omap2/sdrc2xxx.c|1 + 4 files changed, 5 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cm2xxx_3xxx.c b/arch/arm/mach-omap2/cm2xxx_3xxx.c index c79ed63..389f9f8 100644 --- a/arch/arm/mach-omap2/cm2xxx_3xxx.c +++ b/arch/arm/mach-omap2/cm2xxx_3xxx.c @@ -18,6 +18,8 @@ #include linux/err.h #include linux/io.h +#include plat/hardware.h + #include iomap.h #include common.h #include cm.h diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c index 93419de..d620362 100644 --- a/arch/arm/mach-omap2/common.c +++ b/arch/arm/mach-omap2/common.c @@ -20,6 +20,7 @@ #include plat/board.h #include plat/mux.h #include plat/clock.h +#include plat/hardware.h #include iomap.h #include common.h diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 2fd5fd1..18ff359 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -16,6 +16,7 @@ #include linux/io.h #include plat/sdrc.h +#include plat/hardware.h #include iomap.h #include common.h diff --git a/arch/arm/mach-omap2/sdrc2xxx.c b/arch/arm/mach-omap2/sdrc2xxx.c index 2c329a6..181b0c5 100644 --- a/arch/arm/mach-omap2/sdrc2xxx.c +++ b/arch/arm/mach-omap2/sdrc2xxx.c @@ -27,6 +27,7 @@ #include plat/clock.h #include plat/sram.h #include plat/sdrc.h +#include plat/hardware.h #include iomap.h #include common.h -- 1.7.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] arm: fix compile error in mach-omap2/board-omap4panda.c
The commit 3c90c98a1ebbb08d95700ce8a3b7bce6286607bd (linux-next)
OMAP4: omap4panda: Enable audio support
introduced population of a new struct, but chose the wrong (but
similarly named) struct that has none of the named fields.
Change it to the struct with those fields, to fix:
arch/arm/mach-omap2/board-omap4panda.c:284: error: unknown field 'hs_left_step'
specified in initializer
arch/arm/mach-omap2/board-omap4panda.c:285: error: unknown field
'hs_right_step' specified in initializer
arch/arm/mach-omap2/board-omap4panda.c:286: error: unknown field 'hf_left_step'
specified in initializer
arch/arm/mach-omap2/board-omap4panda.c:287: error: unknown field
'hf_right_step' specified in initializer
arch/arm/mach-omap2/board-omap4panda.c:287: warning: large integer implicitly
truncated to unsigned type
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
CC: Peter Ujfalusi peter.ujfal...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
CC: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-omap4panda.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index c1a852d..e919153 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -279,7 +279,7 @@ static int __init omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers)
return 0;
}
-static struct twl4030_codec_data twl6040_codec = {
+static struct twl6040_codec_data twl6040_codec = {
/* single-step ramp for headset and handsfree */
.hs_left_step = 0x0f,
.hs_right_step = 0x0f,
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] arm: more fallout from i2c conversions in board-omap4panda.c
Commit ded0df8510778a03a2f182a0cbfe3c25788e8852 (linux-next)
mfd: Convert twl6040 to an i2c driver, and separate it from twl core
appears to have done an incomplete conversion on the board-omap4panda.c
file, leaving it with more build failures. Comparing the changes that
were done for board-4430sdp.c it is possible for me to whack it with a
stick until it stops twitching, but someone who really understands this
code needs to take a look at the conversion, and check it is done
completely and in a way that will actually work on hardware.
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
CC: Peter Ujfalusi peter.ujfal...@ti.com
CC: Mark Brown broo...@opensource.wolfsonicro.com
CC: Samuel Ortiz sa...@linux.intel.com
---
arch/arm/mach-omap2/board-omap4panda.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index e919153..16a1814 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -287,16 +287,15 @@ static struct twl6040_codec_data twl6040_codec = {
.hf_right_step = 0x1d,
};
-static struct twl4030_audio_data twl6040_audio = {
+static struct twl6040_platform_data twl6040_data = {
.codec = twl6040_codec,
.audpwron_gpio = 127,
- .naudint_irq= OMAP44XX_IRQ_SYS_2N,
.irq_base = TWL6040_CODEC_IRQ_BASE,
};
/* Panda board uses the common PMIC configuration */
static struct twl4030_platform_data omap4_panda_twldata = {
- .audio = twl6040_audio,
+ /* .audio = twl6040_audio, */
};
/*
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] arm: anticipate build breakages due in pending merge
* Paul Gortmaker paul.gortma...@windriver.com [120305 14:10]: Testing in linux-next has revealed that the omap2plus_defconfig will fail upon the merge of arm-soc/for-next as follows: arch/arm/mach-omap2/control.c:238: error: 'OMAP343X_CTRL_BASE' undeclared (first use in this function) arch/arm/mach-omap2/common.c:48: error: 'OMAP2420_SDRC_BASE' undeclared here (not in a function) arch/arm/mach-omap2/common.c:49: error: 'OMAP2420_SMS_BASE' undeclared here (not in a function) arch/arm/mach-omap2/common.c:50: error: 'OMAP242X_CTRL_BASE' undeclared here (not in a function) [...] arch/arm/mach-omap2/common.c:167: error: 'OMAP4430_CM2_BASE' undeclared here (not in a function) arch/arm/mach-omap2/sdrc2xxx.c:108: error: 'OMAP2420_PRM_BASE' undeclared (first use in this function) arch/arm/mach-omap2/cm2xxx_3xxx.c:310: error: 'OMAP3430_CM_BASE' undeclared (first use in this function) It appears that a once implicit path to plat/hardware.h has gone away once two of the arm streams come together. Thanks this one is already waiting to be applied to arm-soc tree. 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 2/3] arm: fix compile error in mach-omap2/board-omap4panda.c
* Paul Gortmaker paul.gortma...@windriver.com [120305 14:10]:
The commit 3c90c98a1ebbb08d95700ce8a3b7bce6286607bd (linux-next)
OMAP4: omap4panda: Enable audio support
introduced population of a new struct, but chose the wrong (but
similarly named) struct that has none of the named fields.
Change it to the struct with those fields, to fix:
arch/arm/mach-omap2/board-omap4panda.c:284: error: unknown field
'hs_left_step' specified in initializer
arch/arm/mach-omap2/board-omap4panda.c:285: error: unknown field
'hs_right_step' specified in initializer
arch/arm/mach-omap2/board-omap4panda.c:286: error: unknown field
'hf_left_step' specified in initializer
arch/arm/mach-omap2/board-omap4panda.c:287: error: unknown field
'hf_right_step' specified in initializer
arch/arm/mach-omap2/board-omap4panda.c:287: warning: large integer implicitly
truncated to unsigned type
Thanks, this mis-merge is something Peter should take a look at
as it seems there's few other parts that got left out.
Regards,
Tony
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
CC: Peter Ujfalusi peter.ujfal...@ti.com
CC: Santosh Shilimkar santosh.shilim...@ti.com
CC: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-omap4panda.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index c1a852d..e919153 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -279,7 +279,7 @@ static int __init omap4_twl6030_hsmmc_init(struct
omap2_hsmmc_info *controllers)
return 0;
}
-static struct twl4030_codec_data twl6040_codec = {
+static struct twl6040_codec_data twl6040_codec = {
/* single-step ramp for headset and handsfree */
.hs_left_step = 0x0f,
.hs_right_step = 0x0f,
--
1.7.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
