* [PATCH] ARM i.MX53: enable fec driver on EVK board
From: Yong Shen @ 2011-01-06 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106061647.GB30232@jasper.tkos.co.il>
Hi Baruch,
Thanks for comments.
>>
>> +static inline void fec_reset(void)
>
> For the sake of clearer stack traces I prefer a less generic name for this
> routine, something like mx53_evk_fec_reset().
>
Acked.
>> +{
>> + ? ? int ret;
>> +
>> + ? ? /* reset FEC PHY */
>> + ? ? ret = gpio_request(SMD_FEC_PHY_RST, "fec-phy-reset");
>> + ? ? if (ret) {
>> + ? ? ? ? ? ? printk(KERN_ERR"failed to get GPIO_FEC_PHY_RESET: %d\n", ret);
>> + ? ? ? ? ? ? return;
>> + ? ? }
>> + ? ? gpio_direction_output(SMD_FEC_PHY_RST, 0);
>> + ? ? gpio_set_value(SMD_FEC_PHY_RST, 0);
>
> This seems to be redundant. gpio_direction_output() has already set the value
> to 0.
You are right. But, gpio_set_value is meant to be here to show the
process of fec reset: first pull low and then pull high. And
gpio_direction_output here is for direction configuration although it
has the ability of configure output value.
cheers
Yong
^ permalink raw reply
* [PATCH 4/9] fb: export fb mode db table
From: Sascha Hauer @ 2011-01-06 10:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106072658.GB15914@linux-sh.org>
On Thu, Jan 06, 2011 at 04:26:58PM +0900, Paul Mundt wrote:
> On Thu, Dec 09, 2010 at 02:47:16PM +0100, Sascha Hauer wrote:
> > The different modes can be useful for drivers. Currently there is
> > no way to expose the modes to sysfs, so export them.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> I'll admit I don't really like the idea of exposing the modedb to drivers
> in this way, but given that we're already doing it for the vesa and cea
> modes, allowing drivers to copy ranges in to their modelist from the
> standard db is probably something we can live with.
>
> The mode list dumping is basically a blatant sysfs abuse already though,
You mean the available modes should not be exposed to sysfs? I found it
quite convenient to have during development. Exporting the modedb seemed
to be the only way to populate sysfs with a sane set of modes.
> and it would be much cleaner simply to back the mode store with an
> fb_find/try_mode() pair that grovels all the right places in addition to
> doing a pass over the fb_info's modelist.
The kernel provides no way to query the modelist other than sysfs. So
when the modelist dumping is a sysfs abuse, what purpose does the
modelist have anyway?
Right now the behaviour is quite strange. Each time a new (formerly
unknown) mode is selected the modelist magically gets a new entry. So
the kernel normally starts with an empty (or one entry from startup)
modelist and gets populated over time with the modes the user used.
I could understand when we say: "We do not keep the modelist in kernel,
do this in userspace". I could also understand when we say "we keep a
list of sane modes in the kernel, use fbset to switch to exotic modes".
ATM we do the worst of both: We keep a list but we do not populate it
with sane modes. Even worse, we use it to store the history of modes.
I know much of this comes from the fact that the fb subsystem does not
have a maintainer and nowadays the big desktop guys are not using the fb
subsystem at all, but it's really hard to find a way through and every
driver seems to have it's own idea of how things should work.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling
From: aaro.koskinen at nokia.com @ 2011-01-06 10:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874o9mvpxf.fsf@ti.com>
Hi,
Kevin Hilman [khilman at ti.com]:
> Aaro Koskinen <aaro.koskinen@nokia.com> writes:
>
> > Make !CONFIG_SUSPEND init declarations identical on all OMAPs and
> > eliminate some ifdefs.
> >
> > Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
>
> I like this solution, but it introduces compiler warnings:
>
> [...]
>
> As you likely noticed, removing the const leads to checkpatch warnings:
>
> WARNING: struct platform_suspend_ops should normally be const
>
> so the choice is between a checkpatch warning or a bunch of compiler
> warnings.
>
> Alternatively, I just posted a patch[1] to linux-pm propsing to fix this
> at the source. Let's see what happens there. Merging $SUBJECT patch
> will depend on how this is fixed upstream.
Sorry, I should have mentioned this when I posted the patch. I was aware of
this issue, but I thought this was already fixed in upstream. Check the following
commit in linux-next:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=2f55ac072f5344519348c0c94b3d2f4cca46847b
(suspend: constify platform_suspend_ops)
A.
^ permalink raw reply
* [PATCH v4 5/8] arm: mxc: move IOMUX_CONFIG_XXXX definitions to iomux-v3.h
From: Sascha Hauer @ 2011-01-06 10:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106065935.GA15509@shlinux1.ap.freescale.net>
On Thu, Jan 06, 2011 at 02:59:36PM +0800, Richard Zhao wrote:
> Hello Sascha,
>
> On Thu, Dec 30, 2010 at 07:25:04PM +0800, Richard Zhao wrote:
> > IOMUX_CONFIG_GPIO is not for iomux-v3. It's for old freescale
> > iomux routines. Remove it.
> >
> > Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
> > Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> If you don't have comments, could you please merge this patch?
> It's causing arch/arm/plat-mxc/include/mach/iomux-mx50.h incomplete.
I didn't apply it because it conflicts with current imx-for-2.6.38
branch. Other than that I don't find the enum very useful at all,
because we have problems with very long lines in these files and
using IOMUX_CONFIG_ALT0 where we could use 0 does not exactly improve
the situation.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v2] i.MX51 Framebuffer support
From: Sascha Hauer @ 2011-01-06 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D246C54.9060503@free.fr>
On Wed, Jan 05, 2011 at 02:04:20PM +0100, Julien Boibessot wrote:
> Hello,
>
> Sascha Hauer a ?crit :
> > The following series adds i.MX51 framebuffer support based on the IPUv3. It
> > is not perfect but I decided it is good enough to open it for a wider audience
> > and collect first reviews. I tested this on a babbage board using both outputs
> > (VGA/DVI) with different resolutions up to 1680x1050 and different colour depths.
> > I also tested it on one custom board using a fixed display setting.
> >
> This driver is also working fine for me on a custom i.MX51 board with a
> 800x480 18 bits TFT LCD (16bpp mode).
>
> The only strange thing I noticed was a kind of uggly sprite/artefact
> (32x32, I would say) appearing at the same time as the Linux console. I
> think it may be related to a hardware cursor badly (?) initialised, but
> I didn't find a fix yet.
> It disappears when I launch a graphical application (Qt or SDL).
It may be the penguin, but I remember a similar report also talkling
about hardware cursors. I can't reproduce this. You could search for
cursor in the IPU section of the manual and play with the corresponding
registers.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v4 5/8] arm: mxc: move IOMUX_CONFIG_XXXX definitions to iomux-v3.h
From: Richard Zhao @ 2011-01-06 10:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106101639.GE26009@pengutronix.de>
On Thu, Jan 06, 2011 at 11:16:39AM +0100, Sascha Hauer wrote:
> On Thu, Jan 06, 2011 at 02:59:36PM +0800, Richard Zhao wrote:
> > Hello Sascha,
> >
> > On Thu, Dec 30, 2010 at 07:25:04PM +0800, Richard Zhao wrote:
> > > IOMUX_CONFIG_GPIO is not for iomux-v3. It's for old freescale
> > > iomux routines. Remove it.
> > >
> > > Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
> > > Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > If you don't have comments, could you please merge this patch?
> > It's causing arch/arm/plat-mxc/include/mach/iomux-mx50.h incomplete.
>
> I didn't apply it because it conflicts with current imx-for-2.6.38
> branch. Other than that I don't find the enum very useful at all,
> because we have problems with very long lines in these files and
> using IOMUX_CONFIG_ALT0 where we could use 0 does not exactly improve
> the situation.
Yes, correct. IOMUX_CONFIG_ALT0-7 is ok. But IOMUX_CONFIG_SION is more
readable than 0x1 << 4, isn't it? If you don't agree put IOMUX_CONFIG_SION
in iomux-v3.h, shall I put it in iomux-mx50.h?
Thanks
Richard
>
> Sascha
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
^ permalink raw reply
* [PATCH v2] i.MX51 Framebuffer support
From: Peter Horton @ 2011-01-06 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106102310.GF26009@pengutronix.de>
On 06/01/2011 10:23, Sascha Hauer wrote:
> On Wed, Jan 05, 2011 at 02:04:20PM +0100, Julien Boibessot wrote:
>> Hello,
>>
>> Sascha Hauer a ?crit :
>>> The following series adds i.MX51 framebuffer support based on the IPUv3. It
>>> is not perfect but I decided it is good enough to open it for a wider audience
>>> and collect first reviews. I tested this on a babbage board using both outputs
>>> (VGA/DVI) with different resolutions up to 1680x1050 and different colour depths.
>>> I also tested it on one custom board using a fixed display setting.
>>>
>> This driver is also working fine for me on a custom i.MX51 board with a
>> 800x480 18 bits TFT LCD (16bpp mode).
>>
>> The only strange thing I noticed was a kind of uggly sprite/artefact
>> (32x32, I would say) appearing at the same time as the Linux console. I
>> think it may be related to a hardware cursor badly (?) initialised, but
>> I didn't find a fix yet.
>> It disappears when I launch a graphical application (Qt or SDL).
>
> It may be the penguin, but I remember a similar report also talkling
> about hardware cursors. I can't reproduce this. You could search for
> cursor in the IPU section of the manual and play with the corresponding
> registers.
>
We see this too, but only when increasing resolution from the kernel
default. We get a yellow square appear in the lower right quadrant of
the display.
P.
^ permalink raw reply
* [PATCH v4 5/8] arm: mxc: move IOMUX_CONFIG_XXXX definitions to iomux-v3.h
From: Sascha Hauer @ 2011-01-06 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106102918.GA2349@shlinux1.ap.freescale.net>
On Thu, Jan 06, 2011 at 06:29:19PM +0800, Richard Zhao wrote:
> On Thu, Jan 06, 2011 at 11:16:39AM +0100, Sascha Hauer wrote:
> > On Thu, Jan 06, 2011 at 02:59:36PM +0800, Richard Zhao wrote:
> > > Hello Sascha,
> > >
> > > On Thu, Dec 30, 2010 at 07:25:04PM +0800, Richard Zhao wrote:
> > > > IOMUX_CONFIG_GPIO is not for iomux-v3. It's for old freescale
> > > > iomux routines. Remove it.
> > > >
> > > > Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
> > > > Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > > If you don't have comments, could you please merge this patch?
> > > It's causing arch/arm/plat-mxc/include/mach/iomux-mx50.h incomplete.
> >
> > I didn't apply it because it conflicts with current imx-for-2.6.38
> > branch. Other than that I don't find the enum very useful at all,
> > because we have problems with very long lines in these files and
> > using IOMUX_CONFIG_ALT0 where we could use 0 does not exactly improve
> > the situation.
> Yes, correct. IOMUX_CONFIG_ALT0-7 is ok. But IOMUX_CONFIG_SION is more
> readable than 0x1 << 4, isn't it? If you don't agree put IOMUX_CONFIG_SION
> in iomux-v3.h, shall I put it in iomux-mx50.h?
IOMUX_CONFIG_SION is ok, but please drop the rest.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Hit BUG_ON in dma-mapping.c:425
From: Nicolas Ferre @ 2011-01-06 10:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105165551.GE8638@n2100.arm.linux.org.uk>
(I include MTD mailing-list now)
Le 05/01/2011 17:55, Russell King - ARM Linux :
> On Wed, Jan 05, 2011 at 05:49:12PM +0100, Nicolas Ferre wrote:
>> Hi,
>>
>> While running mtd_stresstest on a dataflash (atmel_spi
>> + mtd_dataflash drivers) I hit the BUG_ON directive that
>> is at the beginning of ___dma_single_cpu_to_dev() function.
>> This function is called from the SPI driver that do a
>> dma_map_single() before DMA operations on the buffer
>> transmitted from upper layers.
>>
>> It seems that this address is above "high_memory" limit because
>> it is allocated by vmalloc (in mtd_stresstest.c:285)...
>
> Well, its telling you is that you're not allowed to DMA to vmalloc
> addresses. Whether that's the fault of the map driver or not is a
> question for mtd folk.
So you mean that those vmalloc calls should be changed to kmalloc in MTD like this:
--- a/drivers/mtd/tests/mtd_stresstest.c
+++ b/drivers/mtd/tests/mtd_stresstest.c
@@ -26,7 +26,6 @@
#include <linux/mtd/mtd.h>
#include <linux/slab.h>
#include <linux/sched.h>
-#include <linux/vmalloc.h>
#define PRINT_PREF KERN_INFO "mtd_stresstest: "
@@ -281,8 +280,8 @@ static int __init mtd_stresstest_init(void)
bufsize = mtd->erasesize * 2;
err = -ENOMEM;
- readbuf = vmalloc(bufsize);
- writebuf = vmalloc(bufsize);
+ readbuf = kmalloc(bufsize, GFP_KERNEL);
+ writebuf = kmalloc(bufsize, GFP_KERNEL);
offsets = kmalloc(ebcnt * sizeof(int), GFP_KERNEL);
if (!readbuf || !writebuf || !offsets) {
printk(PRINT_PREF "error: cannot allocate memory\n");
@@ -313,8 +312,8 @@ static int __init mtd_stresstest_init(void)
out:
kfree(offsets);
kfree(bbt);
- vfree(writebuf);
- vfree(readbuf);
+ kfree(writebuf);
+ kfree(readbuf);
put_mtd_device(mtd);
if (err)
printk(PRINT_PREF "error %d occurred\n", err);
I also discovered the same issue while trying to write with "dd" on /dev/mtdblockx
Same vmalloc'ed memory seems to be used in mtdblock_writesect():
mtdblk->cache_data = vmalloc(mtdblk->mbd.mtd->erasesize);
I know that using "dd" on a block device is not the common case but it should work instead of not being able to transmit buffer with DMA... So what it implies to switch this to kmalloc? Is it regression-free to do this?
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH v4 5/8] arm: mxc: move IOMUX_CONFIG_XXXX definitions to iomux-v3.h
From: Arnaud Patard (Rtp) @ 2011-01-06 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106101639.GE26009@pengutronix.de>
Sascha Hauer <s.hauer@pengutronix.de> writes:
Hi,
> On Thu, Jan 06, 2011 at 02:59:36PM +0800, Richard Zhao wrote:
>> Hello Sascha,
>>
>> On Thu, Dec 30, 2010 at 07:25:04PM +0800, Richard Zhao wrote:
>> > IOMUX_CONFIG_GPIO is not for iomux-v3. It's for old freescale
>> > iomux routines. Remove it.
>> >
>> > Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
>> > Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
>> If you don't have comments, could you please merge this patch?
>> It's causing arch/arm/plat-mxc/include/mach/iomux-mx50.h incomplete.
>
> I didn't apply it because it conflicts with current imx-for-2.6.38
> branch. Other than that I don't find the enum very useful at all,
> because we have problems with very long lines in these files and
> using IOMUX_CONFIG_ALT0 where we could use 0 does not exactly improve
> the situation.
While I agree with this, there's a small exception. I found out
yesterday that now, there's no more any macro/enum defined for the
infamous SION bit. Theses means that currently to defined a PAD with
SION bit set, we have to create a new macro with IOMUX_PAD instead
of using the _MX51_PAD_* macro as basis. Did I miss something ?
Arnaud
^ permalink raw reply
* [PATCH v4 5/8] arm: mxc: move IOMUX_CONFIG_XXXX definitions to iomux-v3.h
From: Richard Zhao @ 2011-01-06 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106103241.GG26009@pengutronix.de>
On Thu, Jan 06, 2011 at 11:32:41AM +0100, Sascha Hauer wrote:
> On Thu, Jan 06, 2011 at 06:29:19PM +0800, Richard Zhao wrote:
> > On Thu, Jan 06, 2011 at 11:16:39AM +0100, Sascha Hauer wrote:
> > > On Thu, Jan 06, 2011 at 02:59:36PM +0800, Richard Zhao wrote:
> > > > Hello Sascha,
> > > >
> > > > On Thu, Dec 30, 2010 at 07:25:04PM +0800, Richard Zhao wrote:
> > > > > IOMUX_CONFIG_GPIO is not for iomux-v3. It's for old freescale
> > > > > iomux routines. Remove it.
> > > > >
> > > > > Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
> > > > > Acked-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> > > > If you don't have comments, could you please merge this patch?
> > > > It's causing arch/arm/plat-mxc/include/mach/iomux-mx50.h incomplete.
> > >
> > > I didn't apply it because it conflicts with current imx-for-2.6.38
> > > branch. Other than that I don't find the enum very useful at all,
> > > because we have problems with very long lines in these files and
> > > using IOMUX_CONFIG_ALT0 where we could use 0 does not exactly improve
> > > the situation.
> > Yes, correct. IOMUX_CONFIG_ALT0-7 is ok. But IOMUX_CONFIG_SION is more
> > readable than 0x1 << 4, isn't it? If you don't agree put IOMUX_CONFIG_SION
> > in iomux-v3.h, shall I put it in iomux-mx50.h?
>
> IOMUX_CONFIG_SION is ok, but please drop the rest.
ok to put it into iomux-v3.h? I will sent out one patch.
Richard
>
> Sascha
>
>
> --
> Pengutronix e.K. | |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
>
^ permalink raw reply
* [PATCH 3/6] i2c/pxa2xx: Add PCI support for PXA I2C controller
From: Sebastian Andrzej Siewior @ 2011-01-06 10:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105230834.GA26399@suse.de>
* Greg KH | 2011-01-05 15:08:34 [-0800]:
>On Wed, Jan 05, 2011 at 11:03:42PM +0000, Russell King - ARM Linux wrote:
>> On Wed, Jan 05, 2011 at 05:51:00PM +0100, Sebastian Andrzej Siewior wrote:
>> > +static void plat_dev_release(struct device *dev)
>> > +{
>> > + struct ce4100_i2c_device *sd = container_of(dev,
>> > + struct ce4100_i2c_device, pdev.dev);
>> > +
>> > + of_device_node_put(&sd->pdev.dev);
>> > +}
>> > +static int add_i2c_device(struct pci_dev *dev, int bar,
>> > + struct ce4100_i2c_device *sd)
>> > +{
>> > + struct platform_device *pdev = &sd->pdev;
>> > + struct i2c_pxa_platform_data *pdata = &sd->pdata;
>> ...
>> > + pdev->name = "ce4100-i2c";
>> > + pdev->dev.release = plat_dev_release;
>> > + pdev->dev.parent = &dev->dev;
>> > +
>> > + pdev->dev.platform_data = pdata;
>> > + pdev->resource = sd->res;
>> ...
>> > +static int __devinit ce4100_i2c_probe(struct pci_dev *dev,
>> > + const struct pci_device_id *ent)
>> > +{
>> > + sds = kzalloc(sizeof(*sds), GFP_KERNEL);
>> > + if (!sds)
>> > + goto err_mem;
>> > +
>> > + pci_set_drvdata(dev, sds);
>> > +
>> > + for (i = 0; i < ARRAY_SIZE(sds->sd); i++) {
>> > + ret = add_i2c_device(dev, i, &sds->sd[i]);
>> > + if (ret) {
>> > + while (--i >= 0)
>> > + platform_device_unregister(&sds->sd[i].pdev);
>> ...
>> > +static void __devexit ce4100_i2c_remove(struct pci_dev *dev)
>> ...
>> > + for (i = 0; i < ARRAY_SIZE(sds->sd); i++)
>> > + platform_device_unregister(&sds->sd[i].pdev);
>> > +
>> > + pci_disable_device(dev);
>> > + kfree(sds);
>> > +}
>>
>> I think you should be trying to use the platform_device_alloc()
>> interfaces here, rather than trying to reinvent them. The only issue I
>> see with that is the of_device_node_put() call. Maybe OF/DT/device model
>> people can provide some pointers? Adding Greg for the device model
>> maintainer view.
>
>Don't reinvent functions that the core already provides, that's not a
>good idea.
>
>Sebastian, why didn't those functions work for you?
which functions are you talking about? I allocated one piece of memory
which contained a platform device, ressources, platform data. It looked
better than allocating multiple small chunks. I registered it with
platform_device_register() and platform_device_unregister() complained
about a missing ->release function.
So I now I'm going to rework it and use platform_device_alloc() instead.
>thanks,
>
>greg k-h
Sebastian
^ permalink raw reply
* [PATCH v2 0/3] add CNS3xxx AHCI support
From: Anton Vorontsov @ 2011-01-06 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinxNtzpzUn0=-iph_N7tffM6Nu++J9qNNhcp8pX@mail.gmail.com>
On Thu, Jan 06, 2011 at 02:43:08PM +0800, Lin Mac wrote:
[...]
> > It is overkill to rename the entirety of ahci_platform just for one override
> > function.
> > This sort of thing I would have expected to be added directly to
> > ahci_platform.c.
> It might be overkill for only one controller. but it is more clean and
> readable to have different SoC specific changes in separate files,
> especially when more SoCs need to make similar changes.
I think that renaming the file is not necessary. You can just
rename the module in the makefile.
Personally I like the current approach more than putting
controller-specific fixups directly into ahci_platform.
Thanks,
--
Anton Vorontsov
Email: cbouatmailru at gmail.com
^ permalink raw reply
* [PATCH v2 2/3] ahci_pltfm: switch to module device table matching
From: Anton Vorontsov @ 2011-01-06 10:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294206187-11487-3-git-send-email-mkl0301@gmail.com>
On Wed, Jan 05, 2011 at 01:43:06PM +0800, mkl0301 at gmail.com wrote:
> From: Mac Lin <mkl0301@gmail.com>
>
> Switch the driver to use module device table matching mechanism to add SoC-specific parts to the generic driver.
>
> Signed-off-by: Mac Lin <mkl0301@gmail.com>
> ---
> drivers/ata/ahci_pltfm.c | 14 +++++++++++++-
> drivers/ata/ahci_pltfm.h | 17 +++++++++++++++++
> 2 files changed, 30 insertions(+), 1 deletions(-)
> create mode 100644 drivers/ata/ahci_pltfm.h
>
[..]
> + * 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.
> + */
> +
> +#ifndef _DRIVERS_SATA_AHCI_PLTFM_H
> +#define _DRIVERS_SATA_AHCI_PLTFM_H
> +
> +#endif /* _DRIVERS_SATA_AHCI_PLTFM_H */
> +
> --
No need for this empty line at the end of the file.
--
Anton Vorontsov
Email: cbouatmailru at gmail.com
^ permalink raw reply
* [PATCH] i2c-pxa: fix unbidding/rebidding of the device
From: Dmitry Eremin-Solenikov @ 2011-01-06 11:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110105091915.GV27131@trinity.fluff.org>
When a "pxa2xx-i2c" device was unbound (e.g. via sysfs) the remove
callback was not called because it was discarded when linking the
kernel. Because of that the resources allocated in probe were not
freed and so a clean unbind/rebind was impossible.
Fix that by moving the remove callback to .devexit.text.
Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Cc: linux-i2c at vger.kernel.org
Cc: Ben Dooks <ben-linux@fluff.org>
---
drivers/i2c/busses/i2c-pxa.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index f4c19a9..0f10955 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -1115,7 +1115,7 @@ emalloc:
return ret;
}
-static int __exit i2c_pxa_remove(struct platform_device *dev)
+static int __devexit i2c_pxa_remove(struct platform_device *dev)
{
struct pxa_i2c *i2c = platform_get_drvdata(dev);
@@ -1169,7 +1169,7 @@ static const struct dev_pm_ops i2c_pxa_dev_pm_ops = {
static struct platform_driver i2c_pxa_driver = {
.probe = i2c_pxa_probe,
- .remove = __exit_p(i2c_pxa_remove),
+ .remove = __devexit_p(i2c_pxa_remove),
.driver = {
.name = "pxa2xx-i2c",
.owner = THIS_MODULE,
--
1.7.2.3
^ permalink raw reply related
* [PATCH v2 3/3] ahci_platform: add support for CNS3xxx SoC devices
From: Anton Vorontsov @ 2011-01-06 11:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294206187-11487-4-git-send-email-mkl0301@gmail.com>
On Wed, Jan 05, 2011 at 01:43:07PM +0800, mkl0301 at gmail.com wrote:
> From: Mac Lin <mkl0301@gmail.com>
>
> CNS3xxx override the softreset function of ahci_platform ahci_softreset by
> cns3xxx_ahci_softreset, which would retry ahci_do_softreset again with pmp=0 if
> pmp=15 failed, for the controller has problem receiving D2H Reg FIS of the
> different PMP setting of the previous sent H2D Reg FIS.
>
> Following describe the isssue with original ahci_platform driver on
> linux-2.6.37-rc3, arm/cns3xxx.
>
> If CONFIG_SATA_PMP is enabled, while not using multiplier and connect the disks
> directly to the board, the disk cannot be found due to software reset always
> failed.
>
> ahci ahci.0: forcing PORTS_IMPL to 0x3
> ahci ahci.0: AHCI 0001.0100 32 slots 2 ports 3 Gbps 0x3 impl platform mode
> ahci ahci.0: flags: ncq sntf pm led clo only pmp pio slum part ccc
> scsi0 : ahci_platform
> scsi1 : ahci_platform
> ata1: SATA max UDMA/133 irq_stat 0x00400040, connection status changed irq 65
> ata2: SATA max UDMA/133 mmio [mem 0x83000000-0x83ffffff] port 0x180 irq 65
> ata2: SATA link down (SStatus 0 SControl 300)
> ata1: link is slow to respond, please be patient (ready=0)
> ata1: softreset failed (device not ready)
> ata1: link is slow to respond, please be patient (ready=0)
> ata1: softreset failed (device not ready)
> ata1: link is slow to respond, please be patient (ready=0)
> ata1: softreset failed (device not ready)
> ata1: limiting SATA link speed to 1.5 Gbps
> ata1: SATA link down (SStatus 1 SControl 310)
>
> While using multiplier with CONFIG_SATA_PMP enabled, or using disks directly
> without CONFIG_SATA_PMP have no issue. It seems the device is sending D2H Reg
> FIS, but controller is not reflecting it on any known means.
>
> Signed-off-by: Mac Lin <mkl0301@gmail.com>
I like this patch, thanks Mac! Few cosmetic comments below.
> ---
> arch/arm/mach-cns3xxx/devices.c | 2 +-
> drivers/ata/Kconfig | 11 +++++++
> drivers/ata/Makefile | 1 +
> drivers/ata/ahci_cns3xxx.c | 62 +++++++++++++++++++++++++++++++++++++++
> drivers/ata/ahci_pltfm.c | 3 ++
> drivers/ata/ahci_pltfm.h | 2 +
> 6 files changed, 80 insertions(+), 1 deletions(-)
> create mode 100644 drivers/ata/ahci_cns3xxx.c
>
> diff --git a/arch/arm/mach-cns3xxx/devices.c b/arch/arm/mach-cns3xxx/devices.c
> index 50b4d31..b496f02 100644
> --- a/arch/arm/mach-cns3xxx/devices.c
> +++ b/arch/arm/mach-cns3xxx/devices.c
> @@ -40,7 +40,7 @@ static struct resource cns3xxx_ahci_resource[] = {
> static u64 cns3xxx_ahci_dmamask = DMA_BIT_MASK(32);
>
> static struct platform_device cns3xxx_ahci_pdev = {
> - .name = "ahci",
> + .name = "ahci-cns3xxx",
> .id = 0,
> .resource = cns3xxx_ahci_resource,
> .num_resources = ARRAY_SIZE(cns3xxx_ahci_resource),
> diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
> index 36e2319..5d8b1a3 100644
> --- a/drivers/ata/Kconfig
> +++ b/drivers/ata/Kconfig
> @@ -75,6 +75,17 @@ config SATA_AHCI_PLATFORM
>
> If unsure, say N.
>
> +config SATA_AHCI_CNS3XXX
> + bool "AHCI Support on the Cavium Networks CNS3xxx SOC"
> + depends on ARCH_CNS3XXX
> + depends on SATA_AHCI_PLATFORM
> + help
> + This option enables AHCI platform driver to support CNS3xxx
> + System-on-Chip devices. This is only needed when using CNS3xxx AHCI
> + controller.
> +
> + If unsure, say N.
> +
> config SATA_FSL
> tristate "Freescale 3.0Gbps SATA support"
> depends on FSL_SOC
> diff --git a/drivers/ata/Makefile b/drivers/ata/Makefile
> index 5b62be8..a0745e5 100644
> --- a/drivers/ata/Makefile
> +++ b/drivers/ata/Makefile
> @@ -100,6 +100,7 @@ obj-$(CONFIG_PATA_LEGACY) += pata_legacy.o
>
> obj-$(CONFIG_SATA_AHCI_PLATFORM) += ahci_platform.o libahci.o
> ahci_platform-y := ahci_pltfm.o
> +ahci_platform-$(CONFIG_SATA_AHCI_CNS3XXX) += ahci_cns3xxx.o
>
> libata-y := libata-core.o libata-scsi.o libata-eh.o libata-transport.o
> libata-$(CONFIG_ATA_SFF) += libata-sff.o
> diff --git a/drivers/ata/ahci_cns3xxx.c b/drivers/ata/ahci_cns3xxx.c
> new file mode 100644
> index 0000000..f7a238e
> --- /dev/null
> +++ b/drivers/ata/ahci_cns3xxx.c
> @@ -0,0 +1,62 @@
> +/*
> + * AHCI support for CNS3xxx SoC
> + *
> + * Copyright 2010 MontaVista Software, LLC.
> + * Copyright 2010 Cavium Networks
> + *
> + * Authors: Anton Vorontsov <avorontsov@mvista.com>
> + * Mac Lin <mkl0301@gmail.com>
> + *
> + * 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 <linux/libata.h>
> +#include <linux/ahci_platform.h>
> +#include "ahci.h"
> +
> +static int cns3xxx_ahci_softreset(struct ata_link *link, unsigned int *class,
> + unsigned long deadline)
> +{
> + int pmp = sata_srst_pmp(link);
> + int ret;
> + DPRINTK("ENTER\n")
I'd remove this dprintk. Or at least, put an empty line after
'int ret;'
> +
> + ret = ahci_do_softreset(link, class, pmp, deadline, ahci_check_ready);
> + if (pmp && ret)
> + return ahci_do_softreset(link, class, 0, deadline,
> + ahci_check_ready);
> + else
> + return ret;
No need for 'else'
> +}
> +
> +static int cns3xxx_ahci_init(struct device *dev, void __iomem *addr)
> +{
> + /*
> + * TODO: move cns3xxx_ahci_init to here after cns3xxx_pwr*() calls are
> + * thread-safe
> + */
> +
> + return 0;
> +}
This is effectively no-op, just remove this function completely.
You may move the comment on top of the file, if you like.
> +static struct ata_port_operations cns3xxx_ahci_ops = {
> + .inherits = &ahci_ops,
> + .softreset = cns3xxx_ahci_softreset,
> +};
> +
> +static const struct ata_port_info cns3xxx_ata_port_info = {
> + .flags = AHCI_FLAG_COMMON,
> + .pio_mask = ATA_PIO4,
> + .udma_mask = ATA_UDMA6,
> + .port_ops = &cns3xxx_ahci_ops,
> +};
> +
> +struct ahci_platform_data cns3xxx_ahci_platform_data = {
> + .init = cns3xxx_ahci_init,
> + .ata_port_info = &cns3xxx_ata_port_info,
> + .force_port_map = 0,
> + .mask_port_map = 0,
You don't actually need to fill mask_port_map, as well as
force_port_map. cns3xxx_ahci_platform_data is global, thus will
initialize with zeroes.
> +};
> +
No need for this empty line (i.e. at the end of the file).
Thanks!
--
Anton Vorontsov
Email: cbouatmailru at gmail.com
^ permalink raw reply
* Current OMAP build failures
From: Russell King - ARM Linux @ 2011-01-06 11:03 UTC (permalink / raw)
To: linux-arm-kernel
I've observed the following issues while building 2.6.37 + my devel
branch. I don't believe any of them to be due to anything in my tree,
so would be in 2.6.37 as well.
=== omap1 ===
arch/arm/plat-omap/built-in.o: In function `omap2_i2c_add_bus':
arch/arm/plat-omap/i2c.c:169: undefined reference to `omap2_i2c_mux_pins'
$ grep omap2_i2c_mux_pins arch/arm/*omap* -r
arch/arm/mach-omap2/i2c.c:void __init omap2_i2c_mux_pins(int bus_id)
arch/arm/plat-omap/i2c.c: omap2_i2c_mux_pins(bus_id);
arch/arm/plat-omap/include/plat/i2c.h:void __init omap2_i2c_mux_pins(int bus_id);
So, OMAP1 doesn't provide this symbol.
=== omap2 ===
arch/arm/plat-omap/devices.c:253: warning: ?omap_init_wdt? defined but not used
arch/arm/mach-omap2/irq.c:64: warning: ?intc_context? defined but not used
arch/arm/mach-omap2/prcm.c:122: warning: ?prcm_context? defined but not used
Missing __maybe_unused or something else?
It also comes with three section mismatches:
WARNING: vmlinux.o(.text+0x1f4c4): Section mismatch in reference from the function omap_early_device_register() to the function .init.text:early_platform_add_devices()
The function omap_early_device_register() references
the function __init early_platform_add_devices().
This is often because omap_early_device_register lacks a __init
annotation or the annotation of early_platform_add_devices is wrong.
As early_platform_add_devices() is marked __init, so too should be
omap_early_device_register().
WARNING: vmlinux.o(.text+0x1f6bc): Section mismatch in reference from the function omap_device_build_ss() to the function .init.text:early_platform_add_devices()
The function omap_device_build_ss() references
the function __init early_platform_add_devices().
This is often because omap_device_build_ss lacks a __init
annotation or the annotation of early_platform_add_devices is wrong.
This looks like omap_early_device_register() has been inlined into
omap_device_build_ss(), and it doesn't look like it can be marked
__init.
Rather than passing an 'is_early_device' into this function, split
out the common code into a separate function which takes a function
pointer to the registration function. Then you can have two additional
functions, one marked __init which uses omap_early_device_register()
and one not marked __init using omap_device_register().
This also means that we get the init-section type checking further up
the chain.
WARNING: vmlinux.o(.data+0x6bd4): Section mismatch in reference from the variable h4_config to the (unknown reference) .init.data:(unknown)
The variable h4_config references
the (unknown reference) __initdata (unknown)
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
Maybe it shouldn't be marked __initdata?
=== omap3 ===
WARNING: vmlinux.o(.text+0x1b780): Section mismatch in reference from the function sdp3430_twl_gpio_setup() to the function .init.text:omap2_hsmmc_init()
The function sdp3430_twl_gpio_setup() references
the function __init omap2_hsmmc_init().
This is often because sdp3430_twl_gpio_setup lacks a __init
annotation or the annotation of omap2_hsmmc_init is wrong.
Missing __init on sdp3430_twl_gpio_setup ?
WARNING: vmlinux.o(.text+0x1f714): Section mismatch in reference from the function omap_early_device_register() to the function .init.text:early_platform_add_devices()
The function omap_early_device_register() references
the function __init early_platform_add_devices().
This is often because omap_early_device_register lacks a __init
annotation or the annotation of early_platform_add_devices is wrong.
As before.
WARNING: vmlinux.o(.text+0x1f90c): Section mismatch in reference from the function omap_device_build_ss() to the function .init.text:early_platform_add_devices()
The function omap_device_build_ss() references
the function __init early_platform_add_devices().
This is often because omap_device_build_ss lacks a __init
annotation or the annotation of early_platform_add_devices is wrong.
As before.
WARNING: vmlinux.o(.data+0x20670): Section mismatch in reference from the variable twl_driver to the function .init.text:twl_probe()
The variable twl_driver references
the function __init twl_probe()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
twl_probe shouldn't be __init ?
=== omap4 ===
Nothing apparantly new over omap3.
^ permalink raw reply
* [PATCH 1/1] arm: mxc: move IOMUX_CONFIG_SION definition to iomux-v3.h
From: Richard Zhao @ 2011-01-06 11:05 UTC (permalink / raw)
To: linux-arm-kernel
Signed-off-by: Richard Zhao <richard.zhao@freescale.com>
---
arch/arm/plat-mxc/include/mach/iomux-mx53.h | 1 -
arch/arm/plat-mxc/include/mach/iomux-v3.h | 1 +
2 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/plat-mxc/include/mach/iomux-mx53.h b/arch/arm/plat-mxc/include/mach/iomux-mx53.h
index 5deee01..2673007 100644
--- a/arch/arm/plat-mxc/include/mach/iomux-mx53.h
+++ b/arch/arm/plat-mxc/include/mach/iomux-mx53.h
@@ -34,7 +34,6 @@ typedef enum iomux_config {
IOMUX_CONFIG_ALT6,
IOMUX_CONFIG_ALT7,
IOMUX_CONFIG_GPIO, /* added to help user use GPIO mode */
- IOMUX_CONFIG_SION = 0x1 << 4, /* LOOPBACK:MUX SION bit */
} iomux_pin_cfg_t;
/* These 2 defines are for pins that may not have a mux register, but could
diff --git a/arch/arm/plat-mxc/include/mach/iomux-v3.h b/arch/arm/plat-mxc/include/mach/iomux-v3.h
index 2277b01..82620af 100644
--- a/arch/arm/plat-mxc/include/mach/iomux-v3.h
+++ b/arch/arm/plat-mxc/include/mach/iomux-v3.h
@@ -105,6 +105,7 @@ typedef u64 iomux_v3_cfg_t;
#define PAD_CTL_SRE_FAST (1 << 0)
#define PAD_CTL_SRE_SLOW (0 << 0)
+#define IOMUX_CONFIG_SION (0x1 << 4)
#define MX51_NUM_GPIO_PORT 4
--
1.6.3.3
^ permalink raw reply related
* [PATCH 3/6] i2c/pxa2xx: Add PCI support for PXA I2C controller
From: Russell King - ARM Linux @ 2011-01-06 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106105051.GA12146@www.tglx.de>
On Thu, Jan 06, 2011 at 11:50:51AM +0100, Sebastian Andrzej Siewior wrote:
> which functions are you talking about? I allocated one piece of memory
> which contained a platform device, ressources, platform data. It looked
> better than allocating multiple small chunks. I registered it with
> platform_device_register() and platform_device_unregister() complained
> about a missing ->release function.
Please see my email where I described the lifetime rules. Let's say
your module is removed. In doing so, you call platform_device_unregister()
followed by kfree(). After this, your module is removed from the system
and the memory backing the module code is unmapped.
If something holds a reference to the platform device, then that's just
waiting for an OOPS to happen. When those references are finally given
up, your release function will be called - but the code has been unmapped.
That's one source of OOPS. The second source of OOPS is that the platform
device will be dereferenced, but as you've already kfree'd it, the memory
could be used for some other purpose - in which case this manipulation of
what we think is still a platform device is going to corrupt some other
user.
If it hasn't been re-used, hopefully it's been poisoned, so you'll get
an OOPS from that instead.
^ permalink raw reply
* Hit BUG_ON in dma-mapping.c:425
From: Artem Bityutskiy @ 2011-01-06 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D259B9C.6060409@atmel.com>
On Thu, 2011-01-06 at 11:38 +0100, Nicolas Ferre wrote:
> (I include MTD mailing-list now)
>
> Le 05/01/2011 17:55, Russell King - ARM Linux :
> > On Wed, Jan 05, 2011 at 05:49:12PM +0100, Nicolas Ferre wrote:
> >> Hi,
> >>
> >> While running mtd_stresstest on a dataflash (atmel_spi
> >> + mtd_dataflash drivers) I hit the BUG_ON directive that
> >> is at the beginning of ___dma_single_cpu_to_dev() function.
> >> This function is called from the SPI driver that do a
> >> dma_map_single() before DMA operations on the buffer
> >> transmitted from upper layers.
> >>
> >> It seems that this address is above "high_memory" limit because
> >> it is allocated by vmalloc (in mtd_stresstest.c:285)...
> >
> > Well, its telling you is that you're not allowed to DMA to vmalloc
> > addresses. Whether that's the fault of the map driver or not is a
> > question for mtd folk.
>
> So you mean that those vmalloc calls should be changed to kmalloc in
> MTD like this:
>
> --- a/drivers/mtd/tests/mtd_stresstest.c
> +++ b/drivers/mtd/tests/mtd_stresstest.c
> @@ -26,7 +26,6 @@
> #include <linux/mtd/mtd.h>
> #include <linux/slab.h>
> #include <linux/sched.h>
> -#include <linux/vmalloc.h>
>
> #define PRINT_PREF KERN_INFO "mtd_stresstest: "
>
> @@ -281,8 +280,8 @@ static int __init mtd_stresstest_init(void)
> bufsize = mtd->erasesize * 2;
>
> err = -ENOMEM;
> - readbuf = vmalloc(bufsize);
> - writebuf = vmalloc(bufsize);
> + readbuf = kmalloc(bufsize, GFP_KERNEL);
> + writebuf = kmalloc(bufsize, GFP_KERNEL);
> offsets = kmalloc(ebcnt * sizeof(int), GFP_KERNEL);
> if (!readbuf || !writebuf || !offsets) {
> printk(PRINT_PREF "error: cannot allocate memory\n");
> @@ -313,8 +312,8 @@ static int __init mtd_stresstest_init(void)
> out:
> kfree(offsets);
> kfree(bbt);
> - vfree(writebuf);
> - vfree(readbuf);
> + kfree(writebuf);
> + kfree(readbuf);
> put_mtd_device(mtd);
> if (err)
> printk(PRINT_PREF "error %d occurred\n", err);
>
>
> I also discovered the same issue while trying to write with "dd"
> on /dev/mtdblockx
>
> Same vmalloc'ed memory seems to be used in mtdblock_writesect():
> mtdblk->cache_data = vmalloc(mtdblk->mbd.mtd->erasesize);
>
> I know that using "dd" on a block device is not the common case but it
> should work instead of not being able to transmit buffer with DMA...
> So what it implies to switch this to kmalloc? Is it regression-free to
> do this?
Unfortunatelly not. These are about allocating eraseblock-sized buffers,
which may be as large as 512KiB, and kmalloc can easily fail, this is
why vmalloc is used.
What you should do instead is to change the code and make it use smaller
kmalloc-ed buffers instead, in a loop. Or use an array of pointers, each
pointing to smaller buffers, and teach mtd to understand them. Then we
could reuse this infrastructure in UBI and UBIFS and JFFS2 as well.
--
Best Regards,
Artem Bityutskiy (???????? ?????)
^ permalink raw reply
* [PATCH] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling
From: Russell King - ARM Linux @ 2011-01-06 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <874o9mvpxf.fsf@ti.com>
On Wed, Jan 05, 2011 at 04:25:32PM -0800, Kevin Hilman wrote:
> As you likely noticed, removing the const leads to checkpatch warnings:
>
> WARNING: struct platform_suspend_ops should normally be const
>
> so the choice is between a checkpatch warning or a bunch of compiler
> warnings.
checkpatch should not be checking that data declarations are const.
That's a decision for those people declaring them to decide upon, as
they may need to modify the structure before registration.
By doing so, we end up encouraging people to write more code - such
as declaring it __initconst, and then kmalloc'ing, memcpy'ing and
modifying that before registering it.
> > -static struct platform_suspend_ops omap_pm_ops = {
> > - .begin = omap2_pm_begin,
> > - .enter = omap2_pm_enter,
> > - .end = omap2_pm_end,
> > - .valid = suspend_valid_only_mem,
> > +static const struct platform_suspend_ops omap_pm_ops[] = {
> > + {
> > + .begin = omap2_pm_begin,
> > + .enter = omap2_pm_enter,
> > + .end = omap2_pm_end,
> > + .valid = suspend_valid_only_mem,
> > + }
> > };
> > -#else
> > -static const struct platform_suspend_ops __initdata omap_pm_ops;
> > #endif /* CONFIG_SUSPEND */
> >
> > /* XXX This function should be shareable between OMAP2xxx and OMAP3 */
> > @@ -582,7 +582,7 @@ static int __init omap2_pm_init(void)
> > omap24xx_cpu_suspend_sz);
> > }
> >
> > - suspend_set_ops(&omap_pm_ops);
> > + suspend_set_ops(omap_pm_ops);
Utterly yuck. Declaring it as a single element array just to avoid an
ifdef. That's worse than having an ifdef here.
There's another solution. Don't mess about with sticking such stuff in
the header either.
#ifdef WHATEVER
static const struct platform_suspend_ops omap_pm_ops = {
.begin = omap2_pm_begin,
.enter = omap2_pm_enter,
.end = omap2_pm_end,
.valid = suspend_valid_only_mem,
};
#define PM_OPS omap_pm_ops
#else
#define PM_OPS NULL
#endif
...
suspend_set_ops(PM_OPS);
That keeps it all nice and local, and you can see exactly what's going on
without having it spread across many different random files.
^ permalink raw reply
* [PATCH 3/6] i2c/pxa2xx: Add PCI support for PXA I2C controller
From: Sebastian Andrzej Siewior @ 2011-01-06 11:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106111231.GD31708@n2100.arm.linux.org.uk>
* Russell King - ARM Linux | 2011-01-06 11:12:31 [+0000]:
>Please see my email where I described the lifetime rules. Let's say
>your module is removed. In doing so, you call platform_device_unregister()
>followed by kfree(). After this, your module is removed from the system
>and the memory backing the module code is unmapped.
>
>If something holds a reference to the platform device, then that's just
>waiting for an OOPS to happen. When those references are finally given
>up, your release function will be called - but the code has been unmapped.
I got that. That is why I'm going go to use allready provided functions
(platform_device_register_resndata() in this case) so I'm no longer
allocating any memory. So I'm only holding a struct which is pointing to
the platform_device. Everything else is unmapped by the driver core.
So I just have just to of_device_node_put() myself. Hmmm.
Grant, who is calling of_device_node_put() on nodes assigned in
of_register_spi_devices() & of_i2c_register_devices()? I can't find any
reference. The spi part is not putting the node or removing the irq
mapping in error case so I guess there must be some magic triggered
somewhere.
Also adap->dev.of_node and master->dev.of_node has to be
non-null for the device assignment to work. Who is putting these nodes
back? I see drivers (i2c-cpm & i2c-mpc) taking refs but I fail to find a
place where it is put back.
Sebastian
^ permalink raw reply
* [PATCH V2] ST SPEAr: PCIE gadget suppport
From: Viresh Kumar @ 2011-01-06 11:59 UTC (permalink / raw)
To: linux-arm-kernel
From: Pratyush Anand <pratyush.anand@st.com>
This is a configurable gadget. can be configured by sysfs interface. Any
IP available at PCIE bus can be programmed to be used by host
controller.It supoorts both INTX and MSI.
By default, gadget is configured for INTX and SYSRAM1 is mapped to BAR0
with size 0x1000
Changes since V1:
- __iomem added for register addresses
- kerneldoc comment removed whereever not required.
- help node moved from sysfs to documentation/misc-devices
- strict_strtoul used instead of sscanf
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Viresh Kumar <viresh.kumar@st.com>
---
Documentation/misc-devices/spear-pcie-gadget.txt | 125 ++++
drivers/misc/Kconfig | 10 +
drivers/misc/Makefile | 1 +
drivers/misc/spear13xx_pcie_gadget.c | 856 ++++++++++++++++++++++
4 files changed, 992 insertions(+), 0 deletions(-)
create mode 100644 Documentation/misc-devices/spear-pcie-gadget.txt
create mode 100644 drivers/misc/spear13xx_pcie_gadget.c
diff --git a/Documentation/misc-devices/spear-pcie-gadget.txt b/Documentation/misc-devices/spear-pcie-gadget.txt
new file mode 100644
index 0000000..8ade869
--- /dev/null
+++ b/Documentation/misc-devices/spear-pcie-gadget.txt
@@ -0,0 +1,125 @@
+Spear PCIE Gadget Driver:
+
+Author
+=============
+pratyush anand (pratyush.anand at st.com)
+
+Location
+============
+driver/misc/spear13xx_pcie_gadget.c
+
+Supported Chip:
+===================
+SPEAr1300
+SPEAr1310
+
+Menuconfig option:
+==========================
+Device Drivers
+ Misc devices
+ PCIE gadget support for SPEAr13XX platform
+purpose
+===========
+This driver has several nodes which can read/written by sysfs interface.
+Its main purpose is to configure selceted dual mode pcie controller as device
+and then program its various registers to configure it as a prticular device
+type. This driver can be used to show spear's pcie device capability.
+
+Description of different nodes:
+=================================
+
+read behaviour of nodes:
+------------------------------
+link :gives ltssm status.
+int_type :type of supported interrupt
+no_of_msi read :zero if MSI is not enabled by host.A positive value is the
+ number of MSI vector granted.
+vendor_id :returns programmed vendor id (hex)
+device_id :returns programmed device id(hex)
+bar0_size: :retruns size of bar0 in hex.
+bar0_address :returns address of bar0 mapped area in hex.
+bar0_rw_offset :returns offset of bar0 for which bar0_data will return value.
+bar0_data :returns data at bar0_rw_offset.
+
+write behaviour of nodes:
+------------------------------
+link :write UP to enable ltsmm DOWN to disable
+int_type :write interrupt type to be configured and (int_type could be
+ INTA, MSI or NO_INT).select MSI only when you have programmed
+ no_of_msi node.
+no_of_msi :number of MSI vector needed.
+inta :write 1 to assert INTA and 0 to de-assert.
+send_msi :write MSI vector to be send.
+vendor_id :write vendor id(hex) to be programmed.
+device_id :write device id(hex) to be programmed.
+bar0_size :write size of bar0 in hex. default bar0 size is 1000 (hex)
+ bytes.
+bar0_address :write address of bar0 mapped area in hex. (default mapping of
+ bar0 is SYSRAM1(E0800000).Aalways program bar size before bar
+ address. kernel might modify bar size and address to align. So
+ read back bar size and address after writing to cross check.
+bar0_rw_offset :write offset of bar0 for which bar0_data will write value.
+bar0_data :write data to be written at bar0_rw_offset.
+
+Node programming example
+===========================
+Programm all PCIE registers in such a way that when this device is connected
+to the pcie host, then host sees this device as 1MB RAM.
+
+program vendor id as 0x104a
+# echo 104A >> sys/devices/platform/pcie-gadget-spear.0/vendor_id
+
+program device id as 0xCD80
+# echo CD80 >> sys/devices/platform/pcie-gadget-spear.0/device_id
+
+program BAR0 size as 1MB
+# echo 100000 >> sys/devices/platform/pcie-gadget-spear.0/bar0_size
+
+check for programmed bar0 size
+# cat sys/devices/platform/pcie-gadget-spear.0/bar0_size
+
+program BAR0 Address as DDR (0x2100000).this is the physical address of
+memroy, which is to be made visible to pcie host.Similarly any other ip can
+also be made visible to pcie host.e.g if you program base address of UART as
+BAR0 address then when this device will be connected to a host, it will be
+seen as UART.
+# echo 2100000 >> sys/devices/platform/pcie-gadget-spear.0/bar0_address
+
+program interrupt type : INTA
+# echo INTA >> sys/devices/platform/pcie-gadget-spear.0/int_type
+
+go for link up now.
+# echo UP >> sys/devices/platform/pcie-gadget-spear.0/link
+
+It will have to be insured that, once link up is done on gadget then only host
+is started and start to search pcie devices on its port.
+
+/*wait till link is up*/
+# cat sys/devices/platform/pcie-gadget-spear.0/link
+wait till it returns UP.
+
+To assert INTA
+# echo 1 >> sys/devices/platform/pcie-gadget-spear.0/inta
+
+To de-assert INTA
+# echo 0 >> sys/devices/platform/pcie-gadget-spear.0/inta
+
+if MSI is to be used as interrupt, program no of msi vector needed (say4)
+# echo 4 >> sys/devices/platform/pcie-gadget-spear.0/no_of_msi
+
+select MSI as interrupt type
+# echo MSI >> sys/devices/platform/pcie-gadget-spear.0/int_type
+
+go for link up now
+# echo UP >> sys/devices/platform/pcie-gadget-spear.0/link
+
+wait till link is up
+# cat sys/devices/platform/pcie-gadget-spear.0/link
+wait till it returns UP.
+
+wait till msi is enabled
+# cat sys/devices/platform/pcie-gadget-spear.0/no_of_msi
+Should return 4 (number of requested MSI vector)
+
+to send msi vector 2
+# echo 2 >> sys/devices/platform/pcie-gadget-spear.0/send_msi
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 4d073f1..c364a9b 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -394,6 +394,16 @@ config DS1682
This driver can also be built as a module. If so, the module
will be called ds1682.
+config SPEAR13XX_PCIE_GADGET
+ bool "PCIE gadget support for SPEAr13XX platform"
+ depends on ARCH_SPEAR13XX
+ default n
+ help
+ This option enables gadget support for PCIE controller. If
+ board file defines any controller as PCIE endpoint then a sysfs
+ entry will be created for that controller. User can use these
+ sysfs node to configure PCIE EP as per his requirements.
+
config TI_DAC7512
tristate "Texas Instruments DAC7512"
depends on SPI && SYSFS
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 98009cc..c489536 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -37,6 +37,7 @@ obj-$(CONFIG_IWMC3200TOP) += iwmc3200top/
obj-$(CONFIG_HMC6352) += hmc6352.o
obj-y += eeprom/
obj-y += cb710/
+obj-$(CONFIG_SPEAR13XX_PCIE_GADGET) += spear13xx_pcie_gadget.o
obj-$(CONFIG_VMWARE_BALLOON) += vmw_balloon.o
obj-$(CONFIG_ARM_CHARLCD) += arm-charlcd.o
obj-$(CONFIG_PCH_PHUB) += pch_phub.o
diff --git a/drivers/misc/spear13xx_pcie_gadget.c b/drivers/misc/spear13xx_pcie_gadget.c
new file mode 100644
index 0000000..63f45b1
--- /dev/null
+++ b/drivers/misc/spear13xx_pcie_gadget.c
@@ -0,0 +1,856 @@
+/*
+ * drivers/misc/spear13xx_pcie_gadget.c
+ *
+ * Copyright (C) 2010 ST Microelectronics
+ * Pratyush Anand<pratyush.anand@st.com>
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/io.h>
+#include <linux/interrupt.h>
+#include <linux/irq.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/pci_regs.h>
+#include <linux/platform_device.h>
+#include <mach/misc_regs.h>
+#include <mach/pcie.h>
+
+#define IN0_MEM_SIZE (200 * 1024 * 1024 - 1)
+/* In current implementation address translation is done using IN0 only.
+ * So IN1 start address and IN0 end address has been kept same
+*/
+#define IN1_MEM_SIZE (0 * 1024 * 1024 - 1)
+#define IN_IO_SIZE (20 * 1024 * 1024 - 1)
+#define IN_CFG0_SIZE (12 * 1024 * 1024 - 1)
+#define IN_CFG1_SIZE (12 * 1024 * 1024 - 1)
+#define IN_MSG_SIZE (12 * 1024 * 1024 - 1)
+/* Keep default BAR size as 4K*/
+/* AORAM would be mapped by default*/
+#define INBOUND_ADDR_MASK (SPEAR13XX_SYSRAM1_SIZE - 1)
+
+#define INT_TYPE_NO_INT 0
+#define INT_TYPE_INTX 1
+#define INT_TYPE_MSI 2
+struct spear_pcie_gadget_config {
+ void __iomem *base;
+ void __iomem *va_app_base;
+ void __iomem *va_dbi_base;
+ char int_type[10];
+ unsigned long requested_msi;
+ u32 configured_msi;
+ u32 bar0_size;
+ u32 bar0_rw_offset;
+ u32 va_bar0_address;
+};
+
+static void enable_dbi_access(struct pcie_app_reg __iomem *app_reg)
+{
+ /* Enable DBI access */
+ writel(readl(&app_reg->slv_armisc) | (1 << AXI_OP_DBI_ACCESS_ID),
+ &app_reg->slv_armisc);
+ writel(readl(&app_reg->slv_awmisc) | (1 << AXI_OP_DBI_ACCESS_ID),
+ &app_reg->slv_awmisc);
+
+}
+
+static void disable_dbi_access(struct pcie_app_reg __iomem *app_reg)
+{
+ /* disable DBI access */
+ writel(readl(&app_reg->slv_armisc) & ~(1 << AXI_OP_DBI_ACCESS_ID),
+ &app_reg->slv_armisc);
+ writel(readl(&app_reg->slv_awmisc) & ~(1 << AXI_OP_DBI_ACCESS_ID),
+ &app_reg->slv_awmisc);
+
+}
+
+static void spear_dbi_read_reg(struct spear_pcie_gadget_config *config,
+ int where, int size, u32 *val)
+{
+ struct pcie_app_reg __iomem *app_reg
+ = (struct pcie_app_reg __iomem *) config->va_app_base;
+ u32 va_address;
+
+ /* Enable DBI access */
+ enable_dbi_access(app_reg);
+
+ va_address = (u32)config->va_dbi_base + (where & ~0x3);
+
+ *val = readl(va_address);
+
+ if (size == 1)
+ *val = (*val >> (8 * (where & 3))) & 0xff;
+ else if (size == 2)
+ *val = (*val >> (8 * (where & 3))) & 0xffff;
+
+ /* Disable DBI access */
+ disable_dbi_access(app_reg);
+}
+
+static void spear_dbi_write_reg(struct spear_pcie_gadget_config *config,
+ int where, int size, u32 val)
+{
+ struct pcie_app_reg __iomem *app_reg
+ = (struct pcie_app_reg __iomem *) config->va_app_base;
+ u32 va_address;
+
+ /* Enable DBI access */
+ enable_dbi_access(app_reg);
+
+ va_address = (u32)config->va_dbi_base + (where & ~0x3);
+
+ if (size == 4)
+ writel(val, va_address);
+ else if (size == 2)
+ writew(val, va_address + (where & 2));
+ else if (size == 1)
+ writeb(val, va_address + (where & 3));
+
+ /* Disable DBI access */
+ disable_dbi_access(app_reg);
+}
+
+#define PCI_FIND_CAP_TTL 48
+
+static int pci_find_own_next_cap_ttl(struct spear_pcie_gadget_config *config,
+ u32 pos, int cap, int *ttl)
+{
+ u32 id;
+
+ while ((*ttl)--) {
+ spear_dbi_read_reg(config, pos, 1, &pos);
+ if (pos < 0x40)
+ break;
+ pos &= ~3;
+ spear_dbi_read_reg(config, pos + PCI_CAP_LIST_ID, 1, &id);
+ if (id == 0xff)
+ break;
+ if (id == cap)
+ return pos;
+ pos += PCI_CAP_LIST_NEXT;
+ }
+ return 0;
+}
+
+static int pci_find_own_next_cap(struct spear_pcie_gadget_config *config,
+ u32 pos, int cap)
+{
+ int ttl = PCI_FIND_CAP_TTL;
+
+ return pci_find_own_next_cap_ttl(config, pos, cap, &ttl);
+}
+
+static int pci_find_own_cap_start(struct spear_pcie_gadget_config *config,
+ u8 hdr_type)
+{
+ u32 status;
+
+ spear_dbi_read_reg(config, PCI_STATUS, 2, &status);
+ if (!(status & PCI_STATUS_CAP_LIST))
+ return 0;
+
+ switch (hdr_type) {
+ case PCI_HEADER_TYPE_NORMAL:
+ case PCI_HEADER_TYPE_BRIDGE:
+ return PCI_CAPABILITY_LIST;
+ case PCI_HEADER_TYPE_CARDBUS:
+ return PCI_CB_CAPABILITY_LIST;
+ default:
+ return 0;
+ }
+
+ return 0;
+}
+
+/*
+ * Tell if a device supports a given PCI capability.
+ * Returns the address of the requested capability structure within the
+ * device's PCI configuration space or 0 in case the device does not
+ * support it. Possible values for @cap:
+ *
+ * %PCI_CAP_ID_PM Power Management
+ * %PCI_CAP_ID_AGP Accelerated Graphics Port
+ * %PCI_CAP_ID_VPD Vital Product Data
+ * %PCI_CAP_ID_SLOTID Slot Identification
+ * %PCI_CAP_ID_MSI Message Signalled Interrupts
+ * %PCI_CAP_ID_CHSWP CompactPCI HotSwap
+ * %PCI_CAP_ID_PCIX PCI-X
+ * %PCI_CAP_ID_EXP PCI Express
+ */
+static int pci_find_own_capability(struct spear_pcie_gadget_config *config,
+ int cap)
+{
+ u32 pos;
+ u32 hdr_type;
+
+ spear_dbi_read_reg(config, PCI_HEADER_TYPE, 1, &hdr_type);
+
+ pos = pci_find_own_cap_start(config, hdr_type);
+ if (pos)
+ pos = pci_find_own_next_cap(config, pos, cap);
+
+ return pos;
+}
+
+static irqreturn_t spear_pcie_gadget_irq(int irq, void *dev_id)
+{
+ return 0;
+}
+
+static ssize_t pcie_gadget_show_link(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ struct pcie_app_reg __iomem *app_reg =
+ (struct pcie_app_reg __iomem *)config->va_app_base;
+
+ if (readl(&app_reg->app_status_1) & ((u32)1 << XMLH_LINK_UP_ID))
+ return sprintf(buf, "UP");
+ else
+ return sprintf(buf, "DOWN");
+}
+
+static ssize_t pcie_gadget_store_link(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ struct pcie_app_reg __iomem *app_reg =
+ (struct pcie_app_reg __iomem *)config->va_app_base;
+ char link[10];
+
+ if (strlen(buf) >= 10)
+ return -EINVAL;
+
+ if (sscanf(buf, "%s", link) != 1)
+ return -EINVAL;
+
+ if (!strcmp(link, "UP"))
+ writel(readl(&app_reg->app_ctrl_0) | (1 << APP_LTSSM_ENABLE_ID),
+ &app_reg->app_ctrl_0);
+ else
+ writel(readl(&app_reg->app_ctrl_0)
+ & ~(1 << APP_LTSSM_ENABLE_ID),
+ &app_reg->app_ctrl_0);
+ return count;
+}
+
+static DEVICE_ATTR(link, S_IWUSR | S_IRUGO, pcie_gadget_show_link,
+ pcie_gadget_store_link);
+
+static ssize_t pcie_gadget_show_int_type(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%s", config->int_type);
+}
+
+static ssize_t pcie_gadget_store_int_type(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ char int_type[10];
+ u32 cap, vec, flags;
+ unsigned long vector;
+
+ if (strlen(buf) >= 10)
+ return -EINVAL;
+
+ if (sscanf(buf, "%s", int_type) != 1)
+ return -EINVAL;
+
+ if (!strcmp(int_type, "INTA"))
+ spear_dbi_write_reg(config, PCI_INTERRUPT_LINE, 1, 1);
+
+ else if (!strcmp(int_type, "MSI")) {
+ vector = config->requested_msi;
+ vec = 0;
+ while (vector > 1) {
+ vector /= 2;
+ vec++;
+ }
+ spear_dbi_write_reg(config, PCI_INTERRUPT_LINE, 1, 0);
+ cap = pci_find_own_capability(config, PCI_CAP_ID_MSI);
+ spear_dbi_read_reg(config, cap + PCI_MSI_FLAGS, 1, &flags);
+ flags &= ~PCI_MSI_FLAGS_QMASK;
+ flags |= vec << 1;
+ spear_dbi_write_reg(config, cap + PCI_MSI_FLAGS, 1, flags);
+ } else
+ return -EINVAL;
+
+ strcpy(config->int_type, int_type);
+
+ return count;
+}
+
+static DEVICE_ATTR(int_type, S_IWUSR | S_IRUGO, pcie_gadget_show_int_type,
+ pcie_gadget_store_int_type);
+
+static ssize_t pcie_gadget_show_no_of_msi(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ struct pcie_app_reg __iomem *app_reg =
+ (struct pcie_app_reg __iomem *)config->va_app_base;
+ u32 cap, vector, vec, flags;
+
+ if ((readl(&app_reg->msg_status) & (1 << CFG_MSI_EN_ID))
+ != (1 << CFG_MSI_EN_ID))
+ vector = 0;
+ else {
+ cap = pci_find_own_capability(config, PCI_CAP_ID_MSI);
+ spear_dbi_read_reg(config, cap + PCI_MSI_FLAGS, 1, &flags);
+ flags &= ~PCI_MSI_FLAGS_QSIZE;
+ vec = flags >> 4;
+ vector = 1;
+ while (vec--)
+ vector *= 2;
+ }
+ config->configured_msi = vector;
+
+ return sprintf(buf, "%u", vector);
+}
+
+static ssize_t pcie_gadget_store_no_of_msi(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+
+ if (strict_strtoul(buf, 0, &config->requested_msi))
+ return -EINVAL;
+ if (config->requested_msi > 32)
+ config->requested_msi = 32;
+
+ return count;
+}
+
+static DEVICE_ATTR(no_of_msi, S_IWUSR | S_IRUGO, pcie_gadget_show_no_of_msi,
+ pcie_gadget_store_no_of_msi);
+
+static ssize_t pcie_gadget_store_inta(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ struct pcie_app_reg __iomem *app_reg =
+ (struct pcie_app_reg __iomem *)config->va_app_base;
+ unsigned long en;
+
+ if (strict_strtoul(buf, 0, &en))
+ return -EINVAL;
+
+ if (en)
+ writel(readl(&app_reg->app_ctrl_0) | (1 << SYS_INT_ID),
+ &app_reg->app_ctrl_0);
+ else
+ writel(readl(&app_reg->app_ctrl_0) & ~(1 << SYS_INT_ID),
+ &app_reg->app_ctrl_0);
+
+ return count;
+}
+
+static DEVICE_ATTR(inta, S_IWUSR, NULL, pcie_gadget_store_inta);
+
+static ssize_t pcie_gadget_store_send_msi(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ struct pcie_app_reg __iomem *app_reg =
+ (struct pcie_app_reg __iomem *)config->va_app_base;
+ unsigned long vector;
+ u32 ven_msi;
+
+ if (strict_strtoul(buf, 0, &vector))
+ return -EINVAL;
+
+ if (!config->configured_msi)
+ return -EINVAL;
+
+ if (vector >= config->configured_msi)
+ return -EINVAL;
+
+ ven_msi = readl(&app_reg->ven_msi_1);
+ ven_msi &= ~VEN_MSI_FUN_NUM_MASK;
+ ven_msi |= 0 << VEN_MSI_FUN_NUM_ID;
+ ven_msi &= ~VEN_MSI_TC_MASK;
+ ven_msi |= 0 << VEN_MSI_TC_ID;
+ ven_msi &= ~VEN_MSI_VECTOR_MASK;
+ ven_msi |= vector << VEN_MSI_VECTOR_ID;
+
+ /*generating interrupt for msi vector*/
+ ven_msi |= VEN_MSI_REQ_EN;
+ writel(ven_msi, &app_reg->ven_msi_1);
+ /*need to wait till this bit is cleared, it is not cleared
+ * autometically[Bug RTL] TBD*/
+ udelay(1);
+ ven_msi &= ~VEN_MSI_REQ_EN;
+ writel(ven_msi, &app_reg->ven_msi_1);
+
+ return count;
+}
+
+static DEVICE_ATTR(send_msi, S_IWUSR, NULL, pcie_gadget_store_send_msi);
+
+static ssize_t pcie_gadget_show_vendor_id(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ u32 id;
+
+ spear_dbi_read_reg(config, PCI_VENDOR_ID, 2, &id);
+
+ return sprintf(buf, "%x", id);
+}
+
+static ssize_t pcie_gadget_store_vendor_id(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ unsigned long id;
+
+ if (strict_strtoul(buf, 0, &id))
+ return -EINVAL;
+
+ spear_dbi_write_reg(config, PCI_VENDOR_ID, 2, id);
+
+ return count;
+}
+
+static DEVICE_ATTR(vendor_id, S_IWUSR | S_IRUGO, pcie_gadget_show_vendor_id,
+ pcie_gadget_store_vendor_id);
+
+static ssize_t pcie_gadget_show_device_id(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ u32 id;
+
+ spear_dbi_read_reg(config, PCI_DEVICE_ID, 2, &id);
+
+ return sprintf(buf, "%x", id);
+}
+
+static ssize_t pcie_gadget_store_device_id(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ unsigned long id;
+
+ if (strict_strtoul(buf, 0, &id))
+ return -EINVAL;
+
+ spear_dbi_write_reg(config, PCI_DEVICE_ID, 2, id);
+
+ return count;
+}
+
+static DEVICE_ATTR(device_id, S_IWUSR | S_IRUGO, pcie_gadget_show_device_id,
+ pcie_gadget_store_device_id);
+
+static ssize_t pcie_gadget_show_bar0_size(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%x", config->bar0_size);
+}
+
+static ssize_t pcie_gadget_store_bar0_size(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ unsigned long size;
+ u32 pos, pos1;
+ u32 no_of_bit = 0;
+
+ if (strict_strtoul(buf, 0, &size))
+ return -EINVAL;
+ /* as per PCIE specs, min bar size supported is 128 bytes. But
+ * our controller supports min as 256*/
+ if (size <= 0x100)
+ size = 0x100;
+ /* max bar size is 1MB*/
+ else if (size >= 0x100000)
+ size = 0x100000;
+ else {
+ pos = 0;
+ pos1 = 0;
+ while (pos < 21) {
+ pos = find_next_bit((unsigned long *)&size, 21, pos);
+ if (pos != 21)
+ pos1 = pos + 1;
+ pos++;
+ no_of_bit++;
+ }
+ if (no_of_bit == 2)
+ pos1--;
+
+ size = 1 << pos1;
+ }
+ config->bar0_size = size;
+ spear_dbi_write_reg(config, PCIE_BAR0_MASK_REG, 4, size - 1);
+
+ return count;
+}
+
+static DEVICE_ATTR(bar0_size, S_IWUSR | S_IRUGO, pcie_gadget_show_bar0_size,
+ pcie_gadget_store_bar0_size);
+
+static ssize_t pcie_gadget_show_bar0_address(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ struct pcie_app_reg __iomem *app_reg =
+ (struct pcie_app_reg __iomem *)config->va_app_base;
+
+ u32 address = readl(&app_reg->pim0_mem_addr_start);
+
+ return sprintf(buf, "%x", address);
+}
+
+static ssize_t pcie_gadget_store_bar0_address(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ struct pcie_app_reg __iomem *app_reg =
+ (struct pcie_app_reg __iomem *)config->va_app_base;
+ unsigned long address;
+
+ if (strict_strtoul(buf, 0, &address))
+ return -EINVAL;
+
+ address &= ~(config->bar0_size - 1);
+ if (config->va_bar0_address)
+ iounmap((void *)config->va_bar0_address);
+ config->va_bar0_address = (u32)ioremap(address, config->bar0_size);
+ if (!config->va_bar0_address)
+ return -ENOMEM;
+
+ writel(address, &app_reg->pim0_mem_addr_start);
+
+ return count;
+}
+
+static DEVICE_ATTR(bar0_address, S_IWUSR | S_IRUGO,
+ pcie_gadget_show_bar0_address, pcie_gadget_store_bar0_address);
+
+static ssize_t pcie_gadget_show_bar0_rw_offset(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+
+ return sprintf(buf, "%x", config->bar0_rw_offset);
+}
+
+static ssize_t pcie_gadget_store_bar0_rw_offset(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ unsigned long offset;
+
+ if (strict_strtoul(buf, 0, &offset))
+ return -EINVAL;
+
+ if (offset % 4)
+ return -EINVAL;
+
+ config->bar0_rw_offset = offset;
+
+ return count;
+}
+
+static DEVICE_ATTR(bar0_rw_offset, S_IWUSR | S_IRUGO,
+ pcie_gadget_show_bar0_rw_offset, pcie_gadget_store_bar0_rw_offset);
+
+static ssize_t pcie_gadget_show_bar0_data(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ u32 data;
+
+ if (!config->va_bar0_address)
+ return -ENOMEM;
+
+ data = readl(config->va_bar0_address + config->bar0_rw_offset);
+
+ return sprintf(buf, "%x", data);
+}
+
+static ssize_t pcie_gadget_store_bar0_data(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ struct spear_pcie_gadget_config *config = dev_get_drvdata(dev);
+ unsigned long data;
+
+ if (strict_strtoul(buf, 0, &data))
+ return -EINVAL;
+
+ if (!config->va_bar0_address)
+ return -ENOMEM;
+
+ writel(data, config->va_bar0_address + config->bar0_rw_offset);
+
+ return count;
+}
+
+static DEVICE_ATTR(bar0_data, S_IWUSR | S_IRUGO,
+ pcie_gadget_show_bar0_data, pcie_gadget_store_bar0_data);
+
+static struct attribute *pcie_gadget_attributes[] = {
+ &dev_attr_link.attr,
+ &dev_attr_int_type.attr,
+ &dev_attr_no_of_msi.attr,
+ &dev_attr_inta.attr,
+ &dev_attr_send_msi.attr,
+ &dev_attr_vendor_id.attr,
+ &dev_attr_device_id.attr,
+ &dev_attr_bar0_size.attr,
+ &dev_attr_bar0_address.attr,
+ &dev_attr_bar0_rw_offset.attr,
+ &dev_attr_bar0_data.attr,
+ NULL
+};
+
+static const struct attribute_group pcie_gadget_attr_group = {
+ .attrs = pcie_gadget_attributes,
+};
+
+static void spear13xx_pcie_device_init(struct spear_pcie_gadget_config *config)
+{
+ struct pcie_app_reg __iomem *app_reg =
+ (struct pcie_app_reg __iomem *)config->va_app_base;
+
+ /*setup registers for outbound translation */
+
+ writel(config->base, &app_reg->in0_mem_addr_start);
+ writel(app_reg->in0_mem_addr_start + IN0_MEM_SIZE,
+ &app_reg->in0_mem_addr_limit);
+ writel(app_reg->in0_mem_addr_limit + 1, &app_reg->in1_mem_addr_start);
+ writel(app_reg->in1_mem_addr_start + IN1_MEM_SIZE,
+ &app_reg->in1_mem_addr_limit);
+ writel(app_reg->in1_mem_addr_limit + 1, &app_reg->in_io_addr_start);
+ writel(app_reg->in_io_addr_start + IN_IO_SIZE,
+ &app_reg->in_io_addr_limit);
+ writel(app_reg->in_io_addr_limit + 1, &app_reg->in_cfg0_addr_start);
+ writel(app_reg->in_cfg0_addr_start + IN_CFG0_SIZE,
+ &app_reg->in_cfg0_addr_limit);
+ writel(app_reg->in_cfg0_addr_limit + 1, &app_reg->in_cfg1_addr_start);
+ writel(app_reg->in_cfg1_addr_start + IN_CFG1_SIZE,
+ &app_reg->in_cfg1_addr_limit);
+ writel(app_reg->in_cfg1_addr_limit + 1, &app_reg->in_msg_addr_start);
+ writel(app_reg->in_msg_addr_start + IN_MSG_SIZE,
+ &app_reg->in_msg_addr_limit);
+
+ writel(app_reg->in0_mem_addr_start, &app_reg->pom0_mem_addr_start);
+ writel(app_reg->in1_mem_addr_start, &app_reg->pom1_mem_addr_start);
+ writel(app_reg->in_io_addr_start, &app_reg->pom_io_addr_start);
+
+ /*setup registers for inbound translation */
+
+ /* Keep AORAM mapped at BAR0 as default */
+ config->bar0_size = INBOUND_ADDR_MASK + 1;
+ spear_dbi_write_reg(config, PCIE_BAR0_MASK_REG, 4, INBOUND_ADDR_MASK);
+ spear_dbi_write_reg(config, PCI_BASE_ADDRESS_0, 4, 0xC);
+ config->va_bar0_address = (u32)ioremap(SPEAR13XX_SYSRAM1_BASE,
+ config->bar0_size);
+
+ writel(SPEAR13XX_SYSRAM1_BASE, &app_reg->pim0_mem_addr_start);
+ writel(0, &app_reg->pim1_mem_addr_start);
+ writel(INBOUND_ADDR_MASK + 1, &app_reg->mem0_addr_offset_limit);
+
+ writel(0x0, &app_reg->pim_io_addr_start);
+ writel(0x0, &app_reg->pim_io_addr_start);
+ writel(0x0, &app_reg->pim_rom_addr_start);
+
+ writel(DEVICE_TYPE_EP | (1 << MISCTRL_EN_ID)
+ | ((u32)1 << REG_TRANSLATION_ENABLE),
+ &app_reg->app_ctrl_0);
+ /* disable all rx interrupts */
+ writel(0, &app_reg->int_mask);
+
+ /* Select INTA as default*/
+ spear_dbi_write_reg(config, PCI_INTERRUPT_LINE, 1, 1);
+}
+
+static int __devinit spear_pcie_gadget_probe(struct platform_device *pdev)
+{
+ struct resource *res0, *res1;
+ struct spear_pcie_gadget_config *config;
+ unsigned int status = 0;
+ int irq;
+ struct clk *clk;
+
+ /* get resource for application registers*/
+
+ res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!res0) {
+ dev_err(&pdev->dev, "no resource defined\n");
+ return -EBUSY;
+ }
+ if (!request_mem_region(res0->start, resource_size(res0),
+ pdev->name)) {
+ dev_err(&pdev->dev, "pcie gadget region already claimed\n");
+ return -EBUSY;
+ }
+ /* get resource for dbi registers*/
+
+ res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ if (!res1) {
+ dev_err(&pdev->dev, "no resource defined\n");
+ goto err_rel_res0;
+ }
+ if (!request_mem_region(res1->start, resource_size(res1),
+ pdev->name)) {
+ dev_err(&pdev->dev, "pcie gadget region already claimed\n");
+ goto err_rel_res0;
+ }
+
+ config = kzalloc(sizeof(*config), GFP_KERNEL);
+ if (!config) {
+ dev_err(&pdev->dev, "out of memory\n");
+ status = -ENOMEM;
+ goto err_rel_res;
+ }
+
+ config->va_app_base = (void __iomem *)ioremap(res0->start,
+ resource_size(res0));
+ if (!config->va_app_base) {
+ dev_err(&pdev->dev, "ioremap fail\n");
+ status = -ENOMEM;
+ goto err_kzalloc;
+ }
+
+ config->base = (void __iomem *)res1->start;
+
+ config->va_dbi_base = (void __iomem *)ioremap(res1->start,
+ resource_size(res1));
+ if (!config->va_dbi_base) {
+ dev_err(&pdev->dev, "ioremap fail\n");
+ status = -ENOMEM;
+ goto err_iounmap_app;
+ }
+
+ dev_set_drvdata(&pdev->dev, config);
+
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
+ dev_err(&pdev->dev, "no update irq?\n");
+ status = irq;
+ goto err_iounmap;
+ }
+
+ status = request_irq(irq, spear_pcie_gadget_irq, 0, pdev->name, NULL);
+ if (status) {
+ dev_err(&pdev->dev, "pcie gadget interrupt IRQ%d already \
+ claimed\n", irq);
+ goto err_get_irq;
+ }
+ /* Register sysfs hooks */
+ status = sysfs_create_group(&pdev->dev.kobj, &pcie_gadget_attr_group);
+ if (status)
+ goto err_irq;
+
+ /* init basic pcie application registers*/
+ /* do not enable clock if it is PCIE0.Ideally , all controller should
+ * have been independent from others with respect to clock. But PCIE1
+ * and 2 depends on PCIE0.So PCIE0 clk is provided during board init.*/
+ if (pdev->id == 1) {
+ /* Ideally CFG Clock should have been also enabled here. But
+ * it is done currently during board init routne*/
+ clk = clk_get_sys("pcie1", NULL);
+ if (!clk) {
+ pr_err("%s:couldn't get clk for pcie1\n", __func__);
+ goto err_irq;
+ }
+ if (clk_enable(clk)) {
+ pr_err("%s:couldn't enable clk for pcie1\n", __func__);
+ goto err_irq;
+ }
+ } else if (pdev->id == 2) {
+ /* Ideally CFG Clock should have been also enabled here. But
+ * it is done currently during board init routne*/
+ clk = clk_get_sys("pcie2", NULL);
+ if (!clk) {
+ pr_err("%s:couldn't get clk for pcie2\n", __func__);
+ goto err_irq;
+ }
+ if (clk_enable(clk)) {
+ pr_err("%s:couldn't enable clk for pcie2\n", __func__);
+ goto err_irq;
+ }
+ }
+ spear13xx_pcie_device_init(config);
+
+ return 0;
+err_irq:
+ free_irq(irq, NULL);
+err_get_irq:
+ dev_set_drvdata(&pdev->dev, NULL);
+err_iounmap:
+ iounmap(config->va_dbi_base);
+err_iounmap_app:
+ iounmap(config->va_app_base);
+err_kzalloc:
+ kfree(config);
+err_rel_res:
+ release_mem_region(res1->start, resource_size(res1));
+err_rel_res0:
+ release_mem_region(res0->start, resource_size(res0));
+ return status;
+}
+
+static int __devexit spear_pcie_gadget_remove(struct platform_device *pdev)
+{
+ struct resource *res0, *res1;
+ struct spear_pcie_gadget_config *config;
+ int irq;
+
+ res0 = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ res1 = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ irq = platform_get_irq(pdev, 0);
+ config = dev_get_drvdata(&pdev->dev);
+
+ free_irq(irq, NULL);
+ dev_set_drvdata(&pdev->dev, NULL);
+ iounmap(config->va_dbi_base);
+ iounmap(config->va_app_base);
+ kfree(config);
+ release_mem_region(res1->start, resource_size(res1));
+ release_mem_region(res0->start, resource_size(res0));
+ sysfs_remove_group(&pdev->dev.kobj, &pcie_gadget_attr_group);
+
+ return 0;
+}
+
+static void spear_pcie_gadget_shutdown(struct platform_device *pdev)
+{
+}
+
+static struct platform_driver spear_pcie_gadget_driver = {
+ .probe = spear_pcie_gadget_probe,
+ .remove = spear_pcie_gadget_remove,
+ .shutdown = spear_pcie_gadget_shutdown,
+ .driver = {
+ .name = "pcie-gadget-spear",
+ .bus = &platform_bus_type
+ },
+};
+
+static int __init spear_pcie_gadget_init(void)
+{
+ return platform_driver_register(&spear_pcie_gadget_driver);
+}
+module_init(spear_pcie_gadget_init);
+
+static void __exit spear_pcie_gadget_exit(void)
+{
+ platform_driver_unregister(&spear_pcie_gadget_driver);
+}
+module_exit(spear_pcie_gadget_exit);
+
+MODULE_ALIAS("pcie-gadget-spear");
+MODULE_AUTHOR("Pratyush Anand");
+MODULE_LICENSE("GPL");
--
1.7.2.2
^ permalink raw reply related
* [PATCH] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling
From: aaro.koskinen at nokia.com @ 2011-01-06 12:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106111957.GA1198@n2100.arm.linux.org.uk>
Hi,
Russell King - ARM Linux [linux at arm.linux.org.uk]:
> > > -static struct platform_suspend_ops omap_pm_ops = {
> > > - .begin = omap2_pm_begin,
> > > - .enter = omap2_pm_enter,
> > > - .end = omap2_pm_end,
> > > - .valid = suspend_valid_only_mem,
> > > +static const struct platform_suspend_ops omap_pm_ops[] = {
> > > + {
> > > + .begin = omap2_pm_begin,
> > > + .enter = omap2_pm_enter,
> > > + .end = omap2_pm_end,
> > > + .valid = suspend_valid_only_mem,
> > > + }
> > > };
> > > -#else
> > > -static const struct platform_suspend_ops __initdata omap_pm_ops;
> > > #endif /* CONFIG_SUSPEND */
> > >
> > > /* XXX This function should be shareable between OMAP2xxx and OMAP3 */
> > > @@ -582,7 +582,7 @@ static int __init omap2_pm_init(void)
> > > omap24xx_cpu_suspend_sz);
> > > }
> > >
> > > - suspend_set_ops(&omap_pm_ops);
> > > + suspend_set_ops(omap_pm_ops);
>
> Utterly yuck. Declaring it as a single element array just to avoid an
> ifdef. That's worse than having an ifdef here.
Why it is worse? Reducing the amount of different preprocessor branches will
result in better compile test / static analysis coverage.
> There's another solution. Don't mess about with sticking such stuff in
> the header either.
>
> #ifdef WHATEVER
> static const struct platform_suspend_ops omap_pm_ops = {
> .begin = omap2_pm_begin,
> .enter = omap2_pm_enter,
> .end = omap2_pm_end,
> .valid = suspend_valid_only_mem,
> };
> #define PM_OPS omap_pm_ops
> #else
> #define PM_OPS NULL
> #endif
> ...
>
> suspend_set_ops(PM_OPS);
>
> That keeps it all nice and local, and you can see exactly what's going on
> without having it spread across many different random files.
I don't think it's obviously better or simpler. There's already made a mistake in
your example...
A.
^ permalink raw reply
* Current OMAP build failures
From: Santosh Shilimkar @ 2011-01-06 12:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106110336.GC31708@n2100.arm.linux.org.uk>
Russell,
> -----Original Message-----
> From: linux-omap-owner at vger.kernel.org [mailto:linux-omap-
> owner at vger.kernel.org] On Behalf Of Russell King - ARM Linux
> Sent: Thursday, January 06, 2011 4:34 PM
> To: Tony Lindgren
> Cc: linux-omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org
> Subject: Current OMAP build failures
>
Have you used any custom build/ additional build flags
for omap2/3/4 reported issues ?
I just rebased Tony's 'omap-for-linus' branch with 2.6.37 and
it not seems to report below issues. May be it's getting
fixed as part of 2.6.38 omap queue or my build config is
not same as yours. I used omap2plus_defconfig.
> === omap2 ===
> arch/arm/plat-omap/devices.c:253: warning: ?omap_init_wdt? defined
> but not used
> arch/arm/mach-omap2/irq.c:64: warning: ?intc_context? defined but
> not used
> arch/arm/mach-omap2/prcm.c:122: warning: ?prcm_context? defined but
> not used
>
> Missing __maybe_unused or something else?
These seems to be fixed in omap queue.
>
> It also comes with three section mismatches:
>
> WARNING: vmlinux.o(.text+0x1f4c4): Section mismatch in reference
> from the function omap_early_device_register() to the function
> .init.text:early_platform_add_devices()
> The function omap_early_device_register() references
> the function __init early_platform_add_devices().
> This is often because omap_early_device_register lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> As early_platform_add_devices() is marked __init, so too should be
> omap_early_device_register().
I don't see this one. May be fixed
>
> WARNING: vmlinux.o(.text+0x1f6bc): Section mismatch in reference
> from the function omap_device_build_ss() to the function
> .init.text:early_platform_add_devices()
> The function omap_device_build_ss() references
> the function __init early_platform_add_devices().
> This is often because omap_device_build_ss lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> This looks like omap_early_device_register() has been inlined into
> omap_device_build_ss(), and it doesn't look like it can be marked
> __init.
>
> Rather than passing an 'is_early_device' into this function, split
> out the common code into a separate function which takes a function
> pointer to the registration function. Then you can have two
> additional
> functions, one marked __init which uses omap_early_device_register()
> and one not marked __init using omap_device_register().
>
> This also means that we get the init-section type checking further
> up
> the chain.
This too
>
> WARNING: vmlinux.o(.data+0x6bd4): Section mismatch in reference from
> the variable h4_config to the (unknown reference)
> .init.data:(unknown)
> The variable h4_config references
> the (unknown reference) __initdata (unknown)
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the
> variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> Maybe it shouldn't be marked __initdata?
This too
>
> === omap3 ===
> WARNING: vmlinux.o(.text+0x1b780): Section mismatch in reference
> from the function sdp3430_twl_gpio_setup() to the function
> .init.text:omap2_hsmmc_init()
> The function sdp3430_twl_gpio_setup() references
> the function __init omap2_hsmmc_init().
> This is often because sdp3430_twl_gpio_setup lacks a __init
> annotation or the annotation of omap2_hsmmc_init is wrong.
>
> Missing __init on sdp3430_twl_gpio_setup ?
This too
>
> WARNING: vmlinux.o(.text+0x1f714): Section mismatch in reference
> from the function omap_early_device_register() to the function
> .init.text:early_platform_add_devices()
> The function omap_early_device_register() references
> the function __init early_platform_add_devices().
> This is often because omap_early_device_register lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> As before.
This too
>
> WARNING: vmlinux.o(.text+0x1f90c): Section mismatch in reference
> from the function omap_device_build_ss() to the function
> .init.text:early_platform_add_devices()
> The function omap_device_build_ss() references
> the function __init early_platform_add_devices().
> This is often because omap_device_build_ss lacks a __init
> annotation or the annotation of early_platform_add_devices is wrong.
>
> As before.
This too
>
> WARNING: vmlinux.o(.data+0x20670): Section mismatch in reference
> from the variable twl_driver to the function .init.text:twl_probe()
> The variable twl_driver references
> the function __init twl_probe()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the
> variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console,
>
> twl_probe shouldn't be __init ?
>
I only see the twl_probe section miss-match. Have attached full build
log for reference.
Regards,
Santosh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.6.37_omap_for_linus.tar.bz2
Type: application/octet-stream
Size: 8378 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110106/5786427a/attachment.obj>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox