Re: Hang on boot
Hi, On Mon, 2010-10-11 at 14:09 +1100, John Garland wrote: > Hi, > > Both the dspbridge and master branch of linux-omap seem to hang when > trying to boot (i.e. no output) on a beagleboard C2. > This is with the new omap2plus_defconfig (as opposed to the old > omap3_defconfig). > > Is anybody else experiencing this or does anyone have any idea what > could be causing this? > Make sure you update your u-boot environment so that you have console=ttyO2,115200 in your kernel command line (btw, it's ttyO2, not tty02). It's been recently changed in the linux-omap tree (commit d6e284d). You'll probably also need to update your /etc/inittab. Cheers, Ionut. -- 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 6/7] [RFC] OMAP: hwmod: SYSCONFIG register modification for MCBSP
On Friday 08 October 2010 01:12 PM, Cousson, Benoit wrote:
Hi Kishon,
On 10/5/2010 6:37 PM, ABRAHAM, KISHON VIJAY wrote:
MCBSP 2 and 3 in OMAP3 has sidetone feature which requires
autoidle to be disabled before starting the sidetone. Also SYSCONFIG
register has to be set with smart idle or no idle depending on the
dma op mode (threshold or element sync). For doing these operations
dynamically at runtime, hwmod API'S are used to modify SYSCONFIG register
directly.
OK, it looks like we don't have the choice... But for the
implementation, please discussed with Manju on that, He is doing the
similar thing for the smartstandby issue on SDMA.
OK.
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Charulatha V
Signed-off-by: Shubhrajyoti D
Cc: Partha Basak
---
arch/arm/plat-omap/mcbsp.c | 69
++--
1 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/arch/arm/plat-omap/mcbsp.c b/arch/arm/plat-omap/mcbsp.c
index c7c6a83..6b705e1 100644
--- a/arch/arm/plat-omap/mcbsp.c
+++ b/arch/arm/plat-omap/mcbsp.c
@@ -228,10 +228,21 @@ void omap_mcbsp_config(unsigned int id, const struct
omap_mcbsp_reg_cfg *config)
EXPORT_SYMBOL(omap_mcbsp_config);
#ifdef CONFIG_ARCH_OMAP3
+static struct omap_hwmod **find_hwmods_by_dev(struct device *dev)
+{
+ struct platform_device *pdev;
+ struct omap_device *od;
+ pdev = container_of(dev, struct platform_device, dev);
+ od = container_of(pdev, struct omap_device, pdev);
+ return od->hwmods;
Rule #1, don't touch oh in your code. The device should be the only
interface.
If such API is needed, it should be in omap_device. But in your case, I
don't thing it is needed.
OK
+}
+
static void omap_st_on(struct omap_mcbsp *mcbsp)
{
unsigned int w;
+ struct omap_hwmod **oh;
+ oh = find_hwmods_by_dev(mcbsp->dev);
/*
* Sidetone uses McBSP ICLK - which must not idle when sidetones
* are enabled or sidetones start sounding ugly.
@@ -244,8 +255,7 @@ static void omap_st_on(struct omap_mcbsp *mcbsp)
w = MCBSP_READ(mcbsp, SSELCR);
MCBSP_WRITE(mcbsp, SSELCR, w | SIDETONEEN);
- w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w& ~(ST_AUTOIDLE));
+ omap_hwmod_set_module_autoidle(oh[1], 0);
Don't use internal hwmod API. You have to create a similar omap_device API.
You don't have to select only one hwmod in this case, just change the
sysconfig setting for all hwmod that belong to the omap_device, and it
will be fine. It will avoid you to access one hwmod in particular.
This is the implementation that Manju is doing.
OK
/* Enable Sidetone from Sidetone Core */
w = MCBSP_ST_READ(mcbsp, SSELCR);
@@ -255,12 +265,14 @@ static void omap_st_on(struct omap_mcbsp *mcbsp)
static void omap_st_off(struct omap_mcbsp *mcbsp)
{
unsigned int w;
+ struct omap_hwmod **oh;
+
+ oh = find_hwmods_by_dev(mcbsp->dev);
w = MCBSP_ST_READ(mcbsp, SSELCR);
MCBSP_ST_WRITE(mcbsp, SSELCR, w& ~(ST_SIDETONEEN));
- w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w | ST_AUTOIDLE);
+ omap_hwmod_set_module_autoidle(oh[1], 1);
w = MCBSP_READ(mcbsp, SSELCR);
MCBSP_WRITE(mcbsp, SSELCR, w& ~(SIDETONEEN));
@@ -273,9 +285,11 @@ static void omap_st_off(struct omap_mcbsp *mcbsp)
static void omap_st_fir_write(struct omap_mcbsp *mcbsp, s16 *fir)
{
u16 val, i;
+ struct omap_hwmod **oh;
- val = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, val& ~(ST_AUTOIDLE));
+ oh = find_hwmods_by_dev(mcbsp->dev);
+
+ omap_hwmod_set_module_autoidle(oh[1], 0);
val = MCBSP_ST_READ(mcbsp, SSELCR);
@@ -303,9 +317,11 @@ static void omap_st_chgain(struct omap_mcbsp *mcbsp)
{
u16 w;
struct omap_mcbsp_st_data *st_data = mcbsp->st_data;
+ struct omap_hwmod **oh;
+
+ oh = find_hwmods_by_dev(mcbsp->dev);
- w = MCBSP_ST_READ(mcbsp, SYSCONFIG);
- MCBSP_ST_WRITE(mcbsp, SYSCONFIG, w& ~(ST_AUTOIDLE));
+ omap_hwmod_set_module_autoidle(oh[1], 0);
w = MCBSP_ST_READ(mcbsp, SSELCR);
@@ -648,49 +664,46 @@ EXPORT_SYMBOL(omap_mcbsp_get_dma_op_mode);
static inline void omap34xx_mcbsp_request(struct omap_mcbsp *mcbsp)
{
+ struct omap_hwmod **oh;
+
+ oh = find_hwmods_by_dev(mcbsp->dev);
/*
* Enable wakup behavior, smart idle and all wakeups
* REVISIT: some wakeups may be unnecessary
*/
if (cpu_is_omap34xx() || cpu_is_omap44xx()) {
- u16 syscon;
-
- syscon = MCBSP_READ(mcbsp, SYSCON);
- syscon&= ~(ENAWAKEUP | SIDLEMODE(0x03) | CLOCKACTIVITY(0x03));
if (mcbsp->dma_op_mode == MCBSP_DMA_MODE_THRESHOLD) {
- syscon |= (ENAWAKEUP | SIDLEMODE(0x02) |
-
Re: Hang on boot
On Mon, Oct 11, 2010 at 8:39 AM, John Garland wrote: > Hi, > > Both the dspbridge and master branch of linux-omap seem to hang when > trying to boot (i.e. no output) on a beagleboard C2. > This is with the new omap2plus_defconfig (as opposed to the old > omap3_defconfig). > > Is anybody else experiencing this or does anyone have any idea what > could be causing this? > Grazvydas Ignotas reported this with linux-next a few hours ago. Try disabling OMAP2 and OMAP4 support and see if that works. Another useful debug method is to enable CONFIG_EARLY_PRINTK and then add "earlyprintk" to your bootargs. I'll dig up a beagleboard in a while and check. - 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 v4] ARM: Fix sparse warnings due to variables conflicts.
> -Original Message- > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk] > Sent: Saturday, October 09, 2010 4:53 AM > To: Menon, Nishanth > Cc: Poddar, Sourav; G, Manjunath Kondaiah; > linux-omap@vger.kernel.org; Shilimkar, Santosh; > linux-arm-ker...@lists.infradead.org; Varadarajan, Charulatha > Subject: Re: [PATCH v4] ARM: Fix sparse warnings due to > variables conflicts. > > On Fri, Oct 08, 2010 at 06:32:29AM -0500, Nishanth Menon wrote: > > Poddar, Sourav had written, on 10/08/2010 12:53 AM, the following: > >> Fix the sparse warnings generated due to conflicts in > variables used in readl/writel. > >> > >> > >> drivers/net/smc91x.c:312:8: warning: symbol '__v' shadows > an earlier one > >> drivers/net/smc91x.c:312:8: originally declared here > >> > >> With this change, about 200 sparse warnings are fixed. > > The commit message could be a little more detailed. > > see http://marc.info/?l=linux-omap&m=128648102511076&w=2 > > > > also should $subject say ARM: io: fix namespace conflict > > to better reflect the fix? sparse warnings are just an > indication IMHO That sounds more appropriate. Thanks. > > afaics, this patch will cause checkpatch to issue warnings > due to lines > over 80 characters. Okay. The patch was not touching the coding style of how the macros were defined earlier. Anyways, would fix the warnings and send the patch asap. > > I can't check that because I don't have the original patch via the > linux-arm-kernel mailing list. > -- 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 05/11] omap3: Remove non-existent config option
> -Original Message- > From: Felipe Contreras [mailto:felipe.contre...@gmail.com] > Sent: Sunday, October 10, 2010 7:38 PM > To: Guzman Lugo, Fernando > Cc: Marathe, Yogesh; Kanigeri, Hari; Premi, Sanjeev; Tony Lindgren; > linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org > Subject: Re: [PATCH 05/11] omap3: Remove non-existent config > option > > On Wed, Oct 6, 2010 at 3:14 AM, Guzman Lugo, Fernando > wrote: > > Can I know the status of this patch? > > > > This patch is needed now that tidspbridge has migrated to use > > Iommu moudle. > > > > Will this patch be merged? > > This patch hasn't even been sent yet. I expected somebody else to try > it and do so. Felipe, I think Fernando is talking about the patch that I had sent at the beginning. I had replied Fernando saying it is under discussion as you were looking at other iommu patches. If we have agreed upon having CONFIG_OMAP_IOMMU_IVA2 available "by default" I have no problem to try your patch else the original patch that I had sent should be reconsidered. Regards, Yogesh. > Anyway, I'm now trying iommu myself and will send this patch when I > get the dsp working. > > -- > 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 v2 01/10] OMAP: mach-omap2: Fix incorrect assignment warnings
> -Original Message- > From: Kevin Hilman [mailto:khil...@deeprootsystems.com] > Sent: Saturday, October 09, 2010 1:43 AM > To: G, Manjunath Kondaiah > Cc: linux-omap@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; Tony Lindgren; Menon, Nishanth > Subject: Re: [PATCH v2 01/10] OMAP: mach-omap2: Fix incorrect > assignment warnings > > "G, Manjunath Kondaiah" writes: > > > This patch fixes below sparse warnings for incorrect assignments. > > As pointed out by Jean, this patch fixed some sparse > warnings, but also broke some things, specifically off mode. > > In the future, *please* be sure to test the code paths that > are being changed. This patch changed some code that is only > exercised during off-mode, but was clearly not tested with > off mode enabled. > > As background for why this broke functionality, keep this in mind: > > void *a = NULL; > u32 *b = NULL; > > a + 1 = 1 > b + 1 = 4 > > IOW, you cannot simply replace a 'u32 *' by a 'void *' > without checking and fixing any pointer arithmetic. I apologize for breaking off mode support. Since sparse fixes is big patch series, I was able to test only boot and same was mentioned along with the test report in the series. Also, multiple versions of patches posted for review, I was expecting comments on this type of regressions. I will take care of testing code coverage paths for future patches. Thanks to Jean and Kevin for identifying and fixing this regression. -Manjunath-- 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 v4] ARM: Fix sparse warnings due to variables conflicts.
Tony, > -Original Message- > From: Tony Lindgren [mailto:t...@atomide.com] > Sent: Friday, October 08, 2010 11:06 PM > To: Menon, Nishanth > Cc: Poddar, Sourav; linux-omap@vger.kernel.org; > linux-arm-ker...@lists.infradead.org; Shilimkar, Santosh; G, > Manjunath Kondaiah; Varadarajan, Charulatha > Subject: Re: [PATCH v4] ARM: Fix sparse warnings due to > variables conflicts. > > * Nishanth Menon [101008 04:24]: > > Poddar, Sourav had written, on 10/08/2010 12:53 AM, the following: > > >Fix the sparse warnings generated due to conflicts in > variables used in readl/writel. > > > > > > > > >drivers/net/smc91x.c:312:8: warning: symbol '__v' shadows > an earlier > > >one > > >drivers/net/smc91x.c:312:8: originally declared here > > > > > >With this change, about 200 sparse warnings are fixed. > > The commit message could be a little more detailed. > > see http://marc.info/?l=linux-omap&m=128648102511076&w=2 > > > > also should $subject say ARM: io: fix namespace conflict to better > > reflect the fix? sparse warnings are just an indication IMHO > > BTW, also dropping the "OMAP: Convert write/read functions to > raw read/write". > > That patch does not compute, and also ends up leaving files > with __raw_readw followed by writew.. > Why to revert patch "OMAP: Convert write/read functions to raw read/write" since we need to replace other __raw_read/__raw_writel functions if above patch gets accepted. -Manjunath-- 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
Hang on boot
Hi, Both the dspbridge and master branch of linux-omap seem to hang when trying to boot (i.e. no output) on a beagleboard C2. This is with the new omap2plus_defconfig (as opposed to the old omap3_defconfig). Is anybody else experiencing this or does anyone have any idea what could be causing this? Cheers, John. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ftrace - add ftrace function_graph support on ARM
On Sat, Oct 09, 2010 at 08:37:57PM +0100, Russell King - ARM Linux wrote: > On Sat, Oct 09, 2010 at 11:20:50PM +0530, Rabin Vincent wrote: > > It's used just for the C entry functions for interrupts: asm_do_IRQ() > > and the IPI and local timer functions. > > > > AFAICS __exception seems to be used only for is_exception_text(). If > > that's the case, would it be OK to just place those functions in > > __irq_entry if ftrace is built and have is_exception_text() check that > > section too? > > No. is_exception_text() is used to detect those functions which have > a specific stack layout - which is that there's a pt_regs struct on the > stack. Grouping other functions into that violates the expectation. I'm not sure I follow. These functions (asm_do_IRQ(), do_IPI(), and do_local_timer()) will be the only ones in __irq_entry. iow, __irq_entry will contain nothing else except these functions. So we woudn't be grouping other functions; it's just that some of the __exception functions would be moved to the new section so that __exception and __irq_entry combined will contain the functions with the specific stack layout (and only those functions). -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] omap: dsp: fix ioremap() usage
Hi, Please remove the chunks you are not replying to. On Sun, Oct 10, 2010 at 11:17 PM, Premi, Sanjeev wrote: >> -void __init omap_reserve(void) >> +#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE) > > [sp] I do understand that dspbridge is the only driver accessing dsp in > the linux-omap; but there are other known drivers - which would need > this feature. Are you talking about linux-omap the tree? If so, no, the tidspbridge is part of staging, not linux-omap. If you are trying to say there are other DSP drivers intended for OMAP, then I guess you are referring to dsp-link, which uses it's own tricks for contiguous memory allocation (CMEM). So, who and how would benefit from this? > Can we use a more generic config option viz. CONFIG_RESERVE_DSPMEM > (or something similar) so that code is easily (re)usable. How about CONFIG_OMAP_DSP, and CONFIG_OMAP_DSP_RESERVE_SIZE? -- 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 2/3] omap: dsp: fix ioremap() usage
> -Original Message- > From: linux-omap-ow...@vger.kernel.org > [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Felipe > Contreras > Sent: Sunday, October 10, 2010 11:11 PM > To: linux-arm; linux-omap; Greg KH > Cc: Ramirez Luna, Omar; Russell King; Felipe Contreras > Subject: [PATCH 2/3] omap: dsp: fix ioremap() usage > > On commit 309caa9 doing ioremap() became forbidden due tue > architectural > limitations. Only a single mapping is allowed now, so the mempool must > not be part of the memory managed by the kernel. > > Signed-off-by: Felipe Contreras > --- > arch/arm/plat-omap/common.c | 43 > +++-- > arch/arm/plat-omap/devices.c | 30 - > arch/arm/plat-omap/include/plat/common.h |3 +- > arch/arm/plat-omap/include/plat/dsp.h|6 > 4 files changed, 42 insertions(+), 40 deletions(-) > > diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c > index 57205a4..3fee3ca 100644 > --- a/arch/arm/plat-omap/common.c > +++ b/arch/arm/plat-omap/common.c > @@ -37,7 +37,6 @@ > #include > #include > #include > -#include > > #include > > @@ -84,11 +83,49 @@ const void *omap_get_var_config(u16 tag, > size_t *len) > } > EXPORT_SYMBOL(omap_get_var_config); > > -void __init omap_reserve(void) > +#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE) [sp] I do understand that dspbridge is the only driver accessing dsp in the linux-omap; but there are other known drivers - which would need this feature. Can we use a more generic config option viz. CONFIG_RESERVE_DSPMEM (or something similar) so that code is easily (re)usable. ~sanjeev [snip]...[snip] > + > -- 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] arm: mm: allow boards to fiddle with meminfo
On Sun, Oct 10, 2010 at 10:03 PM, Russell King - ARM Linux
wrote:
> On Sun, Oct 10, 2010 at 08:40:38PM +0300, Felipe Contreras wrote:
>> So that they can reserve some memory.
>>
>> Signed-off-by: Felipe Contreras
>> ---
>> arch/arm/include/asm/mach/arch.h | 2 +-
>> arch/arm/mm/init.c | 7 ---
>> 2 files changed, 5 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/mach/arch.h
>> b/arch/arm/include/asm/mach/arch.h
>> index 8a0dd18..408e4d5 100644
>> --- a/arch/arm/include/asm/mach/arch.h
>> +++ b/arch/arm/include/asm/mach/arch.h
>> @@ -38,7 +38,7 @@ struct machine_desc {
>> void (*fixup)(struct machine_desc *,
>> struct tag *, char **,
>> struct meminfo *);
>> - void (*reserve)(void);/* reserve mem blocks */
>> + void (*reserve)(struct meminfo *);/* reserve mem
>> blocks */
>> void (*map_io)(void);/* IO mapping function */
>> void (*init_irq)(void);
>> struct sys_timer *timer; /* system tick timer */
>> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
>> index 7185b00..4b5c117 100644
>> --- a/arch/arm/mm/init.c
>> +++ b/arch/arm/mm/init.c
>> @@ -272,8 +272,6 @@ void __init arm_memblock_init(struct meminfo *mi, struct
>> machine_desc *mdesc)
>> int i;
>>
>> memblock_init();
>> - for (i = 0; i < mi->nr_banks; i++)
>> - memblock_add(mi->bank[i].start, mi->bank[i].size);
>>
>> /* Register the kernel text, kernel data and initrd with memblock. */
>> #ifdef CONFIG_XIP_KERNEL
>> @@ -295,7 +293,10 @@ void __init arm_memblock_init(struct meminfo *mi,
>> struct machine_desc *mdesc)
>>
>> /* reserve any platform specific memblock areas */
>> if (mdesc->reserve)
>> - mdesc->reserve();
>> + mdesc->reserve(mi);
>> +
>> + for (i = 0; i < mi->nr_banks; i++)
>> + memblock_add(mi->bank[i].start, mi->bank[i].size);
>
> It is not a good idea to change the ordering here, as we'll now be
> adding the memory blocks _after_ we've started to make reservations
> into memblock.
>
> At least the omapfb code wants there to be memory present in memblock
> when ->reserve is called.
True. I initially added a new callback called reserve_mem(), but I
thought it would be nicer to avoid adding a new function almost
identical to an existing one.
Anyway, what is your suggestion? Can you come up with something else?
--
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 1/3] arm: mm: allow boards to fiddle with meminfo
On Sun, Oct 10, 2010 at 08:40:38PM +0300, Felipe Contreras wrote:
> So that they can reserve some memory.
>
> Signed-off-by: Felipe Contreras
> ---
> arch/arm/include/asm/mach/arch.h |2 +-
> arch/arm/mm/init.c |7 ---
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/mach/arch.h
> b/arch/arm/include/asm/mach/arch.h
> index 8a0dd18..408e4d5 100644
> --- a/arch/arm/include/asm/mach/arch.h
> +++ b/arch/arm/include/asm/mach/arch.h
> @@ -38,7 +38,7 @@ struct machine_desc {
> void(*fixup)(struct machine_desc *,
>struct tag *, char **,
>struct meminfo *);
> - void(*reserve)(void);/* reserve mem blocks */
> + void(*reserve)(struct meminfo *);/* reserve mem
> blocks */
> void(*map_io)(void);/* IO mapping function */
> void(*init_irq)(void);
> struct sys_timer*timer; /* system tick timer*/
> diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> index 7185b00..4b5c117 100644
> --- a/arch/arm/mm/init.c
> +++ b/arch/arm/mm/init.c
> @@ -272,8 +272,6 @@ void __init arm_memblock_init(struct meminfo *mi, struct
> machine_desc *mdesc)
> int i;
>
> memblock_init();
> - for (i = 0; i < mi->nr_banks; i++)
> - memblock_add(mi->bank[i].start, mi->bank[i].size);
>
> /* Register the kernel text, kernel data and initrd with memblock. */
> #ifdef CONFIG_XIP_KERNEL
> @@ -295,7 +293,10 @@ void __init arm_memblock_init(struct meminfo *mi, struct
> machine_desc *mdesc)
>
> /* reserve any platform specific memblock areas */
> if (mdesc->reserve)
> - mdesc->reserve();
> + mdesc->reserve(mi);
> +
> + for (i = 0; i < mi->nr_banks; i++)
> + memblock_add(mi->bank[i].start, mi->bank[i].size);
It is not a good idea to change the ordering here, as we'll now be
adding the memory blocks _after_ we've started to make reservations
into memblock.
At least the omapfb code wants there to be memory present in memblock
when ->reserve is called.
--
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: g_ether broken on musb
hello, > Reproduce the test with your setup script, no your 'ping' issue > happened on my beagle B5. ok I've updated to next-20101008 (from next-20101006) and the network no longer works at all on fresh boot, it starts working only after replugging the cable. I think it's because patch "usb: musb: gadget: Unmapping the dma buffer when switching to PIO mode" was dropped, which effectively disables DMA due to a bug in it, so it's probably DMA problems on my board. Here is my log: http://notaz.gp2x.de/misc/pnd/linux_next_20101008_musb There is some lock backtrace in the log, but I don't think it's related, as with "Unmapping the dma buffer when switching to PIO mode" patch network works, but I guess I lose DMA. I'm using omap2plus_defconfig with OMAP2 and OMAP4 disabled (otherwise did not boot for some reason), and musb, g_ether and earlyprintk 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
[PATCH 2/3] omap: dsp: fix ioremap() usage
On commit 309caa9 doing ioremap() became forbidden due tue architectural
limitations. Only a single mapping is allowed now, so the mempool must
not be part of the memory managed by the kernel.
Signed-off-by: Felipe Contreras
---
arch/arm/plat-omap/common.c | 43 +++--
arch/arm/plat-omap/devices.c | 30 -
arch/arm/plat-omap/include/plat/common.h |3 +-
arch/arm/plat-omap/include/plat/dsp.h|6
4 files changed, 42 insertions(+), 40 deletions(-)
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
index 57205a4..3fee3ca 100644
--- a/arch/arm/plat-omap/common.c
+++ b/arch/arm/plat-omap/common.c
@@ -37,7 +37,6 @@
#include
#include
#include
-#include
#include
@@ -84,11 +83,49 @@ const void *omap_get_var_config(u16 tag, size_t *len)
}
EXPORT_SYMBOL(omap_get_var_config);
-void __init omap_reserve(void)
+#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE)
+
+static phys_addr_t omap_dsp_mempool_base;
+
+static void __init omap_dsp_reserve_mem(struct meminfo *mi)
+{
+ phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
+ phys_addr_t addr = ~0;
+ int i;
+
+ if (!size)
+ return;
+
+ for (i = mi->nr_banks - 1; i >= 0; i--)
+ if (mi->bank[i].size >= size) {
+ mi->bank[i].size -= size;
+ addr = mi->bank[i].start + mi->bank[i].size;
+ break;
+ }
+
+ if (addr == ~0) {
+ pr_err("%s: failed to reserve 0x%x bytes\n",
+ __func__, size);
+ return;
+ }
+
+ omap_dsp_mempool_base = addr;
+}
+
+phys_addr_t omap_dsp_get_mempool_base(void)
+{
+ return omap_dsp_mempool_base;
+}
+EXPORT_SYMBOL(omap_dsp_get_mempool_base);
+#else
+static inline void omap_dsp_reserve_mem(struct meminfo *mi) { }
+#endif
+
+void __init omap_reserve(struct meminfo *mi)
{
omapfb_reserve_sdram_memblock();
omap_vram_reserve_sdram_memblock();
- omap_dsp_reserve_sdram_memblock();
+ omap_dsp_reserve_mem(mi);
}
/*
diff --git a/arch/arm/plat-omap/devices.c b/arch/arm/plat-omap/devices.c
index 4c8f9b9..d1920be 100644
--- a/arch/arm/plat-omap/devices.c
+++ b/arch/arm/plat-omap/devices.c
@@ -15,7 +15,6 @@
#include
#include
#include
-#include
#include
#include
@@ -273,35 +272,6 @@ static void omap_init_wdt(void)
static inline void omap_init_wdt(void) {}
#endif
-#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE)
-
-static phys_addr_t omap_dsp_phys_mempool_base;
-
-void __init omap_dsp_reserve_sdram_memblock(void)
-{
- phys_addr_t size = CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE;
- phys_addr_t paddr;
-
- if (!size)
- return;
-
- paddr = __memblock_alloc_base(size, SZ_1M, MEMBLOCK_REAL_LIMIT);
- if (!paddr) {
- pr_err("%s: failed to reserve %x bytes\n",
- __func__, size);
- return;
- }
-
- omap_dsp_phys_mempool_base = paddr;
-}
-
-phys_addr_t omap_dsp_get_mempool_base(void)
-{
- return omap_dsp_phys_mempool_base;
-}
-EXPORT_SYMBOL(omap_dsp_get_mempool_base);
-#endif
-
/*
* This gets called after board-specific INIT_MACHINE, and initializes most
* on-chip peripherals accessible on this board (except for few like USB):
diff --git a/arch/arm/plat-omap/include/plat/common.h
b/arch/arm/plat-omap/include/plat/common.h
index 9776b41..3675492 100644
--- a/arch/arm/plat-omap/include/plat/common.h
+++ b/arch/arm/plat-omap/include/plat/common.h
@@ -30,11 +30,12 @@
#include
struct sys_timer;
+struct meminfo;
extern void omap_map_common_io(void);
extern struct sys_timer omap_timer;
-extern void omap_reserve(void);
+extern void omap_reserve(struct meminfo *mi);
/*
* IO bases for various OMAP processors
diff --git a/arch/arm/plat-omap/include/plat/dsp.h
b/arch/arm/plat-omap/include/plat/dsp.h
index 9c604b3..4e53687 100644
--- a/arch/arm/plat-omap/include/plat/dsp.h
+++ b/arch/arm/plat-omap/include/plat/dsp.h
@@ -22,10 +22,4 @@ struct omap_dsp_platform_data {
phys_addr_t phys_mempool_size;
};
-#if defined(CONFIG_TIDSPBRIDGE) || defined(CONFIG_TIDSPBRIDGE_MODULE)
-extern void omap_dsp_reserve_sdram_memblock(void);
-#else
-static inline void omap_dsp_reserve_sdram_memblock(void) { }
-#endif
-
#endif
--
1.7.3.1.2.g7fe2b
--
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 3/3] staging: tidspbridge: remove memory consistency from TODO list
The mempool area is not handled by the kernel any more. Cc: Arnd Bergmann Signed-off-by: Felipe Contreras --- drivers/staging/tidspbridge/TODO |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/staging/tidspbridge/TODO b/drivers/staging/tidspbridge/TODO index 187363f..54f4a29 100644 --- a/drivers/staging/tidspbridge/TODO +++ b/drivers/staging/tidspbridge/TODO @@ -13,7 +13,6 @@ * Audit and clean up header files folder * Use kernel coding style * checkpatch.pl fixes -* allocate ext_mem_pool from consistent memory instead of using ioremap Please send any patches to Greg Kroah-Hartman and Omar Ramirez Luna . -- 1.7.3.1.2.g7fe2b -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] staging: tidspbridge: fix ioremap() usage
Now we truly reserve the memory so that the kernel doesn't map it. Unfortunately, the ARM architecture code doesn't provide a good way to do this, so I had to modify it a bit. Felipe Contreras (3): arm: mm: allow boards to fiddle with meminfo omap: dsp: fix ioremap() usage staging: tidspbridge: remove memory consistency from TODO list arch/arm/include/asm/mach/arch.h |2 +- arch/arm/mm/init.c |7 +++-- arch/arm/plat-omap/common.c | 43 +++-- arch/arm/plat-omap/devices.c | 30 - arch/arm/plat-omap/include/plat/common.h |3 +- arch/arm/plat-omap/include/plat/dsp.h|6 drivers/staging/tidspbridge/TODO |1 - 7 files changed, 47 insertions(+), 45 deletions(-) -- 1.7.3.1.2.g7fe2b -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] arm: mm: allow boards to fiddle with meminfo
So that they can reserve some memory.
Signed-off-by: Felipe Contreras
---
arch/arm/include/asm/mach/arch.h |2 +-
arch/arm/mm/init.c |7 ---
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/mach/arch.h b/arch/arm/include/asm/mach/arch.h
index 8a0dd18..408e4d5 100644
--- a/arch/arm/include/asm/mach/arch.h
+++ b/arch/arm/include/asm/mach/arch.h
@@ -38,7 +38,7 @@ struct machine_desc {
void(*fixup)(struct machine_desc *,
struct tag *, char **,
struct meminfo *);
- void(*reserve)(void);/* reserve mem blocks */
+ void(*reserve)(struct meminfo *);/* reserve mem
blocks */
void(*map_io)(void);/* IO mapping function */
void(*init_irq)(void);
struct sys_timer*timer; /* system tick timer*/
diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
index 7185b00..4b5c117 100644
--- a/arch/arm/mm/init.c
+++ b/arch/arm/mm/init.c
@@ -272,8 +272,6 @@ void __init arm_memblock_init(struct meminfo *mi, struct
machine_desc *mdesc)
int i;
memblock_init();
- for (i = 0; i < mi->nr_banks; i++)
- memblock_add(mi->bank[i].start, mi->bank[i].size);
/* Register the kernel text, kernel data and initrd with memblock. */
#ifdef CONFIG_XIP_KERNEL
@@ -295,7 +293,10 @@ void __init arm_memblock_init(struct meminfo *mi, struct
machine_desc *mdesc)
/* reserve any platform specific memblock areas */
if (mdesc->reserve)
- mdesc->reserve();
+ mdesc->reserve(mi);
+
+ for (i = 0; i < mi->nr_banks; i++)
+ memblock_add(mi->bank[i].start, mi->bank[i].size);
memblock_analyze();
memblock_dump_all();
--
1.7.3.1.2.g7fe2b
--
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: [PATCHv3 00/11] staging tidspbridge: iommu migration
On Tue, Oct 5, 2010 at 11:35 PM, Fernando Guzman Lugo wrote: > This set of patches remove the dspbridge custom mmu > implementation and use iommu module instead. I have tried this, it works for simple tests, but not real use-cases. I applied all your iommu patches. How did you test this? -- 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] iommu: fix end address of vm area comparation in alloc_iovm_area
On Tue, Aug 17, 2010 at 7:56 PM, Fernando Guzman Lugo wrote: > End address of the vm area is .start + bytes -1., not start + byte. > This patch fixes that issue by doing an inclusive comparison with > tmp->da_start. This issue was preventing allocate an area of size > exactly the same than the free area. I did no change the value of > da_end of each vm area because it is used to get area size in > several places. > > Signed-off-by: Fernando Guzman Lugo > Acked-by: Hiroshi DOYU Signed-off-by: Felipe Contreras -- 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: [PATCHv2 2/3] iovmm: add superpages support to fixed da address
On Tue, Oct 5, 2010 at 12:02 AM, Fernando Guzman Lugo wrote:
> This patch adds superpages support to fixed ad address
> inside iommu_kmap function.
>
> Signed-off-by: Fernando Guzman Lugo
> ---
> arch/arm/plat-omap/iovmm.c | 61 ++-
> 1 files changed, 37 insertions(+), 24 deletions(-)
>
> diff --git a/arch/arm/plat-omap/iovmm.c b/arch/arm/plat-omap/iovmm.c
> index 34f0012..8006a19 100644
> --- a/arch/arm/plat-omap/iovmm.c
> +++ b/arch/arm/plat-omap/iovmm.c
> @@ -87,27 +87,37 @@ static size_t sgtable_len(const struct sg_table *sgt)
> }
> #define sgtable_ok(x) (!!sgtable_len(x))
>
> +
> +static unsigned max_alignment(u32 addr)
> +{
> + int i;
> + unsigned pagesize[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K, };
> + for (i = 0; i < ARRAY_SIZE(pagesize) && addr & (pagesize[i] - 1); i++)
> + ;
> + return (i < ARRAY_SIZE(pagesize)) ? pagesize[i] : 0;
> +}
> +
> +
I don't think those extra spaces make sense.
> /*
> * calculate the optimal number sg elements from total bytes based on
> * iommu superpages
> */
> -static unsigned int sgtable_nents(size_t bytes)
> +static unsigned int sgtable_nents(size_t bytes, u32 da, u32 pa)
> {
> - int i;
> - unsigned int nr_entries;
> - const unsigned long pagesize[] = { SZ_16M, SZ_1M, SZ_64K, SZ_4K, };
> + unsigned int nr_entries = 0, ent_sz;
How about s/unsigned int/unsigned/?
>
> if (!IS_ALIGNED(bytes, PAGE_SIZE)) {
> pr_err("%s: wrong size %08x\n", __func__, bytes);
> return 0;
> }
>
> - nr_entries = 0;
> - for (i = 0; i < ARRAY_SIZE(pagesize); i++) {
> - if (bytes >= pagesize[i]) {
> - nr_entries += (bytes / pagesize[i]);
> - bytes %= pagesize[i];
> - }
> + while (bytes) {
> + ent_sz = max_alignment(da | pa);
> + ent_sz = min(ent_sz, (unsigned)iopgsz_max(bytes));
> + nr_entries++;
> + da += ent_sz;
> + pa += ent_sz;
> + bytes -= ent_sz;
> }
> BUG_ON(bytes);
>
> @@ -115,7 +125,8 @@ static unsigned int sgtable_nents(size_t bytes)
> }
>
> /* allocate and initialize sg_table header(a kind of 'superblock') */
> -static struct sg_table *sgtable_alloc(const size_t bytes, u32 flags)
> +static struct sg_table *sgtable_alloc(const size_t bytes, u32 flags,
> + u32 da, u32 pa)
> {
> unsigned int nr_entries;
> int err;
> @@ -127,9 +138,8 @@ static struct sg_table *sgtable_alloc(const size_t bytes,
> u32 flags)
> if (!IS_ALIGNED(bytes, PAGE_SIZE))
> return ERR_PTR(-EINVAL);
>
> - /* FIXME: IOVMF_DA_FIXED should support 'superpages' */
> - if ((flags & IOVMF_LINEAR) && (flags & IOVMF_DA_ANON)) {
> - nr_entries = sgtable_nents(bytes);
> + if (flags & IOVMF_LINEAR) {
> + nr_entries = sgtable_nents(bytes, da, pa);
> if (!nr_entries)
> return ERR_PTR(-EINVAL);
> } else
> @@ -409,7 +419,8 @@ static inline void sgtable_drain_vmalloc(struct sg_table
> *sgt)
> BUG_ON(!sgt);
> }
>
> -static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 pa, size_t len)
> +static void sgtable_fill_kmalloc(struct sg_table *sgt, u32 pa, u32 da,
> + size_t len)
> {
> unsigned int i;
> struct scatterlist *sg;
> @@ -420,7 +431,8 @@ static void sgtable_fill_kmalloc(struct sg_table *sgt,
> u32 pa, size_t len)
> for_each_sg(sgt->sgl, sg, sgt->nents, i) {
> size_t bytes;
>
> - bytes = iopgsz_max(len);
> + bytes = max_alignment(da | pa);
> + bytes = min(bytes, (size_t)iopgsz_max(len));
Why the size_t casting?
Otherwise:
Signed-off-by: Felipe Contreras
--
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 [0/4] perf: clean-up of power events API
On Sun, 2010-10-10 at 08:41 +0200, Peter Zijlstra wrote:
> On Sat, 2010-10-09 at 21:39 -0400, Steven Rostedt wrote:
> > I've been hesitant in the pass from doing the TRACE_EVENT_ABI()
> > before, because Peter Zijlstra (who is currently MIA) has been strongly
> > against it.
>
> I see no point in the TRACE_EVENT_ABI() because if I need to change such
> a tracepoint to reflect changes in the kernel then I will freely do so.
>
> Even seemingly stable points like sched_switch(), which we all agree
> will stay around forever (gotta have context switches on a multi-tasking
> OS) will not stay stable when we add/change scheduling policies.
>
> Sure, the prev and next task thing will stay the same, but the meaning
> and interpretation of things like the prio field will not, esp when we
> go add something like a deadline scheduler that isn't priority based.
>
> So one possibility is to simply remove all that information from the
> tracepoints, remove the prio and state fields, but how useful is that?
>
> I guess what I'm saying is that even if we were to provide _ABI I see us
> getting into this very same argument over and over again, making me want
> to remove all this trace event muck right now before it gets worse.
Then how's this as a compromise. We do not add a TRACE_EVENT_ABI(), but
instead manually add the ABI interface to existing tracepoints. Let's
use the sched example you shown above.
We can connect to the sched_switch() tracepoint manually in something
perhaps called kernel/abi_trace.c or trace_abi.c (whatever).
Here we create the directories manually there:
/sys/kernel/event/sched/sched_switch/
But this sched_switch will only include the prev and next pids, comms,
and perhaps even run state. But not the prio (since we see that
changing).
It would then need the code to enable the trace point with:
register_trace_sched_switch(sched_switch_abi_probe, NULL);
Where we have
static void
sched_switch_abi_probe(void *ignore,
struct task_switch *prev,
struct task_struct *next)
{
/* code to grab just the ABI stuff */
}
And this code can then record to what ever hooked to it.
Making this a manual effort will make it easier to control what becomes
an ABI. We can have long discussions and flames over what goes here. But
that's good since debates before an ABI is created is much better than
debates after one is created.
I'm afraid that a easy macro called TRACE_EVENT_ABI() would have the
same issue. ABIs may be created too quickly before they are thought
through.
Thoughts?
-- Steve
--
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 05/11] omap3: Remove non-existent config option
On Wed, Oct 6, 2010 at 3:14 AM, Guzman Lugo, Fernando wrote: > Can I know the status of this patch? > > This patch is needed now that tidspbridge has migrated to use > Iommu moudle. > > Will this patch be merged? This patch hasn't even been sent yet. I expected somebody else to try it and do so. Anyway, I'm now trying iommu myself and will send this patch when I get the dsp working. -- 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 [0/4] perf: clean-up of power events API
* Arjan van de Ven wrote: > On 10/8/2010 11:28 PM, Ingo Molnar wrote: > >* Mathieu Desnoyers wrote: > > > >>* Arjan van de Ven (ar...@linux.intel.com) wrote: > >>> On 10/8/2010 1:38 AM, Ingo Molnar wrote: > The fundamental thing about tracing/instrumentation is that there > are no deep ABI needs: it's all about analyzing development kernels > (and a few select versions that get the enterprise treatment) but > otherwise the half-life of this kind of information is very short. > > So we dont want to tie ourselves down with excessive ABIs. > >>>ok I'll start working on a second mechanism then to export > >>>information that applications need ;-( it'll look a lot like tracing > >>>I suppose ;-( > >>What's wrong with doing the compatibility layer in a LGPL library > >>shipped with the kernel tree under tools/ ? Why does everything *have* > >>to be done in kernel-space ? Why are you so focused on making your > >>application interact directly with kernel ABIs ? > >The thing is, Arjan is 100% right that a library for this is not a > >'solution', it's an unnecessary complication. > > > >What i suggested in my mail was to _keep existing events_. I.e. do not > >break powertop. We are 100% happy that we _have_ such apps, and we > >should do reasonable things to not break them. > > > >If we need to change events, we can add a new event. The old events will > >lose their relevance without us having to do much - and without us > >having to break powertop, pytimechart, etc. We can even have periods of > >overlap when both events are available - to give instrumentation apps > >time to learn the new events. > > > >I.e. it's not an ABI in the classic sense - we do not (because we > >cannot) guarantee the infinite availability of these events. But we can > >guarantee that the fields do not change in some stupid, avoidable way. > > also I have to say that some events are more likely to change than others > > "function foo in the kernel called" is more likely to change than "the > processor went to THIS frequency". The concept of CPU frequencies has > been with us fora long time and is going to be there for a long time > as well .. Most definitely. It's no accident that it took such a long time for this issue to be raised in the first place. It's a rare occurance - and then we can deal with it intelligently, without breaking stuff unnecessarily. Thanks, Ingo -- 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
