Re: [PATCH] gpio: omap-gpio: add support for pm_runtime autosuspend
On Tuesday 30 October 2012 01:33 AM, Felipe Balbi wrote: Hi, On Mon, Oct 29, 2012 at 01:53:37PM +0530, Santosh Shilimkar wrote: Just to expand a bit, Out of 6 GPIO banks, GPIO1 bank is in always ON domain where as remaing 5 are in peripheral domain. Letting individual banks idle allowed you let the clock domain idle than keeping all the 6 banks and hence respective clock/power domain in ON state. So the adding timeout might be reasonable but I am not sure about the mod_usage change here. IMHO that whole mod_usage is broken. I remember sending a big series of patches getting rid of that long ago. I _did_ break a few things but just because of omap_gpio_prepare_for_idle() / omap_gpio_resume_from_idle() hackery to get GPIO suspended early enough. Well so far I haven't seen/come across a patch/proposal which fixes it. fair point I still think mod_usage needs to go, so does omap_gpio_prepare_for_idle() and omap_gpio_resume_from_idle(). To me, it looks like that needs to be done on -prepare()/-complete() callbacks of system suspend and the gpio driver needs to learn proper runtime suspend. I am not saying it shouldn't go :-) The $subject patch isn't fixing it correctly is what I said. Don't get hung up on suspend case because thats the easiest way to address it. The issue is with idle where GPIO can prevent SOC idle if it isn't taken care. And since its just an IO, its not easy to implement something like inactivity timer towards autosupend. I don't see the relation here. Care to expand a bit ? Let me try again... Before I answer you, a closer look at code, the multiple bank should not be a problem since we create PIO device per bank so the runtime PM layer can indeed manage the use-counting. The issue is with SOC idle. System wide suspend, we suspend all the devices and hence all the GPIO devices(banks) will be suspended letting the SOC to hit suspend state. Hence suspend case is no problem as such. Devices like UART/USB can implement inactivity timers since they do have state machine and after the timeout, those devices can be suspended. GPIO doesn't fall exactly in that category and hence its bit of an issue to take care. How do you ensure that GPIO does idle on SOC idle C-state attempts in such cases. Today that job is done by omap_gpio_[prepare/resume]_for_idle. Idle if we had generic idle notifiers, that would been easy but it doesn't exist today. In case we get rid of mod_usage which is doable, we need to see how to handle the idle since the runtime callback will be in that case controlled by runtime PM layer which is unaware of idle. You can do put on all banks to trigger callback but that will highly UN-optimal. See summary in the end. Co-processor also makes use of GPIO via syslink proxy and thats make things even harder. that's supposed to be solved with hwspinlock, isn't it ? Spin locks are needed when same devices are shared across. That is not the main concern. The PM is centralized on Linux side for GPIO where as the users are outside Linux SW. They may use of syslink proxy to request/free GPIO. Just to summaries, there are 3 things we are talking here. 1. Delaying the idle with a timeout which $subject patch is trying to do to reduce latency for interrupts. That itself is reasonable. 2. Removal of the bank mod_usage which is also clubbed in $subject path. Ofcourse that break the current driver for idle. So that change needs to be made with better thought and in a separate patch. This is doable. 3. Removing omap_gpio_[prepare/resume]_for_idle() with soome thing better. For this one though, so far I have not come across a good solution. Ideas/Solution is welcome !! Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio: omap-gpio: add support for pm_runtime autosuspend
Hi, On Tue, Oct 30, 2012 at 12:02:17PM +0530, Santosh Shilimkar wrote: I still think mod_usage needs to go, so does omap_gpio_prepare_for_idle() and omap_gpio_resume_from_idle(). To me, it looks like that needs to be done on -prepare()/-complete() callbacks of system suspend and the gpio driver needs to learn proper runtime suspend. I am not saying it shouldn't go :-) The $subject patch isn't fixing it correctly is what I said. Don't get hung up on suspend case because thats the easiest way to address it. The issue is with idle where GPIO can prevent SOC idle if it isn't taken care. And since its just an IO, its not easy to implement something like inactivity timer towards autosupend. I don't see the relation here. Care to expand a bit ? Let me try again... Before I answer you, a closer look at code, the multiple bank should not be a problem since we create PIO device per bank so the runtime PM layer can indeed manage the use-counting. The issue is with SOC idle. System wide suspend, we suspend all the devices and hence all the GPIO devices(banks) will be suspended letting the SOC to hit suspend state. Hence suspend case is no problem as such. Devices like UART/USB can implement inactivity timers since they do have state machine and after the timeout, those devices can be suspended. GPIO doesn't fall exactly in that category and hence idling the device has nothing to do with their internal state machines, though :-) We just assume that if device hasn't been used for X ms, it's unlikely it will continue to be used. Likewise, If device has been used Y ms ago, it's likely it will continue to be used. its bit of an issue to take care. How do you ensure that GPIO does idle on SOC idle C-state attempts in such cases. Today that job is done by omap_gpio_[prepare/resume]_for_idle. that's only there because we pm_runtime_get_sync() on gpio_request() and pm_runtime_put_sync() only on gpio_free(). That's the problem IMHO. And that's easy enough to 'fix': call pm_runtime_mark_last_busy(); pm_runtime_put_sync_autosuspend(); also on gpio_request() and pm_runtime_get_sync() on gpio_free(). Idle if we had generic idle notifiers, that would been easy but it doesn't exist today. In case we get rid of mod_usage which is doable, we need to see how to handle the idle since the runtime callback will be in that case controlled by runtime PM layer which is unaware of idle. You can do put on all banks to trigger callback but I think we might have a clash of concepts here. What are you calling idle ? We _do_ have -runtime_idle() callback, are we not using that ? I can see omap_device.c implements it properly and I can see that -runtime_idle() will be called whenever pm_usage counter is decremented but is not zero. Looks like we can turn that into something useful. that will highly UN-optimal. See summary in the end. Co-processor also makes use of GPIO via syslink proxy and thats make things even harder. that's supposed to be solved with hwspinlock, isn't it ? Spin locks are needed when same devices are shared across. That is not the main concern. The PM is centralized on Linux side for GPIO where as the users are outside Linux SW. They may use of syslink proxy to request/free GPIO. fair enough, that's even better. Just to summaries, there are 3 things we are talking here. 1. Delaying the idle with a timeout which $subject patch is trying to do to reduce latency for interrupts. That itself is reasonable. 2. Removal of the bank mod_usage which is also clubbed in $subject path. Ofcourse that break the current driver for idle. So that change needs to be made with better thought and in a separate patch. This is doable. 3. Removing omap_gpio_[prepare/resume]_for_idle() with soome thing better. For this one though, so far I have not come across a good solution. Ideas/Solution is welcome !! make pm_runtime a bit more aggressive. You don't need to keep GPIO bank's clocks on just because a GPIO in that bank is requested. If context save restore isn't buggy, you can disable clocks no problem. The difficult part, IMHO, is to figure out what's a good autosuspend timeout to use. Some GPIO lines are used as IRQ lines on some devices, that means that the GPIO will be periodically triggered and, depending on our timeout, we will either loose IRQs or prevent power domain from idling. We could figure out a way to let board code to choose what it wants on a per-bank basis (maybe some extra DT attribute). -- balbi signature.asc Description: Digital signature
Re: [PATCHv2 12/12] ARM: OMAP4: hwmod data: do not enable or reset the McPDM during kernel init
Hi Paul,
On 10/30/2012 05:05 AM, Paul Walmsley wrote:
omap_hwmod: mcpdm: cannot be enabled for reset (3)
The McPDM on OMAP4 can only receive its functional clock from an
off-chip source. This source is not guaranteed to be present on the
board, and when present, it is controlled by I2C. This would
introduce a board dependency to the early hwmod code which it was not
designed to handle. Also, neither the driver for this off-chip clock
provider nor the I2C code is available early in boot when the hwmod
code is attempting to enable and reset IP blocks. This effectively
makes it impossible to enable and reset this device during hwmod init.
At its core, this patch is a workaround for an OMAP hardware problem.
It should be possible to configure the OMAP to provide any IP block's
functional clock from an on-chip source. (This is true for almost
every IP block on the chip. As far as I know, McPDM is the only
exception.) If the kernel cannot reset and configure IP blocks, it
cannot guarantee a sane SoC state. Relying on an optional off-chip
clock also creates a board dependency which is beyond the scope of the
early hwmod code.
This patch works around the issue by marking the McPDM hwmod record
with the HWMOD_EXT_OPT_MAIN_CLK flag. This prevents the hwmod
code from touching the device early during boot.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Péter Ujfalusi peter.ujfal...@ti.com
Cc: Benoît Cousson b-cous...@ti.com
Acked-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..7bddfa5 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2125,6 +2125,14 @@ static struct omap_hwmod omap44xx_mcpdm_hwmod = {
.name = mcpdm,
.class = omap44xx_mcpdm_hwmod_class,
.clkdm_name = abe_clkdm,
+ /*
+ * It's suspected that the McPDM requires an off-chip main
+ * functional clock, controlled via I2C. This IP block is
+ * currently reset very early during boot, before I2C is
+ * available, so it doesn't seem that we have any choice in
+ * the kernel other than to avoid resetting it.
+ */
+ .flags = HWMOD_EXT_OPT_MAIN_CLK,
.mpu_irqs = omap44xx_mcpdm_irqs,
.sdma_reqs = omap44xx_mcpdm_sdma_reqs,
.main_clk = mcpdm_fck,
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
Hi Paul, On Tue, Oct 30, 2012 at 5:16 AM, Paul Walmsley p...@pwsan.com wrote: Hello Jean, On Tue, 23 Oct 2012, Jean Pihet wrote: Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). Had any luck reproducing this one that Aaro I are seeing? Unfortunately not. I could not reproduce the issue on my side, using an ES2.1 Beagleboard with the latest l-o kernel and your bootloader and rootfs images. Is there some specific to enable in order to reproduce the issue? Regards, Jean - 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: [RESEND/PATCHv3] arm: dts: omap5-evm: Add keypad support
Hi Sourav,
On 10/30/2012 6:26 AM, Sourav wrote:
Hi Benoit,
On Monday 29 October 2012 10:14 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Tested on omap5430 evm with 3.7-rc1 kernel.
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Tested on omap5430 sdp with 3.7-rc1 kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 95
+++
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts
b/arch/arm/boot/dts/omap5-evm.dts
index c663eba..b812d6d 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -140,3 +140,98 @@
mcbsp3 {
status = disabled;
};
+
+i2c5 {
+clock-frequency = 40;
+
+smsc@38 {
+compatible = smscece1099;
+reg = 0x38;
+clock = 0x13;
What does that clock mean?
This chip supports a clock control register which is used to enable the
interface used by the chip to communicate. Here, the interface which you
can are
SMBUS interface or BC-LINK interface.
OK, so you should use a less generic name than clock and potentially
prefix it with smsc, since it is not a generic attribute at all.
BTW, cannot we use the CCF in order to control that clock? I guess it is
just a clock mux?
Well, anyway we need CCF for OMAP to be merged first :-)
But it might worth highlighting this is a temporary solution.
I cannot find that in the binding documentation. BTW, did you add that
documentation in the driver patch?
Nope, I missed out on the dt binding documentation for the driver. :(
Will send a seperate patch for the bindings.
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: [RESEND/PATCHv3] arm: dts: omap5-evm: Add keypad support
Hi Benoit,
On Tuesday 30 October 2012 02:43 PM, Cousson, Benoit wrote:
Hi Sourav,
On 10/30/2012 6:26 AM, Sourav wrote:
Hi Benoit,
On Monday 29 October 2012 10:14 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different series.
Tested on omap5430 evm with 3.7-rc1 kernel.
Cc: Felipe Balbi ba...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Tested on omap5430 sdp with 3.7-rc1 kernel.
Signed-off-by: Sourav Poddar sourav.pod...@ti.com
---
arch/arm/boot/dts/omap5-evm.dts | 95
+++
1 files changed, 95 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/omap5-evm.dts
b/arch/arm/boot/dts/omap5-evm.dts
index c663eba..b812d6d 100644
--- a/arch/arm/boot/dts/omap5-evm.dts
+++ b/arch/arm/boot/dts/omap5-evm.dts
@@ -140,3 +140,98 @@
mcbsp3 {
status = disabled;
};
+
+i2c5 {
+clock-frequency = 40;
+
+smsc@38 {
+compatible = smscece1099;
+reg = 0x38;
+clock = 0x13;
What does that clock mean?
This chip supports a clock control register which is used to enable the
interface used by the chip to communicate. Here, the interface which you
can are
SMBUS interface or BC-LINK interface.
OK, so you should use a less generic name than clock and potentially
prefix it with smsc, since it is not a generic attribute at all.
Sure, will think of less generic name. May be smsc, ctrl-reg will do.
BTW, cannot we use the CCF in order to control that clock?
I don't have much idea about the CCF, so cant really comment on this.
I guess it is just a clock mux?
Yes.
Well, anyway we need CCF for OMAP to be merged first :-)
But it might worth highlighting this is a temporary solution.
I cannot find that in the binding documentation. BTW, did you add that
documentation in the driver patch?
Nope, I missed out on the dt binding documentation for the driver. :(
Will send a seperate patch for the bindings.
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: [RFC PATCH v3 16/16] ARM: dts: add AM33XX SPI support
On Mon, Oct 29, 2012 at 14:40:02, Philip, Avinash wrote:
On Thu, Oct 18, 2012 at 18:56:55, Porter, Matt wrote:
Adds AM33XX SPI support for am335x-bone and am335x-evm.
Matt,
Can you build SPI DT patch with DMA support on top of SPI DT patch
I submitted [1]. With the patch [1] SPI can work on PIO mode.
So we can have basic SPI support available in 3.8.
Benoit,
Can you accept the SPI DT patch [1]
In case if you want I will resubmit a patch with subject line modified.
Current subject line
arm/dts: AM33XX: Add SPI device tree data
1. https://patchwork.kernel.org/patch/1470661/
Thanks
Avinash
Signed-off-by: Matt Porter mpor...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts | 17 +++
arch/arm/boot/dts/am335x-evm.dts |9
arch/arm/boot/dts/am33xx.dtsi | 43
+
3 files changed, 69 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 5510979..23edfd8 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -18,6 +18,17 @@
reg = 0x8000 0x1000; /* 256 MB */
};
+ am3358_pinmux: pinmux@44e10800 {
+ spi1_pins: pinmux_spi1_pins {
+ pinctrl-single,pins =
+ 0x190 0x13 /* mcasp0_aclkx.spi1_sclk,
OUTPUT_PULLUP | MODE3 */
+ 0x194 0x33 /* mcasp0_fsx.spi1_d0,
INPUT_PULLUP | MODE3 */
+ 0x198 0x13 /* mcasp0_axr0.spi1_d1,
OUTPUT_PULLUP | MODE3 */
+ 0x19c 0x13 /* mcasp0_ahclkr.spi1_cs0,
OUTPUT_PULLUP | MODE3 */
+ ;
+ };
+ };
+
Change to am33xx_pinmux.
ocp {
uart1: serial@44e09000 {
status = okay;
@@ -84,3 +95,9 @@
mmc1 {
vmmc-supply = ldo3_reg;
};
+
+spi1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = spi1_pins;
+};
diff --git a/arch/arm/boot/dts/am335x-evm.dts
b/arch/arm/boot/dts/am335x-evm.dts
index d63fce8..8d5f660 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -124,3 +124,12 @@
mmc1 {
vmmc-supply = vmmc_reg;
};
+
+spi0 {
+ status = okay;
+ spi-flash@0 {
+ compatible = spansion,s25fl064k, m25p80;
+ spi-max-frequency = 2400;
+ reg = 0;
+ };
+};
In AM335x-evm, SPI flash available in profile #2 (am335x evm specific
profiles).
So can you drop this changes as if I understood correctly, am335x-evm.dts
will be
populated for devices present only on profile #0.
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 26a6af7..063ecea 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -40,6 +40,15 @@
};
};
+ am3358_pinmux: pinmux@44e10800 {
+ compatible = pinctrl-single;
+ reg = 0x44e10800 0x0238;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-single,register-width = 32;
+ pinctrl-single,function-mask = 0x7f;
+ };
+
Pin ctrl support already submitted
http://git.kernel.org/?p=linux/kernel/git/bcousson/linux-omap-dt.git;a=commitdiff;h=3e0603e905d9ba662e8c1885ecb1d28bc454e448
Thanks
Avinash
/*
* XXX: Use a flat representation of the AM33XX interconnect.
* The real AM33XX interconnect network is quite complex.Since
@@ -261,6 +270,40 @@
status = disabled;
};
+ spi0: spi@4803 {
+ compatible = ti,omap4-mcspi;
+ ti,hwmods = spi0;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x4803 0x400;
+ interrupt-parent = intc;
+ interrupt = 65;
+ dmas = edma 16
+ edma 17
+ edma 18
+ edma 19;
+ dma-names = tx0, rx0, tx1, rx1;
+ ti,spi-num-cs = 2;
+ status = disabled;
+ };
+
+ spi1: spi@481a {
+ compatible = ti,omap4-mcspi;
+ ti,hwmods = spi1;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x481a 0x400;
+ interrupt-parent = intc;
+ interrupt = 125;
+ dmas = edma 42
+ edma 43
+ edma 44
+ edma 45;
+ dma-names = tx0, rx0, tx1, rx1;
+ ti,spi-num-cs = 2;
+ status = disabled;
+ };
+
[PATCH 0/2] ARM: OMAP: hwmod/omapd_device: Fix for resource handling in DT boot
Hello, This series resolves the issue we currently have with the resource handling when booting with DT. In short: at the moment the omap_device_alloc() decides if it needs to update the OF filled resources based on the number of resources on the device and in the hwmod database. This prevents us from removing hwmod data for platforms (OMAP5) which does not support non DT boot anymore. With this series we can make sure that the DT provided resources are used and we only append the DMA resources to the device from hwmod. I have added extra check to prepare us when the DMA resource can be filled via OF. In this case we do not update the resources at all. Tony, Benoit, Paul: Not sure if this qualify for 3.7 inclusion, but for sure going to help us to clean up the OMAP5 hwmod database. Regards, Peter --- Peter Ujfalusi (2): ARM: OMAP: hwmod: Add possibility to count hwmod resources based on type ARM: OMAP: omap_device: Correct resource handling for DT boot arch/arm/mach-omap2/omap_hwmod.c | 27 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +- arch/arm/plat-omap/omap_device.c | 83 +--- 3 files changed, 68 insertions(+), 44 deletions(-) -- 1.7.12.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 1/2] ARM: OMAP: hwmod: Add possibility to count hwmod resources based on type
Add flags parameter for omap_hwmod_count_resources() so users can tell which
type of resources they are interested when counting them in hwmod database.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 27 ---
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +-
arch/arm/plat-omap/omap_device.c | 11 ---
3 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index b969ab1..a79c941 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3337,7 +3337,7 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
/**
* omap_hwmod_count_resources - count number of struct resources needed by
hwmod
* @oh: struct omap_hwmod *
- * @res: pointer to the first element of an array of struct resource to fill
+ * @flags: Type of resources to include when counting (IRQ/DMA/MEM)
*
* Count the number of struct resource array elements necessary to
* contain omap_hwmod @oh resources. Intended to be called by code
@@ -3350,20 +3350,25 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
* resource IDs.
*
*/
-int omap_hwmod_count_resources(struct omap_hwmod *oh)
+int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags)
{
- struct omap_hwmod_ocp_if *os;
- struct list_head *p;
- int ret;
- int i = 0;
+ int ret = 0;
- ret = _count_mpu_irqs(oh) + _count_sdma_reqs(oh);
+ if (flags IORESOURCE_IRQ)
+ ret += _count_mpu_irqs(oh);
- p = oh-slave_ports.next;
+ if (flags IORESOURCE_DMA)
+ ret += _count_sdma_reqs(oh);
- while (i oh-slaves_cnt) {
- os = _fetch_next_ocp_if(p, i);
- ret += _count_ocp_if_addr_spaces(os);
+ if (flags IORESOURCE_MEM) {
+ int i = 0;
+ struct omap_hwmod_ocp_if *os;
+ struct list_head *p = oh-slave_ports.next;
+
+ while (i oh-slaves_cnt) {
+ os = _fetch_next_ocp_if(p, i);
+ ret += _count_ocp_if_addr_spaces(os);
+ }
}
return ret;
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index b3349f7..48a6f5d 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -628,7 +628,7 @@ void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16
reg_offs);
u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs);
int omap_hwmod_softreset(struct omap_hwmod *oh);
-int omap_hwmod_count_resources(struct omap_hwmod *oh);
+int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags);
int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource *res);
int omap_hwmod_get_resource_byname(struct omap_hwmod *oh, unsigned int type,
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7a7d1f2..915cf68 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -442,19 +442,21 @@ int omap_device_get_context_loss_count(struct
platform_device *pdev)
/**
* omap_device_count_resources - count number of struct resource entries needed
* @od: struct omap_device *
+ * @flags: Type of resources to include when counting (IRQ/DMA/MEM)
*
* Count the number of struct resource entries needed for this
* omap_device @od. Used by omap_device_build_ss() to determine how
* much memory to allocate before calling
* omap_device_fill_resources(). Returns the count.
*/
-static int omap_device_count_resources(struct omap_device *od)
+static int omap_device_count_resources(struct omap_device *od,
+ unsigned long flags)
{
int c = 0;
int i;
for (i = 0; i od-hwmods_cnt; i++)
- c += omap_hwmod_count_resources(od-hwmods[i]);
+ c += omap_hwmod_count_resources(od-hwmods[i], flags);
pr_debug(omap_device: %s: counted %d total resources across %d
hwmods\n,
od-pdev-name, c, od-hwmods_cnt);
@@ -558,7 +560,10 @@ struct omap_device *omap_device_alloc(struct
platform_device *pdev,
od-hwmods = hwmods;
od-pdev = pdev;
- res_count = omap_device_count_resources(od);
+ /* Count all resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
+ IORESOURCE_DMA |
+ IORESOURCE_MEM);
/*
* DT Boot:
* OF framework will construct the resource structure (currently
--
1.7.12.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
[PATCH 2/2] ARM: OMAP: omap_device: Correct resource handling for DT boot
When booting with DT the OF core can fill up the resources provided within
the DT blob.
The current way of handling the DT boot prevents us from removing hwmod data
for platforms only suppose to boot with DT (OMAP5 for example) since we need
to keep the whole hwmod database intact in order to have more resources in
hwmod than in DT (to be able to append the DMA resource from hwmod).
To fix this issue we just examine the OF provided resources:
If we do not have resources we use hwmod to fill them.
If we have resources we check if we already able to recive DMA resource, if
no we only append the DMA resurce from hwmod to the OF provided ones.
In this way we can start removing hwmod data for devices which have their
resources correctly configured in DT without regressions.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/omap_device.c | 80 +++-
1 file changed, 47 insertions(+), 33 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 915cf68..a8a9d08 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -560,55 +560,69 @@ struct omap_device *omap_device_alloc(struct
platform_device *pdev,
od-hwmods = hwmods;
od-pdev = pdev;
- /* Count all resources for the device */
- res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
- IORESOURCE_DMA |
- IORESOURCE_MEM);
/*
+* Non-DT Boot:
+* Here, pdev-num_resources = 0, and we should get all the
+* resources from hwmod.
+*
* DT Boot:
* OF framework will construct the resource structure (currently
* does for MEM IRQ resource) and we should respect/use these
* resources, killing hwmod dependency.
* If pdev-num_resources 0, we assume that MEM IRQ resources
* have been allocated by OF layer already (through DTB).
-*
-* Non-DT Boot:
-* Here, pdev-num_resources = 0, and we should get all the
-* resources from hwmod.
+* As preparation for the future we examine the OF provided resources
+* to see if we have DMA resources provided already. In this case
+* there is no need to update the resources for the device, we use the
+* OF provided ones.
*
* TODO: Once DMA resource is available from OF layer, we should
* kill filling any resources from hwmod.
*/
- if (res_count pdev-num_resources) {
- /* Allocate resources memory to account for new resources */
- res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
- if (!res)
- goto oda_exit3;
-
- /*
-* If pdev-num_resources 0, then assume that,
-* MEM and IRQ resources will only come from DT and only
-* fill DMA resource from hwmod layer.
-*/
- if (pdev-num_resources pdev-resource) {
- dev_dbg(pdev-dev, %s(): resources already allocated
%d\n,
- __func__, res_count);
- memcpy(res, pdev-resource,
- sizeof(struct resource) * pdev-num_resources);
- _od_fill_dma_resources(od, res[pdev-num_resources]);
- } else {
- dev_dbg(pdev-dev, %s(): using resources from hwmod
%d\n,
- __func__, res_count);
- omap_device_fill_resources(od, res);
+ if (!pdev-num_resources) {
+ /* Count all resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
+ IORESOURCE_DMA |
+ IORESOURCE_MEM);
+ } else {
+ /* Take a look if we already have DMA resource via DT */
+ for (i = 0; i pdev-num_resources; i++) {
+ struct resource *r = pdev-resource[i];
+
+ /* We have it, no need to touch the resources */
+ if (r-flags == IORESOURCE_DMA)
+ goto have_everything;
}
+ /* Count only DMA resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_DMA);
+ res_count += pdev-num_resources;
+ }
- ret = platform_device_add_resources(pdev, res, res_count);
- kfree(res);
+ /* Allocate resources memory to account for new resources */
+ res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
+ if (!res)
+ goto oda_exit3;
- if
Re: [PATCH 2/2] ARM: OMAP: omap_device: Correct resource handling for DT boot
On 10/30/2012 11:33 AM, Peter Ujfalusi wrote:
When booting with DT the OF core can fill up the resources provided within
the DT blob.
The current way of handling the DT boot prevents us from removing hwmod data
for platforms only suppose to boot with DT (OMAP5 for example) since we need
to keep the whole hwmod database intact in order to have more resources in
hwmod than in DT (to be able to append the DMA resource from hwmod).
To fix this issue we just examine the OF provided resources:
If we do not have resources we use hwmod to fill them.
If we have resources we check if we already able to recive DMA resource, if
no we only append the DMA resurce from hwmod to the OF provided ones.
In this way we can start removing hwmod data for devices which have their
resources correctly configured in DT without regressions.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/omap_device.c | 80
+++-
1 file changed, 47 insertions(+), 33 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c
b/arch/arm/plat-omap/omap_device.c
index 915cf68..a8a9d08 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -560,55 +560,69 @@ struct omap_device *omap_device_alloc(struct
platform_device *pdev,
od-hwmods = hwmods;
od-pdev = pdev;
- /* Count all resources for the device */
- res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
- IORESOURCE_DMA |
- IORESOURCE_MEM);
/*
+ * Non-DT Boot:
+ * Here, pdev-num_resources = 0, and we should get all the
+ * resources from hwmod.
+ *
* DT Boot:
* OF framework will construct the resource structure (currently
* does for MEM IRQ resource) and we should respect/use these
* resources, killing hwmod dependency.
* If pdev-num_resources 0, we assume that MEM IRQ resources
* have been allocated by OF layer already (through DTB).
- *
- * Non-DT Boot:
- * Here, pdev-num_resources = 0, and we should get all the
- * resources from hwmod.
+ * As preparation for the future we examine the OF provided resources
+ * to see if we have DMA resources provided already. In this case
+ * there is no need to update the resources for the device, we use the
+ * OF provided ones.
*
* TODO: Once DMA resource is available from OF layer, we should
* kill filling any resources from hwmod.
*/
- if (res_count pdev-num_resources) {
- /* Allocate resources memory to account for new resources */
- res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
- if (!res)
- goto oda_exit3;
-
- /*
- * If pdev-num_resources 0, then assume that,
- * MEM and IRQ resources will only come from DT and only
- * fill DMA resource from hwmod layer.
- */
- if (pdev-num_resources pdev-resource) {
- dev_dbg(pdev-dev, %s(): resources already allocated
%d\n,
- __func__, res_count);
- memcpy(res, pdev-resource,
-sizeof(struct resource) * pdev-num_resources);
- _od_fill_dma_resources(od, res[pdev-num_resources]);
- } else {
- dev_dbg(pdev-dev, %s(): using resources from hwmod
%d\n,
- __func__, res_count);
- omap_device_fill_resources(od, res);
+ if (!pdev-num_resources) {
+ /* Count all resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
+ IORESOURCE_DMA |
+ IORESOURCE_MEM);
+ } else {
+ /* Take a look if we already have DMA resource via DT */
+ for (i = 0; i pdev-num_resources; i++) {
+ struct resource *r = pdev-resource[i];
+
+ /* We have it, no need to touch the resources */
+ if (r-flags == IORESOURCE_DMA)
+ goto have_everything;
}
+ /* Count only DMA resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_DMA);
We have devices without DMA channel so we can skip the resource recreation for
them.
I'll resend the series with this update.
+ res_count += pdev-num_resources;
+ }
- ret = platform_device_add_resources(pdev, res, res_count);
- kfree(res);
+ /* Allocate resources memory to account for new resources */
+
Re: OMAP baseline test results for v3.7-rc1
Hi Jean, On Tue, 30 Oct 2012, Jean Pihet wrote: On Tue, Oct 30, 2012 at 5:16 AM, Paul Walmsley p...@pwsan.com wrote: On Tue, 23 Oct 2012, Jean Pihet wrote: Let me try with the same setup as yours (bootloader images, omap2pus_defconfig, angstrom roots). Had any luck reproducing this one that Aaro I are seeing? Unfortunately not. I could not reproduce the issue on my side, using an ES2.1 Beagleboard with the latest l-o kernel and your bootloader and rootfs images. Is there some specific to enable in order to reproduce the issue? Could you please post a bootlog from your terminal program, similar to http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/boot/3530es3beagle/3530es3beagle_log.txt ? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] ARM: OMAP: hwmod: Add possibility to count hwmod resources based on type
Add flags parameter for omap_hwmod_count_resources() so users can tell which
type of resources they are interested when counting them in hwmod database.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 27 ---
arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +-
arch/arm/plat-omap/omap_device.c | 11 ---
3 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index b969ab1..a79c941 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -3337,7 +3337,7 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
/**
* omap_hwmod_count_resources - count number of struct resources needed by
hwmod
* @oh: struct omap_hwmod *
- * @res: pointer to the first element of an array of struct resource to fill
+ * @flags: Type of resources to include when counting (IRQ/DMA/MEM)
*
* Count the number of struct resource array elements necessary to
* contain omap_hwmod @oh resources. Intended to be called by code
@@ -3350,20 +3350,25 @@ int omap_hwmod_reset(struct omap_hwmod *oh)
* resource IDs.
*
*/
-int omap_hwmod_count_resources(struct omap_hwmod *oh)
+int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags)
{
- struct omap_hwmod_ocp_if *os;
- struct list_head *p;
- int ret;
- int i = 0;
+ int ret = 0;
- ret = _count_mpu_irqs(oh) + _count_sdma_reqs(oh);
+ if (flags IORESOURCE_IRQ)
+ ret += _count_mpu_irqs(oh);
- p = oh-slave_ports.next;
+ if (flags IORESOURCE_DMA)
+ ret += _count_sdma_reqs(oh);
- while (i oh-slaves_cnt) {
- os = _fetch_next_ocp_if(p, i);
- ret += _count_ocp_if_addr_spaces(os);
+ if (flags IORESOURCE_MEM) {
+ int i = 0;
+ struct omap_hwmod_ocp_if *os;
+ struct list_head *p = oh-slave_ports.next;
+
+ while (i oh-slaves_cnt) {
+ os = _fetch_next_ocp_if(p, i);
+ ret += _count_ocp_if_addr_spaces(os);
+ }
}
return ret;
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index b3349f7..48a6f5d 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -628,7 +628,7 @@ void omap_hwmod_write(u32 v, struct omap_hwmod *oh, u16
reg_offs);
u32 omap_hwmod_read(struct omap_hwmod *oh, u16 reg_offs);
int omap_hwmod_softreset(struct omap_hwmod *oh);
-int omap_hwmod_count_resources(struct omap_hwmod *oh);
+int omap_hwmod_count_resources(struct omap_hwmod *oh, unsigned long flags);
int omap_hwmod_fill_resources(struct omap_hwmod *oh, struct resource *res);
int omap_hwmod_fill_dma_resources(struct omap_hwmod *oh, struct resource *res);
int omap_hwmod_get_resource_byname(struct omap_hwmod *oh, unsigned int type,
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 7a7d1f2..915cf68 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -442,19 +442,21 @@ int omap_device_get_context_loss_count(struct
platform_device *pdev)
/**
* omap_device_count_resources - count number of struct resource entries needed
* @od: struct omap_device *
+ * @flags: Type of resources to include when counting (IRQ/DMA/MEM)
*
* Count the number of struct resource entries needed for this
* omap_device @od. Used by omap_device_build_ss() to determine how
* much memory to allocate before calling
* omap_device_fill_resources(). Returns the count.
*/
-static int omap_device_count_resources(struct omap_device *od)
+static int omap_device_count_resources(struct omap_device *od,
+ unsigned long flags)
{
int c = 0;
int i;
for (i = 0; i od-hwmods_cnt; i++)
- c += omap_hwmod_count_resources(od-hwmods[i]);
+ c += omap_hwmod_count_resources(od-hwmods[i], flags);
pr_debug(omap_device: %s: counted %d total resources across %d
hwmods\n,
od-pdev-name, c, od-hwmods_cnt);
@@ -558,7 +560,10 @@ struct omap_device *omap_device_alloc(struct
platform_device *pdev,
od-hwmods = hwmods;
od-pdev = pdev;
- res_count = omap_device_count_resources(od);
+ /* Count all resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
+ IORESOURCE_DMA |
+ IORESOURCE_MEM);
/*
* DT Boot:
* OF framework will construct the resource structure (currently
--
1.7.12.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More
[PATCH v2 0/2] ARM: OMAP: hwmod/omapd_device: Fix for resource handling in DT boot
Hello, Changes since v1: - If the device does not have DMA resource do not try to recreate the resources Intro mail from v1: This series resolves the issue we currently have with the resource handling when booting with DT. In short: at the moment the omap_device_alloc() decides if it needs to update the OF filled resources based on the number of resources on the device and in the hwmod database. This prevents us from removing hwmod data for platforms (OMAP5) which does not support non DT boot anymore. With this series we can make sure that the DT provided resources are used and we only append the DMA resources to the device from hwmod. I have added extra check to prepare us when the DMA resource can be filled via OF. In this case we do not update the resources at all. Tony, Benoit, Paul: Not sure if this qualify for 3.7 inclusion, but for sure going to help us to clean up the OMAP5 hwmod database. Regards, Peter --- Peter Ujfalusi (2): ARM: OMAP: hwmod: Add possibility to count hwmod resources based on type ARM: OMAP: omap_device: Correct resource handling for DT boot arch/arm/mach-omap2/omap_hwmod.c | 27 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +- arch/arm/plat-omap/omap_device.c | 87 ++-- 3 files changed, 72 insertions(+), 44 deletions(-) -- 1.7.12.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 v2 2/2] ARM: OMAP: omap_device: Correct resource handling for DT boot
When booting with DT the OF core can fill up the resources provided within
the DT blob.
The current way of handling the DT boot prevents us from removing hwmod data
for platforms only suppose to boot with DT (OMAP5 for example) since we need
to keep the whole hwmod database intact in order to have more resources in
hwmod than in DT (to be able to append the DMA resource from hwmod).
To fix this issue we just examine the OF provided resources:
If we do not have resources we use hwmod to fill them.
If we have resources we check if we already able to recive DMA resource, if
no we only append the DMA resurce from hwmod to the OF provided ones.
In this way we can start removing hwmod data for devices which have their
resources correctly configured in DT without regressions.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/plat-omap/omap_device.c | 84
1 file changed, 51 insertions(+), 33 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 915cf68..d35b468 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -560,55 +560,73 @@ struct omap_device *omap_device_alloc(struct
platform_device *pdev,
od-hwmods = hwmods;
od-pdev = pdev;
- /* Count all resources for the device */
- res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
- IORESOURCE_DMA |
- IORESOURCE_MEM);
/*
+* Non-DT Boot:
+* Here, pdev-num_resources = 0, and we should get all the
+* resources from hwmod.
+*
* DT Boot:
* OF framework will construct the resource structure (currently
* does for MEM IRQ resource) and we should respect/use these
* resources, killing hwmod dependency.
* If pdev-num_resources 0, we assume that MEM IRQ resources
* have been allocated by OF layer already (through DTB).
-*
-* Non-DT Boot:
-* Here, pdev-num_resources = 0, and we should get all the
-* resources from hwmod.
+* As preparation for the future we examine the OF provided resources
+* to see if we have DMA resources provided already. In this case
+* there is no need to update the resources for the device, we use the
+* OF provided ones.
*
* TODO: Once DMA resource is available from OF layer, we should
* kill filling any resources from hwmod.
*/
- if (res_count pdev-num_resources) {
- /* Allocate resources memory to account for new resources */
- res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
- if (!res)
- goto oda_exit3;
-
- /*
-* If pdev-num_resources 0, then assume that,
-* MEM and IRQ resources will only come from DT and only
-* fill DMA resource from hwmod layer.
-*/
- if (pdev-num_resources pdev-resource) {
- dev_dbg(pdev-dev, %s(): resources already allocated
%d\n,
- __func__, res_count);
- memcpy(res, pdev-resource,
- sizeof(struct resource) * pdev-num_resources);
- _od_fill_dma_resources(od, res[pdev-num_resources]);
- } else {
- dev_dbg(pdev-dev, %s(): using resources from hwmod
%d\n,
- __func__, res_count);
- omap_device_fill_resources(od, res);
+ if (!pdev-num_resources) {
+ /* Count all resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_IRQ |
+ IORESOURCE_DMA |
+ IORESOURCE_MEM);
+ } else {
+ /* Take a look if we already have DMA resource via DT */
+ for (i = 0; i pdev-num_resources; i++) {
+ struct resource *r = pdev-resource[i];
+
+ /* We have it, no need to touch the resources */
+ if (r-flags == IORESOURCE_DMA)
+ goto have_everything;
}
+ /* Count only DMA resources for the device */
+ res_count = omap_device_count_resources(od, IORESOURCE_DMA);
+ /* The device has no DMA resource, no need for update */
+ if (!res_count)
+ goto have_everything;
+
+ res_count += pdev-num_resources;
+ }
- ret = platform_device_add_resources(pdev, res, res_count);
- kfree(res);
+ /* Allocate resources memory to account for
Re: [PATCH 0/2] ARM: OMAP: hwmod/omapd_device: Fix for resource handling in DT boot
On Tue, 30 Oct 2012, Peter Ujfalusi wrote: Tony, Benoit, Paul: Not sure if this qualify for 3.7 inclusion, but for sure going to help us to clean up the OMAP5 hwmod database. It's definitely not 3.7 material, but will look at it for 3.8 merge window. The OMAP5 hwmod data isn't in mainline yet. - 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: OMAP baseline test results for v3.7-rc3
On 30/10/12 02:36, Paul Walmsley wrote: Here are some basic OMAP test results for Linux v3.7-rc3. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.7-rc3/20121028162003/ Passing tests - Boot to userspace: 2420n800, 3517evm, 3530es3beagle, 3730beaglexm, 37xxevm, 4430es2panda, 5912osk, am335xbone PM ret/off, suspend + dynamic idle: (none) Failing tests: fixed by posted patches -- Boot tests: * 2430sdp: vfp_reload_hw oops during MMC initialization - Kernel attempts to save FP registers that don't exist; fix posted: - http://www.spinics.net/lists/arm-kernel/msg200646.html - added to rmk's patch system as 7566/1 * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - Due to GPMC missing support for DT - Temporary workaround at http://www.spinics.net/lists/arm-kernel/msg200787.html - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 At what point is booting from MMC on the BeagleBone going to start working ? I only ask, since, by default, a new BeagleBone is setup to boot from MMC, so anyone testing a new kernel will probably expect the same setup to work. Cheers Mark JACKSON -- 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/2] ARM: OMAP: hwmod/omapd_device: Fix for resource handling in DT boot
On 10/30/2012 12:25 PM, Paul Walmsley wrote: On Tue, 30 Oct 2012, Peter Ujfalusi wrote: Tony, Benoit, Paul: Not sure if this qualify for 3.7 inclusion, but for sure going to help us to clean up the OMAP5 hwmod database. It's definitely not 3.7 material, but will look at it for 3.8 merge window. The OMAP5 hwmod data isn't in mainline yet. True, it can wait till 3.8. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc3
cc Vaibhav Hiremath On Tue, 30 Oct 2012, Mark Jackson wrote: At what point is booting from MMC on the BeagleBone going to start working ? I only ask, since, by default, a new BeagleBone is setup to boot from MMC, so anyone testing a new kernel will probably expect the same setup to work. BeagleBone boots initramfs from MMC now, which is what mine was shipped to do. Are you asking about rootfs on MMC? If so, Vaibhav would have a better sense of this than I. - 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] [PATCH] remove pcm049 from Makefile
Hello. You forgot to sign off on the patch, so it can't be applied. 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: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi, On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote: This is why I think hiding things from drivers makes no sense. Also consider the situations Linus W exposed on another subthread. If you change ordering of certain calls, you will really break the functionality of the IP. Because we can't make sure this won't work automagically in all cases (just like we can't make sure $size memory allocation is enough for all drivers) we don't hide that from the driver. We require driver to manage its resources properly. We need some place to put the SoC integration; power domains seem like the obvious place to me but YMMV. Nothing about having this out of the except that pin muxing has nothing to do with power domain. To me that sounds like an abuse of the API. drivers requires that this be done by individual subsystems in isolation from each other. Half the point here is that for the reusable IPs this stuff often isn't driver specific at all, it's often more about the SoC integration than it is about the driver and so you'll get a consistent pattern for most IPs on the SoC. and all of that SoC-specific detail is already hidden behind power domains, runtime PM, pinctrl, clk API, regulator framework, etc. How can you make sure that this will work for at least 50% of the drivers ? You just can't. We don't know the implementation details of every arch/soc/platform supported by Linux today to make that decision. Well, we've managed to get along for rather a long time with essentially all architectures implementing this stuff by doing static setup for the pins on boot. That does suggest we can get a reasonably long way with and this is one of the issues we're all trying to solve today so we have single zImage approach for the ARM port. something simple, and it does seem to match up with how things usually look at an electrical level too. simple ? I really doubt it. Just look at the amount of code duplication the ARM port had (still has in some places) to handle platform-specific details. It turned out that drivers weren't very portable when they had to do platform-specific initialization, we were all abusing platform_data to pass strings and/or function pointers down to drivers and so on. I'm concerned if we hide pinctrl under e.g. power domains (as said above, it sounds like an abuse of the API to me) we will end up with a situation like above. Maybe not as bad, but still weird-looking. It seems fairly obvious that if we need to add identical bolier plate code to lots of drivers we're doing something wrong, it's just churn for little practical gain and a problem if we ever decide to change how this stuff works in the future. I wouldn't consider it boilerplate if you remember that each driver might have different requirements regarding how all of those details need to be handled. We have to consider power consumption, ordering of calls, proper IP setup, IP reuse on multiple platforms (even multiple ARCHes), etc etc, and to get that right outside of the driver - who's the only class that actually knows what it needs to do with its resources - will just be too complex and error-prone. I would strongly suggest starting with explicit calls to pinctrl, clk API, etc and if we can really prove later that 95% of the users are standard, then we can factor code out, but making that assumption now is quite risky IMHO. -- balbi signature.asc Description: Digital signature
Re: [PATCH 00/13] ARM: OMAP: remove prcm.[ch]
On Mon, 29 Oct 2012, Vaibhav Hiremath wrote: On 10/26/2012 4:51 AM, Paul Walmsley wrote: Remove arch/arm/mach-omap2/prcm.c and arch/arm/plat-omap/include/plat/prcm.h. This is in preparation for moving the PRM/CM code to drivers/, although to be fair, these files should have been removed a long time ago. Intended for 3.8 cleanup. Applies on top of the existing PRM/CM split cleanup series, and the WDTIMER cleanup series. Paul, By any chance you have branch available with these patches, so that I can validate them here at my end? The current version is at git://git.pwsan.com/linux-2.6 in the branch prcm_cleanup_b_3.8 - 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 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
Tony, On 29 October 2012 12:52, Tony Lindgren t...@atomide.com wrote: --- /dev/null +++ b/include/linux/platform_data/omap_mailbox.h @@ -0,0 +1,105 @@ This file should only contain pure platform data needed by the core omap code to pass to the mailbox driver. Ok, looking at it closely, this header file is related to the API itself, there is nothing that could be actually considered as pure platform data, the structures are related with the mailbox framework and even if I split this file into two, the additional header would end up including the platform_data header unless I move save/restore_ctx functions and then export them as symbols for the API. So, it might be better for the entire file to sit in linux/include/mailbox/ then. The mailbox API header should be somewhere else, like include/linux/mailbox/mailbox-omap.h or similar. Ok. But shouldn't this all now be handled by using the remoteproc framework? Remoteproc doesn't handle the mailbox hardware directly, it still relies in the mailbox framework for the low level communications. E.g.: Proc1 has a message (virtqueue msg) queued to Proc2, uses mailbox msg to generate an interrupt to Proc2, Proc2 queries the message (virtqueue) based on the mailbox message received. Regards, Omar -- 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: Problem with OHCI on OMAP4430
Alan, On Mon, Oct 29, 2012 at 8:54 PM, Alan Stern st...@rowland.harvard.edu wrote: On Mon, 29 Oct 2012, Mohan V wrote: I'm not going to be able to help very much with an Android kernel. Does the same problem occur with a vanilla non-Android 3.6 kernel? If it doesn't, that indicates the problem was caused by some Android-specific changes. With the vanilla 3.6 kernel, the device connected to OHCI port is not even detected. The below messages are seen: [5.343780] usb 2-2: new low-speed USB device number 5 using ohci-omap3 [5.351776] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out 5ec2 cc 5 -- status -62 [5.570770] ohci-omap3 ohci-omap3.0: urb ee7f83c0 path 2 ep0out 5ec2 cc 5 -- status -62 [5.789062] usb 2-2: device not accepting address 5, error -62 [5.795288] hub 2-0:1.0: unable to enumerate USB device on port 2 It looks like the device was detected just fine but the host was unable to communicate with it. I don't know why; maybe a clock or power line wasn't turned on properly or a PHY wasn't enabled. We think it may not be hardware issue, since the device gets detected on android-3.0 kernel. The support for OHCI on OMAP4430 SDP board seems to be missing in Linux mainline (3.6). We ported some OMAP specific patches from android kernel, with this the device gets detected only if it is connected at boot. If the system is booted and then device is connected, it doesn't get detected. Doesn't get detected, or does get detected but then doesn't communicate? The device does not get detected. Perhaps you should send some questions to the maintainers of the various ohci-omap drivers or the Android maintainers. Keshava, can you please comment? Are you referring to this part of the log? Device not getting detected when connected--- / # [ 135.621002] usbhs_wakeup: Enabling clocks [ 135.625762] usbhs_runtime_resume:++ [ 135.630371] usbhs_runtime_resume:-- [ 135.638183] USB IO PAD Wakeup event triggered## [ 135.644958] usbhs_runtime_suspend:++ [ 135.649749] usbhs_runtime_suspend:- It appears that ohci_irq() didn't run. Did ohci_finish_controller_resume() get called? This function is not used in ohci-omap3.c and is used only in ohci-omap.c. Is it necessary to call this function? It is necessary if the driver supports suspend/resume. As far as I can tell, the ohci-omap3 driver does not have this support (at least, not in the 3.6 kernel) whereas the ohci-omap driver does. What driver produced the usbhs_runtime_suspend and usbhs_runtime_resume messages above? (No such messages are present in ohci-omap3.c.) Apparently that driver _does_ support suspend/resume. This driver is USBHS core driver for OMAP EHCI and OHCI (drivers/mfd/omap-usb-host.c) Thanks, Mohan -- 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 baseline test results for v3.7-rc1
Hi, On Tue, Oct 30, 2012 at 12:17:11PM +, Paul Walmsley wrote: On Mon, 29 Oct 2012, Felipe Balbi wrote: that's too bad :-( Can you compile with: CONFIG_I2C_DEBUG_CORE=y CONFIG_I2C_DEBUG_ALGO=y CONFIG_I2C_DEBUG_BUS=y CONFIG_DEFAULT_MESSAGE_LOGLEVEL=9 so that I can see all transfers ? Log is below. that's working. It only helps to let me know we have a race somewhere, and if it is what I'm thinking, the wmb() patch should help, but you said it doesn't, right ? without seeing debugging information on the failing case, it'll be very difficult to sort this one out provided noone else seems to be able to reproduce it. -- balbi signature.asc Description: Digital signature
RE: OMAP baseline test results for v3.7-rc3
On Tue, Oct 30, 2012 at 17:17:00, Paul Walmsley wrote: cc Vaibhav Hiremath On Tue, 30 Oct 2012, Mark Jackson wrote: At what point is booting from MMC on the BeagleBone going to start working ? I only ask, since, by default, a new BeagleBone is setup to boot from MMC, so anyone testing a new kernel will probably expect the same setup to work. BeagleBone boots initramfs from MMC now, which is what mine was shipped to do. Are you asking about rootfs on MMC? If so, Vaibhav would have a better sense of this than I. Mark, MMC is dependent on EDMA-DMA conversion patches from Matt, which he has already submitted to the list recently. So MMC support will come along with EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes. If you refer to the Matt's repo, you should get all the patches required to boot MMC support - https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3 Thanks, Vaibhav -- 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 baseline test results for v3.7-rc1
On Tue, 30 Oct 2012, Felipe Balbi wrote: the wmb() patch should help, but you said it doesn't, right ? Correct. Not sure why you think that would help; the problem is almost certainly PM-idle related, given that the problem goes away by reverting Jean's commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints. The problem is consistent and easy to reproduce here. without seeing debugging information on the failing case, it'll be very difficult to sort this one out provided noone else seems to be able to reproduce it. Aaro sees it also, so it's definitely not a local artifact. It's not very surprising that the problem doesn't appear with the extra logging enabled, since the extra logging presumably keeps the system out of idle. Anyway, you are welcome to the userspace, bootloader, and X-loader here if you would like to try to reproduce it. They've been sent to Jean and Kevin and Shubhrajyoti already. Simply request it and I will send links. - 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: OMAP baseline test results for v3.7-rc1
Hi, On Tue, Oct 30, 2012 at 12:50:52PM +, Paul Walmsley wrote: On Tue, 30 Oct 2012, Felipe Balbi wrote: the wmb() patch should help, but you said it doesn't, right ? Correct. Not sure why you think that would help; the problem is almost because of how the driver is behaving... The only way for omap_i2c_wait_for_bb() to timeout is if the bus is really still busy; meaning that either transfer hasn't fully completed (some data still in FIFO), or we didn't send STOP or Repeated START condition on the bus. certainly PM-idle related, given that the problem goes away by reverting Jean's commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints. The problem is consistent and easy to reproduce here. I don't doubt that :-) What I think, however, is that PM QoS just made the problem a bit easier to trigger for whatever reason. Maybe because pm qos defers constraint updates, or something similar ? without seeing debugging information on the failing case, it'll be very difficult to sort this one out provided noone else seems to be able to reproduce it. Aaro sees it also, so it's definitely not a local artifact. Again I don't doubt it. It's not very surprising that the problem doesn't appear with the extra logging enabled, since the extra logging presumably keeps the system out of idle. Anyway, you are welcome to the userspace, bootloader, and X-loader here if you would like to try to reproduce it. They've been sent to Jean and Kevin and Shubhrajyoti already. Simply request it and I will send links. I can have a look, sure, but I don't have the same platform as you have. I have a beagle XM revB (according to the stickers on the board) which I could use to try to reproduce, if I manage to, then hooray :-) In that case, please give me also a link to your uImage so I can make sure to use the exact same setup. cheers -- balbi signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc3
On Tue, 30 Oct 2012, Vaibhav Hiremath wrote: On 10/30/2012 8:06 AM, Paul Walmsley wrote: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - Due to GPMC missing support for DT - Temporary workaround at http://www.spinics.net/lists/arm-kernel/msg200787.html - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 This is surprising, I have tested v3.7-rc3 branch on AM335xBone platform and its booting up for me without any issues. Jon had submitted another patch which fixes boot issue on Bone. https://patchwork.kernel.org/patch/1606471/ Please don't worry about this one at the moment. This one isn't part of the automated test suite, so it requires further effort from me to re-test. I've marked it as such in the README. Will try to re-test by v3.7-rc4. - 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: OMAP baseline test results for v3.7-rc1
On Tue, 30 Oct 2012, Felipe Balbi wrote: On Tue, Oct 30, 2012 at 12:50:52PM +, Paul Walmsley wrote: certainly PM-idle related, given that the problem goes away by reverting Jean's commit 3db11feffc1ad2ab9dea27789e6b5b3032827adc ARM: OMAP: convert I2C driver to PM QoS for MPU latency constraints. The problem is consistent and easy to reproduce here. I don't doubt that :-) What I think, however, is that PM QoS just made the problem a bit easier to trigger for whatever reason. Maybe because pm qos defers constraint updates, or something similar ? Based on a very quick look, I'd say the original patch 3db11fe is broken. I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for omap2plus_defconfig. - 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: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
broo...@opensource.wolfsonmicro.com wrote:
On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
Moving this handling to bus code or anywhere else
invariably implies that resource acquisition/release order
does not matter, and my point is that it does.
Doing this in the buses is definitely wrong, as you say it's not bus
specific. I do however think we can usefully do this stuff in a SoC
specific place like a power domain, keeping the SoC integration code
together and out of the drivers. IME the SoCs where you need to do
different things for different IPs shoudl mostly still get some reuse
out of such an approach.
Talking to Kevin Hilman today he was also stressing that
power domains is a good thing for handling resources, especially
when replacing prior hacks in the custom clk code. However
he pointed specifically to clocks and voltages, which may
be true.
What worries me is when knowledge of the hardware which
is traditionally a concern for the device driver start to
bubble up to the power domain (or better renamed resource
domain if use like this, as Felipe points out).
I worry that we will end up with power/resource domain
code that start to look like this:
suspend()
switch (device.id) {
case DEV_FOO:
clk_disable();
pinctrl_set_state();
power_domain_off();
case DEV_BAR:
pinctrl_set_state();
clk_disable();
// Always-on domain
case DEV_BAZ:
pinctrl_set_state();
clk_disable();
power_domain_off();
case ...
Mutate the above with silicon errata, specific tweaks etc that
Felipe was mentioning.
What is happening is that device-specific behaviour which
traditionally handled in the driver is now inside the
power/resource domain.
I agree that if the domain was doing the same thing for each
piece of hardware, this would be the right thing to do,
and I think the in-kernel examples are all simple,
e.g. arch/arm/mach-omap2/powerdomain* is all about
power domains and nothing else, and the notifiers used
by SHmobile is all about clock gating and nothing else.
Another effect is that moving all resource handling to
power domains is that if we do that for a widely shared
device driver like the PL011 that mandates that power
domains need to be implemented for U300, Ux500,
Nomadik, SPEAr 13xx, 3xx, 6xx, Versatile, Versatile
Express, Integrator (AP CP) and BCM2835. Probably
more.
None of which has power domains (upstream) as
of today. Some of which (U300, Ux500, Nomadik,
SPEAr, Integrator, BCM2835) implement pin control.
Basically power (resource) domains have the side-effect
of in this light not doing one thing (power domains) but
instead imposing all-or-nothing imperialistic characteristics.
While avoiding a set of distributed, optional pinctrl hooks,
it mandates a central piece of upfront powerdomain
boilerplate to be present in each and every platform that
wants to control its pins.
I think the lesser of two evils is the distributed approach,
and then I'm talking about pinctrl only, disregarding the
fact that clocks and power domains are basically subject to
the same kind of argument. I still buy into the concept of
using power domains for exactly power domains only.
Arguably this is an elegance opinion...
I worry that the per-SoC power domain implementation
which will live in arch/arm/mach-* as of today will become
the new board file problem, overburdening the arch/* tree.
Maybe I'm mistaken as to the size of these things,
but just doing ls arch/arm/mach-omap2/powerdomain*
makes me start worrying.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc1
On Tue, 30 Oct 2012, Paul Walmsley wrote: Based on a very quick look, I'd say the original patch 3db11fe is broken. I don't see how it can ensure that its PM_QOS_CPU_DMA_LATENCY request is honored when CONFIG_CPU_IDLE=n. CONFIG_CPU_IDLE=n is the default for omap2plus_defconfig. So in fact to follow up on this, looks like one of two changes are needed: 1. Revert 3db11fe or 2. If CONFIG_CPU_IDLE=n, the driver needs to call disable_hlt() in place of the pm_qos constraint add, and call enable_hlt() in place of the pm_qos constraint remove. Jean, could you please pick a solution and send a patch for the 3.7-rc timeframe, to fix the bug in 3db11fe? ? - 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: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote: On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote: We need some place to put the SoC integration; power domains seem like the obvious place to me but YMMV. Nothing about having this out of the except that pin muxing has nothing to do with power domain. To me that sounds like an abuse of the API. Well, we can call the API Archibald if we like... what I mean is something that sits in the system below the device in pretty much exactly the way that power domains do. drivers requires that this be done by individual subsystems in isolation from each other. Half the point here is that for the reusable IPs this stuff often isn't driver specific at all, it's often more about the SoC integration than it is about the driver and so you'll get a consistent pattern for most IPs on the SoC. and all of that SoC-specific detail is already hidden behind power domains, runtime PM, pinctrl, clk API, regulator framework, etc. That's all getting rather open coded, especially if you're going to get down to a situation where you have varying ordering constraints between the different APIs on different SoCs. How can you make sure that this will work for at least 50% of the drivers ? You just can't. We don't know the implementation details of every arch/soc/platform supported by Linux today to make that decision. Well, we've managed to get along for rather a long time with essentially all architectures implementing this stuff by doing static setup for the pins on boot. That does suggest we can get a reasonably long way with and this is one of the issues we're all trying to solve today so we have single zImage approach for the ARM port. I don't see the relevance of single zImage here; device tree is supposed to solve that one. something simple, and it does seem to match up with how things usually look at an electrical level too. simple ? I really doubt it. Just look at the amount of code duplication the ARM port had (still has in some places) to handle platform-specific details. What I'm saying here is that I'm concerned about us ending up with more code duplication... It turned out that drivers weren't very portable when they had to do platform-specific initialization, we were all abusing platform_data to pass strings and/or function pointers down to drivers and so on. I'm concerned if we hide pinctrl under e.g. power domains (as said above, it sounds like an abuse of the API to me) we will end up with a situation like above. Maybe not as bad, but still weird-looking. Well, nothing's going to stop that happening if people are determined enough - one could equally see that there'll be flags getting passed to control the ordering of calls if things are open coded. I would expect that with a power domain style approach any data would be being passed directly and bypassing the driver completely. It seems fairly obvious that if we need to add identical bolier plate code to lots of drivers we're doing something wrong, it's just churn for little practical gain and a problem if we ever decide to change how this stuff works in the future. I wouldn't consider it boilerplate if you remember that each driver might have different requirements regarding how all of those details need to be handled. Essentially all the patches I'm seeing adding pinctrl are totally mindless, most of them are just doing the initial setup on boot and not doing any active management at runtime at all. We have to consider power consumption, ordering of calls, proper IP setup, IP reuse on multiple platforms (even multiple ARCHes), etc etc, and to get that right outside of the driver - who's the only class that actually knows what it needs to do with its resources - will just be too complex and error-prone. A big part of my point here is that it's not at all clear to me that it is the driver which knows what's going on. For SoC-specific IPs you can be confident about how the SoC integration looks but for IPs that get reused widely this becomes less true. I would strongly suggest starting with explicit calls to pinctrl, clk API, etc and if we can really prove later that 95% of the users are standard, then we can factor code out, but making that assumption now is quite risky IMHO. Like I say I think we're already seeing a pattern here, the code going into most drivers looks *very* similar with lots of the drivers simply calling get_select_default(). signature.asc Description: Digital signature
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Tue, Oct 30, 2012 at 12:49 PM, Felipe Balbi ba...@ti.com wrote: On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote: We need some place to put the SoC integration; power domains seem like the obvious place to me but YMMV. Nothing about having this out of the except that pin muxing has nothing to do with power domain. To me that sounds like an abuse of the API. It could be renamed to power resources or something as long as it's related to resource handling related to the PM calls. But I worry that it violates the Unix principle to do one thing and one thing only. A device power resource framework goes in the opposite direction, trying to do a lot of unrelated things in a central place as opposed to distributing the task. drivers requires that this be done by individual subsystems in isolation from each other. Half the point here is that for the reusable IPs this stuff often isn't driver specific at all, it's often more about the SoC integration than it is about the driver and so you'll get a consistent pattern for most IPs on the SoC. and all of that SoC-specific detail is already hidden behind power domains, runtime PM, pinctrl, clk API, regulator framework, etc. I agree. pinctrl has already done a fair job at trying to be abstract in the states requested from the core, in linux/pinctrl/pinctrl-state.h. And I accept the idea to try to centralize more as well, maybe as a helpful struct and some inlines for the pinctrl core. I think this is enough, and pushing all handles into central code creates a problem elsewhere. (But I'm not so certain ... so I might just change opinion one of those days depending on what arguments will be made.) Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2] leds: leds-gpio: adopt pinctrl support
On Wed, Oct 03, 2012 at 18:06:10, Linus Walleij wrote:
On Wed, Oct 3, 2012 at 12:52 PM, AnilKumar, Chimata anilku...@ti.com wrote:
On Tue, Oct 02, 2012 at 01:29:37, Linus Walleij wrote:
This is what we're doing for ux500 and should be a good model.
I have looked into this, but not seen any named modes.
OK maybe it's not easy to find. If you look into:
arch/arm/mach-ux500/board-mop500-pins.c
you find our work in progress. Note that this is not (yet)
using device tree. (We want to migrate all our pinctrl
stuff first, then do DT.)
So for example this macro:
#define DB8500_PIN(pin,conf,dev) \
PIN_MAP_CONFIGS_PIN_DEFAULT(dev, pinctrl-db8500, pin, conf)
Will define a config for the default mode for a certain
pin.
This:
#define DB8500_PIN_SLEEP(pin, conf, dev) \
PIN_MAP_CONFIGS_PIN(dev, PINCTRL_STATE_SLEEP, pinctrl-db8500, \
pin, conf)
Will mutatis mutandis define a sleep mode for a pin.
Sorry for the macros. We'll get rid of them in the DT.
(Now that Stephen has patched in preprocessing it will
even look good.)
Hi Linus Walleij/Tony,
I completely understood this named modes, I have added named
modes like this in am335x-xxx.dts files
am33xx_pinmux: pinmux@44e10800 {
pinctrl-names = default, sleep;
pinctrl-0 = user_leds_s0;
pinctrl-1 = user_leds_s1;
user_leds_s0: user_leds_s0 {
pinctrl-single,pins =
0x54 0x7/* gpmc_a5.gpio1_21, OUTPUT | MODE7 */
0x58 0x17 /* gpmc_a6.gpio1_22, OUT PULLUP | MODE7
*/
0x5c 0x7/* gpmc_a7.gpio1_23, OUTPUT | MODE7 */
0x60 0x17 /* gpmc_a8.gpio1_24, OUT PULLUP | MODE7
*/
;
};
user_leds_s1: user_leds_s1 {
pinctrl-single,pins =
0x54 0x2e /* gpmc_a5.gpio1_21, INPUT | MODE7 */
0x58 0x2e /* gpmc_a6.gpio1_22, INPUT | MODE7 */
0x5c 0x2e /* gpmc_a7.gpio1_23, INPUT | MODE7 */
0x60 0x2e /* gpmc_a8.gpio1_24, INPUT | MODE7 */
;
};
};
I think pinctrl-1 state will be used in driver
suspend/resume calls.
I have the pinmux/conf settings for default state but fully
optimized pinmux/conf values in idle suspend states are not
available yet. Even though if I add here, I am unable to test
these pins in suspend state because suspend/resume of AM35xx
is not added yet
I have two options now
- add only default states for now, I can add reset of
the state details once suspend/resume is supported.
- add same values in all the states, modify those once
suspend/resume is added for AM335x.
Thanks
AnilKumar
--
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] gpio: omap-gpio: add support for pm_runtime autosuspend
Hi Felipe, On 10/30/2012 02:09 AM, Felipe Balbi wrote: ... its bit of an issue to take care. How do you ensure that GPIO does idle on SOC idle C-state attempts in such cases. Today that job is done by omap_gpio_[prepare/resume]_for_idle. that's only there because we pm_runtime_get_sync() on gpio_request() and pm_runtime_put_sync() only on gpio_free(). That's the problem IMHO. And that's easy enough to 'fix': call pm_runtime_mark_last_busy(); pm_runtime_put_sync_autosuspend(); also on gpio_request() and pm_runtime_get_sync() on gpio_free(). Sounds like a good approach. I have been discussing with Kevin and I need to look more at the resume handler as we are working around some old issues in there and with this approach the resume following idle will be delayed and we were not sure if there could be any implications for omap2. I am hoping not, but we need to look into this. So I am wondering if we should just take Tim's original proposal for now and then I will look into improving this long term. I really need to clean-up the suspend/resume stuff for gpio and so may be we can make that a separate change. What do you think? ... The difficult part, IMHO, is to figure out what's a good autosuspend timeout to use. Some GPIO lines are used as IRQ lines on some devices, that means that the GPIO will be periodically triggered and, depending on our timeout, we will either loose IRQs or prevent power domain from idling. We could figure out a way to let board code to choose what it wants on a per-bank basis (maybe some extra DT attribute). I have also been bending Kevin's ear on this, this week and we were wondering if we should make the default 0 for now as this will have the same behaviour that we have today but would allow Tim to customise via the sysfs for his specific app. Cheers Jon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Tue, Oct 30, 2012 at 03:02:23PM +0100, Linus Walleij wrote:
I worry that we will end up with power/resource domain
code that start to look like this:
suspend()
switch (device.id) {
case DEV_FOO:
clk_disable();
pinctrl_set_state();
power_domain_off();
case DEV_BAR:
Well, if we're doing that then either we'd presumably either get the
same result if we open code it in the drivers or whoever wrote the
resource domain code for the platform should be creating multiple
domains.
Another effect is that moving all resource handling to
power domains is that if we do that for a widely shared
device driver like the PL011 that mandates that power
domains need to be implemented for U300, Ux500,
Nomadik, SPEAr 13xx, 3xx, 6xx, Versatile, Versatile
Express, Integrator (AP CP) and BCM2835. Probably
more.
Basically power (resource) domains have the side-effect
of in this light not doing one thing (power domains) but
instead imposing all-or-nothing imperialistic characteristics.
For me that's happening anyway with explicit control, just in different
places - for example the Freescale guys have had issues with IPs shared
between m68k and i.MX requiring that stub clocks be provided on m68k for
things that are always on there and similarly with all the platforms
that get affected when some widely used chip acquires regulator support.
It seems easier to organise things if the platform has responsibility
for coordinating this stuff than if we add stuff in the drivers.
I worry that the per-SoC power domain implementation
which will live in arch/arm/mach-* as of today will become
the new board file problem, overburdening the arch/* tree.
Maybe I'm mistaken as to the size of these things,
but just doing ls arch/arm/mach-omap2/powerdomain*
makes me start worrying.
One thing to remember is that OMAP has some of the most featureful
hardware out there in terms of software control for power so it's
unlikely to ever get much more complex than that. IME most SoCs
are very much simpler than that and should be able to punt lots of
stuff to device tree data.
signature.asc
Description: Digital signature
Re: [PATCH] ARM: OMAP2+: am33xx: Add PRM warm reset/reboot support
On Mon, 29 Oct 2012, Vaibhav Hiremath wrote: This patch adds reboot capability to all AM33XX based boards/EVM's, by asserting PRM warm reset bit on 'reboot' command. Signed-off-by: Vaibhav Hiremath hvaib...@ti.com Tested-by: Daniel Mack zon...@gmail.com Cc: Paul Walmsley p...@pwsan.com Cc: Tony Lindgren t...@atomide.com Cc: Afzal Mohammed af...@ti.com Sounds like you're already planning to do this - but could you rebase this on the 3.8 PRCM cleanup branch that was sent in a separate mail? thanks, - 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: OMAP baseline test results for v3.7-rc3
On 10/30/2012 6:09 PM, Hiremath, Vaibhav wrote: On Tue, Oct 30, 2012 at 17:17:00, Paul Walmsley wrote: cc Vaibhav Hiremath On Tue, 30 Oct 2012, Mark Jackson wrote: At what point is booting from MMC on the BeagleBone going to start working ? I only ask, since, by default, a new BeagleBone is setup to boot from MMC, so anyone testing a new kernel will probably expect the same setup to work. BeagleBone boots initramfs from MMC now, which is what mine was shipped to do. Are you asking about rootfs on MMC? If so, Vaibhav would have a better sense of this than I. Mark, MMC is dependent on EDMA-DMA conversion patches from Matt, which he has already submitted to the list recently. So MMC support will come along with EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes. If you refer to the Matt's repo, you should get all the patches required to boot MMC support - https://github.com/ohporter/linux/tree/edma-dmaengine-am33xx-v3 I just tested this branch (+ one fix which Matt provided [1]) on BeagleBone, and MMC is working without any issues. I have tested with rootFS on MMC card. [1] - http://www.spinics.net/lists/linux-omap/msg79911.html Thanks, Vaibhav Thanks, Vaibhav ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Tue, Oct 30, 2012 at 03:16:02PM +0100, Linus Walleij wrote: On Tue, Oct 30, 2012 at 3:07 PM, Mark Brown Essentially all the patches I'm seeing adding pinctrl are totally mindless, most of them are just doing the initial setup on boot and not doing any active management at runtime at all. I concludes in some other mails that all Ux500 drivers will need to handle atleast two states (default and sleep) and some a third state (idle). Right, that's the other common option and obviously it's just an extension of the simple hogs which maps very nicely onto the existing PM states for devices. And this is what we're doing in our patches. Arguably it can all be pushed to power domains, but that will as said mandate all affected systems to implement power domains, and effectively moving code from drivers/* to arch/arm/* in our case atleast. As soon as they start adding clock support and so on, yes. Obviously if they don't want to use any of the features that are offloaded like this then they could happily ignore it. signature.asc Description: Digital signature
Re: [PATCH] gpio: omap-gpio: add support for pm_runtime autosuspend
Hi, On Tue, Oct 30, 2012 at 09:16:34AM -0500, Jon Hunter wrote: Hi Felipe, On 10/30/2012 02:09 AM, Felipe Balbi wrote: ... its bit of an issue to take care. How do you ensure that GPIO does idle on SOC idle C-state attempts in such cases. Today that job is done by omap_gpio_[prepare/resume]_for_idle. that's only there because we pm_runtime_get_sync() on gpio_request() and pm_runtime_put_sync() only on gpio_free(). That's the problem IMHO. And that's easy enough to 'fix': call pm_runtime_mark_last_busy(); pm_runtime_put_sync_autosuspend(); also on gpio_request() and pm_runtime_get_sync() on gpio_free(). Sounds like a good approach. I have been discussing with Kevin and I need to look more at the resume handler as we are working around some old issues in there and with this approach the resume following idle will be delayed and we were not sure if there could be any implications for omap2. I am hoping not, but we need to look into this. So I am wondering if we should just take Tim's original proposal for now and then I will look into improving this long term. I really need to clean-up the suspend/resume stuff for gpio and so may be we can make that a separate change. What do you think? that'll cause a regression right ? The difficult part, IMHO, is to figure out what's a good autosuspend timeout to use. Some GPIO lines are used as IRQ lines on some devices, that means that the GPIO will be periodically triggered and, depending on our timeout, we will either loose IRQs or prevent power domain from idling. We could figure out a way to let board code to choose what it wants on a per-bank basis (maybe some extra DT attribute). I have also been bending Kevin's ear on this, this week and we were wondering if we should make the default 0 for now as this will have the I believe you mean -1 here ;-) same behaviour that we have today but would allow Tim to customise via the sysfs for his specific app. sysfs might be too late for his platform. What if he needs NFS root (just wondering, not sure about his use case) ? -- balbi signature.asc Description: Digital signature
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi, On Tue, Oct 30, 2012 at 02:07:15PM +, Mark Brown wrote: On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote: On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote: We need some place to put the SoC integration; power domains seem like the obvious place to me but YMMV. Nothing about having this out of the except that pin muxing has nothing to do with power domain. To me that sounds like an abuse of the API. Well, we can call the API Archibald if we like... what I mean is I'm sure you know it's not at all about the name and much more about the semantics ;-) something that sits in the system below the device in pretty much exactly the way that power domains do. drivers requires that this be done by individual subsystems in isolation from each other. Half the point here is that for the reusable IPs this stuff often isn't driver specific at all, it's often more about the SoC integration than it is about the driver and so you'll get a consistent pattern for most IPs on the SoC. and all of that SoC-specific detail is already hidden behind power domains, runtime PM, pinctrl, clk API, regulator framework, etc. That's all getting rather open coded, especially if you're going to get down to a situation where you have varying ordering constraints between the different APIs on different SoCs. however we need to consider those cases right ? Otherwise we will endup pushing something to mainline which will have to be reverted couple weeks later after a big rant from Linus ;-) How can you make sure that this will work for at least 50% of the drivers ? You just can't. We don't know the implementation details of every arch/soc/platform supported by Linux today to make that decision. Well, we've managed to get along for rather a long time with essentially all architectures implementing this stuff by doing static setup for the pins on boot. That does suggest we can get a reasonably long way with and this is one of the issues we're all trying to solve today so we have single zImage approach for the ARM port. I don't see the relevance of single zImage here; device tree is supposed to solve that one. DT is part of the deal. DT alone will solve nothing. something simple, and it does seem to match up with how things usually look at an electrical level too. simple ? I really doubt it. Just look at the amount of code duplication the ARM port had (still has in some places) to handle platform-specific details. What I'm saying here is that I'm concerned about us ending up with more code duplication... a fair concern. It turned out that drivers weren't very portable when they had to do platform-specific initialization, we were all abusing platform_data to pass strings and/or function pointers down to drivers and so on. I'm concerned if we hide pinctrl under e.g. power domains (as said above, it sounds like an abuse of the API to me) we will end up with a situation like above. Maybe not as bad, but still weird-looking. Well, nothing's going to stop that happening if people are determined enough - one could equally see that there'll be flags getting passed to control the ordering of calls if things are open coded. I would expect that with a power domain style approach any data would be being passed directly and bypassing the driver completely. situations like that would be a lot more rare in open coded case, don't you think ? Also a lot more local, since they will show up on a driver source code which is used in a small set of use cases, instead of being part of the pm domain implementation for the entire platform. It seems fairly obvious that if we need to add identical bolier plate code to lots of drivers we're doing something wrong, it's just churn for little practical gain and a problem if we ever decide to change how this stuff works in the future. I wouldn't consider it boilerplate if you remember that each driver might have different requirements regarding how all of those details need to be handled. Essentially all the patches I'm seeing adding pinctrl are totally mindless, most of them are just doing the initial setup on boot and not doing any active management at runtime at all. have you considered that might be just a first step ? I have mentioned this before. We first add the bare minimum and work on PM optimizations later. You can be sure most likely those mindless patches you're seeing are probably building blocks for upcoming patches adding sleep/idle modes. We have to consider power consumption, ordering of calls, proper IP setup, IP reuse on multiple platforms (even multiple ARCHes), etc etc, and to get that right outside of the driver - who's the only class that actually knows what it needs to do with its resources - will just be too complex and error-prone. A big part of my point here is that it's not at all clear to me
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Tue, Oct 30, 2012 at 05:16:42PM +0200, Felipe Balbi wrote: On Tue, Oct 30, 2012 at 02:07:15PM +, Mark Brown wrote: and all of that SoC-specific detail is already hidden behind power domains, runtime PM, pinctrl, clk API, regulator framework, etc. That's all getting rather open coded, especially if you're going to get down to a situation where you have varying ordering constraints between the different APIs on different SoCs. however we need to consider those cases right ? Otherwise we will endup pushing something to mainline which will have to be reverted couple weeks later after a big rant from Linus ;-) I'm not sure there's much risk of that either way; if anything it seems like it ought to be cleaner to have the stuff owned by the SoCs. and this is one of the issues we're all trying to solve today so we have single zImage approach for the ARM port. I don't see the relevance of single zImage here; device tree is supposed to solve that one. DT is part of the deal. DT alone will solve nothing. If DT isn't relevant I'm not sure what you're saying about single zImage? The only relevance I can see for that is the data and configuration bloating the kernel, something that DT is supposed to address - this is the main use case where DT has benefits. Well, nothing's going to stop that happening if people are determined enough - one could equally see that there'll be flags getting passed to control the ordering of calls if things are open coded. I would expect that with a power domain style approach any data would be being passed directly and bypassing the driver completely. situations like that would be a lot more rare in open coded case, don't you think ? Also a lot more local, since they will show up on a driver source code which is used in a small set of use cases, instead of being part of the pm domain implementation for the entire platform. I don't see how open coding helps prevent people doing silly things, it seems like it'd have at most neutral impact (and of course it does require going round all the drivers every time someone comes up with a new idea for doing things which is a bit tedious). Essentially all the patches I'm seeing adding pinctrl are totally mindless, most of them are just doing the initial setup on boot and not doing any active management at runtime at all. have you considered that might be just a first step ? I have mentioned this before. We first add the bare minimum and work on PM optimizations later. You can be sure most likely those mindless patches you're seeing are probably building blocks for upcoming patches adding sleep/idle modes. The sleep/idle modes are just a basic extension of the same idea, I'd not anticipate much difference there (and indeed anything where pinmux power saving makes a meaningful impact will I suspect need to be using runtime PM to allow SoC wide power savings anyway). A big part of my point here is that it's not at all clear to me that it is the driver which knows what's going on. For SoC-specific IPs you can be confident about how the SoC integration looks but for IPs that get reused widely this becomes less true. I don't think so. As long as we keep the meaning of the 'default' pinctrl state to mean that this is the working state for the IP, underlying pinctrl-$arch implementation should know how to set muxing up properly, no ? But then this comes round to the mindless code that ought to be factored out :) Only the more interesting cases that do something unusual really register here. signature.asc Description: Digital signature
Re: Problem with OHCI on OMAP4430
On Tue, 30 Oct 2012, Mohan V wrote: Device not getting detected when connected--- / # [ 135.621002] usbhs_wakeup: Enabling clocks [ 135.625762] usbhs_runtime_resume:++ [ 135.630371] usbhs_runtime_resume:-- [ 135.638183] USB IO PAD Wakeup event triggered## [ 135.644958] usbhs_runtime_suspend:++ [ 135.649749] usbhs_runtime_suspend:- It appears that ohci_irq() didn't run. Did ohci_finish_controller_resume() get called? This function is not used in ohci-omap3.c and is used only in ohci-omap.c. Is it necessary to call this function? It is necessary if the driver supports suspend/resume. As far as I can tell, the ohci-omap3 driver does not have this support (at least, not in the 3.6 kernel) whereas the ohci-omap driver does. What driver produced the usbhs_runtime_suspend and usbhs_runtime_resume messages above? (No such messages are present in ohci-omap3.c.) Apparently that driver _does_ support suspend/resume. This driver is USBHS core driver for OMAP EHCI and OHCI (drivers/mfd/omap-usb-host.c) Okay. I don't understand why the usbhs_runtime_suspend routine ever got called. Since ohci-omap3 never allows the OHCI controller to be suspended, the parent platform device should never get suspended either. What do the various files in the /sys/devices/.../ohci-omap3.0/power directory show? What about the corresponding files in the power subdirectory of the parent device? Alan Stern -- 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/12] OMAPDSS: use DSI PLL clk for DPI
Hi, The aim of this series is to enable using DSI PLL as the pixel clock source for DPI output. There are the following main parts: * first 4 patches are slightly related generic improvements/fixes * fix DSI PLL problem related to non-50% duty cycle * fix DSI PLL problem related to powering * changes to the clock handling to always use DSI PLL for DPI when possible I've tested the series on OMAP4 Panda, OMAP4 SDP and OMAP3 Beagle. Tomi Tomi Valkeinen (12): OMAPFB: remove use of extended edid block OMAPFB: improve mode selection from EDID OMAPDSS: fix DPI DSI init order OMAPDSS: fix DSI2 PLL clk names OMAPDSS: DSI: skip odd dividers when pck = 100MHz OMAPDSS: DSI: workaround for HSDiv problem OMAPDSS: add dss_calc_clock_rates() back OMAPDSS: setup default dss fck OMAPDSS: hide dss_select_dispc_clk_source() OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pll OMAPDSS: DPI: verify if DSI PLL is operational OMAPDSS: DPI: always use DSI PLL if available drivers/video/omap2/dss/core.c | 12 ++-- drivers/video/omap2/dss/dpi.c| 99 +- drivers/video/omap2/dss/dsi.c| 14 - drivers/video/omap2/dss/dss.c| 67 +++- drivers/video/omap2/dss/dss.h|2 +- drivers/video/omap2/dss/hdmi.c |8 --- drivers/video/omap2/omapfb/omapfb-main.c | 16 ++--- 7 files changed, 160 insertions(+), 58 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/12] OMAPFB: remove use of extended edid block
It seems that using the second EDID block causes more problems than is of any help. The first mode in the extended block will get FB_MODE_IS_FIRST set, which will override the first mode from the first EDID block, thus making the default videomode selection not to work properly. This patch removes the use of the extended edid block for now. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/omapfb/omapfb-main.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c index bc225e4..0358b14 100644 --- a/drivers/video/omap2/omapfb/omapfb-main.c +++ b/drivers/video/omap2/omapfb/omapfb-main.c @@ -2274,9 +2274,6 @@ static int omapfb_find_best_mode(struct omap_dss_device *display, fb_edid_to_monspecs(edid, specs); - if (edid[126] 0) - fb_edid_add_monspecs(edid + 0x80, specs); - best_xres = 0; best_idx = -1; -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 02/12] OMAPFB: improve mode selection from EDID
The current omapfb code goes over all the modes found from the monitors
EDID data, and searches for a mode that is compatible with the DSS
hardware and has the highest x-res.
While this works ok as such, it proves problematic when using DSI PLL
for pixel clock. Calculating DSI PLL dividers is not the fastest of the
operations, and while doing it for one mode is usually ok, doing it for
20 modes is noticable.
Also, the first mode given in the EDID data should be the native mode of
the monitor, and thus also the best mode, so if that can be used, no
need to look further.
This patch changes the code to use the first mode that is compatible
with the DSS hardware.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/omapfb/omapfb-main.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 0358b14..6e5334c 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2258,7 +2258,7 @@ static int omapfb_find_best_mode(struct omap_dss_device
*display,
{
struct fb_monspecs *specs;
u8 *edid;
- int r, i, best_xres, best_idx, len;
+ int r, i, best_idx, len;
if (!display-driver-read_edid)
return -ENODEV;
@@ -2274,7 +2274,6 @@ static int omapfb_find_best_mode(struct omap_dss_device
*display,
fb_edid_to_monspecs(edid, specs);
- best_xres = 0;
best_idx = -1;
for (i = 0; i specs-modedb_len; ++i) {
@@ -2290,16 +2289,20 @@ static int omapfb_find_best_mode(struct omap_dss_device
*display,
if (m-xres == 2880 || m-xres == 1440)
continue;
+ if (m-vmode FB_VMODE_INTERLACED ||
+ m-vmode FB_VMODE_DOUBLE)
+ continue;
+
fb_videomode_to_omap_timings(m, display, t);
r = display-driver-check_timings(display, t);
- if (r == 0 best_xres m-xres) {
- best_xres = m-xres;
+ if (r == 0) {
best_idx = i;
+ break;
}
}
- if (best_xres == 0) {
+ if (best_idx == -1) {
r = -ENOENT;
goto err2;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 03/12] OMAPDSS: fix DPI DSI init order
DPI may use DSI PLL, so it depends on DSI. However, currently DPI driver
is added first, which causes DPI initialization to fail when it tries to
get the DSI PLL.
This patch changes the init order to fix this.
A better solution would be to separate DSI PLL and DSI drivers. They
have dependencies, though, but we could still have DSI PLL as an
independent entity that we could initialize before any of the output
drivers.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 00aa026..d25374c 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -502,6 +502,9 @@ static int __init omap_dss_bus_register(void)
/* INIT */
static int (*dss_output_drv_reg_funcs[])(void) __initdata = {
+#ifdef CONFIG_OMAP2_DSS_DSI
+ dsi_init_platform_driver,
+#endif
#ifdef CONFIG_OMAP2_DSS_DPI
dpi_init_platform_driver,
#endif
@@ -514,15 +517,15 @@ static int (*dss_output_drv_reg_funcs[])(void) __initdata
= {
#ifdef CONFIG_OMAP2_DSS_VENC
venc_init_platform_driver,
#endif
-#ifdef CONFIG_OMAP2_DSS_DSI
- dsi_init_platform_driver,
-#endif
#ifdef CONFIG_OMAP4_DSS_HDMI
hdmi_init_platform_driver,
#endif
};
static void (*dss_output_drv_unreg_funcs[])(void) __exitdata = {
+#ifdef CONFIG_OMAP2_DSS_DSI
+ dsi_uninit_platform_driver,
+#endif
#ifdef CONFIG_OMAP2_DSS_DPI
dpi_uninit_platform_driver,
#endif
@@ -535,9 +538,6 @@ static void (*dss_output_drv_unreg_funcs[])(void)
__exitdata = {
#ifdef CONFIG_OMAP2_DSS_VENC
venc_uninit_platform_driver,
#endif
-#ifdef CONFIG_OMAP2_DSS_DSI
- dsi_uninit_platform_driver,
-#endif
#ifdef CONFIG_OMAP4_DSS_HDMI
hdmi_uninit_platform_driver,
#endif
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 04/12] OMAPDSS: fix DSI2 PLL clk names
dss_generic_clk_source_names is missing the names for clocks from DSI2
PLL. Add them.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 37ee465..a85bd05 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -97,6 +97,8 @@ static const char * const dss_generic_clk_source_names[] = {
[OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC] = DSI_PLL_HSDIV_DISPC,
[OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI]= DSI_PLL_HSDIV_DSI,
[OMAP_DSS_CLK_SRC_FCK] = DSS_FCK,
+ [OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC] = DSI_PLL2_HSDIV_DISPC,
+ [OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI] = DSI_PLL2_HSDIV_DSI,
};
static inline void dss_write_reg(const struct dss_reg idx, u32 val)
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/12] OMAPDSS: DSI: skip odd dividers when pck = 100MHz
The DSI PLL and HSDivider can be used to generate the pixel clock for LCD overlay manager, which then goes to DPI output. On the DPI output pin the voltage of the signal is shifted from the OMAP's internal minimal voltage to 1.8V range. The shifting is not instant, and the higher the clock frequency, the less time there is to shift the signal to nominal voltage. If the HSDivider's divider is greater than one and odd, the resulting pixel clock does not have 50% duty cycle. For example, with a divider of 3, the duty cycle is 33%. When combining high frequency (in the area of 140MHz+) and non-50% duty cycle, it has been observed the the shifter does not have enough time to shift the voltage enough, and this leads to bad signal which is rejected by monitors. As a workaround this patch makes the divider calculation skip all odd dividers when the required pixel clock is over 100MHz. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com --- drivers/video/omap2/dss/dsi.c |5 + 1 file changed, 5 insertions(+) diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c index 7d0db2b..d0e35da 100644 --- a/drivers/video/omap2/dss/dsi.c +++ b/drivers/video/omap2/dss/dsi.c @@ -1386,6 +1386,11 @@ retry: cur.dsi_pll_hsdiv_dispc_clk = cur.clkin4ddr / cur.regm_dispc; + if (cur.regm_dispc 1 + cur.regm_dispc % 2 != 0 + req_pck = 100) + continue; + /* this will narrow down the search a bit, * but still give pixclocks below what was * requested */ -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 06/12] OMAPDSS: DSI: workaround for HSDiv problem
It looks like on many OMAP versions powers for both HSClk and HSDiv to
be enabled to have a functional HSDiv.
This patch fixes the issue by forcing both powers on.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dsi.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index d0e35da..26d1a78 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1741,6 +1741,12 @@ int dsi_pll_init(struct platform_device *dsidev, bool
enable_hsclk,
DSSDBG(PLL init\n);
+ /*
+* It seems that on many OMAPs we need to enable both to have a
+* functional HSDivider.
+*/
+ enable_hsclk = enable_hsdiv = true;
+
if (dsi-vdds_dsi_reg == NULL) {
struct regulator *vdds_dsi;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/12] OMAPDSS: add dss_calc_clock_rates() back
dss_calc_clock_rates() was removed earlier as it was not used, but it is
needed for DSI PLL calculations, so this patch adds it back.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.c | 23 +++
drivers/video/omap2/dss/dss.h |1 +
2 files changed, 24 insertions(+)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index a85bd05..5affa86 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -432,6 +432,29 @@ enum omap_dss_clk_source dss_get_lcd_clk_source(enum
omap_channel channel)
}
}
+/* calculate clock rates using dividers in cinfo */
+int dss_calc_clock_rates(struct dss_clock_info *cinfo)
+{
+ if (dss.dpll4_m4_ck) {
+ unsigned long prate;
+
+ if (cinfo-fck_div dss.feat-fck_div_max ||
+ cinfo-fck_div == 0)
+ return -EINVAL;
+
+ prate = clk_get_rate(clk_get_parent(dss.dpll4_m4_ck));
+
+ cinfo-fck = prate / cinfo-fck_div *
+ dss.feat-dss_fck_multiplier;
+ } else {
+ if (cinfo-fck_div != 0)
+ return -EINVAL;
+ cinfo-fck = clk_get_rate(dss.dss_clk);
+ }
+
+ return 0;
+}
+
int dss_set_clock_div(struct dss_clock_info *cinfo)
{
if (dss.dpll4_m4_ck) {
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index fb89165..ae4e618 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -297,6 +297,7 @@ void dss_set_venc_output(enum omap_dss_venc_type type);
void dss_set_dac_pwrdn_bgz(bool enable);
unsigned long dss_get_dpll4_rate(void);
+int dss_calc_clock_rates(struct dss_clock_info *cinfo);
int dss_set_clock_div(struct dss_clock_info *cinfo);
int dss_calc_clock_div(unsigned long req_pck, struct dss_clock_info *dss_cinfo,
struct dispc_clock_info *dispc_cinfo);
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 08/12] OMAPDSS: setup default dss fck
We don't currently set the dss fck when starting up. This is not a
problem, as we setup the fck later when configuring the pixel clocks. Or
this is how it was for omap2, for the rest of the omaps this may not be
so.
For DSI, HDMI and also for DPI when using DSI PLL, we don't need to
change the dss fck, and thus it may be left unconfigured. Usually the
dss fck is already setup fine by default, but we can't trust this.
This patch sets the dss fck to maximum at probe time.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dss.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 5affa86..034cc1a 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -485,6 +485,36 @@ unsigned long dss_get_dpll4_rate(void)
return 0;
}
+static int dss_setup_default_clock(void)
+{
+ unsigned long max_dss_fck, prate;
+ unsigned fck_div;
+ struct dss_clock_info dss_cinfo = { 0 };
+ int r;
+
+ if (dss.dpll4_m4_ck == NULL)
+ return 0;
+
+ max_dss_fck = dss_feat_get_param_max(FEAT_PARAM_DSS_FCK);
+
+ prate = dss_get_dpll4_rate();
+
+ fck_div = DIV_ROUND_UP(prate * dss.feat-dss_fck_multiplier,
+ max_dss_fck);
+
+ dss_cinfo.fck_div = fck_div;
+
+ r = dss_calc_clock_rates(dss_cinfo);
+ if (r)
+ return r;
+
+ r = dss_set_clock_div(dss_cinfo);
+ if (r)
+ return r;
+
+ return 0;
+}
+
int dss_calc_clock_div(unsigned long req_pck, struct dss_clock_info *dss_cinfo,
struct dispc_clock_info *dispc_cinfo)
{
@@ -913,6 +943,10 @@ static int __init omap_dsshw_probe(struct platform_device
*pdev)
dss.lcd_clk_source[0] = OMAP_DSS_CLK_SRC_FCK;
dss.lcd_clk_source[1] = OMAP_DSS_CLK_SRC_FCK;
+ r = dss_setup_default_clock();
+ if (r)
+ goto err_setup_clocks;
+
rev = dss_read_reg(DSS_REVISION);
printk(KERN_INFO OMAP DSS rev %d.%d\n,
FLD_GET(rev, 7, 4), FLD_GET(rev, 3, 0));
@@ -923,6 +957,8 @@ static int __init omap_dsshw_probe(struct platform_device
*pdev)
return 0;
+err_setup_clocks:
+ dss_runtime_put();
err_runtime_get:
pm_runtime_disable(pdev-dev);
dss_put_clocks();
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/12] OMAPDSS: hide dss_select_dispc_clk_source()
dss.c currently exposes functions to configure the dispc source clock
and lcd source clock. There are configured separately from the output
drivers.
However, there is no safe way for the output drivers to handle dispc
clock, as it's shared between the outputs. Thus, if, say, the DSI driver
sets up DSI PLL and configures both the dispc and lcd clock sources to
that DSI PLL, the resulting dispc clock could be too low for, say, HDMI.
Thus the output drivers should really only be concerned about the lcd
clock, which is what the output drivers actually use. There's lot to do
to clean up the dss clock handling, but this patch takes one step
forward and removes the use of dss_select_dispc_clk_source() from the
output drivers.
After this patch, the output drivers only configure the lcd source
clock. On omap4+ the dispc src clock is never changed from the default
PRCM source. On omap3, where the dispc and lcd clocks are actually the
same, setting the lcd clock source sets the dispc clock source.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c |6 --
drivers/video/omap2/dss/dsi.c |3 ---
drivers/video/omap2/dss/dss.c |6 --
drivers/video/omap2/dss/dss.h |1 -
drivers/video/omap2/dss/hdmi.c |8
5 files changed, 8 insertions(+), 16 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 56748cf..9df62cf 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -77,6 +77,7 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
unsigned long pck_req, unsigned long *fck, int *lck_div,
int *pck_div)
{
+ struct omap_overlay_manager *mgr = dssdev-output-manager;
struct dsi_clock_info dsi_cinfo;
struct dispc_clock_info dispc_cinfo;
int r;
@@ -90,7 +91,8 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
if (r)
return r;
- dss_select_dispc_clk_source(dssdev-clocks.dispc.dispc_fclk_src);
+ dss_select_lcd_clk_source(mgr-id,
+ dssdev-clocks.dispc.channel.lcd_clk_src);
dpi.mgr_config.clock_info = dispc_cinfo;
@@ -272,7 +274,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device
*dssdev)
dss_mgr_disable(mgr);
if (dpi_use_dsi_pll(dssdev)) {
- dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
+ dss_select_lcd_clk_source(mgr-id, OMAP_DSS_CLK_SRC_FCK);
dsi_pll_uninit(dpi.dsidev, true);
dsi_runtime_put(dpi.dsidev);
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 26d1a78..70bd7a5 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -4720,7 +4720,6 @@ static int dsi_display_init_dsi(struct omap_dss_device
*dssdev)
if (r)
goto err1;
- dss_select_dispc_clk_source(dssdev-clocks.dispc.dispc_fclk_src);
dss_select_dsi_clk_source(dsi-module_id,
dssdev-clocks.dsi.dsi_fclk_src);
dss_select_lcd_clk_source(mgr-id,
dssdev-clocks.dispc.channel.lcd_clk_src);
@@ -4755,7 +4754,6 @@ static int dsi_display_init_dsi(struct omap_dss_device
*dssdev)
err3:
dsi_cio_uninit(dsidev);
err2:
- dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
dss_select_dsi_clk_source(dsi-module_id, OMAP_DSS_CLK_SRC_FCK);
dss_select_lcd_clk_source(mgr-id, OMAP_DSS_CLK_SRC_FCK);
@@ -4782,7 +4780,6 @@ static void dsi_display_uninit_dsi(struct omap_dss_device
*dssdev,
dsi_vc_enable(dsidev, 2, 0);
dsi_vc_enable(dsidev, 3, 0);
- dss_select_dispc_clk_source(OMAP_DSS_CLK_SRC_FCK);
dss_select_dsi_clk_source(dsi-module_id, OMAP_DSS_CLK_SRC_FCK);
dss_select_lcd_clk_source(mgr-id, OMAP_DSS_CLK_SRC_FCK);
dsi_cio_uninit(dsidev);
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index 034cc1a..086ed56 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -304,7 +304,7 @@ static void dss_dump_regs(struct seq_file *s)
#undef DUMPREG
}
-void dss_select_dispc_clk_source(enum omap_dss_clk_source clk_src)
+static void dss_select_dispc_clk_source(enum omap_dss_clk_source clk_src)
{
struct platform_device *dsidev;
int b;
@@ -375,8 +375,10 @@ void dss_select_lcd_clk_source(enum omap_channel channel,
struct platform_device *dsidev;
int b, ix, pos;
- if (!dss_has_feature(FEAT_LCD_CLK_SRC))
+ if (!dss_has_feature(FEAT_LCD_CLK_SRC)) {
+ dss_select_dispc_clk_source(clk_src);
return;
+ }
switch (clk_src) {
case OMAP_DSS_CLK_SRC_FCK:
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index ae4e618..e8435ea 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -284,7 +284,6 @@ void dss_sdi_init(int
[PATCH 11/12] OMAPDSS: DPI: verify if DSI PLL is operational
The SoCs that have DSI module should have a working DSI PLL. However,
some rare boards have not connected the powers to the DSI PLL.
This patch adds a function that tries to power up the DSI PLL, and
reports if that doesn't succeed. DPI uses this function to fall back to
PRCM clocks if DSI PLL doesn't work.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index fc1ec7d..267caf0 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -361,6 +361,28 @@ void omapdss_dpi_set_data_lines(struct omap_dss_device
*dssdev, int data_lines)
}
EXPORT_SYMBOL(omapdss_dpi_set_data_lines);
+static int __init dpi_verify_dsi_pll(struct platform_device *dsidev)
+{
+ int r;
+
+ /* do initial setup with the PLL to see if it is operational */
+
+ r = dsi_runtime_get(dsidev);
+ if (r)
+ return r;
+
+ r = dsi_pll_init(dsidev, 0, 1);
+ if (r) {
+ dsi_runtime_put(dsidev);
+ return r;
+ }
+
+ dsi_pll_uninit(dsidev, true);
+ dsi_runtime_put(dsidev);
+
+ return 0;
+}
+
static int __init dpi_init_display(struct omap_dss_device *dssdev)
{
DSSDBG(init_display\n);
@@ -383,6 +405,11 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
enum omap_dss_clk_source dispc_fclk_src =
dssdev-clocks.dispc.dispc_fclk_src;
dpi.dsidev = dpi_get_dsidev(dispc_fclk_src);
+
+ if (dpi_verify_dsi_pll(dpi.dsidev)) {
+ dpi.dsidev = NULL;
+ DSSWARN(DSI PLL not operational\n);
+ }
}
return 0;
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/12] OMAPDSS: DPI: use dpi.dsidev to see whether to use dsi pll
Instead of using dpi_use_dsi_pll() to check if dsi pll is to be used, we
can just check if dpi.dsidev != NULL.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 9df62cf..fc1ec7d 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -137,7 +137,7 @@ static int dpi_set_mode(struct omap_dss_device *dssdev)
unsigned long pck;
int r = 0;
- if (dpi_use_dsi_pll(dssdev))
+ if (dpi.dsidev)
r = dpi_set_dsi_clk(dssdev, t-pixel_clock * 1000, fck,
lck_div, pck_div);
else
@@ -216,7 +216,7 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
if (r)
goto err_src_sel;
- if (dpi_use_dsi_pll(dssdev)) {
+ if (dpi.dsidev) {
r = dsi_runtime_get(dpi.dsidev);
if (r)
goto err_get_dsi;
@@ -244,10 +244,10 @@ int omapdss_dpi_display_enable(struct omap_dss_device
*dssdev)
err_mgr_enable:
err_set_mode:
- if (dpi_use_dsi_pll(dssdev))
+ if (dpi.dsidev)
dsi_pll_uninit(dpi.dsidev, true);
err_dsi_pll_init:
- if (dpi_use_dsi_pll(dssdev))
+ if (dpi.dsidev)
dsi_runtime_put(dpi.dsidev);
err_get_dsi:
err_src_sel:
@@ -273,7 +273,7 @@ void omapdss_dpi_display_disable(struct omap_dss_device
*dssdev)
dss_mgr_disable(mgr);
- if (dpi_use_dsi_pll(dssdev)) {
+ if (dpi.dsidev) {
dss_select_lcd_clk_source(mgr-id, OMAP_DSS_CLK_SRC_FCK);
dsi_pll_uninit(dpi.dsidev, true);
dsi_runtime_put(dpi.dsidev);
@@ -319,7 +319,7 @@ int dpi_check_timings(struct omap_dss_device *dssdev,
if (timings-pixel_clock == 0)
return -EINVAL;
- if (dpi_use_dsi_pll(dssdev)) {
+ if (dpi.dsidev) {
struct dsi_clock_info dsi_cinfo;
r = dsi_pll_calc_clock_div_pck(dpi.dsidev,
timings-pixel_clock * 1000,
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/12] OMAPDSS: DPI: always use DSI PLL if available
We currently get the decision whether to use PRCM or DSI PLL clock for
DPI from the board file. This is not a good way to handle it, and it
won't work with device tree.
This patch changes DPI to always use DSI PLL if it's available.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/dpi.c | 64 -
1 file changed, 37 insertions(+), 27 deletions(-)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 267caf0..32e7dd5 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -49,28 +49,30 @@ static struct {
struct omap_dss_output output;
} dpi;
-static struct platform_device *dpi_get_dsidev(enum omap_dss_clk_source clk)
+static struct platform_device *dpi_get_dsidev(enum omap_channel channel)
{
- int dsi_module;
-
- dsi_module = clk == OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC ? 0 : 1;
-
- return dsi_get_dsidev_from_id(dsi_module);
+ switch (channel) {
+ case OMAP_DSS_CHANNEL_LCD:
+ return dsi_get_dsidev_from_id(0);
+ case OMAP_DSS_CHANNEL_LCD2:
+ return dsi_get_dsidev_from_id(1);
+ default:
+ return NULL;
+ }
}
-static bool dpi_use_dsi_pll(struct omap_dss_device *dssdev)
+static enum omap_dss_clk_source dpi_get_alt_clk_src(enum omap_channel channel)
{
- if (dssdev-clocks.dispc.dispc_fclk_src ==
- OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC ||
- dssdev-clocks.dispc.dispc_fclk_src ==
- OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC ||
- dssdev-clocks.dispc.channel.lcd_clk_src ==
- OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC ||
- dssdev-clocks.dispc.channel.lcd_clk_src ==
- OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC)
- return true;
- else
- return false;
+ switch (channel) {
+ case OMAP_DSS_CHANNEL_LCD:
+ return OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC;
+ case OMAP_DSS_CHANNEL_LCD2:
+ return OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC;
+ default:
+ /* this shouldn't happen */
+ WARN_ON(1);
+ return OMAP_DSS_CLK_SRC_FCK;
+ }
}
static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
@@ -92,7 +94,7 @@ static int dpi_set_dsi_clk(struct omap_dss_device *dssdev,
return r;
dss_select_lcd_clk_source(mgr-id,
- dssdev-clocks.dispc.channel.lcd_clk_src);
+ dpi_get_alt_clk_src(mgr-id));
dpi.mgr_config.clock_info = dispc_cinfo;
@@ -385,6 +387,8 @@ static int __init dpi_verify_dsi_pll(struct platform_device
*dsidev)
static int __init dpi_init_display(struct omap_dss_device *dssdev)
{
+ struct platform_device *dsidev;
+
DSSDBG(init_display\n);
if (dss_has_feature(FEAT_DPI_USES_VDDS_DSI)
@@ -401,17 +405,23 @@ static int __init dpi_init_display(struct omap_dss_device
*dssdev)
dpi.vdds_dsi_reg = vdds_dsi;
}
- if (dpi_use_dsi_pll(dssdev)) {
- enum omap_dss_clk_source dispc_fclk_src =
- dssdev-clocks.dispc.dispc_fclk_src;
- dpi.dsidev = dpi_get_dsidev(dispc_fclk_src);
+ /*
+* XXX We shouldn't need dssdev-channel for this. The dsi pll clock
+* source for DPI is SoC integration detail, not something that should
+* be configured in the dssdev
+*/
+ dsidev = dpi_get_dsidev(dssdev-channel);
- if (dpi_verify_dsi_pll(dpi.dsidev)) {
- dpi.dsidev = NULL;
- DSSWARN(DSI PLL not operational\n);
- }
+ if (dpi_verify_dsi_pll(dsidev)) {
+ dsidev = NULL;
+ DSSWARN(DSI PLL not operational\n);
}
+ if (dsidev)
+ DSSDBG(using DSI PLL for DPI clock\n);
+
+ dpi.dsidev = dsidev;
+
return 0;
}
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: move mailbox.h out of plat-omap headers
* Omar Ramirez Luna omar.l...@linaro.org [121030 05:20]: Tony, On 29 October 2012 12:52, Tony Lindgren t...@atomide.com wrote: --- /dev/null +++ b/include/linux/platform_data/omap_mailbox.h @@ -0,0 +1,105 @@ This file should only contain pure platform data needed by the core omap code to pass to the mailbox driver. Ok, looking at it closely, this header file is related to the API itself, there is nothing that could be actually considered as pure platform data, the structures are related with the mailbox framework and even if I split this file into two, the additional header would end up including the platform_data header unless I move save/restore_ctx functions and then export them as symbols for the API. So, it might be better for the entire file to sit in linux/include/mailbox/ then. OK to me. The mailbox API header should be somewhere else, like include/linux/mailbox/mailbox-omap.h or similar. Ok. But shouldn't this all now be handled by using the remoteproc framework? Remoteproc doesn't handle the mailbox hardware directly, it still relies in the mailbox framework for the low level communications. E.g.: Proc1 has a message (virtqueue msg) queued to Proc2, uses mailbox msg to generate an interrupt to Proc2, Proc2 queries the message (virtqueue) based on the mailbox message received. OK. Greg, do these patches look OK to you to move to live under drivers/mailbox? 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 baseline test results for v3.7-rc3
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]: MMC is dependent on EDMA-DMA conversion patches from Matt, which he has already submitted to the list recently. So MMC support will come along with EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it goes. This is a bogus dependency, the MMC driver needs to also work without DMA. 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 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
* Tony Lindgren t...@atomide.com [121026 11:02]: * Ohad Ben-Cohen o...@wizery.com [121026 02:56]: Hi Laurent, On Fri, Oct 26, 2012 at 11:35 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: That's on my to-do list, as well as porting the OMAP3 ISP driver to videobuf2, adding DT support, moving to the common clock framework (when that will be available for the OMAP3), supporting missing V4L2 features, ... All this in my spare time of course, otherwise it wouldn't be fun, would it ? ;-) Hmm, seems like a short to-do list ;) Sounds Laurent will take care of it :) I would also like to move the tidspbridge to the DMA API, but I think we'll need to move step by step there, and using the OMAP IOMMU and IOVMM APIs as an intermediate step would allow splitting patches in reviewable chunks. I know it's a step backwards in term of OMAP IOMMU usage, but that's in my opinion a temporary nuisance to make the leap easier. Since tidspbridge is in staging I guess it's not a problem, though it sounds to me like using the correct API in the first place is going to make less churn. Not related to these patches, but also sounds like we may need to drop some staging/tidspbridge code to be able to move forward with the ARM common zImage plans. See the [GIT PULL] omap plat header removal for v3.8 merge window, part1 thread for more info. OK so are people happy with the patches in this series? Please everybody ack if no more comments so we can move on towards getting CONFIG_MULTIPLATFORM to work for omaps. 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 0/2] ARM: OMAP: hwmod/omapd_device: Fix for resource handling in DT boot
Hi Peter, On 10/30/2012 12:24 PM, Peter Ujfalusi wrote: Hello, Changes since v1: - If the device does not have DMA resource do not try to recreate the resources Intro mail from v1: This series resolves the issue we currently have with the resource handling when booting with DT. In short: at the moment the omap_device_alloc() decides if it needs to update the OF filled resources based on the number of resources on the device and in the hwmod database. This prevents us from removing hwmod data for platforms (OMAP5) which does not support non DT boot anymore. At list removing 160 lines for out of tree data for OMAP5 audio part. So going in the good direction. But should much more after cleaning up all IP. Now we need to add DMA binding to remove the data. With this series we can make sure that the DT provided resources are used and we only append the DMA resources to the device from hwmod. I have added extra check to prepare us when the DMA resource can be filled via OF. In this case we do not update the resources at all. Tony, Benoit, Paul: Not sure if this qualify for 3.7 inclusion, but for sure going to help us to clean up the OMAP5 hwmod database. Regards, Peter --- Peter Ujfalusi (2): ARM: OMAP: hwmod: Add possibility to count hwmod resources based on type ARM: OMAP: omap_device: Correct resource handling for DT boot arch/arm/mach-omap2/omap_hwmod.c | 27 + arch/arm/plat-omap/include/plat/omap_hwmod.h | 2 +- arch/arm/plat-omap/omap_device.c | 87 ++-- 3 files changed, 72 insertions(+), 44 deletions(-) Tested-by: Sebastien Guiriec s-guir...@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: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi, On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote: and this is one of the issues we're all trying to solve today so we have single zImage approach for the ARM port. I don't see the relevance of single zImage here; device tree is supposed to solve that one. DT is part of the deal. DT alone will solve nothing. If DT isn't relevant I'm not sure what you're saying about single I didn't say DT is irrelevant. I said it's not the *only* thing. zImage? The only relevance I can see for that is the data and configuration bloating the kernel, something that DT is supposed to address - this is the main use case where DT has benefits. Well, nothing's going to stop that happening if people are determined enough - one could equally see that there'll be flags getting passed to control the ordering of calls if things are open coded. I would expect that with a power domain style approach any data would be being passed directly and bypassing the driver completely. situations like that would be a lot more rare in open coded case, don't you think ? Also a lot more local, since they will show up on a driver source code which is used in a small set of use cases, instead of being part of the pm domain implementation for the entire platform. I don't see how open coding helps prevent people doing silly things, it seems like it'd have at most neutral impact (and of course it does require going round all the drivers every time someone comes up with a new idea for doing things which is a bit tedious). Essentially all the patches I'm seeing adding pinctrl are totally mindless, most of them are just doing the initial setup on boot and not doing any active management at runtime at all. have you considered that might be just a first step ? I have mentioned this before. We first add the bare minimum and work on PM optimizations later. You can be sure most likely those mindless patches you're seeing are probably building blocks for upcoming patches adding sleep/idle modes. The sleep/idle modes are just a basic extension of the same idea, I'd not anticipate much difference there (and indeed anything where pinmux power saving makes a meaningful impact will I suspect need to be using runtime PM to allow SoC wide power savings anyway). A big part of my point here is that it's not at all clear to me that it is the driver which knows what's going on. For SoC-specific IPs you can be confident about how the SoC integration looks but for IPs that get reused widely this becomes less true. I don't think so. As long as we keep the meaning of the 'default' pinctrl state to mean that this is the working state for the IP, underlying pinctrl-$arch implementation should know how to set muxing up properly, no ? But then this comes round to the mindless code that ought to be factored out :) Only the more interesting cases that do something unusual really register here. fair enough. I see your point. Not saying I agree though, just that this discussion has been flying for far too long, so feel free to provide patches implementing what you're defending here ;-) Guess code will speak for itself. On way or another, we need OMAP keypad driver working in mainline and I don't think your arguments are strong enough to keep $SUBJECT from being merged, unless you can provide something stable/tested for v3.8 merge window. -- balbi signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc3
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
already submitted to the list recently. So MMC support will come along
with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it
goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
1869 host-rx_chan = dma_request_channel(mask, omap_dma_filter_fn,
rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX DMA
engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask, omap_dma_filter_fn,
tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX DMA
engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
--
balbi
signature.asc
Description: Digital signature
Re: OMAP baseline test results for v3.7-rc3
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which he has
already submitted to the list recently. So MMC support will come along
with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it
goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask, omap_dma_filter_fn,
rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX DMA
engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask, omap_dma_filter_fn,
tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX DMA
engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
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
[PATCH] w1-gpio: Simplify get rid of defines
There's no reason to have the OF defines; it complicates the driver.
There's also no need for the funky platform_driver_probe.
Add a few warnings in case there's a failure; helps us find out
what went wrong.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/w1/masters/w1-gpio.c | 58
1 file changed, 26 insertions(+), 32 deletions(-)
diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index aec35bd..85b363a 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -18,6 +18,7 @@
#include linux/of_gpio.h
#include linux/pinctrl/consumer.h
#include linux/err.h
+#include linux/of.h
#include ../w1.h
#include ../w1_int.h
@@ -46,7 +47,6 @@ static u8 w1_gpio_read_bit(void *data)
return gpio_get_value(pdata-pin) ? 1 : 0;
}
-#ifdef CONFIG_OF
static struct of_device_id w1_gpio_dt_ids[] = {
{ .compatible = w1-gpio },
{}
@@ -57,11 +57,6 @@ static int w1_gpio_probe_dt(struct platform_device *pdev)
{
struct w1_gpio_platform_data *pdata = pdev-dev.platform_data;
struct device_node *np = pdev-dev.of_node;
- const struct of_device_id *of_id =
- of_match_device(w1_gpio_dt_ids, pdev-dev);
-
- if (!of_id)
- return 0;
pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
if (!pdata)
@@ -76,12 +71,6 @@ static int w1_gpio_probe_dt(struct platform_device *pdev)
return 0;
}
-#else
-static int w1_gpio_probe_dt(struct platform_device *pdev)
-{
- return 0;
-}
-#endif
static int __init w1_gpio_probe(struct platform_device *pdev)
{
@@ -94,28 +83,41 @@ static int __init w1_gpio_probe(struct platform_device
*pdev)
if (IS_ERR(pinctrl))
dev_warn(pdev-dev, unable to select pin group\n);
- err = w1_gpio_probe_dt(pdev);
- if (err 0)
- return err;
+ if (of_have_populated_dt()) {
+ err = w1_gpio_probe_dt(pdev);
+ if (err 0) {
+ dev_err(pdev-dev, Failed to parse DT\n);
+ return err;
+ }
+ }
pdata = pdev-dev.platform_data;
- if (!pdata)
+ if (!pdata) {
+ dev_err(pdev-dev, No configuration data\n);
return -ENXIO;
+ }
master = kzalloc(sizeof(struct w1_bus_master), GFP_KERNEL);
- if (!master)
+ if (!master) {
+ dev_err(pdev-dev, Out of memory\n);
return -ENOMEM;
+ }
err = gpio_request(pdata-pin, w1);
- if (err)
+ if (err) {
+ dev_err(pdev-dev, gpio_request (pin) failed\n);
goto free_master;
+ }
if (gpio_is_valid(pdata-ext_pullup_enable_pin)) {
err = gpio_request_one(pdata-ext_pullup_enable_pin,
GPIOF_INIT_LOW, w1 pullup);
- if (err 0)
+ if (err 0) {
+ dev_err(pdev-dev, gpio_request_one
+ (ext_pullup_enable_pin) failed\n);
goto free_gpio;
+ }
}
master-data = pdata;
@@ -130,8 +132,10 @@ static int __init w1_gpio_probe(struct platform_device
*pdev)
}
err = w1_add_master_device(master);
- if (err)
+ if (err) {
+ dev_err(pdev-dev, w1_add_master device failed\n);
goto free_gpio_ext_pu;
+ }
if (pdata-enable_external_pullup)
pdata-enable_external_pullup(1);
@@ -205,23 +209,13 @@ static struct platform_driver w1_gpio_driver = {
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(w1_gpio_dt_ids),
},
+ .probe = w1_gpio_probe,
.remove = __exit_p(w1_gpio_remove),
.suspend = w1_gpio_suspend,
.resume = w1_gpio_resume,
};
-static int __init w1_gpio_init(void)
-{
- return platform_driver_probe(w1_gpio_driver, w1_gpio_probe);
-}
-
-static void __exit w1_gpio_exit(void)
-{
- platform_driver_unregister(w1_gpio_driver);
-}
-
-module_init(w1_gpio_init);
-module_exit(w1_gpio_exit);
+module_platform_driver(w1_gpio_driver);
MODULE_DESCRIPTION(GPIO w1 bus master driver);
MODULE_AUTHOR(Ville Syrjala syrj...@sci.fi);
--
1.7.12
--
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] i2c-EEPROM: Export memory accessor
Various platforms need access to the EEPROM in other
places besides their platform registration callbacks.
Export the memory accessor to the i2c_client and implement
it for the at24 driver.
And before you ask, no, the platform callback can't be used
for anything that depends on DT.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/misc/eeprom/at24.c | 5 +
include/linux/i2c.h| 24
2 files changed, 29 insertions(+)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index ab1ad41..4f88ae65 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -609,6 +609,9 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
at24-client[0] = client;
+ /* export accessor */
+ client-macc = at24-macc;
+
/* use dummy devices for multiple-address chips */
for (i = 1; i num_addresses; i++) {
at24-client[i] = i2c_new_dummy(client-adapter,
@@ -619,6 +622,7 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
err = -EADDRINUSE;
goto err_clients;
}
+ at24-client[i]-macc = at24-macc;
}
err = sysfs_create_bin_file(client-dev.kobj, at24-bin);
@@ -637,6 +641,7 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
I2C_SMBUS_WORD_DATA ? word : byte);
}
+
/* export data to kernel code */
if (chip.setup)
chip.setup(at24-macc, chip.context);
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 800de22..e20ad4e 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -33,6 +33,7 @@
#include linux/of.h /* for struct device_node */
#include linux/swab.h/* for swab16 */
#include uapi/linux/i2c.h
+#include linux/memory.h
extern struct bus_type i2c_bus_type;
extern struct device_type i2c_adapter_type;
@@ -229,9 +230,32 @@ struct i2c_client {
struct device dev; /* the device structure */
int irq;/* irq issued by device */
struct list_head detected;
+
+ /* export accessor */
+ struct memory_accessor *macc;
};
#define to_i2c_client(d) container_of(d, struct i2c_client, dev)
+static inline ssize_t i2c_memory_read(struct i2c_client *client, char *buf,
off_t offset,
+ size_t count)
+{
+ struct memory_accessor *macc = client-macc;
+
+ if (macc == NULL || macc-read == NULL)
+ return -ENODEV;
+ return (*client-macc-read)(macc, buf, offset, count);
+}
+
+static inline ssize_t i2c_memory_write(struct i2c_client *client, const char
*buf, off_t offset,
+ size_t count)
+{
+ struct memory_accessor *macc = client-macc;
+
+ if (macc == NULL || macc-write == NULL)
+ return -ENODEV;
+ return (*client-macc-write)(macc, buf, offset, count);
+}
+
extern struct i2c_client *i2c_verify_client(struct device *dev);
extern struct i2c_adapter *i2c_verify_adapter(struct device *dev);
--
1.7.12
--
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] ti_tscadc: Match mfd sub devices to regmap interface
The MFD parent device now uses a regmap, instead of direct
memory access. Use the same method in the sub devices to avoid
nasty surprises.
Also rework the channel initialization of tiadc a bit.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/iio/adc/ti_am335x_adc.c | 27 +++
drivers/input/touchscreen/ti_am335x_tsc.c | 16 +---
drivers/mfd/ti_am335x_tscadc.c| 7 +--
3 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index d48fd79..5f325c1 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -23,7 +23,9 @@
#include linux/iio/iio.h
#include linux/iio/machine.h
#include linux/iio/driver.h
+#include linux/regmap.h
+#include linux/io.h
#include linux/mfd/ti_am335x_tscadc.h
#include linux/platform_data/ti_am335x_adc.h
@@ -36,13 +38,17 @@ struct tiadc_device {
static unsigned int tiadc_readl(struct tiadc_device *adc, unsigned int reg)
{
- return readl(adc-mfd_tscadc-tscadc_base + reg);
+ unsigned int val;
+
+ val = (unsigned int)-1;
+ regmap_read(adc-mfd_tscadc-regmap_tscadc, reg, val);
+ return val;
}
static void tiadc_writel(struct tiadc_device *adc, unsigned int reg,
unsigned int val)
{
- writel(val, adc-mfd_tscadc-tscadc_base + reg);
+ regmap_write(adc-mfd_tscadc-regmap_tscadc, reg, val);
}
static void tiadc_step_config(struct tiadc_device *adc_dev)
@@ -75,22 +81,24 @@ static void tiadc_step_config(struct tiadc_device *adc_dev)
tiadc_writel(adc_dev, REG_SE, STPENB_STEPENB);
}
-static int tiadc_channel_init(struct iio_dev *indio_dev, int channels)
+static int tiadc_channel_init(struct iio_dev *indio_dev,
+ struct tiadc_device *adc_dev)
{
struct iio_chan_spec *chan_array;
struct iio_chan_spec *chan;
char *s;
int i, len, size, ret;
+ int channels = adc_dev-channels;
- size = indio_dev-num_channels * (sizeof(struct iio_chan_spec) + 6);
+ size = channels * (sizeof(struct iio_chan_spec) + 6);
chan_array = kzalloc(size, GFP_KERNEL);
if (chan_array == NULL)
return -ENOMEM;
/* buffer space is after the array */
- s = (char *)(chan_array + indio_dev-num_channels);
+ s = (char *)(chan_array + channels);
chan = chan_array;
- for (i = 0; i indio_dev-num_channels; i++, chan++, s += len + 1) {
+ for (i = 0; i channels; i++, chan++, s += len + 1) {
len = sprintf(s, AIN%d, i);
@@ -105,8 +113,9 @@ static int tiadc_channel_init(struct iio_dev *indio_dev,
int channels)
}
indio_dev-channels = chan_array;
+ indio_dev-num_channels = channels;
- size = (indio_dev-num_channels + 1) * sizeof(struct iio_map);
+ size = (channels + 1) * sizeof(struct iio_map);
adc_dev-map = kzalloc(size, GFP_KERNEL);
if (adc_dev-map == NULL) {
kfree(chan_array);
@@ -203,7 +212,7 @@ static int __devinit tiadc_probe(struct platform_device
*pdev)
tiadc_step_config(adc_dev);
- err = tiadc_channel_init(indio_dev, adc_dev-channels);
+ err = tiadc_channel_init(indio_dev, adc_dev);
if (err 0)
goto err_free_device;
@@ -213,6 +222,8 @@ static int __devinit tiadc_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, indio_dev);
+ dev_info(pdev-dev, Initialized\n);
+
return 0;
err_free_channels:
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 7a26810..d09e1a7 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -26,6 +26,7 @@
#include linux/io.h
#include linux/input/ti_am335x_tsc.h
#include linux/delay.h
+#include linux/regmap.h
#include linux/mfd/ti_am335x_tscadc.h
@@ -64,13 +65,17 @@ struct titsc {
static unsigned int titsc_readl(struct titsc *ts, unsigned int reg)
{
- return readl(ts-mfd_tscadc-tscadc_base + reg);
+ unsigned int val;
+
+ val = (unsigned int)-1;
+ regmap_read(ts-mfd_tscadc-regmap_tscadc, reg, val);
+ return val;
}
static void titsc_writel(struct titsc *tsc, unsigned int reg,
unsigned int val)
{
- writel(val, tsc-mfd_tscadc-tscadc_base + reg);
+ regmap_write(tsc-mfd_tscadc-regmap_tscadc, reg, val);
}
/*
@@ -455,10 +460,15 @@ static int __devinit titsc_probe(struct platform_device
*pdev)
/* register to the input system */
err = input_register_device(input_dev);
- if (err)
+ if (err) {
+ dev_err(pdev-dev, Failed to register input device\n);
goto err_free_irq;
+ }
platform_set_drvdata(pdev, ts_dev);
+
+ dev_info(pdev-dev,
[PATCH] da8xx: Fix revision check on the da8xx driver
The revision check fails for the beaglebone; Add new revision ID. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/video/da8xx-fb.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c index 80665f6..866d804 100644 --- a/drivers/video/da8xx-fb.c +++ b/drivers/video/da8xx-fb.c @@ -1283,6 +1283,7 @@ static int __devinit fb_probe(struct platform_device *device) lcd_revision = LCD_VERSION_1; break; case 0x4F200800: + case 0x4F201000: lcd_revision = LCD_VERSION_2; break; default: -- 1.7.12 -- 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] pwm-backlight: Pinctrl-fy
Enable pinctrl for pwm-backlight.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/video/backlight/pwm_bl.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 0c91023..f3b6194 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -20,6 +20,8 @@
#include linux/pwm.h
#include linux/pwm_backlight.h
#include linux/slab.h
+#include linux/pinctrl/consumer.h
+#include linux/err.h
struct pwm_bl_data {
struct pwm_device *pwm;
@@ -180,9 +182,14 @@ static int pwm_backlight_probe(struct platform_device
*pdev)
struct backlight_properties props;
struct backlight_device *bl;
struct pwm_bl_data *pb;
+ struct pinctrl *pinctrl;
unsigned int max;
int ret;
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev, unable to select pin group\n);
+
if (!data) {
ret = pwm_backlight_parse_dt(pdev-dev, defdata);
if (ret 0) {
--
1.7.12
--
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] da8xx: De-constify members in the platform config.
There's no need for this to be const. It interferes with
creating the platform data dynamically.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
include/video/da8xx-fb.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/video/da8xx-fb.h b/include/video/da8xx-fb.h
index 5a0e4f9..a512d6b 100644
--- a/include/video/da8xx-fb.h
+++ b/include/video/da8xx-fb.h
@@ -35,9 +35,9 @@ struct display_panel {
};
struct da8xx_lcdc_platform_data {
- const char manu_name[10];
+ char manu_name[10];
void *controller_data;
- const char type[25];
+ char type[25];
void (*panel_power_ctrl)(int);
};
--
1.7.12
--
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] da8xx: Add CDTech_S035Q01 panel (used by LCD3 bone cape)
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/video/da8xx-fb.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index c661665..c1f5d30 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -298,6 +298,20 @@ static struct da8xx_panel known_lcd_panels[] = {
.pxl_clk = 3000,
.invert_pxl_clk = 0,
},
+ [5] = {
+ /* CDTech S035Q01 */
+ .name = CDTech_S035Q01,
+ .width = 320,
+ .height = 240,
+ .hfp = 58,
+ .hbp = 21,
+ .hsw = 47,
+ .vfp = 23,
+ .vbp = 11,
+ .vsw = 2,
+ .pxl_clk = 800,
+ .invert_pxl_clk = 0,
+ },
};
/* Enable the Raster Engine of the LCD Controller */
--
1.7.12
--
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] da8xx: Allow use by am33xx based devices
This driver can be used for AM33xx devices, like the popular beaglebone. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/video/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig index 9791d10..e7868d8 100644 --- a/drivers/video/Kconfig +++ b/drivers/video/Kconfig @@ -2202,7 +2202,7 @@ config FB_SH7760 config FB_DA8XX tristate DA8xx/OMAP-L1xx Framebuffer support - depends on FB ARCH_DAVINCI_DA8XX + depends on FB (ARCH_DAVINCI_DA8XX || SOC_AM33XX) select FB_CFB_FILLRECT select FB_CFB_COPYAREA select FB_CFB_IMAGEBLIT -- 1.7.12 -- 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] tps65217: Allow placement elsewhere than parent mfd device
The current code expect the configuration of the backlight to stay
constant after initialization. This patch allows to move it around.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/video/backlight/tps65217_bl.c | 103 ++
1 file changed, 92 insertions(+), 11 deletions(-)
diff --git a/drivers/video/backlight/tps65217_bl.c
b/drivers/video/backlight/tps65217_bl.c
index 7088163..69c1dfe 100644
--- a/drivers/video/backlight/tps65217_bl.c
+++ b/drivers/video/backlight/tps65217_bl.c
@@ -24,8 +24,11 @@
#include linux/module.h
#include linux/platform_device.h
#include linux/slab.h
+#include linux/i2c.h
+#include linux/of_i2c.h
struct tps65217_bl {
+ struct i2c_client *i2c_client;
struct tps65217 *tps;
struct device *dev;
struct backlight_device *bl;
@@ -98,8 +101,6 @@ static int tps65217_bl_update_status(struct backlight_device
*bl)
return rc;
}
- dev_dbg(tps65217_bl-dev, brightness set to %d\n, brightness);
-
if (!tps65217_bl-is_enabled)
rc = tps65217_bl_enable(tps65217_bl);
} else {
@@ -187,14 +188,69 @@ static int tps65217_bl_hw_init(struct tps65217_bl
*tps65217_bl,
#ifdef CONFIG_OF
static struct tps65217_bl_pdata *
-tps65217_bl_parse_dt(struct platform_device *pdev)
+tps65217_bl_parse_dt(struct platform_device *pdev, struct tps65217 **tpsp,
+ int *brightnessp)
{
- struct tps65217 *tps = dev_get_drvdata(pdev-dev.parent);
- struct device_node *node = of_node_get(tps-dev-of_node);
+ struct i2c_client *i2c_client;
+ struct tps65217 *tps;
+ struct device_node *node, *rnode, *pnode;
struct tps65217_bl_pdata *pdata, *err;
+ u32 tps_handle;
u32 val;
- node = of_find_node_by_name(node, backlight);
+ tps = NULL;
+ node = NULL;
+ *brightnessp = 0;
+
+ /* our node (compatible) */
+ pnode = pdev-dev.of_node;
+ if (pnode != NULL
+ of_property_read_u32(pnode, tps, tps_handle) == 0) {
+ /* we are not instantiated from the mfd */
+ node = of_find_node_by_phandle(tps_handle);
+ if (node == NULL) {
+ dev_err(pdev-dev, failed to find the tps node\n);
+ err = ERR_PTR(-EINVAL);
+ goto err;
+ }
+ i2c_client = of_find_i2c_device_by_node(node);
+ if (i2c_client == NULL) {
+ dev_err(pdev-dev, failed to find the i2c device
+ of tps node\n);
+ err = ERR_PTR(-EINVAL);
+ goto err;
+ }
+ /* yeah this is gross; the whole concept is */
+ tps = i2c_get_clientdata(i2c_client);
+ if (tps == NULL) {
+ dev_err(pdev-dev, failed to get tps structure\n);
+ err = ERR_PTR(-EINVAL);
+ goto err;
+ }
+
+ /* read default brightness */
+ val = 0;
+ of_property_read_u32(pnode, brightness, val);
+ if (val = 100)
+ val = 100;
+
+ *brightnessp = val;
+
+ /* no need for this anymore */
+ of_node_put(node);
+
+ dev_info(pdev-dev, got tps=%p from handle 0x%x\n, tps,
tps_handle);
+ }
+
+ if (tps == NULL)
+ tps = dev_get_drvdata(pdev-dev.parent);
+
+ rnode = of_node_get(tps-dev-of_node);
+
+ node = of_find_node_by_name(rnode, backlight);
+ of_node_put(rnode);
+ rnode = NULL;
+
if (!node)
return ERR_PTR(-ENODEV);
@@ -247,6 +303,7 @@ tps65217_bl_parse_dt(struct platform_device *pdev)
of_node_put(node);
+ *tpsp = tps;
return pdata;
err:
@@ -254,9 +311,16 @@ err:
return err;
}
+
+static struct of_device_id tps65217_backlight_of_match[] = {
+ { .compatible = tps65217-backlight },
+ { }
+};
+MODULE_DEVICE_TABLE(of, tps65217_backlight_of_match);
#else
static struct tps65217_bl_pdata *
-tps65217_bl_parse_dt(struct platform_device *pdev)
+tps65217_bl_parse_dt(struct platform_device *pdev, struct tps65217 **tpsp,
+ int *brightnessp)
{
return NULL;
}
@@ -265,13 +329,16 @@ tps65217_bl_parse_dt(struct platform_device *pdev)
static int tps65217_bl_probe(struct platform_device *pdev)
{
int rc;
- struct tps65217 *tps = dev_get_drvdata(pdev-dev.parent);
+ struct tps65217 *tps;
struct tps65217_bl *tps65217_bl;
struct tps65217_bl_pdata *pdata;
struct backlight_properties bl_props;
+ int brightness = 0;
- if (tps-dev-of_node) {
- pdata = tps65217_bl_parse_dt(pdev);
+ tps = NULL;
+
+ if (pdev-dev.of_node)
[PATCH] arm-dt: Enable DT proc updates.
This simple patch enables dynamic changes of the DT tree on runtime to be visible to the device-tree proc interface. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- arch/arm/include/asm/prom.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/include/asm/prom.h b/arch/arm/include/asm/prom.h index aeae9c6..6d65ba2 100644 --- a/arch/arm/include/asm/prom.h +++ b/arch/arm/include/asm/prom.h @@ -11,6 +11,8 @@ #ifndef __ASMARM_PROM_H #define __ASMARM_PROM_H +#define HAVE_ARCH_DEVTREE_FIXUPS + #ifdef CONFIG_OF extern struct machine_desc *setup_machine_fdt(unsigned int dt_phys); -- 1.7.12 -- 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] w1-gpio: Pinctrl-fy
Enable pinctrl for w1-gpio.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/w1/masters/w1-gpio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index 6012c4e..aec35bd 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -16,6 +16,8 @@
#include linux/gpio.h
#include linux/of_platform.h
#include linux/of_gpio.h
+#include linux/pinctrl/consumer.h
+#include linux/err.h
#include ../w1.h
#include ../w1_int.h
@@ -85,8 +87,13 @@ static int __init w1_gpio_probe(struct platform_device *pdev)
{
struct w1_bus_master *master;
struct w1_gpio_platform_data *pdata;
+ struct pinctrl *pinctrl;
int err;
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev, unable to select pin group\n);
+
err = w1_gpio_probe_dt(pdev);
if (err 0)
return err;
--
1.7.12
--
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] i2c: Export capability to probe devices
Probe devices for a node other that the adapter node.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/of/of_i2c.c| 14 ++
include/linux/of_i2c.h | 3 +++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/of/of_i2c.c b/drivers/of/of_i2c.c
index 3550f3b..7f36b05 100644
--- a/drivers/of/of_i2c.c
+++ b/drivers/of/of_i2c.c
@@ -18,18 +18,18 @@
#include linux/of_irq.h
#include linux/module.h
-void of_i2c_register_devices(struct i2c_adapter *adap)
+void of_i2c_register_node_devices(struct i2c_adapter *adap,
+ struct device_node *parent_node)
{
void *result;
struct device_node *node;
- /* Only register child devices if the adapter has a node pointer set */
- if (!adap-dev.of_node)
+ if (!parent_node)
return;
dev_dbg(adap-dev, of_i2c: walking child nodes\n);
- for_each_child_of_node(adap-dev.of_node, node) {
+ for_each_child_of_node(parent_node, node) {
struct i2c_board_info info = {};
struct dev_archdata dev_ad = {};
const __be32 *addr;
@@ -76,6 +76,12 @@ void of_i2c_register_devices(struct i2c_adapter *adap)
}
}
}
+EXPORT_SYMBOL(of_i2c_register_node_devices);
+
+void of_i2c_register_devices(struct i2c_adapter *adap)
+{
+ of_i2c_register_node_devices(adap, adap-dev.of_node);
+}
EXPORT_SYMBOL(of_i2c_register_devices);
static int of_dev_node_match(struct device *dev, void *data)
diff --git a/include/linux/of_i2c.h b/include/linux/of_i2c.h
index 1cb775f..d2f8ebb6 100644
--- a/include/linux/of_i2c.h
+++ b/include/linux/of_i2c.h
@@ -15,6 +15,9 @@
#if defined(CONFIG_OF_I2C) || defined(CONFIG_OF_I2C_MODULE)
#include linux/i2c.h
+extern void of_i2c_register_node_devices(struct i2c_adapter *adap,
+ struct device_node *parent_node);
+
extern void of_i2c_register_devices(struct i2c_adapter *adap);
/* must call put_device() when done with returned i2c_client device */
--
1.7.12
--
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] pwm: export of_pwm_request
No need to hide of_pwm_request, it's useful to other in-kernel users.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/pwm/core.c | 6 +-
include/linux/pwm.h | 7 +++
2 files changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index f5acdaa..f8c7e6b 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -457,7 +457,7 @@ static struct pwm_chip *of_node_to_pwmchip(struct
device_node *np)
* becomes mandatory for devices that look up the PWM device via the con_id
* parameter.
*/
-static struct pwm_device *of_pwm_request(struct device_node *np,
+struct pwm_device *of_pwm_request(struct device_node *np,
const char *con_id)
{
struct pwm_device *pwm = NULL;
@@ -466,6 +466,9 @@ static struct pwm_device *of_pwm_request(struct device_node
*np,
int index = 0;
int err;
+ if (!np)
+ return ERR_PTR(-ENODEV);
+
if (con_id) {
index = of_property_match_string(np, pwm-names, con_id);
if (index 0)
@@ -516,6 +519,7 @@ put:
return pwm;
}
+EXPORT_SYMBOL(of_pwm_request);
/**
* pwm_add_table() - register PWM device consumers
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 112b314..fafbb1c 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -171,6 +171,7 @@ struct pwm_device *pwm_request_from_chip(struct pwm_chip
*chip,
unsigned int index,
const char *label);
+struct pwm_device *of_pwm_request(struct device_node *np, const char
*consumer);
struct pwm_device *pwm_get(struct device *dev, const char *consumer);
void pwm_put(struct pwm_device *pwm);
@@ -204,6 +205,12 @@ static inline struct pwm_device
*pwm_request_from_chip(struct pwm_chip *chip,
return ERR_PTR(-ENODEV);
}
+static inline struct pwm_device *of_pwm_request(struct device_node *np,
+const char *consumer)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline struct pwm_device *pwm_get(struct device *dev,
const char *consumer)
{
--
1.7.12
--
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] spi: Export OF interfaces.
Export an interface that other in-kernel users can utilize.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/spi/spi.c | 31 +++
include/linux/spi/spi.h | 18 ++
2 files changed, 41 insertions(+), 8 deletions(-)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 84c2861..f8de2f2 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -801,14 +801,17 @@ err_init_queue:
/*-*/
#if defined(CONFIG_OF) !defined(CONFIG_SPARC)
+
/**
- * of_register_spi_devices() - Register child devices onto the SPI bus
+ * of_register_node_spi_devices() - Register child devices onto the SPI bus
* @master:Pointer to spi_master device
+ * @parent_node: Pointer to the device node containg the devices
*
* Registers an spi_device for each child node of master node which has a 'reg'
* property.
*/
-static void of_register_spi_devices(struct spi_master *master)
+void of_register_node_spi_devices(struct spi_master *master,
+ struct device_node *parent_node)
{
struct spi_device *spi;
struct device_node *nc;
@@ -816,10 +819,10 @@ static void of_register_spi_devices(struct spi_master
*master)
int rc;
int len;
- if (!master-dev.of_node)
+ if (!parent_node)
return;
- for_each_child_of_node(master-dev.of_node, nc) {
+ for_each_child_of_node(parent_node, nc) {
/* Alloc an spi_device */
spi = spi_alloc_device(master);
if (!spi) {
@@ -884,8 +887,20 @@ static void of_register_spi_devices(struct spi_master
*master)
}
}
-#else
-static void of_register_spi_devices(struct spi_master *master) { }
+EXPORT_SYMBOL_GPL(of_register_node_spi_devices);
+
+/**
+ * of_register_spi_devices() - Register child devices onto the SPI bus
+ * @master:Pointer to spi_master device
+ *
+ * Registers an spi_device for each child node of master node which has a 'reg'
+ * property.
+ */
+void of_register_spi_devices(struct spi_master *master)
+{
+ of_register_node_spi_devices(master, master-dev.of_node);
+}
+EXPORT_SYMBOL_GPL(of_register_spi_devices);
#endif
static void spi_master_release(struct device *dev)
@@ -896,12 +911,12 @@ static void spi_master_release(struct device *dev)
kfree(master);
}
-static struct class spi_master_class = {
+struct class spi_master_class = {
.name = spi_master,
.owner = THIS_MODULE,
.dev_release= spi_master_release,
};
-
+EXPORT_SYMBOL_GPL(spi_master_class);
/**
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index fa702ae..618aa5e 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -30,6 +30,8 @@
*/
extern struct bus_type spi_bus_type;
+extern struct class spi_master_class;
+
/**
* struct spi_device - Master side proxy for an SPI slave device
* @dev: Driver model representation of the device.
@@ -856,4 +858,20 @@ spi_unregister_device(struct spi_device *spi)
extern const struct spi_device_id *
spi_get_device_id(const struct spi_device *sdev);
+#if defined(CONFIG_OF) !defined(CONFIG_SPARC)
+
+void of_register_node_spi_devices(struct spi_master *master,
+ struct device_node *parent_node);
+
+void of_register_spi_devices(struct spi_master *master);
+
+#else
+
+static inline void of_register_node_spi_devices(struct spi_master *master,
+ struct device_node *parent_node) { }
+
+static inline void of_register_spi_devices(struct spi_master *master) { }
+
+#endif
+
#endif /* __LINUX_SPI_H */
--
1.7.12
--
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] ti_tscadc: Update with IIO map interface deal with partial activation
Add an IIO map interface that consumers can use.
Also make sure the mfd device doesn't activate a driver which
the configuration doesn't require.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/iio/adc/ti_am335x_adc.c | 53 ++--
drivers/mfd/ti_am335x_tscadc.c | 30 ++--
include/linux/mfd/ti_am335x_tscadc.h | 8 ++
3 files changed, 68 insertions(+), 23 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 02a43c8..d48fd79 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -20,8 +20,9 @@
#include linux/slab.h
#include linux/interrupt.h
#include linux/platform_device.h
-#include linux/io.h
#include linux/iio/iio.h
+#include linux/iio/machine.h
+#include linux/iio/driver.h
#include linux/mfd/ti_am335x_tscadc.h
#include linux/platform_data/ti_am335x_adc.h
@@ -29,6 +30,8 @@
struct tiadc_device {
struct ti_tscadc_dev *mfd_tscadc;
int channels;
+ char *buf;
+ struct iio_map *map;
};
static unsigned int tiadc_readl(struct tiadc_device *adc, unsigned int reg)
@@ -75,25 +78,57 @@ static void tiadc_step_config(struct tiadc_device *adc_dev)
static int tiadc_channel_init(struct iio_dev *indio_dev, int channels)
{
struct iio_chan_spec *chan_array;
- int i;
-
- indio_dev-num_channels = channels;
- chan_array = kcalloc(indio_dev-num_channels,
- sizeof(struct iio_chan_spec), GFP_KERNEL);
+ struct iio_chan_spec *chan;
+ char *s;
+ int i, len, size, ret;
+ size = indio_dev-num_channels * (sizeof(struct iio_chan_spec) + 6);
+ chan_array = kzalloc(size, GFP_KERNEL);
if (chan_array == NULL)
return -ENOMEM;
- for (i = 0; i (indio_dev-num_channels); i++) {
- struct iio_chan_spec *chan = chan_array + i;
+ /* buffer space is after the array */
+ s = (char *)(chan_array + indio_dev-num_channels);
+ chan = chan_array;
+ for (i = 0; i indio_dev-num_channels; i++, chan++, s += len + 1) {
+
+ len = sprintf(s, AIN%d, i);
+
chan-type = IIO_VOLTAGE;
chan-indexed = 1;
chan-channel = i;
- chan-info_mask = IIO_CHAN_INFO_RAW_SEPARATE_BIT;
+ chan-datasheet_name = s;
+ chan-scan_type.sign = 'u';
+ chan-scan_type.realbits = 12;
+ chan-scan_type.storagebits = 32;
+ chan-scan_type.shift = 0;
}
indio_dev-channels = chan_array;
+ size = (indio_dev-num_channels + 1) * sizeof(struct iio_map);
+ adc_dev-map = kzalloc(size, GFP_KERNEL);
+ if (adc_dev-map == NULL) {
+ kfree(chan_array);
+ return -ENOMEM;
+ }
+
+ for (i = 0; i indio_dev-num_channels; i++) {
+ adc_dev-map[i].adc_channel_label =
chan_array[i].datasheet_name;
+ adc_dev-map[i].consumer_dev_name = any;
+ adc_dev-map[i].consumer_channel = chan_array[i].datasheet_name;
+ }
+ adc_dev-map[i].adc_channel_label = NULL;
+ adc_dev-map[i].consumer_dev_name = NULL;
+ adc_dev-map[i].consumer_channel = NULL;
+
+ ret = iio_map_array_register(indio_dev, adc_dev-map);
+ if (ret != 0) {
+ kfree(adc_dev-map);
+ kfree(chan_array);
+ return -ENOMEM;
+ }
+
return indio_dev-num_channels;
}
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index e947dd8..cbb8b70c 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -176,26 +176,38 @@ staticint __devinit ti_tscadc_probe(struct
platform_device *pdev)
ctrl |= CNTRLREG_TSCSSENB;
tscadc_writel(tscadc, REG_CTRL, ctrl);
+ tscadc-used_cells = 0;
+ tscadc-tsc_cell = -1;
+ tscadc-adc_cell = -1;
+
/* TSC Cell */
- cell = tscadc-cells[TSC_CELL];
- cell-name = tsc;
- cell-platform_data = tscadc;
- cell-pdata_size = sizeof(*tscadc);
+ if (tsc_wires 0) {
+ tscadc-tsc_cell = tscadc-used_cells;
+ cell = tscadc-cells[tscadc-used_cells++];
+ cell-name = tsc;
+ cell-platform_data = tscadc;
+ cell-pdata_size = sizeof(*tscadc);
+ }
/* ADC Cell */
- cell = tscadc-cells[ADC_CELL];
- cell-name = tiadc;
- cell-platform_data = tscadc;
- cell-pdata_size = sizeof(*tscadc);
+ if (adc_channels 0) {
+ tscadc-adc_cell = tscadc-used_cells;
+ cell = tscadc-cells[tscadc-used_cells++];
+ cell-name = tiadc;
+ cell-platform_data = tscadc;
+ cell-pdata_size = sizeof(*tscadc);
+ }
err = mfd_add_devices(pdev-dev, pdev-id, tscadc-cells,
-
[PATCH] omap2-clk: Add missing lcdc clock definition
Looks like the lcdc clock definition got dropped.
It is required for the LCD controller to work. Reintroduce.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/clock33xx_data.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 1a45d6b..b7b7995 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -867,6 +867,16 @@ static struct clk lcd_gclk = {
.recalc = followparent_recalc,
};
+static struct clk lcdc_fck = {
+ .name = lcdc_fck,
+ .clkdm_name = lcdc_clkdm,
+ .parent = lcd_gclk,
+ .enable_reg = AM33XX_CM_PER_LCDC_CLKCTRL,
+ .enable_bit = AM33XX_MODULEMODE_SWCTRL,
+ .ops= clkops_omap2_dflt,
+ .recalc = followparent_recalc,
+};
+
static struct clk mmc_clk = {
.name = mmc_clk,
.clkdm_name = l4ls_clkdm,
@@ -1075,6 +1085,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, clkout2_ck, clkout2_ck,CK_AM33XX),
CLK(NULL, timer_32k_ck, clkdiv32k_ick, CK_AM33XX),
CLK(NULL, timer_sys_ck, sys_clkin_ck, CK_AM33XX),
+ CLK(da8xx_lcdc.0, NULL, lcdc_fck, CK_AM33XX),
};
int __init am33xx_clk_init(void)
--
1.7.12
--
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] da8xx-fb: add panel definition for beaglebone LCD7 cape
From: Koen Kooi k...@dominion.thruhere.net
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
drivers/video/da8xx-fb.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 4462d9e..c661665 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -284,6 +284,20 @@ static struct da8xx_panel known_lcd_panels[] = {
.pxl_clk = 5600,
.invert_pxl_clk = 0,
},
+ /* ThreeFive S9700RTWV35TR */
+ [4] = {
+ .name = TFC_S9700RTWV35TR_01B,
+ .width = 800,
+ .height = 480,
+ .hfp = 39,
+ .hbp = 39,
+ .hsw = 47,
+ .vfp = 13,
+ .vbp = 29,
+ .vsw = 2,
+ .pxl_clk = 3000,
+ .invert_pxl_clk = 0,
+ },
};
/* Enable the Raster Engine of the LCD Controller */
--
1.7.12
--
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] i2c: pinctrl-ify i2c-omap.c
* Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:04]: Enable pinctrl for i2c-omap. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com Looks good to me: Acked-by: Tony Lindgren t...@atomide.com --- drivers/i2c/busses/i2c-omap.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index db31eae..4c38aa0 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -44,6 +44,8 @@ #include linux/i2c-omap.h #include linux/pm_runtime.h #include linux/pm_qos.h +#include linux/pinctrl/consumer.h +#include linux/err.h /* I2C controller revisions */ #define OMAP_I2C_OMAP1_REV_2 0x20 @@ -1064,6 +1066,7 @@ omap_i2c_probe(struct platform_device *pdev) const struct of_device_id *match; int irq; int r; + struct pinctrl *pinctrl; /* NOTE: driver uses the static register mapping */ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); @@ -1202,6 +1205,13 @@ omap_i2c_probe(struct platform_device *pdev) of_i2c_register_devices(adap); + pinctrl = devm_pinctrl_get_select_default(pdev-dev); + if (IS_ERR(pinctrl)) + dev_warn(dev-dev, unable to select pin group\n); + + dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, adap-nr, + dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed); + pm_runtime_mark_last_busy(dev-dev); pm_runtime_put_autosuspend(dev-dev); -- 1.7.12 -- 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] omap2-clk: Add missing lcdc clock definition
* Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:04]:
Looks like the lcdc clock definition got dropped.
It is required for the LCD controller to work. Reintroduce.
This looks like a regression, can you also add the commit
causing it?
Regards,
Tony
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/clock33xx_data.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index 1a45d6b..b7b7995 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -867,6 +867,16 @@ static struct clk lcd_gclk = {
.recalc = followparent_recalc,
};
+static struct clk lcdc_fck = {
+ .name = lcdc_fck,
+ .clkdm_name = lcdc_clkdm,
+ .parent = lcd_gclk,
+ .enable_reg = AM33XX_CM_PER_LCDC_CLKCTRL,
+ .enable_bit = AM33XX_MODULEMODE_SWCTRL,
+ .ops= clkops_omap2_dflt,
+ .recalc = followparent_recalc,
+};
+
static struct clk mmc_clk = {
.name = mmc_clk,
.clkdm_name = l4ls_clkdm,
@@ -1075,6 +1085,7 @@ static struct omap_clk am33xx_clks[] = {
CLK(NULL, clkout2_ck, clkout2_ck,CK_AM33XX),
CLK(NULL, timer_32k_ck, clkdiv32k_ick, CK_AM33XX),
CLK(NULL, timer_sys_ck, sys_clkin_ck, CK_AM33XX),
+ CLK(da8xx_lcdc.0, NULL, lcdc_fck, CK_AM33XX),
};
int __init am33xx_clk_init(void)
--
1.7.12
--
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] da8xx: Add standard panel definition
Add standard panel definition that can work for the beaglebone
DVI cape.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/video/da8xx-fb.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/video/da8xx-fb.c b/drivers/video/da8xx-fb.c
index 866d804..4462d9e 100644
--- a/drivers/video/da8xx-fb.c
+++ b/drivers/video/da8xx-fb.c
@@ -270,6 +270,20 @@ static struct da8xx_panel known_lcd_panels[] = {
.pxl_clk = 7833600,
.invert_pxl_clk = 0,
},
+ [3] = {
+/* 1024 x 768 @ 60 Hz Reduced blanking VESA CVT 0.79M3-R */
+ .name = 1024x768@60,
+ .width = 1024,
+ .height = 768,
+ .hfp = 48,
+ .hbp = 80,
+ .hsw = 32,
+ .vfp = 3,
+ .vbp = 15,
+ .vsw = 4,
+ .pxl_clk = 5600,
+ .invert_pxl_clk = 0,
+ },
};
/* Enable the Raster Engine of the LCD Controller */
--
1.7.12
--
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] i2c: pinctrl-ify i2c-omap.c
Enable pinctrl for i2c-omap. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- drivers/i2c/busses/i2c-omap.c | 10 ++ 1 file changed, 10 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index db31eae..4c38aa0 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -44,6 +44,8 @@ #include linux/i2c-omap.h #include linux/pm_runtime.h #include linux/pm_qos.h +#include linux/pinctrl/consumer.h +#include linux/err.h /* I2C controller revisions */ #define OMAP_I2C_OMAP1_REV_2 0x20 @@ -1064,6 +1066,7 @@ omap_i2c_probe(struct platform_device *pdev) const struct of_device_id *match; int irq; int r; + struct pinctrl *pinctrl; /* NOTE: driver uses the static register mapping */ mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); @@ -1202,6 +1205,13 @@ omap_i2c_probe(struct platform_device *pdev) of_i2c_register_devices(adap); + pinctrl = devm_pinctrl_get_select_default(pdev-dev); + if (IS_ERR(pinctrl)) + dev_warn(dev-dev, unable to select pin group\n); + + dev_info(dev-dev, bus %d rev%d.%d.%d at %d kHz\n, adap-nr, +dev-dtrev, dev-rev 4, dev-rev 0xf, dev-speed); + pm_runtime_mark_last_busy(dev-dev); pm_runtime_put_autosuspend(dev-dev); -- 1.7.12 -- 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] gpio-keys: Pinctrl-fy
Enable pinctrl support for gpio-keys.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/input/keyboard/gpio_keys.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/input/keyboard/gpio_keys.c
b/drivers/input/keyboard/gpio_keys.c
index 6a68041..e421082 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -29,6 +29,7 @@
#include linux/of_platform.h
#include linux/of_gpio.h
#include linux/spinlock.h
+#include linux/pinctrl/consumer.h
struct gpio_button_data {
const struct gpio_keys_button *button;
@@ -666,6 +667,7 @@ static int __devinit gpio_keys_probe(struct platform_device
*pdev)
struct input_dev *input;
int i, error;
int wakeup = 0;
+ struct pinctrl *pinctrl;
if (!pdata) {
pdata = gpio_keys_get_devtree_pdata(dev);
@@ -731,6 +733,10 @@ static int __devinit gpio_keys_probe(struct
platform_device *pdev)
goto fail3;
}
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev, unable to select pin group\n);
+
/* get current state of buttons that are connected to GPIOs */
for (i = 0; i pdata-nbuttons; i++) {
struct gpio_button_data *bdata = ddata-data[i];
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote: On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote: But then this comes round to the mindless code that ought to be factored out :) Only the more interesting cases that do something unusual really register here. fair enough. I see your point. Not saying I agree though, just that this discussion has been flying for far too long, so feel free to provide patches implementing what you're defending here ;-) Guess code will speak for itself. On way or another, we need OMAP keypad driver working in mainline Are you saying that introducing pincrtl infrastructure actually _broke_ the driver in mainline? Thanks. -- Dmitry -- 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: Export various omap_hwmod related functions
* Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:05]: omap_hwmod_lookup / omap_device_build / omap_device_build_ss; these functions can be used just fine by modules, there's no need not to have them exported. Just curious, where do you plan to use these? These will be private to arch/arm/mach-omap2 and won't be available to drivers with the patches we have queued up in omap-for-v3.8/cleanup-headers branch. Regards, Tony Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- arch/arm/mach-omap2/omap_hwmod.c | 2 ++ arch/arm/plat-omap/omap_device.c | 6 -- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index b969ab1..5b8b6ec 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -138,6 +138,7 @@ #include linux/spinlock.h #include linux/slab.h #include linux/bootmem.h +#include linux/export.h #include plat/clock.h #include plat/omap_hwmod.h @@ -3041,6 +3042,7 @@ struct omap_hwmod *omap_hwmod_lookup(const char *name) return oh; } +EXPORT_SYMBOL(omap_hwmod_lookup); /** * omap_hwmod_for_each - call function for each registered omap_hwmod diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index 7a7d1f2..a15b715 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -663,7 +663,7 @@ void omap_device_delete(struct omap_device *od) * information. Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise, * passes along the return value of omap_device_build_ss(). */ -struct platform_device __init *omap_device_build(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build(const char *pdev_name, int pdev_id, struct omap_hwmod *oh, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats, @@ -678,6 +678,7 @@ struct platform_device __init *omap_device_build(const char *pdev_name, int pdev pdata_len, pm_lats, pm_lats_cnt, is_early_device); } +EXPORT_SYMBOL(omap_device_build); /** * omap_device_build_ss - build and register an omap_device with multiple hwmods @@ -696,7 +697,7 @@ struct platform_device __init *omap_device_build(const char *pdev_name, int pdev * platform_device record. Returns an ERR_PTR() on error, or passes * along the return value of omap_device_register(). */ -struct platform_device __init *omap_device_build_ss(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, struct omap_hwmod **ohs, int oh_cnt, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats, @@ -751,6 +752,7 @@ odbs_exit: return ERR_PTR(ret); } +EXPORT_SYMBOL(omap_device_build_ss); /** * omap_early_device_register - register an omap_device as an early platform -- 1.7.12 -- 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: Export various omap_hwmod related functions
Hi Tony, The patches that use them are going to be posted in about 30mins. They will make this clear. Regards -- Pantelis On Oct 30, 2012, at 8:22 PM, Tony Lindgren wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:05]: omap_hwmod_lookup / omap_device_build / omap_device_build_ss; these functions can be used just fine by modules, there's no need not to have them exported. Just curious, where do you plan to use these? These will be private to arch/arm/mach-omap2 and won't be available to drivers with the patches we have queued up in omap-for-v3.8/cleanup-headers branch. Regards, Tony Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com --- arch/arm/mach-omap2/omap_hwmod.c | 2 ++ arch/arm/plat-omap/omap_device.c | 6 -- 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c index b969ab1..5b8b6ec 100644 --- a/arch/arm/mach-omap2/omap_hwmod.c +++ b/arch/arm/mach-omap2/omap_hwmod.c @@ -138,6 +138,7 @@ #include linux/spinlock.h #include linux/slab.h #include linux/bootmem.h +#include linux/export.h #include plat/clock.h #include plat/omap_hwmod.h @@ -3041,6 +3042,7 @@ struct omap_hwmod *omap_hwmod_lookup(const char *name) return oh; } +EXPORT_SYMBOL(omap_hwmod_lookup); /** * omap_hwmod_for_each - call function for each registered omap_hwmod diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c index 7a7d1f2..a15b715 100644 --- a/arch/arm/plat-omap/omap_device.c +++ b/arch/arm/plat-omap/omap_device.c @@ -663,7 +663,7 @@ void omap_device_delete(struct omap_device *od) * information. Returns ERR_PTR(-EINVAL) if @oh is NULL; otherwise, * passes along the return value of omap_device_build_ss(). */ -struct platform_device __init *omap_device_build(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build(const char *pdev_name, int pdev_id, struct omap_hwmod *oh, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats, @@ -678,6 +678,7 @@ struct platform_device __init *omap_device_build(const char *pdev_name, int pdev pdata_len, pm_lats, pm_lats_cnt, is_early_device); } +EXPORT_SYMBOL(omap_device_build); /** * omap_device_build_ss - build and register an omap_device with multiple hwmods @@ -696,7 +697,7 @@ struct platform_device __init *omap_device_build(const char *pdev_name, int pdev * platform_device record. Returns an ERR_PTR() on error, or passes * along the return value of omap_device_register(). */ -struct platform_device __init *omap_device_build_ss(const char *pdev_name, int pdev_id, +struct platform_device *omap_device_build_ss(const char *pdev_name, int pdev_id, struct omap_hwmod **ohs, int oh_cnt, void *pdata, int pdata_len, struct omap_device_pm_latency *pm_lats, @@ -751,6 +752,7 @@ odbs_exit: return ERR_PTR(ret); } +EXPORT_SYMBOL(omap_device_build_ss); /** * omap_early_device_register - register an omap_device as an early platform -- 1.7.12 -- 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] gpio-keys: Pinctrl-fy
* Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:23]:
Enable pinctrl support for gpio-keys.
There's some discussion going on regarding doing the
pinctrl boilerplate things somewhere else started by
Dmitry, but meanwhile:
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/input/keyboard/gpio_keys.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/input/keyboard/gpio_keys.c
b/drivers/input/keyboard/gpio_keys.c
index 6a68041..e421082 100644
--- a/drivers/input/keyboard/gpio_keys.c
+++ b/drivers/input/keyboard/gpio_keys.c
@@ -29,6 +29,7 @@
#include linux/of_platform.h
#include linux/of_gpio.h
#include linux/spinlock.h
+#include linux/pinctrl/consumer.h
struct gpio_button_data {
const struct gpio_keys_button *button;
@@ -666,6 +667,7 @@ static int __devinit gpio_keys_probe(struct
platform_device *pdev)
struct input_dev *input;
int i, error;
int wakeup = 0;
+ struct pinctrl *pinctrl;
if (!pdata) {
pdata = gpio_keys_get_devtree_pdata(dev);
@@ -731,6 +733,10 @@ static int __devinit gpio_keys_probe(struct
platform_device *pdev)
goto fail3;
}
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev, unable to select pin group\n);
+
/* get current state of buttons that are connected to GPIOs */
for (i = 0; i pdata-nbuttons; i++) {
struct gpio_button_data *bdata = ddata-data[i];
--
1.7.12
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
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] w1-gpio: Pinctrl-fy
* Pantelis Antoniou pa...@antoniou-consulting.com [121030 11:17]:
Enable pinctrl for w1-gpio.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/w1/masters/w1-gpio.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/w1/masters/w1-gpio.c b/drivers/w1/masters/w1-gpio.c
index 6012c4e..aec35bd 100644
--- a/drivers/w1/masters/w1-gpio.c
+++ b/drivers/w1/masters/w1-gpio.c
@@ -16,6 +16,8 @@
#include linux/gpio.h
#include linux/of_platform.h
#include linux/of_gpio.h
+#include linux/pinctrl/consumer.h
+#include linux/err.h
#include ../w1.h
#include ../w1_int.h
@@ -85,8 +87,13 @@ static int __init w1_gpio_probe(struct platform_device
*pdev)
{
struct w1_bus_master *master;
struct w1_gpio_platform_data *pdata;
+ struct pinctrl *pinctrl;
int err;
+ pinctrl = devm_pinctrl_get_select_default(pdev-dev);
+ if (IS_ERR(pinctrl))
+ dev_warn(pdev-dev, unable to select pin group\n);
+
err = w1_gpio_probe_dt(pdev);
if (err 0)
return err;
--
1.7.12
--
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] ti_tscadc: Match mfd sub devices to regmap interface
On 10/31/2012 04:55 PM, Pantelis Antoniou wrote:
The MFD parent device now uses a regmap, instead of direct
memory access. Use the same method in the sub devices to avoid
nasty surprises.
Also rework the channel initialization of tiadc a bit.
Those two bits are not even closely related, they should really go into
separate patches.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/iio/adc/ti_am335x_adc.c | 27 +++
drivers/input/touchscreen/ti_am335x_tsc.c | 16 +---
drivers/mfd/ti_am335x_tscadc.c| 7 +--
3 files changed, 37 insertions(+), 13 deletions(-)
[...]
@@ -213,6 +222,8 @@ static int __devinit tiadc_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, indio_dev);
+ dev_info(pdev-dev, Initialized\n);
That's just noise, please don't add it. Imagine every driver did this you'd
end up with a lot of noise your debug log.
+
return 0;
err_free_channels:
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 7a26810..d09e1a7 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -26,6 +26,7 @@
[...]
/*
@@ -455,10 +460,15 @@ static int __devinit titsc_probe(struct platform_device
*pdev)
/* register to the input system */
err = input_register_device(input_dev);
- if (err)
+ if (err) {
+ dev_err(pdev-dev, Failed to register input device\n);
goto err_free_irq;
+ }
platform_set_drvdata(pdev, ts_dev);
+
+ dev_info(pdev-dev, Initialized OK\n);
Same here
--
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] ti_tscadc: Update with IIO map interface deal with partial activation
On 10/31/2012 04:55 PM, Pantelis Antoniou wrote:
Add an IIO map interface that consumers can use.
Also make sure the mfd device doesn't activate a driver which
the configuration doesn't require.
Same here, two completely different changes in the same patch.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/iio/adc/ti_am335x_adc.c | 53
++--
drivers/mfd/ti_am335x_tscadc.c | 30 ++--
include/linux/mfd/ti_am335x_tscadc.h | 8 ++
3 files changed, 68 insertions(+), 23 deletions(-)
diff --git a/drivers/iio/adc/ti_am335x_adc.c b/drivers/iio/adc/ti_am335x_adc.c
index 02a43c8..d48fd79 100644
--- a/drivers/iio/adc/ti_am335x_adc.c
+++ b/drivers/iio/adc/ti_am335x_adc.c
@@ -20,8 +20,9 @@
#include linux/slab.h
#include linux/interrupt.h
#include linux/platform_device.h
-#include linux/io.h
#include linux/iio/iio.h
+#include linux/iio/machine.h
+#include linux/iio/driver.h
#include linux/mfd/ti_am335x_tscadc.h
#include linux/platform_data/ti_am335x_adc.h
@@ -29,6 +30,8 @@
struct tiadc_device {
struct ti_tscadc_dev *mfd_tscadc;
int channels;
+ char *buf;
As far as I can see 'buf' is not used otherwise in this patch.
+ struct iio_map *map;
};
static unsigned int tiadc_readl(struct tiadc_device *adc, unsigned int reg)
@@ -75,25 +78,57 @@ static void tiadc_step_config(struct tiadc_device
*adc_dev)
static int tiadc_channel_init(struct iio_dev *indio_dev, int channels)
{
struct iio_chan_spec *chan_array;
- int i;
-
- indio_dev-num_channels = channels;
- chan_array = kcalloc(indio_dev-num_channels,
- sizeof(struct iio_chan_spec), GFP_KERNEL);
+ struct iio_chan_spec *chan;
+ char *s;
+ int i, len, size, ret;
+ size = indio_dev-num_channels * (sizeof(struct iio_chan_spec) + 6);
+ chan_array = kzalloc(size, GFP_KERNEL);
if (chan_array == NULL)
return -ENOMEM;
- for (i = 0; i (indio_dev-num_channels); i++) {
- struct iio_chan_spec *chan = chan_array + i;
+ /* buffer space is after the array */
+ s = (char *)(chan_array + indio_dev-num_channels);
+ chan = chan_array;
+ for (i = 0; i indio_dev-num_channels; i++, chan++, s += len + 1) {
+
+ len = sprintf(s, AIN%d, i);
+
chan-type = IIO_VOLTAGE;
chan-indexed = 1;
chan-channel = i;
- chan-info_mask = IIO_CHAN_INFO_RAW_SEPARATE_BIT;
+ chan-datasheet_name = s;
+ chan-scan_type.sign = 'u';
+ chan-scan_type.realbits = 12;
+ chan-scan_type.storagebits = 32;
+ chan-scan_type.shift = 0;
This part is another separate thing done by this patch and is not even in
the patch description.
}
indio_dev-channels = chan_array;
+ size = (indio_dev-num_channels + 1) * sizeof(struct iio_map);
+ adc_dev-map = kzalloc(size, GFP_KERNEL);
+ if (adc_dev-map == NULL) {
+ kfree(chan_array);
+ return -ENOMEM;
+ }
+
+ for (i = 0; i indio_dev-num_channels; i++) {
+ adc_dev-map[i].adc_channel_label =
chan_array[i].datasheet_name;
+ adc_dev-map[i].consumer_dev_name = any;
+ adc_dev-map[i].consumer_channel = chan_array[i].datasheet_name;
+ }
+ adc_dev-map[i].adc_channel_label = NULL;
+ adc_dev-map[i].consumer_dev_name = NULL;
+ adc_dev-map[i].consumer_channel = NULL;
+
+ ret = iio_map_array_register(indio_dev, adc_dev-map);
+ if (ret != 0) {
+ kfree(adc_dev-map);
+ kfree(chan_array);
+ return -ENOMEM;
+ }
The consumer data is supposed to be passed in by platform data, as it will
depend on the actual consumer. E.g. the consumer_dev_name has to match the
name of device which requests the channel. Same goes for the consumer
channel attribute, this is consumer specific as well.
+
return indio_dev-num_channels;
}
diff --git a/drivers/mfd/ti_am335x_tscadc.c b/drivers/mfd/ti_am335x_tscadc.c
index e947dd8..cbb8b70c 100644
--- a/drivers/mfd/ti_am335x_tscadc.c
+++ b/drivers/mfd/ti_am335x_tscadc.c
@@ -176,26 +176,38 @@ static int __devinit ti_tscadc_probe(struct
platform_device *pdev)
ctrl |= CNTRLREG_TSCSSENB;
tscadc_writel(tscadc, REG_CTRL, ctrl);
+ tscadc-used_cells = 0;
+ tscadc-tsc_cell = -1;
+ tscadc-adc_cell = -1;
+
/* TSC Cell */
- cell = tscadc-cells[TSC_CELL];
- cell-name = tsc;
- cell-platform_data = tscadc;
- cell-pdata_size = sizeof(*tscadc);
+ if (tsc_wires 0) {
+ tscadc-tsc_cell = tscadc-used_cells;
+ cell = tscadc-cells[tscadc-used_cells++];
+ cell-name = tsc;
+ cell-platform_data = tscadc;
+ cell-pdata_size = sizeof(*tscadc);
+ }
Re: [PATCH] ti_tscadc: Match mfd sub devices to regmap interface
OK,
Will rework it, and repost.
On Oct 30, 2012, at 8:21 PM, Lars-Peter Clausen wrote:
On 10/31/2012 04:55 PM, Pantelis Antoniou wrote:
The MFD parent device now uses a regmap, instead of direct
memory access. Use the same method in the sub devices to avoid
nasty surprises.
Also rework the channel initialization of tiadc a bit.
Those two bits are not even closely related, they should really go into
separate patches.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
drivers/iio/adc/ti_am335x_adc.c | 27 +++
drivers/input/touchscreen/ti_am335x_tsc.c | 16 +---
drivers/mfd/ti_am335x_tscadc.c| 7 +--
3 files changed, 37 insertions(+), 13 deletions(-)
[...]
@@ -213,6 +222,8 @@ static int __devinit tiadc_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, indio_dev);
+dev_info(pdev-dev, Initialized\n);
That's just noise, please don't add it. Imagine every driver did this you'd
end up with a lot of noise your debug log.
+
return 0;
err_free_channels:
diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c
b/drivers/input/touchscreen/ti_am335x_tsc.c
index 7a26810..d09e1a7 100644
--- a/drivers/input/touchscreen/ti_am335x_tsc.c
+++ b/drivers/input/touchscreen/ti_am335x_tsc.c
@@ -26,6 +26,7 @@
[...]
/*
@@ -455,10 +460,15 @@ static int __devinit titsc_probe(struct
platform_device *pdev)
/* register to the input system */
err = input_register_device(input_dev);
-if (err)
+if (err) {
+dev_err(pdev-dev, Failed to register input device\n);
goto err_free_irq;
+}
platform_set_drvdata(pdev, ts_dev);
+
+dev_info(pdev-dev, Initialized OK\n);
Same here
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote: On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote: But then this comes round to the mindless code that ought to be factored out :) Only the more interesting cases that do something unusual really register here. fair enough. I see your point. Not saying I agree though, just that this discussion has been flying for far too long, so feel free to provide patches implementing what you're defending here ;-) Guess code will speak for itself. On way or another, we need OMAP keypad driver working in mainline and I don't think your arguments are strong enough to keep $SUBJECT from being merged, unless you can provide something stable/tested for v3.8 merge window. Ship me an OMAP5 system and I might see what I can do :) More seriously the amount of time we seem to have been spending recently on changes which end up requiring us to go through essentially every driver and add code to them (often several times) doesn't seem like we're doing a good job here. pinctrl is really noticable because it's new but it's not the only thing. As a subsystem maintainer this code just makes me want to add new subsystem features to pull the code out of drivers but obviously that's not something that should be being done at the subsystem level. signature.asc Description: Digital signature
Re: [PATCH] i2c-EEPROM: Export memory accessor
On 10/31/2012 08:56 AM, Pantelis Antoniou wrote: Various platforms need access to the EEPROM in other places besides their platform registration callbacks. Export the memory accessor to the i2c_client i2c_clients are *not* intrinsically memory, so adding this to the generic i2c_client structure doesn't really make sense. What would the semantics of this interface be with respect to temperature sensors and GPIO expanders? NACK. and implement it for the at24 driver. And before you ask, no, the platform callback can't be used for anything that depends on DT. Why can't you just allocate (and populate) a struct at24_platform_data for the device if it isn't supplied by whatever created the device? -- 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] i2c-EEPROM: Export memory accessor
Hi David, On Oct 30, 2012, at 8:46 PM, David Daney wrote: On 10/31/2012 08:56 AM, Pantelis Antoniou wrote: Various platforms need access to the EEPROM in other places besides their platform registration callbacks. Export the memory accessor to the i2c_client i2c_clients are *not* intrinsically memory, so adding this to the generic i2c_client structure doesn't really make sense. What would the semantics of this interface be with respect to temperature sensors and GPIO expanders? NACK. It's only filled in for EEPROM devices. There's no other I2C memory read interface for kernel clients. and implement it for the at24 driver. And before you ask, no, the platform callback can't be used for anything that depends on DT. Why can't you just allocate (and populate) a struct at24_platform_data for the device if it isn't supplied by whatever created the device? There are no platform_data in the case of device tree only generic-boards. Everything is configured via the DT and there are no callbacks. DT is a purely data driver concept. I'm open to suggestions on how to read an EEPROM from another kernel client, when there's no such thing as platform_data anymore. Regards -- Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi, On Tue, Oct 30, 2012 at 11:20:07AM -0700, Dmitry Torokhov wrote: On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote: On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote: But then this comes round to the mindless code that ought to be factored out :) Only the more interesting cases that do something unusual really register here. fair enough. I see your point. Not saying I agree though, just that this discussion has been flying for far too long, so feel free to provide patches implementing what you're defending here ;-) Guess code will speak for itself. On way or another, we need OMAP keypad driver working in mainline Are you saying that introducing pincrtl infrastructure actually _broke_ the driver in mainline? no dude, I'm saying we need pinctrl working for this driver because we need to remove OMAP-specific MUX settings. One way or another, this has to work. -- balbi signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc3
Hi,
On Tue, Oct 30, 2012 at 10:58:59AM -0700, Tony Lindgren wrote:
* Felipe Balbi ba...@ti.com [121030 10:34]:
Hi,
On Tue, Oct 30, 2012 at 09:27:28AM -0700, Tony Lindgren wrote:
* Vaibhav Hiremath hvaib...@ti.com [121030 07:50]:
MMC is dependent on EDMA-DMA conversion patches from Matt, which he
has
already submitted to the list recently. So MMC support will come
along with
EDMA support. DMA-EDMA patches are targeted for v3.8, lets see how it
goes.
This is a bogus dependency, the MMC driver needs to also work
without DMA.
heh, too bad driver errors out when it doesn't find DMA channels :-)
It should just print a warning instead and continue.
1869 host-rx_chan = dma_request_channel(mask, omap_dma_filter_fn,
rx_req);
1870 if (!host-rx_chan) {
1871 dev_err(mmc_dev(host-mmc), unable to obtain RX DMA
engine channel %u\n, rx_req);
1872 ret = -ENXIO;
1873 goto err_irq;
1874 }
1875
1876 host-tx_chan = dma_request_channel(mask, omap_dma_filter_fn,
tx_req);
1877 if (!host-tx_chan) {
1878 dev_err(mmc_dev(host-mmc), unable to obtain TX DMA
engine channel %u\n, tx_req);
1879 ret = -ENXIO;
1880 goto err_irq;
1881 }
in fact, if DMAENGINE isn't enabled, this won't even compile due to
omap_dma_filter_fn() right ?
It should, CONFIG_DMADEVICES is optional. If it does not compile,
then there's a bug somewhere.
you're right, there's a static inline nop for when we don't have omap
dma engine driver compiled.
nevermind.
--
balbi
signature.asc
Description: Digital signature
[RFC 0/7] Capebus; a bus for SoCs using simple expansion connectors
Capebus is created to address the problem of many SoCs that can provide a multitude of hardware interfaces but in order to keep costs down the main boards only support a limited number of them. The rest are typically brought out to pin connectors on to which other boards, named capes are connected and allow those peripherals to be used. These capes connect to the SoC interfaces but might also contain various other parts that may need some kind of driver to work. Since SoCs have limited pins and pin muxing options, not all capes can work together so some kind of resource tracking (at least for the pins in use) is required. Before capebus all of this took place in the board support file, and frankly for boards with too many capes it was becoming unmanageable. Capebus provides a virtual bus, which along with a board specific controller, cape drivers can be written using the standard Linux device model. The core capebus infrastructure is not depended on any specific board. However capebus needs a board controller to provide services to the cape devices it controls. Services like addressing and resource reservation are provided by the board controller. Capebus at the moment only support TI's Beaglebone platform. This RFC introduces the core concept; most supporting patches have been posted to the relevant places. If you have a beaglebone and want to check it out, you can do so at: git://github.com/pantoniou/linux-bbxm.git branch capebus-v3 Pantelis Antoniou (7): capebus: Core capebus support capebus: Add beaglebone board support capebus: Beaglebone generic cape support capebus: Beaglebone geiger cape support capebus: Beaglebone capebus DT update capebus: Document DT bindings capebus: Documentation; capebus-summary Documentation/capebus/capebus-summary | 40 + .../capebus/bone-capebus-slot-override.txt | 28 + .../devicetree/bindings/capebus/bone-capebus.txt | 50 ++ .../bindings/capebus/bone-geiger-cape.txt | 78 ++ .../bindings/capebus/bone-generic-cape.txt | 97 +++ .../devicetree/bindings/capebus/da8xx-dt.txt | 31 + .../devicetree/bindings/capebus/i2c-dt.txt | 42 + .../devicetree/bindings/capebus/spi-dt.txt | 37 + .../devicetree/bindings/capebus/ti-tscadc-dt.txt | 34 + arch/arm/boot/dts/am335x-bone-common.dtsi | 689 ++- drivers/Kconfig| 2 + drivers/Makefile | 3 + drivers/capebus/Kconfig| 17 + drivers/capebus/Makefile | 8 + drivers/capebus/boards/Kconfig | 6 + drivers/capebus/boards/Makefile| 3 + drivers/capebus/boards/capebus-bone-generic.c | 237 ++ drivers/capebus/boards/capebus-bone-pdevs.c| 602 + drivers/capebus/boards/capebus-bone.c | 931 + drivers/capebus/capebus-driver.c | 608 ++ drivers/capebus/capebus-probe.c| 320 +++ drivers/capebus/capebus-sysfs.c| 52 ++ drivers/capebus/capes/Kconfig | 13 + drivers/capebus/capes/Makefile | 2 + drivers/capebus/capes/bone-geiger-cape.c | 506 +++ drivers/capebus/capes/bone-generic-cape.c | 96 +++ include/linux/capebus.h| 298 +++ include/linux/capebus/capebus-bone.h | 120 +++ 28 files changed, 4920 insertions(+), 30 deletions(-) create mode 100644 Documentation/capebus/capebus-summary create mode 100644 Documentation/devicetree/bindings/capebus/bone-capebus-slot-override.txt create mode 100644 Documentation/devicetree/bindings/capebus/bone-capebus.txt create mode 100644 Documentation/devicetree/bindings/capebus/bone-geiger-cape.txt create mode 100644 Documentation/devicetree/bindings/capebus/bone-generic-cape.txt create mode 100644 Documentation/devicetree/bindings/capebus/da8xx-dt.txt create mode 100644 Documentation/devicetree/bindings/capebus/i2c-dt.txt create mode 100644 Documentation/devicetree/bindings/capebus/spi-dt.txt create mode 100644 Documentation/devicetree/bindings/capebus/ti-tscadc-dt.txt create mode 100644 drivers/capebus/Kconfig create mode 100644 drivers/capebus/Makefile create mode 100644 drivers/capebus/boards/Kconfig create mode 100644 drivers/capebus/boards/Makefile create mode 100644 drivers/capebus/boards/capebus-bone-generic.c create mode 100644 drivers/capebus/boards/capebus-bone-pdevs.c create mode 100644 drivers/capebus/boards/capebus-bone.c create mode 100644 drivers/capebus/capebus-driver.c create mode 100644 drivers/capebus/capebus-probe.c create mode 100644 drivers/capebus/capebus-sysfs.c create mode 100644 drivers/capebus/capes/Kconfig create mode 100644 drivers/capebus/capes/Makefile create mode 100644 drivers/capebus/capes/bone-geiger-cape.c
