Re: N810: latest linux-omap-2.6.git master
On Tue, 19 May 2009 00:09:20 -0500 "Luke-Jr" wrote: > Yes, that change seemed to get me booting... however, with "rc6", the > keyboard no longer works *at all*, and in neither rc4 nor rc6 does > p54spi actually work. > For me keyboard still works as partially (commit 0b2ce840c9fb58cf489bfdfc2d77f99a09a5dca3). I wonder what have caused it to break during 2.6.30-rc since at quick look I don't point any special from Tony's "Extra omap code in linux-omap tree" patches and patches before those are from February? git whatchanged arch/arm/mach-omap2/board-n800.c git whatchanged drivers/input/keyboard/lm8323.c > Tried setting up g_ether, but for some reason I couldn't get it to > auto- configure (via Gentoo's boot scripts) for rc6. > For me it works but usually only if cable has been plugged in while booting. Same with Beagle as well. Any idea from MUSB guys? > Is anyone actually trying to work on or maintain N8x0 support? I think N8x0 support is a little bit behind from other boards. Lot of active development is going around on newer and more open platforms like Beagle and not all patches are necessary tested on N8x0 (or other boards too!). Of course active hacker base helps to point out breakages. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] omap3-iommu: reorganize
From: ext Felipe Contreras
Subject: [PATCH] omap3-iommu: reorganize
Date: Mon, 18 May 2009 18:43:00 +0200
> No functional changes.
>
> Signed-off-by: Felipe Contreras
> ---
>
> How about this?
What's the advantage of introducing a new structure here?
>
> arch/arm/mach-omap2/omap3-iommu.c | 53
> ++---
> 1 files changed, 26 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/omap3-iommu.c
> b/arch/arm/mach-omap2/omap3-iommu.c
> index 91ee38a..50bd445 100644
> --- a/arch/arm/mach-omap2/omap3-iommu.c
> +++ b/arch/arm/mach-omap2/omap3-iommu.c
> @@ -14,32 +14,30 @@
>
> #include
>
> -#define OMAP3_MMU1_BASE 0x480bd400
> -#define OMAP3_MMU2_BASE 0x5d00
> -#define OMAP3_MMU1_IRQ 24
> -#define OMAP3_MMU2_IRQ 28
> -
> -
> -static unsigned long iommu_base[] __initdata = {
> - OMAP3_MMU1_BASE,
> - OMAP3_MMU2_BASE,
> -};
> -
> -static int iommu_irq[] __initdata = {
> - OMAP3_MMU1_IRQ,
> - OMAP3_MMU2_IRQ,
> +struct iommu_device {
> + resource_size_t base;
> + int irq;
> + struct iommu_platform_data pdata;
> };
>
> -static const struct iommu_platform_data omap3_iommu_pdata[] __initconst = {
> +static struct iommu_device devices[] __initdata = {
> {
> - .name = "isp",
> - .nr_tlb_entries = 8,
> - .clk_name = "cam_ick",
> + .base = 0x480bd400,
> + .irq = 24,
> + .pdata = {
> + .name = "isp",
> + .nr_tlb_entries = 8,
> + .clk_name = "cam_ick",
> + },
> },
> {
> - .name = "iva2",
> - .nr_tlb_entries = 32,
> - .clk_name = "iva2_ck",
> + .base = 0x5d00,
> + .irq = 28,
> + .pdata = {
> + .name = "iva2",
> + .nr_tlb_entries = 32,
> + .clk_name = "iva2_ck",
> + },
> },
> };
> #define NR_IOMMU_DEVICES ARRAY_SIZE(omap3_iommu_pdata)
> @@ -52,6 +50,7 @@ static int __init omap3_iommu_init(void)
>
> for (i = 0; i < NR_IOMMU_DEVICES; i++) {
> struct platform_device *pdev;
> + const struct iommu_device *d = &devices[i];
> struct resource res[2];
>
> pdev = platform_device_alloc("omap-iommu", i);
> @@ -60,19 +59,19 @@ static int __init omap3_iommu_init(void)
> goto err_out;
> }
>
> - memset(res, 0, sizeof(res));
> - res[0].start = iommu_base[i];
> - res[0].end = iommu_base[i] + MMU_REG_SIZE - 1;
> + memset(res, 0, sizeof(res));
> + res[0].start = d->base;
> + res[0].end = d->base + MMU_REG_SIZE - 1;
> res[0].flags = IORESOURCE_MEM;
> - res[1].start = res[1].end = iommu_irq[i];
> + res[1].start = res[1].end = d->irq;
> res[1].flags = IORESOURCE_IRQ;
>
> err = platform_device_add_resources(pdev, res,
> ARRAY_SIZE(res));
> if (err)
> goto err_out;
> - err = platform_device_add_data(pdev, &omap3_iommu_pdata[i],
> -sizeof(omap3_iommu_pdata[0]));
> + err = platform_device_add_data(pdev, &d->pdata,
> +sizeof(d->pdata));
> if (err)
> goto err_out;
> err = platform_device_add(pdev);
> --
> 1.6.3.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/11] OMAP2/3: PM: push core PM code from linux-omap
Kevin Hilman wrote: The problem here is that such an interface is extremely fragile. Consider what happens if a program disables HLT, and then gets killed off for some reason. How does this reference get balanced again? I think a better solution would be a char device driver which has to be kept open as long as a reference is held. When userspace closes it (be that because the program has exited, been killed, etc) you can drop any pending references. OK, this interface is not intended for users/applications. It is intended only for OMAP PM developers who are developing the PM code and want to prevent idle for various reasons during development. It is not intended for productions systems. What about leaving /sys/power/sleep_while_idle but only if CONFIG_PM_DEBUG=y? Sounds like debugfs is the good place for this then. -- 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 3/3] OMAP2/3 V4L2 Display Driver
Hi Hardik,
According to earlier mail from Sergio, I could be noticed that it is
totally ok to restrict number of buffers by driver. As matter of fact,
I was always considering about the H/W restriction and could find the
answer from his mail.
By the way, thank you for your answer.
Cheers,
Nate
On Tue, May 19, 2009 at 2:28 PM, Shah, Hardik wrote:
> Hi Nate,
>
>
>> -Original Message-
>> From: Aguirre Rodriguez, Sergio Alberto
>> Sent: Tuesday, May 19, 2009 10:52 AM
>> To: Dongsoo, Nathaniel Kim; Shah, Hardik
>> Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
>> R;
>> Hiremath, Vaibhav
>> Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
>>
>> Hi Nate,
>>
>> I have 1 input regarding your question:
>>
>> >From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
>> On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
>> >Sent: Tuesday, May 19, 2009 7:53 AM
>> >To: Shah, Hardik
>> >Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
>> R; Hiremath, Vaibhav
>> >Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
>> >
>> >Hello Hardik,
>> >
>> >Reviewing your driver, I found something made me curious.
>> >
>> >
>> >On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah wrote:
>>
>>
>>
>> >> +/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
>> >> + * called. This is used to setup buffers and return size and count of
>> >> + * buffers allocated. After the call to this buffer, videobuf layer will
>> >> + * setup buffer queue depending on the size and count of buffers
>> >> + */
>> >> +static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
>> *count,
>> >> + unsigned int *size)
>> >> +{
>> >> + struct omap_vout_device *vout = q->priv_data;
>> >> + int startindex = 0, i, j;
>> >> + u32 phy_addr = 0, virt_addr = 0;
>> >> +
>> >> + if (!vout)
>> >> + return -EINVAL;
>> >> +
>> >> + if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type)
>> >> + return -EINVAL;
>> >> +
>> >> + startindex = (vout->vid == OMAP_VIDEO1) ?
>> >> + video1_numbuffers : video2_numbuffers;
>> >> + if (V4L2_MEMORY_MMAP == vout->memory && *count < startindex)
>> >> + *count = startindex;
>> >> +
>> >> + if ((rotation_enabled(vout->rotation)) && *count > 4)
>> >> + *count = 4;
>> >> +
>> >
>> >
>> >
>> >This seems to be weird to me. If user requests multiple buffers more
>> >than 4, user cannot recognize that the number of buffers requested is
>> >forced to change into 4. I'm not sure whether this could be serious or
>> >not, but it is obvious that user can have doubt about why if user have
>> >no information about the OMAP H/W.
>> >Is it really necessary to be configured to 4?
> [Shah, Hardik] Rotation requires the VRFB contexts and limited number of
> contexts are available. So maximum number of buffers is fixed to 4 when
> rotation is enabled.
>
> Thanks,
> Hardik
>> >
>> >
>> >Cheers,
>> >
>> >Nate
>> >
>>
>> We did a very similar thing on omap3 camera driver, not exactly by the number
>> of buffers requested, but more about checking if the bytesize of the total
>> requested buffers was superior to the MMU fixed sized page table size
>> capabilities to map that size, then we were limiting the number of buffers
>> accordingly (for keeping the page table size fixed).
>>
>> According to the v4l2 spec, changing the count value should be valid, and it
>> is the userspace app responsability to check the value again, to confirm how
>> many of the requested buffers are actually available.
>>
>> Regards,
>> Sergio
>
--
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media & Communications R&D Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
dongsoo45@samsung.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 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
> -Original Message-
> From: Aguirre Rodriguez, Sergio Alberto
> Sent: Tuesday, May 19, 2009 10:52 AM
> To: Dongsoo, Nathaniel Kim; Shah, Hardik
> Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh R;
> Hiremath, Vaibhav
> Subject: RE: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
>
> Hi Nate,
>
> I have 1 input regarding your question:
>
> >From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
> On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
> >Sent: Tuesday, May 19, 2009 7:53 AM
> >To: Shah, Hardik
> >Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
> R; Hiremath, Vaibhav
> >Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
> >
> >Hello Hardik,
> >
> >Reviewing your driver, I found something made me curious.
> >
> >
> >On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah wrote:
>
>
>
> >> +/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
> >> + * called. This is used to setup buffers and return size and count of
> >> + * buffers allocated. After the call to this buffer, videobuf layer will
> >> + * setup buffer queue depending on the size and count of buffers
> >> + */
> >> +static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
> *count,
> >> + unsigned int *size)
> >> +{
> >> + struct omap_vout_device *vout = q->priv_data;
> >> + int startindex = 0, i, j;
> >> + u32 phy_addr = 0, virt_addr = 0;
> >> +
> >> + if (!vout)
> >> + return -EINVAL;
> >> +
> >> + if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type)
> >> + return -EINVAL;
> >> +
> >> + startindex = (vout->vid == OMAP_VIDEO1) ?
> >> + video1_numbuffers : video2_numbuffers;
> >> + if (V4L2_MEMORY_MMAP == vout->memory && *count < startindex)
> >> + *count = startindex;
> >> +
> >> + if ((rotation_enabled(vout->rotation)) && *count > 4)
> >> + *count = 4;
> >> +
> >
> >
> >
> >This seems to be weird to me. If user requests multiple buffers more
> >than 4, user cannot recognize that the number of buffers requested is
> >forced to change into 4. I'm not sure whether this could be serious or
> >not, but it is obvious that user can have doubt about why if user have
> >no information about the OMAP H/W.
> >Is it really necessary to be configured to 4?
[Shah, Hardik] Rotation requires the VRFB contexts and limited number of
contexts are available. So maximum number of buffers is fixed to 4 when
rotation is enabled.
Thanks,
Hardik
> >
> >
> >Cheers,
> >
> >Nate
> >
>
> We did a very similar thing on omap3 camera driver, not exactly by the number
> of buffers requested, but more about checking if the bytesize of the total
> requested buffers was superior to the MMU fixed sized page table size
> capabilities to map that size, then we were limiting the number of buffers
> accordingly (for keeping the page table size fixed).
>
> According to the v4l2 spec, changing the count value should be valid, and it
> is the userspace app responsability to check the value again, to confirm how
> many of the requested buffers are actually available.
>
> Regards,
> Sergio
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
Hi Sergio,
Thank you for your explanation . I learned much from that.
Cheers,
Nate
On Tue, May 19, 2009 at 2:22 PM, Aguirre Rodriguez, Sergio Alberto
wrote:
> Hi Nate,
>
> I have 1 input regarding your question:
>
>>From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org]
>>On Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
>>Sent: Tuesday, May 19, 2009 7:53 AM
>>To: Shah, Hardik
>>Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh
>>R; Hiremath, Vaibhav
>>Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
>>
>>Hello Hardik,
>>
>>Reviewing your driver, I found something made me curious.
>>
>>
>>On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah wrote:
>
>
>
>>> +/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
>>> + * called. This is used to setup buffers and return size and count of
>>> + * buffers allocated. After the call to this buffer, videobuf layer will
>>> + * setup buffer queue depending on the size and count of buffers
>>> + */
>>> +static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
>>> *count,
>>> + unsigned int *size)
>>> +{
>>> + struct omap_vout_device *vout = q->priv_data;
>>> + int startindex = 0, i, j;
>>> + u32 phy_addr = 0, virt_addr = 0;
>>> +
>>> + if (!vout)
>>> + return -EINVAL;
>>> +
>>> + if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type)
>>> + return -EINVAL;
>>> +
>>> + startindex = (vout->vid == OMAP_VIDEO1) ?
>>> + video1_numbuffers : video2_numbuffers;
>>> + if (V4L2_MEMORY_MMAP == vout->memory && *count < startindex)
>>> + *count = startindex;
>>> +
>>> + if ((rotation_enabled(vout->rotation)) && *count > 4)
>>> + *count = 4;
>>> +
>>
>>
>>
>>This seems to be weird to me. If user requests multiple buffers more
>>than 4, user cannot recognize that the number of buffers requested is
>>forced to change into 4. I'm not sure whether this could be serious or
>>not, but it is obvious that user can have doubt about why if user have
>>no information about the OMAP H/W.
>>Is it really necessary to be configured to 4?
>>
>>
>>Cheers,
>>
>>Nate
>>
>
> We did a very similar thing on omap3 camera driver, not exactly by the number
> of buffers requested, but more about checking if the bytesize of the total
> requested buffers was superior to the MMU fixed sized page table size
> capabilities to map that size, then we were limiting the number of buffers
> accordingly (for keeping the page table size fixed).
>
> According to the v4l2 spec, changing the count value should be valid, and it
> is the userspace app responsability to check the value again, to confirm how
> many of the requested buffers are actually available.
>
> Regards,
> Sergio
--
=
DongSoo, Nathaniel Kim
Engineer
Mobile S/W Platform Lab.
Digital Media & Communications R&D Centre
Samsung Electronics CO., LTD.
e-mail : dongsoo@gmail.com
dongsoo45@samsung.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 3/3] OMAP2/3 V4L2 Display Driver
Hi Nate,
I have 1 input regarding your question:
>From: linux-media-ow...@vger.kernel.org [linux-media-ow...@vger.kernel.org] On
>Behalf Of Dongsoo, Nathaniel Kim [dongsoo@gmail.com]
>Sent: Tuesday, May 19, 2009 7:53 AM
>To: Shah, Hardik
>Cc: linux-me...@vger.kernel.org; linux-omap@vger.kernel.org; Jadav, Brijesh R;
>Hiremath, Vaibhav
>Subject: Re: [PATCH 3/3] OMAP2/3 V4L2 Display Driver
>
>Hello Hardik,
>
>Reviewing your driver, I found something made me curious.
>
>
>On Wed, Apr 22, 2009 at 3:25 PM, Hardik Shah wrote:
>> +/* Buffer setup function is called by videobuf layer when REQBUF ioctl is
>> + * called. This is used to setup buffers and return size and count of
>> + * buffers allocated. After the call to this buffer, videobuf layer will
>> + * setup buffer queue depending on the size and count of buffers
>> + */
>> +static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int
>> *count,
>> + unsigned int *size)
>> +{
>> + struct omap_vout_device *vout = q->priv_data;
>> + int startindex = 0, i, j;
>> + u32 phy_addr = 0, virt_addr = 0;
>> +
>> + if (!vout)
>> + return -EINVAL;
>> +
>> + if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type)
>> + return -EINVAL;
>> +
>> + startindex = (vout->vid == OMAP_VIDEO1) ?
>> + video1_numbuffers : video2_numbuffers;
>> + if (V4L2_MEMORY_MMAP == vout->memory && *count < startindex)
>> + *count = startindex;
>> +
>> + if ((rotation_enabled(vout->rotation)) && *count > 4)
>> + *count = 4;
>> +
>
>
>
>This seems to be weird to me. If user requests multiple buffers more
>than 4, user cannot recognize that the number of buffers requested is
>forced to change into 4. I'm not sure whether this could be serious or
>not, but it is obvious that user can have doubt about why if user have
>no information about the OMAP H/W.
>Is it really necessary to be configured to 4?
>
>
>Cheers,
>
>Nate
>
We did a very similar thing on omap3 camera driver, not exactly by the number
of buffers requested, but more about checking if the bytesize of the total
requested buffers was superior to the MMU fixed sized page table size
capabilities to map that size, then we were limiting the number of buffers
accordingly (for keeping the page table size fixed).
According to the v4l2 spec, changing the count value should be valid, and it is
the userspace app responsability to check the value again, to confirm how many
of the requested buffers are actually available.
Regards,
Sergio--
To unsubscribe from this list: send the line "unsubscribe 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: N810: latest linux-omap-2.6.git master
On Wednesday 13 May 2009 04:12:19 am Jarkko Nikula wrote: > This device node update to initfs is required since Maemo 2.6.21 > kernel & initfs are using major number 254 for mmcblk whereas newer > kernels are using 179. Yes, that change seemed to get me booting... however, with "rc6", the keyboard no longer works *at all*, and in neither rc4 nor rc6 does p54spi actually work. Tried setting up g_ether, but for some reason I couldn't get it to auto- configure (via Gentoo's boot scripts) for rc6. Is anyone actually trying to work on or maintain N8x0 support? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
MMC card corruption during suspend/resume operation
Hi, I have a problem with my TI OMAP 3503 platform, where the microSD card that I have, gets corrupted during a suspend/resume operation. Do the existing power management drivers, cleanly unmount/ mount the mmc card during a suspend/resume operation? I am using the TI OMAP linux 2.6.29 kernel version, with the android-2.6.29 kernel updates. I have installed Doing a search for the mmc card corruption issues, it would appear that a lot of people are facing the same issues on other platforms as well. It appears to be a platform issue for both the older 1.1 and 1.5 android versions. http://forum.xda-developers.com/archive/index.php/t-495899.html http://androidforums.com/updates-cupcakes/5202-did-cupcake-eat-my-sd-card.html http://forums.t-mobile.com/tmbl/board/message?board.id=Android3&message.id=10928 The problem might be because of the application or system not cleanly un-mounting the mmc card, thus causing it to get corrupted, e.g during a suspend/resume operation. So, I thought I'd ask if the existing power management drivers do a clean mount/unmount when it does a suspend/resume operation. Best regards, Elvis -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: Remove IRQ hardcoding from serial.c
> -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Tuesday, May 19, 2009 3:16 AM > To: Shilimkar, Santosh > Cc: linux-omap@vger.kernel.org > Subject: Re: [PATCH] OMAP: Remove IRQ hardcoding from serial.c > > * Shilimkar, Santosh [090513 07:53]: > > Tony, > > Any comments on this patch. > > http://patchwork.kernel.org/patch/19161/ > > We should just set the interrupts etc dynamically using the > cpu_is_omap() functions. That's indeed a good idea. But then are we going to remove this information from platform structures. If not then hardcoding is still bad and should be removed. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v3 1/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board
Tony
>-Original Message-
>From: Tony Lindgren [mailto:t...@atomide.com]
>Sent: Monday, May 18, 2009 4:39 PM
>To: Pandita, Vikram
>Cc: Christensen, Mikkel; linux-omap@vger.kernel.org
>Subject: Re: [PATCH v3 1/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board
>
>* Pandita, Vikram [090518 14:31]:
>> Tony
>>
>> >>
>> >> +
>> >> + zoom2_init_smsc911x();
>> >> + zoom2_init_quaduart();
>> >> + return platform_add_devices(zoom2_devices, ARRAY_SIZE(zoom2_devices));
>> >> +}
>> >> +arch_initcall(omap_zoom2_debugboard_init);
>> >
>> >Please just move all the related functions to board-zoom2.c. I don't see any
>> >reason to have a separate file for the debugboard features. The runtime
>> >detection
>> >should do the trick.
>>
>> Two reasons for keeping a separate debug board.
>> a) debug board is detachable in h/w and hence we thought its better to keep
>> the s/w also that way
>> The quart chip on debug bard is a quard-uart and can support 4 different
>> console outputs.
>> All those we thought of adding in future.
>
>Well those you can easily optimize out by not compiling in those devices.
>
>>
>> b) we took reference from board-rx51-peripherals.c wherein some parts of the
>> board file can be
>moved out to a new file
>>
>> If you still think we need to merge, then let us know.
>> We are open to suggestions/changes.
>
>Well the reason for separate board-*-peripheral-whatever.c files is that
>they're intended to be shared with other board-*.c files. Currently n8x0
>and rx51 share devices. In general, we should try to do generic platform
>init files, like gpmc-onenand.c and gpmc-smc91x.c.
>
>Then I see need for gpmc-sdp-flash.c that's shared between 2430 and 3430 sdp
>at least.
>
>So yeah, for zoom2, I'd rather see just board-zoom2.c for now. But if you
>create some other board that uses the same debug board functions, then
>there could be a separate zoom-debugboard.c.
Yes. There is next generation of zoom boards that will re-use the Debug board.
That way the debug board file will get re-used.
>
>Regards,
>
>Tony
>
>
>> >
>> >Also, the arch_initcall() above is wrong, it runs for all the boards and
>> >platforms compiled in even if they are not zoom2 boards.
>> >
>> >Other than, looks OK to me, so we might be able to get this into mainline
>> >this merge window.
>> >
>> >Regards,
>> >
>> >Tony
>>
>>
>>
>> >
>> >
>> >> diff --git a/arch/arm/mach-omap2/board-zoom2.c
>> >> b/arch/arm/mach-omap2/board-zoom2.c
>> >> new file mode 100644
>> >> index 000..5a656b3
>> >> --- /dev/null
>> >> +++ b/arch/arm/mach-omap2/board-zoom2.c
>> >> @@ -0,0 +1,107 @@
>> >> +/*
>> >> + * Copyright (C) 2009 Texas Instruments Inc.
>> >> + * Mikkel Christensen
>> >> + *
>> >> + * Modified from mach-omap2/board-ldp.c
>> >> + *
>> >> + * This program is free software; you can redistribute it and/or modify
>> >> + * it under the terms of the GNU General Public License version 2 as
>> >> + * published by the Free Software Foundation.
>> >> + */
>> >> +
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +
>> >> +#include
>> >> +#include
>> >> +
>> >> +#include
>> >> +#include
>> >> +#include
>> >> +
>> >> +#include "mmc-twl4030.h"
>> >> +
>> >> +static void __init omap_zoom2_init_irq(void)
>> >> +{
>> >> + omap2_init_common_hw(NULL);
>> >> + omap_init_irq();
>> >> + omap_gpio_init();
>> >> +}
>> >> +
>> >> +static struct omap_uart_config zoom2_uart_config __initdata = {
>> >> + .enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
>> >> +};
>> >> +
>> >> +static struct omap_board_config_kernel zoom2_config[] __initdata = {
>> >> + { OMAP_TAG_UART,&zoom2_uart_config },
>> >> +};
>> >> +
>> >> +static struct twl4030_gpio_platform_data zoom2_gpio_data = {
>> >> + .gpio_base = OMAP_MAX_GPIO_LINES,
>> >> + .irq_base = TWL4030_GPIO_IRQ_BASE,
>> >> + .irq_end= TWL4030_GPIO_IRQ_END,
>> >> +};
>> >> +
>> >> +static struct twl4030_platform_data zoom2_twldata = {
>> >> + .irq_base = TWL4030_IRQ_BASE,
>> >> + .irq_end= TWL4030_IRQ_END,
>> >> +
>> >> + /* platform_data for children goes here */
>> >> + .gpio = &zoom2_gpio_data,
>> >> +};
>> >> +
>> >> +static struct i2c_board_info __initdata zoom2_i2c_boardinfo[] = {
>> >> + {
>> >> + I2C_BOARD_INFO("twl4030", 0x48),
>> >> + .flags = I2C_CLIENT_WAKE,
>> >> + .irq = INT_34XX_SYS_NIRQ,
>> >> + .platform_data = &zoom2_twldata,
>> >> + },
>> >> +};
>> >> +
>> >> +static int __init omap_i2c_init(void)
>> >> +{
>> >> + omap_register_i2c_bus(1, 2600, zoom2_i2c_boardinfo,
>> >> + ARRAY_SIZE(zoom2_i2c_boardinfo));
>> >> + omap_register_i2c_bus(2, 400, NULL, 0);
>> >> + omap_register_i2c_bus(3, 400, NULL, 0);
>> >> + return 0;
>> >> +}
>> >> +
>> >> +static struct twl4030_hsmmc_info mmc[] __initdata = {
>> >> + {
>> >> + .mmc= 1,
>> >> + .wires = 4,
>> >> + .gpio_cd= -EINVAL,
>> >> + .gpio_wp= -EINVAL,
>> >> +
slap corruption
Hi everyone, We have been looking into the Slab Corruption error and we have found the problem occurs after an application has been terminated abnormally, e.g. Using CTL-C or Segmentation Fault or kill. The issue is observed not only for DMM test cases but for others test cases that don't use DMM. The problem is reported by 'slab.c' when a slab object which is inactive, it supposed to be filled with POISON_FREE (6b) and has some 00 within the object, this seems to be corrupted. Slab corruption: size-64 start=c6bc71e0, len=64 <3>Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. Redzone: 0x9f911029d74e35b/0x9f911029d74e35b. <3>Last user: []Last user: [](MEM_Free+0x9c/0xe0 [bridgedriv er])(MEM_Free+0x9c/0xe0 [bridgedriver]) <3>010:010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 00 00 00 00 it seems it is not being freed correctly, because instead of being filled only with 6b it has 00 maybe other process is overwriting it. Does anyone have any idea of what can be happening? Regards, Fernando. -- To unsubscribe from this list: send the line "unsubscribe 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
Russell King - ARM Linux writes:
> On Mon, May 18, 2009 at 02:04:19PM -0500, Woodruff, Richard wrote:
>> cpu_init() is not yet accessible at the point this code is running.
>
> Not at that _exact_ point, but there's no need what so ever for it
> to be at that exact point. There's nothing stopping a call to
> cpu_init() happening later. Much later.
>
>> You could reduce the context perhaps trying to optimize to what the
>> Linux-ARM implementation is today or do a more generic save like is
>> there now.
>>
>> This code is copied into place from the .S code into SRAM. Its
>> position independent and is not linked for this address. If you want
>> to call functions outside of it you need to manually setup linkage.
>
> I wouldn't want to.
>
>> Calling functions on the way _UP_ from wake is NOT easy (like the one
>> you propose) as the MMU is not yet enabled. The MMU is enabled only
>> below this. Calling cpu_init() is not do able here. Even if you
>> dress up the calling pointer to the physical address, it won't work
>> as cpu_init() makes a global variable dereferences (smp_processor_id
>> & stacks[]).
>
> As long as IRQs and FIQs are disabled, you are in a 100% predictable
> environment.
>
> 1. No IRQ or FIQ will be entered; if they are the CPU is buggy.
> 2. No data or prefetch abort will be entered _unless_ you purposely
>access some non-present memory (and you're not exactly going to
>start paging memory in with IRQs disabled.)
>
> So restoring the abort and IRQ mode register state is just plain not
> necessary in your SRAM code.
>
> Let's look at the code. Here are the pertinent bits from Kevin's patch:
>
> static void omap3_pm_idle(void)
> {
> local_irq_disable();
> local_fiq_disable();
>
> omap_sram_idle();
>
> local_fiq_enable();
> local_irq_enable();
> }
>
> static void omap_sram_idle(void)
> {
> _omap_sram_idle(NULL, save_state);
> }
>
> _omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
> omap34xx_cpu_suspend_sz);
> pm_idle = omap3_pm_idle;
>
> _omap_sram_idle() is the assembly code we're discussing, and here we're
> referring to its version in SRAM. From the above code, we can clearly
> see that this is entered with FIQs and IRQs disabled. So everything
> inside omap_sram_idle() is running in a well defined environment provided
> prefetch and data aborts don't happen.
>
> There is nothing stopping this from becoming:
>
> static void omap3_pm_idle(void)
> {
> local_irq_disable();
> local_fiq_disable();
>
> omap_sram_idle();
> + cpu_init();
>
> local_fiq_enable();
> local_irq_enable();
> }
>
> and having the saving of IRQ, FIQ and abort mode registers removed
> from the SRAM code.
I did some quick experiments on a kernel that includes full OFF-mode
support and this and this is working fine.
For it to work for both idle and suspend, I put the cpu_init()
immediately after the return from SRAM (IOW, right after the call to
_omap_sram_idle() inside omap_sram_idle()).
Now I can totally drop all the sp/lr/spsr save/restore code from the
asm code. Nice!
> Other SoCs do precisely this - let's look at PXA:
>
> pxa_cpu_pm_fns->enter(state);
> cpu_init();
>
> The call to the enter method essentially calls the core specific suspend
> function (eg, pxa25x_cpu_suspend()), which is an assembly function which
> ultimately ends up powering down the core resulting in full loss of state
> in the CPU. We seem to be able to avoid having to save the exception mode
> registers there.
>
> The same thing is done with sa11x0 and Samsung SoCs.
>
> I don't see any reason for OMAP to be "special" in this regard.
Neither do I. Thanks for the review and the suggestion.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: n810 internal mmc boot
Jarkko Nikula wrote at 2009-03-25 05:26 -0600: > On Sat, 21 Mar 2009 20:33:55 +0100 greenfreedo...@gmail.com wrote: > > green wrote at 2009-02-27 18:27 -0700: > > > Any news on booting n810 from internal mmc? It hasn't worked for a > > > while. > > > > The kernel detects the external mmc fine (for root=), but not the > > internal... I'm just wondering whether any progress is being made or > > expected. Sorry if I'm being a nuisance. > > So it has been working at least sometime in linux-omap? I've been using > prototype version of N810 with slightly different internal mmc and I > have never noticed that internal mmc is working in linux-omap. It must be 0cde345ce0861d8ac087e87cfbf6680f9b224a46 that broke it. That commit removes drivers/i2c/chips/menelaus.c, the linux-omap version of menelaus. The mainline version doesn't work for internal mmc on the n810. signature.asc Description: Digital signature
Re: [PATCH] OMAP: Remove IRQ hardcoding from serial.c
* Shilimkar, Santosh [090513 07:53]: > Tony, > Any comments on this patch. > http://patchwork.kernel.org/patch/19161/ We should just set the interrupts etc dynamically using the cpu_is_omap() functions. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board
* Pandita, Vikram [090518 14:31]:
> Tony
>
> >-Original Message-
> >From: Tony Lindgren [mailto:t...@atomide.com]
> >Hi,
> >
> >Few comments below.
> >
> >* Mikkel Christensen [090515 14:17]:
> >> This patch creates the minimal OMAP3 Zoom2 board support.
> >>
> >> Signed-off-by: Mikkel Christensen
> >> Signed-off-by: Vikram Pandita
> >> ---
> >> arch/arm/mach-omap2/board-zoom2-debugboard.c | 161
> >> ++
> >> arch/arm/mach-omap2/board-zoom2.c| 107 +
> >> 2 files changed, 268 insertions(+), 0 deletions(-)
> >> create mode 100644 arch/arm/mach-omap2/board-zoom2-debugboard.c
> >> create mode 100644 arch/arm/mach-omap2/board-zoom2.c
>
>
> >>
> >> +
> >> + zoom2_init_smsc911x();
> >> + zoom2_init_quaduart();
> >> + return platform_add_devices(zoom2_devices, ARRAY_SIZE(zoom2_devices));
> >> +}
> >> +arch_initcall(omap_zoom2_debugboard_init);
> >
> >Please just move all the related functions to board-zoom2.c. I don't see any
> >reason to have a separate file for the debugboard features. The runtime
> >detection
> >should do the trick.
>
> Two reasons for keeping a separate debug board.
> a) debug board is detachable in h/w and hence we thought its better to keep
> the s/w also that way
> The quart chip on debug bard is a quard-uart and can support 4 different
> console outputs.
> All those we thought of adding in future.
Well those you can easily optimize out by not compiling in those devices.
>
> b) we took reference from board-rx51-peripherals.c wherein some parts of the
> board file can be moved out to a new file
>
> If you still think we need to merge, then let us know.
> We are open to suggestions/changes.
Well the reason for separate board-*-peripheral-whatever.c files is that
they're intended to be shared with other board-*.c files. Currently n8x0
and rx51 share devices. In general, we should try to do generic platform
init files, like gpmc-onenand.c and gpmc-smc91x.c.
Then I see need for gpmc-sdp-flash.c that's shared between 2430 and 3430 sdp
at least.
So yeah, for zoom2, I'd rather see just board-zoom2.c for now. But if you
create some other board that uses the same debug board functions, then
there could be a separate zoom-debugboard.c.
Regards,
Tony
> >
> >Also, the arch_initcall() above is wrong, it runs for all the boards and
> >platforms compiled in even if they are not zoom2 boards.
> >
> >Other than, looks OK to me, so we might be able to get this into mainline
> >this merge window.
> >
> >Regards,
> >
> >Tony
>
>
>
> >
> >
> >> diff --git a/arch/arm/mach-omap2/board-zoom2.c
> >> b/arch/arm/mach-omap2/board-zoom2.c
> >> new file mode 100644
> >> index 000..5a656b3
> >> --- /dev/null
> >> +++ b/arch/arm/mach-omap2/board-zoom2.c
> >> @@ -0,0 +1,107 @@
> >> +/*
> >> + * Copyright (C) 2009 Texas Instruments Inc.
> >> + * Mikkel Christensen
> >> + *
> >> + * Modified from mach-omap2/board-ldp.c
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include
> >> +#include
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include "mmc-twl4030.h"
> >> +
> >> +static void __init omap_zoom2_init_irq(void)
> >> +{
> >> + omap2_init_common_hw(NULL);
> >> + omap_init_irq();
> >> + omap_gpio_init();
> >> +}
> >> +
> >> +static struct omap_uart_config zoom2_uart_config __initdata = {
> >> + .enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
> >> +};
> >> +
> >> +static struct omap_board_config_kernel zoom2_config[] __initdata = {
> >> + { OMAP_TAG_UART,&zoom2_uart_config },
> >> +};
> >> +
> >> +static struct twl4030_gpio_platform_data zoom2_gpio_data = {
> >> + .gpio_base = OMAP_MAX_GPIO_LINES,
> >> + .irq_base = TWL4030_GPIO_IRQ_BASE,
> >> + .irq_end= TWL4030_GPIO_IRQ_END,
> >> +};
> >> +
> >> +static struct twl4030_platform_data zoom2_twldata = {
> >> + .irq_base = TWL4030_IRQ_BASE,
> >> + .irq_end= TWL4030_IRQ_END,
> >> +
> >> + /* platform_data for children goes here */
> >> + .gpio = &zoom2_gpio_data,
> >> +};
> >> +
> >> +static struct i2c_board_info __initdata zoom2_i2c_boardinfo[] = {
> >> + {
> >> + I2C_BOARD_INFO("twl4030", 0x48),
> >> + .flags = I2C_CLIENT_WAKE,
> >> + .irq = INT_34XX_SYS_NIRQ,
> >> + .platform_data = &zoom2_twldata,
> >> + },
> >> +};
> >> +
> >> +static int __init omap_i2c_init(void)
> >> +{
> >> + omap_register_i2c_bus(1, 2600, zoom2_i2c_boardinfo,
> >> + ARRAY_SIZE(zoom2_i2c_boardinfo));
> >> + omap_register_i2c_bus(2, 400, NULL, 0);
> >> + omap_register_i2c_bus(3, 400, NULL, 0);
> >> + return 0;
> >> +}
> >> +
> >> +static struct twl4030_hsmmc_info mmc[] __initdata = {
> >> + {
> >>
RE: [PATCH v3 1/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board
Tony
>-Original Message-
>From: Tony Lindgren [mailto:t...@atomide.com]
>Hi,
>
>Few comments below.
>
>* Mikkel Christensen [090515 14:17]:
>> This patch creates the minimal OMAP3 Zoom2 board support.
>>
>> Signed-off-by: Mikkel Christensen
>> Signed-off-by: Vikram Pandita
>> ---
>> arch/arm/mach-omap2/board-zoom2-debugboard.c | 161
>> ++
>> arch/arm/mach-omap2/board-zoom2.c| 107 +
>> 2 files changed, 268 insertions(+), 0 deletions(-)
>> create mode 100644 arch/arm/mach-omap2/board-zoom2-debugboard.c
>> create mode 100644 arch/arm/mach-omap2/board-zoom2.c
>>
>> +
>> +zoom2_init_smsc911x();
>> +zoom2_init_quaduart();
>> +return platform_add_devices(zoom2_devices, ARRAY_SIZE(zoom2_devices));
>> +}
>> +arch_initcall(omap_zoom2_debugboard_init);
>
>Please just move all the related functions to board-zoom2.c. I don't see any
>reason to have a separate file for the debugboard features. The runtime
>detection
>should do the trick.
Two reasons for keeping a separate debug board.
a) debug board is detachable in h/w and hence we thought its better to keep the
s/w also that way
The quart chip on debug bard is a quard-uart and can support 4 different
console outputs.
All those we thought of adding in future.
b) we took reference from board-rx51-peripherals.c wherein some parts of the
board file can be moved out to a new file
If you still think we need to merge, then let us know.
We are open to suggestions/changes.
>
>Also, the arch_initcall() above is wrong, it runs for all the boards and
>platforms compiled in even if they are not zoom2 boards.
>
>Other than, looks OK to me, so we might be able to get this into mainline
>this merge window.
>
>Regards,
>
>Tony
>
>
>> diff --git a/arch/arm/mach-omap2/board-zoom2.c
>> b/arch/arm/mach-omap2/board-zoom2.c
>> new file mode 100644
>> index 000..5a656b3
>> --- /dev/null
>> +++ b/arch/arm/mach-omap2/board-zoom2.c
>> @@ -0,0 +1,107 @@
>> +/*
>> + * Copyright (C) 2009 Texas Instruments Inc.
>> + * Mikkel Christensen
>> + *
>> + * Modified from mach-omap2/board-ldp.c
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#include "mmc-twl4030.h"
>> +
>> +static void __init omap_zoom2_init_irq(void)
>> +{
>> +omap2_init_common_hw(NULL);
>> +omap_init_irq();
>> +omap_gpio_init();
>> +}
>> +
>> +static struct omap_uart_config zoom2_uart_config __initdata = {
>> +.enabled_uarts = ((1 << 0) | (1 << 1) | (1 << 2)),
>> +};
>> +
>> +static struct omap_board_config_kernel zoom2_config[] __initdata = {
>> +{ OMAP_TAG_UART,&zoom2_uart_config },
>> +};
>> +
>> +static struct twl4030_gpio_platform_data zoom2_gpio_data = {
>> +.gpio_base = OMAP_MAX_GPIO_LINES,
>> +.irq_base = TWL4030_GPIO_IRQ_BASE,
>> +.irq_end= TWL4030_GPIO_IRQ_END,
>> +};
>> +
>> +static struct twl4030_platform_data zoom2_twldata = {
>> +.irq_base = TWL4030_IRQ_BASE,
>> +.irq_end= TWL4030_IRQ_END,
>> +
>> +/* platform_data for children goes here */
>> +.gpio = &zoom2_gpio_data,
>> +};
>> +
>> +static struct i2c_board_info __initdata zoom2_i2c_boardinfo[] = {
>> +{
>> +I2C_BOARD_INFO("twl4030", 0x48),
>> +.flags = I2C_CLIENT_WAKE,
>> +.irq = INT_34XX_SYS_NIRQ,
>> +.platform_data = &zoom2_twldata,
>> +},
>> +};
>> +
>> +static int __init omap_i2c_init(void)
>> +{
>> +omap_register_i2c_bus(1, 2600, zoom2_i2c_boardinfo,
>> +ARRAY_SIZE(zoom2_i2c_boardinfo));
>> +omap_register_i2c_bus(2, 400, NULL, 0);
>> +omap_register_i2c_bus(3, 400, NULL, 0);
>> +return 0;
>> +}
>> +
>> +static struct twl4030_hsmmc_info mmc[] __initdata = {
>> +{
>> +.mmc= 1,
>> +.wires = 4,
>> +.gpio_cd= -EINVAL,
>> +.gpio_wp= -EINVAL,
>> +},
>> +{} /* Terminator */
>> +};
>> +
>> +static void __init omap_zoom2_init(void)
>> +{
>> +omap_i2c_init();
>> +omap_board_config = zoom2_config;
>> +omap_board_config_size = ARRAY_SIZE(zoom2_config);
>> +omap_serial_init();
>> +twl4030_mmc_init(mmc);
>> +usb_musb_init();
>> +}
>> +
>> +static void __init omap_zoom2_map_io(void)
>> +{
>> +omap2_set_globals_343x();
>> +omap2_map_common_io();
>> +}
>> +
>> +MACHINE_START(OMAP_ZOOM2, "OMAP Zoom2 board")
>> +.phys_io= 0x4800,
>> +.io_pg_offst= ((0xd800) >> 18) & 0xfffc,
>> +.boot_params= 0x8100,
>> +.map_io = omap_zoom2_map_io,
>> +.init_irq = omap_zoom2_init_irq,
>> +.init_machine
[APPLIED] [PATCH] OMAP: sDMA: Correct the the
This patch has been applied to the linux-omap by youw fwiendly patch wobot. Initial commit ID (Likely to change): 0b2ce840c9fb58cf489bfdfc2d77f99a09a5dca3 PatchWorks http://patchwork.kernel.org/patch/20665/ Git (Likely to change, and takes a while to get mirrored) http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap-2.6.git;a=commit;h=0b2ce840c9fb58cf489bfdfc2d77f99a09a5dca3 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 1/3] OMAP3:zoom2: Add support for OMAP3 Zoom2 board
Hi,
Few comments below.
* Mikkel Christensen [090515 14:17]:
> This patch creates the minimal OMAP3 Zoom2 board support.
>
> Signed-off-by: Mikkel Christensen
> Signed-off-by: Vikram Pandita
> ---
> arch/arm/mach-omap2/board-zoom2-debugboard.c | 161
> ++
> arch/arm/mach-omap2/board-zoom2.c| 107 +
> 2 files changed, 268 insertions(+), 0 deletions(-)
> create mode 100644 arch/arm/mach-omap2/board-zoom2-debugboard.c
> create mode 100644 arch/arm/mach-omap2/board-zoom2.c
>
> diff --git a/arch/arm/mach-omap2/board-zoom2-debugboard.c
> b/arch/arm/mach-omap2/board-zoom2-debugboard.c
> new file mode 100644
> index 000..e5686e8
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-zoom2-debugboard.c
> @@ -0,0 +1,161 @@
> +/*
> + * Copyright (C) 2009 Texas Instruments Inc.
> + * Mikkel Christensen
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define ZOOM2_SMSC911X_CS7
> +#define ZOOM2_SMSC911X_GPIO 158
> +#define ZOOM2_QUADUART_CS3
> +#define ZOOM2_QUADUART_GPIO 102
> +#define QUART_CLK1843200
> +#define DEBUG_BASE 0x0800
> +#define ZOOM2_ETHR_START DEBUG_BASE
> +
> +static struct resource zoom2_smsc911x_resources[] = {
> + [0] = {
> + .start = ZOOM2_ETHR_START,
> + .end= ZOOM2_ETHR_START + SZ_4K,
> + .flags = IORESOURCE_MEM,
> + },
> + [1] = {
> + .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWLEVEL,
> + },
> +};
> +
> +static struct smsc911x_platform_config zoom2_smsc911x_config = {
> + .irq_polarity = SMSC911X_IRQ_POLARITY_ACTIVE_LOW,
> + .irq_type = SMSC911X_IRQ_TYPE_OPEN_DRAIN,
> + .flags = SMSC911X_USE_32BIT,
> + .phy_interface = PHY_INTERFACE_MODE_MII,
> +};
> +
> +static struct platform_device zoom2_smsc911x_device = {
> + .name = "smsc911x",
> + .id = -1,
> + .num_resources = ARRAY_SIZE(zoom2_smsc911x_resources),
> + .resource = zoom2_smsc911x_resources,
> + .dev= {
> + .platform_data = &zoom2_smsc911x_config,
> + },
> +};
> +
> +static inline void __init zoom2_init_smsc911x(void)
> +{
> + int eth_cs;
> + unsigned long cs_mem_base;
> + int eth_gpio = 0;
> +
> + eth_cs = ZOOM2_SMSC911X_CS;
> +
> + if (gpmc_cs_request(eth_cs, SZ_16M, &cs_mem_base) < 0) {
> + printk(KERN_ERR "Failed to request GPMC mem for smsc911x\n");
> + return;
> + }
> +
> + zoom2_smsc911x_resources[0].start = cs_mem_base + 0x0;
> + zoom2_smsc911x_resources[0].end = cs_mem_base + 0xff;
> +
> + eth_gpio = ZOOM2_SMSC911X_GPIO;
> +
> + zoom2_smsc911x_resources[1].start = OMAP_GPIO_IRQ(eth_gpio);
> +
> + if (gpio_request(eth_gpio, "smsc911x irq") < 0) {
> + printk(KERN_ERR "Failed to request GPIO%d for smsc911x IRQ\n",
> + eth_gpio);
> + return;
> + }
> + gpio_direction_input(eth_gpio);
> +}
> +
> +static struct plat_serial8250_port serial_platform_data[] = {
> + {
> + .mapbase= 0x1000,
> + .irq= OMAP_GPIO_IRQ(102),
> + .flags = UPF_BOOT_AUTOCONF|UPF_IOREMAP|UPF_SHARE_IRQ,
> + .iotype = UPIO_MEM,
> + .regshift = 1,
> + .uartclk= QUART_CLK,
> + }, {
> + .flags = 0
> + }
> +};
> +
> +static struct platform_device zoom2_debugboard_serial_device = {
> + .name = "serial8250",
> + .id = PLAT8250_DEV_PLATFORM1,
> + .dev= {
> + .platform_data = serial_platform_data,
> + },
> +};
> +
> +static inline void __init zoom2_init_quaduart(void)
> +{
> + int quart_cs;
> + unsigned long cs_mem_base;
> + int quart_gpio = 0;
> +
> + quart_cs = ZOOM2_QUADUART_CS;
> +
> + if (gpmc_cs_request(quart_cs, SZ_1M, &cs_mem_base) < 0) {
> + printk(KERN_ERR "Failed to request GPMC mem"
> + "for Quad UART(TL16CP754C)\n");
> + return;
> + }
> +
> + quart_gpio = ZOOM2_QUADUART_GPIO;
> +
> + if (gpio_request(quart_gpio, "TL16CP754C GPIO") < 0) {
> + printk(KERN_ERR "Failed to request GPIO%d for TL16CP754C\n",
> + quart_gpio);
> + return;
> + }
> + gpio_direction_input(quart_gpio);
> +}
> +
> +static inline int omap_zoom2_debugboard_detect(void)
> +{
> + int debug_board_detect = 0;
> +
> + debug_board_detect = ZOOM2_SMSC911X_GPIO;
> +
> + if (gpio_request(debug_board_detect, "Zoom2 debug bo
RE: [PATCH 01/11] OMAP2/3: PM: push core PM code from linux-omap
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Monday, May 18, 2009 4:11 PM > On Mon, May 18, 2009 at 03:47:31PM -0500, Woodruff, Richard wrote: > > The code flow is: > > - Wakeup event > > - ARM reboots and uses SOC mask ROM context restore helper > > - Mask ROM code jump to restore pointers with MMU OFF. > > - Restore code resets ARM CortexA8 state > > -*- Trustzone SMI calls are made to restore some secure state > > - Jump back from SRAM to C code > > > > The dangling question to me is if any of the cpu state is needed by > > the trustzone monitor code as a precondition. The doc's I have led > > me to believe its ok, but I've not verified this. > > There shouldn't be - it would be _really_ silly if the trustzone monitor > had pre-requisits for the exception mode registers. There's no way that > Linux's use of the exception mode registers is anywhere near the same as > other OSes, and Linux's use of the exception mode registers has changed > over time anyway. We make no promise that we'll keep the way we're using > these registers today either. > > So there are no external guarantees about what useful state the kernel > puts into these registers. Having external code rely on some state > there would itself be broken. > > There's also the problem that if there was a dependency on the insecure > exception mode registers from within the trusted environment, that'd > surely be a rather big security problem in itself. Yes those are reasonable comments. In OMAP2 time security required nasty hacks to Linux vectors code (and other OSes). For OMAP3 the security API does take parameters to say if local OS interrupts are allowed or not. In the case they are there the vector base in monitor is used. Some stacking does occur to allow return. So yes as long as local IRQs are off it should be ok. Changes still need validation. Security does something to SOC resources like DMA which have caused confusion. For instance you call the API and specify a DMA channel. This is ok. But you will find some status left in channel which needs clean up before a successful sleep can happen. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
On Mon, May 18, 2009 at 03:47:31PM -0500, Woodruff, Richard wrote: > The code flow is: > - Wakeup event > - ARM reboots and uses SOC mask ROM context restore helper > - Mask ROM code jump to restore pointers with MMU OFF. > - Restore code resets ARM CortexA8 state > -*- Trustzone SMI calls are made to restore some secure state > - Jump back from SRAM to C code > > The dangling question to me is if any of the cpu state is needed by > the trustzone monitor code as a precondition. The doc's I have led > me to believe its ok, but I've not verified this. There shouldn't be - it would be _really_ silly if the trustzone monitor had pre-requisits for the exception mode registers. There's no way that Linux's use of the exception mode registers is anywhere near the same as other OSes, and Linux's use of the exception mode registers has changed over time anyway. We make no promise that we'll keep the way we're using these registers today either. So there are no external guarantees about what useful state the kernel puts into these registers. Having external code rely on some state there would itself be broken. There's also the problem that if there was a dependency on the insecure exception mode registers from within the trusted environment, that'd surely be a rather big security problem in itself. -- To unsubscribe from this list: send the line "unsubscribe 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
> From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Monday, May 18, 2009 3:25 PM > The call to the enter method essentially calls the core specific suspend > function (eg, pxa25x_cpu_suspend()), which is an assembly function which > ultimately ends up powering down the core resulting in full loss of state > in the CPU. We seem to be able to avoid having to save the exception mode > registers there. > > The same thing is done with sa11x0 and Samsung SoCs. > > I don't see any reason for OMAP to be "special" in this regard. The code flow is: - Wakeup event - ARM reboots and uses SOC mask ROM context restore helper - Mask ROM code jump to restore pointers with MMU OFF. - Restore code resets ARM CortexA8 state -*- Trustzone SMI calls are made to restore some secure state - Jump back from SRAM to C code The dangling question to me is if any of the cpu state is needed by the trustzone monitor code as a precondition. The doc's I have led me to believe its ok, but I've not verified this. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
On Mon, May 18, 2009 at 02:04:19PM -0500, Woodruff, Richard wrote:
> cpu_init() is not yet accessible at the point this code is running.
Not at that _exact_ point, but there's no need what so ever for it
to be at that exact point. There's nothing stopping a call to
cpu_init() happening later. Much later.
> You could reduce the context perhaps trying to optimize to what the
> Linux-ARM implementation is today or do a more generic save like is
> there now.
>
> This code is copied into place from the .S code into SRAM. Its
> position independent and is not linked for this address. If you want
> to call functions outside of it you need to manually setup linkage.
I wouldn't want to.
> Calling functions on the way _UP_ from wake is NOT easy (like the one
> you propose) as the MMU is not yet enabled. The MMU is enabled only
> below this. Calling cpu_init() is not do able here. Even if you
> dress up the calling pointer to the physical address, it won't work
> as cpu_init() makes a global variable dereferences (smp_processor_id
> & stacks[]).
As long as IRQs and FIQs are disabled, you are in a 100% predictable
environment.
1. No IRQ or FIQ will be entered; if they are the CPU is buggy.
2. No data or prefetch abort will be entered _unless_ you purposely
access some non-present memory (and you're not exactly going to
start paging memory in with IRQs disabled.)
So restoring the abort and IRQ mode register state is just plain not
necessary in your SRAM code.
Let's look at the code. Here are the pertinent bits from Kevin's patch:
static void omap3_pm_idle(void)
{
local_irq_disable();
local_fiq_disable();
omap_sram_idle();
local_fiq_enable();
local_irq_enable();
}
static void omap_sram_idle(void)
{
_omap_sram_idle(NULL, save_state);
}
_omap_sram_idle = omap_sram_push(omap34xx_cpu_suspend,
omap34xx_cpu_suspend_sz);
pm_idle = omap3_pm_idle;
_omap_sram_idle() is the assembly code we're discussing, and here we're
referring to its version in SRAM. From the above code, we can clearly
see that this is entered with FIQs and IRQs disabled. So everything
inside omap_sram_idle() is running in a well defined environment provided
prefetch and data aborts don't happen.
There is nothing stopping this from becoming:
static void omap3_pm_idle(void)
{
local_irq_disable();
local_fiq_disable();
omap_sram_idle();
+ cpu_init();
local_fiq_enable();
local_irq_enable();
}
and having the saving of IRQ, FIQ and abort mode registers removed
from the SRAM code.
Other SoCs do precisely this - let's look at PXA:
pxa_cpu_pm_fns->enter(state);
cpu_init();
The call to the enter method essentially calls the core specific suspend
function (eg, pxa25x_cpu_suspend()), which is an assembly function which
ultimately ends up powering down the core resulting in full loss of state
in the CPU. We seem to be able to avoid having to save the exception mode
registers there.
The same thing is done with sa11x0 and Samsung SoCs.
I don't see any reason for OMAP to be "special" in this regard.
--
To unsubscribe from this list: send the line "unsubscribe 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 08/11] ARM: OMAP2/3: GPIO: do not attempt to wake-enable
Hi Kevin,
> Signed-off-by: Kevin Hilman
> Signed-off-by: Tony Lindgren
> ---
> arch/arm/plat-omap/gpio.c | 14 --
> 1 files changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
> index d3fa41e..210a1c0 100644
> --- a/arch/arm/plat-omap/gpio.c
> +++ b/arch/arm/plat-omap/gpio.c
> @@ -921,13 +921,10 @@ static int _set_gpio_wakeup(struct gpio_bank *bank,
> int gpio, int enable)
> case METHOD_MPUIO:
> case METHOD_GPIO_1610:
> spin_lock_irqsave(&bank->lock, flags);
> - if (enable) {
> + if (enable)
> bank->suspend_wakeup |= (1 << gpio);
> - enable_irq_wake(bank->irq);
> - } else {
> - disable_irq_wake(bank->irq);
> + else
> bank->suspend_wakeup &= ~(1 << gpio);
> - }
> spin_unlock_irqrestore(&bank->lock, flags);
> return 0;
> #endif
> @@ -940,13 +937,10 @@ static int _set_gpio_wakeup(struct gpio_bank *bank,
> int gpio, int enable)
> return -EINVAL;
> }
> spin_lock_irqsave(&bank->lock, flags);
> - if (enable) {
> + if (enable)
> bank->suspend_wakeup |= (1 << gpio);
> - enable_irq_wake(bank->irq);
> - } else {
> - disable_irq_wake(bank->irq);
> + else
> bank->suspend_wakeup &= ~(1 << gpio);
> - }
> spin_unlock_irqrestore(&bank->lock, flags);
> return 0;
> #endif
I have been looking into an issue that appears to be related to this. I have
the following questions with regard to this patch.
1). Although, I agree with the above change was there any reason why we did not
add some code to set/clear the appropriate bit in the WKUENA register in this
function? If this function is called via a call to set_irq_wake it will not
modify the WKUENA register. Therefore, we were thinking of something along the
lines of:
diff --git a/arch/arm/plat-omap/gpio.c b/arch/arm/plat-omap/gpio.c
index 17d7afe..895c548 100644
--- a/arch/arm/plat-omap/gpio.c
+++ b/arch/arm/plat-omap/gpio.c
@@ -941,10 +941,13 @@ static int _set_gpio_wakeup(struct gpio_bank *bank, int
gpio, int enable)
return -EINVAL;
}
spin_lock_irqsave(&bank->lock, flags);
- if (enable)
+ if (enable) {
bank->suspend_wakeup |= (1 << gpio);
- else
+ __raw_writel(1 << gpio, bank->base +
OMAP24XX_GPIO_SETWKUENA);
+ } else {
+ __raw_writel(1 << gpio, bank->base +
OMAP24XX_GPIO_CLEARWKUENA);
bank->suspend_wakeup &= ~(1 << gpio);
+ }
spin_unlock_irqrestore(&bank->lock, flags);
return 0;
#endif
2). We have found that a call to request_irq results in a call to the function
"set_24xx_gpio_triggering()" (for OMAP3430). In addition to configuring the
triggering for a given GPIO, this function is also programming the WKUENA
register. Hence, the wake-up enable is enabled for GPIO without calling
set_irq_wake().
I am not sure if this is the intended behaviour or if drivers should explicitly
be calling set_irq_wake to enable/disable the wake-up.
The other problem with this is that once request_irq is called for a gpio, then
even if we call disable_irq the wake-up event is not cleared. So this means
that a gpio event will still wake-up the device without the gpio being enabled
and because the gpio is disabled the event will never be cleared and hence will
prevent retention.
So should the wake-up event only be enabled/disabled by a call to
set_irq_wake() or should we make sure that calling disable_irq in turn calls
gpio_mask_irq and make sure this clears the wake-up event?
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] usb: disable OTG AUTOIDLE only with omap3430
> From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- > ow...@vger.kernel.org] On Behalf Of Niilo Minkkinen > Sent: Monday, May 18, 2009 9:54 AM > Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG > register prevents the device from going into retention. > This is a workaround (by Richard Woodruff/TI), as his comment : > > A new MUSB bug which is a match to data below was identified very > > recently (on hardware and in simulation). > > This bug is in 3430 and not 3630. > > As a priority test (and as new default) you should have engineers > > disable autoidle for MUSB block. > > This is the workaround which will show up in next errata. > > Signed-off-by: Niilo Minkkinen Signed-off-by: Richard Woodruff Yes this is needed for 34xx. Side note is this cost around 1mW of power during active mode of MUSB. When device is not active cost is not significant. System impact depends on duty cycle of MUSB in usecase. Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
> From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Monday, May 18, 2009 12:09 PM > To: Russell King - ARM Linux; Woodruff, Richard > > There is a function which re-initializes the abort mode registers already - > > cpu_init(). Please use that if possible instead. > > Upon a quick glance, using cpu_init() would not cover all the things > that this code does. cpu_init() only handles the init of sp for the > various modes, where this code saves/resores all the banked registers: > sp, lr and spsr as well as r8-r12 of FIQ mode. cpu_init() is not yet accessible at the point this code is running. You could reduce the context perhaps trying to optimize to what the Linux-ARM implementation is today or do a more generic save like is there now. This code is copied into place from the .S code into SRAM. Its position independent and is not linked for this address. If you want to call functions outside of it you need to manually setup linkage. Calling outside functions on the way _DOWN_ is ok. For instance in current TI reference code all cache flush is calling to kernel functions. This saves in space, duplication maintenance and is actually _much_ quicker as it executes from a cached address range. The cache flush code takes 770uS from kernel area and takes 2.2mS from sram (non-cached map). Calling functions on the way _UP_ from wake is NOT easy (like the one you propose) as the MMU is not yet enabled. The MMU is enabled only below this. Calling cpu_init() is not do able here. Even if you dress up the calling pointer to the physical address, it won't work as cpu_init() makes a global variable dereferences (smp_processor_id & stacks[]). Regards, Richard W. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
On Mon, May 18, 2009 at 10:13:55AM -0700, Kevin Hilman wrote: > Russell King - ARM Linux writes: > > > On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote: > >> Russell King - ARM Linux writes: > >> > >> > On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote: > >> >> "stanley.miao" writes: > >> >> > >> >> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been > >> >> >> reported earlier. Switching to 2008q3 works. > >> >> > > >> >> > Yeah, Now the kernel booted. it's compiler's problem. > >> >> > >> >> I was bitten by the same problem few weeks ago. Any chance of getting a > >> >> warning/error if using 2007q3 compiler until the problem is fixed? > >> > > >> > Is there any way of detecting the 2007q3 compiler? > >> > > >> > With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and > >> > __GNUC_PATCHLEVEL__ to identify the three digit version number. > >> > >> I don't know, most probably not. But Jon Hunter investigated the issue > >> and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS: > >> > >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html > >> > >> So maybe we can fix or workaround this. > > > > Why does this change anything? FRAME_POINTERS seems to be enabled > > anyway (and should be given the Kconfig setup we have.) > > See the 'depends on' line in lib/Kconfig.debug. The result is that > without the patch from Jon, even if you have CONFIG_FRAME_POINTERS=y > in your .config, it gets dropped if the arch doesn't set > CONFIG_ARCH_WANT_FRAME_POINTERS. Well, two things. 1. We don't want to force frame pointers on if unwinding support is enabled. 2. The lib/Kconfig.debug entry is overridden by ARM's own version in arch/arm/Kconfig.debug. I've added samr into the discussion since he created this. arch/arm/Kconfig.debug: # RMK wants arm kernels compiled with frame pointers or stack unwinding. # If you know what you are doing and are willing to live without stack # traces, you can get a slightly smaller kernel by setting this option to # n, but then RMK will have to kill you ;). config FRAME_POINTER bool default y if !ARM_UNWIND help If you say N here, the resulting kernel will be slightly smaller and faster. However, if neither FRAME_POINTER nor ARM_UNWIND are enabled, when a problem occurs with the kernel, the information that is reported is severely limited. And lib/Kconfig.debug: config FRAME_POINTER bool "Compile the kernel with frame pointers" depends on DEBUG_KERNEL && \ (CRIS || M68K || M68KNOMMU || FRV || UML || \ AVR32 || SUPERH || BLACKFIN || MN10300) || \ ARCH_WANT_FRAME_POINTERS default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS help If you say Y here the resulting kernel image will be slightly larger and slower, but it gives very useful debugging information in case of kernel bugs. (precise oopses/stacktraces/warnings) this still results in frame pointers being enabled. This is because the ARM version follows the one in lib/, it overrides it rather than supplementing the generic version. I've just checked that by adding 'n &&' to that depends on line in lib/Kconfig.debug, and making oldconfig. I still end up with FRAME_POINTER=y in my configs. However, if I stub out the 'default y' line in arch/arm/Kconfig.debug, it goes away. So I think setting ARCH_WANT_FRAME_POINTERS will be ineffectual. Moreover, I don't think forcing frame pointers to be enabled even with unwinding support is the right solution - if we have frame pointers there's no need for unwind support (so maybe the right answer is to force unwind support off for the time being?) -- To unsubscribe from this list: send the line "unsubscribe 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
On Mon, May 18, 2009 at 10:08:36AM -0700, Kevin Hilman wrote: > [ adding Richard W. to To: since he can probably shed some light here ] > > Russell King - ARM Linux writes: > > > On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote: > >> This patch is to sync the core linux-omap PM code with mainline. This > >> code has evolved and been used for a while the linux-omap tree, but > >> the attempt here is to finally get this into mainline. > > [...] > > Upon a quick glance, using cpu_init() would not cover all the things > that this code does. cpu_init() only handles the init of sp for the > various modes, where this code saves/resores all the banked registers: > sp, lr and spsr as well as r8-r12 of FIQ mode. It doesn't touch sp, lr and spsr for the other modes because there's no requirement to do so. Think about it for a moment. Is there any point to saving LR and SPSR for the abort, FIQ and IRQ modes? No - LR and SPSR are overwritten by the hardware immediately upon entry to the relevent mode via an exception. What about SP? We use SP in the vector entry code, and we need to ensure that this is re-initialized. We never change their value, so we know that these are constant, and therefore if we initialize them once we can repeat the same initialization to restore their values when those values are lost. This is precisely what cpu_init() does. As for FIQ r8-r12, yes this is missing, and it's something that needs to be handled by _every_ platform which puts the CPU into low power state, be that PXA, S3C2410, and so forth. We have code to allow the FIQ vector to be managed, and as yet those architectures which do support sleep modes don't use FIQ mode, hence why there's nothing for it yet. Feel free to add the necessary suspend/resume code to (eg) arch/arm/kernel/fiq.c to fill this hole though. Lastly is system mode. The kernel doesn't use system mode, and this mode doesn't exist in all CPUs (its marked as unpredictable on many older CPUs.) We need a _generic_ extension to support that mode _if_ it is used. Presently it is not used, and so we simply don't bother saving those registers. > The question in my mind however is whether the lr and spsr need to be > saved/restored? Do we really need to preserve the context of these > handlers across idle? Idle is called essentially in process context, with the exception that it's SVC mode rather than user mode. That means no exception handlers will be running. So I think you'll find cpu_init() does everything you require. -- To unsubscribe from this list: send the line "unsubscribe 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
Russell King - ARM Linux writes: > On Mon, May 18, 2009 at 10:00:44AM -0700, Kevin Hilman wrote: >> Russell King - ARM Linux writes: >> >> > On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote: >> >> This patch is to sync the core linux-omap PM code with mainline. This >> >> code has evolved and been used for a while the linux-omap tree, but >> >> the attempt here is to finally get this into mainline. >> >> >> >> Following this will be a series of patches from the 'PM branch' of the >> >> linux-omap tree to add full PM hardware support from the linux-omap >> >> tree. >> >> >> >> Much of this PM core code was written by Jouni Hogander with >> >> significant contributions from Paul Walmsley as well as many others >> >> from Nokia, Texas Instruments and linux-omap community. >> > >> > Overall comment, I think we need to rework the idle support code so >> > that enable_hlt/disable_hlt can be used even when pm_idle has been >> > overridden, rather than OMAP going off and inventing its own mechanisms. >> >> Would adding: >> >> if (hlt_counter) >> cpu_relax(); >> >> to the beginning of omap*_pm_idle functions be sufficient? That will >> at least allow the hlt stuff to behave as expected. > > Yes, but the comment was also directed at the other functions which > increment/decrement that atomic_t variable to enable/disable sleep mode. Ah, right. The sleep_block stuff is only used in OMAP2, we don't use that anymore in OMAP3. In fact, even OMAP2 users of this should be updated to use the OMAP PM layer, so I'll just drop the sleep_block hooks. >> The only thing the OMAP /sys/power/sleep_while_idle hook adds to this >> functionality is the ability to control this from sysfs. >> >> Any objections to /sys/power/enable_hlt? > > That seems to be rather dangerous, even with your atomic based code which > bugs if the count goes below zero. Atomic sleep_block code to be removed. > The problem here is that such an interface is extremely fragile. Consider > what happens if a program disables HLT, and then gets killed off for some > reason. How does this reference get balanced again? > > I think a better solution would be a char device driver which has to be > kept open as long as a reference is held. When userspace closes it (be > that because the program has exited, been killed, etc) you can drop any > pending references. OK, this interface is not intended for users/applications. It is intended only for OMAP PM developers who are developing the PM code and want to prevent idle for various reasons during development. It is not intended for productions systems. What about leaving /sys/power/sleep_while_idle but only if CONFIG_PM_DEBUG=y? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
Russell King - ARM Linux writes: > On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote: >> Russell King - ARM Linux writes: >> >> > On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote: >> >> "stanley.miao" writes: >> >> >> >> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been >> >> >> reported earlier. Switching to 2008q3 works. >> >> > >> >> > Yeah, Now the kernel booted. it's compiler's problem. >> >> >> >> I was bitten by the same problem few weeks ago. Any chance of getting a >> >> warning/error if using 2007q3 compiler until the problem is fixed? >> > >> > Is there any way of detecting the 2007q3 compiler? >> > >> > With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and >> > __GNUC_PATCHLEVEL__ to identify the three digit version number. >> >> I don't know, most probably not. But Jon Hunter investigated the issue >> and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS: >> >> http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html >> >> So maybe we can fix or workaround this. > > Why does this change anything? FRAME_POINTERS seems to be enabled > anyway (and should be given the Kconfig setup we have.) See the 'depends on' line in lib/Kconfig.debug. The result is that without the patch from Jon, even if you have CONFIG_FRAME_POINTERS=y in your .config, it gets dropped if the arch doesn't set CONFIG_ARCH_WANT_FRAME_POINTERS. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/11] OMAP2/3: PM: push core PM code from linux-omap
[ adding Richard W. to To: since he can probably shed some light here ]
Russell King - ARM Linux writes:
> On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote:
>> This patch is to sync the core linux-omap PM code with mainline. This
>> code has evolved and been used for a while the linux-omap tree, but
>> the attempt here is to finally get this into mainline.
[...]
[excerpt of sleep34xx.S]
>> +/* IRQ mode */
>> +bicr0, r7, #0x1F
>> +orrr0, r0, #0x12
>> +msrcpsr, r0 /*go into IRQ mode*/
>> +ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM*/
>> +movsp, r4 /*update the SP */
>> +movlr, r5 /*update the LR */
>> +msrspsr, r6 /*update the SPSR */
>> +
>> +/* ABORT mode */
>> +bicr0, r7, #0x1F
>> +orrr0, r0, #0x17
>> +msrcpsr, r0 /* go into ABORT mode */
>> +ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM */
>> +movsp, r4 /*update the SP */
>> +movlr, r5 /*update the LR */
>> +msrspsr, r6 /*update the SPSR */
>> +
>> +/* UNDEEF mode */
>> +bicr0, r7, #0x1F
>> +orrr0, r0, #0x1B
>> +msrcpsr, r0 /*go into UNDEF mode */
>> +ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM */
>> +movsp, r4 /*update the SP*/
>> +movlr, r5 /*update the LR*/
>> +msrspsr, r6 /*update the SPSR*/
>> +
>> +/* SYSTEM (USER) mode */
>> +bicr0, r7, #0x1F
>> +orrr0, r0, #0x1F
>> +msrcpsr, r0 /*go into USR mode */
>> +ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM*/
>> +movsp, r4 /*update the SP */
>> +movlr, r5 /*update the LR */
>> +msrspsr, r6 /*update the SPSR */
>> +msrcpsr, r7 /*back to original mode*/
>
> There is a function which re-initializes the abort mode registers already -
> cpu_init(). Please use that if possible instead.
Upon a quick glance, using cpu_init() would not cover all the things
that this code does. cpu_init() only handles the init of sp for the
various modes, where this code saves/resores all the banked registers:
sp, lr and spsr as well as r8-r12 of FIQ mode.
The question in my mind however is whether the lr and spsr need to be
saved/restored? Do we really need to preserve the context of these
handlers across idle? Presumably we should not hit idle/suspend in
the middle of one of these handlers, so do we need to save anything
other than the stp? Maybe Richard can shed some light here as to why
that was added.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/11] OMAP2/3: PM: push core PM code from linux-omap
On Mon, May 18, 2009 at 10:00:44AM -0700, Kevin Hilman wrote: > Russell King - ARM Linux writes: > > > On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote: > >> This patch is to sync the core linux-omap PM code with mainline. This > >> code has evolved and been used for a while the linux-omap tree, but > >> the attempt here is to finally get this into mainline. > >> > >> Following this will be a series of patches from the 'PM branch' of the > >> linux-omap tree to add full PM hardware support from the linux-omap > >> tree. > >> > >> Much of this PM core code was written by Jouni Hogander with > >> significant contributions from Paul Walmsley as well as many others > >> from Nokia, Texas Instruments and linux-omap community. > > > > Overall comment, I think we need to rework the idle support code so > > that enable_hlt/disable_hlt can be used even when pm_idle has been > > overridden, rather than OMAP going off and inventing its own mechanisms. > > Would adding: > > if (hlt_counter) > cpu_relax(); > > to the beginning of omap*_pm_idle functions be sufficient? That will > at least allow the hlt stuff to behave as expected. Yes, but the comment was also directed at the other functions which increment/decrement that atomic_t variable to enable/disable sleep mode. > The only thing the OMAP /sys/power/sleep_while_idle hook adds to this > functionality is the ability to control this from sysfs. > > Any objections to /sys/power/enable_hlt? That seems to be rather dangerous, even with your atomic based code which bugs if the count goes below zero. The problem here is that such an interface is extremely fragile. Consider what happens if a program disables HLT, and then gets killed off for some reason. How does this reference get balanced again? I think a better solution would be a char device driver which has to be kept open as long as a reference is held. When userspace closes it (be that because the program has exited, been killed, etc) you can drop any pending references. -- To unsubscribe from this list: send the line "unsubscribe 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 01/11] OMAP2/3: PM: push core PM code from linux-omap
Russell King - ARM Linux writes:
> On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote:
>> This patch is to sync the core linux-omap PM code with mainline. This
>> code has evolved and been used for a while the linux-omap tree, but
>> the attempt here is to finally get this into mainline.
>>
>> Following this will be a series of patches from the 'PM branch' of the
>> linux-omap tree to add full PM hardware support from the linux-omap
>> tree.
>>
>> Much of this PM core code was written by Jouni Hogander with
>> significant contributions from Paul Walmsley as well as many others
>> from Nokia, Texas Instruments and linux-omap community.
>
> Overall comment, I think we need to rework the idle support code so
> that enable_hlt/disable_hlt can be used even when pm_idle has been
> overridden, rather than OMAP going off and inventing its own mechanisms.
Would adding:
if (hlt_counter)
cpu_relax();
to the beginning of omap*_pm_idle functions be sufficient? That will
at least allow the hlt stuff to behave as expected.
The only thing the OMAP /sys/power/sleep_while_idle hook adds to this
functionality is the ability to control this from sysfs.
Any objections to /sys/power/enable_hlt?
>> diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
>> new file mode 100644
>> index 000..2a2d1a3
>> --- /dev/null
>> +++ b/arch/arm/mach-omap2/pm24xx.c
>> @@ -0,0 +1,557 @@
>> +/*
>> + * OMAP2 Power Management Routines
>> + *
>> + * Copyright (C) 2005 Texas Instruments, Inc.
>> + * Copyright (C) 2006-2008 Nokia Corporation
>> + *
>> + * Written by:
>> + * Richard Woodruff
>> + * Tony Lindgren
>> + * Juha Yrjola
>> + * Amit Kucheria
>> + * Igor Stoppa
>> + *
>> + * Based on pm.c for omap1
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>
> Should be linux/gpio.h
Ack
>> +/*
>> + * Note that you can use clock_event_device->min_delta_ns if you want to
>> + * avoid reprogramming timer too often when using CONFIG_NO_HZ.
>> + */
>> +static void omap2_pm_idle(void)
>> +{
>> +local_irq_disable();
>> +local_fiq_disable();
>> +
>> +if (!omap2_can_sleep()) {
>> +if (!atomic_read(&sleep_block) && omap2_irq_pending())
>> +goto out;
>> +omap2_enter_mpu_retention();
>> +goto out;
>> +}
>> +
>> +if (omap2_irq_pending())
>> +goto out;
>> +
>> +omap2_enter_full_retention();
>> +
>> +out:
>> +local_fiq_enable();
>> +local_irq_enable();
>> +}
>
> It's totally unclear what the comment above the function has to do with
> the function itself.
Indeed. Will be removed.
>> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
>> new file mode 100644
>> index 000..0fb6bec
>> --- /dev/null
>> +++ b/arch/arm/mach-omap2/pm34xx.c
>> @@ -0,0 +1,607 @@
>> +/*
>> + * OMAP3 Power Management Routines
>> + *
>> + * Copyright (C) 2006-2008 Nokia Corporation
>> + * Tony Lindgren
>> + * Jouni Hogander
>> + *
>> + * Copyright (C) 2005 Texas Instruments, Inc.
>> + * Richard Woodruff
>> + *
>> + * Based on pm.c for omap1
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#include
>
> Should be linux/gpio.h
Ack
>> +static void omap3_pm_idle(void)
>> +{
>> +local_irq_disable();
>> +local_fiq_disable();
>> +
>> +if (!omap3_can_sleep())
>> +goto out;
>> +
>> +if (omap_irq_pending())
>> +goto out;
>
> So what happens if an IRQ becomes pending at this precise point?
Then it gets missed this time, and will be triggered upon wakeup. If
it's a wakeup-capable interrupt, then it will wake the system
immediately.
In subsequent series of the PM branch, this will be going away in
favor of using the [enable|disable]_irq_wake() and the lazy IRQ
disabling features.
>> +
>> +omap_sram_idle();
>> +
>> +out:
>> +local_fiq_enable();
>> +local_irq_enable();
>> +}
>> +/* IRQ mode */
>> +bicr0, r7, #0x1F
>> +orrr0, r0, #0x12
>> +msrcpsr, r0 /*go into IRQ mode*/
>> +ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM*/
>> +movsp, r4 /*update the SP */
>> +movlr, r5 /*update the LR */
>> +msrspsr, r6 /*update the SPSR */
>> +
>> +/* ABORT mode */
>> +bicr0, r7, #0x1F
>> +
[PATCH] omap3-iommu: reorganize
No functional changes.
Signed-off-by: Felipe Contreras
---
How about this?
arch/arm/mach-omap2/omap3-iommu.c | 53 ++---
1 files changed, 26 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/omap3-iommu.c
b/arch/arm/mach-omap2/omap3-iommu.c
index 91ee38a..50bd445 100644
--- a/arch/arm/mach-omap2/omap3-iommu.c
+++ b/arch/arm/mach-omap2/omap3-iommu.c
@@ -14,32 +14,30 @@
#include
-#define OMAP3_MMU1_BASE0x480bd400
-#define OMAP3_MMU2_BASE0x5d00
-#define OMAP3_MMU1_IRQ 24
-#define OMAP3_MMU2_IRQ 28
-
-
-static unsigned long iommu_base[] __initdata = {
- OMAP3_MMU1_BASE,
- OMAP3_MMU2_BASE,
-};
-
-static int iommu_irq[] __initdata = {
- OMAP3_MMU1_IRQ,
- OMAP3_MMU2_IRQ,
+struct iommu_device {
+ resource_size_t base;
+ int irq;
+ struct iommu_platform_data pdata;
};
-static const struct iommu_platform_data omap3_iommu_pdata[] __initconst = {
+static struct iommu_device devices[] __initdata = {
{
- .name = "isp",
- .nr_tlb_entries = 8,
- .clk_name = "cam_ick",
+ .base = 0x480bd400,
+ .irq = 24,
+ .pdata = {
+ .name = "isp",
+ .nr_tlb_entries = 8,
+ .clk_name = "cam_ick",
+ },
},
{
- .name = "iva2",
- .nr_tlb_entries = 32,
- .clk_name = "iva2_ck",
+ .base = 0x5d00,
+ .irq = 28,
+ .pdata = {
+ .name = "iva2",
+ .nr_tlb_entries = 32,
+ .clk_name = "iva2_ck",
+ },
},
};
#define NR_IOMMU_DEVICES ARRAY_SIZE(omap3_iommu_pdata)
@@ -52,6 +50,7 @@ static int __init omap3_iommu_init(void)
for (i = 0; i < NR_IOMMU_DEVICES; i++) {
struct platform_device *pdev;
+ const struct iommu_device *d = &devices[i];
struct resource res[2];
pdev = platform_device_alloc("omap-iommu", i);
@@ -60,19 +59,19 @@ static int __init omap3_iommu_init(void)
goto err_out;
}
- memset(res, 0, sizeof(res));
- res[0].start = iommu_base[i];
- res[0].end = iommu_base[i] + MMU_REG_SIZE - 1;
+ memset(res, 0, sizeof(res));
+ res[0].start = d->base;
+ res[0].end = d->base + MMU_REG_SIZE - 1;
res[0].flags = IORESOURCE_MEM;
- res[1].start = res[1].end = iommu_irq[i];
+ res[1].start = res[1].end = d->irq;
res[1].flags = IORESOURCE_IRQ;
err = platform_device_add_resources(pdev, res,
ARRAY_SIZE(res));
if (err)
goto err_out;
- err = platform_device_add_data(pdev, &omap3_iommu_pdata[i],
- sizeof(omap3_iommu_pdata[0]));
+ err = platform_device_add_data(pdev, &d->pdata,
+ sizeof(d->pdata));
if (err)
goto err_out;
err = platform_device_add(pdev);
--
1.6.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
On Mon, May 18, 2009 at 06:54:56PM +0300, Kalle Valo wrote: > Russell King - ARM Linux writes: > > > On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote: > >> "stanley.miao" writes: > >> > >> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been > >> >> reported earlier. Switching to 2008q3 works. > >> > > >> > Yeah, Now the kernel booted. it's compiler's problem. > >> > >> I was bitten by the same problem few weeks ago. Any chance of getting a > >> warning/error if using 2007q3 compiler until the problem is fixed? > > > > Is there any way of detecting the 2007q3 compiler? > > > > With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and > > __GNUC_PATCHLEVEL__ to identify the three digit version number. > > I don't know, most probably not. But Jon Hunter investigated the issue > and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS: > > http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html > > So maybe we can fix or workaround this. Why does this change anything? FRAME_POINTERS seems to be enabled anyway (and should be given the Kconfig setup we have.) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP_LDP: Support LCD display as a FB device on ZOOM MDK (Re: LDP support)
Russell King - ARM Linux writes: > On Fri, May 08, 2009 at 07:47:09PM +0300, Kalle Valo wrote: >> "stanley.miao" writes: >> >> >> Looks like you used the CodeSourcery 2007q3 toolchain. This had been >> >> reported earlier. Switching to 2008q3 works. >> > >> > Yeah, Now the kernel booted. it's compiler's problem. >> >> I was bitten by the same problem few weeks ago. Any chance of getting a >> warning/error if using 2007q3 compiler until the problem is fixed? > > Is there any way of detecting the 2007q3 compiler? > > With normal GCC versions, you can use __GNUC__, __GNUC_MINOR__ and > __GNUC_PATCHLEVEL__ to identify the three digit version number. I don't know, most probably not. But Jon Hunter investigated the issue and he found the issue was related to CONFIG_ARCH_WANT_FRAME_POINTERS: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg12403.html So maybe we can fix or workaround this. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe 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: [RESUBMIT][PATCH 4/7] OMAP4: Update common omap platform common sources.
> > > is a static function. The only user of omap4_globals is > > > __omap4_set_globals. > > > It looks to me like the only purpose of omap4_globals is to pass a > > > structure to __omap4_set_globals. Why not use a function > > > argument instead? > > Indeed. Actually I just more or less followed what is done > for OMAP2/OMAP3 here. I will clean this for OMAP4. > > > > Tony, > > We may want to clean up this for OMAP2/OMAP3 as well. Can > we add this to the clean up patches planned if any. I can > create the patch. > > Sure, please post that patch for review. OK Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RESUBMIT][PATCH 4/7] OMAP4: Update common omap platform common sources.
* Shilimkar, Santosh [090516 13:04]:
> Thanks Russell for scanning all the patches minutely !!
>
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Saturday, May 16, 2009 3:24 PM
> > To: Shilimkar, Santosh
> > Cc: linux-arm-ker...@lists.arm.linux.org.uk;
> > linux-omap@vger.kernel.org
> > Subject: Re: [RESUBMIT][PATCH 4/7] OMAP4: Update common omap
> > platform common sources.
> >
> > On Thu, May 07, 2009 at 11:59:13AM +0530, Santosh Shilimkar wrote:
> > > @@ -309,3 +313,26 @@ void __init omap2_set_globals_343x(void)
> > > }
> > > #endif
> > >
> > > +#if defined(CONFIG_ARCH_OMAP4)
> > > +static struct omap_globals *omap4_globals;
> > > +
> > > +static void __init __omap4_set_globals(void)
> > > +{
> > > + omap2_set_globals_tap(omap4_globals);
> > > + omap2_set_globals_control(omap4_globals);
> > > +}
> > > +static struct omap_globals omap443x_globals = {
> > > + .class = OMAP443X_CLASS,
> > > + .tap= OMAP2_IO_ADDRESS(0x4830A000),
> > > + .ctrl = OMAP2_IO_ADDRESS(OMAP443X_CTRL_BASE),
> > > + .prm= OMAP2_IO_ADDRESS(OMAP4430_PRM_BASE),
> > > + .cm = OMAP2_IO_ADDRESS(OMAP4430_CM_BASE),
> > > +};
> > > +
> > > +void __init omap2_set_globals_443x(void)
> > > +{
> > > + omap4_globals = &omap443x_globals;
> > > + __omap4_set_globals();
> >
> > Hmm, confused. omap4_globals is a static variable, and
> > __omap4_set_globals
> > is a static function. The only user of omap4_globals is
> > __omap4_set_globals.
> > It looks to me like the only purpose of omap4_globals is to pass a
> > structure to __omap4_set_globals. Why not use a function
> > argument instead?
> Indeed. Actually I just more or less followed what is done for OMAP2/OMAP3
> here. I will clean this for OMAP4.
>
> Tony,
> We may want to clean up this for OMAP2/OMAP3 as well. Can we add this to the
> clean up patches planned if any. I can create the patch.
Sure, please post that patch for review.
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 08/11] OMAP3: PM: Ensure MUSB block can idle when driver not loaded
* Kevin Hilman [090518 07:50]: > Russell King - ARM Linux writes: > > > On Fri, May 15, 2009 at 11:40:48AM -0700, Kevin Hilman wrote: > >> Otherwise, bootloaders may leave MUSB in a state which prevents > >> retention. > > > > Hmm, so what happens if a boot loader has touched this MUSB thing, but > > the kernel which is being run doesn't have CONFIG_USB_MUSB_SOC enabled? > > Then the OMAP will not be able to hit retention. > > That Makefile change happened after this series was initially made. > I think we should change the Makefile back to always compile usb-musb.c > and move the #ifdef CONFIG_USB_MUSB_SOC into usb-musb.c > > Tony, any objections? Sounds good to me, I like patches that make things behave in a predictable way. We already have enough of these mysterious problems where "the same kernel behaves in a different way on my board" when some registers are only tweaked in the bootloader. 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] usb: disable OTG AUTOIDLE only with omap3430
Omap3 MUSB AUTOIDLE functionality configured through OTG_SYSCONFIG register prevents the device from going into retention. This is a workaround (by Richard Woodruff/TI), as his comment : > A new MUSB bug which is a match to data below was identified very > recently (on hardware and in simulation). > This bug is in 3430 and not 3630. > As a priority test (and as new default) you should have engineers > disable autoidle for MUSB block. > This is the workaround which will show up in next errata. Signed-off-by: Niilo Minkkinen --- drivers/usb/musb/omap2430.c |7 ++- 1 files changed, 6 insertions(+), 1 deletions(-) diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c index 901dffd..396fc6d 100644 --- a/drivers/usb/musb/omap2430.c +++ b/drivers/usb/musb/omap2430.c @@ -241,7 +241,12 @@ int __init musb_platform_init(struct musb *musb) l &= ~AUTOIDLE; /* disable auto idle */ l &= ~NOIDLE; /* remove possible noidle */ l |= SMARTIDLE; /* enable smart idle */ - l |= AUTOIDLE; /* enable auto idle */ + /* +* MUSB AUTOIDLE don't work in 3430. +* Workaround by Richard Woodruff/TI +*/ + if (!cpu_is_omap3430()) + l |= AUTOIDLE; /* enable auto idle */ omap_writel(l, OTG_SYSCONFIG); l = omap_readl(OTG_INTERFSEL); -- 1.6.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/11] OMAP3: PM: Ensure MUSB block can idle when driver not loaded
Russell King - ARM Linux writes: > On Fri, May 15, 2009 at 11:40:48AM -0700, Kevin Hilman wrote: >> Otherwise, bootloaders may leave MUSB in a state which prevents >> retention. > > Hmm, so what happens if a boot loader has touched this MUSB thing, but > the kernel which is being run doesn't have CONFIG_USB_MUSB_SOC enabled? Then the OMAP will not be able to hit retention. That Makefile change happened after this series was initially made. I think we should change the Makefile back to always compile usb-musb.c and move the #ifdef CONFIG_USB_MUSB_SOC into usb-musb.c Tony, any objections? Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] omap iommu: omap3 iommu device registration
From: ext Russell King - ARM Linux
Subject: Re: [PATCH 3/6] omap iommu: omap3 iommu device registration
Date: Sat, 16 May 2009 11:55:14 +0200
> On Sat, May 16, 2009 at 10:20:36AM +0100, Russell King - ARM Linux wrote:
> > This looks all very convoluted. Why not do something like:
> >
> > static unsigned long iommu_base[] = {
> > OMAP3_MMU1_BASE,
> > OMAP3_MMU2_BASE,
> > };
> >
> > static int iommu_irq[] = {
> > OMAP3_MMU1_IRQ,
> > OMAP3_MMU2_IRQ,
> > };
>
> BTW, both of these can be __initdata.
Attached the updated one.
>From 2bfdb4130433708dc04e1c30aa5099d48de408e0 Mon Sep 17 00:00:00 2001
From: Hiroshi DOYU
Date: Wed, 28 Jan 2009 21:32:04 +0200
Subject: [PATCH 3/6] omap iommu: omap3 iommu device registration
Signed-off-by: Hiroshi DOYU
---
arch/arm/mach-omap2/omap3-iommu.c | 103 +
1 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap3-iommu.c
diff --git a/arch/arm/mach-omap2/omap3-iommu.c
b/arch/arm/mach-omap2/omap3-iommu.c
new file mode 100644
index 000..91ee38a
--- /dev/null
+++ b/arch/arm/mach-omap2/omap3-iommu.c
@@ -0,0 +1,103 @@
+/*
+ * omap iommu: omap3 device registration
+ *
+ * Copyright (C) 2008-2009 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+#include
+
+#define OMAP3_MMU1_BASE0x480bd400
+#define OMAP3_MMU2_BASE0x5d00
+#define OMAP3_MMU1_IRQ 24
+#define OMAP3_MMU2_IRQ 28
+
+
+static unsigned long iommu_base[] __initdata = {
+ OMAP3_MMU1_BASE,
+ OMAP3_MMU2_BASE,
+};
+
+static int iommu_irq[] __initdata = {
+ OMAP3_MMU1_IRQ,
+ OMAP3_MMU2_IRQ,
+};
+
+static const struct iommu_platform_data omap3_iommu_pdata[] __initconst = {
+ {
+ .name = "isp",
+ .nr_tlb_entries = 8,
+ .clk_name = "cam_ick",
+ },
+ {
+ .name = "iva2",
+ .nr_tlb_entries = 32,
+ .clk_name = "iva2_ck",
+ },
+};
+#define NR_IOMMU_DEVICES ARRAY_SIZE(omap3_iommu_pdata)
+
+static struct platform_device *omap3_iommu_pdev[NR_IOMMU_DEVICES];
+
+static int __init omap3_iommu_init(void)
+{
+ int i, err;
+
+ for (i = 0; i < NR_IOMMU_DEVICES; i++) {
+ struct platform_device *pdev;
+ struct resource res[2];
+
+ pdev = platform_device_alloc("omap-iommu", i);
+ if (!pdev) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+
+ memset(res, 0, sizeof(res));
+ res[0].start = iommu_base[i];
+ res[0].end = iommu_base[i] + MMU_REG_SIZE - 1;
+ res[0].flags = IORESOURCE_MEM;
+ res[1].start = res[1].end = iommu_irq[i];
+ res[1].flags = IORESOURCE_IRQ;
+
+ err = platform_device_add_resources(pdev, res,
+ ARRAY_SIZE(res));
+ if (err)
+ goto err_out;
+ err = platform_device_add_data(pdev, &omap3_iommu_pdata[i],
+ sizeof(omap3_iommu_pdata[0]));
+ if (err)
+ goto err_out;
+ err = platform_device_add(pdev);
+ if (err)
+ goto err_out;
+ omap3_iommu_pdev[i] = pdev;
+ }
+ return 0;
+
+err_out:
+ while (i--)
+ platform_device_put(omap3_iommu_pdev[i]);
+ return err;
+}
+module_init(omap3_iommu_init);
+
+static void __exit omap3_iommu_exit(void)
+{
+ int i;
+
+ for (i = 0; i < NR_IOMMU_DEVICES; i++)
+ platform_device_unregister(omap3_iommu_pdev[i]);
+}
+module_exit(omap3_iommu_exit);
+
+MODULE_AUTHOR("Hiroshi DOYU");
+MODULE_DESCRIPTION("omap iommu: omap3 device registration");
+MODULE_LICENSE("GPL v2");
--
1.6.0.4
Re: [PATCH][RFC] McSPI Slave and DMA,FIFO support
"Hemanth V" writes:
> - Original Message -
> From: "Gadiyar, Anand"
> To: "V, Hemanth" ; "Kevin Hilman"
>
>
>
>> >> Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
>> >> ===
>> >> --- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2009-05-14
>> >> 12:38:50.0 +0530
>> >> +++ linux-omap-2.6/arch/arm/mach-omap2/devices.c 2009-05-15 >>
>> 16:53:38.0 +0530
>
>
>
>> >> };
>> >>
>> >> static struct resource omap2_mcspi2_resources[] = {
>> >> @@ -351,6 +359,14 @@
>> >>
>> >> static void omap_init_mcspi(void)
>> >> {
>> >> +
>> >> + if (cpu_is_omap3430()) {
>> >> + omap_cfg_reg(AA3_3430_McSPI2_CLK);
>> >> + omap_cfg_reg(Y2_3430_McSPI2_SIMO);
>> >> + omap_cfg_reg(Y3_3430_McSPI2_SOMI);
>> >> + omap_cfg_reg(Y4_3430_McSPI2_CS0);
>> >> + }
>> >> +
>
>>This will change the mux mode for these pads for all OMAP3 boards,
>>even if they do not wish to use McSPI2. In particular, Beagleboard
>>will be affected as it uses HSUSB on Port2 and these pads overlap.
>
> I could add an option like below to plat-omap/Kconfig under
> OMAP Feature Selections. Kevin, Your thoughts on this
>
> config OMAP3430_ENABLE_SPI2_PIN_MUX
>bool "Enable SPI2 pin mux configuration for OMAP3430"
>depends on ARCH_OMAP3430
>default n
>help
>Enable pin mux for SPI2 on OMAP3430 platform. Note
>that the same pins are used for EHCI port2 operation. Hence
>enabling this option effectively disables EHCI port 2
Don't use compile-time setup for this, use runtime. Mux setup is
board-specific and should be done in board init code.
Kevin
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 3/3] omap3-iommu: remote registration
On Mon, May 18, 2009 at 4:40 PM, Russell King - ARM Linux wrote: > On Mon, May 18, 2009 at 04:21:19PM +0300, Felipe Contreras wrote: >> On Mon, May 18, 2009 at 4:02 PM, Russell King - ARM Linux >> wrote: >> > On Mon, May 18, 2009 at 03:46:07PM +0300, Felipe Contreras wrote: >> >> On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux >> >> wrote: >> >> > The real problem here seems to be the TI DSP bridge code, and if that's >> >> > the case why can't we just avoid registering IVA2 if the TI DSP bridge >> >> > code is enabled. That solves your stated problem without creating >> >> > additional management issues. >> >> >> >> The bridgedriver is expected to move and use iommu eventually, but not >> >> right now, so I guess the iva2 device should be registered only if >> >> MPU_BRIDGE_IOMMU is defined. >> >> >> >> But then what's the point of having the isp iommu device if the camera >> >> driver is disabled? Wouldn't that be wasting resources? Then if CAMERA >> >> is not defined the isp device should not be registered either. >> > >> > So have something like: >> > >> > config OMAP_IOMMU >> > tristate >> > >> > and then have both MPU_BRIDGE_IOMMU and the camera support (and whatever >> > else) select it. That way, you only end up with the IOMMU support code >> > built into the kernel if you have users of it. >> > >> > These low-level internal services drivers really don't need to be >> > publically visible in the configuration system. >> >> Yeap, that needs to be done too. >> >> > As for the run-time size, that's truely minimal. >> >> I thought creating iommu devices involved some kind of overhead, >> allocating some resources probably. That's why the iva2 iommu device >> conflicts with tidspbridge custom mmu. > > I believe I've already said how to handle that - in fact it's in the > quoted messages at the top of this mail. > >> >> And finally if none of the two are enabled then you don't really >> >> iommu. By having omap_iommu_add all the dependencies would be handled >> >> automatically, right? 'modprobe bridgedriver' would load iommu. >> > >> > Think about it - the dependencies _already_ have to be there to use >> > the iommu services. >> >> Ok, yes, for iommu, but not for omap3-iommu which is a separate module. > > That is a point, but I think it's a relatively minor one. We could > get around that by ensuring that omap3-iommu is always built-in if > we have the possibility of iommu support, and leave iommu as a module. You mean omap3-iommu will be built-in in the iommu module? That looks ok to me, *if* it's true that iommu devices don't waste any significant resources if nobody is using them. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe 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 3/3] omap3-iommu: remote registration
From: ext Felipe Contreras Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration Date: Mon, 18 May 2009 15:52:59 +0200 > On Mon, May 18, 2009 at 4:35 PM, Hiroshi DOYU wrote: > > From: ext Russell King - ARM Linux > > Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration > > Date: Mon, 18 May 2009 14:11:13 +0200 > > > >> On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote: > >> > This allows devices to be registered only when they are used. The > >> > current dsp-bridge driver for example is not using iommu so registering > >> > the iommu iva2 device would conflict. By allowing remote registration > >> > the dsp-bridge can decide when the iommu iva2 device is registered. > >> > >> I don't think that this is a good idea - what happens if two people > >> call omap_iommu_add() for the same IOMMU device independently? > >> > >> The real problem here seems to be the TI DSP bridge code, and if that's > >> the case why can't we just avoid registering IVA2 if the TI DSP bridge > >> code is enabled. That solves your stated problem without creating > >> additional management issues. > > > > How about the attached patch? I think this is enough. > > That wouldn't work when bridgedriver moves to iommu, how about: > > +#if !defined(CONFIG_MPU_BRIDGE) && !defined(CONFIG_OMAP_DSP_MODULE) > +#if defined(CONFIG_MPU_BRIDGE_IOMMU) Just now I read Russell's proposal. This would be better. Agreed. How about Hari? I think that he's been working on this for a while -- To unsubscribe from this list: send the line "unsubscribe 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 3/3] omap3-iommu: remote registration
From: Hiroshi DOYU Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration Date: Mon, 18 May 2009 16:35:33 +0300 (EEST) > From: ext Russell King - ARM Linux > Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration > Date: Mon, 18 May 2009 14:11:13 +0200 > > > On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote: > > > This allows devices to be registered only when they are used. The > > > current dsp-bridge driver for example is not using iommu so registering > > > the iommu iva2 device would conflict. By allowing remote registration > > > the dsp-bridge can decide when the iommu iva2 device is registered. > > > > I don't think that this is a good idea - what happens if two people > > call omap_iommu_add() for the same IOMMU device independently? > > > > The real problem here seems to be the TI DSP bridge code, and if that's > > the case why can't we just avoid registering IVA2 if the TI DSP bridge > > code is enabled. That solves your stated problem without creating > > additional management issues. > > How about the attached patch? I think this is enough. Oops, CONFIG_NAME was wrong. Attached new one. 0001-omap-iommu-disable-iva2-iommu-device-registration-i.patch Description: Binary data
Re: [RFC/PATCH 3/3] omap3-iommu: remote registration
On Mon, May 18, 2009 at 4:35 PM, Hiroshi DOYU wrote: > From: ext Russell King - ARM Linux > Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration > Date: Mon, 18 May 2009 14:11:13 +0200 > >> On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote: >> > This allows devices to be registered only when they are used. The >> > current dsp-bridge driver for example is not using iommu so registering >> > the iommu iva2 device would conflict. By allowing remote registration >> > the dsp-bridge can decide when the iommu iva2 device is registered. >> >> I don't think that this is a good idea - what happens if two people >> call omap_iommu_add() for the same IOMMU device independently? >> >> The real problem here seems to be the TI DSP bridge code, and if that's >> the case why can't we just avoid registering IVA2 if the TI DSP bridge >> code is enabled. That solves your stated problem without creating >> additional management issues. > > How about the attached patch? I think this is enough. That wouldn't work when bridgedriver moves to iommu, how about: +#if !defined(CONFIG_MPU_BRIDGE) && !defined(CONFIG_OMAP_DSP_MODULE) +#if defined(CONFIG_MPU_BRIDGE_IOMMU) -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe 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 0/3] omap3-iommu: cleanups and remote registration
From: ext Felipe Contreras Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration Date: Mon, 18 May 2009 13:48:09 +0200 > On Mon, May 18, 2009 at 8:16 AM, Hiroshi DOYU wrote: > > From: ext Felipe Contreras > > Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration > > Date: Sat, 16 May 2009 20:32:10 +0200 > > > >> On Sat, May 16, 2009 at 7:36 PM, Russell King - ARM Linux > >> wrote: > >> > On Sat, May 16, 2009 at 01:05:47PM +0300, Felipe Contreras wrote: > >> >> This patch series cleanups up a bit the opap3-iommu device registration > >> >> and > >> >> then allows registration from other parts of the code. > >> >> > >> >> Currently the iva2 code (tidspbridge) is not using iommu, therefore it > >> >> can't be > >> >> used as-is with the current omap iommu. By allowing devies to be > >> >> registered > >> >> externaly (either isp, or iva2) this problem goes away. > >> > > >> > Hmm, so does this mean that the iommu patchset is going to grow by three > >> > patches? Hope not. > > > > This series has been posted for a long time and I want to get this in > > this time with minor fixes. > > > >> I hope Hiroshi integrates my patches. > > > > I think that the problem of yours is that it's not necesary to allow > > device registration around kernel anywhere by "omap_iommu_add()" at > > all, but enough only in "omap3-iommu.c". Since eventually > > "tidspbridge" will use this iommu framework, no need for this > > flexibility. Keeping same kind of device registration in one place is > > good thing from SoC perspective. So I want to avoid adding unnecessary > > flexibility to the code. I'll follow Russell's call, anyway. > > The first patch has nothing to do with omap_iommu_add, it's just > cleanups, and you haven't provided any valid reason to reject them. Your code doesn't work since the other members of "struct resource" haven't been initilialized like: + memset(res, 0, sizeof(res)); Please refer to: http://marc.info/?l=linux-omap&m=124263966231599&w=2 > The rest of the patches are *necessary* as of right now. IMHO iommu > should not be merged in it's current state because it will break > tidspbridge. Maybe after tidspbridge has been fully converted to use > iommu. > > I think there will probably be a conversion period where the > tidspbridge will use iommu optionally, in that period iommu would need > to be patched and add a #ifdef MPU_BRIDGE_IOMMU, that would be ugly. How about: http://lists.arm.linux.org.uk/lurker/attach/3...@20090518.133533.487a3dd4.attach > > Also you haven't answered my questions: what happens if you disable > MPU_BRIDGE? What's the point of iommu to register the iva2 iommu > device? enough small to ignore. > > My patches solves all of those issues. > > -- > Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe 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 3/3] omap3-iommu: remote registration
On Mon, May 18, 2009 at 04:21:19PM +0300, Felipe Contreras wrote: > On Mon, May 18, 2009 at 4:02 PM, Russell King - ARM Linux > wrote: > > On Mon, May 18, 2009 at 03:46:07PM +0300, Felipe Contreras wrote: > >> On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux > >> wrote: > >> > The real problem here seems to be the TI DSP bridge code, and if that's > >> > the case why can't we just avoid registering IVA2 if the TI DSP bridge > >> > code is enabled. That solves your stated problem without creating > >> > additional management issues. > >> > >> The bridgedriver is expected to move and use iommu eventually, but not > >> right now, so I guess the iva2 device should be registered only if > >> MPU_BRIDGE_IOMMU is defined. > >> > >> But then what's the point of having the isp iommu device if the camera > >> driver is disabled? Wouldn't that be wasting resources? Then if CAMERA > >> is not defined the isp device should not be registered either. > > > > So have something like: > > > > config OMAP_IOMMU > > tristate > > > > and then have both MPU_BRIDGE_IOMMU and the camera support (and whatever > > else) select it. That way, you only end up with the IOMMU support code > > built into the kernel if you have users of it. > > > > These low-level internal services drivers really don't need to be > > publically visible in the configuration system. > > Yeap, that needs to be done too. > > > As for the run-time size, that's truely minimal. > > I thought creating iommu devices involved some kind of overhead, > allocating some resources probably. That's why the iva2 iommu device > conflicts with tidspbridge custom mmu. I believe I've already said how to handle that - in fact it's in the quoted messages at the top of this mail. > >> And finally if none of the two are enabled then you don't really > >> iommu. By having omap_iommu_add all the dependencies would be handled > >> automatically, right? 'modprobe bridgedriver' would load iommu. > > > > Think about it - the dependencies _already_ have to be there to use > > the iommu services. > > Ok, yes, for iommu, but not for omap3-iommu which is a separate module. That is a point, but I think it's a relatively minor one. We could get around that by ensuring that omap3-iommu is always built-in if we have the possibility of iommu support, and leave iommu as a module. -- To unsubscribe from this list: send the line "unsubscribe 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 5/6] omap iommu: entries for Kconfig and Makefile
On Tue, May 05, 2009 at 03:47:11PM +0300, Hiroshi DOYU wrote: > +config OMAP_IOMMU > + tristate "IOMMU support" > + depends on ARCH_OMAP > + default n default n is the default whatever. There's no need for the depends line either - the whole file is protected by an "if ARCH_OMAP".."endif" encapsulation. -- To unsubscribe from this list: send the line "unsubscribe 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 3/3] omap3-iommu: remote registration
From: ext Russell King - ARM Linux Subject: Re: [RFC/PATCH 3/3] omap3-iommu: remote registration Date: Mon, 18 May 2009 14:11:13 +0200 > On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote: > > This allows devices to be registered only when they are used. The > > current dsp-bridge driver for example is not using iommu so registering > > the iommu iva2 device would conflict. By allowing remote registration > > the dsp-bridge can decide when the iommu iva2 device is registered. > > I don't think that this is a good idea - what happens if two people > call omap_iommu_add() for the same IOMMU device independently? > > The real problem here seems to be the TI DSP bridge code, and if that's > the case why can't we just avoid registering IVA2 if the TI DSP bridge > code is enabled. That solves your stated problem without creating > additional management issues. How about the attached patch? I think this is enough. 0001-omap-iommu-disable-iva2-iommu-device-registration-i.patch Description: Binary data
Re: [PATCH 01/11] OMAP2/3: PM: push core PM code from linux-omap
On Fri, May 15, 2009 at 11:40:41AM -0700, Kevin Hilman wrote:
> This patch is to sync the core linux-omap PM code with mainline. This
> code has evolved and been used for a while the linux-omap tree, but
> the attempt here is to finally get this into mainline.
>
> Following this will be a series of patches from the 'PM branch' of the
> linux-omap tree to add full PM hardware support from the linux-omap
> tree.
>
> Much of this PM core code was written by Jouni Hogander with
> significant contributions from Paul Walmsley as well as many others
> from Nokia, Texas Instruments and linux-omap community.
Overall comment, I think we need to rework the idle support code so
that enable_hlt/disable_hlt can be used even when pm_idle has been
overridden, rather than OMAP going off and inventing its own mechanisms.
> diff --git a/arch/arm/mach-omap2/pm24xx.c b/arch/arm/mach-omap2/pm24xx.c
> new file mode 100644
> index 000..2a2d1a3
> --- /dev/null
> +++ b/arch/arm/mach-omap2/pm24xx.c
> @@ -0,0 +1,557 @@
> +/*
> + * OMAP2 Power Management Routines
> + *
> + * Copyright (C) 2005 Texas Instruments, Inc.
> + * Copyright (C) 2006-2008 Nokia Corporation
> + *
> + * Written by:
> + * Richard Woodruff
> + * Tony Lindgren
> + * Juha Yrjola
> + * Amit Kucheria
> + * Igor Stoppa
> + *
> + * Based on pm.c for omap1
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
Should be linux/gpio.h
> +/*
> + * Note that you can use clock_event_device->min_delta_ns if you want to
> + * avoid reprogramming timer too often when using CONFIG_NO_HZ.
> + */
> +static void omap2_pm_idle(void)
> +{
> + local_irq_disable();
> + local_fiq_disable();
> +
> + if (!omap2_can_sleep()) {
> + if (!atomic_read(&sleep_block) && omap2_irq_pending())
> + goto out;
> + omap2_enter_mpu_retention();
> + goto out;
> + }
> +
> + if (omap2_irq_pending())
> + goto out;
> +
> + omap2_enter_full_retention();
> +
> +out:
> + local_fiq_enable();
> + local_irq_enable();
> +}
It's totally unclear what the comment above the function has to do with
the function itself.
> diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
> new file mode 100644
> index 000..0fb6bec
> --- /dev/null
> +++ b/arch/arm/mach-omap2/pm34xx.c
> @@ -0,0 +1,607 @@
> +/*
> + * OMAP3 Power Management Routines
> + *
> + * Copyright (C) 2006-2008 Nokia Corporation
> + * Tony Lindgren
> + * Jouni Hogander
> + *
> + * Copyright (C) 2005 Texas Instruments, Inc.
> + * Richard Woodruff
> + *
> + * Based on pm.c for omap1
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include
Should be linux/gpio.h
> +static void omap3_pm_idle(void)
> +{
> + local_irq_disable();
> + local_fiq_disable();
> +
> + if (!omap3_can_sleep())
> + goto out;
> +
> + if (omap_irq_pending())
> + goto out;
So what happens if an IRQ becomes pending at this precise point?
> +
> + omap_sram_idle();
> +
> +out:
> + local_fiq_enable();
> + local_irq_enable();
> +}
> + /* IRQ mode */
> + bicr0, r7, #0x1F
> + orrr0, r0, #0x12
> + msrcpsr, r0 /*go into IRQ mode*/
> + ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM*/
> + movsp, r4 /*update the SP */
> + movlr, r5 /*update the LR */
> + msrspsr, r6 /*update the SPSR */
> +
> + /* ABORT mode */
> + bicr0, r7, #0x1F
> + orrr0, r0, #0x17
> + msrcpsr, r0 /* go into ABORT mode */
> + ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM */
> + movsp, r4 /*update the SP */
> + movlr, r5 /*update the LR */
> + msrspsr, r6 /*update the SPSR */
> +
> + /* UNDEEF mode */
> + bicr0, r7, #0x1F
> + orrr0, r0, #0x1B
> + msrcpsr, r0 /*go into UNDEF mode */
> + ldmia r3!,{r4-r6} /*load the SP and LR from SDRAM */
> + movsp, r4 /*update the SP*/
> + movlr, r5 /*update the LR*/
> + msrspsr, r6 /*update the SPSR*/
> +
> + /* SYSTEM (USER) mode */
> + bicr0, r7, #0x1F
> + orrr0, r0, #0x1F
> + msrcpsr, r0 /*go into USR mode */
> + ldmia r3!,{r4-r6} /*load the SP and LR from SDR
Re: [RFC/PATCH 3/3] omap3-iommu: remote registration
On Mon, May 18, 2009 at 4:02 PM, Russell King - ARM Linux wrote: > On Mon, May 18, 2009 at 03:46:07PM +0300, Felipe Contreras wrote: >> On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux >> wrote: >> > The real problem here seems to be the TI DSP bridge code, and if that's >> > the case why can't we just avoid registering IVA2 if the TI DSP bridge >> > code is enabled. That solves your stated problem without creating >> > additional management issues. >> >> The bridgedriver is expected to move and use iommu eventually, but not >> right now, so I guess the iva2 device should be registered only if >> MPU_BRIDGE_IOMMU is defined. >> >> But then what's the point of having the isp iommu device if the camera >> driver is disabled? Wouldn't that be wasting resources? Then if CAMERA >> is not defined the isp device should not be registered either. > > So have something like: > > config OMAP_IOMMU > tristate > > and then have both MPU_BRIDGE_IOMMU and the camera support (and whatever > else) select it. That way, you only end up with the IOMMU support code > built into the kernel if you have users of it. > > These low-level internal services drivers really don't need to be > publically visible in the configuration system. Yeap, that needs to be done too. > As for the run-time size, that's truely minimal. I thought creating iommu devices involved some kind of overhead, allocating some resources probably. That's why the iva2 iommu device conflicts with tidspbridge custom mmu. >> And finally if none of the two are enabled then you don't really >> iommu. By having omap_iommu_add all the dependencies would be handled >> automatically, right? 'modprobe bridgedriver' would load iommu. > > Think about it - the dependencies _already_ have to be there to use > the iommu services. Ok, yes, for iommu, but not for omap3-iommu which is a separate module. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe 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 08/11] OMAP3: PM: Ensure MUSB block can idle when driver not loaded
On Fri, May 15, 2009 at 11:40:48AM -0700, Kevin Hilman wrote: > Otherwise, bootloaders may leave MUSB in a state which prevents > retention. Hmm, so what happens if a boot loader has touched this MUSB thing, but the kernel which is being run doesn't have CONFIG_USB_MUSB_SOC enabled? -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] omap iommu: simple virtual address space management
On Mon, May 18, 2009 at 09:31:26AM +0300, Hiroshi DOYU wrote: > Right. In this change for better performance, I have to expose "struct > mem_type" and "get_mem_type()" a bit more as below. Is this change > acceptable, or do you have a better idea? You don't need to expose struct mem_type at all. You only need to tell the compiler that it exists and is valid by: struct mem_type; Then you can use it in function prototypes without complaint. I'd also prefer to hide ioremap_page() and get_mem_type() outside of the normal Linux headers - maybe in asm/mach/map.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 1/3] Regulator: Add pmic.c file to regulator framework
On Mon, May 18, 2009 at 05:50:31PM +0530, Aggarwal, Anuj wrote: > > The kernel already provides facilities for detecting the presence of > > devices. In cases where it is possible to do a generic check for a > [Aggarwal, Anuj] In my opinion, it would not be a good idea to probe > for several PMICs, on all the buses present in the system. It can be > simplified by probing only the ones which are relevant for this device. The point here is that the kernel already provides for doing device enumeration of all kinds, both static and dynamic, and that adding this file doesn't add anything except copying of the code from arch/arm into drivers/regulator. > > Another thing here is that the code appears to assume that there will be > > only one regulator device in the system which isn't always true. Some > > designs will use a series of discrete regulators rather than integrated > > chips while others will use several integrated PMICs for reasons such as > > ease of layout or power distribution. > [Aggarwal, Anuj] Can you explain this, I didn't get that much? Instead of having a single PMIC with multiple regulator outputs a system may choose to have several regulators. One way this can happen is that some manufacturers produce simple discrete regulator chips which produce only a single output - typically several of these would be needed in a system. Another approach which cause this to come up some systems use is to have more than one PMIC, for example having one PMIC for the main application processor and a second PMIC providing supplies used by a coprocessor. This can avoid electrical issues by allowing shorter tracks for the regulated supplies and simplifying routing. > [Aggarwal, Anuj] You are right, the primary purpose of this patch is to > avoid duplication of PMIC code, common to many OMAP platforms and I believe > this is a simpler and cleaner approach. > Instead of keeping this file in the drivers/regulator folder, we can move it > to arch/arm/mach-omap2 folder. This sounds like a good approach. -- To unsubscribe from this list: send the line "unsubscribe 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/3] omap3-iommu: reorganize
On Mon, May 18, 2009 at 03:59:42PM +0300, Felipe Contreras wrote: > So resource_size_t is ok for 'base'? Yes. -- To unsubscribe from this list: send the line "unsubscribe 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 3/3] omap3-iommu: remote registration
On Mon, May 18, 2009 at 03:46:07PM +0300, Felipe Contreras wrote: > On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux > wrote: > > The real problem here seems to be the TI DSP bridge code, and if that's > > the case why can't we just avoid registering IVA2 if the TI DSP bridge > > code is enabled. That solves your stated problem without creating > > additional management issues. > > The bridgedriver is expected to move and use iommu eventually, but not > right now, so I guess the iva2 device should be registered only if > MPU_BRIDGE_IOMMU is defined. > > But then what's the point of having the isp iommu device if the camera > driver is disabled? Wouldn't that be wasting resources? Then if CAMERA > is not defined the isp device should not be registered either. So have something like: config OMAP_IOMMU tristate and then have both MPU_BRIDGE_IOMMU and the camera support (and whatever else) select it. That way, you only end up with the IOMMU support code built into the kernel if you have users of it. These low-level internal services drivers really don't need to be publically visible in the configuration system. As for the run-time size, that's truely minimal. > And finally if none of the two are enabled then you don't really > iommu. By having omap_iommu_add all the dependencies would be handled > automatically, right? 'modprobe bridgedriver' would load iommu. Think about it - the dependencies _already_ have to be there to use the iommu services. -- To unsubscribe from this list: send the line "unsubscribe 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/3] omap3-iommu: reorganize
On Mon, May 18, 2009 at 3:07 PM, Russell King - ARM Linux
wrote:
> On Sat, May 16, 2009 at 01:05:48PM +0300, Felipe Contreras wrote:
>> +struct iommu_device {
>> + resource_size_t base;
>> + resource_size_t irq;
>> + struct iommu_platform_data pdata;
>> + struct resource res[2];
>> };
>
> The data which is needed per device is:
>
> - base address
> - IRQ (no need for this to be resource_size_t - int will do)
> - platform data
>
> There's no need for that res[2] being there.
Right, I was using 'res' but not any more; I forgot to remove it.
So resource_size_t is ok for 'base'?
>> @@ -63,23 +51,35 @@ static int __init omap3_iommu_init(void)
>>
>> for (i = 0; i < NR_IOMMU_DEVICES; i++) {
>> struct platform_device *pdev;
>> + const struct iommu_device *d = &devices[i];
>> + struct resource res[] = {
>> + { .flags = IORESOURCE_MEM },
>> + { .flags = IORESOURCE_IRQ },
>> + };
>
> This initialization doesn't buy you anything, in fact quite the opposite.
> The compiler actually interprets this as:
>
> static struct resource __initial_res[] = {
> { .flags = IORESOURCE_MEM },
> { .flags = IORESOURCE_IRQ },
> };
> ...
> for () {
> struct resource res[...];
> memcpy(res, __initial_res, sizeof(__initial_res));
>
>> +
>> + res[0].start = d->base;
>> + res[0].end = d->base + MMU_REG_SIZE - 1;
>> +
>> + res[1].start = d->irq;
>
> It would be far better to initialize the flags element here for both.
> And please also set res[1].end as I did in my patch.
I think I saw that res initialization somewhere and I found it much
easier to read.
Ok. Will do.
>> +
>> + err = platform_device_add_resources(pdev, res,
>> ARRAY_SIZE(res));
>> if (err)
>> goto err_out;
>> - err = platform_device_add_data(pdev, &omap3_iommu_pdata[i],
>> - sizeof(omap3_iommu_pdata[0]));
>> +
>> + err = platform_device_add_data(pdev, &d->pdata,
>> sizeof(d->pdata));
>
> This will fail checkpatch.
I'll make sure it passes.
Cheers.
--
Felipe Contreras
--
To unsubscribe from this list: send the line "unsubscribe 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 3/3] omap3-iommu: remote registration
On Mon, May 18, 2009 at 3:11 PM, Russell King - ARM Linux wrote: > On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote: >> This allows devices to be registered only when they are used. The >> current dsp-bridge driver for example is not using iommu so registering >> the iommu iva2 device would conflict. By allowing remote registration >> the dsp-bridge can decide when the iommu iva2 device is registered. > > I don't think that this is a good idea - what happens if two people > call omap_iommu_add() for the same IOMMU device independently? Hmm, right, some extra checks would be needed to see if the device is already registered and then increase some refcount. That's more complicated that I was hoping for. > The real problem here seems to be the TI DSP bridge code, and if that's > the case why can't we just avoid registering IVA2 if the TI DSP bridge > code is enabled. That solves your stated problem without creating > additional management issues. The bridgedriver is expected to move and use iommu eventually, but not right now, so I guess the iva2 device should be registered only if MPU_BRIDGE_IOMMU is defined. But then what's the point of having the isp iommu device if the camera driver is disabled? Wouldn't that be wasting resources? Then if CAMERA is not defined the isp device should not be registered either. And finally if none of the two are enabled then you don't really iommu. By having omap_iommu_add all the dependencies would be handled automatically, right? 'modprobe bridgedriver' would load iommu. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 3/3] Regulator: Added board-dependent code for TPS65023
> -Original Message-
> From: Mark Brown [mailto:broo...@sirena.org.uk]
> Sent: Saturday, May 09, 2009 1:45 AM
> To: Aggarwal, Anuj
> Cc: linux-omap@vger.kernel.org; l...@slimlogic.co.uk
> Subject: Re: [PATCH 3/3] Regulator: Added board-dependent code for
> TPS65023
>
> On Fri, May 08, 2009 at 08:42:16PM +0530, Anuj Aggarwal wrote:
> > Added OMAP3 EVM specific code for TPS65023 in pmic.c file.
> >
> > Signed-off-by: Anuj Aggarwal
>
> CCing in Liam again.
>
> > ---
> > drivers/regulator/pmic.c | 92
> ++
> > 1 files changed, 92 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/regulator/pmic.c b/drivers/regulator/pmic.c
> > index 36ed341..6e7276a 100644
> > --- a/drivers/regulator/pmic.c
> > +++ b/drivers/regulator/pmic.c
> > @@ -29,6 +29,96 @@
> > /*
> > * Definitions specific to TPS65023
> > */
> > +#if defined(CONFIG_OMAP3EVM_TPS65023)
> > +/* MPU voltage regulator of DCDC type */
> > +struct regulator_consumer_supply tps65023_mpu_consumers = {
> > + .supply = "vdd1",
> > +};
>
> This comes back to my questions about pmic.c but I'd expect this all to
> appear in the OMAP3 EVM code.
[Aggarwal, Anuj] Same reason given in my other email. Just to avoid duplication
of the code, I have created this file and moved all the code from board-*.c to
this place.
The same file will be populated for other PMICs, coming on OMAP based platforms
in future.
>
> > +
> > +/* CORE voltage regulator of DCDC type */
> > +struct regulator_consumer_supply tps65023_core_consumers = {
> > + .supply = "vdd2",
> > +};
> > +
> > +/* SRAM/MEM/WKUP_BG voltage regulator of DCDC type */
> > +struct regulator_consumer_supply tps65023_vdds_consumers = {
> > + .supply = "vdds",
> > +};
> > +
> > +/* DPLL voltage regulator of LDO type */
> > +struct regulator_consumer_supply tps65023_dpll_consumers = {
> > + .supply = "dpll",
> > +};
> > +
> > +/* MMC voltage regulator of LDO type */
> > +struct regulator_consumer_supply tps65023_mmc_consumers = {
> > + .supply = "mmc",
> > +};
> > +
> > +struct regulator_init_data tps65023_regulator_data[] = {
> > + {
> > + .constraints = {
> > + .min_uV = 80,
> > + .max_uV = 160,
> > + .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
> > + REGULATOR_CHANGE_STATUS),
> > + .boot_on = 1,
> > + },
> > + .num_consumer_supplies = 1,
> > + .consumer_supplies = &tps65023_mpu_consumers,
> > + },
> > + {
> > + .constraints = {
> > + .min_uV = 180,
> > + .max_uV = 330,
> > + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> > + .boot_on = 1,
> > + },
> > + .num_consumer_supplies = 1,
> > + .consumer_supplies = &tps65023_core_consumers,
> > + },
> > + {
> > + .constraints = {
> > + .min_uV = 180,
> > + .max_uV = 330,
> > + .valid_ops_mask = REGULATOR_CHANGE_STATUS,
> > + .boot_on = 1,
> > + },
> > + .num_consumer_supplies = 1,
> > + .consumer_supplies = &tps65023_vdds_consumers,
> > + },
> > + {
> > + .constraints = {
> > + .min_uV = 100,
> > + .max_uV = 315,
> > + .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
> > + REGULATOR_CHANGE_STATUS),
> > + .boot_on = 1,
> > + },
> > + .num_consumer_supplies = 1,
> > + .consumer_supplies = &tps65023_dpll_consumers,
> > + },
> > + {
> > + .constraints = {
> > + .min_uV = 105,
> > + .max_uV = 330,
> > + .valid_ops_mask = (REGULATOR_CHANGE_VOLTAGE |
> > + REGULATOR_CHANGE_STATUS),
> > + .boot_on = 1,
> > + },
> > + .num_consumer_supplies = 1,
> > + .consumer_supplies = &tps65023_mmc_consumers,
> > + },
> > +};
> > +
> > +static struct i2c_board_info __initdata board_tps65023_instances[] = {
> > + {
> > + I2C_BOARD_INFO("tps65023", 0x48),
> > + .flags = I2C_CLIENT_WAKE,
> > + .platform_data = &tps65023_regulator_data[0],
> > + },
> > +};
> > +#endif
> >
> > static int flag_pmic_twl4030;
> > static int flag_pmic_tps6235x;
> > @@ -96,6 +186,8 @@ int pmic_init(void)
> >
> > #if defined(CONFIG_OMAP3EVM_TPS65023)
> > /* do stuff specific to TPS65023 */
> > + omap_register_i2c_bus(1, 400, board_tps65023_instances,
> > + ARRAY_SIZE(board_tps65023_instances));
> > #endif
> >
> > return 0;
> > --
> > 1.6.2.4
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> > the body of a message to majord...@vger.kerne
RE: [PATCH 1/3] Regulator: Add pmic.c file to regulator framework
> -Original Message- > From: Mark Brown [mailto:broo...@opensource.wolfsonmicro.com] > Sent: Saturday, May 09, 2009 12:37 AM > To: Aggarwal, Anuj > Cc: linux-omap@vger.kernel.org > Subject: Re: [PATCH 1/3] Regulator: Add pmic.c file to regulator framework > > On Fri, May 08, 2009 at 08:42:06PM +0530, Anuj Aggarwal wrote: > > > Added drivers\regulator\pmic.c file to the regulator framework which will > > I suspect you mean / there :) [Aggarwal, Anuj] Yeah:) > > > have the board specific information for different regulators and will do the > > regulator initialization depending on one which is available. > > > Signed-off-by: Anuj Aggarwal > > I'm really not sure what the abstraction that you're attempting to > introduce here is intended to do that can't handled by the existing > kernel features - could you go into more detail about the problem that > this patch is intended to solve, please? > > The kernel already provides facilities for detecting the presence of > devices. In cases where it is possible to do a generic check for a > device (for example, by reading back ID registers on the device and > checking the values) then the device driver can do so in its probe > routine and the board can unconditionally declare that the device is > there, allowing the probe to fail. In cases where something board > specific needs to be done (such as checking for fit resistors or > information provided by the bootloader) then that'd need to be handled > in the board code anyway - it's not going to apply on generic systems. > There will also be cases where it's just not possible to determine > what's fitted at runtime, especially for simple devices with GPIO only > control. [Aggarwal, Anuj] In my opinion, it would not be a good idea to probe for several PMICs, on all the buses present in the system. It can be simplified by probing only the ones which are relevant for this device. > > If there is initialisation which can always be done for a chip no matter > what board it's on then I'd expect the driver to just handle that when > it is starting up without needing separate code - if there's something > preventing that then we should definitely fix that, probably in a way > that's not specific to the regulator framework since I'd expect other > subsystems to be running into similar issues. > > Another thing here is that the code appears to assume that there will be > only one regulator device in the system which isn't always true. Some > designs will use a series of discrete regulators rather than integrated > chips while others will use several integrated PMICs for reasons such as > ease of layout or power distribution. [Aggarwal, Anuj] Can you explain this, I didn't get that much? > > Based on experience with the OMAP audio drivers I suspect the problem > the patch is trying to solve may be that there are a lot of designs out > there which are based on the reference platforms which TI have produced > and are therefore have very repetitive board code. Perhaps this might > be best handled by having some utility routines in the OMAP code which > the machine drivers can use to say that they have the same PMIC setup as > a given reference design? [Aggarwal, Anuj] You are right, the primary purpose of this patch is to avoid duplication of PMIC code, common to many OMAP platforms and I believe this is a simpler and cleaner approach. Instead of keeping this file in the drivers/regulator folder, we can move it to arch/arm/mach-omap2 folder. > > CCing in Liam so I've not deleted any of the text. > > > --- > > drivers/regulator/Makefile |2 +- > > drivers/regulator/pmic.c | 103 > > > include/linux/regulator/pmic.h | 29 +++ > > 3 files changed, 133 insertions(+), 1 deletions(-) > > create mode 100644 drivers/regulator/pmic.c > > create mode 100644 include/linux/regulator/pmic.h > > > > diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile > > index bac133a..c0d87bf 100644 > > --- a/drivers/regulator/Makefile > > +++ b/drivers/regulator/Makefile > > @@ -3,7 +3,7 @@ > > # > > > > > > -obj-$(CONFIG_REGULATOR) += core.o > > +obj-$(CONFIG_REGULATOR) += core.o pmic.o > > obj-$(CONFIG_REGULATOR_FIXED_VOLTAGE) += fixed.o > > obj-$(CONFIG_REGULATOR_VIRTUAL_CONSUMER) += virtual.o > > > > diff --git a/drivers/regulator/pmic.c b/drivers/regulator/pmic.c > > new file mode 100644 > > index 000..36ed341 > > --- /dev/null > > +++ b/drivers/regulator/pmic.c > > @@ -0,0 +1,103 @@ > > +/* > > + * pmic.c > > + * > > + * Supports run-time detection of different Power Management ICs. > > + * > > + * Copyright (C) 2009 Texas Instrument Incorporated - http://www.ti.com/ > > + * > > + * 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 version 2. > > + * > > + * This program is distributed "as is" WITHOU
Re: [RESUBMIT][PATCH 4/7] OMAP4: Update common omap platform common sources.
On Mon, May 18, 2009 at 05:37:24PM +0530, Shilimkar, Santosh wrote: > > As for the pointer to the array of names, why can't this be declared > > const and therefore that cast be removed? > I am sorry but didn't get this point. > dm_source_names = (char **)omap4_dm_source_names; > In this 'omap4_dm_source_names' is already const. The problem is > dm_source_names is declared as 'char ** ' and hence compiler cribs for right > reasons without cast. > > Did you mean don't declare 'omap4_dm_source_name' as const ? No, I'm saying dm_source_names should also be const. -- To unsubscribe from this list: send the line "unsubscribe 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 3/3] omap3-iommu: remote registration
On Sat, May 16, 2009 at 01:05:50PM +0300, Felipe Contreras wrote: > This allows devices to be registered only when they are used. The > current dsp-bridge driver for example is not using iommu so registering > the iommu iva2 device would conflict. By allowing remote registration > the dsp-bridge can decide when the iommu iva2 device is registered. I don't think that this is a good idea - what happens if two people call omap_iommu_add() for the same IOMMU device independently? The real problem here seems to be the TI DSP bridge code, and if that's the case why can't we just avoid registering IVA2 if the TI DSP bridge code is enabled. That solves your stated problem without creating additional management issues. -- To unsubscribe from this list: send the line "unsubscribe 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: [RESUBMIT][PATCH 4/7] OMAP4: Update common omap platform common sources.
Russell,
> > +static const char *omap4_dm_source_names[] __initdata = {
> > + "sys_ck",
> > + "omap_32k_fck",
> > + NULL
> > +};
> > +static struct clk **omap4_dm_source_clocks[2];
>
> Umm. struct clk **[2].
>
> > +static const int dm_timer_count = ARRAY_SIZE(omap4_dm_timers);
> > +
> > #else
> >
> > #error OMAP architecture not supported!
> > @@ -461,7 +508,8 @@ __u32
> omap_dm_timer_modify_idlect_mask(__u32 inputmask)
> > }
> > EXPORT_SYMBOL_GPL(omap_dm_timer_modify_idlect_mask);
> >
> > -#elif defined(CONFIG_ARCH_OMAP2) || defined (CONFIG_ARCH_OMAP3)
> > +#elif defined(CONFIG_ARCH_OMAP2) || defined(CONFIG_ARCH_OMAP3) || \
> > + defined(CONFIG_ARCH_OMAP4)
> >
> > struct clk *omap_dm_timer_get_fclk(struct omap_dm_timer *timer)
> > {
> > @@ -705,6 +753,10 @@ int __init omap_dm_timer_init(void)
> > dm_timers = omap3_dm_timers;
> > dm_source_names = (char **)omap3_dm_source_names;
> > dm_source_clocks = (struct clk
> **)omap3_dm_source_clocks;
> > + } else if (cpu_is_omap44xx()) {
> > + dm_timers = omap4_dm_timers;
> > + dm_source_names = (char **)omap4_dm_source_names;
> > + dm_source_clocks = (struct clk
> **)omap4_dm_source_clocks;
>
> which then gets casted to a struct clk **. These are two different
> objects. I don't think someone quite understood what they were
> doing here and threw a cast in to shut up the compiler warning:
>
> warning: assignment from incompatible pointer type
>
> This is *very* wrong and is a prime example of why casts are _bad_
> news. This cast is saying "THERE IS A BUG HERE" in 100ft
> high letters.
>
> What you want is:
>
> static struct clk *omap4_dm_source_clocks[2];
> ...
>
> dm_source_clocks = omap4_dm_source_clocks;
>
> This is because struct clk *[] is equivalent to struct clk **.
> (remember that arrays are handled in C as a pointer to the first
> array element.)
OK. I will fix this for OMAP4 now. Will create patch for OMAP2/3 bit later.
> As for the pointer to the array of names, why can't this be declared
> const and therefore that cast be removed?
I am sorry but didn't get this point.
dm_source_names = (char **)omap4_dm_source_names;
In this 'omap4_dm_source_names' is already const. The problem is
dm_source_names is declared as 'char ** ' and hence compiler cribs for right
reasons without cast.
Did you mean don't declare 'omap4_dm_source_name' as const ?
> TTOTD: Casts are bad news. It's far better to have stuff correctly
> typed in the first place.
Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/3] omap3-iommu: reorganize
On Sat, May 16, 2009 at 01:05:48PM +0300, Felipe Contreras wrote:
> +struct iommu_device {
> + resource_size_t base;
> + resource_size_t irq;
> + struct iommu_platform_data pdata;
> + struct resource res[2];
> };
The data which is needed per device is:
- base address
- IRQ (no need for this to be resource_size_t - int will do)
- platform data
There's no need for that res[2] being there.
> @@ -63,23 +51,35 @@ static int __init omap3_iommu_init(void)
>
> for (i = 0; i < NR_IOMMU_DEVICES; i++) {
> struct platform_device *pdev;
> + const struct iommu_device *d = &devices[i];
> + struct resource res[] = {
> + { .flags = IORESOURCE_MEM },
> + { .flags = IORESOURCE_IRQ },
> + };
This initialization doesn't buy you anything, in fact quite the opposite.
The compiler actually interprets this as:
static struct resource __initial_res[] = {
{ .flags = IORESOURCE_MEM },
{ .flags = IORESOURCE_IRQ },
};
...
for () {
struct resource res[...];
memcpy(res, __initial_res, sizeof(__initial_res));
> +
> + res[0].start = d->base;
> + res[0].end = d->base + MMU_REG_SIZE - 1;
> +
> + res[1].start = d->irq;
It would be far better to initialize the flags element here for both.
And please also set res[1].end as I did in my patch.
> +
> + err = platform_device_add_resources(pdev, res, ARRAY_SIZE(res));
> if (err)
> goto err_out;
> - err = platform_device_add_data(pdev, &omap3_iommu_pdata[i],
> -sizeof(omap3_iommu_pdata[0]));
> +
> + err = platform_device_add_data(pdev, &d->pdata,
> sizeof(d->pdata));
This will fail checkpatch.
--
To unsubscribe from this list: send the line "unsubscribe 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 0/3] omap3-iommu: cleanups and remote registration
On Mon, May 18, 2009 at 8:33 AM, Hiroshi DOYU wrote: > From: Hiroshi DOYU > Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration > Date: Mon, 18 May 2009 08:16:27 +0300 (EEST) > >> From: ext Felipe Contreras >> Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration >> Date: Sat, 16 May 2009 20:32:10 +0200 >> >> > On Sat, May 16, 2009 at 7:36 PM, Russell King - ARM Linux >> > wrote: >> > > On Sat, May 16, 2009 at 01:05:47PM +0300, Felipe Contreras wrote: >> > >> This patch series cleanups up a bit the opap3-iommu device registration >> > >> and >> > >> then allows registration from other parts of the code. >> > >> >> > >> Currently the iva2 code (tidspbridge) is not using iommu, therefore it >> > >> can't be >> > >> used as-is with the current omap iommu. By allowing devies to be >> > >> registered >> > >> externaly (either isp, or iva2) this problem goes away. >> > > >> > > Hmm, so does this mean that the iommu patchset is going to grow by three >> > > patches? Hope not. >> >> This series has been posted for a long time and I want to get this in >> this time with minor fixes. >> >> > I hope Hiroshi integrates my patches. >> >> I think that the problem of yours is that it's not necesary to allow >> device registration around kernel anywhere by "omap_iommu_add()" at >> all, but enough only in "omap3-iommu.c". Since eventually >> "tidspbridge" will use this iommu framework, no need for this >> flexibility. Keeping same kind of device registration in one place is >> good thing from SoC perspective. So I want to avoid adding unnecessary >> flexibility to the code. I'll follow Russell's call, anyway. > > The other thing is about introducing a new structure type, "struct > iommu_device". I don't want to define new structure type just for this > device registration. Since device registration part is kind of > conventional one in kernel, I want to keep things simple/conventional > as much as possible. It is an *internal* structure, just like you local 'omap3_iommu_pdata' nobody has not know about it outside omap3-iommu.c. The exported function is: struct platform_device *omap_iommu_add(const char *name); Nothing custom there. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe 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 0/3] omap3-iommu: cleanups and remote registration
On Mon, May 18, 2009 at 8:16 AM, Hiroshi DOYU wrote: > From: ext Felipe Contreras > Subject: Re: [RFC/PATCH 0/3] omap3-iommu: cleanups and remote registration > Date: Sat, 16 May 2009 20:32:10 +0200 > >> On Sat, May 16, 2009 at 7:36 PM, Russell King - ARM Linux >> wrote: >> > On Sat, May 16, 2009 at 01:05:47PM +0300, Felipe Contreras wrote: >> >> This patch series cleanups up a bit the opap3-iommu device registration >> >> and >> >> then allows registration from other parts of the code. >> >> >> >> Currently the iva2 code (tidspbridge) is not using iommu, therefore it >> >> can't be >> >> used as-is with the current omap iommu. By allowing devies to be >> >> registered >> >> externaly (either isp, or iva2) this problem goes away. >> > >> > Hmm, so does this mean that the iommu patchset is going to grow by three >> > patches? Hope not. > > This series has been posted for a long time and I want to get this in > this time with minor fixes. > >> I hope Hiroshi integrates my patches. > > I think that the problem of yours is that it's not necesary to allow > device registration around kernel anywhere by "omap_iommu_add()" at > all, but enough only in "omap3-iommu.c". Since eventually > "tidspbridge" will use this iommu framework, no need for this > flexibility. Keeping same kind of device registration in one place is > good thing from SoC perspective. So I want to avoid adding unnecessary > flexibility to the code. I'll follow Russell's call, anyway. The first patch has nothing to do with omap_iommu_add, it's just cleanups, and you haven't provided any valid reason to reject them. The rest of the patches are *necessary* as of right now. IMHO iommu should not be merged in it's current state because it will break tidspbridge. Maybe after tidspbridge has been fully converted to use iommu. I think there will probably be a conversion period where the tidspbridge will use iommu optionally, in that period iommu would need to be patched and add a #ifdef MPU_BRIDGE_IOMMU, that would be ugly. Also you haven't answered my questions: what happens if you disable MPU_BRIDGE? What's the point of iommu to register the iva2 iommu device? My patches solves all of those issues. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] omap iommu: omap3 iommu device registration
From: ext Russell King - ARM Linux
Subject: Re: [PATCH 3/6] omap iommu: omap3 iommu device registration
Date: Sat, 16 May 2009 11:55:14 +0200
> On Sat, May 16, 2009 at 10:20:36AM +0100, Russell King - ARM Linux wrote:
> > This looks all very convoluted. Why not do something like:
> >
> > static unsigned long iommu_base[] = {
> > OMAP3_MMU1_BASE,
> > OMAP3_MMU2_BASE,
> > };
> >
> > static int iommu_irq[] = {
> > OMAP3_MMU1_IRQ,
> > OMAP3_MMU2_IRQ,
> > };
>
> BTW, both of these can be __initdata.
Attached the updated one.
>From 2bfdb4130433708dc04e1c30aa5099d48de408e0 Mon Sep 17 00:00:00 2001
From: Hiroshi DOYU
Date: Wed, 28 Jan 2009 21:32:04 +0200
Subject: [PATCH 3/6] omap iommu: omap3 iommu device registration
Signed-off-by: Hiroshi DOYU
---
arch/arm/mach-omap2/omap3-iommu.c | 103 +
1 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-omap2/omap3-iommu.c
diff --git a/arch/arm/mach-omap2/omap3-iommu.c
b/arch/arm/mach-omap2/omap3-iommu.c
new file mode 100644
index 000..91ee38a
--- /dev/null
+++ b/arch/arm/mach-omap2/omap3-iommu.c
@@ -0,0 +1,103 @@
+/*
+ * omap iommu: omap3 device registration
+ *
+ * Copyright (C) 2008-2009 Nokia Corporation
+ *
+ * Written by Hiroshi DOYU
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+
+#include
+
+#define OMAP3_MMU1_BASE0x480bd400
+#define OMAP3_MMU2_BASE0x5d00
+#define OMAP3_MMU1_IRQ 24
+#define OMAP3_MMU2_IRQ 28
+
+
+static unsigned long iommu_base[] __initdata = {
+ OMAP3_MMU1_BASE,
+ OMAP3_MMU2_BASE,
+};
+
+static int iommu_irq[] __initdata = {
+ OMAP3_MMU1_IRQ,
+ OMAP3_MMU2_IRQ,
+};
+
+static const struct iommu_platform_data omap3_iommu_pdata[] __initconst = {
+ {
+ .name = "isp",
+ .nr_tlb_entries = 8,
+ .clk_name = "cam_ick",
+ },
+ {
+ .name = "iva2",
+ .nr_tlb_entries = 32,
+ .clk_name = "iva2_ck",
+ },
+};
+#define NR_IOMMU_DEVICES ARRAY_SIZE(omap3_iommu_pdata)
+
+static struct platform_device *omap3_iommu_pdev[NR_IOMMU_DEVICES];
+
+static int __init omap3_iommu_init(void)
+{
+ int i, err;
+
+ for (i = 0; i < NR_IOMMU_DEVICES; i++) {
+ struct platform_device *pdev;
+ struct resource res[2];
+
+ pdev = platform_device_alloc("omap-iommu", i);
+ if (!pdev) {
+ err = -ENOMEM;
+ goto err_out;
+ }
+
+ memset(res, 0, sizeof(res));
+ res[0].start = iommu_base[i];
+ res[0].end = iommu_base[i] + MMU_REG_SIZE - 1;
+ res[0].flags = IORESOURCE_MEM;
+ res[1].start = res[1].end = iommu_irq[i];
+ res[1].flags = IORESOURCE_IRQ;
+
+ err = platform_device_add_resources(pdev, res,
+ ARRAY_SIZE(res));
+ if (err)
+ goto err_out;
+ err = platform_device_add_data(pdev, &omap3_iommu_pdata[i],
+ sizeof(omap3_iommu_pdata[0]));
+ if (err)
+ goto err_out;
+ err = platform_device_add(pdev);
+ if (err)
+ goto err_out;
+ omap3_iommu_pdev[i] = pdev;
+ }
+ return 0;
+
+err_out:
+ while (i--)
+ platform_device_put(omap3_iommu_pdev[i]);
+ return err;
+}
+module_init(omap3_iommu_init);
+
+static void __exit omap3_iommu_exit(void)
+{
+ int i;
+
+ for (i = 0; i < NR_IOMMU_DEVICES; i++)
+ platform_device_unregister(omap3_iommu_pdev[i]);
+}
+module_exit(omap3_iommu_exit);
+
+MODULE_AUTHOR("Hiroshi DOYU");
+MODULE_DESCRIPTION("omap iommu: omap3 device registration");
+MODULE_LICENSE("GPL v2");
--
1.6.0.4
Re: [PATCH][RFC] McSPI Slave and DMA,FIFO support
- Original Message -
From: "Gadiyar, Anand"
To: "V, Hemanth" ; "Kevin Hilman"
>> Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
>> ===
>> --- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2009-05-14
>> 12:38:50.0 +0530
>> +++ linux-omap-2.6/arch/arm/mach-omap2/devices.c 2009-05-15
>> 16:53:38.0 +0530
>> };
>>
>> static struct resource omap2_mcspi2_resources[] = {
>> @@ -351,6 +359,14 @@
>>
>> static void omap_init_mcspi(void)
>> {
>> +
>> + if (cpu_is_omap3430()) {
>> + omap_cfg_reg(AA3_3430_McSPI2_CLK);
>> + omap_cfg_reg(Y2_3430_McSPI2_SIMO);
>> + omap_cfg_reg(Y3_3430_McSPI2_SOMI);
>> + omap_cfg_reg(Y4_3430_McSPI2_CS0);
>> + }
>> +
This will change the mux mode for these pads for all OMAP3 boards,
even if they do not wish to use McSPI2. In particular, Beagleboard
will be affected as it uses HSUSB on Port2 and these pads overlap.
I could add an option like below to plat-omap/Kconfig under
OMAP Feature Selections. Kevin, Your thoughts on this
config OMAP3430_ENABLE_SPI2_PIN_MUX
bool "Enable SPI2 pin mux configuration for OMAP3430"
depends on ARCH_OMAP3430
default n
help
Enable pin mux for SPI2 on OMAP3430 platform. Note
that the same pins are used for EHCI port2 operation. Hence
enabling this option effectively disables EHCI port 2 usage.
--
To unsubscribe from this list: send the line "unsubscribe 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][RFC] McSPI Slave and DMA,FIFO support
> >> Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
> >> ===
> >> --- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2009-05-14
> >> 12:38:50.0 +0530
> >> +++ linux-omap-2.6/arch/arm/mach-omap2/devices.c 2009-05-15
> >> 16:53:38.0 +0530
> >> };
> >>
> >> static struct resource omap2_mcspi2_resources[] = {
> >> @@ -351,6 +359,14 @@
> >>
> >> static void omap_init_mcspi(void)
> >> {
> >> +
> >> + if (cpu_is_omap3430()) {
> >> + omap_cfg_reg(AA3_3430_McSPI2_CLK);
> >> + omap_cfg_reg(Y2_3430_McSPI2_SIMO);
> >> + omap_cfg_reg(Y3_3430_McSPI2_SOMI);
> >> + omap_cfg_reg(Y4_3430_McSPI2_CS0);
> >> + }
> >> +
This will change the mux mode for these pads for all OMAP3 boards,
even if they do not wish to use McSPI2. In particular, Beagleboard
will be affected as it uses HSUSB on Port2 and these pads overlap.
Regards,
Anand
--
To unsubscribe from this list: send the line "unsubscribe 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][RFC] McSPI Slave and DMA,FIFO support
- Original Message -
From: "Kevin Hilman"
Subject: Re: [PATCH][RFC] McSPI Slave and DMA,FIFO support
"Hemanth V" writes:
This patch adds support for McSPI slave and FIFO. DMA and FIFO
could be enabled together for better throughput. Platform config
parameters have been added to enable these features on any particular
McSPI controller.
FIFO can be enabled by defining fifo_depth parameter. fifo_depth needs
to be a multiple of buffer size that is used for read/write.
These features are useful when you have high throughput devices
like WLAN or Modem connected over SPI.
Signed-off-by: Hemanth V
---
arch/arm/mach-omap2/board-3430sdp.c | 19 +
arch/arm/mach-omap2/devices.c | 16 +
arch/arm/mach-omap2/mux.c | 11
arch/arm/plat-omap/include/mach/mcspi.h | 13 +
arch/arm/plat-omap/include/mach/mux.h |7
drivers/spi/omap2_mcspi.c | 353
6 files changed, 379 insertions(+), 40 deletions(-)
I think you should break this up into a series:
1) SPI driver changes (which could go upstream after review/approval)
2) mux changes
3) OMAP init changes (devices.c)
4) SDP changes, which are debug only
Where (2) and (3) could probably be combined.
Yes, will create a series of 3 patches.
Index: linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/board-3430sdp.c 2009-05-14
12:38:50.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/board-3430sdp.c 2009-05-14
19:48:35.0 +0530
@@ -228,6 +228,13 @@
.single_channel = 1, /* 0: slave, 1: master */
};
+#ifdef CONFIG_SPI_DEBUG
+static struct omap2_mcspi_device_config dummy_mcspi_config = {
+ .turbo_mode = 0,
+ .single_channel = 1, /* 0: slave, 1: master */
+};
+#endif
+
static struct spi_board_info sdp3430_spi_board_info[] __initdata = {
[0] = {
/*
@@ -242,6 +249,18 @@
.irq = 0,
.platform_data = &tsc2046_config,
},
+#ifdef CONFIG_SPI_DEBUG
+ [1] = {
+ /* SPI test driver attached to SPI2 controller by
+ * default
+ */
+ .modalias = "spitst",
+ .bus_num = 2,
+ .chip_select = 0,
+ .max_speed_hz = 150,
+ .controller_data = &dummy_mcspi_config,
+ },
+#endif
};
static struct platform_device sdp3430_lcd_device = {
Index: linux-omap-2.6/arch/arm/mach-omap2/devices.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/devices.c 2009-05-14
12:38:50.0 +0530
+++ linux-omap-2.6/arch/arm/mach-omap2/devices.c 2009-05-15
16:53:38.0
+0530
@@ -257,8 +257,12 @@
#define OMAP2_MCSPI3_BASE 0x480b8000
#define OMAP2_MCSPI4_BASE 0x480ba000
+#define OMAP2_MCSPI_MASTER 0
+#define OMAP2_MCSPI_SLAVE 1
+
If these are to be 'mode' flags for 'struct
omap2_mcspi_platform_config' then they should be part of mcspi.h, not
defined here.
Will move them to mcspi.h
static struct omap2_mcspi_platform_config omap2_mcspi1_config = {
.num_cs = 4,
+ .force_cs_mode = 1,
};
static struct resource omap2_mcspi1_resources[] = {
@@ -281,6 +285,10 @@
static struct omap2_mcspi_platform_config omap2_mcspi2_config = {
.num_cs = 2,
+ .mode = OMAP2_MCSPI_MASTER,
+ .dma_mode = 1,
+ .force_cs_mode = 0,
+ .fifo_depth = 0,
Setting these init values to zero is redundant.
This is to serve as an easy reference for someone trying to enable these
features.
};
static struct resource omap2_mcspi2_resources[] = {
@@ -351,6 +359,14 @@
static void omap_init_mcspi(void)
{
+
+ if (cpu_is_omap3430()) {
+ omap_cfg_reg(AA3_3430_McSPI2_CLK);
+ omap_cfg_reg(Y2_3430_McSPI2_SIMO);
+ omap_cfg_reg(Y3_3430_McSPI2_SOMI);
+ omap_cfg_reg(Y4_3430_McSPI2_CS0);
+ }
+
platform_device_register(&omap2_mcspi1);
platform_device_register(&omap2_mcspi2);
#if defined(CONFIG_ARCH_OMAP2430) || defined(CONFIG_ARCH_OMAP3)
Index: linux-omap-2.6/arch/arm/mach-omap2/mux.c
===
--- linux-omap-2.6.orig/arch/arm/mach-omap2/mux.c 2009-05-14
12:38:50.0
+0530
+++ linux-omap-2.6/arch/arm/mach-omap2/mux.c 2009-05-15
16:18:41.0 +0530
@@ -486,6 +486,17 @@
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_OUTPUT)
MUX_CFG_34XX("J25_34XX_GPIO170", 0x1c6,
OMAP34XX_MUX_MODE4 | OMAP34XX_PIN_INPUT)
+
+/* McSPI */
+MUX_CFG_34XX("AA3_3430_McSPI2_CLK", 0x1d6,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("Y2_3430_McSPI2_SIMO", 0x1d8,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("Y3_3430_McSPI2_SOMI", 0x1da,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT)
+MUX_CFG_34XX("Y4_3430_McSPI2_CS0", 0x1dc,
+ OMAP34XX_MUX_MODE0 | OMAP34XX_PIN_INPUT_PULLDOWN)
+
};
#define OMAP34XX_PINS_SZ ARRAY_SIZE(omap34xx_pins)
Index: linux-omap-2.6/arch/arm/plat-omap/include/mach/mcspi.h
===
--- linux-omap-2.6.orig/arch/arm/plat-omap/include/mach/mcspi.h
2009-05-14
12:38:54.0 +0530
+++ linux-omap-2
Has anyone tried android BT HSP/HFP on Zoom2 beta board?
Hi there, See title. I think one of the hardest work to do is figuring out how to route digital audio from GSM modem to Omap processor via McBsp3. Could anyone give me some points? Thanks, Wang, Husheng -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
