* [PATCH 1/2] Add a common struct clk
From: Russell King - ARM Linux @ 2011-01-07 0:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101070810.21398.jeremy.kerr@canonical.com>
On Fri, Jan 07, 2011 at 08:10:20AM +0800, Jeremy Kerr wrote:
> Hi Richard,
>
> > > > +struct clk {
> > > > + const struct clk_ops *ops;
> > > > + unsigned int enable_count;
> > > > + int flags;
> > > > + union {
> > > > + struct mutex mutex;
> > > > + spinlock_t spinlock;
> > > > + } lock;
> > > > +};
> > >
> > > Here you have a "polymorphic" lock, where the clock instance knows
> > > which type it is supposed to be. I got flak from David Miller and
> > >
> > > others trying to do the same thing with the mdio_bus:
> > > http://kerneltrap.org/mailarchive/linux-netdev/2010/7/6/6280618
> > >
> > > The criticism, applied to your case, is that the clk_enable() caller
> > > cannot know whether it is safe to make the call or not. I was told,
> > > "there has got to be a better way."
> >
> > Note that this is not "new". Currently there is no convention available
> > if clk_enable sleeps or not. See e.g.
> > http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744
>
> As Uwe says, the common clock does not change these semantics; I would prefer
> to keep the driver API changes at a minimum with these patches.
>
> But yes, it would be a good idea to:
>
> * introduce clk_enable_atomic, which requires clk->flags & CLK_ATOMIC
>
> * add might_sleep to clk_enable(), encouraging clk uses in atomic contexts
> to switch to clk_enable_atomic.
>
> We'd still be able to handle CLK_ATOMIC clocks in clk_enable(), so the
> enforcement only needs to be one-way.
I think the atomic stuff should be the norm through and through - otherwise
we're going to end up with problems in drivers where they use the _atomic()
stuff, but the clocks behind are coded to sleep.
I hate the GPIO APIs for doing this _cansleep crap as the decision of
whether to use the _cansleep or normal APIs normally can't be made at
the time when the API is used, but sometime later. Many people just use
the non-_cansleep versions irrespective of the context they're in -
which is unnecessarily restrictive - consider what happens if you then
have that driver use a GPIO on an I2C peripheral...
By inventing two interfaces, you're asking for the same thing to happen
with clocks.
^ permalink raw reply
* [PATCH 1/2] Add a common struct clk
From: Jeremy Kerr @ 2011-01-07 0:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106201137.GY25121@pengutronix.de>
Hi Richard,
> > > +struct clk {
> > > + const struct clk_ops *ops;
> > > + unsigned int enable_count;
> > > + int flags;
> > > + union {
> > > + struct mutex mutex;
> > > + spinlock_t spinlock;
> > > + } lock;
> > > +};
> >
> > Here you have a "polymorphic" lock, where the clock instance knows
> > which type it is supposed to be. I got flak from David Miller and
> >
> > others trying to do the same thing with the mdio_bus:
> > http://kerneltrap.org/mailarchive/linux-netdev/2010/7/6/6280618
> >
> > The criticism, applied to your case, is that the clk_enable() caller
> > cannot know whether it is safe to make the call or not. I was told,
> > "there has got to be a better way."
>
> Note that this is not "new". Currently there is no convention available
> if clk_enable sleeps or not. See e.g.
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744
As Uwe says, the common clock does not change these semantics; I would prefer
to keep the driver API changes at a minimum with these patches.
But yes, it would be a good idea to:
* introduce clk_enable_atomic, which requires clk->flags & CLK_ATOMIC
* add might_sleep to clk_enable(), encouraging clk uses in atomic contexts
to switch to clk_enable_atomic.
We'd still be able to handle CLK_ATOMIC clocks in clk_enable(), so the
enforcement only needs to be one-way.
However, I think these would be better as separate changes.
Cheers,
Jeremy
^ permalink raw reply
* [PATCH v2 0/3] add CNS3xxx AHCI support
From: Jeff Garzik @ 2011-01-06 23:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106105157.GA9560@oksana.dev.rtsoft.ru>
On 01/06/2011 05:51 AM, Anton Vorontsov wrote:
> 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.
My main objection is the renaming. If ahci_platform wants to export
some symbols for SoC modules like ahci_platform_cns, that's ok.
In general, follow the library approach rather than linking modules
together in strange ways.
Jeff
^ permalink raw reply
* [PATCH 5/5] omap2+: pm_bus: make functions used as pointers as static
From: Tony Lindgren @ 2011-01-06 22:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87zkrg2nfa.fsf@ti.com>
* Kevin Hilman <khilman@ti.com> [110104 16:39]:
> Nishanth Menon <nm@ti.com> writes:
>
> > omap_pm_runtime_suspend and omap_pm_runtime_resume are used
> > as function pointers and does not really need to be exposed
> > to the world.
> >
> > Fixes sparse warnings:
> > arch/arm/mach-omap2/pm_bus.c:23:5: warning: symbol 'omap_pm_runtime_suspend' was not declared. Should it be static?
> > arch/arm/mach-omap2/pm_bus.c:40:5: warning: symbol 'omap_pm_runtime_resume' was not declared. Should it be static?
> >
> > Signed-off-by: Nishanth Menon <nm@ti.com>
>
> Thanks, will queue this one in my pm-fixes branch for 2.6.38-rc.
I'll take patches 1 - 4.
Tony
^ permalink raw reply
* [PATCH] arm: mach-omap2: pm: cleanup !CONFIG_SUSPEND handling
From: Kevin Hilman @ 2011-01-06 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ei8qx8v3.fsf@ti.com>
Kevin Hilman <khilman@ti.com> writes:
> <aaro.koskinen@nokia.com> writes:
>
>> 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)
>
> ah, thanks. somehow I missed that one when looking to see if this was
> already fixed.
OK, now your patch and the one from linux-next are conflicting as they
both touch the platform_suspend_ops in pm*.c.
So for now, I'm gonna drop this one, but it should be rebased/reposted as
soon as 2.6.38-rc1 is out.
Thanks,
Kevin
^ permalink raw reply
* [PATCH v3 0/3] OMAP3: beaglexm: GPIO fixes
From: Kevin Hilman @ 2011-01-06 22:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294343679-10605-1-git-send-email-nm@ti.com>
Nishanth Menon <nm@ti.com> writes:
> Hi,
> As discussed in the threads:
> http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
> http://marc.info/?t=121540030800004&r=1&w=2
>
> here is the split up series with commit message after discussion:
> http://www.beagleboard.org/irclogs/index.php?date=2011-01-06#T19:12:21
>
> Koen Kooi (3):
> omap3: beaglexm: fix EHCI power up GPIO dir
> omap3: beaglexm: fix DVI reset GPIO
> omap3: beaglexm: power on DVI
>
> arch/arm/mach-omap2/board-omap3beagle.c | 37 ++++++++++++++++++++++++++----
> 1 files changed, 32 insertions(+), 5 deletions(-)
>
> v3:
> split up the series, addressed review comments
Thanks, queueing for the .38-rc cycle.
Kevin
> v2: http://marc.info/?t=129276977900002&r=1&w=2
> Reenable the PMU stat LED
> v1: http://marc.info/?t=129172571000001&r=1&w=2
>
> Regards,
> Nishanth Menon
^ permalink raw reply
* [PATCH] arm: mach-omap2: mux: fix buffer overrun
From: Tony Lindgren @ 2011-01-06 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294245733-4126-1-git-send-email-aaro.koskinen@nokia.com>
* Aaro Koskinen <aaro.koskinen@nokia.com> [110105 08:39]:
> memcpy() copies 8 bytes too much (omap_mux_entry vs. omap_mux). Correct
> by replacing memcpy() with struct assignment, which is safer.
Thanks will queue as a fix after the merge window.
Tony
> Signed-off-by: Aaro Koskinen <aaro.koskinen@nokia.com>
> ---
> arch/arm/mach-omap2/mux.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> index 17bd639..df8d2f2 100644
> --- a/arch/arm/mach-omap2/mux.c
> +++ b/arch/arm/mach-omap2/mux.c
> @@ -893,7 +893,7 @@ static struct omap_mux * __init omap_mux_list_add(
> return NULL;
>
> m = &entry->mux;
> - memcpy(m, src, sizeof(struct omap_mux_entry));
> + entry->mux = *src;
>
> #ifdef CONFIG_OMAP_MUX
> if (omap_mux_copy_names(src, m)) {
> --
> 1.5.6.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 3/6] i2c/pxa2xx: Add PCI support for PXA I2C controller
From: Greg KH @ 2011-01-06 21:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106092044.GT8638@n2100.arm.linux.org.uk>
On Thu, Jan 06, 2011 at 09:20:44AM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 05, 2011 at 03:08:34PM -0800, Greg KH wrote:
> > 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 see we're still repeating the same mistakes with lifetime rules of
> > > sysfs objects.
> > >
> > > Any struct device which has been registered into the device model can
> > > remain indefinitely live after it's been unregistered (by, eg, if
> > > userspace holds a reference to it via sysfs.)
> >
> > Actually this race is almost not possible these days with the rework
> > that Tejun did on sysfs, so it's not easy to test for this anymore.
>
> Is it wise to make such a problematical bug harder to trigger without
> completely preventing it triggering?
>
> A different approach was taken with IRQ handling where people were
> registering handlers before the driver was ready for it to be called -
> request_irq() would explicitly call the handler as soon as it was
> registered to provoke bugs.
>
> Surely for these lifetime violations a similar approach should be taken.
> Make the kernel more likely to oops should a violation occur before the
> developer can get the code out the door. One way I can think of doing
> that is when devices are unregistered but not yet released, place them
> on a list which is periodically scanned, and not only is the device
> dereferenced by also the release function.
>
> When the use count drops to zero, don't immediately release, but wait
> a number of polls.
>
> If either goes away before the device has been released, then we
> predictably oops, and the developer gets to know about his violation
> of the rules immediately.
Yes, that would be a good way to resolve this, patches are glady welcome
:)
thanks,
greg k-h
^ permalink raw reply
* still nfs problems [Was: Linux 2.6.37-rc8]
From: James Bottomley @ 2011-01-06 21:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294338341.22825.216.camel@mulgrave.site>
On Thu, 2011-01-06 at 12:25 -0600, James Bottomley wrote:
> OK, so thinking about this, it seems that the only danger is actually
> what NFS is doing: reading cache pages via a vmap. In that case, since
> the requirement is to invalidate the vmap range to prepare for read, we
> could have invalidate_kernel_vmap_range loop over the underlying pages
> and flush them through the kernel alias if the architecture specific
> flag indicates their contents might be dirty.
>
> The loop adds expense that is probably largely unnecessary to
> invalidate_kernel_vmap_range() but the alternative is adding to the API
> proliferation with something that only flushes the kernel pages if the
> arch specific flag says they're dirty.
This is what I think the arm patch would look like (example only: I
can't compile it). Is something like this too expensive? the loop can't
be optimised away because of the need to check the pages (and
vmalloc_to_page is a three level page table lookup).
James
---
diff --git a/arch/arm/include/asm/cacheflush.h b/arch/arm/include/asm/cacheflush.h
index 3acd8fa..34469ca 100644
--- a/arch/arm/include/asm/cacheflush.h
+++ b/arch/arm/include/asm/cacheflush.h
@@ -414,8 +414,17 @@ static inline void flush_kernel_vmap_range(void *addr, int size)
}
static inline void invalidate_kernel_vmap_range(void *addr, int size)
{
- if ((cache_is_vivt() || cache_is_vipt_aliasing()))
- __cpuc_flush_dcache_area(addr, (size_t)size);
+ if ((cache_is_vivt() || cache_is_vipt_aliasing())) {
+ void *cursor = addr;
+
+ for ( ; cursor < addr + size; cursor += PAGE_SIZE) {
+ struct page *page = vmalloc_to_page(cursor);
+
+ if (!test_and_set_bit(PG_dcache_clean, &page->flags))
+ __flush_dcache_page(page_mapping(page), page);
+ }
+ __cpuc_flush_dcache_area(addr, (size_t)size);
+ }
}
#define ARCH_HAS_FLUSH_ANON_PAGE
^ permalink raw reply related
* still nfs problems [Was: Linux 2.6.37-rc8]
From: John Stoffel @ 2011-01-06 20:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294335614.22825.154.camel@mulgrave.site>
>>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> writes:
James> On Wed, 2011-01-05 at 23:28 +0000, James Bottomley wrote:
>> Can you explain how the code works? it looks to me like you read the xdr
>> stuff through the vmap region then write it out directly to the pages?
James> OK, I think I see how this is supposed to work: It's a
James> sequential loop of reading in via the pages (i.e. through the
James> kernel mapping) and then updating those pages via the vmap. In
James> which case, I think this patch is what you need.
James> The theory of operation is that the readdir on pages actually
James> uses the network DMA operations to perform, so when it's
James> finished, the underlying page is up to date. After this you
James> invalidate the vmap range, so we have no cache lines above it
James> (so it picks up the values from the uptodate page). Finally,
James> after the operation on the vmap region has finished, you flush
James> it so that any updated contents go back to the pages themselves
James> before the next iteration begins.
You need to re-spin this patch to include the above description into
the magic steps your taking here, or at least document it more clearly
somewhere why you need to make these funky steps.
John
James> James
James> ---
James> diff --git a/fs/nfs/dir.c b/fs/nfs/dir.c
James> index 996dd89..bde1911 100644
James> --- a/fs/nfs/dir.c
James> +++ b/fs/nfs/dir.c
James> @@ -587,12 +587,16 @@ int nfs_readdir_xdr_to_array(nfs_readdir_descriptor_t *desc, struct page *page,
James> if (status < 0)
James> break;
James> pglen = status;
James> +
James> + invalidate_kernel_vmap_range(pages_ptr, pglen);
James> +
James> status = nfs_readdir_page_filler(desc, &entry, pages_ptr, page, pglen);
James> if (status < 0) {
James> if (status == -ENOSPC)
James> status = 0;
James> break;
James> }
James> + flush_kernel_vmap_range(pages_ptr, pglen);
James> } while (array->eof_index < 0);
James> nfs_readdir_free_large_page(pages_ptr, pages, array_size);
James> --
James> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
James> the body of a message to majordomo at vger.kernel.org
James> More majordomo info at http://vger.kernel.org/majordomo-info.html
James> Please read the FAQ at http://www.tux.org/lkml/
--
^ permalink raw reply
* [PATCH V2] ST SPEAr: PCIE gadget suppport
From: Andrew Morton @ 2011-01-06 20:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <137dfad4a093ea0ac80396f5eb7fbf0c382be698.1294314772.git.viresh.kumar@st.com>
On Thu, 6 Jan 2011 17:29:10 +0530
Viresh Kumar <viresh.kumar@st.com> wrote:
> 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
>
> ...
>
> --- /dev/null
> +++ b/Documentation/misc-devices/spear-pcie-gadget.txt
Please recheck this documentation file - it contains a number of simple
typos.
>
> ...
>
> + if (strict_strtoul(buf, 0, &config->requested_msi))
> + return -EINVAL;
It doesn't matter much, but the code really should propagate the
strict_strtoul() return error code back to the caller, rather than
overwriting it with -EINVAL.
^ permalink raw reply
* [PATCH 1/2] Add a common struct clk
From: Uwe Kleine-König @ 2011-01-06 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110106160752.GA2775@riccoc20.at.omicron.at>
On Thu, Jan 06, 2011 at 05:07:52PM +0100, Richard Cochran wrote:
> On Wed, Jan 05, 2011 at 11:51:02AM +0800, Jeremy Kerr wrote:
>
> > + * The @lock member provides either a spinlock or a mutex to protect (at least)
> > + * @enable_count. The type of lock used will depend on @flags; if CLK_ATOMIC is
> > + * set, then the core clock code will use a spinlock, otherwise a mutex. This
> > + * lock will be acquired during clk_enable and clk_disable, so for atomic
> > + * clocks, these ops callbacks must not sleep.
> > + *
> > + * The choice of atomic or non-atomic clock depends on how the clock is enabled.
> > + * Typically, you'll want to use a non-atomic clock. For clocks that need to be
> > + * enabled/disabled in interrupt context, use CLK_ATOMIC. Note that atomic
> > + * clocks with parents will typically cascade enable/disable operations to
> > + * their parent, so the parent of an atomic clock *must* be atomic too.
>
> ...
>
> > +struct clk {
> > + const struct clk_ops *ops;
> > + unsigned int enable_count;
> > + int flags;
> > + union {
> > + struct mutex mutex;
> > + spinlock_t spinlock;
> > + } lock;
> > +};
>
> Here you have a "polymorphic" lock, where the clock instance knows
> which type it is supposed to be. I got flak from David Miller and
> others trying to do the same thing with the mdio_bus:
>
> http://kerneltrap.org/mailarchive/linux-netdev/2010/7/6/6280618
>
> The criticism, applied to your case, is that the clk_enable() caller
> cannot know whether it is safe to make the call or not. I was told,
> "there has got to be a better way."
Note that this is not "new". Currently there is no convention available
if clk_enable sleeps or not. See e.g.
http://thread.gmane.org/gmane.linux.ports.arm.kernel/100744
So if there is no consent and you want to introduce common code there is
no choice.
I don't like it, too. IMHO clk_enable should be allowed to sleep, but I
see the concerns of the other camp, too. If you know the better way
that has to exists, please tell us.
(Hmm, the way the gpio api does it comes to mind:
clk_enable_atomic
clk_enable_cansleep
(where one of these can be named clk_enable).)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v3 0/3] OMAP3: beaglexm: GPIO fixes
From: Koen Kooi @ 2011-01-06 19:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294343679-10605-1-git-send-email-nm@ti.com>
Thanks for splitting it up! Now I can work on the patches for xM rev C where the pins changed again :)
Op 6 jan 2011, om 20:54 heeft Nishanth Menon het volgende geschreven:
> Hi,
> As discussed in the threads:
> http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
> http://marc.info/?t=121540030800004&r=1&w=2
>
> here is the split up series with commit message after discussion:
> http://www.beagleboard.org/irclogs/index.php?date=2011-01-06#T19:12:21
>
> Koen Kooi (3):
> omap3: beaglexm: fix EHCI power up GPIO dir
> omap3: beaglexm: fix DVI reset GPIO
> omap3: beaglexm: power on DVI
>
> arch/arm/mach-omap2/board-omap3beagle.c | 37 ++++++++++++++++++++++++++----
> 1 files changed, 32 insertions(+), 5 deletions(-)
>
> v3:
> split up the series, addressed review comments
>
> v2: http://marc.info/?t=129276977900002&r=1&w=2
> Reenable the PMU stat LED
> v1: http://marc.info/?t=129172571000001&r=1&w=2
>
> Regards,
> Nishanth Menon
^ permalink raw reply
* [PATCH v3 3/3] omap3: beaglexm: power on DVI
From: Nishanth Menon @ 2011-01-06 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294343679-10605-1-git-send-email-nm@ti.com>
From: Koen Kooi <koen@beagleboard.org>
TFP410 DVI chip is used to provide display out.
this chip is controlled by 2 lines:
LDO which supplies the power is controlled over gpio + 2
and the enable of the chip itself is done over gpio + 1
NOTE: the LDO is necessary for LED, serial blocks as well.
GPIO + 1 was used to sense USB overcurrent in vanilla beagle
[nm at ti.com: helped split up the patch]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Koen Kooi <koen@beagleboard.org>
---
arch/arm/mach-omap2/board-omap3beagle.c | 20 +++++++++++++++++---
1 files changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index d628f5e..7c82730 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -293,9 +293,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
-
- gpio_request(gpio + 1, "EHCI_nOC");
- gpio_direction_input(gpio + 1);
+ if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
+ gpio_request(gpio + 1, "EHCI_nOC");
+ gpio_direction_input(gpio + 1);
+ }
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
@@ -317,6 +318,19 @@ static int beagle_twl_gpio_setup(struct device *dev,
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
+ /*
+ * gpio + 1 on Xm controls the TFP410's enable line (active low)
+ * gpio + 2 control varies depending on the board rev as follows:
+ * P7/P8 revisions(prototype): Camera EN
+ * A2+ revisions (production): LDO (supplies DVI, serial, led blocks)
+ */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ gpio_request(gpio + 1, "nDVI_PWR_EN");
+ gpio_direction_output(gpio + 1, 0);
+ gpio_request(gpio + 2, "DVI_LDO_EN");
+ gpio_direction_output(gpio + 2, 1);
+ }
+
return 0;
}
--
1.6.3.3
^ permalink raw reply related
* [PATCH v3 2/3] omap3: beaglexm: fix DVI reset GPIO
From: Nishanth Menon @ 2011-01-06 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294343679-10605-1-git-send-email-nm@ti.com>
From: Koen Kooi <koen@beagleboard.org>
GPIO reset line for Beagle XM is different from vanilla beagle
so we populate it as part of gpio update routine.
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Koen Kooi <koen@beagleboard.org>
---
arch/arm/mach-omap2/board-omap3beagle.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 1b5aa7a..d628f5e 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -199,7 +199,7 @@ static struct omap_dss_device beagle_dvi_device = {
.name = "dvi",
.driver_name = "generic_panel",
.phy.dpi.data_lines = 24,
- .reset_gpio = 170,
+ .reset_gpio = -EINVAL,
.platform_enable = beagle_enable_dvi,
.platform_disable = beagle_disable_dvi,
};
@@ -308,6 +308,12 @@ static int beagle_twl_gpio_setup(struct device *dev,
else
gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ /* DVI reset GPIO is different between beagle revisions */
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+ beagle_dvi_device.reset_gpio = 129;
+ else
+ beagle_dvi_device.reset_gpio = 170;
+
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
--
1.6.3.3
^ permalink raw reply related
* [PATCH v3 1/3] omap3: beaglexm: fix EHCI power up GPIO dir
From: Nishanth Menon @ 2011-01-06 19:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294343679-10605-1-git-send-email-nm@ti.com>
From: Koen Kooi <koen@beagleboard.org>
EHCI enable power pin is inverted (active high) in comparison
to vanilla beagle which is active low. Handle this case conditionally.
[nm at ti.com: helped split up]
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Koen Kooi <koen@beagleboard.org>
---
arch/arm/mach-omap2/board-omap3beagle.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 6c12760..1b5aa7a 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -297,9 +297,16 @@ static int beagle_twl_gpio_setup(struct device *dev,
gpio_request(gpio + 1, "EHCI_nOC");
gpio_direction_input(gpio + 1);
- /* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, active low) */
+ /*
+ * TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
+ * high / others active low)
+ */
gpio_request(gpio + TWL4030_GPIO_MAX, "nEN_USB_PWR");
gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+ gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
+ else
+ gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
/* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
--
1.6.3.3
^ permalink raw reply related
* [PATCH v3 0/3] OMAP3: beaglexm: GPIO fixes
From: Nishanth Menon @ 2011-01-06 19:54 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
As discussed in the threads:
http://thread.gmane.org/gmane.linux.ports.arm.omap/47807/
http://marc.info/?t=121540030800004&r=1&w=2
here is the split up series with commit message after discussion:
http://www.beagleboard.org/irclogs/index.php?date=2011-01-06#T19:12:21
Koen Kooi (3):
omap3: beaglexm: fix EHCI power up GPIO dir
omap3: beaglexm: fix DVI reset GPIO
omap3: beaglexm: power on DVI
arch/arm/mach-omap2/board-omap3beagle.c | 37 ++++++++++++++++++++++++++----
1 files changed, 32 insertions(+), 5 deletions(-)
v3:
split up the series, addressed review comments
v2: http://marc.info/?t=129276977900002&r=1&w=2
Reenable the PMU stat LED
v1: http://marc.info/?t=129172571000001&r=1&w=2
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 7/7] ARM: S3C2442: RX1950: Add support for LED blinking
From: Vasily Khoruzhick @ 2011-01-06 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294343572-28518-1-git-send-email-anarsoul@gmail.com>
Add .gpio_set_blink callback to support HW blinking
available on RX1950
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
arch/arm/mach-s3c2440/mach-rx1950.c | 54 +++++++++++++++++++++++++++++++++++
1 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c2440/mach-rx1950.c b/arch/arm/mach-s3c2440/mach-rx1950.c
index e7cc993..2d2f4e4 100644
--- a/arch/arm/mach-s3c2440/mach-rx1950.c
+++ b/arch/arm/mach-s3c2440/mach-rx1950.c
@@ -263,6 +263,52 @@ void rx1950_disable_charger(void)
gpio_direction_output(S3C2410_GPJ(3), 0);
}
+DEFINE_SPINLOCK(rx1950_blink_spin);
+
+static int rx1950_led_blink_set(unsigned gpio, int state,
+ unsigned long *delay_on, unsigned long *delay_off)
+{
+ int blink_gpio, check_gpio;
+
+ switch (gpio) {
+ case S3C2410_GPA(6):
+ blink_gpio = S3C2410_GPA(4);
+ check_gpio = S3C2410_GPA(3);
+ break;
+ case S3C2410_GPA(7):
+ blink_gpio = S3C2410_GPA(3);
+ check_gpio = S3C2410_GPA(4);
+ break;
+ default:
+ return -EINVAL;
+ break;
+ }
+
+ if (delay_on && delay_off && !*delay_on && !*delay_off)
+ *delay_on = *delay_off = 500;
+
+ spin_lock(&rx1950_blink_spin);
+
+ switch (state) {
+ case GPIO_LED_NO_BLINK_LOW:
+ case GPIO_LED_NO_BLINK_HIGH:
+ if (!gpio_get_value(check_gpio))
+ gpio_set_value(S3C2410_GPJ(6), 0);
+ gpio_set_value(blink_gpio, 0);
+ gpio_set_value(gpio, state);
+ break;
+ case GPIO_LED_BLINK:
+ gpio_set_value(gpio, 0);
+ gpio_set_value(S3C2410_GPJ(6), 1);
+ gpio_set_value(blink_gpio, 1);
+ break;
+ }
+
+ spin_unlock(&rx1950_blink_spin);
+
+ return 0;
+}
+
static struct gpio_led rx1950_leds_desc[] = {
{
.name = "Green",
@@ -287,6 +333,7 @@ static struct gpio_led rx1950_leds_desc[] = {
static struct gpio_led_platform_data rx1950_leds_pdata = {
.num_leds = ARRAY_SIZE(rx1950_leds_desc),
.leds = rx1950_leds_desc,
+ .gpio_blink_set = rx1950_led_blink_set,
};
static struct platform_device rx1950_leds = {
@@ -774,6 +821,13 @@ static void __init rx1950_init_machine(void)
WARN_ON(gpio_request(S3C2410_GPB(1), "LCD power"));
+ WARN_ON(gpio_request(S3C2410_GPA(3), "Red blink"));
+ WARN_ON(gpio_request(S3C2410_GPA(4), "Green blink"));
+ WARN_ON(gpio_request(S3C2410_GPJ(6), "LED blink"));
+ gpio_direction_output(S3C2410_GPA(3), 0);
+ gpio_direction_output(S3C2410_GPA(4), 0);
+ gpio_direction_output(S3C2410_GPJ(6), 0);
+
platform_add_devices(rx1950_devices, ARRAY_SIZE(rx1950_devices));
i2c_register_board_info(0, rx1950_i2c_devices,
--
1.7.3.2
^ permalink raw reply related
* [PATCH 6/7] ARM: S3C2442: RX1950: Retain LEDs state in suspend
From: Vasily Khoruzhick @ 2011-01-06 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294343572-28518-1-git-send-email-anarsoul@gmail.com>
s3c_adc_battery uses LEDs to indicate charging process,
retain LEDs state in suspend, otherwise user have no information if PDA
battery is charging after he put it to suspend.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
arch/arm/mach-s3c2440/mach-rx1950.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c2440/mach-rx1950.c b/arch/arm/mach-s3c2440/mach-rx1950.c
index eab6ae5..e7cc993 100644
--- a/arch/arm/mach-s3c2440/mach-rx1950.c
+++ b/arch/arm/mach-s3c2440/mach-rx1950.c
@@ -268,16 +268,19 @@ static struct gpio_led rx1950_leds_desc[] = {
.name = "Green",
.default_trigger = "main-battery-charging-or-full",
.gpio = S3C2410_GPA(6),
+ .retain_state_suspended = 1,
},
{
.name = "Red",
.default_trigger = "main-battery-full",
.gpio = S3C2410_GPA(7),
+ .retain_state_suspended = 1,
},
{
.name = "Blue",
.default_trigger = "rx1950-acx-mem",
.gpio = S3C2410_GPA(11),
+ .retain_state_suspended = 1,
},
};
--
1.7.3.2
^ permalink raw reply related
* [PATCH 5/7] ARM: S3C2410: H1940: Fix lcd_power_set function
From: Vasily Khoruzhick @ 2011-01-06 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294343572-28518-1-git-send-email-anarsoul@gmail.com>
Current implementation of lcd_power_set is not reliable, sometimes
it does not enable LCD at all.
Mimic WinCE behavior to fix this issue.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
arch/arm/mach-s3c2410/mach-h1940.c | 26 +++++++++++++++-----------
1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-s3c2410/mach-h1940.c b/arch/arm/mach-s3c2410/mach-h1940.c
index 6a3cf78..5531c4c 100644
--- a/arch/arm/mach-s3c2410/mach-h1940.c
+++ b/arch/arm/mach-s3c2410/mach-h1940.c
@@ -30,6 +30,7 @@
#include <linux/leds.h>
#include <linux/pda_power.h>
#include <linux/s3c_adc_battery.h>
+#include <linux/delay.h>
#include <video/platform_lcd.h>
@@ -228,15 +229,15 @@ static struct s3c2410fb_mach_info h1940_fb_info __initdata = {
.num_displays = 1,
.default_display = 0,
- .lpcsel= 0x02,
- .gpccon= 0xaa940659,
- .gpccon_mask= 0xffffffff,
- .gpcup= 0x0000ffff,
- .gpcup_mask= 0xffffffff,
- .gpdcon= 0xaa84aaa0,
- .gpdcon_mask= 0xffffffff,
- .gpdup= 0x0000faff,
- .gpdup_mask= 0xffffffff,
+ .lpcsel = 0x02,
+ .gpccon = 0xaa940659,
+ .gpccon_mask = 0xffffc0f0,
+ .gpcup = 0x0000ffff,
+ .gpcup_mask = 0xffffffff,
+ .gpdcon = 0xaa84aaa0,
+ .gpdcon_mask = 0xffffffff,
+ .gpdup = 0x0000faff,
+ .gpdup_mask = 0xffffffff,
};
static int power_supply_init(struct device *dev)
@@ -545,14 +546,14 @@ static struct platform_device h1940_backlight = {
static void h1940_lcd_power_set(struct plat_lcd_data *pd,
unsigned int power)
{
- int value;
+ int value, retries = 100;
if (!power) {
gpio_set_value(S3C2410_GPC(0), 0);
/* wait for 3ac */
do {
value = gpio_get_value(S3C2410_GPC(6));
- } while (value);
+ } while (value && retries--);
gpio_set_value(H1940_LATCH_LCD_P2, 0);
gpio_set_value(H1940_LATCH_LCD_P3, 0);
@@ -570,6 +571,9 @@ static void h1940_lcd_power_set(struct plat_lcd_data *pd,
gpio_set_value(H1940_LATCH_LCD_P0, 1);
gpio_set_value(H1940_LATCH_LCD_P1, 1);
+ gpio_direction_input(S3C2410_GPC(1));
+ gpio_direction_input(S3C2410_GPC(4));
+ mdelay(10);
s3c_gpio_cfgpin(S3C2410_GPC(1), S3C_GPIO_SFN(2));
s3c_gpio_cfgpin(S3C2410_GPC(4), S3C_GPIO_SFN(2));
--
1.7.3.2
^ permalink raw reply related
* [PATCH 4/7] ARM: S3C2410: H1940: Add battery support
From: Vasily Khoruzhick @ 2011-01-06 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294343572-28518-1-git-send-email-anarsoul@gmail.com>
Add battery monitoring/charging support via pda_power and
s3c_adc_battery drivers
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
arch/arm/mach-s3c2410/mach-h1940.c | 144 ++++++++++++++++++++++++++++++++++++
1 files changed, 144 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c2410/mach-h1940.c b/arch/arm/mach-s3c2410/mach-h1940.c
index 5d0d2ae..6a3cf78 100644
--- a/arch/arm/mach-s3c2410/mach-h1940.c
+++ b/arch/arm/mach-s3c2410/mach-h1940.c
@@ -28,6 +28,8 @@
#include <linux/pwm_backlight.h>
#include <linux/i2c.h>
#include <linux/leds.h>
+#include <linux/pda_power.h>
+#include <linux/s3c_adc_battery.h>
#include <video/platform_lcd.h>
@@ -237,6 +239,146 @@ static struct s3c2410fb_mach_info h1940_fb_info __initdata = {
.gpdup_mask= 0xffffffff,
};
+static int power_supply_init(struct device *dev)
+{
+ return gpio_request(S3C2410_GPF(2), "cable plugged");
+}
+
+static int h1940_is_ac_online(void)
+{
+ return !gpio_get_value(S3C2410_GPF(2));
+}
+
+static void power_supply_exit(struct device *dev)
+{
+ gpio_free(S3C2410_GPF(2));
+}
+
+static char *h1940_supplicants[] = {
+ "main-battery",
+ "backup-battery",
+};
+
+static struct pda_power_pdata power_supply_info = {
+ .init = power_supply_init,
+ .is_ac_online = h1940_is_ac_online,
+ .exit = power_supply_exit,
+ .supplied_to = h1940_supplicants,
+ .num_supplicants = ARRAY_SIZE(h1940_supplicants),
+};
+
+static struct resource power_supply_resources[] = {
+ [0] = {
+ .name = "ac",
+ .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_LOWEDGE |
+ IORESOURCE_IRQ_HIGHEDGE,
+ .start = IRQ_EINT2,
+ .end = IRQ_EINT2,
+ },
+};
+
+static struct platform_device power_supply = {
+ .name = "pda-power",
+ .id = -1,
+ .dev = {
+ .platform_data =
+ &power_supply_info,
+ },
+ .resource = power_supply_resources,
+ .num_resources = ARRAY_SIZE(power_supply_resources),
+};
+
+static const struct s3c_adc_bat_thresh bat_lut_noac[] = {
+ { .volt = 4070, .cur = 162, .level = 100},
+ { .volt = 4040, .cur = 165, .level = 95},
+ { .volt = 4016, .cur = 164, .level = 90},
+ { .volt = 3996, .cur = 166, .level = 85},
+ { .volt = 3971, .cur = 168, .level = 80},
+ { .volt = 3951, .cur = 168, .level = 75},
+ { .volt = 3931, .cur = 170, .level = 70},
+ { .volt = 3903, .cur = 172, .level = 65},
+ { .volt = 3886, .cur = 172, .level = 60},
+ { .volt = 3858, .cur = 176, .level = 55},
+ { .volt = 3842, .cur = 176, .level = 50},
+ { .volt = 3818, .cur = 176, .level = 45},
+ { .volt = 3789, .cur = 180, .level = 40},
+ { .volt = 3769, .cur = 180, .level = 35},
+ { .volt = 3749, .cur = 184, .level = 30},
+ { .volt = 3732, .cur = 184, .level = 25},
+ { .volt = 3716, .cur = 184, .level = 20},
+ { .volt = 3708, .cur = 184, .level = 15},
+ { .volt = 3716, .cur = 96, .level = 10},
+ { .volt = 3700, .cur = 96, .level = 5},
+ { .volt = 3684, .cur = 96, .level = 0},
+};
+
+static const struct s3c_adc_bat_thresh bat_lut_acin[] = {
+ { .volt = 4130, .cur = 0, .level = 100},
+ { .volt = 3982, .cur = 0, .level = 50},
+ { .volt = 3854, .cur = 0, .level = 10},
+ { .volt = 3841, .cur = 0, .level = 0},
+};
+
+int h1940_bat_init(void)
+{
+ int ret;
+
+ ret = gpio_request(H1940_LATCH_SM803_ENABLE, "h1940-charger-enable");
+ if (ret)
+ return ret;
+ gpio_direction_output(H1940_LATCH_SM803_ENABLE, 0);
+
+ return 0;
+
+}
+
+void h1940_bat_exit(void)
+{
+ gpio_free(H1940_LATCH_SM803_ENABLE);
+}
+
+void h1940_enable_charger(void)
+{
+ gpio_set_value(H1940_LATCH_SM803_ENABLE, 1);
+}
+
+void h1940_disable_charger(void)
+{
+ gpio_set_value(H1940_LATCH_SM803_ENABLE, 0);
+}
+
+static struct s3c_adc_bat_pdata h1940_bat_cfg = {
+ .init = h1940_bat_init,
+ .exit = h1940_bat_exit,
+ .enable_charger = h1940_enable_charger,
+ .disable_charger = h1940_disable_charger,
+ .gpio_charge_finished = S3C2410_GPF(3),
+ .gpio_inverted = 1,
+ .lut_noac = bat_lut_noac,
+ .lut_noac_cnt = ARRAY_SIZE(bat_lut_noac),
+ .lut_acin = bat_lut_acin,
+ .lut_acin_cnt = ARRAY_SIZE(bat_lut_acin),
+ .volt_channel = 0,
+ .current_channel = 1,
+ .volt_mult = 4056,
+ .current_mult = 1893,
+ .internal_impedance = 200,
+ .backup_volt_channel = 3,
+ /* TODO Check backup volt multiplier */
+ .backup_volt_mult = 4056,
+ .backup_volt_min = 0,
+ .backup_volt_max = 4149288
+};
+
+static struct platform_device h1940_battery = {
+ .name = "s3c-adc-battery",
+ .id = -1,
+ .dev = {
+ .parent = &s3c_device_adc.dev,
+ .platform_data = &h1940_bat_cfg,
+ },
+};
+
DEFINE_SPINLOCK(h1940_blink_spin);
int h1940_led_blink_set(unsigned gpio, int state,
@@ -517,6 +659,8 @@ static struct platform_device *h1940_devices[] __initdata = {
&h1940_lcd_powerdev,
&s3c_device_adc,
&s3c_device_ts,
+ &power_supply,
+ &h1940_battery,
};
static void __init h1940_map_io(void)
--
1.7.3.2
^ permalink raw reply related
* [PATCH 3/7] ARM: S3C2410: H1940: Use leds-gpio driver for LEDs managing
From: Vasily Khoruzhick @ 2011-01-06 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294343572-28518-1-git-send-email-anarsoul@gmail.com>
We can use generic leds-gpio driver, as latch api was converted
to gpiolib.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
arch/arm/mach-s3c2410/h1940-bluetooth.c | 8 ++-
arch/arm/mach-s3c2410/include/mach/h1940.h | 3 +
arch/arm/mach-s3c2410/mach-h1940.c | 93 +++++++++++++++++++++++++++-
3 files changed, 101 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-s3c2410/h1940-bluetooth.c b/arch/arm/mach-s3c2410/h1940-bluetooth.c
index 6c59ef5..2c126bb 100644
--- a/arch/arm/mach-s3c2410/h1940-bluetooth.c
+++ b/arch/arm/mach-s3c2410/h1940-bluetooth.c
@@ -18,12 +18,14 @@
#include <linux/leds.h>
#include <linux/gpio.h>
#include <linux/rfkill.h>
+#include <linux/leds.h>
#include <mach/regs-gpio.h>
#include <mach/hardware.h>
#include <mach/h1940-latch.h>
+#include <mach/h1940.h>
-#define DRV_NAME "h1940-bt"
+#define DRV_NAME "h1940-bt"
/* Bluetooth control */
static void h1940bt_enable(int on)
@@ -37,6 +39,8 @@ static void h1940bt_enable(int on)
gpio_set_value(S3C2410_GPH(1), 1);
mdelay(10);
gpio_set_value(S3C2410_GPH(1), 0);
+
+ h1940_led_blink_set(-EINVAL, GPIO_LED_BLINK, NULL, NULL);
}
else {
gpio_set_value(S3C2410_GPH(1), 1);
@@ -44,6 +48,8 @@ static void h1940bt_enable(int on)
gpio_set_value(S3C2410_GPH(1), 0);
mdelay(10);
gpio_set_value(H1940_LATCH_BLUETOOTH_POWER, 0);
+
+ h1940_led_blink_set(-EINVAL, GPIO_LED_NO_BLINK_LOW, NULL, NULL);
}
}
diff --git a/arch/arm/mach-s3c2410/include/mach/h1940.h b/arch/arm/mach-s3c2410/include/mach/h1940.h
index 4559784..2aa683c 100644
--- a/arch/arm/mach-s3c2410/include/mach/h1940.h
+++ b/arch/arm/mach-s3c2410/include/mach/h1940.h
@@ -17,5 +17,8 @@
#define H1940_SUSPEND_CHECK (0x30080000)
extern void h1940_pm_return(void);
+extern int h1940_led_blink_set(unsigned gpio, int state,
+ unsigned long *delay_on, unsigned long *delay_off);
+
#endif /* __ASM_ARCH_H1940_H */
diff --git a/arch/arm/mach-s3c2410/mach-h1940.c b/arch/arm/mach-s3c2410/mach-h1940.c
index 641586a..5d0d2ae 100644
--- a/arch/arm/mach-s3c2410/mach-h1940.c
+++ b/arch/arm/mach-s3c2410/mach-h1940.c
@@ -27,6 +27,8 @@
#include <linux/gpio_keys.h>
#include <linux/pwm_backlight.h>
#include <linux/i2c.h>
+#include <linux/leds.h>
+
#include <video/platform_lcd.h>
#include <linux/mmc/host.h>
@@ -235,9 +237,87 @@ static struct s3c2410fb_mach_info h1940_fb_info __initdata = {
.gpdup_mask= 0xffffffff,
};
+DEFINE_SPINLOCK(h1940_blink_spin);
+
+int h1940_led_blink_set(unsigned gpio, int state,
+ unsigned long *delay_on, unsigned long *delay_off)
+{
+ int blink_gpio, check_gpio1, check_gpio2;
+
+ switch (gpio) {
+ case H1940_LATCH_LED_GREEN:
+ blink_gpio = S3C2410_GPA(7);
+ check_gpio1 = S3C2410_GPA(1);
+ check_gpio2 = S3C2410_GPA(3);
+ break;
+ case H1940_LATCH_LED_RED:
+ blink_gpio = S3C2410_GPA(1);
+ check_gpio1 = S3C2410_GPA(7);
+ check_gpio2 = S3C2410_GPA(3);
+ break;
+ default:
+ blink_gpio = S3C2410_GPA(3);
+ check_gpio1 = S3C2410_GPA(1);
+ check_gpio1 = S3C2410_GPA(7);
+ break;
+ }
+
+ if (delay_on && delay_off && !*delay_on && !*delay_off)
+ *delay_on = *delay_off = 500;
+
+ spin_lock(&h1940_blink_spin);
+
+ switch (state) {
+ case GPIO_LED_NO_BLINK_LOW:
+ case GPIO_LED_NO_BLINK_HIGH:
+ if (!gpio_get_value(check_gpio1) &&
+ !gpio_get_value(check_gpio2))
+ gpio_set_value(H1940_LATCH_LED_FLASH, 0);
+ gpio_set_value(blink_gpio, 0);
+ if (gpio_is_valid(gpio))
+ gpio_set_value(gpio, state);
+ break;
+ case GPIO_LED_BLINK:
+ if (gpio_is_valid(gpio))
+ gpio_set_value(gpio, 0);
+ gpio_set_value(H1940_LATCH_LED_FLASH, 1);
+ gpio_set_value(blink_gpio, 1);
+ break;
+ }
+
+ spin_unlock(&h1940_blink_spin);
+
+ return 0;
+}
+EXPORT_SYMBOL(h1940_led_blink_set);
+
+static struct gpio_led h1940_leds_desc[] = {
+ {
+ .name = "Green",
+ .default_trigger = "main-battery-charging-or-full",
+ .gpio = H1940_LATCH_LED_GREEN,
+ .retain_state_suspended = 1,
+ },
+ {
+ .name = "Red",
+ .default_trigger = "main-battery-full",
+ .gpio = H1940_LATCH_LED_RED,
+ .retain_state_suspended = 1,
+ },
+};
+
+static struct gpio_led_platform_data h1940_leds_pdata = {
+ .num_leds = ARRAY_SIZE(h1940_leds_desc),
+ .leds = h1940_leds_desc,
+ .gpio_blink_set = h1940_led_blink_set,
+};
+
static struct platform_device h1940_device_leds = {
- .name = "h1940-leds",
- .id = -1,
+ .name = "leds-gpio",
+ .id = -1,
+ .dev = {
+ .platform_data = &h1940_leds_pdata,
+ },
};
static struct platform_device h1940_device_bluetooth = {
@@ -522,6 +602,15 @@ static void __init h1940_init(void)
platform_add_devices(h1940_devices, ARRAY_SIZE(h1940_devices));
+ gpio_request(S3C2410_GPA(1), "Red LED blink");
+ gpio_request(S3C2410_GPA(3), "Blue LED blink");
+ gpio_request(S3C2410_GPA(7), "Green LED blink");
+ gpio_request(H1940_LATCH_LED_FLASH, "LED blink");
+ gpio_direction_output(S3C2410_GPA(1), 0);
+ gpio_direction_output(S3C2410_GPA(3), 0);
+ gpio_direction_output(S3C2410_GPA(7), 0);
+ gpio_direction_output(H1940_LATCH_LED_FLASH, 0);
+
i2c_register_board_info(0, h1940_i2c_devices,
ARRAY_SIZE(h1940_i2c_devices));
}
--
1.7.3.2
^ permalink raw reply related
* [PATCH 2/7] ARM: S3C2410: H1940: Make h1940-bluetooth.c compile again
From: Vasily Khoruzhick @ 2011-01-06 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294343572-28518-1-git-send-email-anarsoul@gmail.com>
It was broken by removal of rfkill_set_led_trigger_name function,
and now compiler complains about implicit declaration.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
arch/arm/mach-s3c2410/h1940-bluetooth.c | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-s3c2410/h1940-bluetooth.c b/arch/arm/mach-s3c2410/h1940-bluetooth.c
index 6b86a72..6c59ef5 100644
--- a/arch/arm/mach-s3c2410/h1940-bluetooth.c
+++ b/arch/arm/mach-s3c2410/h1940-bluetooth.c
@@ -85,7 +85,6 @@ static int __devinit h1940bt_probe(struct platform_device *pdev)
s3c_gpio_cfgpin(S3C2410_GPH(3), S3C2410_GPH3_RXD0);
s3c_gpio_setpull(S3C2410_GPH(3), S3C_GPIO_PULL_NONE);
-
rfk = rfkill_alloc(DRV_NAME, &pdev->dev, RFKILL_TYPE_BLUETOOTH,
&h1940bt_rfkill_ops, NULL);
if (!rfk) {
@@ -93,8 +92,6 @@ static int __devinit h1940bt_probe(struct platform_device *pdev)
goto err_rfk_alloc;
}
- rfkill_set_led_trigger_name(rfk, "h1940-bluetooth");
-
ret = rfkill_register(rfk);
if (ret)
goto err_rfkill;
--
1.7.3.2
^ permalink raw reply related
* [PATCH 1/7] ARM: S3C2410: H1940: Add keys device
From: Vasily Khoruzhick @ 2011-01-06 19:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294343572-28518-1-git-send-email-anarsoul@gmail.com>
From: Arnaud Patard (Rtp) <arnaud.patard@rtp-net.org>
Add buttons definition for H1940.
Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
---
arch/arm/mach-s3c2410/mach-h1940.c | 39 ++++++++++++++++++++++++++++++++++++
1 files changed, 39 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-s3c2410/mach-h1940.c b/arch/arm/mach-s3c2410/mach-h1940.c
index 1a81fe1..641586a 100644
--- a/arch/arm/mach-s3c2410/mach-h1940.c
+++ b/arch/arm/mach-s3c2410/mach-h1940.c
@@ -23,6 +23,8 @@
#include <linux/platform_device.h>
#include <linux/io.h>
#include <linux/gpio.h>
+#include <linux/input.h>
+#include <linux/gpio_keys.h>
#include <linux/pwm_backlight.h>
#include <linux/i2c.h>
#include <video/platform_lcd.h>
@@ -381,7 +383,44 @@ static struct i2c_board_info h1940_i2c_devices[] = {
},
};
+#define DECLARE_BUTTON(p, k, n, w) \
+ { \
+ .gpio = p, \
+ .code = k, \
+ .desc = n, \
+ .wakeup = w, \
+ .active_low = 1, \
+ }
+
+static struct gpio_keys_button h1940_buttons[] = {
+ DECLARE_BUTTON(S3C2410_GPF(0), KEY_POWER, "Power", 1),
+ DECLARE_BUTTON(S3C2410_GPF(6), KEY_ENTER, "Select", 1),
+ DECLARE_BUTTON(S3C2410_GPF(7), KEY_RECORD, "Record", 0),
+ DECLARE_BUTTON(S3C2410_GPG(0), KEY_F11, "Calendar", 0),
+ DECLARE_BUTTON(S3C2410_GPG(2), KEY_F12, "Contacts", 0),
+ DECLARE_BUTTON(S3C2410_GPG(3), KEY_MAIL, "Mail", 0),
+ DECLARE_BUTTON(S3C2410_GPG(6), KEY_LEFT, "Left_arrow", 0),
+ DECLARE_BUTTON(S3C2410_GPG(7), KEY_HOMEPAGE, "Home", 0),
+ DECLARE_BUTTON(S3C2410_GPG(8), KEY_RIGHT, "Right_arrow", 0),
+ DECLARE_BUTTON(S3C2410_GPG(9), KEY_UP, "Up_arrow", 0),
+ DECLARE_BUTTON(S3C2410_GPG(10), KEY_DOWN, "Down_arrow", 0),
+};
+
+static struct gpio_keys_platform_data h1940_buttons_data = {
+ .buttons = h1940_buttons,
+ .nbuttons = ARRAY_SIZE(h1940_buttons),
+};
+
+static struct platform_device h1940_dev_buttons = {
+ .name = "gpio-keys",
+ .id = -1,
+ .dev = {
+ .platform_data = &h1940_buttons_data,
+ }
+};
+
static struct platform_device *h1940_devices[] __initdata = {
+ &h1940_dev_buttons,
&s3c_device_ohci,
&s3c_device_lcd,
&s3c_device_wdt,
--
1.7.3.2
^ permalink raw reply related
* [PATCH 0/7] ARM: S3C24XX: H1940 and RX1950 series
From: Vasily Khoruzhick @ 2011-01-06 19:52 UTC (permalink / raw)
To: linux-arm-kernel
This series improves HP iPAQ H1940 and RX1950 support.
Changes introduced by these patches:
1. Add support for H1940 buttons
2. Compile fix for h1940-bluetooth.c
3. Use leds-gpio to drive LEDs on H1940
4. Add support for battery monitoring and charging on H1940
5. Improve LCD power-on sequence
6. Retain LEDs state on RX1950 in suspend
7. Add support for HW LEDs blinking on RX1950
^ 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