Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH v2 1/2] watchdog: core: dt: add support for the timeout-sec dt property
From: Fabio Porcedda @ 2012-10-04  8:26 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1349339219-1467-1-git-send-email-fabio.porcedda@gmail.com>

Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
---
 Documentation/watchdog/watchdog-kernel-api.txt |  3 +++
 include/linux/watchdog.h                       | 15 +++++++++++++++
 2 files changed, 18 insertions(+)

diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt
index 086638f..35057b2 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -212,3 +212,6 @@ driver specific data to and a pointer to the data itself.
 The watchdog_get_drvdata function allows you to retrieve driver specific data.
 The argument of this function is the watchdog device where you want to retrieve
 data from. The function returns the pointer to the driver specific data.
+
+The watchdog_probe_dt_timeout function allows you to retrieve the timeout-sec
+property from the device tree.
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index da70f0f..18af39f 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -11,6 +11,7 @@
 
 #include <linux/ioctl.h>
 #include <linux/types.h>
+#include <linux/of.h>
 
 #define	WATCHDOG_IOCTL_BASE	'W'
 
@@ -174,6 +175,20 @@ static inline void *watchdog_get_drvdata(struct watchdog_device *wdd)
 	return wdd->driver_data;
 }
 
+/* Use the following function to retrieve the timeout-sec property from dt */
+static inline void watchdog_probe_dt_timeout(struct watchdog_device *wdd,
+					     struct device_node *node)
+{
+	unsigned int t = 0;
+
+	if (!node)
+		return;
+
+	of_property_read_u32(node, "timeout-sec", &t);
+	if ((t >= wdd->min_timeout) && (t <= wdd->max_timeout))
+		wdd->timeout = t;
+}
+
 /* drivers/watchdog/core/watchdog_core.c */
 extern int watchdog_register_device(struct watchdog_device *);
 extern void watchdog_unregister_device(struct watchdog_device *);
-- 
1.7.11.3

^ permalink raw reply related

* [RFC PATCH v2 0/2] watchdog: core: dt: add support for the timeout-sec dt property
From: Fabio Porcedda @ 2012-10-04  8:26 UTC (permalink / raw)
  To: linux-arm-kernel

Hi all,
this patchset add the timeout-sec property to the watchdog core,
in the next revision i will add the pnx4008 and s3c2410 driver.

changes:
v2:
  - change "timeout" to "timeout-sec" as asked by Jean-Christophe
  - at91sam9_wdt: use the new helper function
  - at91sam9_wdt: add bounds checking
  - watchdog.h: add bounds checking 

Fabio Porcedda (2):
  watchdog: core: dt: add support for the timeout-sec dt property
  watchdog: add timeout-sec property binding to some drivers

 .../devicetree/bindings/watchdog/atmel-wdt.txt     |  4 ++++
 .../devicetree/bindings/watchdog/marvel.txt        |  5 +++++
 Documentation/watchdog/watchdog-kernel-api.txt     |  3 +++
 drivers/watchdog/at91sam9_wdt.c                    | 23 ++++++++++++++++------
 drivers/watchdog/orion_wdt.c                       | 13 ++++++------
 include/linux/watchdog.h                           | 15 ++++++++++++++
 6 files changed, 51 insertions(+), 12 deletions(-)

-- 
1.7.11.3

^ permalink raw reply

* [PATCHv3 2/4] Input: keypad: Add smsc ece1099 keypad driver
From: Sourav @ 2012-10-04  8:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121004072426.GB14217@core.coreip.homeip.net>

Hi Dmitry,
On Thursday 04 October 2012 12:54 PM, Dmitry Torokhov wrote:
> On Wed, Oct 03, 2012 at 11:26:46AM +0530, Poddar, Sourav wrote:
>> Hi Dmitry,
>>
>> On Tue, Oct 2, 2012 at 11:48 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>>> Hi Sourav,
>>>
>>> On Mon, Oct 01, 2012 at 04:31:50PM +0530, Sourav Poddar wrote:
>>>> From: G, Manjunath Kondaiah <manjugk@ti.com>
>>>>
>>>> +
>>>> +     /* Enable smsc keypad interrupts */
>>>> +     ret = smsc_write(dev, SMSC_KP_INT_MASK, 0xff);
>>>> +     if (ret < 0)
>>>> +             goto err2;
>>>> +
>>>> +     return 0;
>>>> +
>>>> +err2:
>>>> +     input_unregister_device(input);
>>>> +err1:
>>>> +     input_free_device(input);
>>> Double free.
>>>
>> I believe what you are trying to say here is that we dont really
>> need a " input_unregister_device" (as also I checked in other keypad
>> implementations) and do a "unregister_device" in the remove api ??
> What I was trying to say is that if input device has been registered
> then you need to call input_unregister_device() to unregister and free
> it, otherwise you need to call input_free_device(), but not both.
>
> Thanks.
Ok. Thanks for the clarification. Will update and post a new version.

~Sourav

^ permalink raw reply

* [PATCH V2 3/3] spi: spi-pl022: Minor simplification for runtime pm
From: Ulf Hansson @ 2012-10-04  8:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1349337881-15917-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson@linaro.org>

In probe pm_runtime_put_autosuspend has the same effect as doing
pm_runtime_put. This due to upper layer in driver core is preventing
the device from being runtime suspended by a pm_runtime_get*.

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/spi/spi-pl022.c |    5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index a1db91a..51b7a95 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2246,10 +2246,9 @@ pl022_probe(struct amba_device *adev, const struct amba_id *id)
 		pm_runtime_set_autosuspend_delay(dev,
 			platform_info->autosuspend_delay);
 		pm_runtime_use_autosuspend(dev);
-		pm_runtime_put_autosuspend(dev);
-	} else {
-		pm_runtime_put(dev);
 	}
+	pm_runtime_put(dev);
+
 	return 0;
 
  err_spi_register:
-- 
1.7.10

^ permalink raw reply related

* [PATCH V2 2/3] Revert "spi/pl022: enable runtime PM"
From: Ulf Hansson @ 2012-10-04  8:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1349337881-15917-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson@linaro.org>

This reverts commit 2fb30d1147c599f5657e8c62c862f9a0f58d9d99.

This patch is reverted due to wrong runtime PM code.

Conflicts:

	drivers/spi/spi-pl022.c

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/spi/spi-pl022.c |    4 ----
 1 file changed, 4 deletions(-)

diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 5cf0643..a1db91a 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2186,9 +2186,6 @@ pl022_probe(struct amba_device *adev, const struct amba_id *id)
 	printk(KERN_INFO "pl022: mapped registers from 0x%08x to %p\n",
 	       adev->res.start, pl022->virtbase);
 
-	pm_runtime_enable(dev);
-	pm_runtime_resume(dev);
-
 	pl022->clk = devm_clk_get(&adev->dev, NULL);
 	if (IS_ERR(pl022->clk)) {
 		status = PTR_ERR(pl022->clk);
@@ -2293,7 +2290,6 @@ pl022_remove(struct amba_device *adev)
 
 	clk_disable(pl022->clk);
 	clk_unprepare(pl022->clk);
-	pm_runtime_disable(&adev->dev);
 	amba_release_regions(adev);
 	tasklet_disable(&pl022->pump_transfers);
 	spi_unregister_master(pl022->master);
-- 
1.7.10

^ permalink raw reply related

* [PATCH V2 1/3] Revert "spi/pl022: fix spi-pl022 pm enable at probe"
From: Ulf Hansson @ 2012-10-04  8:04 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1349337881-15917-1-git-send-email-ulf.hansson@stericsson.com>

From: Ulf Hansson <ulf.hansson@linaro.org>

This reverts commit 6887237cd7da904184dab2750504040c68f3a080.

This reverts is done due to earlier wrong commit, which is
also reverted. "Revert "spi/pl022: enable runtime PM""

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
---
 drivers/spi/spi-pl022.c |    1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index 9194641..5cf0643 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -2186,6 +2186,7 @@ pl022_probe(struct amba_device *adev, const struct amba_id *id)
 	printk(KERN_INFO "pl022: mapped registers from 0x%08x to %p\n",
 	       adev->res.start, pl022->virtbase);
 
+	pm_runtime_enable(dev);
 	pm_runtime_resume(dev);
 
 	pl022->clk = devm_clk_get(&adev->dev, NULL);
-- 
1.7.10

^ permalink raw reply related

* [PATCH V2 0/3] spi: spi-pl022: Fixup use of runtime pm
From: Ulf Hansson @ 2012-10-04  8:04 UTC (permalink / raw)
  To: linux-arm-kernel

From: Ulf Hansson <ulf.hansson@linaro.org>

Some old runtime pm patches got merged whiched messed up things.
These are now reverted. Additionaly one patch do a simplification
of the use of runtime pm functions.

V2:
Rebased patches and updated commit messages.

Ulf Hansson (3):
  Revert "spi/pl022: fix spi-pl022 pm enable at probe"
  Revert "spi/pl022: enable runtime PM"
  spi: spi-pl022: Minor simplification for runtime pm

 drivers/spi/spi-pl022.c |    8 ++------
 1 file changed, 2 insertions(+), 6 deletions(-)

-- 
1.7.10

^ permalink raw reply

* [PATCH 3/4] ARM: OMAP2: gpmc: Add support for BCH ECC scheme
From: Philip, Avinash @ 2012-10-04  8:03 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121003185458.GA27502@parrot.com>

On Thu, Oct 04, 2012 at 00:24:58, Ivan Djelic wrote:
> On Wed, Oct 03, 2012 at 03:29:48PM +0100, Philip, Avinash wrote:
> > Add support for BCH ECC scheme to gpmc driver and also enabling multi
> > sector read/write. This helps in doing single shot NAND page read and
> > write.
> > 
> > ECC engine configurations
> > BCH 4 bit support
> > 1. write => ECC engine configured in wrap mode 6 and with ecc_size0 as 32.
> > 2. read  => ECC engine configured in wrap mode 1 and with ecc_size0 as
> > 13 and ecc_size1 as 1.
> > 
> > BCH 8 bit support
> > 1. write => ECC engine configured in wrap mode 6 and with ecc_size0 as 32.
> > 2. read  => ECC engine configured in wrap mode 1 and with ecc_size0 as
> > 26 and ecc_size1 as 2.
> > 
> > Note: For BCH8 ECC bytes set to 14 to make compatible with RBL.
> > 
> 
> Hi Philip,
> 
> I have a few comments/questions below,
> 
> (...)
> > diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> > index 72428bd..c9bc3cf 100644
> > --- a/arch/arm/mach-omap2/gpmc.c
> > +++ b/arch/arm/mach-omap2/gpmc.c
> > @@ -24,6 +24,7 @@
> >  #include <linux/io.h>
> >  #include <linux/module.h>
> >  #include <linux/interrupt.h>
> > +#include <linux/mtd/nand.h>
> >  
> >  #include <asm/mach-types.h>
> >  #include <plat/gpmc.h>
> > @@ -83,6 +84,18 @@
> >  #define ENABLE_PREFETCH		(0x1 << 7)
> >  #define DMA_MPU_MODE		2
> >  
> > +/* GPMC ecc engine settings for read */
> > +#define BCH_WRAPMODE_1		1	/* BCH wrap mode 6 */
> 
> Comment should say "mode 1".

Ok I will correct it.

> 
> (...)
> >  /**
> > + * gpmc_calculate_ecc_bch	- Generate ecc bytes per block of 512 data bytes for entire page
> > + * @cs:  chip select number
> > + * @dat: The pointer to data on which ECC is computed
> > + * @ecc: The ECC output buffer
> > + */
> > +int gpmc_calculate_ecc_bch(int cs, const u_char *dat, u_char *ecc)
> > +{
> > +	int i, eccbchtsel;
> > +	u32 nsectors, reg, bch_val1, bch_val2, bch_val3, bch_val4;
> > +
> > +	if (gpmc_ecc_used != cs)
> > +		return -EINVAL;
> > +
> > +	/* read number of sectors for ecc to be calculated */
> > +	nsectors = ((gpmc_read_reg(GPMC_ECC_CONFIG) >> 4) & 0x7) + 1;
> > +	/*
> > +	 * find BCH scheme used
> > +	 * 0 -> BCH4
> > +	 * 1 -> BCH8
> > +	 */
> > +	eccbchtsel = ((gpmc_read_reg(GPMC_ECC_CONFIG) >> 12) & 0x3);
> > +
> > +	/* update ecc bytes for entire page */
> > +	for (i = 0; i < nsectors; i++) {
> > +
> > +		reg = GPMC_ECC_BCH_RESULT_0 + 16 * i;
> > +
> > +		/* Read hw-computed remainder */
> > +		bch_val1 = gpmc_read_reg(reg + 0);
> > +		bch_val2 = gpmc_read_reg(reg + 4);
> > +		if (eccbchtsel) {
> > +			bch_val3 = gpmc_read_reg(reg + 8);
> > +			bch_val4 = gpmc_read_reg(reg + 12);
> > +		}
> > +
> > +		if (eccbchtsel) {
> > +			/* BCH8 ecc scheme */
> > +			*ecc++ = (bch_val4 & 0xFF);
> > +			*ecc++ = ((bch_val3 >> 24) & 0xFF);
> > +			*ecc++ = ((bch_val3 >> 16) & 0xFF);
> > +			*ecc++ = ((bch_val3 >> 8) & 0xFF);
> > +			*ecc++ = (bch_val3 & 0xFF);
> > +			*ecc++ = ((bch_val2 >> 24) & 0xFF);
> > +			*ecc++ = ((bch_val2 >> 16) & 0xFF);
> > +			*ecc++ = ((bch_val2 >> 8) & 0xFF);
> > +			*ecc++ = (bch_val2 & 0xFF);
> > +			*ecc++ = ((bch_val1 >> 24) & 0xFF);
> > +			*ecc++ = ((bch_val1 >> 16) & 0xFF);
> > +			*ecc++ = ((bch_val1 >> 8) & 0xFF);
> > +			*ecc++ = (bch_val1 & 0xFF);
> > +			/* 14th byte of ecc not used */
> > +			*ecc++ = 0;
> > +		} else {
> > +			/* BCH4 ecc scheme */
> > +			*ecc++ = ((bch_val2 >> 12) & 0xFF);
> > +			*ecc++ = ((bch_val2 >> 4) & 0xFF);
> > +			*ecc++ = (((bch_val2 & 0xF) << 4) |
> > +					((bch_val1 >> 28) & 0xF));
> > +			*ecc++ = ((bch_val1 >> 20) & 0xFF);
> > +			*ecc++ = ((bch_val1 >> 12) & 0xFF);
> > +			*ecc++ = ((bch_val1 >> 4) & 0xFF);
> > +			*ecc++ = ((bch_val1 & 0xF) << 4);
> > +		}
> > +	}
> > +
> > +	gpmc_ecc_used = -EINVAL;
> > +	return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(gpmc_calculate_ecc_bch);
> 
> Here you introduce a function very similar to gpmc_calculate_ecc_bch4 and
> gpmc_calculate_ecc_bch8, but without the added benefit (IMHO) of the constant
> polynomial that allows to get an ecc sequence of 0xFFs for a buffer filled with
> 0xFFs. Why ?

I don't exactly understand what we benefitted/achieve. In my observation,
this API does spare area also written with 0xFF if data area is 0xFFs.
So the area looks like erased page again.

> If using the ELM prevents you from reusing gpmc_calculate_ecc_bch[48], could you explain in which way ?

When using gpmc_calculate_ecc_bch[48], calculated ecc values modified.
The read sequence we following is
Read 512 byte -> read ECC bytes from spare area
Now the calculated ECC will be zero if no error is reported. In case of error, a syndrome
Polynomial is reported. In either case modifying will corrupt the data.

This is valid if we are writing a page with 0xFF also. But this time we were filling a valid
ecc in spare area not 0xFF as in gpmc_calculate_ecc_bch[48].

Additionally to make compatible with RBL ECC layout (14 byte), we were setting ecc[13] as zero.

Thanks
Avinash  

> 
> Best regards,
> --
> Ivan
> 

^ permalink raw reply

* [PATCH] ARM: kirkwood: DT board setup for Network Space v2 and parents
From: Simon Guinot @ 2012-10-04  7:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121004055443.GK21046@lunn.ch>

On Thu, Oct 04, 2012 at 07:54:43AM +0200, Andrew Lunn wrote:
> > > > --- a/arch/arm/mach-kirkwood/board-dt.c
> > > > +++ b/arch/arm/mach-kirkwood/board-dt.c
> > > > @@ -96,6 +96,11 @@ static void __init kirkwood_dt_init(void)
> > > >  	if (of_machine_is_compatible("keymile,km_kirkwood"))
> > > >  		km_kirkwood_init();
> > > >  
> > > > +	if (of_machine_is_compatible("lacie,inetspace_v2") ||
> > > > +	    of_machine_is_compatible("lacie,netspace_v2") ||
> > > > +	    of_machine_is_compatible("lacie,netspace_max_v2"))
> > > > +		ns2_init();
> > > > +
> > > >  	of_platform_populate(NULL, kirkwood_dt_match_table,
> > > >  			     kirkwood_auxdata_lookup, NULL);
> > > 
> > > I'm not a DT policy expert. Could this be one compatibility string for
> > > all the boards? Maybe ask on the DT mainline list?
> > 
> > Maybe I could use "lacie,ns2_common" as a compatibility string. But this
> > does not match any existing device. I don't know if it is correct.
> 
> Hi Simon
> 
> I did a bit of looking around. For kirkwood, we already have two
> boards sharing the same compatibility string. kirkwood-dns320.dts and
> kirkwood-dns325.dts both have dlink,dns-kirkwood and this is what the
> board-dt.c matches on.
> 
> For the tegra20 soc, all boards match on nvidia,tegra20, and that is the only
> compatibility string in board-dt-tegra20.c.
> 
> So i don't see any problem having just one compatibility string here.
> 
> The question is, what is the appropriate name. How common is this
> common C code? Are there ns2 where this C code is not appropriate. One
> thing to remember is that most of this C code will soon disappear and
> become DT. All the mpp will be replaced with pinctrl in 3.8. I hope we
> can get the Ethernet setup in DT as well. You are working on ns2_led,
> so all the C code will be replaced by DT. So all we are really left
> with is power off GPIO handling.
> 
> So i think the danger of using lacie,ns2_common, and then finding it
> does not work with some other ns2 device is quite low.
> 
> What do you think?

The status for this ns2 boards is more or less end-of-life. I mean, this
boards are no longer in production. So I think it is safe to consider
the code inside board-ns2.c as common and shareable between ns2, is2 and
ns2max.

Once this file will be removed, the compatibility checks will be removed
as well. But one could easily forget to remove the useless compatibility
string "lacie,ns2_common" from the dts...

Let me know your preference.

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20121004/0802e67b/attachment.sig>

^ permalink raw reply

* [PATCH 2/4] mtd: devices: elm: Add support for ELM error correction
From: Philip, Avinash @ 2012-10-04  7:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.01.1210031701440.32543@pmeerw.net>

On Wed, Oct 03, 2012 at 20:40:46, Peter Meerwald wrote:
> 
> some minor nitpicks below
> 
> > + *
> > + * On completion of processing by elm module, error location status
> > + * register updated with correctable/uncorrectable error information.
> > + * In case of correctable errors, number of errors located from
> > + * elm location status register & read the these many positions from
> 
> should probably be: "... & read the positions from ..."?

Ok I will correct it.

> 
> > + * elm error location register.
> > + */
> > +static void elm_error_correction(struct elm_info *info,
> > +		struct elm_errorvec *err_vec)
> > +{
> > +	int i, j, errors = 0;
> > +	void *err_loc_base = info->elm_base + ELM_ERROR_LOCATION_0;
> > +	elm_error_t *err_loc;
> > +	void *offset;
> > +	u32 reg_val;
> > +
> > +	for (i = 0; i < ERROR_VECTOR_MAX; i++) {
> > +		/* check error reported */
> > +		if (err_vec[i].error_reported) {
> > +			offset = info->elm_base + ELM_LOCATION_STATUS +
> > +				i * ERROR_LOCATION_SIZE;
> > +			reg_val = elm_read_reg(offset);
> > +			/* check correctable error or not */
> > +			if (reg_val & ECC_CORRECTABLE_MASK) {
> > +				err_loc = err_loc_base +
> > +					i * ERROR_LOCATION_SIZE;
> > +				/* read count of correctable errors */
> > +				err_vec[i].error_count = reg_val &
> > +					ECC_NB_ERRORS_MASK;
> > +
> > +				/* update the error locations in error vector */
> > +				for (j = 0; j < err_vec[i].error_count; j++) {
> > +
> > +					reg_val = elm_read_reg(*err_loc + j);
> > +					err_vec[i].error_loc[j] = reg_val &
> > +						ECC_ERROR_LOCATION_MASK;
> > +				}
> > +
> > +				errors += err_vec[i].error_count;
> > +			} else {
> > +				err_vec[i].error_uncorrectable++;
> > +			}
> 
> extra braces above

As per coding style
This does not apply if only one branch of a conditional statement is a single
statement; in the latter case use braces in both branches:

> 
> > +
> > +			/* clearing interrupts for processed error vectors */
> > +			elm_write_reg(info->elm_base + ELM_IRQSTATUS, BIT(i));
> > +
> > +			/* disable page mode */
> > +			elm_configure_page_mode(info, i, false);
> > +		}
> > +	}
> > +
> > +	return;
> > +}
> > +
> > +/**
> > + * elm_decode_bch_error_page - Locate error position
> > + * @info:	elm info
> 
> should be dev, not info

Ok I will correct it.

> 
> > + * @ecc_calc:	calculated ECC bytes from GPMC
> > + * @err_vec:	elm error vectors
> > + *
> > + * Called with one or greater reported and is vectors with error reported
> > + * is updated in err_vec[].error_reported
> > + */
> 
> I do not understand the statement "Called with one ..."

elm_decode_bch_error_page() API will called from nand driver if and only if
errors are present while reading page. Errors can be reported in one or
multiple error vectors.

I will reword it as.

Called with one or more error reported vectors & vectors with error reported
is updated in err_vec[].error_reported

> 
[snip]
> > +
> > +#define BCH8_ECC_OOB_BYTES		13
> > +/* RBL requires 14 byte even though BCH8 uses only 13 byte */
> 
> not sure what RBL is?

RBL stands for Rom boot Loader

> 
> > +#define BCH8_SIZE			(BCH8_ECC_OOB_BYTES + 1)
> > +#define BCH4_SIZE			7
> > +
> > +#define	BCH8_SYNDROME_SIZE		4	/* 13 bytes of ecc */
> > +#define	BCH4_SYNDROME_SIZE		2	/* 7 bytes of ecc */
> > +
> > +/**
> > + * struct elm_errorvec - error vector for elm
> > + * @error_reported:		set true for vectors error is reported
> > + *
> > + * @error_count:		number of correctable errors in the sector
> > + * @error_uncorrectable:	number of uncorrectable errors
> > + * @error_loc:			buffer for error location
> > + *
> > + */
> > +struct elm_errorvec {
> > +	bool error_reported;
> > +	int error_count;
> > +	int error_uncorrectable;
> > +	int error_loc[ERROR_VECTOR_MAX];
> > +};
> > +
> > +void elm_decode_bch_error_page(struct device *dev, u8 *ecc_calc,
> > +		struct elm_errorvec *err_vec);
> > +struct device *elm_request(enum bch_ecc bch_type);
> > +#endif /* __ELM_H */
> > 
> 
> -- 
> 
> Peter Meerwald
> +43-664-2444418 (mobile)
> 

^ permalink raw reply

* [PATCH v1 01/14] media: s5p-hdmi: add HPD GPIO to platform data
From: RAHUL SHARMA @ 2012-10-04  7:39 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Mr. Tomasz, Mr. Park, list,

First patch in the following set belongs to s5p-media, rest to exynos-drm.
Please review the media patch so that It can be merged for mainline.

regards,
Rahul Sharma

On Thu, Oct 4, 2012 at 9:12 PM, Rahul Sharma <rahul.sharma@samsung.com> wrote:
> From: Tomasz Stanislawski <t.stanislaws@samsung.com>
>
> This patch extends s5p-hdmi platform data by a GPIO identifier for
> Hot-Plug-Detection pin.
>
> Signed-off-by: Tomasz Stanislawski <t.stanislaws@samsung.com>
> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
> ---
>  include/media/s5p_hdmi.h |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/include/media/s5p_hdmi.h b/include/media/s5p_hdmi.h
> index 361a751..181642b 100644
> --- a/include/media/s5p_hdmi.h
> +++ b/include/media/s5p_hdmi.h
> @@ -20,6 +20,7 @@ struct i2c_board_info;
>   * @hdmiphy_info: template for HDMIPHY I2C device
>   * @mhl_bus: controller id for MHL control bus
>   * @mhl_info: template for MHL I2C device
> + * @hpd_gpio: GPIO for Hot-Plug-Detect pin
>   *
>   * NULL pointer for *_info fields indicates that
>   * the corresponding chip is not present
> @@ -29,6 +30,7 @@ struct s5p_hdmi_platform_data {
>         struct i2c_board_info *hdmiphy_info;
>         int mhl_bus;
>         struct i2c_board_info *mhl_info;
> +       int hpd_gpio;
>  };
>
>  #endif /* S5P_HDMI_H */
> --
> 1.7.0.4
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH 2/2] mtd: delete nomadik_nand driver
From: Linus Walleij @ 2012-10-04  7:28 UTC (permalink / raw)
  To: linux-arm-kernel

The nomadik_nand driver is really just a subset of the FSMC
NAND driver, and there are no users anymore so let's delete
it.

Cc: Alessandro Rubini <rubini@unipv.it>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
I'm seeking the MTD maintainer(s) ACK for this patch so I can
merge it through the ARM SoC tree just after switching the
platform to using the FSMC driver.
---
 drivers/mtd/nand/Kconfig                       |   6 -
 drivers/mtd/nand/Makefile                      |   1 -
 drivers/mtd/nand/nomadik_nand.c                | 235 -------------------------
 include/linux/platform_data/mtd-nomadik-nand.h |  16 --
 4 files changed, 258 deletions(-)
 delete mode 100644 drivers/mtd/nand/nomadik_nand.c
 delete mode 100644 include/linux/platform_data/mtd-nomadik-nand.h

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 598cd0a..ec4acae 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -515,12 +515,6 @@ config MTD_NAND_MXC
 	  This enables the driver for the NAND flash controller on the
 	  MXC processors.
 
-config MTD_NAND_NOMADIK
-	tristate "ST Nomadik 8815 NAND support"
-	depends on ARCH_NOMADIK
-	help
-	  Driver for the NAND flash controller on the Nomadik, with ECC.
-
 config MTD_NAND_SH_FLCTL
 	tristate "Support for NAND on Renesas SuperH FLCTL"
 	depends on SUPERH || ARCH_SHMOBILE
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index d4b4d87..4d4e33a 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -45,7 +45,6 @@ obj-$(CONFIG_MTD_NAND_MXC)		+= mxc_nand.o
 obj-$(CONFIG_MTD_NAND_SOCRATES)		+= socrates_nand.o
 obj-$(CONFIG_MTD_NAND_TXX9NDFMC)	+= txx9ndfmc.o
 obj-$(CONFIG_MTD_NAND_NUC900)		+= nuc900_nand.o
-obj-$(CONFIG_MTD_NAND_NOMADIK)		+= nomadik_nand.o
 obj-$(CONFIG_MTD_NAND_BCM_UMI)		+= bcm_umi_nand.o nand_bcm_umi.o
 obj-$(CONFIG_MTD_NAND_MPC5121_NFC)	+= mpc5121_nfc.o
 obj-$(CONFIG_MTD_NAND_RICOH)		+= r852.o
diff --git a/drivers/mtd/nand/nomadik_nand.c b/drivers/mtd/nand/nomadik_nand.c
deleted file mode 100644
index 9ee0c4e..0000000
--- a/drivers/mtd/nand/nomadik_nand.c
+++ /dev/null
@@ -1,235 +0,0 @@
-/*
- *  drivers/mtd/nand/nomadik_nand.c
- *
- *  Overview:
- *  	Driver for on-board NAND flash on Nomadik Platforms
- *
- * Copyright ?? 2007 STMicroelectronics Pvt. Ltd.
- * Author: Sachin Verma <sachin.verma@st.com>
- *
- * Copyright ?? 2009 Alessandro Rubini
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- */
-
-#include <linux/init.h>
-#include <linux/module.h>
-#include <linux/types.h>
-#include <linux/mtd/mtd.h>
-#include <linux/mtd/nand.h>
-#include <linux/mtd/nand_ecc.h>
-#include <linux/platform_device.h>
-#include <linux/mtd/partitions.h>
-#include <linux/io.h>
-#include <linux/slab.h>
-#include <linux/platform_data/mtd-nomadik-nand.h>
-#include <mach/fsmc.h>
-
-#include <mtd/mtd-abi.h>
-
-struct nomadik_nand_host {
-	struct mtd_info		mtd;
-	struct nand_chip	nand;
-	void __iomem *data_va;
-	void __iomem *cmd_va;
-	void __iomem *addr_va;
-	struct nand_bbt_descr *bbt_desc;
-};
-
-static struct nand_ecclayout nomadik_ecc_layout = {
-	.eccbytes = 3 * 4,
-	.eccpos = { /* each subpage has 16 bytes: pos 2,3,4 hosts ECC */
-		0x02, 0x03, 0x04,
-		0x12, 0x13, 0x14,
-		0x22, 0x23, 0x24,
-		0x32, 0x33, 0x34},
-	/* let's keep bytes 5,6,7 for us, just in case we change ECC algo */
-	.oobfree = { {0x08, 0x08}, {0x18, 0x08}, {0x28, 0x08}, {0x38, 0x08} },
-};
-
-static void nomadik_ecc_control(struct mtd_info *mtd, int mode)
-{
-	/* No need to enable hw ecc, it's on by default */
-}
-
-static void nomadik_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
-{
-	struct nand_chip *nand = mtd->priv;
-	struct nomadik_nand_host *host = nand->priv;
-
-	if (cmd == NAND_CMD_NONE)
-		return;
-
-	if (ctrl & NAND_CLE)
-		writeb(cmd, host->cmd_va);
-	else
-		writeb(cmd, host->addr_va);
-}
-
-static int nomadik_nand_probe(struct platform_device *pdev)
-{
-	struct nomadik_nand_platform_data *pdata = pdev->dev.platform_data;
-	struct nomadik_nand_host *host;
-	struct mtd_info *mtd;
-	struct nand_chip *nand;
-	struct resource *res;
-	int ret = 0;
-
-	/* Allocate memory for the device structure (and zero it) */
-	host = kzalloc(sizeof(struct nomadik_nand_host), GFP_KERNEL);
-	if (!host) {
-		dev_err(&pdev->dev, "Failed to allocate device structure.\n");
-		return -ENOMEM;
-	}
-
-	/* Call the client's init function, if any */
-	if (pdata->init)
-		ret = pdata->init();
-	if (ret < 0) {
-		dev_err(&pdev->dev, "Init function failed\n");
-		goto err;
-	}
-
-	/* ioremap three regions */
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_addr");
-	if (!res) {
-		ret = -EIO;
-		goto err_unmap;
-	}
-	host->addr_va = ioremap(res->start, resource_size(res));
-
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_data");
-	if (!res) {
-		ret = -EIO;
-		goto err_unmap;
-	}
-	host->data_va = ioremap(res->start, resource_size(res));
-
-	res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "nand_cmd");
-	if (!res) {
-		ret = -EIO;
-		goto err_unmap;
-	}
-	host->cmd_va = ioremap(res->start, resource_size(res));
-
-	if (!host->addr_va || !host->data_va || !host->cmd_va) {
-		ret = -ENOMEM;
-		goto err_unmap;
-	}
-
-	/* Link all private pointers */
-	mtd = &host->mtd;
-	nand = &host->nand;
-	mtd->priv = nand;
-	nand->priv = host;
-
-	host->mtd.owner = THIS_MODULE;
-	nand->IO_ADDR_R = host->data_va;
-	nand->IO_ADDR_W = host->data_va;
-	nand->cmd_ctrl = nomadik_cmd_ctrl;
-
-	/*
-	 * This stanza declares ECC_HW but uses soft routines. It's because
-	 * HW claims to make the calculation but not the correction. However,
-	 * I haven't managed to get the desired data out of it until now.
-	 */
-	nand->ecc.mode = NAND_ECC_SOFT;
-	nand->ecc.layout = &nomadik_ecc_layout;
-	nand->ecc.hwctl = nomadik_ecc_control;
-	nand->ecc.size = 512;
-	nand->ecc.bytes = 3;
-
-	nand->options = pdata->options;
-
-	/*
-	 * Scan to find existence of the device
-	 */
-	if (nand_scan(&host->mtd, 1)) {
-		ret = -ENXIO;
-		goto err_unmap;
-	}
-
-	mtd_device_register(&host->mtd, pdata->parts, pdata->nparts);
-
-	platform_set_drvdata(pdev, host);
-	return 0;
-
- err_unmap:
-	if (host->cmd_va)
-		iounmap(host->cmd_va);
-	if (host->data_va)
-		iounmap(host->data_va);
-	if (host->addr_va)
-		iounmap(host->addr_va);
- err:
-	kfree(host);
-	return ret;
-}
-
-/*
- * Clean up routine
- */
-static int nomadik_nand_remove(struct platform_device *pdev)
-{
-	struct nomadik_nand_host *host = platform_get_drvdata(pdev);
-	struct nomadik_nand_platform_data *pdata = pdev->dev.platform_data;
-
-	if (pdata->exit)
-		pdata->exit();
-
-	if (host) {
-		nand_release(&host->mtd);
-		iounmap(host->cmd_va);
-		iounmap(host->data_va);
-		iounmap(host->addr_va);
-		kfree(host);
-	}
-	return 0;
-}
-
-static int nomadik_nand_suspend(struct device *dev)
-{
-	struct nomadik_nand_host *host = dev_get_drvdata(dev);
-	int ret = 0;
-	if (host)
-		ret = mtd_suspend(&host->mtd);
-	return ret;
-}
-
-static int nomadik_nand_resume(struct device *dev)
-{
-	struct nomadik_nand_host *host = dev_get_drvdata(dev);
-	if (host)
-		mtd_resume(&host->mtd);
-	return 0;
-}
-
-static const struct dev_pm_ops nomadik_nand_pm_ops = {
-	.suspend = nomadik_nand_suspend,
-	.resume = nomadik_nand_resume,
-};
-
-static struct platform_driver nomadik_nand_driver = {
-	.probe = nomadik_nand_probe,
-	.remove = nomadik_nand_remove,
-	.driver = {
-		.owner = THIS_MODULE,
-		.name = "nomadik_nand",
-		.pm = &nomadik_nand_pm_ops,
-	},
-};
-
-module_platform_driver(nomadik_nand_driver);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("ST Microelectronics (sachin.verma at st.com)");
-MODULE_DESCRIPTION("NAND driver for Nomadik Platform");
diff --git a/include/linux/platform_data/mtd-nomadik-nand.h b/include/linux/platform_data/mtd-nomadik-nand.h
deleted file mode 100644
index c3c8254..0000000
--- a/include/linux/platform_data/mtd-nomadik-nand.h
+++ /dev/null
@@ -1,16 +0,0 @@
-#ifndef __ASM_ARCH_NAND_H
-#define __ASM_ARCH_NAND_H
-
-struct nomadik_nand_platform_data {
-	struct mtd_partition *parts;
-	int nparts;
-	int options;
-	int (*init) (void);
-	int (*exit) (void);
-};
-
-#define NAND_IO_DATA	0x40000000
-#define NAND_IO_CMD	0x40800000
-#define NAND_IO_ADDR	0x41000000
-
-#endif				/* __ASM_ARCH_NAND_H */
-- 
1.7.11.4

^ permalink raw reply related

* [PATCH 1/2] ARM: nomadik: switch over to using the FSMC driver
From: Linus Walleij @ 2012-10-04  7:28 UTC (permalink / raw)
  To: linux-arm-kernel

The Nomadik NAND driver is really just a subset of the existing
FSMC driver, so let's switch over to using that driver instead,
since it handles more variants of this chip. The callbacks for
setting up the chip is doing stuff now handled by the FSMC
driver.

Cc: Alessandro Rubini <rubini@unipv.it>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
I'm requesting Mike Turquette's ACK on this patch so I can merge
it through ARM SoC.
---
 arch/arm/configs/nhk8815_defconfig        |  2 +-
 arch/arm/mach-nomadik/board-nhk8815.c     | 64 ++++++++++++++-----------------
 arch/arm/mach-nomadik/include/mach/fsmc.h | 29 --------------
 drivers/clk/clk-nomadik.c                 |  1 +
 4 files changed, 30 insertions(+), 66 deletions(-)
 delete mode 100644 arch/arm/mach-nomadik/include/mach/fsmc.h

diff --git a/arch/arm/configs/nhk8815_defconfig b/arch/arm/configs/nhk8815_defconfig
index bf123c5..9a8adfd 100644
--- a/arch/arm/configs/nhk8815_defconfig
+++ b/arch/arm/configs/nhk8815_defconfig
@@ -58,7 +58,7 @@ CONFIG_MTD_BLOCK=y
 CONFIG_MTD_NAND=y
 CONFIG_MTD_NAND_ECC_SMC=y
 CONFIG_MTD_NAND_VERIFY_WRITE=y
-CONFIG_MTD_NAND_NOMADIK=y
+CONFIG_MTD_NAND_FSMC=y
 CONFIG_MTD_ONENAND=y
 CONFIG_MTD_ONENAND_VERIFY_WRITE=y
 CONFIG_MTD_ONENAND_GENERIC=y
diff --git a/arch/arm/mach-nomadik/board-nhk8815.c b/arch/arm/mach-nomadik/board-nhk8815.c
index bfa1eab..a105d1b 100644
--- a/arch/arm/mach-nomadik/board-nhk8815.c
+++ b/arch/arm/mach-nomadik/board-nhk8815.c
@@ -19,6 +19,7 @@
 #include <linux/gpio.h>
 #include <linux/mtd/mtd.h>
 #include <linux/mtd/nand.h>
+#include <linux/mtd/fsmc.h>
 #include <linux/mtd/onenand.h>
 #include <linux/mtd/partitions.h>
 #include <linux/i2c.h>
@@ -36,7 +37,6 @@
 #include <plat/mtu.h>
 #include <plat/pincfg.h>
 
-#include <linux/platform_data/mtd-nomadik-nand.h>
 #include <mach/fsmc.h>
 
 #include "cpu-8815.h"
@@ -48,36 +48,18 @@
 /* These addresses span 16MB, so use three individual pages */
 static struct resource nhk8815_nand_resources[] = {
 	{
-		.name = "nand_addr",
-		.start = NAND_IO_ADDR,
-		.end = NAND_IO_ADDR + 0xfff,
-		.flags = IORESOURCE_MEM,
-	}, {
-		.name = "nand_cmd",
-		.start = NAND_IO_CMD,
-		.end = NAND_IO_CMD + 0xfff,
+		.name = "nand_data",
+		.start = 0x40000000,
+		.end = 0x40000000 + SZ_16K - 1,
 		.flags = IORESOURCE_MEM,
 	}, {
-		.name = "nand_data",
-		.start = NAND_IO_DATA,
-		.end = NAND_IO_DATA + 0xfff,
+		.name  = "fsmc_regs",
+		.start = NOMADIK_FSMC_BASE,
+		.end   = NOMADIK_FSMC_BASE + SZ_4K - 1,
 		.flags = IORESOURCE_MEM,
-	}
+	},
 };
 
-static int nhk8815_nand_init(void)
-{
-	/* FSMC setup for nand chip select (8-bit nand in 8815NHK) */
-	writel(0x0000000E, FSMC_PCR(0));
-	writel(0x000D0A00, FSMC_PMEM(0));
-	writel(0x00100A00, FSMC_PATT(0));
-
-	/* enable access to the chip select area */
-	writel(readl(FSMC_PCR(0)) | 0x04, FSMC_PCR(0));
-
-	return 0;
-}
-
 /*
  * These partitions are the same as those used in the 2.6.20 release
  * shipped by the vendor; the first two partitions are mandated
@@ -111,20 +93,30 @@ static struct mtd_partition nhk8815_partitions[] = {
 	}
 };
 
-static struct nomadik_nand_platform_data nhk8815_nand_data = {
-	.parts		= nhk8815_partitions,
-	.nparts		= ARRAY_SIZE(nhk8815_partitions),
-	.options	= NAND_COPYBACK | NAND_CACHEPRG | NAND_NO_PADDING,
-	.init		= nhk8815_nand_init,
+static struct fsmc_nand_timings nhk8815_nand_timings = {
+	.thiz	= 0,
+	.thold	= 0x10,
+	.twait	= 0x0A,
+	.tset	= 0,
+};
+
+static struct fsmc_nand_platform_data nhk8815_nand_platform_data = {
+	.nand_timings = &nhk8815_nand_timings,
+	.partitions = nhk8815_partitions,
+	.nr_partitions = ARRAY_SIZE(nhk8815_partitions),
+	.width = FSMC_NAND_BW8,
+	.ale_off = 0x1000000,
+	.cle_off = 0x800000,
 };
 
 static struct platform_device nhk8815_nand_device = {
-	.name		= "nomadik_nand",
-	.dev		= {
-		.platform_data = &nhk8815_nand_data,
+	.name = "fsmc-nand",
+	.id = -1,
+	.resource = nhk8815_nand_resources,
+	.num_resources = ARRAY_SIZE(nhk8815_nand_resources),
+	.dev = {
+		.platform_data = &nhk8815_nand_platform_data,
 	},
-	.resource	= nhk8815_nand_resources,
-	.num_resources	= ARRAY_SIZE(nhk8815_nand_resources),
 };
 
 /* These are the partitions for the OneNand device, different from above */
diff --git a/arch/arm/mach-nomadik/include/mach/fsmc.h b/arch/arm/mach-nomadik/include/mach/fsmc.h
deleted file mode 100644
index 8c2c051..0000000
--- a/arch/arm/mach-nomadik/include/mach/fsmc.h
+++ /dev/null
@@ -1,29 +0,0 @@
-
-/* Definitions for the Nomadik FSMC "Flexible Static Memory controller" */
-
-#ifndef __ASM_ARCH_FSMC_H
-#define __ASM_ARCH_FSMC_H
-
-#include <mach/hardware.h>
-/*
- * Register list
- */
-
-/* bus control reg. and bus timing reg. for CS0..CS3 */
-#define FSMC_BCR(x)     (NOMADIK_FSMC_VA + (x << 3))
-#define FSMC_BTR(x)     (NOMADIK_FSMC_VA + (x << 3) + 0x04)
-
-/* PC-card and NAND:
- * PCR = control register
- * PMEM = memory timing
- * PATT = attribute timing
- * PIO = I/O timing
- * PECCR = ECC result
- */
-#define FSMC_PCR(x)     (NOMADIK_FSMC_VA + ((2 + x) << 5) + 0x00)
-#define FSMC_PMEM(x)    (NOMADIK_FSMC_VA + ((2 + x) << 5) + 0x08)
-#define FSMC_PATT(x)    (NOMADIK_FSMC_VA + ((2 + x) << 5) + 0x0c)
-#define FSMC_PIO(x)     (NOMADIK_FSMC_VA + ((2 + x) << 5) + 0x10)
-#define FSMC_PECCR(x)   (NOMADIK_FSMC_VA + ((2 + x) << 5) + 0x14)
-
-#endif /* __ASM_ARCH_FSMC_H */
diff --git a/drivers/clk/clk-nomadik.c b/drivers/clk/clk-nomadik.c
index 517a8ff..6b4c70f 100644
--- a/drivers/clk/clk-nomadik.c
+++ b/drivers/clk/clk-nomadik.c
@@ -20,6 +20,7 @@ void __init nomadik_clk_init(void)
 	clk_register_clkdev(clk, NULL, "gpio.2");
 	clk_register_clkdev(clk, NULL, "gpio.3");
 	clk_register_clkdev(clk, NULL, "rng");
+	clk_register_clkdev(clk, NULL, "fsmc-nand");
 
 	/*
 	 * The 2.4 MHz TIMCLK reference clock is active@boot time, this is
-- 
1.7.11.4

^ permalink raw reply related

* [PATCHv3 2/4] Input: keypad: Add smsc ece1099 keypad driver
From: Dmitry Torokhov @ 2012-10-04  7:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAKdam55BEQi9tJb1yzKJWNhO7sHrW5NFHfsZjicw2NGYDEFovQ@mail.gmail.com>

On Wed, Oct 03, 2012 at 11:26:46AM +0530, Poddar, Sourav wrote:
> Hi Dmitry,
> 
> On Tue, Oct 2, 2012 at 11:48 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > Hi Sourav,
> >
> > On Mon, Oct 01, 2012 at 04:31:50PM +0530, Sourav Poddar wrote:
> >> From: G, Manjunath Kondaiah <manjugk@ti.com>
> >>
> >> +
> >> +     /* Enable smsc keypad interrupts */
> >> +     ret = smsc_write(dev, SMSC_KP_INT_MASK, 0xff);
> >> +     if (ret < 0)
> >> +             goto err2;
> >> +
> >> +     return 0;
> >> +
> >> +err2:
> >> +     input_unregister_device(input);
> >> +err1:
> >> +     input_free_device(input);
> >
> > Double free.
> >
> I believe what you are trying to say here is that we dont really
> need a " input_unregister_device" (as also I checked in other keypad
> implementations) and do a "unregister_device" in the remove api ??

What I was trying to say is that if input device has been registered
then you need to call input_unregister_device() to unregister and free
it, otherwise you need to call input_free_device(), but not both.

Thanks.

-- 
Dmitry

^ permalink raw reply

* [PATCH] ARM: davinci: dm644x: fix out range signal for ED
From: Sekhar Nori @ 2012-10-04  7:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CA+V-a8uFNXvb7bPv0dLKeSeNzZ9C3rvrXCNSWy+8HgiumR9sEw@mail.gmail.com>

On 10/4/2012 10:22 AM, Prabhakar Lad wrote:
> Hi Sekhar,
> 
> On Wed, Oct 3, 2012 at 4:08 PM, Sekhar Nori <nsekhar@ti.com> wrote:
>> On 10/3/2012 12:05 PM, Prabhakar wrote:
>>> From: Lad, Prabhakar <prabhakar.lad@ti.com>
>>>
>>> while testing display on dm644x, for ED out-range signals
>>> was observed. This patch fixes appropriate clock setting
>>> for ED.
>>
>> Can you please clarify what you mean by "out range signal"? Are there
>> any user visible artifacts on the display? What was the clock being
>> provided earlier and what is the value after this patch?
>>
>> Also, is the issue severe enough that this patch should be applied to
>> stable tree as well?
>>
> Ideally a clock of 54Mhz is required for  enhanced definition to
> work, which it was actually set to but while testing I noticed
> out-of-range signal. The out-of-range signal is often caused
> when the field rate is above the rate that the television will handle.
> When this is the case the TV or monitor displays "Out-Of-Range Signal".
> 
> Reducing the clock fixed it. now the clock is set to 27Mhz.

So, is the requirement for ED 54MHz or lower? Still trying to explain
myself how 27MHz is working where a 54MHz is required. I guess there is
also a lower limit on what the frequency should be?

Sorry I am not familiar will all the video concepts, hence the questions.

Thanks,
Sekhar

^ permalink raw reply

* linux-next: manual merge of the signal tree with the modules and arm-soc trees
From: Arnd Bergmann @ 2012-10-04  7:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20121004145241.fac039e78a15bb614cbd6da0@canb.auug.org.au>

On Thursday 04 October 2012, Stephen Rothwell wrote:
> Hi Al,
> 
> Today's linux-next merge of the signal tree got conflicts in
> arch/avr32/include/asm/Kbuild, arch/cris/include/asm/Kbuild,
> arch/frv/include/asm/Kbuild, arch/h8300/include/asm/Kbuild,
> arch/ia64/include/asm/Kbuild, arch/m32r/include/asm/Kbuild,
> arch/microblaze/include/asm/Kbuild, arch/mn10300/include/asm/Kbuild and
> arch/xtensa/include/asm/Kbuild between commit e7a570ff7dff ("asm-generic:
> Add default clkdev.h") from the arm-soc tree, commit 786d35d45cc4 ("Make
> most arch asm/module.h files use asm-generic/module.h") from the modules
> tree and commit ddd03a1f7591 ("get rid of generic instances of
> asm/exec.h") from the signal tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks for the three fixups. I was aware the conflicts would happen, but
your solutions are all correct. I had promised ot Mark a long time ago
to merge his patch and never actually done it.

My plan right now is to send the pull request after the other changes
have gone in and it's been in linux-next without new complaints for
a few days. The patch itself is very simple and should be harmless.

	Arnd

^ permalink raw reply

* usb: uhci-platform driver fails after patch changes during merge
From: Tony Prisk @ 2012-10-04  6:55 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1349332691.7583.3.camel@gitbox>

On Thu, 2012-10-04 at 19:38 +1300, Tony Prisk wrote:
> Mike,
> 
> I see someone made changes to the uhci-platform.c driver I submitted
> during v3.7 which results in it not working on mach-vt8500.
> 
> Could you clarify why the changes were made, and what the suggested
> resolution would be to solve the problem that it introduced?
> 
> Lines indicated by ---> below were removed from the patch, which means
> that on arch-vt8500 there is no dma_mask set, and its fails to
> communicate with attached devices.
> 
> Regards
> 
> Tony P
> 
> 
> static int __devinit uhci_hcd_platform_probe(struct platform_device
> *pdev)
> ...
> 	if (usb_disabled())
> 		return -ENODEV;
> --->
> 	/* Right now device-tree probed devices don't get dma_mask set.
> 	 * Since shared usb code relies on it, set it here for now.
> 	 * Once we have dma capability bindings this can go away.
> 	 */
> 	if (!pdev->dev.dma_mask)
> 		pdev->dev.dma_mask = &platform_uhci_dma_mask;
> --->
> 	hcd = usb_create_hcd(&uhci_platform_hc_driver, &pdev->dev,
> 				pdev->name);
> ...
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Greg,

This message was intended for you rather than Mike. Could you clarify
what happened and the expected resolution?

Regards

Tony P

^ permalink raw reply

* usb: uhci-platform driver fails after patch changes during merge
From: Tony Prisk @ 2012-10-04  6:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1349332691.7583.3.camel@gitbox>

On Thu, 2012-10-04 at 19:38 +1300, Tony Prisk wrote:
> Mike,
> 
> I see someone made changes to the uhci-platform.c driver I submitted
> during v3.7 which results in it not working on mach-vt8500.
> 
> Could you clarify why the changes were made, and what the suggested
> resolution would be to solve the problem that it introduced?
> 
> Lines indicated by ---> below were removed from the patch, which means
> that on arch-vt8500 there is no dma_mask set, and its fails to
> communicate with attached devices.
> 
> Regards
> 
> Tony P
> 
> 
> static int __devinit uhci_hcd_platform_probe(struct platform_device
> *pdev)
> ...
> 	if (usb_disabled())
> 		return -ENODEV;
> --->
> 	/* Right now device-tree probed devices don't get dma_mask set.
> 	 * Since shared usb code relies on it, set it here for now.
> 	 * Once we have dma capability bindings this can go away.
> 	 */
> 	if (!pdev->dev.dma_mask)
> 		pdev->dev.dma_mask = &platform_uhci_dma_mask;
> --->
> 	hcd = usb_create_hcd(&uhci_platform_hc_driver, &pdev->dev,
> 				pdev->name);
> ...
> 

Apologies Mike,

This isn't intended for you.

^ permalink raw reply

* [PATCH 3/3] clk: Don't return negative numbers for unsigned values with !clk
From: Stephen Boyd @ 2012-10-04  6:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1349332735-20096-1-git-send-email-sboyd@codeaurora.org>

Some of the helper functions return negative error codes if
passed a NULL clock. This can lead to confusing behavior when the
expected return value is unsigned. Fix up these accessors so that
they return unsigned values (or bool in the case of is_enabled).
This way we can't interpret NULL clocks as having valid and
interesting values.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 drivers/clk/clk.c            | 20 ++++++++++----------
 include/linux/clk-provider.h |  6 +++---
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 6852809..2847a66 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -262,7 +262,7 @@ inline struct clk_hw *__clk_get_hw(struct clk *clk)
 
 inline u8 __clk_get_num_parents(struct clk *clk)
 {
-	return !clk ? -EINVAL : clk->num_parents;
+	return !clk ? 0 : clk->num_parents;
 }
 
 inline struct clk *__clk_get_parent(struct clk *clk)
@@ -270,14 +270,14 @@ inline struct clk *__clk_get_parent(struct clk *clk)
 	return !clk ? NULL : clk->parent;
 }
 
-inline int __clk_get_enable_count(struct clk *clk)
+inline unsigned int __clk_get_enable_count(struct clk *clk)
 {
-	return !clk ? -EINVAL : clk->enable_count;
+	return !clk ? 0 : clk->enable_count;
 }
 
-inline int __clk_get_prepare_count(struct clk *clk)
+inline unsigned int __clk_get_prepare_count(struct clk *clk)
 {
-	return !clk ? -EINVAL : clk->prepare_count;
+	return !clk ? 0 : clk->prepare_count;
 }
 
 unsigned long __clk_get_rate(struct clk *clk)
@@ -303,15 +303,15 @@ out:
 
 inline unsigned long __clk_get_flags(struct clk *clk)
 {
-	return !clk ? -EINVAL : clk->flags;
+	return !clk ? 0 : clk->flags;
 }
 
-int __clk_is_enabled(struct clk *clk)
+bool __clk_is_enabled(struct clk *clk)
 {
 	int ret;
 
 	if (!clk)
-		return -EINVAL;
+		return false;
 
 	/*
 	 * .is_enabled is only mandatory for clocks that gate
@@ -324,7 +324,7 @@ int __clk_is_enabled(struct clk *clk)
 
 	ret = clk->ops->is_enabled(clk->hw);
 out:
-	return ret;
+	return !!ret;
 }
 
 static struct clk *__clk_lookup_subtree(const char *name, struct clk *clk)
@@ -569,7 +569,7 @@ unsigned long __clk_round_rate(struct clk *clk, unsigned long rate)
 	unsigned long parent_rate = 0;
 
 	if (!clk)
-		return -EINVAL;
+		return 0;
 
 	if (!clk->ops->round_rate) {
 		if (clk->flags & CLK_SET_RATE_PARENT)
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 0571261..3593a3c 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -341,11 +341,11 @@ const char *__clk_get_name(struct clk *clk);
 struct clk_hw *__clk_get_hw(struct clk *clk);
 u8 __clk_get_num_parents(struct clk *clk);
 struct clk *__clk_get_parent(struct clk *clk);
-inline int __clk_get_enable_count(struct clk *clk);
-inline int __clk_get_prepare_count(struct clk *clk);
+inline unsigned int __clk_get_enable_count(struct clk *clk);
+inline unsigned int __clk_get_prepare_count(struct clk *clk);
 unsigned long __clk_get_rate(struct clk *clk);
 unsigned long __clk_get_flags(struct clk *clk);
-int __clk_is_enabled(struct clk *clk);
+bool __clk_is_enabled(struct clk *clk);
 struct clk *__clk_lookup(const char *name);
 
 /*
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply related

* some question about armv7 cache operations
From: loody @ 2012-10-04  6:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CANudz+sbFPunRXGm9ehapd51zJ9ucbYvH0E_eAUQTHrP9cwDGw@mail.gmail.com>

hi all:
After studying Arm v7 document and trace kernel source code, I cannot
find any instruction which can tell us the tag and data value at
specific index/way.
Take v7 data cache for example,
we use
MCR     p15, 0, r11, c7, c6, 2

to invalidate data cache by set/way, where r11 put set/way format.

but if I need to know the tag/data value in set/way what r11 content,
is there any command I can adopt?

--
Regards,


-- 
Regards,

^ permalink raw reply

* [PATCH 2/3] clk: Fix documentation typos
From: Stephen Boyd @ 2012-10-04  6:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1349332735-20096-1-git-send-email-sboyd@codeaurora.org>

Fix some minor typos in the documentation for the ops structure.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 include/linux/clk-provider.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 5a548e3..0571261 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -57,9 +57,9 @@ struct clk_hw;
  * 		This function must not sleep. Optional, if this op is not
  * 		set then the enable count will be used.
  *
- * @recalc_rate	Recalculate the rate of this clock, by quering hardware.  The
+ * @recalc_rate	Recalculate the rate of this clock, by querying hardware. The
  * 		parent rate is an input parameter.  It is up to the caller to
- * 		insure that the prepare_mutex is held across this call.
+ * 		ensure that the prepare_mutex is held across this call.
  * 		Returns the calculated rate.  Optional, but recommended - if
  * 		this op is not set then clock rate will be initialized to 0.
  *
@@ -93,7 +93,7 @@ struct clk_hw;
  * implementations to split any work between atomic (enable) and sleepable
  * (prepare) contexts.  If enabling a clock requires code that might sleep,
  * this must be done in clk_prepare.  Clock enable code that will never be
- * called in a sleepable context may be implement in clk_enable.
+ * called in a sleepable context may be implemented in clk_enable.
  *
  * Typically, drivers will call clk_prepare when a clock may be needed later
  * (eg. when a device is opened), and clk_enable when the clock is actually
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply related

* [PATCH 1/3] clk: Document .is_enabled op
From: Stephen Boyd @ 2012-10-04  6:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1349332735-20096-1-git-send-email-sboyd@codeaurora.org>

Add the missing kernel-doc for this op.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
 include/linux/clk-provider.h | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 710c6cb..5a548e3 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -53,6 +53,10 @@ struct clk_hw;
  * @disable:	Disable the clock atomically. Called with enable_lock held.
  * 		This function must not sleep.
  *
+ * @is_enabled:	Queries the hardware to determine if the clock is enabled.
+ * 		This function must not sleep. Optional, if this op is not
+ * 		set then the enable count will be used.
+ *
  * @recalc_rate	Recalculate the rate of this clock, by quering hardware.  The
  * 		parent rate is an input parameter.  It is up to the caller to
  * 		insure that the prepare_mutex is held across this call.
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply related

* [PATCH 0/3] Minor fixes for generic clock framework
From: Stephen Boyd @ 2012-10-04  6:38 UTC (permalink / raw)
  To: linux-arm-kernel

This is a small set of patches that fixes some documentation
and fixes return values of functions that aren't used that
much yet. Noticed while going through this code.

Stephen Boyd (3):
  clk: Document .is_enabled op
  clk: Fix documentation typos
  clk: Don't return negative numbers for unsigned values with !clk

 drivers/clk/clk.c            | 20 ++++++++++----------
 include/linux/clk-provider.h | 16 ++++++++++------
 2 files changed, 20 insertions(+), 16 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

^ permalink raw reply

* usb: uhci-platform driver fails after patch changes during merge
From: Tony Prisk @ 2012-10-04  6:38 UTC (permalink / raw)
  To: linux-arm-kernel

Mike,

I see someone made changes to the uhci-platform.c driver I submitted
during v3.7 which results in it not working on mach-vt8500.

Could you clarify why the changes were made, and what the suggested
resolution would be to solve the problem that it introduced?

Lines indicated by ---> below were removed from the patch, which means
that on arch-vt8500 there is no dma_mask set, and its fails to
communicate with attached devices.

Regards

Tony P


static int __devinit uhci_hcd_platform_probe(struct platform_device
*pdev)
...
	if (usb_disabled())
		return -ENODEV;
--->
	/* Right now device-tree probed devices don't get dma_mask set.
	 * Since shared usb code relies on it, set it here for now.
	 * Once we have dma capability bindings this can go away.
	 */
	if (!pdev->dev.dma_mask)
		pdev->dev.dma_mask = &platform_uhci_dma_mask;
--->
	hcd = usb_create_hcd(&uhci_platform_hc_driver, &pdev->dev,
				pdev->name);
...

^ permalink raw reply

* [PATCH] pwm: Get rid of HAVE_PWM
From: Thierry Reding @ 2012-10-04  6:06 UTC (permalink / raw)
  To: linux-arm-kernel

Now that all drivers have been moved to the PWM subsystem, remove the
legacy HAVE_PWM symbol and replace it with the new PWM symbol. While at
it, select the PWM subsystem and corresponding PWM driver on boards that
require PWM functionality.

Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Eric Miao <eric.y.miao@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Bryan Wu <bryan.wu@canonical.com>
Cc: Richard Purdie <rpurdie@rpsys.net>
Cc: Samuel Ortiz <sameo@linux.intel.com>
Cc: Ashish Jangam <ashish.jangam@kpitcummins.com>
Cc: Andrew Jones <drjones@redhat.com>
Cc: linux-arm-kernel at lists.infradead.org
Cc: linux-kernel at vger.kernel.org
Cc: linux-mips at linux-mips.org
Cc: linux-input at vger.kernel.org
Cc: linux-leds at vger.kernel.org
---
 arch/arm/Kconfig           |  6 ++----
 arch/arm/mach-mxs/Kconfig  |  6 ++++--
 arch/arm/mach-pxa/Kconfig  | 42 ++++++++++++++++++++++++++++--------------
 arch/mips/Kconfig          |  3 ++-
 drivers/input/misc/Kconfig |  4 ++--
 drivers/leds/Kconfig       |  2 +-
 include/linux/pwm.h        |  2 +-
 7 files changed, 40 insertions(+), 25 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index e91c7cd..a0cebf8 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -69,9 +69,6 @@ config ARM_DMA_USE_IOMMU
 	select ARM_HAS_SG_CHAIN
 	bool
 
-config HAVE_PWM
-	bool
-
 config MIGHT_HAVE_PCI
 	bool
 
@@ -610,7 +607,8 @@ config ARCH_LPC32XX
 	select CLKDEV_LOOKUP
 	select GENERIC_CLOCKEVENTS
 	select USE_OF
-	select HAVE_PWM
+	select PWM
+	select PWM_LPC32XX
 	help
 	  Support for the NXP LPC32XX family of processors
 
diff --git a/arch/arm/mach-mxs/Kconfig b/arch/arm/mach-mxs/Kconfig
index 9a8bbda..2fc01bd 100644
--- a/arch/arm/mach-mxs/Kconfig
+++ b/arch/arm/mach-mxs/Kconfig
@@ -6,7 +6,8 @@ config SOC_IMX23
 	bool
 	select ARM_AMBA
 	select CPU_ARM926T
-	select HAVE_PWM
+	select PWM
+	select PWM_MXS
 	select PINCTRL_IMX23
 
 config SOC_IMX28
@@ -14,7 +15,8 @@ config SOC_IMX28
 	select ARM_AMBA
 	select CPU_ARM926T
 	select HAVE_CAN_FLEXCAN if CAN
-	select HAVE_PWM
+	select PWM
+	select PWM_MXS
 	select PINCTRL_IMX28
 
 comment "MXS platforms:"
diff --git a/arch/arm/mach-pxa/Kconfig b/arch/arm/mach-pxa/Kconfig
index fe2d1f8..14f41c3 100644
--- a/arch/arm/mach-pxa/Kconfig
+++ b/arch/arm/mach-pxa/Kconfig
@@ -33,12 +33,14 @@ config ARCH_LUBBOCK
 config MACH_MAINSTONE
 	bool "Intel HCDDBBVA0 Development Platform (aka Mainstone)"
 	select PXA27x
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 
 config MACH_ZYLONITE
 	bool
 	select PXA3xx
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 
 config MACH_ZYLONITE300
 	bool "PXA3xx Development Platform (aka Zylonite) PXA300/310"
@@ -78,7 +80,8 @@ config ARCH_VIPER
 	select PXA25x
 	select ISA
 	select I2C_GPIO
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 	select PXA_HAVE_ISA_IRQS
 	select ARCOM_PCMCIA
 
@@ -128,7 +131,8 @@ config MACH_CM_X300
 	select PXA3xx
 	select CPU_PXA300
 	select CPU_PXA310
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 
 config MACH_CAPC7117
 	bool "Embedian CAPC-7117 evaluation kit based on the MXM-8x10 CoM"
@@ -220,7 +224,8 @@ config TRIZEPS_PCMCIA
 config MACH_LOGICPD_PXA270
 	bool "LogicPD PXA270 Card Engine Development Platform"
 	select PXA27x
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 
 config MACH_PCM027
 	bool "Phytec phyCORE-PXA270 CPU module (PCM-027)"
@@ -229,7 +234,8 @@ config MACH_PCM027
 
 config MACH_PCM990_BASEBOARD
 	bool "PHYTEC PCM-990 development board"
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 	depends on MACH_PCM027
 
 choice
@@ -255,7 +261,8 @@ config MACH_COLIBRI_PXA270_INCOME
 	bool "Income s.r.o. PXA270 SBC"
 	depends on MACH_COLIBRI
 	select PXA27x
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 
 config MACH_COLIBRI300
 	bool "Toradex Colibri PXA300/310"
@@ -285,7 +292,8 @@ config MACH_H4700
 	bool "HP iPAQ hx4700"
 	select PXA27x
 	select IWMMXT
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 
 config MACH_H5000
 	bool "HP iPAQ h5000"
@@ -299,13 +307,15 @@ config MACH_MAGICIAN
 	bool "Enable HTC Magician Support"
 	select PXA27x
 	select IWMMXT
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 
 config MACH_MIOA701
 	bool "Mitac Mio A701 Support"
 	select PXA27x
 	select IWMMXT
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 	select GPIO_SYSFS
 	help
 	  Say Y here if you intend to run this kernel on a
@@ -316,7 +326,8 @@ config PXA_EZX
 	bool "Motorola EZX Platform"
 	select PXA27x
 	select IWMMXT
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 
 config MACH_EZX_A780
 	bool "Motorola EZX A780"
@@ -354,7 +365,8 @@ config MACH_MP900C
 
 config ARCH_PXA_PALM
 	bool "PXA based Palm PDAs"
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 
 config MACH_PALM27X
 	bool
@@ -454,7 +466,8 @@ config MACH_RAUMFELD_RC
 	select PXA3xx
 	select CPU_PXA300
 	select POWER_SUPPLY
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 
 config MACH_RAUMFELD_CONNECTOR
 	bool "Raumfeld Connector"
@@ -617,7 +630,8 @@ config MACH_E800
 config MACH_ZIPIT2
 	bool "Zipit Z2 Handheld"
 	select PXA27x
-	select HAVE_PWM
+	select PWM
+	select PWM_PXA
 endif
 endmenu
 
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 331d574..b38f23d 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -219,7 +219,8 @@ config MACH_JZ4740
 	select GENERIC_GPIO
 	select ARCH_REQUIRE_GPIOLIB
 	select SYS_HAS_EARLY_PRINTK
-	select HAVE_PWM
+	select PWM
+	select PWM_JZ4740
 	select HAVE_CLK
 	select GENERIC_IRQ_CHIP
 
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7c0f1ec..af6188b 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -146,7 +146,7 @@ config INPUT_MAX8925_ONKEY
 
 config INPUT_MAX8997_HAPTIC
 	tristate "MAXIM MAX8997 haptic controller support"
-	depends on HAVE_PWM && MFD_MAX8997
+	depends on PWM && MFD_MAX8997
 	select INPUT_FF_MEMLESS
 	help
 	  This option enables device driver support for the haptic controller
@@ -444,7 +444,7 @@ config INPUT_PCF8574
 
 config INPUT_PWM_BEEPER
 	tristate "PWM beeper support"
-	depends on HAVE_PWM
+	depends on PWM
 	help
 	  Say Y here to get support for PWM based beeper devices.
 
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index c96bbaa..a720d99 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -298,7 +298,7 @@ config LEDS_DAC124S085
 config LEDS_PWM
 	tristate "PWM driven LED Support"
 	depends on LEDS_CLASS
-	depends on HAVE_PWM
+	depends on PWM
 	help
 	  This option enables support for pwm driven LEDs
 
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 112b314..eea3f26 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -7,7 +7,7 @@
 struct pwm_device;
 struct seq_file;
 
-#if IS_ENABLED(CONFIG_PWM) || IS_ENABLED(CONFIG_HAVE_PWM)
+#if IS_ENABLED(CONFIG_PWM)
 /*
  * pwm_request - request a PWM device
  */
-- 
1.7.12.2

^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox