Re: [PATCH] ARM: OMAP2+: Fix compiler warning for 32k timer
Hi,
On Thu, Nov 15, 2012 at 03:35:47PM -0600, Jon Hunter wrote:
On 11/15/2012 02:45 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 15, 2012 at 01:44:04PM -0600, Jon Hunter wrote:
+static struct of_device_id omap_counter_match[] __initdata = {
not directly related to $SUBJECT, but shouldn't this be static const
__initconst ?
Yes you are right. Looks like there are several other of_device_id
structs in arch/arm/mach-omap2 that could be updated to const too.
here's a quick sed substitution for you:
$ sed -i 's/static \(struct
of_device_id\)\s\(\w\+\[\]\)\s\(__initdata\|\)/static const \1 \2 __initconst/'
arch/arm/*omap*/*.c
It worked fine here.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: add get_user() support for 8 byte types
On Thursday 15 November 2012, Rob Clark wrote: From: Rob Clark r...@ti.com A new atomic modeset/pageflip ioctl being developed in DRM requires get_user() to work for 64bit types (in addition to just put_user()). v1: original v2: pass correct size to check_uaccess, and better handling of narrowing double word read with __get_user_xb() (Russell King's suggestion) v3: explain in comment about why this works for narrowing fetch to 1, 2, or 4 byte type on ARM. Signed-off-by: Rob Clark r...@ti.com Acked-by: Arnd Bergmann a...@arndb.de -- To unsubscribe from this list: send the line unsubscribe 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/3] omap3 nand : use NAND_BUSWIDTH_AUTO
On Tue, 2012-11-06 at 10:40 -0800, Tony Lindgren wrote: Where such tree could be found ? You should be able to use omap-for-v3.8/cleanup-headers-gpmc branch as a base for your patches [1]. Is this a stable branch which I may pull into l2-mtd.git? Then I could merge Matthieu's patches. -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
Re: [PATCH] usb: dwc3: core: move dwc3_cache_hwparams before dwc3_alloc_event_buffers
Hi,
On Fri, Nov 16, 2012 at 12:07:54PM +0530, Kishon Vijay Abraham I wrote:
commit 392142 moved event buffer allocation out of dwc3_core_init() but
event buffer allocation uses the cached copy of hwparams to determine
the number of event buffers and the caching is done in dwc3_core_init.
So moved dwc3_cache_hwparams function before dwc3_alloc_event_buffers so
that dwc3_alloc_event_buffers sees the correct number of event buffers.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
My bad, what a regression I caused :-)
Greg, can you take this one ?
Signed-off-by: Felipe Balbi ba...@ti.com
---
drivers/usb/dwc3/core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b923183..88e8d31 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -356,8 +356,6 @@ static int __devinit dwc3_core_init(struct dwc3 *dwc)
dwc3_core_soft_reset(dwc);
- dwc3_cache_hwparams(dwc);
-
reg = dwc3_readl(dwc-regs, DWC3_GCTL);
reg = ~DWC3_GCTL_SCALEDOWN_MASK;
reg = ~DWC3_GCTL_DISSCRAMBLE;
@@ -498,6 +496,8 @@ static int __devinit dwc3_probe(struct platform_device
*pdev)
pm_runtime_get_sync(dev);
pm_runtime_forbid(dev);
+ dwc3_cache_hwparams(dwc);
+
ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE);
if (ret) {
dev_err(dwc-dev, failed to allocate event buffers\n);
--
1.7.9.5
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel
On 11/16/2012 02:37 AM, Vinod Koul : On Fri, 2012-11-09 at 14:01 -0600, Jon Hunter wrote: Hi Vinod, A few people have been asking me if getting device-tree support for DMA engine is plan for record for v3.8. I know that you were working through implementing a common interface and so I wanted to check how that is going. Do you have any insight to when device-tree support may get added? I have not been able to do much work on this for last couple of weeks. I hope to do it in by this weekend. If not I will merge yours and then uppdate. Anyway, DT would be there in 3.8 with or without my changes. Vinod, So, can we imagine having this tree in linux-next rapidly (with or without your changes)? Thanks, best regards, -- Nicolas Ferre -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5] OMAPFB: use dma_alloc instead of omap's vram
Hi Tony, On 2012-11-13 00:50, Tony Lindgren wrote: * Tomi Valkeinen tomi.valkei...@ti.com [121112 02:27]: Hi, This series changes omapfb to use standard dma_alloc funcs instead of omap specific vram allocator. This let's us remove the omap vram allocator, making omapfb platform independent. However, note that using standard dma funcs causes the following downsides: 1) dma_alloc_attrs doesn't let us allocate at certain physical address. However, this should not be a problem as this feature of vram allocator is only used when reserving the framebuffer that was initialized by the bootloader, and we don't currently support passing a framebuffer from the bootloader to the kernel anyway. 2) dma_alloc_attrs, as of now, always ioremaps the allocated area, and we don't need the ioremap when using VRFB. This patch uses DMA_ATTR_NO_KERNEL_MAPPING for the allocation, but the flag is currently not operational. 3) OMAPFB_GET_VRAM_INFO ioctl cannot return real values anymore. I changed the ioctl to return 64M for all the values, which, I hope, the applications will interpret as there's enough vram. 4) vram kernel parameter to define how much ram to reserve for video use no longer works. The user needs to enable CMA and use cma parameter. Great, thanks for fixing these. Could you please queue these into a separate branch against v3.7-rc5 that I can also merge into omap-for-v3.8/cleanup-headers-prepare-multiplatform-v3? Should we enable CMA by default in omap2plus_defconfig? And perhaps on omap1 also? I have to say I don't know the details of the dma allocation, but afaik there are no drawbacks with CMA. Although it is still marked EXPERIMENTAL in the kconfig... Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
On Thu, Nov 15, 2012 at 08:31:33AM -0600, Rob Herring wrote: So we should make all these work-arounds depend on !MULTI_PLATFORM then. No, because some of the work-arounds don't require setting bits in magic registers. Also realise this: we test for the revision of the CPU to which they're applicable before attempting to set them. If you have a work-around enabled in the kernel, and it fails at boot, _that_ is an indicator not that the kernel is doing something wrong, but that you need to ensure that the work-around has been applied by the earlier stages. It's not about but platform X doesn't need it - it's about platform X not having the earlier stages updated to fix the errata. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
On Thu, Nov 15, 2012 at 09:37:08AM -0600, Rob Herring wrote: Does that work for Versatile Express CA9? It needs ARM_ERRATA_751472. On VE Linux runs in secure mode, so it's fine. WTF? You are contradicting yourself. No, it's already been explained; the problem is lack of understanding. Versatile Express does indeed run in secure mode; it doesn't have any secure monitor present. OMAP and many other platforms run in non-secure mode. The work-arounds are applied to secure mode registers which are sensitive to writes in the following manner: - we check the revision of the CPU to see whether the workaround is applicable. If it is, then... - the register is read. - the bit(s) are checked to see whether the work-around has already been applied. - the bit(s) is set to the appropriate state. - the register is written _if_ the work-around has not already been applied. That means a platform running in secure mode gets the work-arounds applied as appropriate for the CPU. It also means that a platform running in non- secure mode won't boot if the work-around has not already been applied. That is a good thing; some work-arounds fix data corrupting bugs, and we don't want an unsafe kernel running on such platforms. So, we don't detect whether we're running in secure mode or not; as I've already stated, we don't have a way to do that. We instead only apply work-arounds which aren't already enabled prior to the kernel booting. So, even on a secure mode platform, we will avoid writing the bits if the work-around has already been applied. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] regulator: fixed: Properly use input_supply parameter from device tree
On 11/15/2012 09:11 PM, Laxman Dewangan wrote:
On 11/15/2012 09:56 AM, Roger Quadros wrote:
The device tree node will provide the input supply name as
a string. Use that to populate the supply_name parameter of
the regulator descriptor.
Also correct the documentation to reflect the same.
Signed-off-by: Roger Quadros rog...@ti.com
CC: Laxman Dewangan ldewan...@nvidia.com
CC: Mark Brown broo...@opensource.wolfsonmicro.com
---
regulator-boot-on;
gpio-open-drain;
-vin-supply = parent_reg;
+vin-supply = input-supply-name;
This is not correct as per the regulator binding. It says
- name-supply: phandle to the parent supply/regulator node
So we need to pass the phandle rather than string.
If you see of_get_fixed_voltage_config() in drivers/regulator/fixed.c,
all it does (without my patch) is
if (of_find_property(np, vin-supply, NULL))
config-input_supply = vin;
How is this supposed to work? How does phandle supplied in vin-supply
map to config-input_supply?
This config-input_supply is a string which is used in
reg_fixed_voltage_probe() like below
if (config-input_supply) {
drvdata-desc.supply_name = kstrdup(config-input_supply,
GFP_KERNEL);
So I don't understand how supplying phandle would work. Maybe I missed
something?
Just for curiosity, why do you want this change? What is the issue are
you facing.
Because I could not understood how the original approach would work. But
if you can explain how it works maybe my patch is redundant.
This change will creates regression on many platform.
Did you test your platform on 3.7-rc5?
regards,
-roger
---
This email message is for the sole use of the intended recipient(s) and
may contain
confidential information. Any unauthorized review, use, disclosure or
distribution
is prohibited. If you are not the intended recipient, please contact
the sender by
reply email and destroy all copies of the original message.
---
--
To unsubscribe from this list: send the line unsubscribe 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 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
On Fri, Nov 16, 2012 at 11:43:36, AnilKumar, Chimata wrote:
On Mon, Nov 12, 2012 at 15:17:48, AnilKumar, Chimata wrote:
On Tue, Nov 06, 2012 at 11:15:34, Bedia, Vaibhav wrote:
On Mon, Nov 05, 2012 at 15:12:27, AnilKumar, Chimata wrote:
[...]
+#define SHUTDOWN_TIME_SEC 2
+#define SECS_IN_MIN60
+#define WAIT_AFTER (SECS_IN_MIN -
SHUTDOWN_TIME_SEC)
+#define WAIT_TIME_MS (SHUTDOWN_TIME_SEC * 1000)
+
static void __iomem*rtc_base;
[...]
+
+ /* Wait few seconds instead of rollover */
+ do {
+ omap_rtc_read_time(NULL, tm);
+ if (WAIT_AFTER = tm.tm_sec)
+ mdelay(WAIT_TIME_MS);
+ } while (WAIT_AFTER = tm.tm_sec);
This hardcoded wait for rollover doesn't look good. I see some
helper functions in rtc-lib.c which probably could be used for
converting the current time to elapsed seconds, add the delay and
then convert it back to the time to be programmed in RTC without
worrying about rollover. Why not use that?
I am not aware of those APIs, can you point some?
I have gone through rtc-lib.c, these are the API's I am seeing
in the library
1. rtc_time_to_tm: Convert seconds since 01-01-1970 00:00:00 to
Gregorian date
2. rtc_tm_to_time: Convert Gregorian date to seconds since
01-01-1970 00:00:00
Steps I followed:-
1: unsigned long time;
2: omap_rtc_read_time(NULL, tm);
3: rtc_tm_to_time(tm, time);
4: pr_info(Time 1 %lu\n, time);
5: time += 2; /* (2sec) */
6: rtc_time_to_tm(time, tm);
7: rtc_tm_to_time(tm, time); /* Only for printing time value */
8: pr_info(Time 2 %lu\n, time);
With the above steps I am seeing completely two different time
values at step4 and step8
Nevermind it working now.
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 1/4] ARM: OMAP: usb-host: Device tree support for USB Host
Hi Benoit,
On 11/16/2012 12:30 PM, Benoit Cousson wrote:
Hi Roger,
On 11/15/2012 03:56 PM, Roger Quadros wrote:
Provides a means for the OMAP USB host subsystem to be initialized
from Device tree. This is a first step for device tree migration where
we specify only the board specific stuff. Things like I/O address space
and interrupts are not yet specified in the device tree but can be
done as a next step.
This patch will allow boards to be booted with our without device tree
and have USB host functional.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/arm/omap/usb-host.txt | 60 +
arch/arm/mach-omap2/board-generic.c|1 +
arch/arm/mach-omap2/common.h |2 +
arch/arm/mach-omap2/usb-host.c | 71
4 files changed, 134 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/usb-host.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/usb-host.txt
b/Documentation/devicetree/bindings/arm/omap/usb-host.txt
new file mode 100644
index 000..f25cfa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/usb-host.txt
@@ -0,0 +1,60 @@
+* usb-host - OMAP USB Host Subsystem
+
+The OMAP USB host subsystem consists of the following modules
+1) USBTLL (Tranceiverless interface)
+2) USBHOST (Host Controller module) which includes both EHCI and OHCI
controllers
+
+THe USB Host subsystem can be connected to the external world using 3 PORTs
that could
+be configured in various modes like UTMI+ for external PHY, ULPI
transceiverless link (TLL),
+Serial TLL, High-speed interchip (HSIC), etc.
+
+Required proprties:
+- compatible: Must be ti,usb-host;
+- num_ports: Number of physical ports available
+
+Optional properties:
+- 1 child node for each available port. These child nodes are usually
supplied by the
+ board support device tree as they are specific to how the ports are wired
on the board
+
+ - mode: Integer specifying the mode in which the port is used
+* OMAP_USBHS_PORT_MODE_UNUSED = 0,
+* OMAP_EHCI_PORT_MODE_PHY = 1,
+* OMAP_EHCI_PORT_MODE_TLL = 2,
+* OMAP_EHCI_PORT_MODE_HSIC = 3,
+* OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0 = 4,
+* OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM = 5,
+* OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0 = 6,
+* OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM = 7,
+* OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0 = 8,
+* OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM = 9,
+* OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0 = 10,
+* OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM = 11,
+* OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0 = 12,
+* OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM = 13,
+ - clk: Name of the clock that needs to be active when using the port
+ - clkrate: Frequency at which the above clk needs to be run at
+
+
+Example:
+
+/* In the OMAP Core tree */
+usbhost: usb-host {
+compatible = ti,usb-host;
+num_ports = 3;
+};
+
+/* In the Board tree */
+usbhost {
+port@0 {
+mode = 1;
+clk = auxclk3_ck;
+clkrate = 1920;
+};
+port@1 {
+mode = 0;
+};
+port@2 {
+mode = 0;
+};
+};
+
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 601ecdf..4e53b62 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -40,6 +40,7 @@ static void __init omap_generic_init(void)
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+usbhost_init_of();
You should never have to add that kind of hacks in generic board file.
Why do you need that during board init?
In theory, the of_platform_populate will create all the devices, and
during the driver probe you will create the sub nodes.
OK. I was thinking of this as a temporary fix till the USB host drivers
support OF nodes natively. Maybe I should work on fixing up the host
drivers instead.
But I'm not sure how the PM runtime calls map to omap_device/hwmod
framework when device tree boot is used. I can see that the device tree
node can specify ti,hwmods = parameter. Just can't seem to figure out
how all this adds up :P
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] ARM: OMAP: usb-host: Device tree support for USB Host
On 11/16/2012 11:55 AM, Roger Quadros wrote:
Hi Benoit,
On 11/16/2012 12:30 PM, Benoit Cousson wrote:
Hi Roger,
On 11/15/2012 03:56 PM, Roger Quadros wrote:
Provides a means for the OMAP USB host subsystem to be initialized
from Device tree. This is a first step for device tree migration where
we specify only the board specific stuff. Things like I/O address space
and interrupts are not yet specified in the device tree but can be
done as a next step.
This patch will allow boards to be booted with our without device tree
and have USB host functional.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/arm/omap/usb-host.txt | 60 +
arch/arm/mach-omap2/board-generic.c|1 +
arch/arm/mach-omap2/common.h |2 +
arch/arm/mach-omap2/usb-host.c | 71
4 files changed, 134 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/usb-host.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/usb-host.txt
b/Documentation/devicetree/bindings/arm/omap/usb-host.txt
new file mode 100644
index 000..f25cfa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/usb-host.txt
@@ -0,0 +1,60 @@
+* usb-host - OMAP USB Host Subsystem
+
+The OMAP USB host subsystem consists of the following modules
+1) USBTLL (Tranceiverless interface)
+2) USBHOST (Host Controller module) which includes both EHCI and OHCI
controllers
+
+THe USB Host subsystem can be connected to the external world using 3
PORTs that could
+be configured in various modes like UTMI+ for external PHY, ULPI
transceiverless link (TLL),
+Serial TLL, High-speed interchip (HSIC), etc.
+
+Required proprties:
+- compatible: Must be ti,usb-host;
+- num_ports: Number of physical ports available
+
+Optional properties:
+- 1 child node for each available port. These child nodes are usually
supplied by the
+ board support device tree as they are specific to how the ports are
wired on the board
+
+ - mode: Integer specifying the mode in which the port is used
+ * OMAP_USBHS_PORT_MODE_UNUSED = 0,
+ * OMAP_EHCI_PORT_MODE_PHY = 1,
+ * OMAP_EHCI_PORT_MODE_TLL = 2,
+ * OMAP_EHCI_PORT_MODE_HSIC = 3,
+ * OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0 = 4,
+ * OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM = 5,
+ * OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0 = 6,
+ * OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM = 7,
+ * OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0 = 8,
+ * OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM = 9,
+ * OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0 = 10,
+ * OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM = 11,
+ * OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0 = 12,
+ * OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM = 13,
+ - clk: Name of the clock that needs to be active when using the port
+ - clkrate: Frequency at which the above clk needs to be run at
+
+
+Example:
+
+/* In the OMAP Core tree */
+usbhost: usb-host {
+ compatible = ti,usb-host;
+ num_ports = 3;
+};
+
+/* In the Board tree */
+usbhost {
+ port@0 {
+ mode = 1;
+ clk = auxclk3_ck;
+ clkrate = 1920;
+ };
+ port@1 {
+ mode = 0;
+ };
+ port@2 {
+ mode = 0;
+ };
+};
+
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 601ecdf..4e53b62 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -40,6 +40,7 @@ static void __init omap_generic_init(void)
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ usbhost_init_of();
You should never have to add that kind of hacks in generic board file.
Why do you need that during board init?
In theory, the of_platform_populate will create all the devices, and
during the driver probe you will create the sub nodes.
OK. I was thinking of this as a temporary fix till the USB host drivers
support OF nodes natively. Maybe I should work on fixing up the host
drivers instead.
Well, yeah, that's clearly better.
But I'm not sure how the PM runtime calls map to omap_device/hwmod
framework when device tree boot is used. I can see that the device tree
node can specify ti,hwmods = parameter. Just can't seem to figure out
how all this adds up :P
It is done auto-magically in the omap_device code. As soon as you add
the ti,hwmods: attribute, an omap_device will be created instead of a
regular platform_device. A custom PM domain is added to handle the
pm_runtime callback for OMAP IPs. And every omap_device belongs to that
PM domain.
Regards,
Benoit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.7-rc5
Boot tests:
* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
- May be fixed now, pending retest:
- http://marc.info/?l=linux-omapm=135082257727502w=2
- Not yet part of the automated test suite
* May be due to an old U-boot with FDT support problems used here?
Pending local investigation and re-test
I'm also trying to boot 3.7-rc5, but my board has console on ttyO3. So I took
arch/arm/boot/dts/am335x-evm.dts and replaced uart definition to
uart4: serial@481a6000 {
status = okay;
};
is it sufficient?
In u-boot
commit 59852d03867108217fe88e3bfc3e1e9cedfe63c5
Merge: 22b6fcb b3e5cd1
Author: Tom Rini tr...@ti.com
Date: Fri Nov 9 08:47:25 2012 -0700
Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
I use following commands and get following output:
U-Boot# mmc rescan ; fatload mmc 0 8200 uImage;fatload mmc 0 8000
am335x-evm.dtb
reading uImage
4222584 bytes read
reading am335x-evm.dtb
5172 bytes read
U-Boot# fdt addr 8000; fdt resize; bootm 8200 - 8000
## Booting kernel from Legacy Image at 8200 ...
Image Name: Linux-3.7.0-rc5-00028-g79e979e
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:4222520 Bytes = 4 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 8000
Booting using the fdt blob at 0x8000
Loading Kernel Image ... OK
OK
reserving fdt memory region: addr=8000 size=2000
Loading Device Tree to 8fe64000, end 8fe68fff ... OK
Starting kernel ...
I force kernel to use default params, so I don't specify them in u-boot. Any
idea?
Best regards,
Yegor
--
To unsubscribe from this list: send the line unsubscribe 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 PATCH v3 1/4] i2c: introduce i2c-cbus driver
On Mon, Nov 12, 2012 at 09:08:42PM +0200, Aaro Koskinen wrote: Add i2c driver to enable access to devices behind CBUS on Nokia Internet Tablets. The patch also adds CBUS I2C configuration for N8x0 which is one of the users of this driver. Cc: linux-...@vger.kernel.org Acked-by: Felipe Balbi ba...@ti.com Acked-by: Tony Lindgren t...@atomide.com Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi Cc: Wolfram Sang w.s...@pengutronix.de Mostly good, but the devicetree binding description is missing. Please add a proper file with the same name as the driver to Documentation/devicetree/bindings/i2c. Also, it might make sense to rename the driver to i2c-cbus-gpio? Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.7-rc5
On Fri, Nov 16, 2012 at 11:47 AM, Richard Cochran richardcoch...@gmail.com wrote: On Tue, Nov 13, 2012 at 08:05:26PM +0400, Igor Mazanov wrote: Paul Walmsley wrote: * AM335x Beaglebone: omap2plus_defconfig kernels don't boot - May be fixed now, pending retest: - http://marc.info/?l=linux-omapm=135082257727502w=2 - Not yet part of the automated test suite * May be due to an old U-boot with FDT support problems used here? Pending local investigation and re-test I have the same result with omap2plus_defconfig and kernel 3.7.0-rc5. I dumped the kernel log buffer via JTAG and can send this log if it could be useful. I just got my BeagleBone replaced via RMA, and so I could try a fresh build of 3.7.0-rc5 with omap2plus_defconfig. It works just fine for me. A few details: U-Boot SPL 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20) U-Boot 2012.10-rc1-00148-g4668a08 (Sep 30 2012 - 09:35:20) setenv ipaddr 192.168.0.77 setenv serverip 192.168.0.12 setenv netmask 255.255.255.0 setenv bootargs console=ttyO0,115200n8 mem=256M root=/dev/ram rw initrd=0x8200,16MB ramdisk_size=16384 earlyprintk=serial tftp 8100 uImage tftp 8200 beaglebone-initrd.gz tftp 8000 am335x-bone.dtb bootm 8100 - 8000 So I guess just using a recent u-boot will fix whatever issues you are seeing. I have a quite new u-boot, exactly U-Boot 2012.10-02160-gc4d22de (Oct 24 2012 - 18:25:04). The problem was in some inconsistency with clock names during changes in the AM33xx clock subsystem, see http://marc.info/?l=linux-omapm=135299082705058w=2 For now Beaglebone boots with current git kernel. Regards, Igor. Thanks, Richard -- To unsubscribe from this list: send the line unsubscribe 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-rc5
Yegor Yefremov wrote:
Boot tests:
* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
- May be fixed now, pending retest:
- http://marc.info/?l=linux-omapm=135082257727502w=2
- Not yet part of the automated test suite
* May be due to an old U-boot with FDT support problems used here?
Pending local investigation and re-test
I'm also trying to boot 3.7-rc5, but my board has console on ttyO3. So I took
arch/arm/boot/dts/am335x-evm.dts and replaced uart definition to
uart4: serial@481a6000 {
status = okay;
};
is it sufficient?
In u-boot
commit 59852d03867108217fe88e3bfc3e1e9cedfe63c5
Merge: 22b6fcb b3e5cd1
Author: Tom Rini tr...@ti.com
Date: Fri Nov 9 08:47:25 2012 -0700
Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
I use following commands and get following output:
U-Boot# mmc rescan ; fatload mmc 0 8200 uImage;fatload mmc 0 8000
am335x-evm.dtb
reading uImage
4222584 bytes read
reading am335x-evm.dtb
5172 bytes read
U-Boot# fdt addr 8000; fdt resize; bootm 8200 - 8000
## Booting kernel from Legacy Image at 8200 ...
Image Name: Linux-3.7.0-rc5-00028-g79e979e
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:4222520 Bytes = 4 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 8000
Booting using the fdt blob at 0x8000
Loading Kernel Image ... OK
OK
reserving fdt memory region: addr=8000 size=2000
Loading Device Tree to 8fe64000, end 8fe68fff ... OK
Starting kernel ...
I force kernel to use default params, so I don't specify them in u-boot. Any
idea?
Did you try to set console=ttyO3,115200 in u-boot bootargs settings?
Best regards,
Yegor
--
To unsubscribe from this list: send the line unsubscribe 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: OMAP baseline test results for v3.7-rc5
On 16.11.2012 12:56, Igor Mazanov wrote:
Yegor Yefremov wrote:
Boot tests:
* AM335x Beaglebone: omap2plus_defconfig kernels don't boot
- May be fixed now, pending retest:
- http://marc.info/?l=linux-omapm=135082257727502w=2
- Not yet part of the automated test suite
* May be due to an old U-boot with FDT support problems used here?
Pending local investigation and re-test
I'm also trying to boot 3.7-rc5, but my board has console on ttyO3. So I
took arch/arm/boot/dts/am335x-evm.dts and replaced uart definition to
uart4: serial@481a6000 {
status = okay;
};
is it sufficient?
In u-boot
commit 59852d03867108217fe88e3bfc3e1e9cedfe63c5
Merge: 22b6fcb b3e5cd1
Author: Tom Rini tr...@ti.com
Date: Fri Nov 9 08:47:25 2012 -0700
Merge branch 'master' of git://www.denx.de/git/u-boot-microblaze
I use following commands and get following output:
U-Boot# mmc rescan ; fatload mmc 0 8200 uImage;fatload mmc 0 8000
am335x-evm.dtb
reading uImage
4222584 bytes read
reading am335x-evm.dtb
5172 bytes read
U-Boot# fdt addr 8000; fdt resize; bootm 8200 - 8000
## Booting kernel from Legacy Image at 8200 ...
Image Name: Linux-3.7.0-rc5-00028-g79e979e
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size:4222520 Bytes = 4 MiB
Load Address: 80008000
Entry Point: 80008000
Verifying Checksum ... OK
## Flattened Device Tree blob at 8000
Booting using the fdt blob at 0x8000
Loading Kernel Image ... OK
OK
reserving fdt memory region: addr=8000 size=2000
Loading Device Tree to 8fe64000, end 8fe68fff ... OK
Starting kernel ...
I force kernel to use default params, so I don't specify them in u-boot. Any
idea?
Did you try to set console=ttyO3,115200 in u-boot bootargs settings?
Got the stuff working by just invoking make omap2plus_config once again.
Perhaps I changed something viable and didn't notice that. Now waiting for MMC
device tree support ;-)
Thanks.
Yegor
--
To unsubscribe from this list: send the line unsubscribe 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/4] ARM: OMAP: usb-host: Device tree support for USB Host
On 11/16/2012 01:06 PM, Benoit Cousson wrote:
On 11/16/2012 11:55 AM, Roger Quadros wrote:
Hi Benoit,
On 11/16/2012 12:30 PM, Benoit Cousson wrote:
Hi Roger,
On 11/15/2012 03:56 PM, Roger Quadros wrote:
Provides a means for the OMAP USB host subsystem to be initialized
from Device tree. This is a first step for device tree migration where
we specify only the board specific stuff. Things like I/O address space
and interrupts are not yet specified in the device tree but can be
done as a next step.
This patch will allow boards to be booted with our without device tree
and have USB host functional.
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/arm/omap/usb-host.txt | 60
+
arch/arm/mach-omap2/board-generic.c|1 +
arch/arm/mach-omap2/common.h |2 +
arch/arm/mach-omap2/usb-host.c | 71
4 files changed, 134 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/usb-host.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/usb-host.txt
b/Documentation/devicetree/bindings/arm/omap/usb-host.txt
new file mode 100644
index 000..f25cfa4
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/usb-host.txt
@@ -0,0 +1,60 @@
+* usb-host - OMAP USB Host Subsystem
+
+The OMAP USB host subsystem consists of the following modules
+1) USBTLL (Tranceiverless interface)
+2) USBHOST (Host Controller module) which includes both EHCI and OHCI
controllers
+
+THe USB Host subsystem can be connected to the external world using 3
PORTs that could
+be configured in various modes like UTMI+ for external PHY, ULPI
transceiverless link (TLL),
+Serial TLL, High-speed interchip (HSIC), etc.
+
+Required proprties:
+- compatible: Must be ti,usb-host;
+- num_ports: Number of physical ports available
+
+Optional properties:
+- 1 child node for each available port. These child nodes are usually
supplied by the
+ board support device tree as they are specific to how the ports are
wired on the board
+
+ - mode: Integer specifying the mode in which the port is used
+ * OMAP_USBHS_PORT_MODE_UNUSED = 0,
+ * OMAP_EHCI_PORT_MODE_PHY = 1,
+ * OMAP_EHCI_PORT_MODE_TLL = 2,
+ * OMAP_EHCI_PORT_MODE_HSIC = 3,
+ * OMAP_OHCI_PORT_MODE_PHY_6PIN_DATSE0 = 4,
+ * OMAP_OHCI_PORT_MODE_PHY_6PIN_DPDM = 5,
+ * OMAP_OHCI_PORT_MODE_PHY_3PIN_DATSE0 = 6,
+ * OMAP_OHCI_PORT_MODE_PHY_4PIN_DPDM = 7,
+ * OMAP_OHCI_PORT_MODE_TLL_6PIN_DATSE0 = 8,
+ * OMAP_OHCI_PORT_MODE_TLL_6PIN_DPDM = 9,
+ * OMAP_OHCI_PORT_MODE_TLL_3PIN_DATSE0 = 10,
+ * OMAP_OHCI_PORT_MODE_TLL_4PIN_DPDM = 11,
+ * OMAP_OHCI_PORT_MODE_TLL_2PIN_DATSE0 = 12,
+ * OMAP_OHCI_PORT_MODE_TLL_2PIN_DPDM = 13,
+ - clk: Name of the clock that needs to be active when using the port
+ - clkrate: Frequency at which the above clk needs to be run at
+
+
+Example:
+
+/* In the OMAP Core tree */
+usbhost: usb-host {
+ compatible = ti,usb-host;
+ num_ports = 3;
+};
+
+/* In the Board tree */
+usbhost {
+ port@0 {
+ mode = 1;
+ clk = auxclk3_ck;
+ clkrate = 1920;
+ };
+ port@1 {
+ mode = 0;
+ };
+ port@2 {
+ mode = 0;
+ };
+};
+
diff --git a/arch/arm/mach-omap2/board-generic.c
b/arch/arm/mach-omap2/board-generic.c
index 601ecdf..4e53b62 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -40,6 +40,7 @@ static void __init omap_generic_init(void)
omap_sdrc_init(NULL, NULL);
of_platform_populate(NULL, omap_dt_match_table, NULL, NULL);
+ usbhost_init_of();
You should never have to add that kind of hacks in generic board file.
Why do you need that during board init?
In theory, the of_platform_populate will create all the devices, and
during the driver probe you will create the sub nodes.
OK. I was thinking of this as a temporary fix till the USB host drivers
support OF nodes natively. Maybe I should work on fixing up the host
drivers instead.
Well, yeah, that's clearly better.
But I'm not sure how the PM runtime calls map to omap_device/hwmod
framework when device tree boot is used. I can see that the device tree
node can specify ti,hwmods = parameter. Just can't seem to figure out
how all this adds up :P
It is done auto-magically in the omap_device code. As soon as you add
the ti,hwmods: attribute, an omap_device will be created instead of a
regular platform_device. A custom PM domain is added to handle the
pm_runtime callback for OMAP IPs. And every omap_device belongs to that
PM domain.
Thanks. Just figured out it happens through BUS_NOTIFY_ADD_DEVICE -
_omap_device_notifier_call() - omap_device_build_from_dt()
cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe
Re: [PATCH] usb: dwc3: core: move dwc3_cache_hwparams before dwc3_alloc_event_buffers
Hello. On 16-11-2012 10:37, Kishon Vijay Abraham I wrote: commit 392142 Please specify thta commit summary in parens. moved event buffer allocation out of dwc3_core_init() but event buffer allocation uses the cached copy of hwparams to determine the number of event buffers and the caching is done in dwc3_core_init. So moved dwc3_cache_hwparams function before dwc3_alloc_event_buffers so that dwc3_alloc_event_buffers sees the correct number of event buffers. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com 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
[PATCH v2 3/4] ARM: dts: AM33XX: Set pmic-shutdown-controller for BeagleBone
Set ti,pmic-shutdown-controller for BeagleBone in am335x-bone.dts
file, this flag is used by the driver to set tps65217 PMIC status
to OFF when PWR_EN toggle.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 2c33888..1d55190 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -88,6 +88,8 @@
/include/ tps65217.dtsi
tps {
+ ti,pmic-shutdown-controller;
+
regulators {
dcdc1_reg: regulator@0 {
regulator-always-on;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 4/4] ARM: dts: AM33XX: Enable system power off control in am335x-bone
Enable system power off control for BeagleBone in am335x-bone.dts file
under rtc node. RTC is the incharge of controlling the system power.
This flag is used by the driver to hook up the pm_power_off system call.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 1d55190..206c3eb 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -52,6 +52,10 @@
};
};
+
+ rtc@44e3e000 {
+ ti,system-power-controller;
+ };
};
leds {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/4] pm: Add power off control
Add PM power_off control to rtc driver, along with this PMIC status is set to STATUS_OFF to shutdown PMIC if PWR_EN is toggled by RTC module. System power off sequence:- * Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low * Enable PMIC_POWER_EN in rtc module * Set rtc ALARM2 time * Enable ALARM2 interrupt These patches were tested on AM335x-Bone. Changes from v1: - Incorporated Vaibhav's comments on v1 * Changed the time rollover logic with the help of rtc-lib APIs AnilKumar Ch (2): ARM: dts: AM33XX: Set pmic-shutdown-controller for BeagleBone ARM: dts: AM33XX: Enable system power off control in am335x-bone Colin Foe-Parker (2): mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle rtc: OMAP: Add system pm_power_off to rtc driver .../devicetree/bindings/regulator/tps65217.txt |4 + Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++ arch/arm/boot/dts/am335x-bone.dts |6 ++ drivers/mfd/tps65217.c | 12 +++ drivers/rtc/rtc-omap.c | 81 +++- 5 files changed, 107 insertions(+), 1 deletion(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
From: Colin Foe-Parker colin.foepar...@logicpd.com
Set tps65217 PMIC status to OFF if power enable toggle is
supported. Also adds platform data flag, which should be
passed from board init data.
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move the additions to tps65217 MFD driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
.../devicetree/bindings/regulator/tps65217.txt |4
drivers/mfd/tps65217.c | 12
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
index d316fb8..4f05d20 100644
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
@@ -11,6 +11,9 @@ Required properties:
using the standard binding for regulators found at
Documentation/devicetree/bindings/regulator/regulator.txt.
+Optional properties:
+- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
+
The valid names for regulators are:
tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
@@ -20,6 +23,7 @@ Example:
tps: tps@24 {
compatible = ti,tps65217;
+ ti,pmic-shutdown-controller;
regulators {
dcdc1_reg: dcdc1 {
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index 3fb32e6..c7f17d8 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -160,6 +160,7 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
unsigned int version;
unsigned int chip_id = ids-driver_data;
const struct of_device_id *match;
+ bool status_off = false;
int ret;
if (client-dev.of_node) {
@@ -170,6 +171,8 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
return -EINVAL;
}
chip_id = (unsigned int)match-data;
+ status_off = of_property_read_bool(client-dev.of_node,
+ ti,pmic-shutdown-controller);
}
if (!chip_id) {
@@ -207,6 +210,15 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
return ret;
}
+ /* Set the PMIC to shutdown on PWR_EN toggle */
+ if (status_off) {
+ ret = tps65217_set_bits(tps, TPS65217_REG_STATUS,
+ TPS65217_STATUS_OFF, TPS65217_STATUS_OFF,
+ TPS65217_PROTECT_NONE);
+ if (ret)
+ dev_warn(tps-dev, unable to set the status OFF\n);
+ }
+
dev_info(tps-dev, TPS65217 ID %#x version 1.%d\n,
(version TPS65217_CHIPID_CHIP_MASK) 4,
version TPS65217_CHIPID_REV_MASK);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/4] rtc: OMAP: Add system pm_power_off to rtc driver
From: Colin Foe-Parker colin.foepar...@logicpd.com
Add system power off control to rtc driver which is the in-charge
of controlling the BeagleBone system power. The power_off routine
can be hooked up to pm_power_off system call.
System power off sequence:-
* Set PMIC STATUS_OFF when PMIC_POWER_EN is pulled low
* Enable PMIC_POWER_EN in rtc module
* Set rtc ALARM2 time
* Enable ALARM2 interrupt
Added while (1); after the above steps to make sure that no other
process acquire cpu. Otherwise we might see an unexpected behaviour
because we are shutting down all the power rails of SoC except RTC.
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move poweroff additions to rtc driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
Documentation/devicetree/bindings/rtc/rtc-omap.txt |5 ++
drivers/rtc/rtc-omap.c | 81 +++-
2 files changed, 85 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
index b47aa41..8d9f4f9 100644
--- a/Documentation/devicetree/bindings/rtc/rtc-omap.txt
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -6,6 +6,10 @@ Required properties:
- interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller
+Optional properties:
+- ti,system-power-controller: Telling whether or not rtc is controlling
+ the system power.
+
Example:
rtc@1c23000 {
@@ -14,4 +18,5 @@ rtc@1c23000 {
interrupts = 19
19;
interrupt-parent = intc;
+ ti,system-power-controller;
};
diff --git a/drivers/rtc/rtc-omap.c b/drivers/rtc/rtc-omap.c
index 6009714..c31f93a 100644
--- a/drivers/rtc/rtc-omap.c
+++ b/drivers/rtc/rtc-omap.c
@@ -72,6 +72,14 @@
#define OMAP_RTC_KICK0_REG 0x6c
#define OMAP_RTC_KICK1_REG 0x70
+#define OMAP_RTC_ALARM2_SECONDS_REG0x80
+#define OMAP_RTC_ALARM2_MINUTES_REG0x84
+#define OMAP_RTC_ALARM2_HOURS_REG 0x88
+#define OMAP_RTC_ALARM2_DAYS_REG 0x8c
+#define OMAP_RTC_ALARM2_MONTHS_REG 0x90
+#define OMAP_RTC_ALARM2_YEARS_REG 0x94
+#define OMAP_RTC_PMIC_REG 0x98
+
/* OMAP_RTC_CTRL_REG bit fields: */
#define OMAP_RTC_CTRL_SPLIT(17)
#define OMAP_RTC_CTRL_DISABLE (16)
@@ -93,15 +101,21 @@
#define OMAP_RTC_STATUS_BUSY(10)
/* OMAP_RTC_INTERRUPTS_REG bit fields: */
+#define OMAP_RTC_INTERRUPTS_IT_ALARM2 (14)
#define OMAP_RTC_INTERRUPTS_IT_ALARM(13)
#define OMAP_RTC_INTERRUPTS_IT_TIMER(12)
+/* OMAP_RTC_PMIC_REG bit fields: */
+#define OMAP_RTC_PMIC_POWER_EN_EN (116)
+
/* OMAP_RTC_KICKER values */
#defineKICK0_VALUE 0x83e70b13
#defineKICK1_VALUE 0x95a4f1e0
#defineOMAP_RTC_HAS_KICKER 0x1
+#define SHUTDOWN_TIME_SEC 2
+
static void __iomem*rtc_base;
#define rtc_read(addr) readb(rtc_base + (addr))
@@ -290,6 +304,63 @@ static int omap_rtc_set_alarm(struct device *dev, struct
rtc_wkalrm *alm)
return 0;
}
+/*
+ * rtc_power_off: Set the pmic power off sequence. The RTC generates
+ * pmic_pwr_enable control, which can be used to control an external
+ * PMIC.
+ */
+static void rtc_power_off(void)
+{
+ u32 val;
+ struct rtc_time tm;
+ spinlock_t lock;
+ unsigned long flags, time;
+
+ spin_lock_init(lock);
+
+ /* Set PMIC power enable */
+ val = readl(rtc_base + OMAP_RTC_PMIC_REG);
+ writel(val | OMAP_RTC_PMIC_POWER_EN_EN, rtc_base + OMAP_RTC_PMIC_REG);
+
+ /* Read rtc time */
+ omap_rtc_read_time(NULL, tm);
+
+ /* Convert Gregorian date to seconds since 01-01-1970 00:00:00 */
+ rtc_tm_to_time(tm, time);
+
+ /* Add shutdown time to the current value */
+ time += SHUTDOWN_TIME_SEC;
+
+ /* Convert seconds since 01-01-1970 00:00:00 to Gregorian date */
+ rtc_time_to_tm(time, tm);
+
+ if (tm2bcd(tm) 0)
+ return;
+
+ pr_info(System will go to power_off state in approx. %d secs\n,
+ SHUTDOWN_TIME_SEC);
+
+ /*
+* pmic_pwr_enable is controlled by means of ALARM2 event. So here
+* programming alarm2 expiry time and enabling alarm2 interrupt
+*/
+ rtc_write(tm.tm_sec, OMAP_RTC_ALARM2_SECONDS_REG);
+ rtc_write(tm.tm_min, OMAP_RTC_ALARM2_MINUTES_REG);
+ rtc_write(tm.tm_hour, OMAP_RTC_ALARM2_HOURS_REG);
+ rtc_write(tm.tm_mday, OMAP_RTC_ALARM2_DAYS_REG);
+ rtc_write(tm.tm_mon, OMAP_RTC_ALARM2_MONTHS_REG);
+ rtc_write(tm.tm_year, OMAP_RTC_ALARM2_YEARS_REG);
+
+ /* Enable alarm2 interrupt */
+ val = readl(rtc_base + OMAP_RTC_INTERRUPTS_REG);
+ writel(val | OMAP_RTC_INTERRUPTS_IT_ALARM2,
+ rtc_base + OMAP_RTC_INTERRUPTS_REG);
+
+ /* Do not allow to
Re: [PATCH] drm/omap: use omapdss low level API
On Thu, Nov 15, 2012 at 06:00:58PM -0600, Rob Clark wrote: This patch changes the omapdrm KMS to bypass the omapdss compat layer and use the core omapdss API directly. This solves some layering issues that would cause unpin confusion vs GO bit status, because we would not know whether a particular pageflip or overlay update has hit the screen or not. Now instead we explicitly manage the GO bits in dispc and handle the vblank/framedone interrupts ourself so that we always know which buffers are being scanned out at any given time, and so on. As an added bonus, we no longer leave the last overlay buffer pinned when the display is disabled, and have been able to add the previously missing vblank event handling. Signed-off-by: Rob Clark robdcl...@gmail.com --- Note: this patch applies on top of staging-next plus the OMAPDSS: create compat layer patch series: http://comments.gmane.org/gmane.linux.ports.arm.omap/89435 Hm, I can't take that patch set in staging-next, so how should this go in? thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] OMAP: board-files: fix i2c_bus for tfp410
The i2c handling in tfp410 driver, which handles converting parallel RGB
to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af. The
patch changed what value the driver considers as invalid/undefined.
Before the patch 0 was the invalid value, but as 0 is a valid bus
number, the patch changed this to -1.
However, the fact was missed that many board files do not define the bus
number at all, thus it's left to 0. This causes the driver to fail to
get the i2c bus, exiting from the driver's probe with an error, meaning
that the DVI output does not work for those boards.
This patch fixes the issue by changing the i2c_bus number field in the
driver's platform data from u16 to int, and setting the bus number to -1
in the board files for the boards that did not define the bus. The
exception is devkit8000, for which the bus is set to 1, which is the
correct bus for that board.
The bug exists in v3.5+ kernels.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
Reported-by: Thomas Weber tho...@tomweber.eu
[for v3.5, v3.6 stable kernels]
Cc: sta...@vger.kernel.org
---
arch/arm/mach-omap2/board-3430sdp.c |1 +
arch/arm/mach-omap2/board-am3517evm.c|1 +
arch/arm/mach-omap2/board-cm-t35.c |1 +
arch/arm/mach-omap2/board-devkit8000.c |1 +
arch/arm/mach-omap2/board-omap3evm.c |1 +
arch/arm/mach-omap2/board-omap3stalker.c |1 +
include/video/omap-panel-tfp410.h|2 +-
7 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 96cd369..09e1790 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -157,6 +157,7 @@ static struct omap_dss_device sdp3430_lcd_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
+ .i2c_bus_num= -1,
};
static struct omap_dss_device sdp3430_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-am3517evm.c
b/arch/arm/mach-omap2/board-am3517evm.c
index e162897..f2a920a 100644
--- a/arch/arm/mach-omap2/board-am3517evm.c
+++ b/arch/arm/mach-omap2/board-am3517evm.c
@@ -208,6 +208,7 @@ static struct omap_dss_device am3517_evm_tv_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
+ .i2c_bus_num= -1,
};
static struct omap_dss_device am3517_evm_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 376d26e..7ed0270 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -243,6 +243,7 @@ static struct omap_dss_device cm_t35_lcd_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= CM_T35_DVI_EN_GPIO,
+ .i2c_bus_num= -1,
};
static struct omap_dss_device cm_t35_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 1fd161e..6f04f0f 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -139,6 +139,7 @@ static struct omap_dss_device devkit8000_lcd_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= -1,
+ .i2c_bus_num= 1,
};
static struct omap_dss_device devkit8000_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index b9b776b..5631eb9 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -236,6 +236,7 @@ static struct omap_dss_device omap3_evm_tv_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= OMAP3EVM_DVI_PANEL_EN_GPIO,
+ .i2c_bus_num= -1,
};
static struct omap_dss_device omap3_evm_dvi_device = {
diff --git a/arch/arm/mach-omap2/board-omap3stalker.c
b/arch/arm/mach-omap2/board-omap3stalker.c
index 731235e..797be22 100644
--- a/arch/arm/mach-omap2/board-omap3stalker.c
+++ b/arch/arm/mach-omap2/board-omap3stalker.c
@@ -119,6 +119,7 @@ static struct omap_dss_device omap3_stalker_tv_device = {
static struct tfp410_platform_data dvi_panel = {
.power_down_gpio= DSS_ENABLE_GPIO,
+ .i2c_bus_num= -1,
};
static struct omap_dss_device omap3_stalker_dvi_device = {
diff --git a/include/video/omap-panel-tfp410.h
b/include/video/omap-panel-tfp410.h
index 68c31d7..aef35e4 100644
--- a/include/video/omap-panel-tfp410.h
+++ b/include/video/omap-panel-tfp410.h
@@ -28,7 +28,7 @@ struct omap_dss_device;
* @power_down_gpio: gpio number for PD pin (or -1 if not available)
*/
struct tfp410_platform_data {
- u16 i2c_bus_num;
+ int i2c_bus_num;
int power_down_gpio;
};
--
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
[PATCH v2] usb: dwc3: core: move dwc3_cache_hwparams before dwc3_alloc_event_buffers
commit 392142 (moved event buffer allocation out of dwc3_core_init()). But
event buffer allocation uses the cached copy of hwparams to determine
the number of event buffers and the caching is done in dwc3_core_init.
So moved dwc3_cache_hwparams function before dwc3_alloc_event_buffers so
that dwc3_alloc_event_buffers sees the correct number of event buffers.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
---
Changes from v1:
Added *parens* to the commit message as per Sergei's comments.
drivers/usb/dwc3/core.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index b923183..88e8d31 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -356,8 +356,6 @@ static int __devinit dwc3_core_init(struct dwc3 *dwc)
dwc3_core_soft_reset(dwc);
- dwc3_cache_hwparams(dwc);
-
reg = dwc3_readl(dwc-regs, DWC3_GCTL);
reg = ~DWC3_GCTL_SCALEDOWN_MASK;
reg = ~DWC3_GCTL_DISSCRAMBLE;
@@ -498,6 +496,8 @@ static int __devinit dwc3_probe(struct platform_device
*pdev)
pm_runtime_get_sync(dev);
pm_runtime_forbid(dev);
+ dwc3_cache_hwparams(dwc);
+
ret = dwc3_alloc_event_buffers(dwc, DWC3_EVENT_BUFFERS_SIZE);
if (ret) {
dev_err(dwc-dev, failed to allocate event buffers\n);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] usb: dwc3: core: move dwc3_cache_hwparams before dwc3_alloc_event_buffers
On Fri, Nov 16, 2012 at 10:17:19AM +0200, Felipe Balbi wrote: Hi, On Fri, Nov 16, 2012 at 12:07:54PM +0530, Kishon Vijay Abraham I wrote: commit 392142 moved event buffer allocation out of dwc3_core_init() but event buffer allocation uses the cached copy of hwparams to determine the number of event buffers and the caching is done in dwc3_core_init. So moved dwc3_cache_hwparams function before dwc3_alloc_event_buffers so that dwc3_alloc_event_buffers sees the correct number of event buffers. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com My bad, what a regression I caused :-) Greg, can you take this one ? Yes, will do. -- To unsubscribe from this list: send the line unsubscribe 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] usb: dwc3: core: move dwc3_cache_hwparams before dwc3_alloc_event_buffers
Hello. On 16-11-2012 16:45, Kishon Vijay Abraham I wrote: commit 392142 (moved event buffer allocation out of dwc3_core_init()). But The actual summary is usb: dwc3: core: move event buffer allocation out of dwc3_core_init(). event buffer allocation uses the cached copy of hwparams to determine the number of event buffers and the caching is done in dwc3_core_init. So moved dwc3_cache_hwparams function before dwc3_alloc_event_buffers so that dwc3_alloc_event_buffers sees the correct number of event buffers. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Felipe Balbi ba...@ti.com 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: [PATCH] usb: dwc3: core: move dwc3_cache_hwparams before dwc3_alloc_event_buffers
On Fri, Nov 16, 2012 at 04:47:11AM -0800, Greg KH wrote: On Fri, Nov 16, 2012 at 10:17:19AM +0200, Felipe Balbi wrote: Hi, On Fri, Nov 16, 2012 at 12:07:54PM +0530, Kishon Vijay Abraham I wrote: commit 392142 moved event buffer allocation out of dwc3_core_init() but event buffer allocation uses the cached copy of hwparams to determine the number of event buffers and the caching is done in dwc3_core_init. So moved dwc3_cache_hwparams function before dwc3_alloc_event_buffers so that dwc3_alloc_event_buffers sees the correct number of event buffers. Signed-off-by: Kishon Vijay Abraham I kis...@ti.com My bad, what a regression I caused :-) Greg, can you take this one ? Yes, will do. thanks a lot ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH v2] usb: dwc3: core: move dwc3_cache_hwparams before dwc3_alloc_event_buffers
On Fri, Nov 16, 2012 at 05:06:38PM +0400, Sergei Shtylyov wrote: Hello. On 16-11-2012 16:45, Kishon Vijay Abraham I wrote: commit 392142 (moved event buffer allocation out of dwc3_core_init()). But The actual summary is usb: dwc3: core: move event buffer allocation out of dwc3_core_init(). too late for that. Already on Greg's tree. Let's just hope this won' repeat on upcoming patches ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] OMAP: board-files: fix i2c_bus for tfp410
Hi, On Fri, Nov 16, 2012 at 02:22:33PM +0200, Tomi Valkeinen wrote: The i2c handling in tfp410 driver, which handles converting parallel RGB to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af. The commit summary should be added in () after commit hash. This would look like: 'was changed in 958f271 (OMAPDSS: TFP410: pdata rewrite).' patch changed what value the driver considers as invalid/undefined. Before the patch 0 was the invalid value, but as 0 is a valid bus ^ missing comma (,) character here. number, the patch changed this to -1. However, the fact was missed that many board files do not define the bus number at all, thus it's left to 0. This causes the driver to fail to get the i2c bus, exiting from the driver's probe with an error, meaning that the DVI output does not work for those boards. This patch fixes the issue by changing the i2c_bus number field in the driver's platform data from u16 to int, and setting the bus number to -1 in the board files for the boards that did not define the bus. The exception is devkit8000, for which the bus is set to 1, which is the correct bus for that board. The bug exists in v3.5+ kernels. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Reported-by: Thomas Weber tho...@tomweber.eu [for v3.5, v3.6 stable kernels] Cc: sta...@vger.kernel.org This format is peculiar. Usually people use: Cc: sta...@vger.kernel.org # v3.5 v3.6 To be fair, the whole i2c_bus_num looks like a big hackery introduced by the way panel drivers are written for OMAP DSS. TFP410 is an I2C client, not an OMAPDSS client. After a quick look at the driver, there's is no such thing as a DSS bus, so looks like you should have an I2C driver for TFP410 and the whole DSS stuff should be just a list of clients, but not a struct bus at all. The fact that you have to pass the I2C bus number down to the panel driver is already a big indication of how wrong this is, IMHO. -- balbi signature.asc Description: Digital signature
Re: [PATCH] drm/omap: use omapdss low level API
On Fri, Nov 16, 2012 at 12:44 AM, Archit Taneja arc...@ti.com wrote:
On Friday 16 November 2012 05:30 AM, Rob Clark wrote:
+static void omap_crtc_set_lcd_config(struct omap_overlay_manager *mgr,
+ const struct dss_lcd_mgr_config *config)
+{
+ struct omap_crtc *omap_crtc = container_of(mgr, struct omap_crtc,
mgr);
+ DBG(%s, omap_crtc-name);
+ dispc_mgr_set_lcd_config(omap_crtc-channel, config);
Maybe you should move this dispc write also to omap_crtc_pre_apply, the same
way it's done for timings. We'll also be confident about having the clocks
required if this is called in pre_apply.
That was the first thing I had tried, although the order doesn't
really work out well and lcd config ends up getting set on the n+1'th
apply. Currently this is only called indirectly from
omap_encoder_set_enabled() - dssdrv-enable() which always happens on
apply worker. In fact no dispc or dssdev fxn that changes state is
called outside of apply worker. (Only things like detect and reading
edid are happening outside of apply worker.)
When we get to the point of having more sophisticated panel drivers,
these callbacks from the panel are probably going to need some sort of
if (is_in_apply_worker()) sort of check.
+static void apply_worker(struct work_struct *work)
+{
+ struct omap_crtc *omap_crtc =
+ container_of(work, struct omap_crtc, apply_work);
+ struct drm_crtc *crtc = omap_crtc-base;
+ struct drm_device *dev = crtc-dev;
+ struct omap_drm_apply *apply, *n;
+ bool need_apply;
+
+ /*
+* Synchronize everything on mode_config.mutex, to keep
+* the callbacks and list modification all serialized
+* with respect to modesetting ioctls from userspace.
+*/
+ mutex_lock(dev-mode_config.mutex);
+ dispc_runtime_get();
+
+ /*
+* If we are still pending a previous update, wait.. when the
+* pending update completes, we get kicked again.
+*/
+ if (omap_crtc-apply_irq.registered)
+ goto out;
+
+ /* finish up previous apply's: */
+ list_for_each_entry_safe(apply, n,
+ omap_crtc-pending_applies, pending_node) {
+ apply-post_apply(apply);
+ list_del(apply-pending_node);
+ }
+
+ need_apply = !list_empty(omap_crtc-queued_applies);
+
+ /* then handle the next round of of queued apply's: */
+ list_for_each_entry_safe(apply, n,
+ omap_crtc-queued_applies, queued_node) {
+ apply-pre_apply(apply);
+ list_del(apply-queued_node);
+ apply-queued = false;
+ list_add_tail(apply-pending_node,
+ omap_crtc-pending_applies);
+ }
+
+ if (need_apply) {
+ enum omap_channel channel = omap_crtc-channel;
+
+ DBG(%s: GO, omap_crtc-name);
+
+ if (dispc_mgr_is_enabled(channel)) {
+ omap_irq_register(dev, omap_crtc-apply_irq);
+ dispc_mgr_go(channel);
+ } else if (!dispc_mgr_go_busy(channel)) {
I'm not clear about this. Why would GO be set in the first place if the
manager isn't enabled? This could be replaced with a simple 'else'
Yeah, that extra if should be redundant
+static void omap_crtc_pre_apply(struct omap_drm_apply *apply)
+{
+ struct omap_crtc *omap_crtc =
+ container_of(apply, struct omap_crtc, apply);
+ struct drm_crtc *crtc = omap_crtc-base;
+ struct drm_encoder *encoder = NULL;
+
+ DBG(%s: enabled=%d, full=%d, omap_crtc-name,
+ omap_crtc-enabled, omap_crtc-full_update);
+
+ if (omap_crtc-full_update) {
If I get it right, full_update refers to manager properties that previously
used to propogate downstream from the output driver to dispc, i.e, things
like timings and so on. and the ones which aren't full_update are upstream
properties like transparency keys, default_color and so on?
Well, it basically means power or timings have changed. So it means
closer to full modeset vs pageflip.
But this function does deal with one mismatch between DRM and DSS.. in
DRM, everything gets setup in crtc - downstream order, whereas
omapdss to accommodate more sophisticated panels does things in the
reverse order. So the crtc here propagates timing/power state change
to the encoder (which may turn into mgr op callbacks), rather than
relying on the encoder-helper fxn ptrs called from KMS.
And in fact other DRM drivers will need the same thing eventually if
they are to support the common panel/display framework. So I think
eventually a new / alternate set of crtc helpers (at least
drm_crtc_helper_set_{config,mode})()) will be needed. But I think it
would be easier to introduce after the atomic modeset changes.
Re: [PATCHv3] i2c: omap: Move the remove constraint
On Thu, Nov 15, 2012 at 02:19:21PM +0530, Shubhrajyoti D wrote: Currently we just queue the transfer and release the qos constraints, however we do not wait for the transfer to complete to release the constraint. Move the remove constraint after the bus busy as we are sure that the transfers are completed by then. Acked-by: Jean Pihet j-pi...@ti.com Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com Applied to for-next. Please let me know if it should go to for-current. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] OMAP: board-files: fix i2c_bus for tfp410
On 2012-11-16 15:51, Felipe Balbi wrote: Hi, On Fri, Nov 16, 2012 at 02:22:33PM +0200, Tomi Valkeinen wrote: The i2c handling in tfp410 driver, which handles converting parallel RGB to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af. The commit summary should be added in () after commit hash. This would look like: 'was changed in 958f271 (OMAPDSS: TFP410: pdata rewrite).' Yep. patch changed what value the driver considers as invalid/undefined. Before the patch 0 was the invalid value, but as 0 is a valid bus ^ missing comma (,) character here. Right. number, the patch changed this to -1. However, the fact was missed that many board files do not define the bus number at all, thus it's left to 0. This causes the driver to fail to get the i2c bus, exiting from the driver's probe with an error, meaning that the DVI output does not work for those boards. This patch fixes the issue by changing the i2c_bus number field in the driver's platform data from u16 to int, and setting the bus number to -1 in the board files for the boards that did not define the bus. The exception is devkit8000, for which the bus is set to 1, which is the correct bus for that board. The bug exists in v3.5+ kernels. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Reported-by: Thomas Weber tho...@tomweber.eu [for v3.5, v3.6 stable kernels] Cc: sta...@vger.kernel.org This format is peculiar. Usually people use: Cc: sta...@vger.kernel.org # v3.5 v3.6 Yes, I tried that. But my git send-email (1.7.10.4) rejects that line. I don't know if it's my setup, that particular git version, or what... To be fair, the whole i2c_bus_num looks like a big hackery introduced by the way panel drivers are written for OMAP DSS. TFP410 is an I2C client, not an OMAPDSS client. After a quick look at the driver, there's is no such thing as a DSS bus, so looks like you should have an I2C driver for TFP410 and the whole DSS stuff should be just a list of clients, but not a struct bus at all. The fact that you have to pass the I2C bus number down to the panel driver is already a big indication of how wrong this is, IMHO. Without going deeper in the dss device model problems, I would agree with you if this was about i2c panel, but this is not quite like that. A panel controlled via i2c would be an i2c device. But TFP410 is not controlled via i2c. It's not really controlled at all except via power-down gpio. TFP410 doesn't need the i2c to be functional at all. The i2c lines do not even touch TFP410 chip, so to be precise, the i2c lines should not be TFP410's concern. The i2c lines come from the monitor and go to OMAP's i2c pins. But TFP410 driver is a convenient place to manage them. (As a side note, TFP410 _could_ be controlled via i2c, if it would've been setup so in the board hardware. That would be totally different thing, though, than what's discussed here.). Anyway, this patch wasn't meant to fix dss device model problems. It's meant to fix a bug in the kernel. Tomi signature.asc Description: OpenPGP digital signature
USB only powered Beaglebone powers off when ethernet cable is connected
Hello, Interesting, but Beaglebone powers off on the boot in case when the board is powered only via USB and ethernet cable is connected. It looks like PMIC turns off all voltages on the board - even Power LED doesn't light and USB device disappears from the host. The described situation doesn't show with an external PSU or without ethernet cable. I don't think that is a hardware problem because the board boots fine with a kernel/userland config from original supplied TF card. I use the current git kernel with DTS and omap2plus_defconfig. Regards, Igor. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/13] MFD: twl drivers: Convert to regmap IO and cleanups
Hi Peter / Samuel, I just tested this set on omap3beagle + omap4460 panda boards and both seem to work fine. Did a boot + simple PM test for both to see that regulator control (which is using the I2C related stuff you have changed) works. Also, looking at the code everything seems to be okay to me, thus for whole set: Acked-by: Tero Kristo t-kri...@ti.com On Tue, 2012-11-13 at 09:28 +0100, Peter Ujfalusi wrote: Hello, This series converts the twl-core to use regmap for IO towards the chip. With the conversion to regmap IO we no longer need to allocate bigger buffer for writes. I have appended patches to this series to make some cleanups which will help in the future to further clean up the twl stack. The series depends on a regression fix patch for the twl-core: https://patchwork.kernel.org/patch/1679421/ Regards, Peter --- Peter Ujfalusi (13): MFD: twl-core: Register twl4030-madc child only for twl4030 class MFD: twl-core: Support for proper PWM drivers MFD: twl-core: Convert to use regmap for I/O MFD/rtc/gpio: twl: No need to allocate bigger buffer for write MFD: twl-core: Clean up and correct child registration mfd: twl: Remove unused TWL_MODULE definitions mfd: twl: Convert module id definitions to enums mfd: twl: Use decimal numbers for TWL6030_MODULE_IDs MFD: twl-core: re-group the twl_mapping table for easier reading mfd: twl4030-madc: Change TWL4030_MODULE_* ids to TWL_MODULE_* mfd: twl4030-power: Change TWL4030_MODULE_* ids to TWL_MODULE_* mfd: twl4030-irq: Change TWL4030_MODULE_* ids to TWL_MODULE_* mfd: twl-core: Change TWL4030_MODULE_* ids to TWL_MODULE_* drivers/gpio/gpio-twl4030.c | 12 +-- drivers/mfd/twl-core.c | 227 +++- drivers/mfd/twl4030-irq.c | 10 +- drivers/mfd/twl4030-madc.c | 14 +-- drivers/mfd/twl4030-power.c | 124 ++-- drivers/mfd/twl6030-irq.c | 4 +- drivers/rtc/rtc-twl.c | 32 +++ include/linux/i2c/twl.h | 73 +++--- 8 files changed, 241 insertions(+), 255 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP2+: Fix compiler warning for 32k timer
On 11/16/2012 01:52 AM, Felipe Balbi wrote:
Hi,
On Thu, Nov 15, 2012 at 03:35:47PM -0600, Jon Hunter wrote:
On 11/15/2012 02:45 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 15, 2012 at 01:44:04PM -0600, Jon Hunter wrote:
+static struct of_device_id omap_counter_match[] __initdata = {
not directly related to $SUBJECT, but shouldn't this be static const
__initconst ?
Yes you are right. Looks like there are several other of_device_id
structs in arch/arm/mach-omap2 that could be updated to const too.
here's a quick sed substitution for you:
$ sed -i 's/static \(struct
of_device_id\)\s\(\w\+\[\]\)\s\(__initdata\|\)/static const \1 \2
__initconst/' arch/arm/*omap*/*.c
It worked fine here.
Thanks. Will fix this up in a subsequent patch.
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: board-files: fix i2c_bus for tfp410
Hi, On Fri, Nov 16, 2012 at 04:27:01PM +0200, Tomi Valkeinen wrote: On 2012-11-16 15:51, Felipe Balbi wrote: Hi, On Fri, Nov 16, 2012 at 02:22:33PM +0200, Tomi Valkeinen wrote: The i2c handling in tfp410 driver, which handles converting parallel RGB to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af. The commit summary should be added in () after commit hash. This would look like: 'was changed in 958f271 (OMAPDSS: TFP410: pdata rewrite).' Yep. patch changed what value the driver considers as invalid/undefined. Before the patch 0 was the invalid value, but as 0 is a valid bus ^ missing comma (,) character here. Right. number, the patch changed this to -1. However, the fact was missed that many board files do not define the bus number at all, thus it's left to 0. This causes the driver to fail to get the i2c bus, exiting from the driver's probe with an error, meaning that the DVI output does not work for those boards. This patch fixes the issue by changing the i2c_bus number field in the driver's platform data from u16 to int, and setting the bus number to -1 in the board files for the boards that did not define the bus. The exception is devkit8000, for which the bus is set to 1, which is the correct bus for that board. The bug exists in v3.5+ kernels. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Reported-by: Thomas Weber tho...@tomweber.eu [for v3.5, v3.6 stable kernels] Cc: sta...@vger.kernel.org This format is peculiar. Usually people use: Cc: sta...@vger.kernel.org # v3.5 v3.6 Yes, I tried that. But my git send-email (1.7.10.4) rejects that line. I don't know if it's my setup, that particular git version, or what... weird... I never had that problem, since git 1.6.x, I have never seen that and I tend to upgrade rather frequently. I'm using 1.8.0 now and have sent a few patches to stable recently with no problems. To be fair, the whole i2c_bus_num looks like a big hackery introduced by the way panel drivers are written for OMAP DSS. TFP410 is an I2C client, not an OMAPDSS client. After a quick look at the driver, there's is no such thing as a DSS bus, so looks like you should have an I2C driver for TFP410 and the whole DSS stuff should be just a list of clients, but not a struct bus at all. The fact that you have to pass the I2C bus number down to the panel driver is already a big indication of how wrong this is, IMHO. Without going deeper in the dss device model problems, I would agree with you if this was about i2c panel, but this is not quite like that. A panel controlled via i2c would be an i2c device. But TFP410 is not controlled via i2c. It's not really controlled at all except via power-down gpio. TFP410 doesn't need the i2c to be functional at all. then why does it need the i2c adapter ? What is this power-down gpio ? Should that be hidden under gpiolib instead ? The i2c lines do not even touch TFP410 chip, so to be precise, the i2c lines should not be TFP410's concern. The i2c lines come from the monitor and go to OMAP's i2c pins. But TFP410 driver is a convenient place to manage them. fair enough... but who's actually using those i2c lines ? OMAP is the I2C master, who's the slave ? It's something in the monitor, I assume... IIUC, this I2C bus goes over the HDMI wire ? (As a side note, TFP410 _could_ be controlled via i2c, if it would've been setup so in the board hardware. That would be totally different thing, though, than what's discussed here.). Anyway, this patch wasn't meant to fix dss device model problems. It's meant to fix a bug in the kernel. I understand... should've added that this part wasn't related to $SUBJECT. -- balbi signature.asc Description: Digital signature
Re: [PATCH] OMAP: board-files: fix i2c_bus for tfp410
On 2012-11-16 17:19, Felipe Balbi wrote: Hi, On Fri, Nov 16, 2012 at 04:27:01PM +0200, Tomi Valkeinen wrote: On 2012-11-16 15:51, Felipe Balbi wrote: Hi, On Fri, Nov 16, 2012 at 02:22:33PM +0200, Tomi Valkeinen wrote: The i2c handling in tfp410 driver, which handles converting parallel RGB to DVI, was changed in 958f2717b84e88bf833d996997fda8f73276f2af. The commit summary should be added in () after commit hash. This would look like: 'was changed in 958f271 (OMAPDSS: TFP410: pdata rewrite).' Yep. patch changed what value the driver considers as invalid/undefined. Before the patch 0 was the invalid value, but as 0 is a valid bus ^ missing comma (,) character here. Right. number, the patch changed this to -1. However, the fact was missed that many board files do not define the bus number at all, thus it's left to 0. This causes the driver to fail to get the i2c bus, exiting from the driver's probe with an error, meaning that the DVI output does not work for those boards. This patch fixes the issue by changing the i2c_bus number field in the driver's platform data from u16 to int, and setting the bus number to -1 in the board files for the boards that did not define the bus. The exception is devkit8000, for which the bus is set to 1, which is the correct bus for that board. The bug exists in v3.5+ kernels. Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com Reported-by: Thomas Weber tho...@tomweber.eu [for v3.5, v3.6 stable kernels] Cc: sta...@vger.kernel.org This format is peculiar. Usually people use: Cc: sta...@vger.kernel.org # v3.5 v3.6 Yes, I tried that. But my git send-email (1.7.10.4) rejects that line. I don't know if it's my setup, that particular git version, or what... weird... I never had that problem, since git 1.6.x, I have never seen that and I tend to upgrade rather frequently. I'm using 1.8.0 now and have sent a few patches to stable recently with no problems. To be fair, the whole i2c_bus_num looks like a big hackery introduced by the way panel drivers are written for OMAP DSS. TFP410 is an I2C client, not an OMAPDSS client. After a quick look at the driver, there's is no such thing as a DSS bus, so looks like you should have an I2C driver for TFP410 and the whole DSS stuff should be just a list of clients, but not a struct bus at all. The fact that you have to pass the I2C bus number down to the panel driver is already a big indication of how wrong this is, IMHO. Without going deeper in the dss device model problems, I would agree with you if this was about i2c panel, but this is not quite like that. A panel controlled via i2c would be an i2c device. But TFP410 is not controlled via i2c. It's not really controlled at all except via power-down gpio. TFP410 doesn't need the i2c to be functional at all. then why does it need the i2c adapter ? What is this power-down gpio ? Should that be hidden under gpiolib instead ? For the i2c, see below. Power-down GPIO is used to power down and up the tfp410 chip. The i2c lines do not even touch TFP410 chip, so to be precise, the i2c lines should not be TFP410's concern. The i2c lines come from the monitor and go to OMAP's i2c pins. But TFP410 driver is a convenient place to manage them. fair enough... but who's actually using those i2c lines ? OMAP is the I2C master, who's the slave ? It's something in the monitor, I assume... IIUC, this I2C bus goes over the HDMI wire ? Yes, the i2c goes over HDMI wire. OMAP is the master, monitor is the slave. You can see some more info from http://en.wikipedia.org/wiki/Display_Data_Channel under DDC2 section. It is used to read the EDID (http://en.wikipedia.org/wiki/Extended_display_identification_data) information from the monitor, which tells things like supported video timings etc. As for why the tfp410 driver handles the i2c... We don't have a better place. There's no driver for the monitor. Although in the future with common panel framework perhaps we will. Tomi signature.asc Description: OpenPGP digital signature
Re: [PATCH V6 2/2] dmaengine: add helper function to request a slave DMA channel
On 11/15/2012 07:37 PM, Vinod Koul wrote: On Fri, 2012-11-09 at 14:01 -0600, Jon Hunter wrote: Hi Vinod, A few people have been asking me if getting device-tree support for DMA engine is plan for record for v3.8. I know that you were working through implementing a common interface and so I wanted to check how that is going. Do you have any insight to when device-tree support may get added? I have not been able to do much work on this for last couple of weeks. I hope to do it in by this weekend. If not I will merge yours and then uppdate. Anyway, DT would be there in 3.8 with or without my changes. Thanks, Vinod. Can you make sure you also pick up the two fixes [1][2] I sent out? Cheers Jon [1] http://marc.info/?l=linux-omapm=134859981920598w=2 [2] http://marc.info/?l=linux-omapm=134998461526129w=2 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 02/16] ARM: davinci: move private EDMA API to arm/common
On Sun, Oct 28, 2012 at 01:47:09PM +0530, Sekhar Nori wrote:
On 10/18/2012 6:56 PM, Matt Porter wrote:
Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well. This just moves the
private EDMA API but does not support OMAP.
Signed-off-by: Matt Porter mpor...@ti.com
---
diff --git a/arch/arm/mach-davinci/devices.c
b/arch/arm/mach-davinci/devices.c
index 4c48a36..f45d591 100644
--- a/arch/arm/mach-davinci/devices.c
+++ b/arch/arm/mach-davinci/devices.c
@@ -19,9 +19,10 @@
#include mach/irqs.h
#include mach/cputype.h
#include mach/mux.h
-#include mach/edma.h
#include linux/platform_data/mmc-davinci.h
#include mach/time.h
+#include linux/platform_data/edma.h
Can you please introduce a patch to clean this mixture of linux/ and
mach/ includes?
Sure.
+
#include davinci.h
#include clock.h
@@ -141,10 +142,10 @@ static struct resource mmcsd0_resources[] = {
},
/* DMA channels: RX, then TX */
{
- .start = EDMA_CTLR_CHAN(0, DAVINCI_DMA_MMCRXEVT),
+ .start = EDMA_CTLR_CHAN(0, 26),
Instead of just replacing the event #defines with plain numbers, can you
introduce a mach-davinci local edma.h which can then be included in the
davinci platform files which refer to edma channel numbers?
Yes.
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 7cd56ed..153fab8 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -28,6 +28,7 @@ config ARCH_OMAP2PLUS
select OMAP_DM_TIMER
select PROC_DEVICETREE if PROC_FS
select SPARSE_IRQ
+ select TI_PRIV_EDMA
This hunk does not seem to belong to subject of this patch.
Yep, stray hunk..will move to the am335x enablement.
select USE_OF
help
Systems based on OMAP2, OMAP3, OMAP4 or OMAP5
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
new file mode 100644
index 000..7396f0b3
--- /dev/null
+++ b/include/linux/platform_data/edma.h
@@ -0,0 +1,198 @@
+/*
+ * TI DAVINCI dma definitions
+ *
+ * Copyright (C) 2006-2009 Texas Instruments.
+ *
+ * This program is free software; you can redistribute it and/or modify
it
+ * under the terms of the GNU General Public License as published by
the
+ * Free Software Foundation; either version 2 of the License, or (at
your
+ * option) any later version.
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF
+ * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN
+ * NO EVENT SHALL THE AUTHOR BELIABLE FOR ANY DIRECT, INDIRECT,
+ * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS
OF
+ * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON
+ * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR
TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF
+ * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ * You should have received a copy of the GNU General Public License
along
+ * with this program; if not, write to the Free Software Foundation,
Inc.,
+ * 675 Mass Ave, Cambridge, MA 02139, USA.
This part can be dropped, I suppose ;-)
Ok :)
-Matt
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
* Russell King - ARM Linux li...@arm.linux.org.uk [121116 02:07]: So, we don't detect whether we're running in secure mode or not; as I've already stated, we don't have a way to do that. We instead only apply work-arounds which aren't already enabled prior to the kernel booting. So, even on a secure mode platform, we will avoid writing the bits if the work-around has already been applied. This all assumes that we can read the value of the diagnostic register, and on my 4430 blaze the read returns zero. I have no idea if this is the correct value for the register, or if reads always just returns 0. If we can verify that the read of the diagnostic register returns the correct value, then we don't need to test for the secure mode like you are saying, and can require the bootrom or bootloader set the right bits. Can somebody confirm that reading of the diagnostic register without using SMI is supposed to return the correct value? 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] Remove inline from clock framework function definitions to build the kernel with GCC 4.7
Paul Walmsley wrote: + Mike On Thu, 15 Nov 2012, Igor Mazanov wrote: Remove inline from clock framework function definitions to build the kernel with GCC 4.7 sparse warns about this also. Signed-off-by: Igor Mazanov i.maza...@gmail.com This one is for Mike to deal with as CCF maintainer; it's out of the hands of the OMAP folks. Thanks for comments, I'll bear in mind it for the future. Acked-by: Paul Walmsley p...@pwsan.com --- include/linux/clk-provider.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index c127315..f9f5e9e 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -335,8 +335,8 @@ const char *__clk_get_name(struct clk *clk); struct clk_hw *__clk_get_hw(struct clk *clk); u8 __clk_get_num_parents(struct clk *clk); struct clk *__clk_get_parent(struct clk *clk); -inline int __clk_get_enable_count(struct clk *clk); -inline int __clk_get_prepare_count(struct clk *clk); +int __clk_get_enable_count(struct clk *clk); +int __clk_get_prepare_count(struct clk *clk); unsigned long __clk_get_rate(struct clk *clk); unsigned long __clk_get_flags(struct clk *clk); int __clk_is_enabled(struct clk *clk); -- 1.7.4.4 - 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 v2 1/2] ARM: OMAP2+: HDMI: Relocate audio platform device creation
Hi Tomi, On 11/16/2012 01:38 AM, Tomi Valkeinen wrote: Hi, On 2012-11-16 03:36, Ricardo Neri wrote: Creating the accessory devices (such as audio) from the HDMI driver, allows to regard HDMI as a single entity with audio an display functionality. This intends to follow the design of drivers such as MFD-type, in which a single entity handles the creation of the accessory devices. Such devices are then used by domain-specific drivers (audio in this case). This is in line with the DT implementation of HDMI, in which we will have a single node to describe this feature of the OMAP SoC. Otherwise, we would need to have separate nodes for audio and video functionality. Previously, the platform device for the audio driver was created in arch/arm/mach-omap2/devices.c. Thus, this is removed. Also, as the platform device for audio created by the OMAPDSS HDMI now provides a resource for the DMA port for audio samples, we do not need to specify any offset in the ASoC HDMI CPU DAI driver. If you notice yourself writing also, the patch does this in the patch description, it's usually a sign that the patch needs to be split =). :) That's perhaps not so important when a patch only deals with one subsystem or one file, but when the patch changes arch, video and audio drivers at the same time I would like to have the patches as simple as possible. Here I suggest you handle the DMA port change in a separate patch. I went ahead and submitted this part in the same patch to make sure that HDMI audio works in every patch. What I can do is that a first patch creates the platform device for HDMI and just passes the whole register space to the audio platform device to not break ASoC HDMI. Then, a second patch will refine the pdev audio resources and remove the offset from the ASoC HDMI driver. Does that make sense to you? BR, Ricardo Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP: Timer Clean-up
The following changes since commit 9dc57643738f9fbe45c10cc062903d5dfda5bdd9: Merge branch 'fixes-timer' of github.com:jonhunter/linux into omap-for-v3.8/timer (2012-11-13 13:52:38 -0800) are available in the git repository at: git://github.com/jonhunter/linux.git cleanup-timer for you to fetch changes up to 258e84af9799b8c81cf856dcbd8e2d4cc082741d: ARM: OMAP2+: Fix compiler warning for 32k timer (2012-11-16 10:35:09 -0600) Various OMAP timer clean-ups. I have dropped the patch to move dmtimer.h as discussed. I have also included the compilation warning fix for sync-32k reported by Kevin Hilman. Jon Hunter (8): ARM: OMAP: Clean-up dmtimer reset code ARM: OMAP: Define omap_dm_timer_prepare function as static ARM: OMAP: Don't store timers physical address ARM: OMAP2+: Remove unnecessary local variable in timer code ARM: OMAP: Remove unnecessary omap_dm_timer structure declaration ARM: OMAP: Add platform data header for DMTIMERs ARM: OMAP: Remove unnecessary inclusion of dmtimer.h ARM: OMAP2+: Fix compiler warning for 32k timer arch/arm/mach-omap1/timer.c|1 + arch/arm/mach-omap1/timer32k.c |1 - arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 - arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 - arch/arm/mach-omap2/pm-debug.c |1 - arch/arm/mach-omap2/timer.c| 36 ++--- arch/arm/plat-omap/dmtimer.c | 54 --- arch/arm/plat-omap/include/plat/dmtimer.h | 80 drivers/staging/tidspbridge/core/ue_deh.c |1 - include/linux/platform_data/dmtimer-omap.h | 31 +++ 10 files changed, 105 insertions(+), 102 deletions(-) create mode 100644 include/linux/platform_data/dmtimer-omap.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Remove inline from clock framework function definitions to build the kernel with GCC 4.7
Quoting Igor Mazanov (2012-11-16 09:16:02) Paul Walmsley wrote: + Mike On Thu, 15 Nov 2012, Igor Mazanov wrote: Remove inline from clock framework function definitions to build the kernel with GCC 4.7 sparse warns about this also. Signed-off-by: Igor Mazanov i.maza...@gmail.com This one is for Mike to deal with as CCF maintainer; it's out of the hands of the OMAP folks. Thanks for comments, I'll bear in mind it for the future. I forgot to reply to this thread yesterday. A fixes request has been sent out, hopefully will be picked up for 3.7-rc6. Thanks all, Mike Acked-by: Paul Walmsley p...@pwsan.com --- include/linux/clk-provider.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h index c127315..f9f5e9e 100644 --- a/include/linux/clk-provider.h +++ b/include/linux/clk-provider.h @@ -335,8 +335,8 @@ const char *__clk_get_name(struct clk *clk); struct clk_hw *__clk_get_hw(struct clk *clk); u8 __clk_get_num_parents(struct clk *clk); struct clk *__clk_get_parent(struct clk *clk); -inline int __clk_get_enable_count(struct clk *clk); -inline int __clk_get_prepare_count(struct clk *clk); +int __clk_get_enable_count(struct clk *clk); +int __clk_get_prepare_count(struct clk *clk); unsigned long __clk_get_rate(struct clk *clk); unsigned long __clk_get_flags(struct clk *clk); int __clk_is_enabled(struct clk *clk); -- 1.7.4.4 - 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] omap2/ompafb/omapfb-main.c: Delete if evaluating constant.
Variable r is never set to any value different to zero.
Delete the if statement as it will never executed.
Signed-off-by: Matthias Brugger matthias@gmail.com
---
drivers/video/omap2/omapfb/omapfb-main.c |4
1 file changed, 4 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index 16db158..85f9de0 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2411,7 +2411,6 @@ static int __init omapfb_probe(struct platform_device
*pdev)
fbdev-dev = pdev-dev;
platform_set_drvdata(pdev, fbdev);
- r = 0;
fbdev-num_displays = 0;
dssdev = NULL;
for_each_dss_dev(dssdev) {
@@ -2434,9 +2433,6 @@ static int __init omapfb_probe(struct platform_device
*pdev)
d-update_mode = OMAPFB_AUTO_UPDATE;
}
- if (r)
- goto cleanup;
-
if (fbdev-num_displays == 0) {
dev_err(pdev-dev, no displays\n);
r = -EINVAL;
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/2] ARM: OMAP4+: HDMI: Rearrange platform devices for ASoC drivers
On 11/16/2012 01:52 AM, Tomi Valkeinen wrote:
On 2012-11-16 03:36, Ricardo Neri wrote:
This relocates and renames the platform devices for ASoC HDMI drivers
to give them a more logical structure.
The previous omap-hdmi-audio device is renamed as omap-hdmi-audio-card
and is relocated to the SDP4430 and Pandaboard board files. This is to
better illustrate the fact that it describes the whole HDMI audio
functionality on such boards, including the companion chip.
The previous omap-hdmi-audio-dai is renamed as omap-hdmi-audio. The -dai
part is removed to not have references to ASoC concepts in the OMAPDSS
HDMI driver. Also, as it will be used by the ASoC HDMI CPU DAI driver,
the name refers only to OMAP HDMI audio functionality, irrespective of the
board.
The names of the ASoC drivers are also updated accordingly.
And same thing here as with the previous patch. Do the move and rename
in separate patches for clarity.
OK. I'll do.
Signed-off-by: Ricardo Neri ricardo.n...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c|6 ++
arch/arm/mach-omap2/board-omap4panda.c |6 ++
arch/arm/mach-omap2/devices.c | 17 -
drivers/video/omap2/dss/hdmi.c |2 +-
sound/soc/omap/omap-hdmi-card.c|4 ++--
sound/soc/omap/omap-hdmi.c |2 +-
6 files changed, 16 insertions(+), 21 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 3669c12..97bdff3 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -388,6 +388,11 @@ static struct platform_device sdp4430_hdmi_audio_codec = {
.id = -1,
};
+static struct platform_device sdp4430_hdmi_audio_card = {
+ .name = omap-hdmi-audio-card,
+ .id = -1,
+};
+
static struct omap_abe_twl6040_data sdp4430_abe_audio_data = {
.card_name = SDP4430,
.has_hs = ABE_TWL6040_LEFT | ABE_TWL6040_RIGHT,
@@ -423,6 +428,7 @@ static struct platform_device *sdp4430_devices[] __initdata
= {
sdp4430_dmic_codec,
sdp4430_abe_audio,
sdp4430_hdmi_audio_codec,
+ sdp4430_hdmi_audio_card,
};
I don't know anything at all about the audio drivers, but this doesn't
feel good to me. The HDMI audio is tied to the HDMI video, both of which
are parts of OMAP SoC. So if you have two boards with HDMI video (and
thus audio), the device data related to HDMI video and audio are
identical except for a few HW details like the GPIOs for the TPD chip.
So is there any reason to add hdmi audio devices in each board file? It
sounds to me that a common place to add the device for all boards would
make more sense. This could, perhaps, be arch/arm/mach-omap2/display.c
which handles adding the HDMI device, or some other similar file
(although you just removed it from such a file, the devices.c...).
In ASoC, we have three drivers for ASoC HDMI audio. The CPU-DAI driver
deals with the CPU audio interface. So, I regard the OMAP HDMI IP as the
CPU DAI. A device is needed to probe the driver, but as HDMI audio and
video are the same physical component, it made sense to have the HDMI
video driver to create it. Furthermore, except for the TPD handling the
HDMI driver deals only with OMAP stuff. Also, we will have a single node
for HDMI when DT comes. Thus, the device for the ASoC CPU DAI has to be
created somewhere.
We also have codec. ASoC codecs are chips like TWL6040 that
render/capture audio. For ASoC HDMI, a TV or a home theater unit could
be regarded as the codec. Strictly speaking, it is not a device mounted
on the board such as TWL6040 but does the same work and we have to
represent it for ASoC to use.
Finally we have the ASoC machine (or board) driver, that glues together
the DAI and codec.
And actually, why isn't the card driver added in the hdmi video driver,
like the omap-hdmi-audio-dai?
The card driver represents a board. It made sense to me to relocate it
into the board files. Furthermore, when HDMI DT is supported in the
feature, the node for this machine driver will be in the DT; so, we will
not needed and we would end up relocating it anyways.
You say the omap-hdmi-audio-card covers also the TPD chip, but why does
HDMI audio even need to cover that chip? It has no relevance to the
audio side, as long as the video driver enables it properly, right?
Yes, audio does not have anything to do with the TPD chip, but we do
need an ASoC machine driver. Thus, the only components that are there to
describe an ASoC machine driver are the OMAP, TPD and the HDMI
connector. Indeed, to not tie the ASoC machine driver to a specific
companion chip (as commented by Liam), I just used the -card suffix.
Perhaps I'm missing something here, as I don't have any knowledge of the
audio side, though. What do the different audio devices represent?
I hope the explanation above provides more clarity to you. I think HDMI
does not fit
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
On Fri, Nov 16, 2012 at 09:59:21AM +, Russell King - ARM Linux wrote: On Thu, Nov 15, 2012 at 08:31:33AM -0600, Rob Herring wrote: So we should make all these work-arounds depend on !MULTI_PLATFORM then. No, because some of the work-arounds don't require setting bits in magic registers. Also realise this: we test for the revision of the CPU to which they're applicable before attempting to set them. If you have a work-around enabled in the kernel, and it fails at boot, _that_ is an indicator not that the kernel is doing something wrong, but that you need to ensure that the work-around has been applied by the earlier stages. It's not about but platform X doesn't need it - it's about platform X not having the earlier stages updated to fix the errata. There is another aspect. Many CPUs in the field, even if they are a certain rxpy revision, have ECO fixes applied for critical bugs and don't require the workaround. Sometimes those undocumented bits have considerable performance impact and vendors may apply an ECO (unless they are very late in the tape-out process). But the ECO fix does not change the CPU revision, hence the workaround becomes platform specific. That's why I think it's better if those workarounds are just pushed to the boot-loader for multi-platform kernels. Linux could still check the bits and warn about them rather than failing to boot. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
tfp410 and i2c_bus_num (was: Re: [PATCH] OMAP: board-files: fix i2c_bus for tfp410)
Hi, On Fri, Nov 16, 2012 at 05:39:44PM +0200, Tomi Valkeinen wrote: To be fair, the whole i2c_bus_num looks like a big hackery introduced by the way panel drivers are written for OMAP DSS. TFP410 is an I2C client, not an OMAPDSS client. After a quick look at the driver, there's is no such thing as a DSS bus, so looks like you should have an I2C driver for TFP410 and the whole DSS stuff should be just a list of clients, but not a struct bus at all. The fact that you have to pass the I2C bus number down to the panel driver is already a big indication of how wrong this is, IMHO. Without going deeper in the dss device model problems, I would agree with you if this was about i2c panel, but this is not quite like that. A panel controlled via i2c would be an i2c device. But TFP410 is not controlled via i2c. It's not really controlled at all except via power-down gpio. TFP410 doesn't need the i2c to be functional at all. then why does it need the i2c adapter ? What is this power-down gpio ? Should that be hidden under gpiolib instead ? For the i2c, see below. Power-down GPIO is used to power down and up the tfp410 chip. that much I guessed ;-) Should it be hidden under gpiolib ? The i2c lines do not even touch TFP410 chip, so to be precise, the i2c lines should not be TFP410's concern. The i2c lines come from the monitor and go to OMAP's i2c pins. But TFP410 driver is a convenient place to manage them. fair enough... but who's actually using those i2c lines ? OMAP is the I2C master, who's the slave ? It's something in the monitor, I assume... IIUC, this I2C bus goes over the HDMI wire ? Yes, the i2c goes over HDMI wire. OMAP is the master, monitor is the slave. You can see some more info from http://en.wikipedia.org/wiki/Display_Data_Channel under DDC2 section. It is used to read the EDID (http://en.wikipedia.org/wiki/Extended_display_identification_data) information from the monitor, which tells things like supported video timings etc. As for why the tfp410 driver handles the i2c... We don't have a better place. There's no driver for the monitor. Although in the future with than that's wrong :-) If TFP410 isn't really using I2C it shouldn't need the whole i2c_bus_num logic. I'm far from fully understanding dss architecture but it looks like what you want is a generic 'i2c-edid.c' which just reads the edid structure during probe and caches the values and exposes them via sysfs ?!? (perhaps you also need a kernel API to read those values... I don't know; but that's also doable). If you have a generic i2c-edid.c simple driver, I guess X could be changes to read those values from sysfs and take actions based on those. Looks like even drm_edid.c should change, btw. common panel framework perhaps we will. ok, good ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
On Fri, Nov 16, 2012 at 06:09:28PM +, Catalin Marinas wrote: On Fri, Nov 16, 2012 at 09:59:21AM +, Russell King - ARM Linux wrote: On Thu, Nov 15, 2012 at 08:31:33AM -0600, Rob Herring wrote: So we should make all these work-arounds depend on !MULTI_PLATFORM then. No, because some of the work-arounds don't require setting bits in magic registers. Also realise this: we test for the revision of the CPU to which they're applicable before attempting to set them. If you have a work-around enabled in the kernel, and it fails at boot, _that_ is an indicator not that the kernel is doing something wrong, but that you need to ensure that the work-around has been applied by the earlier stages. It's not about but platform X doesn't need it - it's about platform X not having the earlier stages updated to fix the errata. There is another aspect. Many CPUs in the field, even if they are a certain rxpy revision, have ECO fixes applied for critical bugs and don't require the workaround. Sometimes those undocumented bits have considerable performance impact and vendors may apply an ECO (unless they are very late in the tape-out process). But the ECO fix does not change the CPU revision, hence the workaround becomes platform specific. That's why I think it's better if those workarounds are just pushed to the boot-loader for multi-platform kernels. Linux could still check the bits and warn about them rather than failing to boot. ... and that's a U-turn if ever there was one... it's ARM Ltd who've been pushing to have these work-arounds in the kernel in the first place. Should we just remove all the work-arounds, and require boot loaders, including the one on Versatile platforms, to implement this? Why should we treat secure platforms be any different from the non-secure ones in this regard? After all, this _does_ stand in the way of a single kernel image working properly on secure and non-secure platforms. The more this thread progresses, the more I think the decision to put errata into the kernel was the wrong one. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: Fix errata 751472 handling on Cortex-A9 r1p*
On Fri, Nov 16, 2012 at 09:13:33AM -0800, Tony Lindgren wrote: * Russell King - ARM Linux li...@arm.linux.org.uk [121116 02:07]: So, we don't detect whether we're running in secure mode or not; as I've already stated, we don't have a way to do that. We instead only apply work-arounds which aren't already enabled prior to the kernel booting. So, even on a secure mode platform, we will avoid writing the bits if the work-around has already been applied. This all assumes that we can read the value of the diagnostic register, and on my 4430 blaze the read returns zero. I have no idea if this is the correct value for the register, or if reads always just returns 0. ARM Ltd has made that assumption since the inception of the errata work-arounds appearing in the kernel for v6+ CPUs... But your question may prove to be moot if we end up ripping all these out, like I'm beginning to think we should do. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/4] mfd: tps65217: Set PMIC to shutdowm on PWR_EN toggle
AnilKumar Ch anilku...@ti.com writes:
From: Colin Foe-Parker colin.foepar...@logicpd.com
Set tps65217 PMIC status to OFF if power enable toggle is
supported. Also adds platform data flag, which should be
passed from board init data.
nit: changelog mentions platform_data, but the code is using DT.
Kevin
Signed-off-by: Colin Foe-Parker colin.foepar...@logicpd.com
[anilku...@ti.com: move the additions to tps65217 MFD driver]
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
.../devicetree/bindings/regulator/tps65217.txt |4
drivers/mfd/tps65217.c | 12
2 files changed, 16 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt
b/Documentation/devicetree/bindings/regulator/tps65217.txt
index d316fb8..4f05d20 100644
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
@@ -11,6 +11,9 @@ Required properties:
using the standard binding for regulators found at
Documentation/devicetree/bindings/regulator/regulator.txt.
+Optional properties:
+- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
+
The valid names for regulators are:
tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
@@ -20,6 +23,7 @@ Example:
tps: tps@24 {
compatible = ti,tps65217;
+ ti,pmic-shutdown-controller;
regulators {
dcdc1_reg: dcdc1 {
diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
index 3fb32e6..c7f17d8 100644
--- a/drivers/mfd/tps65217.c
+++ b/drivers/mfd/tps65217.c
@@ -160,6 +160,7 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
unsigned int version;
unsigned int chip_id = ids-driver_data;
const struct of_device_id *match;
+ bool status_off = false;
int ret;
if (client-dev.of_node) {
@@ -170,6 +171,8 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
return -EINVAL;
}
chip_id = (unsigned int)match-data;
+ status_off = of_property_read_bool(client-dev.of_node,
+ ti,pmic-shutdown-controller);
}
if (!chip_id) {
@@ -207,6 +210,15 @@ static int __devinit tps65217_probe(struct i2c_client
*client,
return ret;
}
+ /* Set the PMIC to shutdown on PWR_EN toggle */
+ if (status_off) {
+ ret = tps65217_set_bits(tps, TPS65217_REG_STATUS,
+ TPS65217_STATUS_OFF, TPS65217_STATUS_OFF,
+ TPS65217_PROTECT_NONE);
+ if (ret)
+ dev_warn(tps-dev, unable to set the status OFF\n);
+ }
+
dev_info(tps-dev, TPS65217 ID %#x version 1.%d\n,
(version TPS65217_CHIPID_CHIP_MASK) 4,
version TPS65217_CHIPID_REV_MASK);
--
To unsubscribe from this list: send the line unsubscribe 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 4/4] ARM: dts: AM33XX: Enable system power off control in am335x-bone
AnilKumar Ch anilku...@ti.com writes:
Enable system power off control for BeagleBone in am335x-bone.dts file
under rtc node. RTC is the incharge of controlling the system power.
This flag is used by the driver to hook up the pm_power_off system call.
Signed-off-by: AnilKumar Ch anilku...@ti.com
---
arch/arm/boot/dts/am335x-bone.dts |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index 1d55190..206c3eb 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -52,6 +52,10 @@
};
};
+
+ rtc@44e3e000 {
+ ti,system-power-controller;
+ };
};
Also, I think this series is missing a patch that allows the RTC driver
to be compiled on AM335x.
Kevin
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/16] OMAP USB Host cleanup
Roger Quadros rog...@ti.com writes: Hi, This patchset addresses the following - Avoid addressing clocks one by one by name and use a for loop + bunch of cleanups. - Get number of channels/ports dynamically either from revision register or from platform data. Avoids getting clocks that are not present. - Add OMAP5 and HSIC mode (Not tested) - Save power on Panda when EHCI driver is not loaded. Seeing the clock changes/cleanups, I gave this a spin on OMAP3 (3530/Beagle, 3530/Overo, 3730/Beagle-xM, 3730/OveroSTORM) to see if it fixed up the problem where CORE does not hit retention in idle when USB host is enabled, even with no devices attached. Unfortunately, it didn't help. :( Felipe, Keshava, any plans to address this problem which has been around for a couple cycles now and led me to disable USB host in omap2plus_defconfig?[1] Kevin [1] https://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=06b4ba529528fbf9c24ce37b7618f4b0264750e2 -- To unsubscribe from this list: send the line unsubscribe 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] dmaengine: omap-dma: Allow DMA controller to prefetch data
On Fri, Oct 19, 2012 at 02:45:55PM +0200, Péter Ujfalusi wrote:
Hi,
On 10/19/2012 01:33 AM, Russell King - ARM Linux wrote:
I would suggest getting some feedback from the ASoC people first, before
trying to invent new APIs to work around this stuff. If they can live
with having prefetch enabled on OMAP then there isn't an issue here. If
not, we need a solution to this.
I do not believe that precisely stopping and starting playback across a
suspend/resume event is really necessary (it's desirable but the world
doesn't collapse if you miss a few samples.) It could be more of an
issue for pause/resume though, but as I say, that's for ASoC people to
comment on.
There is another issue with the prefetch in audio:
we tend to like to know the position of the DMA and also to know how much data
we have stored in buffers, FIFOs. This information is used by userspace to do
echo cancellation and also used by PA for example to do runtime mixing
directly in the audio buffer. We have means to extract this information from
McBSP for example (and from tlv320dac33 codec) but AFAIK this information can
not be retrieved from sDMA.
We could assume that the sDMA FIFO is kept full and report that as a 'delay'
or do not account this information.
For now I think the cyclic mode should not set the prefetch. If I recall right
the cyclic mode is only used by audio at the moment.
I'm merely pointing out here that we need their feedback here before
deciding if there's anything further that needs to happen.
Thanks Russell, I'll take a look at the implication of the prefetch for audio.
So how about enabling prefetch for just non-cyclic?
---
From 04b4d7b2d940822af501ea8a6bf265098d2c1810 Mon Sep 17 00:00:00 2001
From: Mark A. Greer mgr...@animalcreek.com
Date: Wed, 17 Oct 2012 18:12:21 -0700
Subject: [PATCH] dmaengine: omap-dma: Allow DMA controller to prefetch data
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Enable DMA prefetching for non-cyclic DMAs by setting the
'OMAP_DMA_DST_SYNC_PREFETCH' flag when there is a destination
synchronized DMA transfer. Prefetching is not allowed on
source synchronized DMA transfers. It is not allowed on
cyclic DMAs either since that can cause issues with some
users (e.g., suspending/resuming audio).
CC: rmk+ker...@arm.linux.org.uk
CC: Péter Ujfalusi peter.ujfal...@ti.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/dma/omap-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index bb2d8e7..e660f94 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -310,7 +310,7 @@ static struct dma_async_tx_descriptor
*omap_dma_prep_slave_sg(
dev_addr = c-cfg.dst_addr;
dev_width = c-cfg.dst_addr_width;
burst = c-cfg.dst_maxburst;
- sync_type = OMAP_DMA_DST_SYNC;
+ sync_type = OMAP_DMA_DST_SYNC | OMAP_DMA_DST_SYNC_PREFETCH;
} else {
dev_err(chan-device-dev, %s: bad direction?\n, __func__);
return NULL;
--
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 v3 7/7] crypto: omap_sham: Remove usage of private DMA API
On Wed, Nov 14, 2012 at 09:47:55AM -0700, Mark A. Greer wrote: On Tue, Nov 13, 2012 at 11:47:57PM -0800, Kasatkin, Dmitry wrote: On Fri, Nov 9, 2012 at 9:17 AM, Mark A. Greer mgr...@animalcreek.com wrote: On Fri, Nov 09, 2012 at 06:28:16PM +0200, Kasatkin, Dmitry wrote: On Wed, Nov 7, 2012 at 4:57 AM, Mark A. Greer mgr...@animalcreek.com wrote: From: Mark A. Greer mgr...@animalcreek.com Remove usage of the private OMAP DMA API. The dmaengine API will be used instead. CC: Russell King rmk+ker...@arm.linux.org.uk CC: Dmitry Kasatkin dmitry.kasat...@intel.com Signed-off-by: Mark A. Greer mgr...@animalcreek.com --- drivers/crypto/omap-sham.c | 117 - 1 file changed, 117 deletions(-) diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c index b57277c..ebb5255 100644 --- a/drivers/crypto/omap-sham.c +++ b/drivers/crypto/omap-sham.c @@ -807,18 +762,6 @@ static int omap_sham_handle_queue(struct omap_sham_dev *dd, if (err) goto err1; -#ifdef OMAP_SHAM_DMA_PRIVATE - omap_set_dma_dest_params(dd-dma_lch, 0, - OMAP_DMA_AMODE_CONSTANT, - dd-phys_base + SHA_REG_DIN(0), 0, 16); - - omap_set_dma_dest_burst_mode(dd-dma_lch, - OMAP_DMA_DATA_BURST_16); - - omap_set_dma_src_burst_mode(dd-dma_lch, - OMAP_DMA_DATA_BURST_4); Burst mode significantly improves performance. How do you configure burst mode with new API? This is (or should be) taken care of by the dmaengine infrastructure. I've noted that there's an issue and there is a discussion about it here: http://www.spinics.net/lists/linux-omap/msg79855.html We probably need to extend the dmaengine API to allow API-users to request specific tweaks/optimizations/whatever but that's MHO. Hello, I am in favor of new APIs. The only my concern is that it performs worse.. Is it possible to keep burst mode setting there? I'm going to respin the patch the I posted in the email thread above to only set bursting for non-cyclic DMAs. Just sent. Should be in your inbox shortly. Mark -- -- To unsubscribe from this list: send the line unsubscribe 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] AM33XX: Clock: Fix JTAG disconnect during kernel boot
Set ENABLE_ON_INIT for debugss clock so that it is on during init and the
usecount is incremented.
Not doing so causes kernel to disable debugss clock to save power when
CONFIG_OMAP_RESET_CLOCKS
is set, causing a JTAG disconnect.
Signed-off-by: Joel A Fernandes joelag...@ti.com
Cc: Russ Dill russ.d...@ti.com
Cc: Matt Porter mpor...@ti.com
Cc: Steve Kipisz s-kipi...@ti.com
Cc: Jason Kridner jkrid...@beagleboard.org
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/clock33xx_data.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index b7b7995..d0b4313 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -585,6 +585,7 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+ .flags = ENABLE_ON_INIT,
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] AM33XX: Clock: Fix JTAG disconnect during kernel boot
Set ENABLE_ON_INIT for debugss clock so that it is on during init and the
usecount is incremented.
Not doing so causes kernel to disable debugss clock to save power when
CONFIG_OMAP_RESET_CLOCKS
is set, causing a JTAG disconnect.
Signed-off-by: Joel A Fernandes joelag...@ti.com
Cc: Russ Dill russ.d...@ti.com
Cc: Matt Porter mpor...@ti.com
Cc: Steve Kipisz s-kipi...@ti.com
Cc: Jason Kridner jkrid...@beagleboard.org
Cc: Tony Lindgren t...@atomide.com
---
Resending, as Cc list was dropped.
arch/arm/mach-omap2/clock33xx_data.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index b7b7995..d0b4313 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -585,6 +585,7 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+ .flags = ENABLE_ON_INIT,
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] AM33XX: Clock: Fix JTAG disconnect during kernel boot
On 11/16/2012 05:44 PM, Joel A Fernandes wrote:
Set ENABLE_ON_INIT for debugss clock so that it is on during init and the
usecount is incremented.
Not doing so causes kernel to disable debugss clock to save power when
CONFIG_OMAP_RESET_CLOCKS
is set, causing a JTAG disconnect.
Signed-off-by: Joel A Fernandes joelag...@ti.com
Cc: Russ Dill russ.d...@ti.com
Cc: Matt Porter mpor...@ti.com
Cc: Steve Kipisz s-kipi...@ti.com
Cc: Jason Kridner jkrid...@beagleboard.org
Cc: Tony Lindgren t...@atomide.com
---
Resending, as Cc list was dropped.
arch/arm/mach-omap2/clock33xx_data.c |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index b7b7995..d0b4313 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -585,6 +585,7 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+ .flags = ENABLE_ON_INIT,
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Does this mean this clock will always be enabled, even when not using
JTAG? If so, is that what you want?
I was not sure if you are concerned about power at all. Or if having
that always enabled can inhibit low power states for suspend/idle etc.
May be worth adding more details to the changelog about if there are
side-effects to this change or not.
Adding Paul as he is the maintainer of clocks and clock data.
Cheers
Jon
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP2+: mux: Fixed gpio mux mode analysis.
* oleg.matcovs...@ti.com oleg.matcovs...@ti.com [121115 13:42]: From: Oleg Matcovschi oleg.matcovs...@ti.com OMAP_MODE_GPIO() macro verified only OMAP_MUX_MODE4. Indeed, that needs to be fixed. It is not correct for following platforms: 2430 - gpio mux mode 3 44xx - gpio mux mode 3 Looks like these are set properly to GPIO_IN_MODE3 with omap_mux_init(). 54xx - gpio mux mode 6 This will be only using pinctrl-single.c, so we don't really have to worrry about this one. But I guess we might as well fix that too while at it if somebody backports omap5 support to some older kernel.. Patch reserves first 3 bits in partition flags for storing gpio mux mode in same format as stored in control pad register. Modified OMAP_MODE_GPIO() macro handles all possible cases of gpio mux mode. Modified omap_mux_init() flags of omap34xx to include OMAP_MUX_GPIO_IN_MODE4. Why don't you just add int gpio to struct omap_mux_partition? You're not saving many bytes as at most we have two partitions so far per SoC. --- a/arch/arm/mach-omap2/mux34xx.c +++ b/arch/arm/mach-omap2/mux34xx.c @@ -2053,7 +2053,7 @@ int __init omap3_mux_init(struct omap_board_mux *board_subset, int flags) return -EINVAL; } - return omap_mux_init(core, 0, + return omap_mux_init(core, OMAP_MUX_GPIO_IN_MODE4, OMAP3_CONTROL_PADCONF_MUX_PBASE, OMAP3_CONTROL_PADCONF_MUX_SIZE, omap3_muxmodes, package_subset, board_subset, The default is GPIO_IN_MODE4, but that seems to be a bad default choice as only omap3 uses it. So yeah, might as well initialize that too and not assume any defaults GPIO mode. 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] AM33XX: Clock: Fix JTAG disconnect during kernel boot
Hi Jon,
On Fri, Nov 16, 2012 at 6:12 PM, Jon Hunter jon-hun...@ti.com wrote:
diff --git a/arch/arm/mach-omap2/clock33xx_data.c
b/arch/arm/mach-omap2/clock33xx_data.c
index b7b7995..d0b4313 100644
--- a/arch/arm/mach-omap2/clock33xx_data.c
+++ b/arch/arm/mach-omap2/clock33xx_data.c
@@ -585,6 +585,7 @@ static struct clk debugss_ick = {
.clkdm_name = l3_aon_clkdm,
.parent = dpll_core_m4_ck,
.ops= clkops_omap2_dflt,
+ .flags = ENABLE_ON_INIT,
.enable_reg = AM33XX_CM_WKUP_DEBUGSS_CLKCTRL,
.enable_bit = AM33XX_MODULEMODE_SWCTRL,
.recalc = followparent_recalc,
Does this mean this clock will always be enabled, even when not using
JTAG? If so, is that what you want?
Yes, the clock will always be on, because some times we connect JTAG
on a running Linux system without powering it down. I can't comment
without doing measurements if keeping the clock on has significant
impact on power, but I see what you mean. Definitely low power is a
parameter and folks who want lowest possible power might need to turn
off the clock and not have JTAG in production, but that depends on the
user's requirement. I personally don't care about power as much as I
care about not being able to JTAG, and I think there are other folks
who suffer from the same JTAG problem who wouldn't necessarily want
lowest power.
I was not sure if you are concerned about power at all. Or if having
that always enabled can inhibit low power states for suspend/idle etc.
Maybe, suspend/resume code can turn off clock on suspend and enable it
on resume.
May be worth adding more details to the changelog about if there are
side-effects to this change or not.
Sure, will do after waiting for any other review comments.
Thanks,
Joel
--
To unsubscribe from this list: send the line unsubscribe 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: tfp410 and i2c_bus_num
On 2012-11-16 20:21, Felipe Balbi wrote: Hi, On Fri, Nov 16, 2012 at 05:39:44PM +0200, Tomi Valkeinen wrote: To be fair, the whole i2c_bus_num looks like a big hackery introduced by the way panel drivers are written for OMAP DSS. TFP410 is an I2C client, not an OMAPDSS client. After a quick look at the driver, there's is no such thing as a DSS bus, so looks like you should have an I2C driver for TFP410 and the whole DSS stuff should be just a list of clients, but not a struct bus at all. The fact that you have to pass the I2C bus number down to the panel driver is already a big indication of how wrong this is, IMHO. Without going deeper in the dss device model problems, I would agree with you if this was about i2c panel, but this is not quite like that. A panel controlled via i2c would be an i2c device. But TFP410 is not controlled via i2c. It's not really controlled at all except via power-down gpio. TFP410 doesn't need the i2c to be functional at all. then why does it need the i2c adapter ? What is this power-down gpio ? Should that be hidden under gpiolib instead ? For the i2c, see below. Power-down GPIO is used to power down and up the tfp410 chip. that much I guessed ;-) Should it be hidden under gpiolib ? I have to say I have no idea what you mean... Hidden how? The i2c lines do not even touch TFP410 chip, so to be precise, the i2c lines should not be TFP410's concern. The i2c lines come from the monitor and go to OMAP's i2c pins. But TFP410 driver is a convenient place to manage them. fair enough... but who's actually using those i2c lines ? OMAP is the I2C master, who's the slave ? It's something in the monitor, I assume... IIUC, this I2C bus goes over the HDMI wire ? Yes, the i2c goes over HDMI wire. OMAP is the master, monitor is the slave. You can see some more info from http://en.wikipedia.org/wiki/Display_Data_Channel under DDC2 section. It is used to read the EDID (http://en.wikipedia.org/wiki/Extended_display_identification_data) information from the monitor, which tells things like supported video timings etc. As for why the tfp410 driver handles the i2c... We don't have a better place. There's no driver for the monitor. Although in the future with than that's wrong :-) If TFP410 isn't really using I2C it shouldn't need the whole i2c_bus_num logic. I'm far from fully understanding dss architecture but it looks like what you want is a generic 'i2c-edid.c' which just reads the edid structure during probe and caches the values and exposes them via sysfs ?!? (perhaps you also need a kernel API to read those values... I don't know; but that's also doable). Well, it's not that simple. TFP410 manages hot plug detection of the HDMI cable (although not implemented currently), so the we'd need to convey that information to the i2c-edid somehow. Which, of course, is doable, but increases complexity. Another thing is that even if in this case the i2c and EDID reading are separate from the actual video path, that may not be the case for other display solutions. We could have a DSI panel which reports its resolution via DSI bus, or we could have an external DSI-to-HDMI chip, which reads the EDID via i2c from the monitor, but reports them back to the SoC via DSI bus. So we need a generic way to get the resolution information, and it makes sense to have this in the components of the video path, not in a separate driver which is not part of the video path as such. And while the above issues could perhaps be solved, all we do is read one or two 128 byte datablocks from the i2c device. I'm not sure if the extra complexity is worth it. At least it's not on the top of my todo list as long as the current solution works =). If you have a generic i2c-edid.c simple driver, I guess X could be changes to read those values from sysfs and take actions based on those. We handle the EDID inside the kernel, although I'm not sure if drm also exposes the EDID to userspace. Looks like even drm_edid.c should change, btw. Yes, DRM handles it in somewhat similar way. Tomi signature.asc Description: OpenPGP digital signature
