Re: [PATCHv2 0/6] OMAP: DSS: porting old drivers to DSS2 (board files part)
Hi Tony, On Mon, 2011-09-12 at 14:20 +0300, Tomi Valkeinen wrote: > This patch set ports all the OMAP2/3 boards, except N8x0, that use the old > omapfb to use the newer DSS2 driver. Only board files are changed, the panel > driver additions are done in separate patch set. Applying this set without the > driver changes will obviously disable the displays of the affected boards > until > the drivers are also merged. > > Some board files contained old omapfb code, but there wasn't a matching LCD > driver. That board file code is also removed. Any chances to get these in for the next merge window? These will remove most of the OMAP2/3 users of the old omapfb, and when the old omapfb is used only by OMAP1, we can remove quite a bit of code there. 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
Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
Hi Martin, On Monday 19 September 2011 08:10:19 mar...@neutronstar.dyndns.org wrote: > On Sun, Sep 18, 2011 at 11:58:55PM +0200, Laurent Pinchart wrote: > > On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote: > > > Adds board support for an MT9M032 based camera to omap3evm. > > > > > > Sigend-off-by: Martin Hostettler > > > --- > > > > > > arch/arm/mach-omap2/Makefile|1 + > > > arch/arm/mach-omap2/board-omap3evm-camera.c | 183 > > > > > > +++ 2 files changed, 184 insertions(+), 0 > > > deletions(-) > > > > > > create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c > > > > > > Changes in V2: > > > * ported to current mainline > > > * Style fixes > > > * Fix error handling > > > > > > diff --git a/arch/arm/mach-omap2/Makefile > > > b/arch/arm/mach-omap2/Makefile index f343365..8ae3d25 100644 > > > --- a/arch/arm/mach-omap2/Makefile > > > +++ b/arch/arm/mach-omap2/Makefile > > > + return 0; > > > + > > > +err_8: > > > + gpio_free(EVM_TWL_GPIO_BASE + 8); > > > +err_2: > > > + gpio_free(EVM_TWL_GPIO_BASE + 2); > > > +err_vdsel: > > > + gpio_free(nCAM_VD_SEL); > > > +err: > > > + return ret; > > > +} > > > + > > > +device_initcall(camera_init); > > > > Please don't use device_initcall(), but call the function directly from > > the OMAP3 EVM init handler. Otherwise camera_init() will be called if > > OMAP3 EVM support is compiled in the kernel, regardless of the board the > > kernel runs on. > > Ok, will do. > In which header should the prototyp of that function go? Or can i just > add a prototyp to board-omap3evm.c directly? > I couldn't find anything that looked right, this is rather board specific > after all. You can either create arch/arm/mach-omap2/board-omap3evm.h or add the prototype to board-omap3evm.c. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe 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] misc: remove CONFIG_MISC_DEVICES
On Sunday 18 September 2011 11:45:16 Randy Dunlap wrote:
> >> We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
> >> consistent or timely with applying drivers/misc/ patches. It deserves
> >> better.
> >> [added him to Cc: list]
> >
> > I do try to handle patches sent to me for misc/ in time for the
> > different merge windows as that directory contains drivers that have
> > moved out of the staging/ directory.
> >
> > But yes, I'm not the overall drivers/misc/ maintainer, do we really need
> > one? If so, I can easily start maintaining a development tree for it to
> > keep it separate for the different driver authors to send me stuff and
> > start tracking it more "for real" if Arnd doesn't want to do it.
>
> We need for the patches to be applied in a timely manner.
> Sometimes when there is no real maintainer, that does not happen.
I think the other equally import aspect of maintainership that
drivers/misc (and drivers/char) needs is someone who says no to
stuff that doesn't belong there and helps submitters to find a
proper place where appropriate and to come up with a proper user
interface abstraction.
I'm definitely willing to do that part.
Greg, how about we both formally take ownership of driver/{misc,char}
and you track the patches while I do the bulk of the reviews? You
are definitely better than me with the patch tracking workflow.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
群发软件+买家搜索机+109届广交会买家、海关数据,B2B询盘买家500万。
群发软件+109届广交会买家、海关数据、搜索引擎买家,B2B询盘买家共500万,仅10元每天。
保证每天都有买家回复。
保证每天都有买家回复。
1、群发软件： 操作简单，功能强大，模仿人工操作模式，到达率高，日发送5万封以上。
2、500万广交会买家资源： 赠送的500万买家资源库，每月更新 。
3、超级海外买家Email搜索机： 每天能搜索1-2万以上买家真实EMAIL，成单率高。
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625...@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625...@qq.com
要的抓紧联系QQ: 1339625218 或者立即回复邮箱: 1339625...@qq.com
免费赠送:
一共8个包(数据是全行业的，按照行业分好类，并且可以按照关键词查询的)：
1，2011春季109届广交会买家现场询盘数据库新鲜出炉，超级新鲜买家，新鲜数据，容易成单！
2，购买后可以免费更新2011秋季广交会+2012春季广交会买家数据。太超值了。
3，最新全球买家库,共451660条数据。 (最新更新日期 2011-05-16日)
4，2008年,2009年,2010年 春季+秋季广交会买家名录，103 104 105 106 107 108 共六届 共120.6万数据。
5，2010年国际促销协会（PPAI）成员名单 PPAI Members Directory，非常重要的大买家。
6，2010年到香港采购的国外客人名录(香港贸发局提供)，共7.2万数据，超级重要的买家。
7，48.68万条最新买家询盘，购买后每月更新 1-2万条，包括2部分，1，最新的询盘 2，最新的展会买家。免费更新36个月。
8，2009年海关提单数据piers版数据 1千万。
诚信为本，支持支付宝担保交易 (先发货并安装设置群发软件，然后付款) 彻底打消您的 顾虑。
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
精准数据-成单率极高
N�r��yb�X��ǧv�^�){.n�+{��f��{ay� ʇڙ�,j��f���h���z� �w���
���j:+v���w�j�mzZ+�ݢj"��!�i
Re: [PATCH 1/5 v9] arm: omap: usb: ehci and ohci hwmod structures for omap4
On Thu, Sep 15, 2011 at 6:52 PM, Keshava Munegowda
wrote:
> From: Benoit Cousson
>
> Following 4 hwmod structures are added:
> UHH hwmod of usbhs with uhh base address and functional clock,
> EHCI hwmod with irq and base address,
> OHCI hwmod with irq and base address,
> TLL hwmod of usbhs with the TLL base address and irq.
>
> Signed-off-by: Benoit Cousson
> Signed-off-by: Keshava Munegowda
> ---
> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 249
> +++-
> 1 files changed, 248 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> index 6201422..f06efa6 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> @@ -68,6 +68,10 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
> static struct omap_hwmod omap44xx_mpu_hwmod;
> static struct omap_hwmod omap44xx_mpu_private_hwmod;
> static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
> +static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
> +static struct omap_hwmod omap44xx_usbhs_ohci_hwmod;
> +static struct omap_hwmod omap44xx_usbhs_ehci_hwmod;
> +static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
>
> /*
> * Interconnects omap_hwmod structures
> @@ -5336,6 +5340,244 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
> .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> };
>
> +/*
> + * 'usb_host_hs' class
> + * high-speed multi-port usb host controller
> + */
> +static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
> + .master = &omap44xx_usb_host_hs_hwmod,
> + .slave = &omap44xx_l3_main_2_hwmod,
> + .clk = "l3_div_ck",
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
> + .rev_offs = 0x,
> + .sysc_offs = 0x0010,
> + .syss_offs = 0x0014,
> + .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
> + .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
> + SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
> + MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
> + .sysc_fields = &omap_hwmod_sysc_type2,
> +};
> +
> +static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
> + .name = "usbhs_uhh",
> + .sysc = &omap44xx_usb_host_hs_sysc,
> +};
> +
> +static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
> + &omap44xx_usb_host_hs__l3_main_2,
> +};
> +
> +static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
> + {
> + .name = "uhh",
> + .pa_start = 0x4a064000,
> + .pa_end = 0x4a0647ff,
> + .flags = ADDR_TYPE_RT
> + },
> + {}
> +};
> +
> +static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
> + .master = &omap44xx_l4_cfg_hwmod,
> + .slave = &omap44xx_usb_host_hs_hwmod,
> + .clk = "l4_div_ck",
> + .addr = omap44xx_usb_host_hs_addrs,
> + .user = OCP_USER_MPU | OCP_USER_SDMA,
> +};
> +
> +static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
> + &omap44xx_l4_cfg__usb_host_hs,
> +};
> +
> +static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
> + .name = "usbhs_uhh",
> + .class = &omap44xx_usb_host_hs_hwmod_class,
> + .clkdm_name = "l3_init_clkdm",
> + .main_clk = "usb_host_hs_fck",
> + .prcm = {
> + .omap4 = {
> + .clkctrl_offs =
> OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
> + .context_offs =
> OMAP4_RM_L3INIT_USB_HOST_CONTEXT_OFFSET,
> + .modulemode = MODULEMODE_SWCTRL,
> + },
> + },
> + .slaves = omap44xx_usb_host_hs_slaves,
> + .slaves_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_slaves),
> + .masters = omap44xx_usb_host_hs_masters,
> + .masters_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_masters),
> + .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
> + .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
> +};
> +
> +/* 'usbhs_ohci' class */
> +static struct omap_hwmod_class omap44xx_usbhs_ohci_hwmod_class = {
> + .name = "usbhs_ohci",
> +};
> +
> +static struct omap_hwmod_irq_info omap44xx_usbhs_ohci_irqs[] = {
> + { .name = "ohci-irq", .irq = 76 + OMAP44XX_IRQ_GIC_START },
> + { .irq = -1 }
> +};
> +
> +static struct omap_hwmod_addr_space omap44xx_usbhs_ohci_addrs[] = {
> + {
> + .name = "ohci",
> + .pa_start = 0x4A064800,
> + .pa_end = 0x4A064BFF,
> + .flags = ADDR_MAP_ON_INIT
> + },
> + {}
> +};
> +
> +static struct oma
RE: [PATCH] ti816x: add support for nand on ti8168 evm
> -Original Message- > From: Artem Bityutskiy [mailto:dedeki...@gmail.com] > Sent: Monday, September 19, 2011 10:26 AM > To: Saxena, Parth > Cc: linux-...@lists.infradead.org; Basheer, Mansoor Ahamed; linux- > o...@vger.kernel.org > Subject: Re: [PATCH] ti816x: add support for nand on ti8168 evm > > On Thu, 2011-09-08 at 18:33 +0530, Saxena, Parth wrote: > > Add partition table for NAND device on TI8168 EVM > > and initialise the NAND module. > > > > Signed-off-by: Saxena, Parth > > Signed-off-by: Basheer, Mansoor Ahamed > > --- > > > > This patch is tested on top of linux-omap/master and > > Hemant's patches submitted recently. > > > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53457.html > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg54296.html > > > > arch/arm/mach-omap2/board-ti8168evm.c | 39 > + > > 1 files changed, 39 insertions(+), 0 deletions(-) > > Please, send this patch to Tony, I think it should go in via the omap > tree, not via the MTD tree. [Saxena, Parth] Artem, I will re-post this patch to linux-omap list and Tony. Can I add your name in the 'Acked-by' section? > > -- > Best Regards, > Artem Bityutskiy -- To unsubscribe from this list: send the line "unsubscribe 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] ti816x: add support for nand on ti8168 evm
On Mon, 2011-09-19 at 17:04 +0530, Saxena, Parth wrote: > Artem, > I will re-post this patch to linux-omap list and Tony. Can I add your name in > the 'Acked-by' section? No, I did not review this patch. -- Best Regards, Artem Bityutskiy -- To unsubscribe from this list: send the line "unsubscribe 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] misc: remove CONFIG_MISC_DEVICES
On Mon, Sep 19, 2011 at 10:47:50AM +0200, Arnd Bergmann wrote:
> On Sunday 18 September 2011 11:45:16 Randy Dunlap wrote:
> > >> We have fallbacks to Andrew and/or GregKH currently, but GregKH is not
> > >> consistent or timely with applying drivers/misc/ patches. It deserves
> > >> better.
> > >> [added him to Cc: list]
> > >
> > > I do try to handle patches sent to me for misc/ in time for the
> > > different merge windows as that directory contains drivers that have
> > > moved out of the staging/ directory.
> > >
> > > But yes, I'm not the overall drivers/misc/ maintainer, do we really need
> > > one? If so, I can easily start maintaining a development tree for it to
> > > keep it separate for the different driver authors to send me stuff and
> > > start tracking it more "for real" if Arnd doesn't want to do it.
> >
> > We need for the patches to be applied in a timely manner.
> > Sometimes when there is no real maintainer, that does not happen.
>
> I think the other equally import aspect of maintainership that
> drivers/misc (and drivers/char) needs is someone who says no to
> stuff that doesn't belong there and helps submitters to find a
> proper place where appropriate and to come up with a proper user
> interface abstraction.
>
> I'm definitely willing to do that part.
>
> Greg, how about we both formally take ownership of driver/{misc,char}
> and you track the patches while I do the bulk of the reviews? You
> are definitely better than me with the patch tracking workflow.
That sounds good to me, I'll be glad to collect the patches and push
them to Linus for both of those trees (might as well keep them in the
same git tree, no need to separate them, right?) and I'll rely on you
for review and acking them. Much like I do today for the tty and serial
trees.
I'll go set up the trees locally today and when kernel.org opens back
up, make them public and add them to linux-next.
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
Re: [PATCH v2 1/2] OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration
On 9/17/2011 6:05 PM, Grant Likely wrote:
On Fri, Sep 16, 2011 at 04:43:18PM +0200, Benoit Cousson wrote:
Split the omap_device_build_ss into two smaller functions
that will allow to populate a platform_device already allocated by
device-tree.
The functionality of the omap_device_build_ss is still the same, but
the omap_device_alloc will be usable with devices already built by
device-tree.
Signed-off-by: Benoit Cousson
Cc: Kevin Hilman
Looks pretty good. Comments below.
g.
---
arch/arm/plat-omap/omap_device.c | 177 +
1 files changed, 119 insertions(+), 58 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index 54bbe7b..cac7b9a 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -96,6 +96,11 @@
static int omap_device_register(struct platform_device *pdev);
static int omap_early_device_register(struct platform_device *pdev);
+static struct omap_device *omap_device_alloc(struct platform_device *pdev,
+ struct omap_hwmod **ohs, int oh_cnt,
+ struct omap_device_pm_latency *pm_lats,
+ int pm_lats_cnt);
+
static struct omap_device_pm_latency omap_default_latency[] = {
{
@@ -397,6 +402,110 @@ static int omap_device_fill_resources(struct omap_device
*od,
}
/**
+ * omap_device_alloc - allocate an omap_device
+ * @pdev: platform_device that will be included in this omap_device
+ * @oh: ptr to the single omap_hwmod that backs this omap_device
+ * @pdata: platform_data ptr to associate with the platform_device
+ * @pdata_len: amount of memory pointed to by @pdata
+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
+ *
+ * Convenience function for allocating an omap_device structure and filling
+ * hwmods, resources and pm_latency attributes.
+ *
+ * Returns an struct omap_device pointer or ERR_PTR() on error;
+ */
+static struct omap_device *omap_device_alloc(struct platform_device *pdev,
+ struct omap_hwmod **ohs, int oh_cnt,
+ struct omap_device_pm_latency *pm_lats,
+ int pm_lats_cnt)
+{
+ int ret = -ENOMEM;
+ struct omap_device *od;
+ struct resource *res = NULL;
+ int i, res_count;
+ struct omap_hwmod **hwmods;
+
+ od = kzalloc(sizeof(struct omap_device), GFP_KERNEL);
possible enhancement: devm_kzalloc() perhaps? Would simplify the cleanup
paths.
+ if (!od) {
+ ret = -ENOMEM;
+ goto oda_exit1;
+ }
+ od->hwmods_cnt = oh_cnt;
+
+ hwmods = kmemdup(ohs, sizeof(struct omap_hwmod *) * oh_cnt, GFP_KERNEL);
Ditto here. would require creation of devm_kmemdup()
+ if (!hwmods)
+ goto oda_exit2;
+
+ od->hwmods = hwmods;
+ od->pdev = pdev;
+
+ /*
+* HACK: Ideally the resources from DT should match, and hwmod
+* should just add the missing ones. Since the name is not
+* properly populated by DT, stick to hwmod resources only.
+*/
+ if (pdev->num_resources&& pdev->resource)
+ dev_warn(&pdev->dev, "%s(): resources already allocated %d\n",
+ __func__, pdev->num_resources);
+
+ res_count = omap_device_count_resources(od);
+ if (res_count> 0) {
+ dev_dbg(&pdev->dev, "%s(): resources allocated from hwmod %d\n",
+ __func__, res_count);
+ res = kzalloc(sizeof(struct resource) * res_count, GFP_KERNEL);
+ if (!res)
+ goto oda_exit3;
+
+ omap_device_fill_resources(od, res);
+
+ ret = platform_device_add_resources(pdev, res, res_count);
+ kfree(res);
How big is res_count? Struct resource isn't very big. It can
probably be on the stack.
It will depend of the number of entries in the hwmod DB that can vary
from one address space to 10 addresses + a bunch of irqs + a bunch of
dmas. To be honest, that code is just a cut&paste of the original one.
But since that number can vary based on another file content and
considering that this code is supposed to disappear as soon as the
resource will come from DT, I'm not 100% convince it worth the effort.
+
+ if (ret)
+ goto oda_exit3;
+ }
+
+ if (!pm_lats) {
+ pm_lats = omap_default_latency;
+ pm_lats_cnt = ARRAY_SIZE(omap_default_latency);
+ }
+
+ od->pm_lats_cnt = pm_lats_cnt;
+ od->pm_lats = kmemdup(pm_lats,
+ sizeof(struct omap_device_pm_latency) * pm_lats_cnt,
+ GFP_KERNEL);
+ if (!od->pm_lats)
+ goto oda_exit3;
+
+ pdev->archdata.od = od;
+
+
Re: [PATCH v2 2/2] OMAP: omap_device: Add a method to build an omap_device from a DT node
On 9/17/2011 6:13 PM, Grant Likely wrote:
On Fri, Sep 16, 2011 at 04:43:19PM +0200, Benoit Cousson wrote:
Add a notifier called during device_add phase. If an of_node is present,
retrieve the hwmod entry in order to populate properly the omap_device
structure.
For the moment the resource from the device-tree are overloaded.
DT does not support named resource yet, and thus, most driver
will not work without that information.
Add two helpers function to parse a property that contains multiple
strings.
Signed-off-by: Benoit Cousson
Cc: Kevin Hilman
---
arch/arm/plat-omap/omap_device.c | 144 ++
1 files changed, 144 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/omap_device.c b/arch/arm/plat-omap/omap_device.c
index cac7b9a..da13630 100644
--- a/arch/arm/plat-omap/omap_device.c
+++ b/arch/arm/plat-omap/omap_device.c
@@ -85,6 +85,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -94,12 +96,15 @@
#define USE_WAKEUP_LAT0
#define IGNORE_WAKEUP_LAT 1
+#define MAX_HWMOD_NAME_SIZE32
+
static int omap_device_register(struct platform_device *pdev);
static int omap_early_device_register(struct platform_device *pdev);
static struct omap_device *omap_device_alloc(struct platform_device *pdev,
struct omap_hwmod **ohs, int oh_cnt,
struct omap_device_pm_latency *pm_lats,
int pm_lats_cnt);
+static void omap_device_delete(struct omap_device *od);
static struct omap_device_pm_latency omap_default_latency[] = {
@@ -315,6 +320,138 @@ static void _add_hwmod_clocks_clkdev(struct omap_device
*od,
_add_clkdev(od, oh->opt_clks[i].role, oh->opt_clks[i].clk);
}
+/*
+ * XXX: DT helper functions that should probably move elsewhere if
+ * they become usefull for other needs.
+ */
Lets just *assume* these are useful for other needs and start with
them in drivers/of so that other people know that they actually exist.
Otherwise they will never be made generic. :-)
Good point...
But, meanwhile Stephen Warren proposed a much nicer iterator to deal
with that. Since these patches are still not in mainline, I didn't want
to depend on them yet. So my "secret" plan was to remove these functions
once the ones from Stephen will be merged.
+static int _dt_count_property_string(const char *prop, int len)
+{
+ int i = 0;
+ size_t l = 0, total = 0;
+
+ if (!prop || !len)
+ return -EINVAL;
+
+ for (i = 0; len>= total; total += l, prop += l) {
+ l = strlen(prop) + 1;
+ if (*prop != 0)
+ i++;
+ }
+ return i;
+}
+
+static int _dt_get_property(const char *prop, int len, int index, char *output,
+ int size)
+{
+ int i = 0;
+ size_t l = 0, total = 0;
+
+ if (!prop || !len)
+ return -EINVAL;
+
+ for (i = 0; len>= total; total += l, prop += l) {
+ l = strlcpy(output, prop, size) + 1;
+ if (*prop != 0) {
+ if (i++ == index)
+ return 0;
+ }
+ }
+ return -ENODEV;
+}
+
+static struct dev_pm_domain omap_device_pm_domain;
+
+/**
+ * omap_device_build_from_dt - build an omap_device with multiple hwmods
+ * @pdev_name: name of the platform_device driver to use
+ * @pdev_id: this platform_device's connection ID
+ * @oh: ptr to the single omap_hwmod that backs this omap_device
+ * @pdata: platform_data ptr to associate with the platform_device
+ * @pdata_len: amount of memory pointed to by @pdata
+ * @pm_lats: pointer to a omap_device_pm_latency array for this device
+ * @pm_lats_cnt: ARRAY_SIZE() of @pm_lats
+ * @is_early_device: should the device be registered as an early device or not
+ *
+ * Function for building an omap_device already registered from device-tree
+ *
+ * Returns 0 or PTR_ERR() on error.
+ */
+static int omap_device_build_from_dt(struct platform_device *pdev)
+{
+ struct omap_hwmod **hwmods;
+ struct omap_device *od;
+ struct omap_hwmod *oh;
+ char oh_name[MAX_HWMOD_NAME_SIZE];
+ const char *prop;
+ int oh_cnt, i, prop_len;
+ int ret = 0;
+
+ prop = of_get_property(pdev->dev.of_node, "hwmods",&prop_len);
I know you've posted it before, but what is the status of the "hwmods"
binding documentation. I would expect it to be part of this patch.
It was part of the series that introduced the first node with hwmods
attribute
(http://lists.ozlabs.org/pipermail/devicetree-discuss/2011-August/007621.html).
I do agree, it makes sense to add it here.
+ oh_cnt = _dt_count_property_string(prop, prop_len);
+ if (!oh_cnt || IS_ERR_VALUE(oh_cnt)) {
+ dev_warn(&pdev->dev, "No 'hwmods' to build omap_device\n");
+ re
[PATCH] ti816x: add support for nand on ti8168 evm
Add partition table for NAND device on TI8168 EVM
and initialise the NAND module.
Signed-off-by: Saxena, Parth
Signed-off-by: Basheer, Mansoor Ahamed
---
This patch is tested on top of linux-omap/master and
Hemant's patches submitted recently.
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg53457.html
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg54296.html
arch/arm/mach-omap2/board-ti8168evm.c | 39 +
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-ti8168evm.c
b/arch/arm/mach-omap2/board-ti8168evm.c
index e516a04..87953bb 100644
--- a/arch/arm/mach-omap2/board-ti8168evm.c
+++ b/arch/arm/mach-omap2/board-ti8168evm.c
@@ -14,6 +14,7 @@
*/
#include
#include
+#include
#include
#include
@@ -23,6 +24,42 @@
#include
#include
#include
+#include
+#include
+
+#include "board-flash.h"
+
+#define NAND_BLOCK_SIZESZ_128K
+
+static struct mtd_partition ti816x_nand_partitions[] = {
+/* All the partition sizes are listed in terms of NAND block size */
+ {
+ .name = "U-Boot",
+ .offset = 0,/* Offset = 0x0 */
+ .size = 18 * NAND_BLOCK_SIZE,
+ .mask_flags = MTD_WRITEABLE,/* force read-only */
+ },
+ {
+ .name = "U-Boot Env",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x24 */
+ .size = 2 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "Kernel",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x28 */
+ .size = 34 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "File System",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0x6C */
+ .size = 1601 * NAND_BLOCK_SIZE,
+ },
+ {
+ .name = "Reserved",
+ .offset = MTDPART_OFS_APPEND, /* Offset = 0xCEE */
+ .size = MTDPART_SIZ_FULL,
+ },
+};
static struct omap_board_config_kernel ti8168_evm_config[] __initdata = {
};
@@ -35,6 +72,8 @@ static void __init ti8168_init_early(void)
static void __init ti8168_evm_init(void)
{
+ board_nand_init(ti816x_nand_partitions,
+ ARRAY_SIZE(ti816x_nand_partitions), 0, NAND_BUSWIDTH_16);
omap_serial_init();
omap_board_config = ti8168_evm_config;
omap_board_config_size = ARRAY_SIZE(ti8168_evm_config);
--
1.6.2.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8 06/16] power: omap-prm: added chain interrupt handler
Hi Tero, On Fri, Sep 16, 2011 at 9:35 PM, Tero Kristo wrote: > Introduce a chained interrupt handler mechanism for the PRCM > interrupt, so that individual PRCM event can cleanly be handled by > handlers in separate drivers. We do this by introducing PRCM event > names, which are then matched to the particular PRCM interrupt bit > depending on the specific OMAP SoC being used. > > Driver detects the version of the PRM module in use via PRM hwmod > revision. This hwmod also defines the interrupt number for the chain > handler. Driver itself contains SoC specific data for register offsets > within the PRM module, and contains a list of supported PRCM interrupt > events. > > PRCM interrupts have two priority levels, high or normal. High priority > is needed for IO event handling, so that we can be sure that IO events > are processed before other events. This reduces latency for IO event > customers and also prevents incorrect ack sequence on OMAP3. > > Signed-off-by: Tero Kristo > Cc: Paul Walmsley > Cc: Kevin Hilman > Cc: Avinash.H.M > Cc: Cousson, Benoit > Cc: Tony Lindgren > Cc: Govindraj.R > --- > drivers/power/omap_prm.c | 351 > +++- > include/linux/power/omap_prm.h | 19 +++ > 2 files changed, 368 insertions(+), 2 deletions(-) > create mode 100644 include/linux/power/omap_prm.h > [..] > diff --git a/include/linux/power/omap_prm.h b/include/linux/power/omap_prm.h > new file mode 100644 > index 000..9b161b5 > --- /dev/null > +++ b/include/linux/power/omap_prm.h > @@ -0,0 +1,19 @@ > +/* > + * OMAP Power and Reset Management (PRM) driver > + * > + * Copyright (C) 2011 Texas Instruments, Inc. > + * > + * Author: Tero Kristo > + * > + * 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. > + */ > + > +#ifndef __LINUX_POWER_OMAP_PRM_H__ > +#define __LINUX_POWER_OMAP_PRM_H__ > + > +int omap_prcm_event_to_irq(const char *name); Minor comment, When omap_prm driver is not enabled by default leads to compilation break as in [1] So we should either have omap_prm driver default enabled from Kconfig or Have dummy omap_prcm_event_to_irq func if omap_prm is not defined. -- Thanks, Govindraj.R [1]: arch/arm/mach-omap2/built-in.o: In function `omap_mux_late_init': /home/ubnuser/clones/mirror/linux-omap-pm/arch/arm/mach-omap2/mux.c:799: undefined reference to `omap_prcm_event_to_irq' arch/arm/mach-omap2/built-in.o: In function `omap3_pm_init': /home/ubnuser/clones/mirror/linux-omap-pm/arch/arm/mach-omap2/pm34xx.c:817: undefined reference to `omap_prcm_event_to_irq' /home/ubnuser/clones/mirror/linux-omap-pm/arch/arm/mach-omap2/pm34xx.c:826: undefined reference to `omap_prcm_event_to_irq' make: *** [.tmp_vmlinux1] Error 1 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv8] 00/16] OMAP PRCM chain handler driver
On Fri, Sep 16, 2011 at 9:35 PM, Tero Kristo wrote: > Hello, > > This patch set is the version 8 for the OMAP PRCM chain interrupt handler. > The driver is providing a chain handler for PRCM interrupt events, which > can be then individually used by different drivers. Currently PRCM interrupt > is owned by the PM core code and it is impossible for other users to listen > to any of the PRCM events. Quite a few of the patches in this set are tagged > as TEMP, they are not meant for integration at this point, but are provided > as FYI for educated users and as a means to test the driver out. > > Changes compared to the previous set: > > - PRCM chain handler is now a driver of its own > - The driver gets PRCM IP info from omap hwmod and configures itself based > on this > - Added temporary implementations for OMAP3 and OMAP4 PRM hwmods > > Applies on top of Kevin's PM branch. > > Testing done: > > - platforms used: omap3 beagleboard and omap4430 blaze > - suspend / resume test with retention : ok on both > - cpuidle with retention test : ok on both > - off-mode testing : ok on omap3 (omap4 does not support off-mode yet) > > OMAP4 testing was done on top of a custom kernel tree, this patch set > does not work directly for omap4 on mainline. > Looks like you have CC'ed the wrong arm mailing list. I think it should be be linux-arm-ker...@lists.infradead.org -- Thanks, Govindraj.R -- To unsubscribe from this list: send the line "unsubscribe 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 v9] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers
Hi Keshava, On Thu, Sep 15, 2011 at 06:52:45PM +0530, Keshava Munegowda wrote: > From: Keshava Munegowda > > The Hwmod structures and Runtime PM features are implemented > For EHCI and OHCI drivers of OMAP3 and OMAP4. > The global suspend/resume of EHCI and OHCI > is validated on OMAP3430 sdp board with these patches. > > these patches are rebased to kevin's pm branch and > usbhs latest mainline kernel patches I'm ready to apply this one to my MFD for-next branch. Or do you want it to go through Kevin's tree ? Cheers, Samuel > TODO: >- Adding pad configurations to Hwmods >- Aggressive clock cutting in usb bus suspends >- Remote Wakeup implementation using irq-chaining > > > Benoit Cousson (1): > arm: omap: usb: ehci and ohci hwmod structures for omap4 > > Keshava Munegowda (4): > arm: omap: usb: ehci and ohci hwmod structures for omap3 > arm: omap: usb: register hwmods of usbhs > arm: omap: usb: device name change for the clk names of usbhs > mfd: omap: usb: Runtime PM support > > arch/arm/mach-omap2/clock3xxx_data.c | 26 +- > arch/arm/mach-omap2/clock44xx_data.c | 10 +- > arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 281 +++ > arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 247 ++ > arch/arm/mach-omap2/usb-host.c | 114 ++--- > arch/arm/plat-omap/include/plat/usb.h |3 - > drivers/mfd/omap-usb-host.c| 733 > +++- > drivers/usb/host/ehci-omap.c | 17 +- > drivers/usb/host/ohci-omap3.c | 18 +- > 9 files changed, 891 insertions(+), 558 deletions(-) > -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/5 v9] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers
On Mon, Sep 19, 2011 at 7:26 PM, Samuel Ortiz wrote: > Hi Keshava, > > On Thu, Sep 15, 2011 at 06:52:45PM +0530, Keshava Munegowda wrote: >> From: Keshava Munegowda >> >> The Hwmod structures and Runtime PM features are implemented >> For EHCI and OHCI drivers of OMAP3 and OMAP4. >> The global suspend/resume of EHCI and OHCI >> is validated on OMAP3430 sdp board with these patches. >> >> these patches are rebased to kevin's pm branch and >> usbhs latest mainline kernel patches > > I'm ready to apply this one to my MFD for-next branch. Or do you want it to go > through Kevin's tree ? > > Cheers, > Samuel Thanks samuel; But, patch 1 and 2 requires benoit causson's ack by; so , I am waiting for benoit response on this. please wait till I will cofirm for the merge; As of now, kevin and balbi are OK with these patches, benoit's confirmation/comments are pending. Thanks and regards keshava > > >> TODO: >> - Adding pad configurations to Hwmods >> - Aggressive clock cutting in usb bus suspends >> - Remote Wakeup implementation using irq-chaining >> >> >> Benoit Cousson (1): >> arm: omap: usb: ehci and ohci hwmod structures for omap4 >> >> Keshava Munegowda (4): >> arm: omap: usb: ehci and ohci hwmod structures for omap3 >> arm: omap: usb: register hwmods of usbhs >> arm: omap: usb: device name change for the clk names of usbhs >> mfd: omap: usb: Runtime PM support >> >> arch/arm/mach-omap2/clock3xxx_data.c | 26 +- >> arch/arm/mach-omap2/clock44xx_data.c | 10 +- >> arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 281 +++ >> arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 247 ++ >> arch/arm/mach-omap2/usb-host.c | 114 ++--- >> arch/arm/plat-omap/include/plat/usb.h | 3 - >> drivers/mfd/omap-usb-host.c | 733 >> +++- >> drivers/usb/host/ehci-omap.c | 17 +- >> drivers/usb/host/ohci-omap3.c | 18 +- >> 9 files changed, 891 insertions(+), 558 deletions(-) >> > > -- > Intel Open Source Technology Centre > http://oss.intel.com/ > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: READ THIS: the next mach-types update
Russell King - ARM Linux wrote on Saturday, September 17, 2011 8:04 PM: > On Sat, Sep 17, 2011 at 07:58:20PM +0530, Pedanekar, Hemant wrote: >> But since I had submitted v1 (see [1]) and am working on v2 post review, >> can you please suggest how to go about it as I will need the above for >> adding support for TI8148 EVM? > > The answer you require is in this statement: > > # This is a cut-down version of the file; it contains only > machines that > # are merged into mainline or have been edited in the machine database > # within the last 12 months. References to machine_is_NAME() > do not count! > > which highlights the policy. The key thing there is "edited". Thanks, got it. Hemant-- To unsubscribe from this list: send the line "unsubscribe 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 1/6] usb: musb: omap: Configure OTG_INTERFSEL for proper charger detection
On Fri, Sep 16, 2011 at 7:43 PM, Greg KH wrote: > On Fri, Sep 16, 2011 at 07:21:41PM +0530, ABRAHAM, KISHON VIJAY wrote: >> Sergei, >> >> Thanks for your comments. >> >> On Fri, Sep 16, 2011 at 3:18 PM, Sergei Shtylyov >> wrote: >> > Hello. >> > >> > On 15-09-2011 18:19, Kishon Vijay Abraham I wrote: >> > >> >> Setting OTG_INTERFSEL to UTMI interferes with charger detection resulting >> >> in incorrect detection of charger type. Hence OTG_INTERFSEL is configured >> >> to >> >> ULPI initially and changed to UTMI only after receiving USB_EVENT_ID or >> >> USB_EVENT_VBUS notification. >> > >> >> Signed-off-by: Kishon Vijay Abraham I >> >> Signed-off-by: Balaji T K >> > >> > AFAIK, full name is needed here. >> >> is it not the prerogative of the person giving his signed-off by?? > > Not really. > Certainly did not want to compete for long names :-) But Is Real Name + unique email id not sufficient. patches with this Signed-off . -- Thanks and Regards, Balaji T K -- To unsubscribe from this list: send the line "unsubscribe 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] mfd: Combine MFD_SUPPORT and MFD_CORE
On Thursday 15 September 2011, Grant Likely wrote: > > diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig > > index 21574bd..1836cdf 100644 > > --- a/drivers/mfd/Kconfig > > +++ b/drivers/mfd/Kconfig > > @@ -2,10 +2,9 @@ > > # Multifunction miscellaneous devices > > # > > > > -menuconfig MFD_SUPPORT > > - bool "Multifunction device drivers" > > +menuconfig MFD_CORE > > + tristate "Multifunction device drivers" > > depends on HAS_IOMEM > > - default y > > Looks like there is a bug here. Kconfig symbols with dependencies > (HAS_IOMEM) must not ever be selected by other symbols because Kconfig > doesn't implement a way to resolve them. This patch means that every > "select MFD_CORE" just assumes that HAS_IOMEM is also selected. That is probably a fair assumption though. Almost all architectures set HAS_IOMEM unconditionally, and the other ones (probably just s390) would not select MFD_CORE. Note that Samuel already took the other patch in the end, so it doesn't matter. The patch I posted encloses the entire directory in "if HAS_IOMEM". Arnd -- To unsubscribe from this list: send the line "unsubscribe 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] OMAP: omap_device: Add omap_device_[alloc|delete] for DT integration
On 9/19/2011 3:11 PM, Cousson, Benoit wrote:
On 9/17/2011 6:05 PM, Grant Likely wrote:
On Fri, Sep 16, 2011 at 04:43:18PM +0200, Benoit Cousson wrote:
[...]
- pr_debug("omap_device: %s: building with %d hwmods\n", pdev_name,
- oh_cnt);
+ /* Set the dev_name early to allow dev_xxx in omap_device_alloc */
+ if (pdev->id != -1)
+ dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);
+ else
+ dev_set_name(&pdev->dev, "%s", pdev->name);
This is duplicated from the core platform_device code. What is the
reasoning for doing it again here?
Well, it is written in the comment... But this is maybe not that obvious
:-)
That part is only needed for the legacy path that will create a
omap_device before having created the device, and thus at that time the
dev_xxx will not give the device name. This is not a big deal, but that
was painful for the debug.
That being said, by writing that, I'm now realizing that this is due to
the way the legacy code was working, because I didn't try to change the
sequence.
But maybe, I can easily avoid that by changing the original sequence.
In fact If I create the omap_device after the omap_device_register, the
platform_device will already have the correct name...
That should work, I'll give it a try.
Mmm, that's funny because it still does require to copy some part of the
platform_device_add to make that work.
This is now the resource name that are missing in that case :-(
So I will have to add at least that part to make that work:
if (r->name == NULL)
r->name = dev_name(&pdev->dev);
And the real function is doing s little bit more:
p = r->parent;
if (!p) {
if (resource_type(r) == IORESOURCE_MEM)
p = &iomem_resource;
else if (resource_type(r) == IORESOURCE_IO)
p = &ioport_resource;
}
if (p && insert_resource(p, r)) {
printk(KERN_ERR
"%s: failed to claim resource %d\n",
dev_name(&pdev->dev), i);
ret = -EBUSY;
goto failed;
}
It seems that in both cases, some part of the platform core code has to
be copied to make that work properly.
Except if someone has a better idea, I'd rather stick to the original
dev_set_name hack. Considering that this code should be removed at some
point anyway.
Any thoughts?
Regards,
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] misc: remove CONFIG_MISC_DEVICES
On Monday 19 September 2011, Greg KH wrote: > That sounds good to me, I'll be glad to collect the patches and push > them to Linus for both of those trees (might as well keep them in the > same git tree, no need to separate them, right?) and I'll rely on you > for review and acking them. Much like I do today for the tty and serial > trees. > > I'll go set up the trees locally today and when kernel.org opens back > up, make them public and add them to linux-next. Ok, great! Thanks, Arnd -- To unsubscribe from this list: send the line "unsubscribe 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/8] ispvideo: Add support for G/S/ENUM_STD ioctl
> -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Friday, September 16, 2011 6:36 PM > To: Ravi, Deepthy > Cc: linux-me...@vger.kernel.org; t...@atomide.com; li...@arm.linux.org.uk; > linux-omap@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux- > ker...@vger.kernel.org; mche...@infradead.org; g.liakhovet...@gmx.de; > Hiremath, Vaibhav > Subject: Re: [PATCH 4/8] ispvideo: Add support for G/S/ENUM_STD ioctl > > Hi Deepthy, > > On Friday 16 September 2011 15:00:53 Ravi, Deepthy wrote: > > On Thursday, September 08, 2011 10:51 PM Laurent Pinchart wrote: > > > On Thursday 08 September 2011 15:35:22 Deepthy Ravi wrote: > > >> From: Vaibhav Hiremath > > >> > > >> In order to support TVP5146 (for that matter any video decoder), > > >> it is important to support G/S/ENUM_STD ioctl on /dev/videoX > > >> device node. > > > > > > Why so ? Shouldn't it be queried on the subdev output pad directly ? > > > > Because standard v4l2 application for analog devices will call these std > > ioctls on the streaming device node. So it's done on /dev/video to make > the > > existing apllication work. > > Existing applications can't work with the OMAP3 ISP (and similar complex > embedded devices) without userspace support anyway, either in the form of > a > GStreamer element or a libv4l plugin. I still believe that analog video > standard operations should be added to the subdev pad operations and > exposed > through subdev device nodes, exactly as done with formats. > [Hiremath, Vaibhav] Laurent, I completely agree with your point that, existing application will not work without setting links properly. But I believe the assumption here is, media-controller should set the links (along with pad formants) and all existing application should work as is. Isn't it? The way it is being done currently is, set the format at the pad level which is same as analog standard resolution and use existing application for streaming... I am ok, if we add s/g/enum_std api support at sub-dev level but this should also be supported on streaming device node. Thanks, Vaibhav > -- > Regards, > > Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe 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/11] Add L2 cache cleaning to generic CPU suspend
On Sun, Sep 11, 2011 at 12:10:04AM +0800, Shawn Guo wrote: > On Thu, Sep 01, 2011 at 11:57:54PM +0800, Shawn Guo wrote: > > On Thu, Sep 01, 2011 at 04:34:51PM +0100, Russell King - ARM Linux wrote: > > > On Thu, Sep 01, 2011 at 11:33:43PM +0800, Shawn Guo wrote: > > > > This is also the case on i.MX6Q, which L2 cache is retained during a > > > > suspend/resume cycle. Currently, I have to call into the following > > > > before calling generic cpu_suspend() to clean/invalidate the entire > > > > L2 cache. > > > > > > > > outer_flush_all(); > > > > outer_disable(); > > > > > > > > But there is a wired thing on using generic cpu_resume(). I have to > > > > invalidate L1 before calling into cpu_resume() like below. > > > > > > > > ENTRY(imx6q_cpu_resume) > > > > bl v7_invalidate_l1 > > > > b cpu_resume > > > > ENDPROC(imx6q_cpu_resume) > > > > > > > > ENTRY(imx6q_secondary_startup) > > > > bl v7_invalidate_l1 > > > > b secondary_startup > > > > ENDPROC(imx6q_secondary_startup) > > > > > > > > The v7_invalidate_l1() is the function copied from mach-tegra/headsmp.S, > > > > which has to be called before calling secondary_startup to boot > > > > secondary cores (same situation between Tegra and i.MX6Q). > > > > > > Presumably that's because your L1 cache contains randomized data with > > > random validity (and presumably random dirtyness) at boot time - something > > > which unfortunately the ARM ARM permits. I don't think we can go to the > > > extent of dealing with this in the generic code as it would unnecessarily > > > perturb those implementations which either the boot loader has already > > > sorted out that issue, or which don't have the issue at all. > > > > > Yes, agreed. It seems that Tegra and i.MX6Q are the only two CA9MP > > cases here. But is it possible to maintain this v7_invalidate_l1() > > function in cache-v7.S, so that we do not need to duplicate it in > > platform codes? > > > > > > Before applying this patch series, I have something like below actually > > > > working. > > > > > > > > > > > > outer_flush_all(); > > > > outer_disable(); > > > > imx_set_cpu_jump(0, imx6q_cpu_resume); > > > > /* Zzz ... */ > > > > cpu_suspend(0, imx6q_suspend_finish); > > > > > > > > I expect with you patches applied, I can still have it work with simply > > > > removing those two lines outer cache codes. > > > > > > That should be the case. > > > > > > > But unfortunately, I'm > > > > running into Oops when resuming back. And I also have Oops with > > > > imx_set_cpu_jump(0, cpu_resume) which means skipping the > > > > v7_invalidate_l1() and calling generic cpu_resume() only. > > > > > > Do you have a copy of the oops? > > > > > > Hi Russell, > > After following your great debugging clue that we need to enable L2 > before calling into generic cpu_resume(), now this patch series works > great for imx6q. Thanks a lot, and here is my tag. > > Tested-by: Shawn Guo Is that for all these patches? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/11] ARM: pm: convert some assembly to C
On Wed, Sep 07, 2011 at 04:48:28PM +0100, Lorenzo Pieralisi wrote: > > @@ -29,8 +48,7 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned > > long)) > > * resume (indicated by a zero return code), we need to switch > > * back to the correct page tables. > > */ > > - ret = __cpu_suspend(virt_to_phys(suspend_pgd), > > - PHYS_OFFSET - PAGE_OFFSET, arg, fn); > > + ret = __cpu_suspend(arg, fn); > > if (ret == 0) > > cpu_switch_mm(mm->pgd, mm); > > It is still early testing, but without a local tlb flush here I am getting > random segmentation faults in user space. > My fear is that 1:1 global TLB entries cause issues if user space processes > happen to map those pages at addresses overlapping 1:1 mapping set-up for > resume and we do not flush the TLB. Yes, having the global TLB entry potentially in userspace is a problem. I don't think we can get around this any other way than by calling local_flush_tlb_all() here. I'll post an updated series shortly. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/7] Add L2 cache cleaning to generic CPU suspend
This is a re-post of the previous patch series, but with an additional TLB flush to ensure that hte global TLB entry in the page tables is flushed out. This is a flush of all TLB entries, but it could probably be more targetted if we need to. Original cover mail follows: Some systems (such as OMAP) preserve the L2 cache across a suspend/ resume cycle. This means they do not perform L2 cache maintanence in their suspend finisher function. However, the side effect is that the saved CPU state is not readable by the resume code because it is sitting in the L2 cache. This patch series adds L2 cache cleaning to the generic CPU suspend/ resume support code, making it possible to use this on systems with L2 cache enabled without having to clean/invalidate the entire L2 cache. We also add a separate page table, allocated at boot time, for the resume process to use so we don't have to fiddle about with tweaking entries in the current processes page table. Moreover, the current processes page table may be in use by another CPU in the system if these paths are used from cpuidle or hotplug, so changing the page table is technically unsound. Overall, this makes it possible for OMAP4 systems to use this code. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/7] ARM: pm: force non-zero return value from __cpu_suspend when aborting
Ensure that the return value from __cpu_suspend is non-zero when
aborting. Zero indicates a successful suspend occurred.
Tested-by: Santosh Shilimkar
Signed-off-by: Russell King
---
arch/arm/kernel/sleep.S |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index dc902f2..46a9f46 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -61,6 +61,8 @@ ENDPROC(__cpu_suspend)
cpu_suspend_abort:
ldmia sp!, {r1 - r3} @ pop v:p, virt SP, phys resume fn
+ teq r0, #0
+ moveq r0, #1 @ force non-zero value
mov sp, r2
ldmfd sp!, {r4 - r11, pc}
ENDPROC(cpu_suspend_abort)
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/7] ARM: pm: preallocate a page table for suspend/resume
Preallocate a page table and setup an identity mapping for the MMU
enable code. This means we don't have to "borrow" a page table to
do this, avoiding complexities with L2 cache coherency.
Tested-by: Santosh Shilimkar
Signed-off-by: Russell King
---
arch/arm/include/asm/suspend.h | 17 +-
arch/arm/kernel/Makefile |2 +-
arch/arm/kernel/sleep.S| 33 ++-
arch/arm/kernel/suspend.c | 48
arch/arm/mm/proc-arm920.S |4 ---
arch/arm/mm/proc-arm926.S |4 ---
arch/arm/mm/proc-sa1100.S |4 ---
arch/arm/mm/proc-v6.S |6 -
arch/arm/mm/proc-v7.S |6 -
arch/arm/mm/proc-xsc3.S|6 -
arch/arm/mm/proc-xscale.S |4 ---
11 files changed, 62 insertions(+), 72 deletions(-)
create mode 100644 arch/arm/kernel/suspend.c
diff --git a/arch/arm/include/asm/suspend.h b/arch/arm/include/asm/suspend.h
index b0e4e1a..1c0a551 100644
--- a/arch/arm/include/asm/suspend.h
+++ b/arch/arm/include/asm/suspend.h
@@ -1,22 +1,7 @@
#ifndef __ASM_ARM_SUSPEND_H
#define __ASM_ARM_SUSPEND_H
-#include
-#include
-
extern void cpu_resume(void);
-
-/*
- * Hide the first two arguments to __cpu_suspend - these are an implementation
- * detail which platform code shouldn't have to know about.
- */
-static inline int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
-{
- extern int __cpu_suspend(int, long, unsigned long,
-int (*)(unsigned long));
- int ret = __cpu_suspend(0, PHYS_OFFSET - PAGE_OFFSET, arg, fn);
- flush_tlb_all();
- return ret;
-}
+extern int cpu_suspend(unsigned long, int (*)(unsigned long));
#endif
diff --git a/arch/arm/kernel/Makefile b/arch/arm/kernel/Makefile
index f7887dc..787b888 100644
--- a/arch/arm/kernel/Makefile
+++ b/arch/arm/kernel/Makefile
@@ -29,7 +29,7 @@ obj-$(CONFIG_MODULES) += armksyms.o module.o
obj-$(CONFIG_ARTHUR) += arthur.o
obj-$(CONFIG_ISA_DMA) += dma-isa.o
obj-$(CONFIG_PCI) += bios32.o isa.o
-obj-$(CONFIG_PM_SLEEP) += sleep.o
+obj-$(CONFIG_PM_SLEEP) += sleep.o suspend.o
obj-$(CONFIG_HAVE_SCHED_CLOCK) += sched_clock.o
obj-$(CONFIG_SMP) += smp.o smp_tlb.o
obj-$(CONFIG_HAVE_ARM_SCU) += smp_scu.o
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 46a9f46..8cf13de 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -27,7 +27,7 @@ ENTRY(__cpu_suspend)
sub sp, sp, r5 @ allocate CPU state on stack
mov r0, sp @ save pointer to CPU save block
add ip, ip, r1 @ convert resume fn to phys
- stmfd sp!, {r1, r6, ip} @ save v:p, virt SP, phys resume fn
+ stmfd sp!, {r6, ip} @ save virt SP, phys resume fn
ldr r5, =sleep_save_sp
add r6, sp, r1 @ convert SP to phys
stmfd sp!, {r2, r3} @ save suspend func arg and pointer
@@ -60,7 +60,7 @@ ENDPROC(__cpu_suspend)
.ltorg
cpu_suspend_abort:
- ldmia sp!, {r1 - r3} @ pop v:p, virt SP, phys resume fn
+ ldmia sp!, {r2 - r3} @ pop virt SP, phys resume fn
teq r0, #0
moveq r0, #1 @ force non-zero value
mov sp, r2
@@ -74,28 +74,19 @@ ENDPROC(cpu_suspend_abort)
* r3 = L1 section flags
*/
ENTRY(cpu_resume_mmu)
- adr r4, cpu_resume_turn_mmu_on
- mov r4, r4, lsr #20
- orr r3, r3, r4, lsl #20
- ldr r5, [r2, r4, lsl #2]@ save old mapping
- str r3, [r2, r4, lsl #2]@ setup 1:1 mapping for mmu code
- sub r2, r2, r1
ldr r3, =cpu_resume_after_mmu
- bic r1, r0, #CR_C @ ensure D-cache is disabled
b cpu_resume_turn_mmu_on
ENDPROC(cpu_resume_mmu)
.ltorg
.align 5
-cpu_resume_turn_mmu_on:
- mcr p15, 0, r1, c1, c0, 0 @ turn on MMU, I-cache, etc
- mrc p15, 0, r1, c0, c0, 0 @ read id reg
- mov r1, r1
- mov r1, r1
+ENTRY(cpu_resume_turn_mmu_on)
+ mcr p15, 0, r0, c1, c0, 0 @ turn on MMU, I-cache, etc
+ mrc p15, 0, r0, c0, c0, 0 @ read id reg
+ mov r0, r0
+ mov r0, r0
mov pc, r3 @ jump to virtual address
ENDPROC(cpu_resume_turn_mmu_on)
cpu_resume_after_mmu:
- str r5, [r2, r4, lsl #2]@ restore old mapping
- mcr p15, 0, r0, c1, c0, 0 @ turn on D-cache
bl cpu_init@ restore the und/abt/irq banked regs
mov r0, #0 @ return zero on success
ldmfd sp!, {r4 - r11, pc}
@@ -121,11 +112,11 @@ ENTRY(cpu_resume)
ldr r0, sleep_save_sp @ stack phys addr
#endif
setmode PSR_I_BIT | PSR_F_BIT | SVC_MODE, r1 @ set SVC, irqs off
-
Re: [RFC PATCH 1/6] usb: musb: omap: Configure OTG_INTERFSEL for proper charger detection
On Mon, Sep 19, 2011 at 08:26:08PM +0530, T Krishnamoorthy, Balaji wrote: > On Fri, Sep 16, 2011 at 7:43 PM, Greg KH wrote: > > On Fri, Sep 16, 2011 at 07:21:41PM +0530, ABRAHAM, KISHON VIJAY wrote: > >> Sergei, > >> > >> Thanks for your comments. > >> > >> On Fri, Sep 16, 2011 at 3:18 PM, Sergei Shtylyov > >> wrote: > >> > Hello. > >> > > >> > On 15-09-2011 18:19, Kishon Vijay Abraham I wrote: > >> > > >> >> Setting OTG_INTERFSEL to UTMI interferes with charger detection > >> >> resulting > >> >> in incorrect detection of charger type. Hence OTG_INTERFSEL is > >> >> configured > >> >> to > >> >> ULPI initially and changed to UTMI only after receiving USB_EVENT_ID or > >> >> USB_EVENT_VBUS notification. > >> > > >> >> Signed-off-by: Kishon Vijay Abraham I > >> >> Signed-off-by: Balaji T K > >> > > >> > AFAIK, full name is needed here. > >> > >> is it not the prerogative of the person giving his signed-off by?? > > > > Not really. > > > > Certainly did not want to compete for long names :-) > But Is Real Name + unique email id not sufficient. > patches with this Signed-off . Real Name + unique email is sufficient. If "Balaji T K" is the real name here, then my sincere apologies at getting this incorrect. If it isn't, a few more letters might be sufficient, or even, native utf-8 characters for the name in the native language is also ok. I know I get enough problems with my "odd" last name to be aware that there are lots of misconceptions about what is a real and not-real way to spell/handle a name, so again, if I am mistaken here, please let me know. 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
Re: [PATCH 0/5 v9] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers
Hi Keshava, On 9/19/2011 4:01 PM, Munegowda, Keshava wrote: On Mon, Sep 19, 2011 at 7:26 PM, Samuel Ortiz wrote: Hi Keshava, On Thu, Sep 15, 2011 at 06:52:45PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda The Hwmod structures and Runtime PM features are implemented For EHCI and OHCI drivers of OMAP3 and OMAP4. The global suspend/resume of EHCI and OHCI is validated on OMAP3430 sdp board with these patches. these patches are rebased to kevin's pm branch and usbhs latest mainline kernel patches I'm ready to apply this one to my MFD for-next branch. Or do you want it to go through Kevin's tree ? Cheers, Samuel Thanks samuel; But, patch 1 and 2 requires benoit causson's ack by; so , I am waiting for benoit response on this. I made a couple of comments in the v8, and you did address only half of them. It will be nice to at least answer the remaining points. Moreover, Paul is the maintainer of the OMAP3 hwmod data file. Regards, Benoit -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Add support for dmtimer v2 ip (Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver)
* Pedanekar, Hemant [110918 20:32]: > > Tony, > Kernel boots fine on TI816X (should also boot on TI814X) with your patch > and patches (including OSC clock fix) from series > http://www.spinics.net/lists/linux-omap/msg57011.html OK good to hear, I assume I can add your Tested-by then? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Add support for dmtimer v2 ip (Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver)
* DebBarma, Tarun Kanti [110918 04:53]: > > > > But we can map the interrupt registers separately and then have > > the rest start from func_base that is different based on the timer > > version. Rebasing the rest of the dmtimer hwmod patches on this > > should be fairly easy, mostly just need to pass timer instead of > > timer->io_base and use __raw_read/write for the interrupt registers. > I went through the patch. It definitely looks much more simplified now. > I will rebase on top of this change. OK thanks, can I add your Acked-by then? Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: Add support for dmtimer v2 ip (Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver)
* Mohammed, Afzal [110918 21:48]: > Hi Tony, > > On Sat, Sep 17, 2011 at 07:05:31, Tony Lindgren wrote: > > > > Afzal, care to check if that works for AM335X/TI816X/TI814X? > > With following patch over yours, AM335X (the only board with me) boots up > fine. Thanks for catching that, will fold it in with your Signed-off-by. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 7/7] ARM: pm: add L2 cache cleaning for suspend
We need to ensure that state is pushed out from the L2 cache when suspending so that the resume paths can access their data before the MMU and caches have been re-initialized. Add the necessary calls to __cpu_suspend_save(). Tested-by: Santosh Shilimkar Signed-off-by: Russell King --- arch/arm/kernel/suspend.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c index 2d60f19..93a22d2 100644 --- a/arch/arm/kernel/suspend.c +++ b/arch/arm/kernel/suspend.c @@ -28,6 +28,9 @@ void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32 *save_ptr) cpu_do_suspend(ptr); flush_cache_all(); + outer_clean_range(*save_ptr, *save_ptr + ptrsz); + outer_clean_range(virt_to_phys(save_ptr), + virt_to_phys(save_ptr) + sizeof(*save_ptr)); } /* -- 1.7.4.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/7] ARM: pm: convert some assembly to C
Convert some of the sleep.S guts to C code, which makes it easier to
use our macros and to add L2 cache handling. We provide a helper
function, __cpu_suspend_save(), which deals with saving the common
state, setting up for resume, and flushing caches.
The remainder left as assembly code is the saving of the CPU general
purpose registers, and allocating space on the stack to save the CPU
specific registers and resume state.
Tested-by: Santosh Shilimkar
Signed-off-by: Russell King
---
arch/arm/include/asm/proc-fns.h |8 ++
arch/arm/kernel/sleep.S | 53 --
arch/arm/kernel/suspend.c | 24 +++--
3 files changed, 46 insertions(+), 39 deletions(-)
diff --git a/arch/arm/include/asm/proc-fns.h b/arch/arm/include/asm/proc-fns.h
index 633d1cb..9e92cb2 100644
--- a/arch/arm/include/asm/proc-fns.h
+++ b/arch/arm/include/asm/proc-fns.h
@@ -81,6 +81,10 @@ extern void cpu_dcache_clean_area(void *, int);
extern void cpu_do_switch_mm(unsigned long pgd_phys, struct mm_struct *mm);
extern void cpu_set_pte_ext(pte_t *ptep, pte_t pte, unsigned int ext);
extern void cpu_reset(unsigned long addr) __attribute__((noreturn));
+
+/* These three are private to arch/arm/kernel/suspend.c */
+extern void cpu_do_suspend(void *);
+extern void cpu_do_resume(void *);
#else
#define cpu_proc_init processor._proc_init
#define cpu_proc_fin processor._proc_fin
@@ -89,6 +93,10 @@ extern void cpu_reset(unsigned long addr)
__attribute__((noreturn));
#define cpu_dcache_clean_area processor.dcache_clean_area
#define cpu_set_pte_extprocessor.set_pte_ext
#define cpu_do_switch_mm processor.switch_mm
+
+/* These three are private to arch/arm/kernel/suspend.c */
+#define cpu_do_suspend processor.do_suspend
+#define cpu_do_resume processor.do_resume
#endif
extern void cpu_resume(void);
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index c9a43ca..020e99c 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -8,54 +8,35 @@
.text
/*
- * Save CPU state for a suspend
- * r0 = phys addr of temporary page tables
- * r1 = v:p offset
- * r2 = suspend function arg0
- * r3 = suspend function
+ * Save CPU state for a suspend. This saves the CPU general purpose
+ * registers, and allocates space on the kernel stack to save the CPU
+ * specific registers and some other data for resume.
+ * r0 = suspend function arg0
+ * r1 = suspend function
*/
ENTRY(__cpu_suspend)
stmfd sp!, {r4 - r11, lr}
- mov r4, r0
#ifdef MULTI_CPU
ldr r10, =processor
- ldr r5, [r10, #CPU_SLEEP_SIZE] @ size of CPU sleep state
- ldr ip, [r10, #CPU_DO_RESUME] @ virtual resume function
+ ldr r4, [r10, #CPU_SLEEP_SIZE] @ size of CPU sleep state
#else
- ldr r5, =cpu_suspend_size
- ldr ip, =cpu_do_resume
+ ldr r4, =cpu_suspend_size
#endif
- mov r6, sp @ current virtual SP
- sub sp, sp, r5 @ allocate CPU state on stack
- mov r0, sp @ save pointer to CPU save block
- add ip, ip, r1 @ convert resume fn to phys
- stmfd sp!, {r4, r6, ip} @ save phys pgd, virt SP, phys resume fn
- ldr r5, =sleep_save_sp
- add r6, sp, r1 @ convert SP to phys
- stmfd sp!, {r2, r3} @ save suspend func arg and pointer
+ mov r5, sp @ current virtual SP
+ add r4, r4, #12 @ Space for pgd, virt sp, phys resume fn
+ sub sp, sp, r4 @ allocate CPU state on stack
+ stmfd sp!, {r0, r1} @ save suspend func arg and pointer
+ add r0, sp, #8 @ save pointer to save block
+ mov r1, r4 @ size of save block
+ mov r2, r5 @ virtual SP
+ ldr r3, =sleep_save_sp
#ifdef CONFIG_SMP
ALT_SMP(mrc p15, 0, lr, c0, c0, 5)
ALT_UP(mov lr, #0)
and lr, lr, #15
- str r6, [r5, lr, lsl #2]@ save phys SP
-#else
- str r6, [r5]@ save phys SP
-#endif
-#ifdef MULTI_CPU
- mov lr, pc
- ldr pc, [r10, #CPU_DO_SUSPEND] @ save CPU state
-#else
- bl cpu_do_suspend
-#endif
-
- @ flush data cache
-#ifdef MULTI_CACHE
- ldr r10, =cpu_cache
- mov lr, pc
- ldr pc, [r10, #CACHE_FLUSH_KERN_ALL]
-#else
- bl __cpuc_flush_kern_all
+ add r3, r3, lr, lsl #2
#endif
+ bl __cpu_suspend_save
adr lr, BSYM(cpu_suspend_abort)
ldmfd sp!, {r0, pc} @ call suspend fn
ENDPROC(__cpu_suspend)
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index ed4160b..2d60f19 100644
--- a/arch/arm/kernel/suspend.c
+
[PATCH 4/7] ARM: pm: no need to save/restore context ID register
There is no need to save and restore the context ID register on ARMv6
and ARMv7 with a temporary page table as we write the context ID
register when we switch back to the real page tables for the thread.
Moreover, the temporary page tables do not contain any non-global
mappings, so the context ID value should not be used. To be safe,
initialize the register to a reserved context ID value.
Tested-by: Santosh Shilimkar
Signed-off-by: Russell King
---
arch/arm/mm/proc-v6.S | 33 -
arch/arm/mm/proc-v7.S | 13 ++---
2 files changed, 22 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mm/proc-v6.S b/arch/arm/mm/proc-v6.S
index 2e27b46..d061d2f 100644
--- a/arch/arm/mm/proc-v6.S
+++ b/arch/arm/mm/proc-v6.S
@@ -128,19 +128,18 @@ ENTRY(cpu_v6_set_pte_ext)
/* Suspend/resume support: taken from arch/arm/mach-s3c64xx/sleep.S */
.globl cpu_v6_suspend_size
-.equ cpu_v6_suspend_size, 4 * 7
+.equ cpu_v6_suspend_size, 4 * 6
#ifdef CONFIG_PM_SLEEP
ENTRY(cpu_v6_do_suspend)
- stmfd sp!, {r4 - r10, lr}
+ stmfd sp!, {r4 - r9, lr}
mrc p15, 0, r4, c13, c0, 0 @ FCSE/PID
- mrc p15, 0, r5, c13, c0, 1 @ Context ID
- mrc p15, 0, r6, c3, c0, 0 @ Domain ID
- mrc p15, 0, r7, c2, c0, 1 @ Translation table base 1
- mrc p15, 0, r8, c1, c0, 1 @ auxiliary control register
- mrc p15, 0, r9, c1, c0, 2 @ co-processor access control
- mrc p15, 0, r10, c1, c0, 0 @ control register
- stmia r0, {r4 - r10}
- ldmfd sp!, {r4- r10, pc}
+ mrc p15, 0, r5, c3, c0, 0 @ Domain ID
+ mrc p15, 0, r6, c2, c0, 1 @ Translation table base 1
+ mrc p15, 0, r7, c1, c0, 1 @ auxiliary control register
+ mrc p15, 0, r8, c1, c0, 2 @ co-processor access control
+ mrc p15, 0, r9, c1, c0, 0 @ control register
+ stmia r0, {r4 - r9}
+ ldmfd sp!, {r4- r9, pc}
ENDPROC(cpu_v6_do_suspend)
ENTRY(cpu_v6_do_resume)
@@ -149,19 +148,19 @@ ENTRY(cpu_v6_do_resume)
mcr p15, 0, ip, c7, c5, 0 @ invalidate I cache
mcr p15, 0, ip, c7, c15, 0 @ clean+invalidate cache
mcr p15, 0, ip, c7, c10, 4 @ drain write buffer
- ldmia r0, {r4 - r10}
+ mcr p15, 0, ip, c13, c0, 1 @ set reserved context ID
+ ldmia r0, {r4 - r9}
mcr p15, 0, r4, c13, c0, 0 @ FCSE/PID
- mcr p15, 0, r5, c13, c0, 1 @ Context ID
- mcr p15, 0, r6, c3, c0, 0 @ Domain ID
+ mcr p15, 0, r5, c3, c0, 0 @ Domain ID
ALT_SMP(orr r1, r1, #TTB_FLAGS_SMP)
ALT_UP(orr r1, r1, #TTB_FLAGS_UP)
mcr p15, 0, r1, c2, c0, 0 @ Translation table base 0
- mcr p15, 0, r7, c2, c0, 1 @ Translation table base 1
- mcr p15, 0, r8, c1, c0, 1 @ auxiliary control register
- mcr p15, 0, r9, c1, c0, 2 @ co-processor access control
+ mcr p15, 0, r6, c2, c0, 1 @ Translation table base 1
+ mcr p15, 0, r7, c1, c0, 1 @ auxiliary control register
+ mcr p15, 0, r8, c1, c0, 2 @ co-processor access control
mcr p15, 0, ip, c2, c0, 2 @ TTB control register
mcr p15, 0, ip, c7, c5, 4 @ ISB
- mov r0, r10 @ control register
+ mov r0, r9 @ control register
b cpu_resume_mmu
ENDPROC(cpu_v6_do_resume)
#endif
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index b56004f..6af366c 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -217,14 +217,13 @@ ENDPROC(cpu_v7_set_pte_ext)
/* Suspend/resume support: derived from arch/arm/mach-s5pv210/sleep.S */
.globl cpu_v7_suspend_size
-.equ cpu_v7_suspend_size, 4 * 8
+.equ cpu_v7_suspend_size, 4 * 7
#ifdef CONFIG_PM_SLEEP
ENTRY(cpu_v7_do_suspend)
stmfd sp!, {r4 - r10, lr}
mrc p15, 0, r4, c13, c0, 0 @ FCSE/PID
- mrc p15, 0, r5, c13, c0, 1 @ Context ID
- mrc p15, 0, r6, c13, c0, 3 @ User r/o thread ID
- stmia r0!, {r4 - r6}
+ mrc p15, 0, r5, c13, c0, 3 @ User r/o thread ID
+ stmia r0!, {r4 - r5}
mrc p15, 0, r6, c3, c0, 0 @ Domain ID
mrc p15, 0, r7, c2, c0, 1 @ TTB 1
mrc p15, 0, r8, c1, c0, 0 @ Control register
@@ -238,10 +237,10 @@ ENTRY(cpu_v7_do_resume)
mov ip, #0
mcr p15, 0, ip, c8, c7, 0 @ invalidate TLBs
mcr p15, 0, ip, c7, c5, 0 @ invalidate I cache
- ldmia r0!, {r4 - r6}
+ mcr p15, 0, ip, c13, c0, 1 @ set reserved context ID
+ ldmia r0!, {r4 - r5}
mcr p15, 0, r4, c13, c0, 0 @ FCSE/PID
- mcr p15, 0, r5, c13, c0, 1 @ Context ID
- mcr p15, 0, r6, c13, c0, 3 @ User r/o thread ID
+ mcr p15, 0, r5, c13, c0, 3 @ User r/o thread ID
ldmia r0, {r6 - r10}
mcr p15, 0, r6, c3, c0, 0 @ Domain ID
A
[PATCH 3/7] ARM: pm: only use preallocated page table during resume
Only use the preallocated page table during the resume, not while
suspending. This avoids the overhead of having to switch unnecessarily
to the resume page table in the suspend path.
Tested-by: Santosh Shilimkar
Signed-off-by: Russell King
---
arch/arm/kernel/sleep.S | 19 +--
arch/arm/kernel/suspend.c | 17 ++---
arch/arm/mm/proc-arm920.S | 17 -
arch/arm/mm/proc-arm926.S | 17 -
arch/arm/mm/proc-sa1100.S | 21 ++---
arch/arm/mm/proc-v6.S | 31 ---
arch/arm/mm/proc-v7.S | 33 +
arch/arm/mm/proc-xsc3.S | 22 +++---
arch/arm/mm/proc-xscale.S | 21 ++---
9 files changed, 99 insertions(+), 99 deletions(-)
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 8cf13de..25d42df 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -9,12 +9,14 @@
/*
* Save CPU state for a suspend
+ * r0 = phys addr of temporary page tables
* r1 = v:p offset
* r2 = suspend function arg0
* r3 = suspend function
*/
ENTRY(__cpu_suspend)
stmfd sp!, {r4 - r11, lr}
+ mov r4, r0
#ifdef MULTI_CPU
ldr r10, =processor
ldr r5, [r10, #CPU_SLEEP_SIZE] @ size of CPU sleep state
@@ -27,7 +29,7 @@ ENTRY(__cpu_suspend)
sub sp, sp, r5 @ allocate CPU state on stack
mov r0, sp @ save pointer to CPU save block
add ip, ip, r1 @ convert resume fn to phys
- stmfd sp!, {r6, ip} @ save virt SP, phys resume fn
+ stmfd sp!, {r4, r6, ip} @ save phys pgd, virt SP, phys resume fn
ldr r5, =sleep_save_sp
add r6, sp, r1 @ convert SP to phys
stmfd sp!, {r2, r3} @ save suspend func arg and pointer
@@ -60,7 +62,7 @@ ENDPROC(__cpu_suspend)
.ltorg
cpu_suspend_abort:
- ldmia sp!, {r2 - r3} @ pop virt SP, phys resume fn
+ ldmia sp!, {r1 - r3} @ pop phys pgd, virt SP, phys resume fn
teq r0, #0
moveq r0, #1 @ force non-zero value
mov sp, r2
@@ -69,9 +71,6 @@ ENDPROC(cpu_suspend_abort)
/*
* r0 = control register value
- * r1 = v:p offset (preserved by cpu_do_resume)
- * r2 = phys page table base
- * r3 = L1 section flags
*/
ENTRY(cpu_resume_mmu)
ldr r3, =cpu_resume_after_mmu
@@ -112,11 +111,11 @@ ENTRY(cpu_resume)
ldr r0, sleep_save_sp @ stack phys addr
#endif
setmode PSR_I_BIT | PSR_F_BIT | SVC_MODE, r1 @ set SVC, irqs off
- @ load stack, resume fn
- ARM( ldmia r0!, {sp, pc} )
-THUMB( ldmia r0!, {r2, r3} )
-THUMB( mov sp, r2 )
-THUMB( bx r3 )
+ @ load phys pgd, stack, resume fn
+ ARM( ldmia r0!, {r1, sp, pc} )
+THUMB( ldmia r0!, {r1, r2, r3} )
+THUMB( mov sp, r2 )
+THUMB( bx r3 )
ENDPROC(cpu_resume)
sleep_save_sp:
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 0a33f10..2beda56 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -24,14 +24,17 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
return -EINVAL;
/*
-* Temporarily switch the page tables to our suspend page
-* tables, which contain the temporary identity mapping
-* required for resuming.
+* Provide a temporary page table with an identity mapping for
+* the MMU-enable code, required for resuming. On successful
+* resume (indicated by a zero return code), we need to switch
+* back to the correct page tables.
*/
- cpu_switch_mm(suspend_pgd, mm);
- ret = __cpu_suspend(0, PHYS_OFFSET - PAGE_OFFSET, arg, fn);
- cpu_switch_mm(mm->pgd, mm);
- local_flush_tlb_all();
+ ret = __cpu_suspend(virt_to_phys(suspend_pgd),
+ PHYS_OFFSET - PAGE_OFFSET, arg, fn);
+ if (ret == 0) {
+ cpu_switch_mm(mm->pgd, mm);
+ local_flush_tlb_all();
+ }
return ret;
}
diff --git a/arch/arm/mm/proc-arm920.S b/arch/arm/mm/proc-arm920.S
index 035d57b..88fb3d9 100644
--- a/arch/arm/mm/proc-arm920.S
+++ b/arch/arm/mm/proc-arm920.S
@@ -379,27 +379,26 @@ ENTRY(cpu_arm920_set_pte_ext)
/* Suspend/resume support: taken from arch/arm/plat-s3c24xx/sleep.S */
.globl cpu_arm920_suspend_size
-.equ cpu_arm920_suspend_size, 4 * 4
+.equ cpu_arm920_suspend_size, 4 * 3
#ifdef CONFIG_PM_SLEEP
ENTRY(cpu_arm920_do_suspend)
- stmfd sp!, {r4 - r7, lr}
+ stmfd sp!, {r4 - r6, lr}
mrc p15, 0, r4, c13, c0, 0 @ PID
mrc p15, 0, r5, c3, c0, 0 @ Domain ID
- mrc p15, 0, r6, c2, c0, 0 @ TTB address
- mrc p15, 0, r7, c1, c0, 0 @ Control
[PATCH 5/7] ARM: pm: get rid of cpu_resume_turn_mmu_on
We don't require cpu_resume_turn_mmu_on as we can combine the ldr
instruction with the following code provided we ensure that
cpu_resume_mmu is aligned for older CPUs. Note that we also align
to a 32-byte boundary to ensure that the code can't cross a section
boundary.
Tested-by: Santosh Shilimkar
Signed-off-by: Russell King
---
arch/arm/kernel/sleep.S |8 ++--
arch/arm/kernel/suspend.c |4 ++--
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/arch/arm/kernel/sleep.S b/arch/arm/kernel/sleep.S
index 25d42df..c9a43ca 100644
--- a/arch/arm/kernel/sleep.S
+++ b/arch/arm/kernel/sleep.S
@@ -72,19 +72,15 @@ ENDPROC(cpu_suspend_abort)
/*
* r0 = control register value
*/
+ .align 5
ENTRY(cpu_resume_mmu)
ldr r3, =cpu_resume_after_mmu
- b cpu_resume_turn_mmu_on
-ENDPROC(cpu_resume_mmu)
- .ltorg
- .align 5
-ENTRY(cpu_resume_turn_mmu_on)
mcr p15, 0, r0, c1, c0, 0 @ turn on MMU, I-cache, etc
mrc p15, 0, r0, c0, c0, 0 @ read id reg
mov r0, r0
mov r0, r0
mov pc, r3 @ jump to virtual address
-ENDPROC(cpu_resume_turn_mmu_on)
+ENDPROC(cpu_resume_mmu)
cpu_resume_after_mmu:
bl cpu_init@ restore the und/abt/irq banked regs
mov r0, #0 @ return zero on success
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 2beda56..ed4160b 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -9,7 +9,7 @@
static pgd_t *suspend_pgd;
extern int __cpu_suspend(int, long, unsigned long, int (*)(unsigned long));
-extern void cpu_resume_turn_mmu_on(void);
+extern void cpu_resume_mmu(void);
/*
* Hide the first two arguments to __cpu_suspend - these are an implementation
@@ -43,7 +43,7 @@ static int __init cpu_suspend_init(void)
{
suspend_pgd = pgd_alloc(&init_mm);
if (suspend_pgd) {
- unsigned long addr = virt_to_phys(cpu_resume_turn_mmu_on);
+ unsigned long addr = virt_to_phys(cpu_resume_mmu);
identity_mapping_add(suspend_pgd, addr, addr + SECTION_SIZE);
}
return suspend_pgd ? 0 : -ENOMEM;
--
1.7.4.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
Hi
On Sun, 18 Sep 2011, Laurent Pinchart wrote:
> Hi Martin,
>
> On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote:
> > Adds board support for an MT9M032 based camera to omap3evm.
> >
> > Sigend-off-by: Martin Hostettler
> > ---
> > arch/arm/mach-omap2/Makefile|1 +
> > arch/arm/mach-omap2/board-omap3evm-camera.c | 183
> > +++ 2 files changed, 184 insertions(+), 0
> > deletions(-)
> > create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c
> >
> > Changes in V2:
> > * ported to current mainline
> > * Style fixes
> > * Fix error handling
> >
> > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> > index f343365..8ae3d25 100644
> > --- a/arch/arm/mach-omap2/Makefile
> > +++ b/arch/arm/mach-omap2/Makefile
> > @@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO)+=
> > board-omap3logic.o \ obj-$(CONFIG_MACH_OVERO) +=
> > board-overo.o \
> >hsmmc.o
> > obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \
> > + board-omap3evm-camera.o \
> >hsmmc.o
> > obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \
> >hsmmc.o
> > diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c
> > b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644
> > index 000..be987d9
> > --- /dev/null
> > +++ b/arch/arm/mach-omap2/board-omap3evm-camera.c
> > @@ -0,0 +1,183 @@
[snip]
> > +static int __init camera_init(void)
> > +{
> > + int ret = -EINVAL;
> > +
> > + omap_mux_init_gpio(nCAM_VD_SEL, OMAP_PIN_OUTPUT);
> > + if (gpio_request(nCAM_VD_SEL, "nCAM_VD_SEL") < 0) {
> > + pr_err("omap3evm-camera: Failed to get GPIO nCAM_VD_SEL(%d)\n",
> > + nCAM_VD_SEL);
> > + goto err;
> > + }
> > + if (gpio_direction_output(nCAM_VD_SEL, 1) < 0) {
> > + pr_err("omap3evm-camera: Failed to set GPIO nCAM_VD_SEL(%d)
> > direction\n", +nCAM_VD_SEL);
> > + goto err_vdsel;
> > + }
> > +
> > + if (gpio_request(EVM_TWL_GPIO_BASE + 2, "T2_GPIO2") < 0) {
> > + pr_err("omap3evm-camera: Failed to get GPIO T2_GPIO2(%d)\n",
> > + EVM_TWL_GPIO_BASE + 2);
> > + goto err_vdsel;
> > + }
> > + if (gpio_direction_output(EVM_TWL_GPIO_BASE + 2, 0) < 0) {
> > + pr_err("omap3evm-camera: Failed to set GPIO T2_GPIO2(%d)
> > direction\n",
> > + EVM_TWL_GPIO_BASE + 2);
> > + goto err_2;
> > + }
> > +
> > + if (gpio_request(EVM_TWL_GPIO_BASE + 8, "nCAM_VD_EN") < 0) {
> > + pr_err("omap3evm-camera: Failed to get GPIO nCAM_VD_EN(%d)\n",
> > + EVM_TWL_GPIO_BASE + 8);
> > + goto err_2;
> > + }
> > + if (gpio_direction_output(EVM_TWL_GPIO_BASE + 8, 0) < 0) {
> > + pr_err("omap3evm-camera: Failed to set GPIO nCAM_VD_EN(%d)
> > direction\n",
> > + EVM_TWL_GPIO_BASE + 8);
> > + goto err_8;
> > + }
> > +
> > + omap3evm_set_mux(MUX_CAMERA_SENSOR);
> > +
> > +
> > + ret = omap3_init_camera(&isp_platform_data);
> > + if (ret < 0)
> > + goto err_8;
> > + return 0;
> > +
> > +err_8:
> > + gpio_free(EVM_TWL_GPIO_BASE + 8);
> > +err_2:
> > + gpio_free(EVM_TWL_GPIO_BASE + 2);
> > +err_vdsel:
> > + gpio_free(nCAM_VD_SEL);
> > +err:
> > + return ret;
> > +}
> > +
> > +device_initcall(camera_init);
>
> Please don't use device_initcall(), but call the function directly from the
> OMAP3 EVM init handler. Otherwise camera_init() will be called if OMAP3 EVM
> support is compiled in the kernel, regardless of the board the kernel runs on.
Another possibility is to put
if (!machine_is_omap3evm())
return 0;
in the beginning of the function. Probably, best to follow what other
omap3 boards do.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.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 v2] arm: omap3evm: Add support for an MT9M032 based camera board.
On Mon, Sep 19, 2011 at 11:37:37AM +0530, Hiremath, Vaibhav wrote: > > > -Original Message- > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart > > Sent: Monday, September 19, 2011 3:29 AM > > To: Martin Hostettler > > Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux- > > me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > > Subject: Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based > > camera board. > > > > Hi Martin, > > > > On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote: > > > Adds board support for an MT9M032 based camera to omap3evm. > > > > > > Sigend-off-by: Martin Hostettler > > > --- > > > arch/arm/mach-omap2/Makefile|1 + > > > arch/arm/mach-omap2/board-omap3evm-camera.c | 183 > > > +++ 2 files changed, 184 insertions(+), 0 > > > deletions(-) > > > create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c > > > > > > Changes in V2: > > > * ported to current mainline > > > * Style fixes > > > * Fix error handling > > > > > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile > > > index f343365..8ae3d25 100644 > > > --- a/arch/arm/mach-omap2/Makefile > > > +++ b/arch/arm/mach-omap2/Makefile > > > @@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= > > > board-omap3logic.o \ obj-$(CONFIG_MACH_OVERO) += > > > board-overo.o \ > > > hsmmc.o > > > obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \ > > > +board-omap3evm-camera.o \ > > > hsmmc.o > > > obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ > > > hsmmc.o > > > diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c > > > b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644 > > > index 000..be987d9 > > > --- /dev/null > > > +++ b/arch/arm/mach-omap2/board-omap3evm-camera.c > > > @@ -0,0 +1,183 @@ > > > +/* > > > + * Copyright (C) 2010-2011 Lund Engineering > > > + * Contact: Gil Lund > > > + * Author: Martin Hostettler > > > + * > [Hiremath, Vaibhav] The file below seems copied from (which is coming from > all older releases of TI) > > http://arago-project.org/git/projects/?p=linux-omap3.git;a=blob;f=arch/arm/mach-omap2/board-omap3evm-camera.c;h=2e6ccfef69027dee880d507b98b5a7998d4bbe7e;hb=adcd067326836777c049e3cb32a5b7d9d401fc31 > > So I would appreciate if you keep original copyright and authorship of the > file and add your sign-off to the patch. > First of all i don't have any problem Adding your name and the TI copyright. Maybe i should have been more careful when looking at and adeption omap3evm_set_mux as i really took that from the TI code. I honestly don't remember if i took any other code from that file or not. It ends up doing what the hardware needs anyway. For me it doesn't matter with such trival things, but i should have been more careful. Do you consider it resolved if use the following at the start? /* * Copyright (C) 2010 Texas Instruments Inc * Copyright (C) 2010-2011 Lund Engineering * Contact: Gil Lund * Authors: *Vaibhav Hiremath *Martin Hostettler */ But then again the copy on my harddisk has these too... * Contributors: * Anuj Aggarwal * Sivaraj R Maybe i should add them too. Not sure really... - Martin Hostettler -- To unsubscribe from this list: send the line "unsubscribe 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/3] OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting
> -Original Message-
> From: Taneja, Archit
> Sent: Friday, September 16, 2011 12:09 PM
> To: Valkeinen, Tomi
> Cc: Hiremath, Vaibhav; linux-omap@vger.kernel.org; Taneja, Archit; linux-
> me...@vger.kernel.org; Molnar, Lajos
> Subject: [PATCH v2 1/3] OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha
> compatibility setting
>
[Hiremath, Vaibhav] Few minor comments below -
> On OMAP3, in order to enable alpha blending for LCD and TV managers, we
> needed
> to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
> OMAP4, alpha blending is always enabled by default, if the above bits are
> set,
> we switch to an OMAP3 compatibility mode where the zorder values in the
> pipeline
[Hiremath, Vaibhav] Spelling mistake???
> attribute registers are ignored and a fixed priority is configured.
>
> Rename the manager_info member "alpha_enabled" to "partial_alpha_enabled"
> for
> more clarity. Introduce two dss_features FEAT_ALPHA_FIXED_ZORDER and
> FEAT_ALPHA_FREE_ZORDER which represent OMAP3-alpha compatibility mode and
> OMAP4
> alpha mode respectively. Introduce an overlay cap for ZORDER. The DSS2
> user is
> expected to check for the ZORDER cap, if an overlay doesn't have this cap,
> the
> user is expected to set the parameter partial_alpha_enabled. If the
> overlay has
> ZORDER cap, the DSS2 user can assume that alpha blending is already
> enabled.
>
> Don't support OMAP3 compatibility mode for now. Trying to read/write to
> alpha_blending_enabled sysfs attribute issues a warning for OMAP4 and does
> not
> set the LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits.
>
> Change alpha_enabled to partial_alpha_enabled int the omap_vout driver.
> Use
> overlay cap "OMAP_DSS_OVL_CAP_GLOBAL_ALPHA" to check if overlay supports
> alpha
> blending or not. Replace this with checks for VIDEO1 pipeline.
>
> Initial patch was made by: Lajos Molnar
>
[Hiremath, Vaibhav] I think you can put his sign-off as well and remove this
line or move it below ---
> Cc: linux-me...@vger.kernel.org
> Cc: Lajos Molnar
> Signed-off-by: Archit Taneja
> ---
> drivers/media/video/omap/omap_vout.c | 16 +++-
> drivers/video/omap2/dss/dispc.c| 24
> drivers/video/omap2/dss/dss.h |4 ++--
> drivers/video/omap2/dss/dss_features.c | 22 +++---
> drivers/video/omap2/dss/dss_features.h |3 ++-
> drivers/video/omap2/dss/manager.c | 28 +++
> -
> include/video/omapdss.h|3 ++-
> 7 files changed, 59 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/media/video/omap/omap_vout.c
> b/drivers/media/video/omap/omap_vout.c
> index b3a5ecd..95daf98 100644
> --- a/drivers/media/video/omap/omap_vout.c
> +++ b/drivers/media/video/omap/omap_vout.c
> @@ -1165,12 +1165,17 @@ static int vidioc_try_fmt_vid_overlay(struct file
> *file, void *fh,
> {
> int ret = 0;
> struct omap_vout_device *vout = fh;
> + struct omap_overlay *ovl;
> + struct omapvideo_info *ovid;
> struct v4l2_window *win = &f->fmt.win;
>
> + ovid = &vout->vid_info;
> + ovl = ovid->overlays[0];
> +
[Hiremath, Vaibhav] I think it will be helpful if you put some comment above
this line on why video1, something like,
/*
* Global alpha is not supported on Video1 pipeline/overlay
*/
> ret = omap_vout_try_window(&vout->fbuf, win);
>
> if (!ret) {
> - if (vout->vid == OMAP_VIDEO1)
> + if ((ovl->caps & OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
> win->global_alpha = 255;
> else
> win->global_alpha = f->fmt.win.global_alpha;
> @@ -1194,8 +1199,7 @@ static int vidioc_s_fmt_vid_overlay(struct file
> *file, void *fh,
>
> ret = omap_vout_new_window(&vout->crop, &vout->win, &vout->fbuf,
> win);
> if (!ret) {
> - /* Video1 plane does not support global alpha */
> - if (ovl->id == OMAP_DSS_VIDEO1)
> + if ((ovl->caps & OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
> vout->win.global_alpha = 255;
> else
> vout->win.global_alpha = f->fmt.win.global_alpha;
> @@ -1788,7 +1792,9 @@ static int vidioc_s_fbuf(struct file *file, void *fh,
> if (ovl->manager && ovl->manager->get_manager_info &&
> ovl->manager->set_manager_info) {
> ovl->manager->get_manager_info(ovl->manager, &info);
> - info.alpha_enabled = enable;
> + /* enable this only if there is no zorder cap */
> + if ((ovl->caps & OMAP_DSS_OVL_CAP_ZORDER) == 0)
> + info.partial_alpha_enabled = enable;
> if (ovl->manager->set_manager_info(ovl->manager, &info))
> return -EINVAL;
> }
> @@ -1820,7 +1826,7 @@ static int vidioc_g_fbuf(struct file *file, void *fh,
> }
> if (ovl->manager && ovl->manager->get_manager_info) {
> ovl-
RE: [PATCH v2 2/3] OMAPDSS: DISPC: VIDEO3 pipeline support
> -Original Message-
> From: Taneja, Archit
> Sent: Friday, September 16, 2011 12:09 PM
> To: Valkeinen, Tomi
> Cc: Hiremath, Vaibhav; linux-omap@vger.kernel.org; Taneja, Archit
> Subject: [PATCH v2 2/3] OMAPDSS: DISPC: VIDEO3 pipeline support
>
> Add support for VIDEO3 pipeline on OMAP4:
> - Add VIDEO3 pipeline information in dss_features and omapdss.h
> - Add VIDEO3 pipeline register coefficients in dispc.h
> - Create a new overlay structure corresponding to VIDEO3.
> - Make changes in dispc.c for VIDEO3
>
> Signed-off-by: Archit Taneja
> ---
> drivers/video/omap2/dss/dispc.c| 17 --
> drivers/video/omap2/dss/dispc.h| 57
>
> drivers/video/omap2/dss/dss_features.c | 18 +-
> drivers/video/omap2/dss/dss_features.h |2 +-
> drivers/video/omap2/dss/overlay.c |5 +++
> include/video/omapdss.h|5 ++-
> 6 files changed, 97 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/omap2/dss/dispc.c
> b/drivers/video/omap2/dss/dispc.c
> index e0639d3..fa7aadf 100644
> --- a/drivers/video/omap2/dss/dispc.c
> +++ b/drivers/video/omap2/dss/dispc.c
> @@ -751,7 +751,7 @@ static void dispc_ovl_set_pre_mult_alpha(enum
> omap_plane plane, bool enable)
>
> static void dispc_ovl_setup_global_alpha(enum omap_plane plane, u8
> global_alpha)
> {
> - static const unsigned shifts[] = { 0, 8, 16, };
> + static const unsigned shifts[] = { 0, 8, 16, 24, };
> int shift;
> struct omap_overlay *ovl = omap_dss_get_overlay(plane);
>
> @@ -866,6 +866,7 @@ static void dispc_ovl_set_channel_out(enum omap_plane
> plane,
> break;
> case OMAP_DSS_VIDEO1:
> case OMAP_DSS_VIDEO2:
> + case OMAP_DSS_VIDEO3:
> shift = 16;
> break;
> default:
> @@ -903,7 +904,7 @@ static void dispc_ovl_set_channel_out(enum omap_plane
> plane,
> static void dispc_ovl_set_burst_size(enum omap_plane plane,
> enum omap_burst_size burst_size)
> {
> - static const unsigned shifts[] = { 6, 14, 14, };
> + static const unsigned shifts[] = { 6, 14, 14, 14, };
> int shift;
>
> shift = shifts[plane];
> @@ -988,7 +989,7 @@ static void dispc_ovl_set_vid_color_conv(enum
> omap_plane plane, bool enable)
>
> static void dispc_ovl_enable_replication(enum omap_plane plane, bool
> enable)
> {
> - static const unsigned shifts[] = { 5, 10, 10 };
> + static const unsigned shifts[] = { 5, 10, 10, 10 };
> int shift;
>
> shift = shifts[plane];
> @@ -2558,6 +2559,10 @@ void dispc_dump_irqs(struct seq_file *s)
> PIS(VID1_END_WIN);
> PIS(VID2_FIFO_UNDERFLOW);
> PIS(VID2_END_WIN);
> + if (dss_feat_get_num_ovls() > 3) {
> + PIS(VID3_FIFO_UNDERFLOW);
> + PIS(VID3_END_WIN);
> + }
> PIS(SYNC_LOST);
> PIS(SYNC_LOST_DIGIT);
> PIS(WAKEUP);
> @@ -2583,6 +2588,7 @@ void dispc_dump_regs(struct seq_file *s)
> [OMAP_DSS_GFX] = "GFX",
> [OMAP_DSS_VIDEO1] = "VID1",
> [OMAP_DSS_VIDEO2] = "VID2",
> + [OMAP_DSS_VIDEO3] = "VID3",
> };
> const char **p_names;
>
> @@ -2985,6 +2991,8 @@ static void print_irq_status(u32 status)
> PIS(OCP_ERR);
> PIS(VID1_FIFO_UNDERFLOW);
> PIS(VID2_FIFO_UNDERFLOW);
> + if (dss_feat_get_num_ovls() > 3)
> + PIS(VID3_FIFO_UNDERFLOW);
> PIS(SYNC_LOST);
> PIS(SYNC_LOST_DIGIT);
> if (dss_has_feature(FEAT_MGR_LCD2))
> @@ -3082,6 +3090,7 @@ static void dispc_error_worker(struct work_struct
> *work)
> DISPC_IRQ_GFX_FIFO_UNDERFLOW,
> DISPC_IRQ_VID1_FIFO_UNDERFLOW,
> DISPC_IRQ_VID2_FIFO_UNDERFLOW,
> + DISPC_IRQ_VID3_FIFO_UNDERFLOW,
> };
>
> static const unsigned sync_lost_bits[] = {
> @@ -3257,6 +3266,8 @@ static void _omap_dispc_initialize_irq(void)
> dispc.irq_error_mask = DISPC_IRQ_MASK_ERROR;
> if (dss_has_feature(FEAT_MGR_LCD2))
> dispc.irq_error_mask |= DISPC_IRQ_SYNC_LOST2;
> + if (dss_feat_get_num_ovls() > 3)
> + dispc.irq_error_mask |= DISPC_IRQ_VID3_FIFO_UNDERFLOW;
>
> /* there's SYNC_LOST_DIGIT waiting after enabling the DSS,
>* so clear it */
> diff --git a/drivers/video/omap2/dss/dispc.h
> b/drivers/video/omap2/dss/dispc.h
> index 6c9ee0a..c06efc3 100644
> --- a/drivers/video/omap2/dss/dispc.h
> +++ b/drivers/video/omap2/dss/dispc.h
> @@ -291,6 +291,8 @@ static inline u16 DISPC_OVL_BASE(enum omap_plane
> plane)
> return 0x00BC;
> case OMAP_DSS_VIDEO2:
> return 0x014C;
> + case OMAP_DSS_VIDEO3:
> + return 0x0300;
> default:
> BUG();
> }
> @@ -304,6 +306,8 @@ static inline u16 DISPC_BA0_OFFSET(enum omap_plane
> plane)
> case OMAP_DSS_VIDEO1:
> case OMAP_DSS_VIDEO2:
> return 0x;
> + case
RE: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based camera board.
> -Original Message- > From: mar...@neutronstar.dyndns.org [mailto:mar...@neutronstar.dyndns.org] > Sent: Tuesday, September 20, 2011 12:55 AM > To: Hiremath, Vaibhav > Cc: Laurent Pinchart; Tony Lindgren; linux-omap@vger.kernel.org; linux- > me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > Subject: Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 based > camera board. > > On Mon, Sep 19, 2011 at 11:37:37AM +0530, Hiremath, Vaibhav wrote: > > > > > -Original Message- > > > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > > > ow...@vger.kernel.org] On Behalf Of Laurent Pinchart > > > Sent: Monday, September 19, 2011 3:29 AM > > > To: Martin Hostettler > > > Cc: Tony Lindgren; linux-omap@vger.kernel.org; linux- > > > me...@vger.kernel.org; linux-arm-ker...@lists.infradead.org > > > Subject: Re: [PATCH v2] arm: omap3evm: Add support for an MT9M032 > based > > > camera board. > > > > > > Hi Martin, > > > > > > On Saturday 17 September 2011 11:34:57 Martin Hostettler wrote: > > > > Adds board support for an MT9M032 based camera to omap3evm. > > > > > > > > Sigend-off-by: Martin Hostettler > > > > --- > > > > arch/arm/mach-omap2/Makefile|1 + > > > > arch/arm/mach-omap2/board-omap3evm-camera.c | 183 > > > > +++ 2 files changed, 184 insertions(+), 0 > > > > deletions(-) > > > > create mode 100644 arch/arm/mach-omap2/board-omap3evm-camera.c > > > > > > > > Changes in V2: > > > > * ported to current mainline > > > > * Style fixes > > > > * Fix error handling > > > > > > > > diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach- > omap2/Makefile > > > > index f343365..8ae3d25 100644 > > > > --- a/arch/arm/mach-omap2/Makefile > > > > +++ b/arch/arm/mach-omap2/Makefile > > > > @@ -202,6 +202,7 @@ obj-$(CONFIG_MACH_OMAP3_TORPEDO)+= > > > > board-omap3logic.o \ obj-$(CONFIG_MACH_OVERO) += board- > overo.o \ > > > >hsmmc.o > > > > obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \ > > > > + board-omap3evm-camera.o \ > > > >hsmmc.o > > > > obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ > > > >hsmmc.o > > > > diff --git a/arch/arm/mach-omap2/board-omap3evm-camera.c > > > > b/arch/arm/mach-omap2/board-omap3evm-camera.c new file mode 100644 > > > > index 000..be987d9 > > > > --- /dev/null > > > > +++ b/arch/arm/mach-omap2/board-omap3evm-camera.c > > > > @@ -0,0 +1,183 @@ > > > > +/* > > > > + * Copyright (C) 2010-2011 Lund Engineering > > > > + * Contact: Gil Lund > > > > + * Author: Martin Hostettler > > > > + * > > [Hiremath, Vaibhav] The file below seems copied from (which is coming > from all older releases of TI) > > > > http://arago-project.org/git/projects/?p=linux- > omap3.git;a=blob;f=arch/arm/mach-omap2/board-omap3evm- > camera.c;h=2e6ccfef69027dee880d507b98b5a7998d4bbe7e;hb=adcd067326836777c04 > 9e3cb32a5b7d9d401fc31 > > > > So I would appreciate if you keep original copyright and authorship of > the file and add your sign-off to the patch. > > > > First of all i don't have any problem Adding your name and the TI > copyright. > Maybe i should have been more careful when looking at and adeption > omap3evm_set_mux as i really took that from the TI code. > The best practice it to always keep copy-right of the file intact... I wouldn't mind if you use and modify any part of the code and also add your authorship. I feel, Copy-right is important part. > I honestly don't remember if i took any other code from that file or not. > It ends up doing what the hardware needs anyway. For me it doesn't matter > with such trival things, but i should have been more careful. > > Do you consider it resolved if use the following at the start? > > /* > * Copyright (C) 2010 Texas Instruments Inc Change it to 2011. > * Copyright (C) 2010-2011 Lund Engineering > * Contact: Gil Lund Not sure do you really need above line... > * Authors: > *Vaibhav Hiremath > *Martin Hostettler > */ > > Looks ok to me. > But then again the copy on my harddisk has these too... > > * Contributors: > * Anuj Aggarwal > * Sivaraj R > > Maybe i should add them too. > > Not sure really... > > I think we should not pollute source file with all our names, so I would recommend to put copy rights and probably author. Thanks, Vaibhav > - Martin Hostettler -- To unsubscribe from this list: send the line "unsubscribe 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/5 v8] arm: omap: usb: ehci and ohci hwmod structures for omap4
OK, it looks like the second half of the answer was in a second email...
that makes sense:-)
On 9/15/2011 9:22 AM, Munegowda, Keshava wrote:
On Thu, Sep 15, 2011 at 11:25 AM, Munegowda, Keshava
wrote:
On Wed, Sep 14, 2011 at 10:20 PM, Cousson, Benoit wrote:
Hi Keshava,
On 8/25/2011 9:01 AM, Munegowda, Keshava wrote:
From: Benoit Cousson
Following 4 hwmod structures are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson
That version is really different compared to my original patch, so you should
highlight the diff you introduced.
Since there are too many changes are done compare to your original
patch; i prefer keep a single patch,rather
keeping your original patch and my changes are another patch.
This is not really what I was asking for. You changed at least 30% of
the original patch without mentioning anything in the changelog.
You should at least add a history to clarify what part you edited /
added compared to the original.
Signed-off-by: Keshava Munegowda
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 247
1 files changed, 247 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..0bc01dd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,10 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
None of the 3 last entries are master, and thus should not need any backward
declaration.
yes, I will make this change.
But you didn't...
/*
* Interconnects omap_hwmod structures
@@ -5336,6 +5340,245 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master =&omap44xx_usb_host_hs_hwmod,
+ .slave =&omap44xx_l3_main_2_hwmod,
+ .clk= "l3_div_ck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE |
+ MSTANDBY_NO | MSTANDBY_SMART |
+ MSTANDBY_SMART_WKUP),
Minor, but it should be:
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields=&omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = "usbhs_uhh",
+ .sysc =&omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+&omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = "uhh",
In general, there is no name for unique entry. And if you need a name, you
should find something relevant considering this is local to the hwmod.
No answer and no change on that one.
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {} /* Terminating Entry */
That comment is useless. Paul added one space inside the terminator as well.
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master =&omap44xx_l4_cfg_hwmod,
+ .slave =&omap44xx_usb_host_hs_hwmod,
+ .clk= "l4_div_ck",
+ .addr = omap44xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+&omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+ .name = "usbhs_uhh",
+ .class =&omap44xx_usb_host_hs_hwmod_class,
+ .clkdm_name = "l3_init_clkdm",
+ .main_clk = "usb_host_hs_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs
Re: [PATCH 1/5 v9] arm: omap: usb: ehci and ohci hwmod structures for omap4
Keshava,
I've just replied to your previous v8 version about the comments you
didn't take into account.
I just have one minor nit on that one I missed previously, plus a couple
of clarifications.
On 9/15/2011 3:22 PM, Munegowda, Keshava wrote:
From: Benoit Cousson
Following 4 hwmod structures are added:
UHH hwmod of usbhs with uhh base address and functional clock,
EHCI hwmod with irq and base address,
OHCI hwmod with irq and base address,
TLL hwmod of usbhs with the TLL base address and irq.
Signed-off-by: Benoit Cousson
Signed-off-by: Keshava Munegowda
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 249 +++-
1 files changed, 248 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 6201422..f06efa6 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -68,6 +68,10 @@ static struct omap_hwmod omap44xx_mmc2_hwmod;
static struct omap_hwmod omap44xx_mpu_hwmod;
static struct omap_hwmod omap44xx_mpu_private_hwmod;
static struct omap_hwmod omap44xx_usb_otg_hs_hwmod;
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ohci_hwmod;
+static struct omap_hwmod omap44xx_usbhs_ehci_hwmod;
+static struct omap_hwmod omap44xx_usb_tll_hs_hwmod;
/*
* Interconnects omap_hwmod structures
@@ -5336,6 +5340,244 @@ static struct omap_hwmod omap44xx_wd_timer3_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
+/*
+ * 'usb_host_hs' class
+ * high-speed multi-port usb host controller
+ */
+static struct omap_hwmod_ocp_if omap44xx_usb_host_hs__l3_main_2 = {
+ .master =&omap44xx_usb_host_hs_hwmod,
+ .slave =&omap44xx_l3_main_2_hwmod,
+ .clk= "l3_div_ck",
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_class_sysconfig omap44xx_usb_host_hs_sysc = {
+ .rev_offs = 0x,
+ .sysc_offs = 0x0010,
+ .syss_offs = 0x0014,
+ .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_SIDLEMODE),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
+ SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
+ MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
+ .sysc_fields=&omap_hwmod_sysc_type2,
+};
+
+static struct omap_hwmod_class omap44xx_usb_host_hs_hwmod_class = {
+ .name = "usbhs_uhh",
+ .sysc =&omap44xx_usb_host_hs_sysc,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_masters[] = {
+ &omap44xx_usb_host_hs__l3_main_2,
+};
+
+static struct omap_hwmod_addr_space omap44xx_usb_host_hs_addrs[] = {
+ {
+ .name = "uhh",
+ .pa_start = 0x4a064000,
+ .pa_end = 0x4a0647ff,
+ .flags = ADDR_TYPE_RT
+ },
+ {}
+};
+
+static struct omap_hwmod_ocp_if omap44xx_l4_cfg__usb_host_hs = {
+ .master =&omap44xx_l4_cfg_hwmod,
+ .slave =&omap44xx_usb_host_hs_hwmod,
+ .clk= "l4_div_ck",
+ .addr = omap44xx_usb_host_hs_addrs,
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+static struct omap_hwmod_ocp_if *omap44xx_usb_host_hs_slaves[] = {
+ &omap44xx_l4_cfg__usb_host_hs,
+};
+
+static struct omap_hwmod omap44xx_usb_host_hs_hwmod = {
+ .name = "usbhs_uhh",
+ .class =&omap44xx_usb_host_hs_hwmod_class,
+ .clkdm_name = "l3_init_clkdm",
+ .main_clk = "usb_host_hs_fck",
+ .prcm = {
+ .omap4 = {
+ .clkctrl_offs = OMAP4_CM_L3INIT_USB_HOST_CLKCTRL_OFFSET,
+ .context_offs = OMAP4_RM_L3INIT_USB_HOST_CONTEXT_OFFSET,
+ .modulemode = MODULEMODE_SWCTRL,
+ },
+ },
+ .slaves = omap44xx_usb_host_hs_slaves,
+ .slaves_cnt = ARRAY_SIZE(omap44xx_usb_host_hs_slaves),
+ .masters= omap44xx_usb_host_hs_masters,
+ .masters_cnt= ARRAY_SIZE(omap44xx_usb_host_hs_masters),
+ .flags = HWMOD_SWSUP_SIDLE | HWMOD_SWSUP_MSTANDBY,
Why do you need these flags? These flags are reserved for non-standard
behavior / HW bugs. I know that this IP is full of various bugs, but it
will be nice to add some explanation in the changelog and a small
comment here as well.
+ .omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
+};
+
+/* 'usbhs_ohci' class */
+static struct omap_hwmod_class omap44xx_usbhs_ohci_hwmod_class = {
+ .name = "usbhs_ohci",
+};
+
+static struct omap_hwmod_irq_info omap44xx_usbhs_ohci_irqs[] = {
+ { .name = "ohci-irq", .irq = 76 + OMAP44XX_IRQ_GIC_START },
+ { .irq = -1 }
+};
+
+static struct omap_hwmod_addr_space omap44xx_usbhs_ohci_addrs[] = {
+ {
+ .name = "ohci",
+ .p
Re: [PATCHv2 0/6] OMAP: DSS: porting old drivers to DSS2 (board files part)
* Tomi Valkeinen [110919 00:05]: > Hi Tony, > > On Mon, 2011-09-12 at 14:20 +0300, Tomi Valkeinen wrote: > > This patch set ports all the OMAP2/3 boards, except N8x0, that use the old > > omapfb to use the newer DSS2 driver. Only board files are changed, the panel > > driver additions are done in separate patch set. Applying this set without > > the > > driver changes will obviously disable the displays of the affected boards > > until > > the drivers are also merged. > > > > Some board files contained old omapfb code, but there wasn't a matching LCD > > driver. That board file code is also removed. > > Any chances to get these in for the next merge window? These will remove > most of the OMAP2/3 users of the old omapfb, and when the old omapfb is > used only by OMAP1, we can remove quite a bit of code there. OK thanks for cleaning this up. Will apply these to board branch. Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] CPUIdle: Reevaluate C-states under CPU load to favor deeper C-states
From: Nicole Chalhoub
While there is CPU load, program a C-state specific one-shot timer in
order to give CPUidle another opportunity to pick a deeper C-state
instead of spending potentially long idle times in a shallow C-state.
Long winded version:
When going idle with a high load average, CPUidle menu governor will
decide to pick a shallow C-state since one of the guiding principles
of the menu governor is "The busier the system, the less impact of
C-states is acceptable" (taken from cpuidle/governors/menu.c.)
That makes perfect sense.
However, there are missed power-saving opportunities for bursty
workloads with long idle times (e.g. MP3 playback.) Given such a
workload, because of the load average, CPUidle tends to pick a shallow
C-state. Because we also go tickless, this shallow C-state is used
for the duration of the idle period. If the idle period is long, a
deeper C state would've resulted in better power savings.
This patch provides an additional opportuntity for CPUidle to pick a
deeper C-state by programming a timer (with a C-state specific timeout)
such that the CPUidle governor will have another opportunity to pick a
deeper C-state.
Adding this timer for C-state reevaluation improved the load estimation
on our ARM/OMAP4 platform and increased the time spent in deep C-states
(~50% of idle time in C-states deeper than C1). A power saving of ~10mA
at battery level is observed during MP3 playback on OMAP4/Blaze board.
Signed-off-by: Nicole Chalhoub
Signed-off-by: Kevin Hilman
---
drivers/cpuidle/cpuidle.c| 28 +-
drivers/cpuidle/governors/menu.c | 39 -
include/linux/cpuidle.h |4 +++
3 files changed, 63 insertions(+), 8 deletions(-)
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index 1994885..4b1ac0c 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -92,13 +92,33 @@ static void cpuidle_idle_call(void)
target_state->time += (unsigned long long)dev->last_residency;
target_state->usage++;
- /* give the governor an opportunity to reflect on the outcome */
- if (cpuidle_curr_governor->reflect)
+ hrtimer_cancel(&dev->cstate_timer);
+
+ /*
+* Give the governor an opportunity to reflect on the outcome
+* Do not take into account the wakeups due to the hrtimer, they
+* should not impact the predicted idle time.
+*/
+ if ((!dev->hrtimer_expired) && cpuidle_curr_governor->reflect)
cpuidle_curr_governor->reflect(dev);
trace_power_end(0);
}
/**
+ * cstate_reassessment_timer - interrupt handler of the cstate hrtimer
+ * @handle:the expired hrtimer
+ */
+static enum hrtimer_restart cstate_reassessment_timer(struct hrtimer *handle)
+{
+ struct cpuidle_device *data =
+ container_of(handle, struct cpuidle_device, cstate_timer);
+
+ data->hrtimer_expired = 1;
+
+ return HRTIMER_NORESTART;
+}
+
+/**
* cpuidle_install_idle_handler - installs the cpuidle idle loop handler
*/
void cpuidle_install_idle_handler(void)
@@ -185,6 +205,10 @@ int cpuidle_enable_device(struct cpuidle_device *dev)
dev->enabled = 1;
+ dev->hrtimer_expired = 0;
+ hrtimer_init(&dev->cstate_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+ dev->cstate_timer.function = cstate_reassessment_timer;
+
enabled_devices++;
return 0;
diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
index 1b12870..fd54584 100644
--- a/drivers/cpuidle/governors/menu.c
+++ b/drivers/cpuidle/governors/menu.c
@@ -125,10 +125,21 @@ struct menu_device {
#define LOAD_INT(x) ((x) >> FSHIFT)
#define LOAD_FRAC(x) LOAD_INT(((x) & (FIXED_1-1)) * 100)
-static int get_loadavg(void)
+static int get_loadavg(struct cpuidle_device *dev)
{
- unsigned long this = this_cpu_load();
+ unsigned long this;
+ /*
+* this_cpu_load() returns the value of rq->load.weight
+* at the previous scheduler tick and not the current value.
+* If the timer expired, that means we are in idle,there
+* are no more runnable processes in the current queue
+* =>return the current value of rq->load.weight which is 0.
+*/
+ if (dev->hrtimer_expired == 1)
+ return 0;
+ else
+ this = this_cpu_load();
return LOAD_INT(this) * 10 + LOAD_FRAC(this) / 10;
}
@@ -166,13 +177,13 @@ static inline int which_bucket(unsigned int duration)
* to be, the higher this multiplier, and thus the higher
* the barrier to go to an expensive C state.
*/
-static inline int performance_multiplier(void)
+static inline int performance_multiplier(struct cpuidle_device *dev)
{
int mult = 1;
/* for higher loadavg, we are more reluctant */
- mult += 2 * get_loadavg();
+ mult += 2 * get_loadavg(dev);
/* for IO wait tasks (per
RE: [PATCH] ARM: OMAP: Add support for dmtimer v2 ip (Re: [PATCH v15 06/12] OMAP: dmtimer: switch-over to platform device driver)
Tony Lindgren wrote on Monday, September 19, 2011 11:11 PM: > device driver) > > * Pedanekar, Hemant [110918 20:32]: >> >> Tony, >> Kernel boots fine on TI816X (should also boot on TI814X) with your patch >> and patches (including OSC clock fix) from series >> http://www.spinics.net/lists/linux-omap/msg57011.html > > OK good to hear, I assume I can add your Tested-by then? > > Regards, > > Tony Yes. Thanks. Hemant-- To unsubscribe from this list: send the line "unsubscribe 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/11] Add L2 cache cleaning to generic CPU suspend
On Mon, Sep 19, 2011 at 05:22:22PM +0100, Russell King - ARM Linux wrote: > On Sun, Sep 11, 2011 at 12:10:04AM +0800, Shawn Guo wrote: > > On Thu, Sep 01, 2011 at 11:57:54PM +0800, Shawn Guo wrote: > > > On Thu, Sep 01, 2011 at 04:34:51PM +0100, Russell King - ARM Linux wrote: > > > > On Thu, Sep 01, 2011 at 11:33:43PM +0800, Shawn Guo wrote: > > > > > This is also the case on i.MX6Q, which L2 cache is retained during a > > > > > suspend/resume cycle. Currently, I have to call into the following > > > > > before calling generic cpu_suspend() to clean/invalidate the entire > > > > > L2 cache. > > > > > > > > > > outer_flush_all(); > > > > > outer_disable(); > > > > > > > > > > But there is a wired thing on using generic cpu_resume(). I have to > > > > > invalidate L1 before calling into cpu_resume() like below. > > > > > > > > > > ENTRY(imx6q_cpu_resume) > > > > > bl v7_invalidate_l1 > > > > > b cpu_resume > > > > > ENDPROC(imx6q_cpu_resume) > > > > > > > > > > ENTRY(imx6q_secondary_startup) > > > > > bl v7_invalidate_l1 > > > > > b secondary_startup > > > > > ENDPROC(imx6q_secondary_startup) > > > > > > > > > > The v7_invalidate_l1() is the function copied from > > > > > mach-tegra/headsmp.S, > > > > > which has to be called before calling secondary_startup to boot > > > > > secondary cores (same situation between Tegra and i.MX6Q). > > > > > > > > Presumably that's because your L1 cache contains randomized data with > > > > random validity (and presumably random dirtyness) at boot time - > > > > something > > > > which unfortunately the ARM ARM permits. I don't think we can go to the > > > > extent of dealing with this in the generic code as it would > > > > unnecessarily > > > > perturb those implementations which either the boot loader has already > > > > sorted out that issue, or which don't have the issue at all. > > > > > > > Yes, agreed. It seems that Tegra and i.MX6Q are the only two CA9MP > > > cases here. But is it possible to maintain this v7_invalidate_l1() > > > function in cache-v7.S, so that we do not need to duplicate it in > > > platform codes? > > > > > > > > Before applying this patch series, I have something like below > > > > > actually > > > > > working. > > > > > > > > > > > > > > > outer_flush_all(); > > > > > outer_disable(); > > > > > imx_set_cpu_jump(0, imx6q_cpu_resume); > > > > > /* Zzz ... */ > > > > > cpu_suspend(0, imx6q_suspend_finish); > > > > > > > > > > I expect with you patches applied, I can still have it work with > > > > > simply > > > > > removing those two lines outer cache codes. > > > > > > > > That should be the case. > > > > > > > > > But unfortunately, I'm > > > > > running into Oops when resuming back. And I also have Oops with > > > > > imx_set_cpu_jump(0, cpu_resume) which means skipping the > > > > > v7_invalidate_l1() and calling generic cpu_resume() only. > > > > > > > > Do you have a copy of the oops? > > > > > > > > > Hi Russell, > > > > After following your great debugging clue that we need to enable L2 > > before calling into generic cpu_resume(), now this patch series works > > great for imx6q. Thanks a lot, and here is my tag. > > > > Tested-by: Shawn Guo > > Is that for all these patches? > Yes, it is. -- Regards, Shawn -- To unsubscribe from this list: send the line "unsubscribe 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/7] Add L2 cache cleaning to generic CPU suspend
On Mon, Sep 19, 2011 at 05:37:41PM +0100, Russell King - ARM Linux wrote:
> This is a re-post of the previous patch series, but with an additional
> TLB flush to ensure that hte global TLB entry in the page tables is
> flushed out. This is a flush of all TLB entries, but it could probably
> be more targetted if we need to.
>
Here is the diff on suspend.c between last post and this series. With
the outer_clean_range() calls added back, the series works fine on
imx6q, otherwise it hangs on resume.
diff --git a/arch/arm/kernel/suspend.c b/arch/arm/kernel/suspend.c
index 4c95410..2d60f19 100644
--- a/arch/arm/kernel/suspend.c
+++ b/arch/arm/kernel/suspend.c
@@ -28,9 +28,6 @@ void __cpu_suspend_save(u32 *ptr, u32 ptrsz, u32 sp, u32
*save_ptr)
cpu_do_suspend(ptr);
flush_cache_all();
- outer_clean_range(*save_ptr, *save_ptr + ptrsz);
- outer_clean_range(virt_to_phys(save_ptr),
- virt_to_phys(save_ptr) + sizeof(*save_ptr));
}
/*
@@ -52,8 +49,10 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned long))
* back to the correct page tables.
*/
ret = __cpu_suspend(arg, fn);
- if (ret == 0)
+ if (ret == 0) {
cpu_switch_mm(mm->pgd, mm);
+ local_flush_tlb_all();
+ }
return ret;
}
--
Regards,
Shawn
--
To unsubscribe from this list: send the line "unsubscribe 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 v9] mfd: omap: usb: Runtime PM support for EHCI and OHCI drivers
On Mon, Sep 19, 2011 at 10:52 PM, Cousson, Benoit wrote: > Hi Keshava, > > On 9/19/2011 4:01 PM, Munegowda, Keshava wrote: >> >> On Mon, Sep 19, 2011 at 7:26 PM, Samuel Ortiz >> wrote: >>> >>> Hi Keshava, >>> >>> On Thu, Sep 15, 2011 at 06:52:45PM +0530, Keshava Munegowda wrote: From: Keshava Munegowda The Hwmod structures and Runtime PM features are implemented For EHCI and OHCI drivers of OMAP3 and OMAP4. The global suspend/resume of EHCI and OHCI is validated on OMAP3430 sdp board with these patches. these patches are rebased to kevin's pm branch and usbhs latest mainline kernel patches >>> >>> I'm ready to apply this one to my MFD for-next branch. Or do you want it >>> to go >>> through Kevin's tree ? >>> >>> Cheers, >>> Samuel >> >> >> Thanks samuel; >> But, patch 1 and 2 requires benoit causson's ack by; >> so , I am waiting for benoit response on this. > > I made a couple of comments in the v8, and you did address only half of > them. It will be nice to at least answer the remaining points. > > Moreover, Paul is the maintainer of the OMAP3 hwmod data file. > > Regards, > Benoit Thanks Benoit I will reply to your mail which includes your comments with detailed descriptions. regards keshava -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting
Hi,
On Tuesday 20 September 2011 01:06 AM, Hiremath, Vaibhav wrote:
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 12:09 PM
To: Valkeinen, Tomi
Cc: Hiremath, Vaibhav; linux-omap@vger.kernel.org; Taneja, Archit; linux-
me...@vger.kernel.org; Molnar, Lajos
Subject: [PATCH v2 1/3] OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha
compatibility setting
[Hiremath, Vaibhav] Few minor comments below -
On OMAP3, in order to enable alpha blending for LCD and TV managers, we
needed
to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
OMAP4, alpha blending is always enabled by default, if the above bits are
set,
we switch to an OMAP3 compatibility mode where the zorder values in the
pipeline
[Hiremath, Vaibhav] Spelling mistake???
Thanks, I'll fix this.
attribute registers are ignored and a fixed priority is configured.
Rename the manager_info member "alpha_enabled" to "partial_alpha_enabled"
for
more clarity. Introduce two dss_features FEAT_ALPHA_FIXED_ZORDER and
FEAT_ALPHA_FREE_ZORDER which represent OMAP3-alpha compatibility mode and
OMAP4
alpha mode respectively. Introduce an overlay cap for ZORDER. The DSS2
user is
expected to check for the ZORDER cap, if an overlay doesn't have this cap,
the
user is expected to set the parameter partial_alpha_enabled. If the
overlay has
ZORDER cap, the DSS2 user can assume that alpha blending is already
enabled.
Don't support OMAP3 compatibility mode for now. Trying to read/write to
alpha_blending_enabled sysfs attribute issues a warning for OMAP4 and does
not
set the LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits.
Change alpha_enabled to partial_alpha_enabled int the omap_vout driver.
Use
overlay cap "OMAP_DSS_OVL_CAP_GLOBAL_ALPHA" to check if overlay supports
alpha
blending or not. Replace this with checks for VIDEO1 pipeline.
Initial patch was made by: Lajos Molnar
[Hiremath, Vaibhav] I think you can put his sign-off as well and remove this
line or move it below ---
Okay, I'll wait for his comments, and then put his sign-off.
Cc: linux-me...@vger.kernel.org
Cc: Lajos Molnar
Signed-off-by: Archit Taneja
---
drivers/media/video/omap/omap_vout.c | 16 +++-
drivers/video/omap2/dss/dispc.c| 24
drivers/video/omap2/dss/dss.h |4 ++--
drivers/video/omap2/dss/dss_features.c | 22 +++---
drivers/video/omap2/dss/dss_features.h |3 ++-
drivers/video/omap2/dss/manager.c | 28 +++
-
include/video/omapdss.h|3 ++-
7 files changed, 59 insertions(+), 41 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index b3a5ecd..95daf98 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1165,12 +1165,17 @@ static int vidioc_try_fmt_vid_overlay(struct file
*file, void *fh,
{
int ret = 0;
struct omap_vout_device *vout = fh;
+ struct omap_overlay *ovl;
+ struct omapvideo_info *ovid;
struct v4l2_window *win =&f->fmt.win;
+ ovid =&vout->vid_info;
+ ovl = ovid->overlays[0];
+
[Hiremath, Vaibhav] I think it will be helpful if you put some comment above
this line on why video1, something like,
/*
* Global alpha is not supported on Video1 pipeline/overlay
*/
Sure, i'll add this comment.
ret = omap_vout_try_window(&vout->fbuf, win);
if (!ret) {
- if (vout->vid == OMAP_VIDEO1)
+ if ((ovl->caps& OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
win->global_alpha = 255;
else
win->global_alpha = f->fmt.win.global_alpha;
@@ -1194,8 +1199,7 @@ static int vidioc_s_fmt_vid_overlay(struct file
*file, void *fh,
ret = omap_vout_new_window(&vout->crop,&vout->win,&vout->fbuf,
win);
if (!ret) {
- /* Video1 plane does not support global alpha */
- if (ovl->id == OMAP_DSS_VIDEO1)
+ if ((ovl->caps& OMAP_DSS_OVL_CAP_GLOBAL_ALPHA) == 0)
vout->win.global_alpha = 255;
else
vout->win.global_alpha = f->fmt.win.global_alpha;
@@ -1788,7 +1792,9 @@ static int vidioc_s_fbuf(struct file *file, void *fh,
if (ovl->manager&& ovl->manager->get_manager_info&&
ovl->manager->set_manager_info) {
ovl->manager->get_manager_info(ovl->manager,&info);
- info.alpha_enabled = enable;
+ /* enable this only if there is no zorder cap */
+ if ((ovl->caps& OMAP_DSS_OVL_CAP_ZORDER) == 0)
+ info.partial_alpha_enabled = enable;
if (ovl->manager->set_manager_info(ovl->manager,&info))
return -EINVAL;
}
@@ -1820,7 +1826,7 @@ static int vidioc_g_fbuf(struct file *file, void *fh,
}
if (ovl->manager&& ovl->manager->get_manager_info) {
Re: [PATCH v2 2/3] OMAPDSS: DISPC: VIDEO3 pipeline support
Hi,
On Tuesday 20 September 2011 01:13 AM, Hiremath, Vaibhav wrote:
-Original Message-
From: Taneja, Archit
Sent: Friday, September 16, 2011 12:09 PM
To: Valkeinen, Tomi
Cc: Hiremath, Vaibhav; linux-omap@vger.kernel.org; Taneja, Archit
Subject: [PATCH v2 2/3] OMAPDSS: DISPC: VIDEO3 pipeline support
Add support for VIDEO3 pipeline on OMAP4:
- Add VIDEO3 pipeline information in dss_features and omapdss.h
- Add VIDEO3 pipeline register coefficients in dispc.h
- Create a new overlay structure corresponding to VIDEO3.
- Make changes in dispc.c for VIDEO3
Signed-off-by: Archit Taneja
diff --git a/drivers/video/omap2/dss/dss_features.h
b/drivers/video/omap2/dss/dss_features.h
index e81271a..6a6c05d 100644
--- a/drivers/video/omap2/dss/dss_features.h
+++ b/drivers/video/omap2/dss/dss_features.h
@@ -25,7 +25,7 @@
#endif
#define MAX_DSS_MANAGERS 3
-#define MAX_DSS_OVERLAYS 3
+#define MAX_DSS_OVERLAYS 4
[Hiremath, Vaibhav] Not related to this patch as such, but I think we should
now get rid of these macros and use run-time mechanism.
This macro is used within DSS2 to declare the size of some arrays. So a
runtime mechanism isn't possible(unless we allocate the arrays
dynamically itself, but they are used for trivial purposes, and won't be
large in size, so I don't think that this is needed).
We anyway use the function omap_dss_get_num_overlays() wherever possible.
Overall this patch looks ok to me, I will test it tomorrow and will update you.
Thanks,
Archit
Thanks,
Vaibhav
#define MAX_DSS_LCD_MANAGERS 2
#define MAX_NUM_DSI 2
diff --git a/drivers/video/omap2/dss/overlay.c
b/drivers/video/omap2/dss/overlay.c
index afb7583..11d21e3 100644
--- a/drivers/video/omap2/dss/overlay.c
+++ b/drivers/video/omap2/dss/overlay.c
@@ -615,6 +615,11 @@ void dss_init_overlays(struct platform_device *pdev)
ovl->id = OMAP_DSS_VIDEO2;
ovl->info.global_alpha = 255;
break;
+ case 3:
+ ovl->name = "vid3";
+ ovl->id = OMAP_DSS_VIDEO3;
+ ovl->info.global_alpha = 255;
+ break;
}
ovl->set_manager =&omap_dss_set_manager;
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 5f0ce5e..1f12559 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -41,6 +41,8 @@
#define DISPC_IRQ_WAKEUP (1<< 16)
#define DISPC_IRQ_SYNC_LOST2 (1<< 17)
#define DISPC_IRQ_VSYNC2 (1<< 18)
+#define DISPC_IRQ_VID3_END_WIN (1<< 19)
+#define DISPC_IRQ_VID3_FIFO_UNDERFLOW(1<< 20)
#define DISPC_IRQ_ACBIAS_COUNT_STAT2 (1<< 21)
#define DISPC_IRQ_FRAMEDONE2 (1<< 22)
#define DISPC_IRQ_FRAMEDONEWB(1<< 23)
@@ -63,7 +65,8 @@ enum omap_display_type {
enum omap_plane {
OMAP_DSS_GFX= 0,
OMAP_DSS_VIDEO1 = 1,
- OMAP_DSS_VIDEO2 = 2
+ OMAP_DSS_VIDEO2 = 2,
+ OMAP_DSS_VIDEO3 = 3,
};
enum omap_channel {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
