Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On 06/17/2014 11:09 AM, Russell King - ARM Linux wrote: Here's the most obvious question in the world on this topic. Are capes hot-pluggable? capes as in Beaglebone capes might not be due to the mechanical constraints you listed. capes as a concept of pluggable hardware might well be. here is a real world example of commercially available pluggable hardware add-ons on a Linux system back from 2008: http://en.wikipedia.org/wiki/Archos_Generation_6#Accessories depending on the add-on, different interfaces like GPIO, UART, USB, SPI using the same pins were used and there was no reboot needed to load a new hardware configuration or change the pinmux -- To unsubscribe from this list: send the line unsubscribe 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: Trouble with newer kernels on Gumstix Overo boards
Daniel Mack wrote: Well, it doesn't really affect me as I just use this as a development platform for now. But please consider that there is hardware out there which gets software updates through automated download and install procedures. In such cases, you want as little dependencies between the bootloader and the kernel, so you can boot both older and newer If you want *minimal* dependency, then a compiled-in command line is the way to go and the bootloader only providing a few board identifying tags kernels (and full software distribution images) with no pain. Or maybe quickly switch from one version to the other for testing. Depending on the complexity of the system, the bootloader might also add extra parameters to the cmdline dynamically. AFAIK there is way to have the bootloader provided cmdline appended to the compiled-in one The serial console change breaks this approach, at it forces the kernel to ship its own CMDLINE and override the one the bootloader provides. I'm sure this is a problem that affects people out there. FWIW, for our firmware update deployment it's not a problem at all, since we do *not* want to rely on a kernel commandline provided by the bootloader for the exact same reason. Kernels change and thus the kernel command line belongs to the kernel. What does not change is e.g. the board id or revision or mem size, that (and only that) is provided by the bootloader to the kernel. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] omap v4l2: fix wrong resizer calculation
changes since v1:
reworded the commit message as requested
From f7f1c11fef76e53cdfe4ad98c6c9605dbe94aa86 Mon Sep 17 00:00:00 2001
From: Vladimir Pantelic vlado...@gmail.com
Date: Tue, 26 Apr 2011 09:28:11 +0200
Subject: [PATCH] omap v4l2: fix wrong resizer calculation
The omap_vout_new_crop() function has a possible bug, it uses
uninitialized variables crop.width/height which are actually output of the
function. Instead we should be using try_crop.width/height to calculate
the resizer values.
Signed-off-by: Vladimir Pantelic vlado...@gmail.com
Acked-by: Hiremath, Vaibhav hvaib...@ti.com
---
drivers/media/video/omap/omap_voutlib.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap/omap_voutlib.c b/drivers/media/video/omap/omap_voutlib.c
index 2aa6a76..8ae7481 100644
--- a/drivers/media/video/omap/omap_voutlib.c
+++ b/drivers/media/video/omap/omap_voutlib.c
@@ -193,7 +193,7 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
return -EINVAL;
if (cpu_is_omap24xx()) {
- if (crop-height != win-w.height) {
+ if (try_crop.height != win-w.height) {
/* If we're resizing vertically, we can't support a
* crop width wider than 768 pixels.
*/
@@ -202,7 +202,7 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
}
}
/* vertical resizing */
- vresize = (1024 * crop-height) / win-w.height;
+ vresize = (1024 * try_crop.height) / win-w.height;
if (cpu_is_omap24xx() (vresize 2048))
vresize = 2048;
else if (cpu_is_omap34xx() (vresize 4096))
@@ -221,7 +221,7 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
try_crop.height = 2;
}
/* horizontal resizing */
- hresize = (1024 * crop-width) / win-w.width;
+ hresize = (1024 * try_crop.width) / win-w.width;
if (cpu_is_omap24xx() (hresize 2048))
hresize = 2048;
else if (cpu_is_omap34xx() (hresize 4096))
--
1.7.6.rc1.1.g2c162b
Re: [RFC][PATCH 2/9] OMAP4: HWMOD: make current hwmods common for 4460 and 4430
Nishanth Menon wrote:
From: Aneesh Vane...@ti.com
Make all hwmod data used for OMAP4430 available for
the OMAP44XX class so that OMAP4460 can use them.
We will modify the required 4460 hwmod in further patch(es).
[n...@ti.com: just rebased to .39]
Signed-off-by: Nishanth Menonn...@ti.com
Signed-off-by: Aneesh Vane...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 164 ++--
1 files changed, 82 insertions(+), 82 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index abc548a..2f51a5a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -124,7 +124,7 @@ static struct omap_hwmod omap44xx_dmm_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_dmm_slaves),
.mpu_irqs = omap44xx_dmm_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap44xx_dmm_irqs),
- .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP44XX),
I guess at the time that CHIP_IS_OMAP4430 was introduced it was totally
unthinkable that another 44xx based chip would ever exist?
--
To unsubscribe from this list: send the line unsubscribe 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] About ARM expansion boards and others things
Enric Balletbò i Serra wrote: Hi guys, I'm thinking probably in a crazy idea, I hope someone can help me or kill definitely this idea from my mind. I'll explain a little more, the real problem is I don't know how to add support for an expansion board for IGEP v2 board. I see most of boards adds the support inside the board-x.c file, for example if the expansion board has a Touchscreen interface using ADS7846/TSC2046 they register ads7846 platform data in board-.c file. This is ok beacause the ads7846 can be detected and if expansion board is not present the detection fails, but maybe other devices in expansion board can't be detected (for example an I/O expansion). So which is the best form to do this ? I'm thinking in create a kernel module for the expansion board that add all the new features, the expansion board should come with a I2C E2PROM for board ID storage, so the idea is create an i2c driver that reads the E2PROM and if found the Board ID inits all the expansion board devices. don't know if you are aware of that: http://elinux.org/BeagleBoardPinMux#Expansion_boards also beagle.c board file has support for some expansion boards already, maybe there is some code to be shared. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] Initial BN Nook Color (encore) support.
Oleg Drokin wrote: Hello! Is there any special support needed for 3621, though? My understanding is that's just 3630 without a phone part? 3621 is more or less a 3630 in a different package, less pins, 0.5mm ball pitch and no PoP option. The .29 kernel they had only added is_omap3621 stuff that's not called anywhere, but smartreflex code (I guess that's might be useful to add too of course). I know about the new code drop is coming, but I don't expect there to be any basic stuff changes (and this board file is coming pretty barebones right now), besides I am not so optimistic to actually expect this patch to be merged right away, but I am already gathering valuable feedback. ;) BTW I saw in the archives that you are also working a port, do you have your tree hosted anywhere? Bye, Oleg On Apr 28, 2011, at 7:34 PM, Abimanyu Gottumukkala wrote: Hi, Nook color has Ti OMAP 3621. 3621 CPU Support is not available in current kernel, adding CPU support will be nice before board. BN is set to release new source code in few days, taking new code as porting base is also recommended. Regards, Abimanyu G On Thu, Apr 28, 2011 at 9:27 PM,gr...@linuxhacker.ru wrote: From: Oleg Drokingr...@linuxhacker.ru Bare-bones board file, comes with serial console, gpio keys, MMC/SDCard and USB support. --- arch/arm/mach-omap2/Kconfig |5 + arch/arm/mach-omap2/Makefile |2 + arch/arm/mach-omap2/board-omap3encore.c | 380 ++ arch/arm/plat-omap/include/plat/uncompress.h |1 + arch/arm/tools/mach-types|2 +- 5 files changed, 389 insertions(+), 1 deletions(-) create mode 100644 arch/arm/mach-omap2/board-omap3encore.c diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index b997a35..5370561 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -173,6 +173,11 @@ config MACH_OMAP3_TORPEDO for full description please see the products webpage at http://www.logicpd.com/products/development-kits/zoom-omap35x-torpedo-development-kit +config MACH_ENCORE +bool Barnes Noble Encore (Nook Color) +depends on ARCH_OMAP3 +select OMAP_PACKAGE_CBP + config MACH_OVERO bool Gumstix Overo board depends on ARCH_OMAP3 diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 512b152..b894777 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -189,6 +189,8 @@ obj-$(CONFIG_MACH_OMAP3530_LV_SOM) += board-omap3logic.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= board-omap3logic.o \ hsmmc.o +obj-$(CONFIG_MACH_ENCORE) += board-omap3encore.o \ + hsmmc.o obj-$(CONFIG_MACH_OVERO) += board-overo.o \ hsmmc.o obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \ diff --git a/arch/arm/mach-omap2/board-omap3encore.c b/arch/arm/mach-omap2/board-omap3encore.c new file mode 100644 index 000..c7bf8de --- /dev/null +++ b/arch/arm/mach-omap2/board-omap3encore.c @@ -0,0 +1,380 @@ +/* + * + * Copyright (C) 2008 Texas Instruments Inc. + * Vikram Panditavikram.pand...@ti.com + * + * Modified from mach-omap2/board-ldp.c + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * April 2011 Oleg Drokingr...@linuxhacker.ru - Port to 2.6.39 + * + */ + +#includelinux/kernel.h +#includelinux/platform_device.h +#includelinux/gpio_keys.h +#includelinux/err.h + +#includelinux/spi/spi.h +#includelinux/i2c/twl.h +#includelinux/regulator/machine.h +#includelinux/regulator/fixed.h +#includemach/hardware.h +#includeasm/mach-types.h +#includeasm/mach/arch.h + +#includemach/gpio.h +#includeplat/board.h +#includeplat/common.h +#includeplat/usb.h +#includeplat/mux.h +#includeplat/sram.h +#includeplat/mmc.h +#includeplat/omap-serial.h +#includeplat/system.h + +#include mux.h +#include hsmmc.h +#include sdram-hynix-h8mbx00u0mer-0em.h + +/* Encore-specific device-info and i2c addresses. */ +/* Battery, bus 1 */ +#define MAX17042_I2C_SLAVE_ADDRESS 0x36 +#define MAX17042_GPIO_FOR_IRQ 100 + +/*addition of MAXIM8903/TI GPIO mapping WRT schematics */ +#define MAX8903_UOK_GPIO_FOR_IRQ 115 +#define MAX8903_DOK_GPIO_FOR_IRQ 114 +#define MAX8903_GPIO_CHG_EN110 +#define MAX8903_GPIO_CHG_STATUS111 +#define MAX8903_GPIO_CHG_FLT 101 +#define MAX8903_GPIO_CHG_IUSB 102 +#define MAX8903_GPIO_CHG_USUS 104 +#define MAX8903_GPIO_CHG_ILM 61 + +/* TI WLAN */
[PATCH] omap v4l2: fix wrong resizer calculation
From 47473f26bda2ef2e3a5e8f0203fde0c74c412c36 Mon Sep 17 00:00:00 2001
From: Vladimir Pantelic vlado...@gmail.com
Date: Tue, 26 Apr 2011 09:28:11 +0200
Subject: [PATCH] omap v4l2: fix wrong resizer calculation
in omap_vout_new_crop(), crop is the output parameter and
therefore new_crop/try_crop should be used to calculate the
resizer values
Signed-off-by: Vladimir Pantelic vlado...@gmail.com
---
drivers/media/video/omap/omap_voutlib.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/omap/omap_voutlib.c b/drivers/media/video/omap/omap_voutlib.c
index 2aa6a76..8ae7481 100644
--- a/drivers/media/video/omap/omap_voutlib.c
+++ b/drivers/media/video/omap/omap_voutlib.c
@@ -193,7 +193,7 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
return -EINVAL;
if (cpu_is_omap24xx()) {
- if (crop-height != win-w.height) {
+ if (try_crop.height != win-w.height) {
/* If we're resizing vertically, we can't support a
* crop width wider than 768 pixels.
*/
@@ -202,7 +202,7 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
}
}
/* vertical resizing */
- vresize = (1024 * crop-height) / win-w.height;
+ vresize = (1024 * try_crop.height) / win-w.height;
if (cpu_is_omap24xx() (vresize 2048))
vresize = 2048;
else if (cpu_is_omap34xx() (vresize 4096))
@@ -221,7 +221,7 @@ int omap_vout_new_crop(struct v4l2_pix_format *pix,
try_crop.height = 2;
}
/* horizontal resizing */
- hresize = (1024 * crop-width) / win-w.width;
+ hresize = (1024 * try_crop.width) / win-w.width;
if (cpu_is_omap24xx() (hresize 2048))
hresize = 2048;
else if (cpu_is_omap34xx() (hresize 4096))
--
1.6.0.2
Re: OMAP_DSS: DSI driver with support for video mode?
Archit Taneja wrote: On Tuesday 12 April 2011 01:00 AM, Juha Kuikka wrote: Hello, I am wondering if anyone has implemented DSI video mode support in the DSS driver? I tried to trawl the web and the mailing list archives but no patches come up. I am using DM3730. Video mode isn't supported yet. But there are lots of custom implementations of it over the current DSS2. One I can think of is motorola's droid 2 and droid X source code: https://opensource.motorola.com/sf/sfmain/do/viewProject/projects.milestone Another one is in Archos Gen8 source code: http://www.archos.com/support/download/software/sources/gen8-gpl-froyo.tgz -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HELP:dspbridge:how to configure GPT timer
onlyfever wrote: Hi all! currently dsp make use of gpt 5, 6, 7 or 8. I'm using gpt 8 for something else. Is it possible to configure dsp-bridge to use other gpt timer? I want to change gpt 8 to gpt 9,or gpt 7. Please give me some advice. http://dev.omapzoom.org/?p=integration/kernel-omap3.git;a=commit;h=b310b556fda5888440a7b451939e22170fd0b246 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HELP:dspbridge:how to configure GPT timer
onlyfever wrote: 2011/4/11 Vladimir Pantelicvlado...@gmail.com: onlyfever wrote: Hi all! currently dsp make use of gpt 5, 6, 7 or 8. I'm using gpt 8 for something else. Is it possible to configure dsp-bridge to use other gpt timer? I want to change gpt 8 to gpt 9,or gpt 7. Please give me some advice. http://dev.omapzoom.org/?p=integration/kernel-omap3.git;a=commit;h=b310b556fda5888440a7b451939e22170fd0b246 I mean the GPT8 for decode 720p,not this one. Last time I checked, the OMAP3 had only one GPT8 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: HELP:dspbridge:how to configure GPT timer
Ramirez Luna, Omar wrote: Hi, On Sat, Apr 9, 2011 at 7:38 AM, onlyfeveronlyfe...@gmail.com wrote: Hi all! currently dsp make use of gpt 5, 6, 7 or 8. I'm using gpt 8 for something else. Is it possible to configure dsp-bridge to use other gpt timer? I want to change gpt 8 to gpt 9,or gpt 7. Please give me some advice. GPT8 is used for avsync on the dsp side, unfortunately there is no way to change this without dsp sources and the latter are not publicly available :/ Ah, didn't know that :( It's certainly not in use here for anything dsp related and 720p codecs running fine... -- To unsubscribe from this list: send the line unsubscribe 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] DSPBRIDGE: use dm timer framework for gpt timers
Omar Ramirez Luna wrote: yes, dsp side wants: bios -- GPT5 (only used during boot up - baseimage load) load monitoring -- GPT 6 (used while the dsp is awake) AV Sync -- GPT 8 (based on use case) to generate the interrupt for mmu fault case it needs one connected to the dsp interrupt line and only 5, 6, 7 or 8 apply. and it is also GPT8 for mmu fault handling atm. So, as GPT8 is one of the PWM capable, could that functionality be moved to GPT7? -- To unsubscribe from this list: send the line unsubscribe 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] DSPBRIDGE: use dm timer framework for gpt timers
Nishanth Menon wrote: Kevin Hilman had written, on 04/28/2010 12:59 PM, the following: Omar Ramirez Luna omar.rami...@ti.com writes: On 4/28/2010 11:36 AM, Menon, Nishanth wrote: Kevin Hilman had written, on 04/28/2010 11:29 AM, the following: Omar Ramirez Lunaomar.rami...@ti.com writes: On 4/28/2010 2:46 AM, Felipe Contreras wrote: On Wed, Apr 28, 2010 at 4:29 AM, Omar Ramirez Lunaomar.rami...@ti.com wrote: This patch switches to use DM timer framework instead of a custom one for GPT timers, currently dsp can make use of gpt 5, 6, 7 or 8. I heard someone that was using gpt 8 for something else. Is it possible to configure dsp-bridge to not use it? There are two scenarios: 1. The request comes from the DSP side (afaik for video use case), the change should be in the DSP side binaries to request some other gpt instead. I don't know how possible is to get this changed. 2. bridge driver also requests gpt8 whenever a mmu fault is triggered, this to set a timer to interrupt the dsp after the mmu fault dump has been finished, I think this can be easily replaced in bridge to use some other gpt, but 1 is still there. (besides a new patch is needed to remove direct access to dm timer inside ue_deh and make it to go through dsp-clock) Why does Bridge care at all which specific timers it requests? They are all the same, with the exception of GPT1 which is in the WKUP powerdomain and already used as the kernel clocksource. Bridge should just use the generic _request() instead of _request_specific() trouble I believe is that DSP BIOS uses a specific timer. yes, dsp side wants: bios -- GPT5 (only used during boot up - baseimage load) load monitoring -- GPT 6 (used while the dsp is awake) AV Sync -- GPT 8 (based on use case) to generate the interrupt for mmu fault case it needs one connected to the dsp interrupt line and only 5, 6, 7 or 8 apply. Then DSP bios is broken by hard-coding *general purpose* timers. /me just eats my own words. Not really.. I just got educated internally that DSP does not get interrupts from all GPTs. Ref: http://focus.ti.com/pdfs/wtbu/SWPU114Q_PrelimFinal_EPDF_03_05_2009.pdf page 1753 - only mentioned these timers can generate interrupts for DSP, and hence for BIOS's usage. Added to this, the fact that GPT PWM is usable on 9,10,11 as well, makes me believe this is something to consider as part of board design based on which peripherals one uses and their constraints. BIOS is not at fault here to use the resources it requires, but is part of system design to look at options, constraints and select the ones appropriately.. A similar example is mux pins, you have options to plug to one of many options, but if you plug in both a interrupt and a data line to the same pin which could run in two different modes, there is a problem there right? Alright, that is too obvious i suppose Yes, just that pin mux issues are pretty obvious reading the TRM and DM, but the fact that bridge blocks GPT5,6 and 8 is not. You are telling me that using all 4 GPTs for PWM or input event capture is not possible when using dspbridge? As I understand, bridge mostly uses 2 of the GPTs (6 for load monitoring, 8 for sync/mmu fault), so I think moving GPT8 to 7 should make both sides happy, no? Regards, Vladimir -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP2/3 V4L2: Add support for OMAP2/3 V4L2 driver on top of DSS2
hvaib...@ti.com wrote:
From: Vaibhav Hiremathhvaib...@ti.com
Features Supported -
1. Provides V4L2 user interface for the video pipelines of DSS
2. Basic streaming working on LCD, DVI and TV.
3. Works on latest DSS2 library from Tomi
4. Support for various pixel formats like YUV, UYVY, RGB32, RGB24,
RGB565
5. Supports Alpha blending.
6. Supports Color keying both source and destination.
7. Supports rotation.
8. Supports cropping.
9. Supports Background color setting.
10. Allocated buffers to only needed size
Signed-off-by: Vaibhav Hiremathhvaib...@ti.com
snip
diff --git a/drivers/media/video/omap/omap_voutlib.c
b/drivers/media/video/omap/omap_voutlib.c
new file mode 100644
index 000..05c0e17
--- /dev/null
+++ b/drivers/media/video/omap/omap_voutlib.c
@@ -0,0 +1,258 @@
+/*
+ * omap_voutlib.c
+ *
+ * Copyright (C) 2005-2010 Texas Instruments.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed as is without any warranty of any
+ * kind, whether express or implied.
+ *
+ * Based on the OMAP2 camera driver
+ * Video-for-Linux (Version 2) camera capture driver for
+ * the OMAP24xx camera controller.
+ *
+ * Author: Andy Lowe (sou...@mvista.com)
+ *
+ * Copyright (C) 2004 MontaVista Software, Inc.
+ * Copyright (C) 2010 Texas Instruments.
+ *
+ */
+
+#includelinux/module.h
+#includelinux/errno.h
+#includelinux/kernel.h
+#includelinux/types.h
+#includelinux/videodev2.h
+
+MODULE_AUTHOR(Texas Instruments);
+MODULE_DESCRIPTION(OMAP Video library);
+MODULE_LICENSE(GPL);
+
+/* Return the default overlay cropping rectangle in crop given the image
+ * size in pix and the video display size in fbuf. The default
+ * cropping rectangle is the largest rectangle no larger than the capture size
+ * that will fit on the display. The default cropping rectangle is centered in
+ * the image. All dimensions and offsets are rounded down to even numbers.
+ */
+void omap_vout_default_crop(struct v4l2_pix_format *pix,
+ struct v4l2_framebuffer *fbuf, struct v4l2_rect *crop)
+{
+ crop-width = (pix-width fbuf-fmt.width) ?
+ pix-width : fbuf-fmt.width;
+ crop-height = (pix-height fbuf-fmt.height) ?
+ pix-height : fbuf-fmt.height;
+ crop-width= ~1;
+ crop-height= ~1;
+ crop-left = ((pix-width - crop-width) 1) ~1;
+ crop-top = ((pix-height - crop-height) 1) ~1;
+}
+EXPORT_SYMBOL_GPL(omap_vout_default_crop);
+
+/* Given a new render window in new_win, adjust the window to the
+ * nearest supported configuration. The adjusted window parameters are
+ * returned in new_win.
+ * Returns zero if succesful, or -EINVAL if the requested window is
+ * impossible and cannot reasonably be adjusted.
+ */
+int omap_vout_try_window(struct v4l2_framebuffer *fbuf,
+ struct v4l2_window *new_win)
+{
+ struct v4l2_rect try_win;
+
+ /* make a working copy of the new_win rectangle */
+ try_win = new_win-w;
+
+ /* adjust the preview window so it fits on the display by clipping any
+* offscreen areas
+*/
+ if (try_win.left 0) {
+ try_win.width += try_win.left;
+ try_win.left = 0;
+ }
+ if (try_win.top 0) {
+ try_win.height += try_win.top;
+ try_win.top = 0;
+ }
+ try_win.width = (try_win.width fbuf-fmt.width) ?
+ try_win.width : fbuf-fmt.width;
+ try_win.height = (try_win.height fbuf-fmt.height) ?
+ try_win.height : fbuf-fmt.height;
+ if (try_win.left + try_win.width fbuf-fmt.width)
+ try_win.width = fbuf-fmt.width - try_win.left;
+ if (try_win.top + try_win.height fbuf-fmt.height)
+ try_win.height = fbuf-fmt.height - try_win.top;
+ try_win.width= ~1;
+ try_win.height= ~1;
+
+ if (try_win.width= 0 || try_win.height= 0)
+ return -EINVAL;
+
+ /* We now have a valid preview window, so go with it */
+ new_win-w = try_win;
+ new_win-field = V4L2_FIELD_ANY;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(omap_vout_try_window);
+
+/* Given a new render window in new_win, adjust the window to the
+ * nearest supported configuration. The image cropping window in crop
+ * will also be adjusted if necessary. Preference is given to keeping the
+ * the window as close to the requested configuration as possible. If
+ * successful, new_win, vout-win, and crop are updated.
+ * Returns zero if succesful, or -EINVAL if the requested preview window is
+ * impossible and cannot reasonably be adjusted.
+ */
+int omap_vout_new_window(struct v4l2_rect *crop,
+ struct v4l2_window *win, struct v4l2_framebuffer *fbuf,
+ struct v4l2_window *new_win)
+{
+ int err;
+
+ err = omap_vout_try_window(fbuf, new_win);
+ if
Re: [PATCH] OMAP3630:DSS2:Enable Pre-Multiplied Alpha Support
Y, Kishore wrote: As per TRM, this bit is valid only for ARGB formats and experts suggested that we can safely assume pre-multiplied data always in real world I asked a few experts here, and they weren't so sure, and neither am I. I don't see any problems making this feature configurable, but there may be problems if it's hardcoded. So, it should be configurable. I think the default should be the same as on 3430, so that they will work similarly. Tomi I haven't considered the backward compatibility with 3430 apps. I will make this configurable. And please defaulting to non-pre-multiplied. All 3430 apps will be non-pre-multiplied as this is what the 3430 supports only. So apps need to be actively changed to use pre-multiplied. -- To unsubscribe from this list: send the line unsubscribe 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: OMAP2420-HS flashing question
Andrejs Cainikovs wrote: Dear all, I've googled that OMAP HS are checking some kind of signature (applications should be signed with the special tool (OST Tools)) so the developer must own the keys for particular CPU? It is possible to turn off the HS option so I'll be able to work with non-signed binaries? The problem is that I want to get kernel running on custom OMAP2420-HS board but have no keys. no, it cannot be turned off, that would somehow counteract the high part in high security If somebody can send me the OMAP2420 HS (or similar) datasheet, I'll really appreciate that. hehe, nice try... :-) -- To unsubscribe from this list: send the line unsubscribe 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: MMC3 Overo
Tony Lindgren wrote: snip Here's an idea: 1) Replace index with enum search in pin table - this breaks the requirement that the enum list and table align - a good thing as misalingment has bitten me multiple times when adding pins to the current mux table. Also, pinmux setup is done infrequently, so the search doesn't add much overall execution time. Yeh something like that sounds good. We should just move the omap1 specific code to live in mach-omap1 and keep it as it is for now. You might also want to take a look at what the sh people have done: $ find arch/sh -name \*mux* 2) Break up mux table into two parts, the common mux list, and a custom mux list - the latter in the board file, and add a function to add the custom mux list to mux lists searched by omap_cfg_reg(). 3) Search the custom mux list first (if specified - allows replacing an entry in the common table if hardware required differences in termination, custom pins for GPIO, etc). For example, on the OMAP3530, balls H18-H21 can be associated with either UART3, or GPIOs 163-166. In the common mux list (where multiple boards use those pins for UART3, the common mux file can have the entries: H18_35XX_UART3_CTS H19_35XX_UART3_RTS H20_35XX_UART3_RX H21_35XX_UART_TX that sets up the mux for those pines as a UART. If a board wants to use those pins instead for GPIO, then in the board file it can have a custom mux list with: H18_35XX_GPIO_163 H19_35XX_GPIO_164 H20_35XX_GPIO_165 H21_35XX_GPIO_166 and call into the mux code to add the custom mux list to be searched first. Thoughts? Sounds pretty good to me! but does not solve yet the package issue, where different omap3 packages have different balls connected, no? It would be ok for board files, assuming that a board has only one package, but what about the common code? Or are the package differences only for a few pins, in this case they could be banned from common and must live in board files.. -- To unsubscribe from this list: send the line unsubscribe 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: MMC3 Overo
Kevin Hilman wrote: AB1_35XXCBB_MMC3_CLK AF10_35XXCBB_MMC3_CLK R9_35XXCBC_MMC3_CLK AB2_35XXCBC_MMC3_CLK AC1_35XXCUS_MMC3_CLK We would then have to update mux.c making sure the position matches and add the proper settings. So this is obviously a maintenance nightmare. So why don't we drop the ball (pun intended.) ;) This is what I proposed to Phillip Ballister for his SPI changes for Beagle. Though I haven't looked at the details for each package, I have a hard time imagining that the reg offsets and functionality for each package is different. In fact, I'm pretty sure they're even the same between 34xx and 35xx. IOW, why not just name it OMAP3_MMC3_CLK and have a single entry. Then each board file that cares simply has to call omap_cfg_reg() on that name and not care about the package. even for 1 package, how will you know whether OMAP3_MMC3_CLK is connected to ball AB1 or AF10 as both is possible... -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
