* Re: [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related
@ 2010-09-07 19:26 David Cross
2010-09-07 23:58 ` Greg KH
0 siblings, 1 reply; 6+ messages in thread
From: David Cross @ 2010-09-07 19:26 UTC (permalink / raw)
To: tony; +Cc: greg, linux-kernel, linux-omap
This patch exports some of the gpmc driver functions in OMAP3. The purpose behind this patch
is to allow device drivers compiled as loadable modules to be interfaced to the GPMC. I am
hoping that Tony is the correct maintainer and willing to ACK this change. Please let me know
if there are any issues or concerns with this patch.
Thanks,
David
Signed-off-by: David Cross <david.cross@cypress.com>
diff -uprN -X linux-next-vanilla/Documentation/dontdiff linux-next-vanilla/arch/arm/mach-omap2/gpmc.c linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c
--- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31 19:32:51.000000000 -0700
+++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c 2010-09-01 16:10:21.000000000 -0700
@@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx,
reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
__raw_writel(val, reg_addr);
}
+EXPORT_SYMBOL(gpmc_cs_write_reg);
u32 gpmc_cs_read_reg(int cs, int idx)
{
@@ -141,6 +142,7 @@ u32 gpmc_cs_read_reg(int cs, int idx)
reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
return __raw_readl(reg_addr);
}
+EXPORT_SYMBOL(gpmc_cs_read_reg);
/* TODO: Add support for gpmc_fck to clock framework and use it */
unsigned long gpmc_get_fclk_period(void)
@@ -294,6 +296,7 @@ int gpmc_cs_set_timings(int cs, const st
return 0;
}
+EXPORT_SYMBOL(gpmc_cs_set_timings);
static void gpmc_cs_enable_mem(int cs, u32 base, u32 size)
{
---------------------------------------------------------------
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---------------------------------------------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related
2010-09-07 19:26 [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related David Cross
@ 2010-09-07 23:58 ` Greg KH
2010-09-08 17:00 ` David Cross
2010-09-08 17:28 ` Tony Lindgren
0 siblings, 2 replies; 6+ messages in thread
From: Greg KH @ 2010-09-07 23:58 UTC (permalink / raw)
To: David Cross; +Cc: tony, linux-kernel, linux-omap
On Tue, Sep 07, 2010 at 12:26:47PM -0700, David Cross wrote:
> This patch exports some of the gpmc driver functions in OMAP3. The purpose behind this patch
> is to allow device drivers compiled as loadable modules to be interfaced to the GPMC. I am
> hoping that Tony is the correct maintainer and willing to ACK this change. Please let me know
> if there are any issues or concerns with this patch.
> Thanks,
> David
>
> Signed-off-by: David Cross <david.cross@cypress.com>
>
> diff -uprN -X linux-next-vanilla/Documentation/dontdiff linux-next-vanilla/arch/arm/mach-omap2/gpmc.c linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c
> --- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31 19:32:51.000000000 -0700
> +++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c 2010-09-01 16:10:21.000000000 -0700
> @@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx,
> reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
> __raw_writel(val, reg_addr);
> }
> +EXPORT_SYMBOL(gpmc_cs_write_reg);
EXPORT_SYMBOL_GPL() perhaps?
What about platforms that don't have this symbol, how will the driver
build properly then? Shouldn't something like this be in a arch-neutral
place in the kernel tree?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related
2010-09-07 23:58 ` Greg KH
@ 2010-09-08 17:00 ` David Cross
2010-09-08 17:30 ` Tony Lindgren
2010-09-08 17:28 ` Tony Lindgren
1 sibling, 1 reply; 6+ messages in thread
From: David Cross @ 2010-09-08 17:00 UTC (permalink / raw)
To: 'Greg KH'; +Cc: tony, linux-kernel, linux-omap
> From: Greg KH [mailto:greg@kroah.com]
> On Tue, Sep 07, 2010 at 12:26:47PM -0700, David Cross wrote:
> > This patch exports some of the gpmc driver functions in OMAP3. The
purpose behind this patch
> > is to allow device drivers compiled as loadable modules to be interfaced
> to the GPMC. I am
> > hoping that Tony is the correct maintainer and willing to ACK this
change. Please let me know
> > if there are any issues or concerns with this patch.
> > Thanks,
> > David
> >
> > Signed-off-by: David Cross <david.cross@cypress.com>
> >
> > diff -uprN -X linux-next-vanilla/Documentation/dontdiff
linux-next-vanilla/arch/arm/mach-omap2/gpmc.c
linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c
> > --- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31
19:32:51.000000000 -0700
> > +++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c 2010-09-01
16:10:21.000000000 -0700
> > @@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx,
> > reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
> > __raw_writel(val, reg_addr);
> > }
> > +EXPORT_SYMBOL(gpmc_cs_write_reg);
> EXPORT_SYMBOL_GPL() perhaps?
I don't have an issue with that, though I am not sure I understand why we
would want to limit the usage of the function to GPL'd modules. It is
probably Tony's call assuming he is ok with exporting the symbol.
> What about platforms that don't have this symbol, how will the driver
> build properly then?
The driver will require some sort of HAL to build, this is part of the
reason for the Kconfig changes. They require a HAL to be selected before the
driver can be included. A platform which does not have a gpmc specifically
will have some method of configuring the memory interface to talk with an
external chip. In that case, whatever functions are used for memory
interface configuration will be used.
> Shouldn't something like this be in a arch-neutral
> place in the kernel tree?
I don't think so, the inclusion of west bridge is architecture specific
based on the need to configure an external memory interface to talk to it.
Thanks,
david
---------------------------------------------------------------
This message and any attachments may contain Cypress (or its
subsidiaries) confidential information. If it has been received
in error, please advise the sender and immediately delete this
message.
---------------------------------------------------------------
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related
2010-09-08 17:00 ` David Cross
@ 2010-09-08 17:30 ` Tony Lindgren
0 siblings, 0 replies; 6+ messages in thread
From: Tony Lindgren @ 2010-09-08 17:30 UTC (permalink / raw)
To: David Cross; +Cc: 'Greg KH', linux-kernel, linux-omap
* David Cross <david.cross@cypress.com> [100908 09:52]:
>
> > From: Greg KH [mailto:greg@kroah.com]
>
> > On Tue, Sep 07, 2010 at 12:26:47PM -0700, David Cross wrote:
> > > This patch exports some of the gpmc driver functions in OMAP3. The
> purpose behind this patch
> > > is to allow device drivers compiled as loadable modules to be interfaced
> > to the GPMC. I am
> > > hoping that Tony is the correct maintainer and willing to ACK this
> change. Please let me know
> > > if there are any issues or concerns with this patch.
> > > Thanks,
> > > David
> > >
> > > Signed-off-by: David Cross <david.cross@cypress.com>
> > >
> > > diff -uprN -X linux-next-vanilla/Documentation/dontdiff
> linux-next-vanilla/arch/arm/mach-omap2/gpmc.c
> linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c
> > > --- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31
> 19:32:51.000000000 -0700
> > > +++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c 2010-09-01
> 16:10:21.000000000 -0700
> > > @@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx,
> > > reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
> > > __raw_writel(val, reg_addr);
> > > }
> > > +EXPORT_SYMBOL(gpmc_cs_write_reg);
>
> > EXPORT_SYMBOL_GPL() perhaps?
>
> I don't have an issue with that, though I am not sure I understand why we
> would want to limit the usage of the function to GPL'd modules. It is
> probably Tony's call assuming he is ok with exporting the symbol.
Exporting these is not a good idea, it should be done in the platform
init code like I replied in another message.
Regards,
Tony
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related
2010-09-07 23:58 ` Greg KH
2010-09-08 17:00 ` David Cross
@ 2010-09-08 17:28 ` Tony Lindgren
2010-09-09 3:39 ` Greg KH
1 sibling, 1 reply; 6+ messages in thread
From: Tony Lindgren @ 2010-09-08 17:28 UTC (permalink / raw)
To: Greg KH; +Cc: David Cross, linux-kernel, linux-omap
* Greg KH <greg@kroah.com> [100907 17:17]:
> On Tue, Sep 07, 2010 at 12:26:47PM -0700, David Cross wrote:
> > This patch exports some of the gpmc driver functions in OMAP3. The purpose behind this patch
> > is to allow device drivers compiled as loadable modules to be interfaced to the GPMC. I am
> > hoping that Tony is the correct maintainer and willing to ACK this change. Please let me know
> > if there are any issues or concerns with this patch.
> > Thanks,
> > David
> >
> > Signed-off-by: David Cross <david.cross@cypress.com>
> >
> > diff -uprN -X linux-next-vanilla/Documentation/dontdiff linux-next-vanilla/arch/arm/mach-omap2/gpmc.c linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c
> > --- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31 19:32:51.000000000 -0700
> > +++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c 2010-09-01 16:10:21.000000000 -0700
> > @@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx,
> > reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
> > __raw_writel(val, reg_addr);
> > }
> > +EXPORT_SYMBOL(gpmc_cs_write_reg);
>
> EXPORT_SYMBOL_GPL() perhaps?
>
> What about platforms that don't have this symbol, how will the driver
> build properly then? Shouldn't something like this be in a arch-neutral
> place in the kernel tree?
I don't think exporting these functions is a good idea, so NAK from
me for that.
All the drivers should be generic, and whatever needs to be done
that's omap specific should be done in the platform init code.
If the driver needs to reconfigure something, such as memory timings,
it can be done by passing a retime function pointer to the driver
in the platform_data. Then the driver can call that function if
it exists.
Regards,
Tony
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related
2010-09-08 17:28 ` Tony Lindgren
@ 2010-09-09 3:39 ` Greg KH
0 siblings, 0 replies; 6+ messages in thread
From: Greg KH @ 2010-09-09 3:39 UTC (permalink / raw)
To: Tony Lindgren; +Cc: David Cross, linux-kernel, linux-omap
On Wed, Sep 08, 2010 at 10:28:45AM -0700, Tony Lindgren wrote:
> * Greg KH <greg@kroah.com> [100907 17:17]:
> > On Tue, Sep 07, 2010 at 12:26:47PM -0700, David Cross wrote:
> > > This patch exports some of the gpmc driver functions in OMAP3. The purpose behind this patch
> > > is to allow device drivers compiled as loadable modules to be interfaced to the GPMC. I am
> > > hoping that Tony is the correct maintainer and willing to ACK this change. Please let me know
> > > if there are any issues or concerns with this patch.
> > > Thanks,
> > > David
> > >
> > > Signed-off-by: David Cross <david.cross@cypress.com>
> > >
> > > diff -uprN -X linux-next-vanilla/Documentation/dontdiff linux-next-vanilla/arch/arm/mach-omap2/gpmc.c linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c
> > > --- linux-next-vanilla/arch/arm/mach-omap2/gpmc.c 2010-08-31 19:32:51.000000000 -0700
> > > +++ linux-next-incl-sdk/arch/arm/mach-omap2/gpmc.c 2010-09-01 16:10:21.000000000 -0700
> > > @@ -133,6 +133,7 @@ void gpmc_cs_write_reg(int cs, int idx,
> > > reg_addr = gpmc_base + GPMC_CS0_OFFSET + (cs * GPMC_CS_SIZE) + idx;
> > > __raw_writel(val, reg_addr);
> > > }
> > > +EXPORT_SYMBOL(gpmc_cs_write_reg);
> >
> > EXPORT_SYMBOL_GPL() perhaps?
> >
> > What about platforms that don't have this symbol, how will the driver
> > build properly then? Shouldn't something like this be in a arch-neutral
> > place in the kernel tree?
>
> I don't think exporting these functions is a good idea, so NAK from
> me for that.
>
> All the drivers should be generic, and whatever needs to be done
> that's omap specific should be done in the platform init code.
Ah, that makes more sense. David, care to make those changes?
thanks,
greg k-h
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-09-09 5:22 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-09-07 19:26 [PATCH] gpmc, EXPORT_SYMBOLS, west bridge related David Cross
2010-09-07 23:58 ` Greg KH
2010-09-08 17:00 ` David Cross
2010-09-08 17:30 ` Tony Lindgren
2010-09-08 17:28 ` Tony Lindgren
2010-09-09 3:39 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).