Re: [PATCH v2] i2c: omap: re-factor omap_i2c_init function
On Thu, Oct 25, 2012 at 12:06 PM, Felipe Balbi wrote:
> Hi,
>
> On Thu, Oct 25, 2012 at 12:06:51PM +0530, Shubhrajyoti D wrote:
>> re-factor omap_i2c_init() so that we can re-use it for resume.
>> While at it also remove the bufstate variable as we write it
>> in omap_i2c_resize_fifo for every transfer.
>>
>> Signed-off-by: Shubhrajyoti D
>> ---
>> v2 - add the iestate 0 check back.
>>- Remove a stray change.
>> - Applies on top of Felipe's patches.
>> http://www.spinics.net/lists/linux-omap/msg79995.html
>>
>>
>> Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
>> on omap3636 beagle both idle and suspend.
>>
>> Functional testing on omap4sdp.
>>
>> drivers/i2c/busses/i2c-omap.c | 71
>> ++--
>> 1 files changed, 32 insertions(+), 39 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
>> index 5e5cefb..3d400b1 100644
>> --- a/drivers/i2c/busses/i2c-omap.c
>> +++ b/drivers/i2c/busses/i2c-omap.c
>> @@ -209,7 +209,6 @@ struct omap_i2c_dev {
>> u16 pscstate;
>> u16 scllstate;
>> u16 sclhstate;
>> - u16 bufstate;
>> u16 syscstate;
>> u16 westate;
>> u16 errata;
>> @@ -285,9 +284,31 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
>> *i2c_dev, int reg)
>> }
>> }
>>
>> +static void __omap_i2c_init(struct omap_i2c_dev *dev)
>> +{
>> +
>> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
>> + /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
>> + omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
>> +
>> + /* SCL low and high time values */
>> + omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
>> + omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
>> + if (dev->rev >= OMAP_I2C_REV_ON_3430_3530)
>> + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
>> + /* Take the I2C module out of reset: */
>> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
>
> a few blank lines in this function wouldn't hurt and they would help
> with readability.
Will add .
>
>> + /*
>> + * Don't write to this register if the IE state is 0 as it can
>> + * cause deadlock.
>> + */
>> + if (dev->iestate)
>> + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
>> +}
>> +
>> static int omap_i2c_init(struct omap_i2c_dev *dev)
>> {
>> - u16 psc = 0, scll = 0, sclh = 0, buf = 0;
>> + u16 psc = 0, scll = 0, sclh = 0;
>> u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
>> unsigned long fclk_rate = 1200;
>> unsigned long timeout;
>> @@ -337,11 +358,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>>* REVISIT: Some wkup sources might not be needed.
>>*/
>> dev->westate = OMAP_I2C_WE_ALL;
>> - omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
>> - dev->westate);
>
> remove the comment too since now that's done by some other function ?
>
>> }
>> }
>> - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
>>
>> if (dev->flags & OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
>> /*
>> @@ -426,28 +444,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>> sclh = fclk_rate / (dev->speed * 2) - 7 + psc;
>> }
>>
>> - /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
>> - omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
>> -
>> - /* SCL low and high time values */
>> - omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
>> - omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
>> -
>> - /* Take the I2C module out of reset: */
>> - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
>> -
>> /* Enable interrupts */
>> dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
>> OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL) |
>> ((dev->fifo_size) ? (OMAP_I2C_IE_RDR |
>> OMAP_I2C_IE_XDR) : 0);
>> - omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
>> - if (dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
>> - dev->pscstate = psc;
>> - dev->scllstate = scll;
>> - dev->sclhstate = sclh;
>> - dev->bufstate = buf;
>> - }
>> +
>> + dev->pscstate = psc;
>> + dev->scllstate = scll;
>> + dev->sclhstate = sclh;
>> +
>> + __omap_i2c_init(dev);
>> +
>> return 0;
>> }
>>
>> @@ -1268,23 +1276,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
>> {
>> struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
>>
>> - if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
>> - oma
Re: [PATCH v2] i2c: omap: re-factor omap_i2c_init function
Hi,
On Thu, Oct 25, 2012 at 12:06:51PM +0530, Shubhrajyoti D wrote:
> re-factor omap_i2c_init() so that we can re-use it for resume.
> While at it also remove the bufstate variable as we write it
> in omap_i2c_resize_fifo for every transfer.
>
> Signed-off-by: Shubhrajyoti D
> ---
> v2 - add the iestate 0 check back.
>- Remove a stray change.
> - Applies on top of Felipe's patches.
> http://www.spinics.net/lists/linux-omap/msg79995.html
>
>
> Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
> on omap3636 beagle both idle and suspend.
>
> Functional testing on omap4sdp.
>
> drivers/i2c/busses/i2c-omap.c | 71 ++--
> 1 files changed, 32 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index 5e5cefb..3d400b1 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -209,7 +209,6 @@ struct omap_i2c_dev {
> u16 pscstate;
> u16 scllstate;
> u16 sclhstate;
> - u16 bufstate;
> u16 syscstate;
> u16 westate;
> u16 errata;
> @@ -285,9 +284,31 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
> *i2c_dev, int reg)
> }
> }
>
> +static void __omap_i2c_init(struct omap_i2c_dev *dev)
> +{
> +
> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
> + /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
> + omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
> +
> + /* SCL low and high time values */
> + omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
> + omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
> + if (dev->rev >= OMAP_I2C_REV_ON_3430_3530)
> + omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
> + /* Take the I2C module out of reset: */
> + omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
a few blank lines in this function wouldn't hurt and they would help
with readability.
> + /*
> + * Don't write to this register if the IE state is 0 as it can
> + * cause deadlock.
> + */
> + if (dev->iestate)
> + omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
> +}
> +
> static int omap_i2c_init(struct omap_i2c_dev *dev)
> {
> - u16 psc = 0, scll = 0, sclh = 0, buf = 0;
> + u16 psc = 0, scll = 0, sclh = 0;
> u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
> unsigned long fclk_rate = 1200;
> unsigned long timeout;
> @@ -337,11 +358,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
>* REVISIT: Some wkup sources might not be needed.
>*/
> dev->westate = OMAP_I2C_WE_ALL;
> - omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
> - dev->westate);
remove the comment too since now that's done by some other function ?
> }
> }
> - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
>
> if (dev->flags & OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
> /*
> @@ -426,28 +444,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> sclh = fclk_rate / (dev->speed * 2) - 7 + psc;
> }
>
> - /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
> - omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
> -
> - /* SCL low and high time values */
> - omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
> - omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
> -
> - /* Take the I2C module out of reset: */
> - omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
> -
> /* Enable interrupts */
> dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
> OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL) |
> ((dev->fifo_size) ? (OMAP_I2C_IE_RDR |
> OMAP_I2C_IE_XDR) : 0);
> - omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
> - if (dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
> - dev->pscstate = psc;
> - dev->scllstate = scll;
> - dev->sclhstate = sclh;
> - dev->bufstate = buf;
> - }
> +
> + dev->pscstate = psc;
> + dev->scllstate = scll;
> + dev->sclhstate = sclh;
> +
> + __omap_i2c_init(dev);
> +
> return 0;
> }
>
> @@ -1268,23 +1276,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
> {
> struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
>
> - if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
> - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->sclls
[PATCH v2] i2c: omap: re-factor omap_i2c_init function
re-factor omap_i2c_init() so that we can re-use it for resume.
While at it also remove the bufstate variable as we write it
in omap_i2c_resize_fifo for every transfer.
Signed-off-by: Shubhrajyoti D
---
v2 - add the iestate 0 check back.
- Remove a stray change.
- Applies on top of Felipe's patches.
http://www.spinics.net/lists/linux-omap/msg79995.html
Tested with Terro sys fix + Felipe's stop sched_clock() during suspend
on omap3636 beagle both idle and suspend.
Functional testing on omap4sdp.
drivers/i2c/busses/i2c-omap.c | 71 ++--
1 files changed, 32 insertions(+), 39 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5e5cefb..3d400b1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -209,7 +209,6 @@ struct omap_i2c_dev {
u16 pscstate;
u16 scllstate;
u16 sclhstate;
- u16 bufstate;
u16 syscstate;
u16 westate;
u16 errata;
@@ -285,9 +284,31 @@ static inline u16 omap_i2c_read_reg(struct omap_i2c_dev
*i2c_dev, int reg)
}
}
+static void __omap_i2c_init(struct omap_i2c_dev *dev)
+{
+
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
+ /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
+ omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, dev->pscstate);
+
+ /* SCL low and high time values */
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, dev->scllstate);
+ omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, dev->sclhstate);
+ if (dev->rev >= OMAP_I2C_REV_ON_3430_3530)
+ omap_i2c_write_reg(dev, OMAP_I2C_WE_REG, dev->westate);
+ /* Take the I2C module out of reset: */
+ omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
+ /*
+* Don't write to this register if the IE state is 0 as it can
+* cause deadlock.
+*/
+ if (dev->iestate)
+ omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
+}
+
static int omap_i2c_init(struct omap_i2c_dev *dev)
{
- u16 psc = 0, scll = 0, sclh = 0, buf = 0;
+ u16 psc = 0, scll = 0, sclh = 0;
u16 fsscll = 0, fssclh = 0, hsscll = 0, hssclh = 0;
unsigned long fclk_rate = 1200;
unsigned long timeout;
@@ -337,11 +358,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
* REVISIT: Some wkup sources might not be needed.
*/
dev->westate = OMAP_I2C_WE_ALL;
- omap_i2c_write_reg(dev, OMAP_I2C_WE_REG,
- dev->westate);
}
}
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
if (dev->flags & OMAP_I2C_FLAG_ALWAYS_ARMXOR_CLK) {
/*
@@ -426,28 +444,18 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
sclh = fclk_rate / (dev->speed * 2) - 7 + psc;
}
- /* Setup clock prescaler to obtain approx 12MHz I2C module clock: */
- omap_i2c_write_reg(dev, OMAP_I2C_PSC_REG, psc);
-
- /* SCL low and high time values */
- omap_i2c_write_reg(dev, OMAP_I2C_SCLL_REG, scll);
- omap_i2c_write_reg(dev, OMAP_I2C_SCLH_REG, sclh);
-
- /* Take the I2C module out of reset: */
- omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
-
/* Enable interrupts */
dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
OMAP_I2C_IE_NACK | OMAP_I2C_IE_AL) |
((dev->fifo_size) ? (OMAP_I2C_IE_RDR |
OMAP_I2C_IE_XDR) : 0);
- omap_i2c_write_reg(dev, OMAP_I2C_IE_REG, dev->iestate);
- if (dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- dev->pscstate = psc;
- dev->scllstate = scll;
- dev->sclhstate = sclh;
- dev->bufstate = buf;
- }
+
+ dev->pscstate = psc;
+ dev->scllstate = scll;
+ dev->sclhstate = sclh;
+
+ __omap_i2c_init(dev);
+
return 0;
}
@@ -1268,23 +1276,8 @@ static int omap_i2c_runtime_resume(struct device *dev)
{
struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
- if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
- omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
- omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG, _dev->scllstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG, _dev->sclhstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG, _dev->syscstate);
- omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
- omap_
Re: [PATCH] drivers: bus: omap_interconnect: Fix rand-config build warning
On Thursday 25 October 2012 06:12 AM, Tony Lindgren wrote: * Tony Lindgren [121024 17:36]: * Santosh Shilimkar [121017 06:35]: (Looping Arnd and Olof) On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote: When building omap_l3_noc/smx drivers as modules, the following warning appears: CC [M] drivers/bus/omap_l3_smx.o drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or storage class drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in declaration of 'postcore_initcall_sync' drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in function declaration drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used CC [M] drivers/bus/omap_l3_noc.o drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or storage class drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in declaration of 'arch_initcall_sync' drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in function declaration drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used Adding module_init() and macros in omap_l3_noc/smx drivers when building as modules to remove the above warning. Reported-by: Tony Lindgren Signed-off-by: Lokesh Vutla --- Thanks for the fix Lokesh. Looks fine to me. Acked-by: Santosh Shilimkar Looks like nobody else has picked this up so I'll queue this along with few other omap warnings and regressions. Hmm actually this might require some more discussion. If we make it use regular initcalls, then the ugly ifdefs can be left out. Is there a reason to init this early, can't we just use regular initcalls? I thought about it. The whole reason we want interconnect errors enabled early in the boot to avoid bad accesses issued on interconnect in early boot by various init codes. We managed to discovered many init sequence issues where the a driver is trying to access registers when clocks are not active, or drivers are using bad mapping. At times these errors gets un-noticed because of the behavior of interconnect and later causes serious issues. Leaving the driver init late in the boot means we can't catch any of the issues happen till the L3 driver init happens. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support
Hi, On Wed, Oct 24, 2012 at 05:48:07PM -0700, Tony Lindgren wrote: > * Tony Lindgren [121016 09:53]: > > * Kishon Vijay Abraham I [121007 23:01]: > > > ocp2scp was not having pdata support which makes *musb* fail for non-dt > > > boot in OMAP platform. The pdata will have information about the devices > > > that is connected to ocp2scp. ocp2scp driver will now make use of this > > > information to create the devices that is attached to ocp2scp. > > > > > > Signed-off-by: Kishon Vijay Abraham I > > > > This fixes the regression on my panda es for musb port: > > > > Acked-by: Tony Lindgren > > Looks like nobody has picked this one up and we need it to > fix the musb regression on omap, so I'll queue these up. I don't seem to have the patches around in any mailbox :-( -- balbi signature.asc Description: Digital signature
Re: [PATCH v2 1/2] USB: dwc3-exynos: Add support for device tree
Hi,
On Tue, Oct 16, 2012 at 3:38 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 16, 2012 at 03:36:43PM +0530, kishon wrote:
>> Hi,
>>
>> On Tuesday 16 October 2012 03:23 PM, Felipe Balbi wrote:
>> >On Tue, Oct 16, 2012 at 02:15:56PM +0530, Vivek Gautam wrote:
>> >>This patch adds support to parse probe data for
>> >>dwc3-exynos driver using device tree.
>> >>
>> >>Signed-off-by: Vivek Gautam
>> >>---
>> >> drivers/usb/dwc3/dwc3-exynos.c | 20
>> >> 1 files changed, 20 insertions(+), 0 deletions(-)
>> >>
>> >>diff --git a/drivers/usb/dwc3/dwc3-exynos.c
>> >>b/drivers/usb/dwc3/dwc3-exynos.c
>> >>index ca65978..d11ef49 100644
>> >>--- a/drivers/usb/dwc3/dwc3-exynos.c
>> >>+++ b/drivers/usb/dwc3/dwc3-exynos.c
>> >>@@ -21,6 +21,7 @@
>> >> #include
>> >> #include
>> >> #include
>> >>+#include
>> >>
>> >> #include "core.h"
>> >>
>> >>@@ -87,6 +88,8 @@ err1:
>> >>return ret;
>> >> }
>> >>
>> >>+static u64 dwc3_exynos_dma_mask = DMA_BIT_MASK(32);
>> >>+
>> >> static int __devinit dwc3_exynos_probe(struct platform_device *pdev)
>> >> {
>> >>struct dwc3_exynos_data *pdata = pdev->dev.platform_data;
>> >>@@ -103,6 +106,14 @@ static int __devinit dwc3_exynos_probe(struct
>> >>platform_device *pdev)
>> >>goto err0;
>> >>}
>> >>
>> >>+ /*
>> >>+* 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 move to full device tree support this will vanish off.
>> >>+*/
>> >>+ if (!pdev->dev.dma_mask)
>> >>+ pdev->dev.dma_mask = &dwc3_exynos_dma_mask;
>> >
>> >says who ?
>> >
>> >$ git grep -e dma_mask drivers/of/
>> >drivers/of/platform.c: dev->dev.dma_mask = &dev->archdata.dma_mask;
>> >drivers/of/platform.c: dev->archdata.dma_mask = 0xUL;
>> >drivers/of/platform.c: dev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> >drivers/of/platform.c: dev->dev.coherent_dma_mask = ~0;
>> >drivers/of/platform.c: dev->dma_mask = ~0;
>> >
>> >-ECONFUSED
>>
>> dma_mask is set under some ifdef except for "dev->dma_mask = ~0;".
>> However I agree with you for coherent_dma_mask case.
>
> indeed. Should we try to patch that instead ?
>
> Rob, should we set dma_mask at the driver or do you have a nicer way to
> handle it ??
>
Can i have suggestions here please ? :)
> --
> balbi
>
> ___
> devicetree-discuss mailing list
> devicetree-disc...@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/devicetree-discuss
>
Thanks & Regards
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: re-factor omap_i2c_init function
On Tue, Oct 23, 2012 at 11:27 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Oct 23, 2012 at 11:26:15PM +0530, Shubhrajyoti Datta wrote:
>> >> @@ -1268,23 +1271,8 @@ static int omap_i2c_runtime_resume(struct device
>> >> *dev)
>> >> {
>> >> struct omap_i2c_dev *_dev = dev_get_drvdata(dev);
>> >>
>> >> - if (_dev->flags & OMAP_I2C_FLAG_RESET_REGS_POSTIDLE) {
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, 0);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_PSC_REG, _dev->pscstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLL_REG,
>> >> _dev->scllstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SCLH_REG,
>> >> _dev->sclhstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_BUF_REG, _dev->bufstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_SYSC_REG,
>> >> _dev->syscstate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_WE_REG, _dev->westate);
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_CON_REG, OMAP_I2C_CON_EN);
>> >> - }
>> >> -
>> >> - /*
>> >> - * Don't write to this register if the IE state is 0 as it can
>> >> - * cause deadlock.
>> >> - */
>> >> - if (_dev->iestate)
>> >> - omap_i2c_write_reg(_dev, OMAP_I2C_IE_REG, _dev->iestate);
>> >
>> > this part is not on __omap_i2c_init() so you're potentially causing a
>> > regression here.
>>
>> iestate is set at init so cannot be zero. so the check was removed.
>
Hmm thinking a little more, there is a case that I missed the resume
handler may get called before
the omap_i2c_init will restore the check and send another version.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: omap: re-factor omap_i2c_init function
On 10/24/2012 12:41 AM, Felipe Balbi wrote: >return 0; >} another thing, the few places in omap_i2c_xfer_msg() which are currently calling omap_i2c_init() should also be converted to call the newly added __omap_i2c_init(). We don't need to recalculate any of those clock dividers and whatnot. Yes in fact omap_i2c_init() can be reset - calculate - and __omap_i2c_init. Then in those places the recalculate can be optimised. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
On 10/22/2012 02:55 PM, Daniel Mack wrote:
> This patch adds basic DT bindings for OMAP GPMC.
>
> The actual peripherals are instanciated from child nodes within the GPMC
> node, and the only type of device that is currently supported is NAND.
>
> Code was added to parse the generic GPMC timing parameters and some
> documentation with examples on how to use them.
>
> Successfully tested on an AM33xx board.
>
> Signed-off-by: Daniel Mack
> ---
> Documentation/devicetree/bindings/bus/gpmc.txt | 59 +
> .../devicetree/bindings/mtd/gpmc-nand.txt | 65 ++
> arch/arm/mach-omap2/gpmc.c | 139
> +
> 3 files changed, 263 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/gpmc.txt
> create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/gpmc.txt
> b/Documentation/devicetree/bindings/bus/gpmc.txt
> new file mode 100644
> index 000..ef1c6e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/gpmc.txt
> @@ -0,0 +1,59 @@
> +Device tree bindings for OMAP general purpose memory controllers (GPMC)
> +
> +The actual devices are instantiated from the child nodes of a GPMC node.
> +
> +Required properties:
> +
> + - compatible: Should be set to "ti,gpmc"
> +
> +Timing properties for child nodes. All are optional and default to 0.
> +
> + - gpmc,sync-clk:Minimum clock period for synchronous mode, in
> picoseconds
> +
> + Chip-select signal timings corresponding to GPMC_CS_CONFIG2:
> + - gpmc,cs-on: Assertion time
> + - gpmc,cs-rd-off: Read deassertion time
> + - gpmc,cs-wr-off: Write deassertion time
> +
> + ADV signal timings corresponding to GPMC_CONFIG3:
> + - gpmc,adv-on: Assertion time
> + - gpmc,adv-rd-off: Read deassertion time
> + - gpmc,adv-wr-off: Write deassertion time
> +
> + WE signals timings corresponding to GPMC_CONFIG4:
> + - gpmc,we-on: Assertion time
> + - gpmc,we-off: Deassertion time
> +
> + OE signals timings corresponding to GPMC_CONFIG4
> + - gpmc,oe-on: Assertion time
> + - gpmc,oe-off: Deassertion time
> +
> + Access time and cycle time timings corresponding to GPMC_CONFIG5
> + - gpmc,page-burst-access: Multiple access word delay
> + - gpmc,access: Start-cycle to first data valid delay
> + - gpmc,rd-cycle:Total read cycle time
> + - gpmc,wr-cycle:Total write cycle time
> +
> +The following are only on OMAP3430
> + - gpmc,wr-access
> + - gpmc,wr-data-mux-bus
> +
> +
> +Example for an AM33xx board:
> +
> + gpmc: gpmc@5000 {
> + compatible = "ti,gpmc";
> + ti,hwmods = "gpmc";
> + reg = <0x5000 0x100>;
Nit-pick, that size is quite large for a register range. I recommend
looking at the HWMOD data file
(arch/arm/mach-omap2/omap_hwmod_33xx_data.c) and see how much space is
allocated for the registers (see structure am33xx_gpmc_addr_space).
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
Hi Daniel,
On 10/22/2012 02:55 PM, Daniel Mack wrote:
> This patch adds basic DT bindings for OMAP GPMC.
>
> The actual peripherals are instanciated from child nodes within the GPMC
> node, and the only type of device that is currently supported is NAND.
>
> Code was added to parse the generic GPMC timing parameters and some
> documentation with examples on how to use them.
>
> Successfully tested on an AM33xx board.
Thanks for sending this and sorry for the delay in responding. Some
comments below ...
> Signed-off-by: Daniel Mack
> ---
> Documentation/devicetree/bindings/bus/gpmc.txt | 59 +
> .../devicetree/bindings/mtd/gpmc-nand.txt | 65 ++
> arch/arm/mach-omap2/gpmc.c | 139
> +
> 3 files changed, 263 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/gpmc.txt
> create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
>
> diff --git a/Documentation/devicetree/bindings/bus/gpmc.txt
> b/Documentation/devicetree/bindings/bus/gpmc.txt
> new file mode 100644
> index 000..ef1c6e1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/gpmc.txt
> @@ -0,0 +1,59 @@
> +Device tree bindings for OMAP general purpose memory controllers (GPMC)
> +
> +The actual devices are instantiated from the child nodes of a GPMC node.
> +
> +Required properties:
> +
> + - compatible: Should be set to "ti,gpmc"
Is this the only required property? I think that "reg" and "ti,hwmods"
are probably also required.
Also given that we are describing the hardware, I am wondering if the
number of chip-selects and wait signals should be defined here too. I
recall that different devices had different number of wait pins available.
> +
> +Timing properties for child nodes. All are optional and default to 0.
> +
> + - gpmc,sync-clk:Minimum clock period for synchronous mode, in
> picoseconds
> +
> + Chip-select signal timings corresponding to GPMC_CS_CONFIG2:
> + - gpmc,cs-on: Assertion time
> + - gpmc,cs-rd-off: Read deassertion time
> + - gpmc,cs-wr-off: Write deassertion time
> +
> + ADV signal timings corresponding to GPMC_CONFIG3:
> + - gpmc,adv-on: Assertion time
> + - gpmc,adv-rd-off: Read deassertion time
> + - gpmc,adv-wr-off: Write deassertion time
> +
> + WE signals timings corresponding to GPMC_CONFIG4:
> + - gpmc,we-on: Assertion time
> + - gpmc,we-off: Deassertion time
> +
> + OE signals timings corresponding to GPMC_CONFIG4
> + - gpmc,oe-on: Assertion time
> + - gpmc,oe-off: Deassertion time
> +
> + Access time and cycle time timings corresponding to GPMC_CONFIG5
> + - gpmc,page-burst-access: Multiple access word delay
> + - gpmc,access: Start-cycle to first data valid delay
> + - gpmc,rd-cycle:Total read cycle time
> + - gpmc,wr-cycle:Total write cycle time
> +
> +The following are only on OMAP3430
> + - gpmc,wr-access
> + - gpmc,wr-data-mux-bus
> +
> +
> +Example for an AM33xx board:
> +
> + gpmc: gpmc@5000 {
> + compatible = "ti,gpmc";
> + ti,hwmods = "gpmc";
> + reg = <0x5000 0x100>;
> + interrupt-parent = <&intc>;
> + interrupts = <100>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + /* child nodes go here */
> + };
> +
> +
> +
> +
> +
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> new file mode 100644
> index 000..6790fcf
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@ -0,0 +1,65 @@
> +Device tree bindings for GPMC connected NANDs
> +
> +GPMC connected NAND (found on OMAP boards) are represented as child nodes of
> +the GPMC controller with a name of "nand".
> +
> +All timing relevant properties are explained in a separate documents - please
> +refer to Documentation/devicetree/bindings/bus/gpmc.txt
> +
> +Required properties:
> +
> + - reg: The CS line the peripheral is connected to
Is this the only required property? I would have thought that bus-width
is needed too.
In general, I am wondering if this should be broken into two patches as
you are creating the binding for the gpmc and nand here.
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
* Russell King - ARM Linux [121023 03:12]: > On Fri, Oct 12, 2012 at 04:54:34PM +0100, Russell King - ARM Linux wrote: > > For those who don't bother looking at my kautobuild boot tests on the OMAP > > boards I have, here's the errors which get spat out at boot time. Note > > that some of these I've reported in the past, and one of them is missing > > a newline character at the end of its string. > > > > twd: can't register interrupt 45 (-22) > > twd_local_timer_register failed -22 > > omap_hwmod: mcpdm: cannot be enabled for reset (3) > > omap-gpmc omap-gpmc: error: clk_get > > omap-gpmc: probe of omap-gpmc failed with error -2 > > Error setting wl12xx data: -38 > > omap_hsmmc omap_hsmmc.1: Failed to get debounce clk > > omap_hsmmc omap_hsmmc.0: Failed to get debounce clk > > omap_hsmmc omap_hsmmc.4: Failed to get debounce clk > > twl6040-codec twl6040-codec: ASoC: Failed to create Capture debugfs file > > omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0). > > omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels > > (0).Power Management for TI OMAP4. > > mmc1: host does not support reading read-only switch. assuming write-enable. > > Here's the latest set of error like messages, thanks to the kautobuild > system: > > omap_hwmod: mcpdm: cannot be enabled for reset (3) > Error setting wl12xx data: -38 That's now fixed up and I've queued it. > omap_hsmmc omap_hsmmc.1: Failed to get debounce clk > omap_hsmmc omap_hsmmc.0: Failed to get debounce clk > omap_hsmmc omap_hsmmc.4: Failed to get debounce clk > omap_vc_i2c_init: I2C config for vdd_iva does not match other channels (0). > omap_vc_i2c_init: I2C config for vdd_mpu does not match other channels > (0).Power Management for TI OMAP4. > mmc1: host does not support reading read-only switch. assuming write-enable. > > This looks much better compared to the previous set, but we could still > do with getting a "\n" on at least one of those messages... Kevin, do you have a patch for some of this? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support
* Tony Lindgren [121016 09:53]: > * Kishon Vijay Abraham I [121007 23:01]: > > ocp2scp was not having pdata support which makes *musb* fail for non-dt > > boot in OMAP platform. The pdata will have information about the devices > > that is connected to ocp2scp. ocp2scp driver will now make use of this > > information to create the devices that is attached to ocp2scp. > > > > Signed-off-by: Kishon Vijay Abraham I > > This fixes the regression on my panda es for musb port: > > Acked-by: Tony Lindgren Looks like nobody has picked this one up and we need it to fix the musb regression on omap, so I'll queue these up. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: bus: omap_interconnect: Fix rand-config build warning
* Tony Lindgren [121024 17:36]: > * Santosh Shilimkar [121017 06:35]: > > (Looping Arnd and Olof) > > > > On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote: > > >When building omap_l3_noc/smx drivers as modules, the following > > >warning appears: > > > > > >CC [M] drivers/bus/omap_l3_smx.o > > >drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or > > >storage class > > >drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in > > >declaration of 'postcore_initcall_sync' > > >drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in > > >function declaration > > >drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not > > >used > > >CC [M] drivers/bus/omap_l3_noc.o > > >drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or > > >storage class > > >drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in > > >declaration of 'arch_initcall_sync' > > >drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in > > >function declaration > > >drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not > > >used > > > > > >Adding module_init() and macros in omap_l3_noc/smx drivers when building > > >as modules to remove the above warning. > > > > > >Reported-by: Tony Lindgren > > >Signed-off-by: Lokesh Vutla > > >--- > > Thanks for the fix Lokesh. Looks fine to me. > > > > Acked-by: Santosh Shilimkar > > Looks like nobody else has picked this up so I'll queue this along > with few other omap warnings and regressions. Hmm actually this might require some more discussion. If we make it use regular initcalls, then the ugly ifdefs can be left out. Is there a reason to init this early, can't we just use regular initcalls? Dropping the patch for now anyways. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] drivers: bus: omap_interconnect: Fix rand-config build warning
* Santosh Shilimkar [121017 06:35]: > (Looping Arnd and Olof) > > On Wednesday 17 October 2012 06:58 PM, Lokesh Vutla wrote: > >When building omap_l3_noc/smx drivers as modules, the following > >warning appears: > > > >CC [M] drivers/bus/omap_l3_smx.o > >drivers/bus/omap_l3_smx.c:291: warning: data definition has no type or > >storage class > >drivers/bus/omap_l3_smx.c:291: warning: type defaults to 'int' in > >declaration of 'postcore_initcall_sync' > >drivers/bus/omap_l3_smx.c:291: warning: parameter names (without types) in > >function declaration > >drivers/bus/omap_l3_smx.c:287: warning: 'omap3_l3_init' defined but not used > >CC [M] drivers/bus/omap_l3_noc.o > >drivers/bus/omap_l3_noc.c:260: warning: data definition has no type or > >storage class > >drivers/bus/omap_l3_noc.c:260: warning: type defaults to 'int' in > >declaration of 'arch_initcall_sync' > >drivers/bus/omap_l3_noc.c:260: warning: parameter names (without types) in > >function declaration > >drivers/bus/omap_l3_noc.c:256: warning: 'omap4_l3_init' defined but not used > > > >Adding module_init() and macros in omap_l3_noc/smx drivers when building > >as modules to remove the above warning. > > > >Reported-by: Tony Lindgren > >Signed-off-by: Lokesh Vutla > >--- > Thanks for the fix Lokesh. Looks fine to me. > > Acked-by: Santosh Shilimkar Looks like nobody else has picked this up so I'll queue this along with few other omap warnings and regressions. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
* Laurent Pinchart [121024 16:54]: > On Wednesday 24 October 2012 15:34:12 Tony Lindgren wrote: > > > > BTW, doing a test compile on v3.7-rc2, I'm seeing the following warnings > > for omap3isp for isp_video_ioctl_ops: > > > > drivers/media/platform/omap3isp/ispvideo.c:1213: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/ispccdc.c:2303: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/ispccdc.c:2304: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/isph3a_aewb.c:282: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/isph3a_aewb.c:283: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/isph3a_af.c:347: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/isph3a_af.c:348: warning: initialization > > from incompatible pointer type > > drivers/media/platform/omap3isp/isphist.c:453: warning: initialization from > > incompatible pointer type > > drivers/media/platform/omap3isp/isphist.c:454: warning: initialization from > > incompatible pointer type > > I've just sent a pull request to linux-media for v3.7 with fixes for those. OK thanks! Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: OMAP2+: Make some definitions local
* Laurent Pinchart [121024 16:38]: > On Wednesday 24 October 2012 16:33:18 Tony Lindgren wrote: > > > > BTW, after updating patch 3/6 I noticed patches 4 - 6 had trivial merge > > conflicts with the includes, so let me know if you want met to repost the > > whole set. > > Please do. I'll then ack it (provided I have no more comments to make of > course :-)). Posted now as "[PATCH v4 0/6] omap iommu changes to remove plat includes". Also noticed one more sorting issue in the isp files that's fixed now. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 5/6] ARM: OMAP2+: Make some definitions local
From: Ido Yariv
Move some of the definitions in omap-iommu.h that can be made local to
either drivers/iommu.
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Omar Ramirez Luna
Signed-off-by: Ido Yariv
[t...@atomide.com: updated for header changes in the series]
Signed-off-by: Tony Lindgren
---
drivers/iommu/omap-iommu.c | 15 +++
drivers/iommu/omap-iommu.h | 33 +++--
drivers/iommu/omap-iommu2.c |6 ++
3 files changed, 24 insertions(+), 30 deletions(-)
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index 4db86e1..df84087 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -54,6 +54,21 @@ struct omap_iommu_domain {
spinlock_t lock;
};
+#define MMU_LOCK_BASE_SHIFT10
+#define MMU_LOCK_BASE_MASK (0x1f << MMU_LOCK_BASE_SHIFT)
+#define MMU_LOCK_BASE(x) \
+ ((x & MMU_LOCK_BASE_MASK) >> MMU_LOCK_BASE_SHIFT)
+
+#define MMU_LOCK_VICT_SHIFT4
+#define MMU_LOCK_VICT_MASK (0x1f << MMU_LOCK_VICT_SHIFT)
+#define MMU_LOCK_VICT(x) \
+ ((x & MMU_LOCK_VICT_MASK) >> MMU_LOCK_VICT_SHIFT)
+
+struct iotlb_lock {
+ short base;
+ short vict;
+};
+
/* accommodate the difference between omap1 and omap2/3 */
static const struct iommu_functions *arch_iommu;
diff --git a/drivers/iommu/omap-iommu.h b/drivers/iommu/omap-iommu.h
index 8c3378d..2b5f3c0 100644
--- a/drivers/iommu/omap-iommu.h
+++ b/drivers/iommu/omap-iommu.h
@@ -72,11 +72,6 @@ struct cr_regs {
};
};
-struct iotlb_lock {
- short base;
- short vict;
-};
-
/* architecture specific functions */
struct iommu_functions {
unsigned long version;
@@ -117,13 +112,6 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
}
#endif
-/* IOMMU errors */
-#define OMAP_IOMMU_ERR_TLB_MISS(1 << 0)
-#define OMAP_IOMMU_ERR_TRANS_FAULT (1 << 1)
-#define OMAP_IOMMU_ERR_EMU_MISS(1 << 2)
-#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 << 3)
-#define OMAP_IOMMU_ERR_MULTIHIT_FAULT (1 << 4)
-
/*
* MMU Register offsets
*/
@@ -151,16 +139,6 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
/*
* MMU Register bit definitions
*/
-#define MMU_LOCK_BASE_SHIFT10
-#define MMU_LOCK_BASE_MASK (0x1f << MMU_LOCK_BASE_SHIFT)
-#define MMU_LOCK_BASE(x) \
- ((x & MMU_LOCK_BASE_MASK) >> MMU_LOCK_BASE_SHIFT)
-
-#define MMU_LOCK_VICT_SHIFT4
-#define MMU_LOCK_VICT_MASK (0x1f << MMU_LOCK_VICT_SHIFT)
-#define MMU_LOCK_VICT(x) \
- ((x & MMU_LOCK_VICT_MASK) >> MMU_LOCK_VICT_SHIFT)
-
#define MMU_CAM_VATAG_SHIFT12
#define MMU_CAM_VATAG_MASK \
((~0UL >> MMU_CAM_VATAG_SHIFT) << MMU_CAM_VATAG_SHIFT)
@@ -222,20 +200,15 @@ extern void omap_iotlb_cr_to_e(struct cr_regs *cr, struct
iotlb_entry *e);
extern int
omap_iopgtable_store_entry(struct omap_iommu *obj, struct iotlb_entry *e);
-extern int omap_iommu_set_isr(const char *name,
-int (*isr)(struct omap_iommu *obj, u32 da, u32 iommu_errs,
- void *priv),
-void *isr_priv);
-
extern void omap_iommu_save_ctx(struct device *dev);
extern void omap_iommu_restore_ctx(struct device *dev);
-extern int omap_install_iommu_arch(const struct iommu_functions *ops);
-extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
-
extern int omap_foreach_iommu_device(void *data,
int (*fn)(struct device *, void *));
+extern int omap_install_iommu_arch(const struct iommu_functions *ops);
+extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
+
extern ssize_t
omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf, ssize_t len);
extern size_t
diff --git a/drivers/iommu/omap-iommu2.c b/drivers/iommu/omap-iommu2.c
index f97c386..29e98a2 100644
--- a/drivers/iommu/omap-iommu2.c
+++ b/drivers/iommu/omap-iommu2.c
@@ -68,6 +68,12 @@
((pgsz) == MMU_CAM_PGSZ_64K) ? 0x :\
((pgsz) == MMU_CAM_PGSZ_4K) ? 0xf000 : 0)
+/* IOMMU errors */
+#define OMAP_IOMMU_ERR_TLB_MISS(1 << 0)
+#define OMAP_IOMMU_ERR_TRANS_FAULT (1 << 1)
+#define OMAP_IOMMU_ERR_EMU_MISS(1 << 2)
+#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 << 3)
+#define OMAP_IOMMU_ERR_MULTIHIT_FAULT (1 << 4)
static void __iommu_set_twl(struct omap_iommu *obj, bool on)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 6/6] ARM: OMAP2+: Move iommu/iovmm headers to platform_data
Move iommu/iovmm headers from plat/ to platform_data/ as part of the
single zImage work.
Partially based on an earlier version by Ido Yariv .
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Ido Yariv
Cc: Laurent Pinchart
Cc: Omar Ramirez Luna
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/devices.c |2 +-
arch/arm/mach-omap2/omap-iommu.c |2 +-
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 +-
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 +-
drivers/iommu/omap-iommu-debug.c |3 +--
drivers/iommu/omap-iommu.c |2 +-
drivers/iommu/omap-iommu2.c|2 +-
drivers/iommu/omap-iovmm.c |3 +--
drivers/media/platform/omap3isp/ispvideo.c |1 -
include/linux/platform_data/iommu-omap.h |0
10 files changed, 8 insertions(+), 11 deletions(-)
rename arch/arm/plat-omap/include/plat/iommu.h =>
include/linux/platform_data/iommu-omap.h (100%)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index cba60e0..1002ff8 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -126,7 +126,7 @@ static struct platform_device omap2cam_device = {
#if defined(CONFIG_IOMMU_API)
-#include
+#include
static struct resource omap3isp_resources[] = {
{
diff --git a/arch/arm/mach-omap2/omap-iommu.c b/arch/arm/mach-omap2/omap-iommu.c
index df298d4..a6a4ff8 100644
--- a/arch/arm/mach-omap2/omap-iommu.c
+++ b/arch/arm/mach-omap2/omap-iommu.c
@@ -13,7 +13,7 @@
#include
#include
-#include
+#include
#include "soc.h"
#include "common.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f67b7ee..621bc71 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -26,8 +26,8 @@
#include
#include
#include
+#include
#include
-#include
#include "am35xx.h"
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 652d028..5850b3e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -27,10 +27,10 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
#include "omap_hwmod_common_data.h"
#include "cm1_44xx.h"
diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c
index d0427bd..d97fbe4 100644
--- a/drivers/iommu/omap-iommu-debug.c
+++ b/drivers/iommu/omap-iommu-debug.c
@@ -19,8 +19,7 @@
#include
#include
#include
-
-#include
+#include
#include "omap-iopgtable.h"
#include "omap-iommu.h"
diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c
index df84087..badc17c 100644
--- a/drivers/iommu/omap-iommu.c
+++ b/drivers/iommu/omap-iommu.c
@@ -26,7 +26,7 @@
#include
-#include
+#include
#include "omap-iopgtable.h"
#include "omap-iommu.h"
diff --git a/drivers/iommu/omap-iommu2.c b/drivers/iommu/omap-iommu2.c
index 29e98a2..c020202 100644
--- a/drivers/iommu/omap-iommu2.c
+++ b/drivers/iommu/omap-iommu2.c
@@ -19,8 +19,8 @@
#include
#include
#include
+#include
-#include
#include "omap-iommu.h"
/*
diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c
index 3e3b242..46d87569 100644
--- a/drivers/iommu/omap-iovmm.c
+++ b/drivers/iommu/omap-iovmm.c
@@ -18,12 +18,11 @@
#include
#include
#include
+#include
#include
#include
-#include
-
#include "omap-iopgtable.h"
#include "omap-iommu.h"
diff --git a/drivers/media/platform/omap3isp/ispvideo.c
b/drivers/media/platform/omap3isp/ispvideo.c
index a4b8290..21f7313 100644
--- a/drivers/media/platform/omap3isp/ispvideo.c
+++ b/drivers/media/platform/omap3isp/ispvideo.c
@@ -35,7 +35,6 @@
#include
#include
#include
-#include
#include
#include "ispvideo.h"
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/include/linux/platform_data/iommu-omap.h
similarity index 100%
rename from arch/arm/plat-omap/include/plat/iommu.h
rename to include/linux/platform_data/iommu-omap.h
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] ARM: OMAP2+: Move iommu2 to drivers/iommu/omap-iommu2.c
This file should not be in arch/arm. Move it to drivers/iommu
to allow making most of the header local to drivers/iommu.
This is needed as we are removing plat and mach includes
from drivers for ARM common zImage support.
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Ido Yariv
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Omar Ramirez Luna
Cc: linux-me...@vger.kernel.org
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/Makefile|2
arch/arm/plat-omap/include/plat/iommu.h | 272 ++-
drivers/iommu/Makefile |1
drivers/iommu/omap-iommu-debug.c|1
drivers/iommu/omap-iommu.c | 19 ++
drivers/iommu/omap-iommu.h | 255 +
drivers/iommu/omap-iommu2.c |2
drivers/iommu/omap-iopgtable.h | 22 ---
drivers/iommu/omap-iovmm.c |1
9 files changed, 293 insertions(+), 282 deletions(-)
create mode 100644 drivers/iommu/omap-iommu.h
rename arch/arm/mach-omap2/iommu2.c => drivers/iommu/omap-iommu2.c (99%)
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fe40d9e..d6721a7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -184,8 +184,6 @@ obj-$(CONFIG_HW_PERF_EVENTS)+= pmu.o
obj-$(CONFIG_OMAP_MBOX_FWK)+= mailbox_mach.o
mailbox_mach-objs := mailbox.o
-obj-$(CONFIG_OMAP_IOMMU) += iommu2.o
-
iommu-$(CONFIG_OMAP_IOMMU) := omap-iommu.o
obj-y += $(iommu-m) $(iommu-y)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index a4b71b1..c677b9f 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -10,103 +10,21 @@
* published by the Free Software Foundation.
*/
-#ifndef __MACH_IOMMU_H
-#define __MACH_IOMMU_H
-
-#include
-
-#if defined(CONFIG_ARCH_OMAP1)
-#error "iommu for this processor not implemented yet"
-#endif
-
-struct iotlb_entry {
- u32 da;
- u32 pa;
- u32 pgsz, prsvd, valid;
- union {
- u16 ap;
- struct {
- u32 endian, elsz, mixed;
- };
- };
-};
-
-struct omap_iommu {
- const char *name;
- struct module *owner;
- struct clk *clk;
- void __iomem*regbase;
- struct device *dev;
- void*isr_priv;
- struct iommu_domain *domain;
-
- unsigned intrefcount;
- spinlock_t iommu_lock; /* global for this whole object */
-
- /*
-* We don't change iopgd for a situation like pgd for a task,
-* but share it globally for each iommu.
-*/
- u32 *iopgd;
- spinlock_t page_table_lock; /* protect iopgd */
-
- int nr_tlb_entries;
-
- struct list_headmmap;
- struct mutexmmap_lock; /* protect mmap */
-
- void *ctx; /* iommu context: registres saved area */
- u32 da_start;
- u32 da_end;
-};
-
-struct cr_regs {
- union {
- struct {
- u16 cam_l;
- u16 cam_h;
- };
- u32 cam;
- };
- union {
- struct {
- u16 ram_l;
- u16 ram_h;
- };
- u32 ram;
- };
-};
-
-struct iotlb_lock {
- short base;
- short vict;
-};
-
-/* architecture specific functions */
-struct iommu_functions {
- unsigned long version;
-
- int (*enable)(struct omap_iommu *obj);
- void (*disable)(struct omap_iommu *obj);
- void (*set_twl)(struct omap_iommu *obj, bool on);
- u32 (*fault_isr)(struct omap_iommu *obj, u32 *ra);
-
- void (*tlb_read_cr)(struct omap_iommu *obj, struct cr_regs *cr);
- void (*tlb_load_cr)(struct omap_iommu *obj, struct cr_regs *cr);
-
- struct cr_regs *(*alloc_cr)(struct omap_iommu *obj,
- struct iotlb_entry *e);
- int (*cr_valid)(struct cr_regs *cr);
- u32 (*cr_to_virt)(struct cr_regs *cr);
- void (*cr_to_e)(struct cr_regs *cr, struct iotlb_entry *e);
- ssize_t (*dump_cr)(struct omap_iommu *obj, struct cr_regs *cr,
- char *buf);
-
- u32 (*get_pte_attr)(struct iotlb_entry *e);
+#define MMU_REG_SIZE 256
- void (*save_ctx)(struct omap_iommu *obj);
- void (*restore_ctx)(struct omap_iommu *obj);
- ssize_t (*dump_ctx)(struct omap_iommu *obj, char *buf, ssize_t len);
+/**
+ * struct iommu_arch_data - omap iommu private data
+ * @name: name of the iommu device
+ * @iommu_dev: handle of the iommu device
+ *
+ * This is an omap iommu private data object, which binds an iommu user
+ * to its io
[PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
Looks like the iommu framework does not have generic functions
exported for all the needs yet. The hardware specific functions
are defined in files like intel-iommu.h and amd-iommu.h. Follow
the same standard for omap-iommu.h.
This is needed because we are removing plat and mach includes
for ARM common zImage support. Further work should continue
in the iommu framework context as only pure platform data will
be communicated from arch/arm/*omap*/* code to the iommu
framework.
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Ido Yariv
Cc: Laurent Pinchart
Cc: Omar Ramirez Luna
Cc: linux-me...@vger.kernel.org
Acked-by: Mauro Carvalho Chehab
Signed-off-by: Tony Lindgren
---
arch/arm/mach-omap2/iommu2.c |1
arch/arm/plat-omap/include/plat/iommu.h| 10 +--
arch/arm/plat-omap/include/plat/iovmm.h| 89
drivers/iommu/omap-iommu-debug.c |2 -
drivers/iommu/omap-iommu.c |1
drivers/iommu/omap-iovmm.c | 46 ++
drivers/media/platform/omap3isp/isp.c |1
drivers/media/platform/omap3isp/isp.h |4 -
drivers/media/platform/omap3isp/ispccdc.c |1
drivers/media/platform/omap3isp/ispstat.c |1
drivers/media/platform/omap3isp/ispvideo.c |2 -
include/linux/omap-iommu.h | 52
12 files changed, 107 insertions(+), 103 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/iovmm.h
create mode 100644 include/linux/omap-iommu.h
diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c
index eefc379..e8116cf 100644
--- a/arch/arm/mach-omap2/iommu2.c
+++ b/arch/arm/mach-omap2/iommu2.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 7e8c7b6..a4b71b1 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -216,13 +216,10 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
#define MMU_RAM_PADDR_SHIFT12
#define MMU_RAM_PADDR_MASK \
((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT)
-#define MMU_RAM_ENDIAN_SHIFT 9
+
#define MMU_RAM_ENDIAN_MASK(1 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ENDIAN_BIG (1 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
-#define MMU_RAM_ELSZ_SHIFT 7
#define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT)
-#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
+
#define MMU_RAM_ELSZ_16(1 << MMU_RAM_ELSZ_SHIFT)
#define MMU_RAM_ELSZ_32(2 << MMU_RAM_ELSZ_SHIFT)
#define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT)
@@ -269,9 +266,6 @@ extern int omap_iommu_set_isr(const char *name,
void *priv),
void *isr_priv);
-extern void omap_iommu_save_ctx(struct device *dev);
-extern void omap_iommu_restore_ctx(struct device *dev);
-
extern int omap_install_iommu_arch(const struct iommu_functions *ops);
extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops);
diff --git a/arch/arm/plat-omap/include/plat/iovmm.h
b/arch/arm/plat-omap/include/plat/iovmm.h
deleted file mode 100644
index 498e57c..000
--- a/arch/arm/plat-omap/include/plat/iovmm.h
+++ /dev/null
@@ -1,89 +0,0 @@
-/*
- * omap iommu: simple virtual address space management
- *
- * Copyright (C) 2008-2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- */
-
-#ifndef __IOMMU_MMAP_H
-#define __IOMMU_MMAP_H
-
-#include
-
-struct iovm_struct {
- struct omap_iommu *iommu; /* iommu object which this belongs to */
- u32 da_start; /* area definition */
- u32 da_end;
- u32 flags; /* IOVMF_: see below */
- struct list_headlist; /* linked in ascending order */
- const struct sg_table *sgt; /* keep 'page' <-> 'da' mapping */
- void*va; /* mpu side mapped address */
-};
-
-/*
- * IOVMF_FLAGS: attribute for iommu virtual memory area(iovma)
- *
- * lower 16 bit is used for h/w and upper 16 bit is for s/w.
- */
-#define IOVMF_SW_SHIFT 16
-
-/*
- * iovma: h/w flags derived from cam and ram attribute
- */
-#define IOVMF_CAM_MASK (~((1 << 10) - 1))
-#define IOVMF_RAM_MASK (~IOVMF_CAM_MASK)
-
-#define IOVMF_PGSZ_MASK(3 << 0)
-#define IOVMF_PGSZ_1M MMU_CAM_PGSZ_1M
-#define IOVMF_PGSZ_64K MMU_CAM_PGSZ_64K
-#define IOVMF_PGSZ_4K MMU_CAM_PGSZ_4K
-#define IOVMF_PGSZ_16M MMU_CAM_PGSZ_16M
-
-#define IOVMF_ENDIAN_MASK (1 << 9)
-#define IOVMF_ENDIAN_BIG MMU_RAM_ENDIA
[PATCH 2/6] ARM: OMAP2+: Move iopgtable header to drivers/iommu/
From: Ido Yariv The iopgtable header file is only used by the iommu & iovmm drivers, so move it to drivers/iommu/, as part of the single zImage effort. Cc: Joerg Roedel Cc: Ohad Ben-Cohen Cc: Laurent Pinchart Cc: Mauro Carvalho Chehab Cc: Omar Ramirez Luna Signed-off-by: Ido Yariv [t...@atomide.com: updated to be earlier in the series] Signed-off-by: Tony Lindgren --- drivers/iommu/omap-iommu-debug.c|2 +- drivers/iommu/omap-iommu.c |2 +- drivers/iommu/omap-iopgtable.h |0 drivers/iommu/omap-iovmm.c |2 +- 4 files changed, 3 insertions(+), 3 deletions(-) rename arch/arm/plat-omap/include/plat/iopgtable.h => drivers/iommu/omap-iopgtable.h (100%) diff --git a/drivers/iommu/omap-iommu-debug.c b/drivers/iommu/omap-iommu-debug.c index f55fc5d..0cac372 100644 --- a/drivers/iommu/omap-iommu-debug.c +++ b/drivers/iommu/omap-iommu-debug.c @@ -22,7 +22,7 @@ #include #include -#include +#include "omap-iopgtable.h" #define MAXCOLUMN 100 /* for short messages */ diff --git a/drivers/iommu/omap-iommu.c b/drivers/iommu/omap-iommu.c index d0b1234..f2bbfb0 100644 --- a/drivers/iommu/omap-iommu.c +++ b/drivers/iommu/omap-iommu.c @@ -26,7 +26,7 @@ #include -#include +#include "omap-iopgtable.h" #define for_each_iotlb_cr(obj, n, __i, cr) \ for (__i = 0; \ diff --git a/arch/arm/plat-omap/include/plat/iopgtable.h b/drivers/iommu/omap-iopgtable.h similarity index 100% rename from arch/arm/plat-omap/include/plat/iopgtable.h rename to drivers/iommu/omap-iopgtable.h diff --git a/drivers/iommu/omap-iovmm.c b/drivers/iommu/omap-iovmm.c index 2e10c3e..b332392 100644 --- a/drivers/iommu/omap-iovmm.c +++ b/drivers/iommu/omap-iovmm.c @@ -24,7 +24,7 @@ #include #include -#include +#include "omap-iopgtable.h" static struct kmem_cache *iovm_area_cachep; -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] ARM: OMAP: Merge iommu2.h into iommu.h
From: Ido Yariv
Since iommu is not supported on OMAP1 and will not likely to ever be
supported, merge plat/iommu2.h into iommu.h so only one file would have
to move to platform_data/ as part of the single zImage effort.
Cc: Joerg Roedel
Cc: Ohad Ben-Cohen
Cc: Laurent Pinchart
Cc: Mauro Carvalho Chehab
Cc: Omar Ramirez Luna
Signed-off-by: Ido Yariv
Signed-off-by: Tony Lindgren
---
arch/arm/plat-omap/include/plat/iommu.h | 88 ++--
arch/arm/plat-omap/include/plat/iommu2.h | 96 --
2 files changed, 83 insertions(+), 101 deletions(-)
delete mode 100644 arch/arm/plat-omap/include/plat/iommu2.h
diff --git a/arch/arm/plat-omap/include/plat/iommu.h
b/arch/arm/plat-omap/include/plat/iommu.h
index 68b5f03..7e8c7b6 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -13,6 +13,12 @@
#ifndef __MACH_IOMMU_H
#define __MACH_IOMMU_H
+#include
+
+#if defined(CONFIG_ARCH_OMAP1)
+#error "iommu for this processor not implemented yet"
+#endif
+
struct iotlb_entry {
u32 da;
u32 pa;
@@ -159,11 +165,70 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct
device *dev)
#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 << 3)
#define OMAP_IOMMU_ERR_MULTIHIT_FAULT (1 << 4)
-#if defined(CONFIG_ARCH_OMAP1)
-#error "iommu for this processor not implemented yet"
-#else
-#include
-#endif
+/*
+ * MMU Register offsets
+ */
+#define MMU_REVISION 0x00
+#define MMU_SYSCONFIG 0x10
+#define MMU_SYSSTATUS 0x14
+#define MMU_IRQSTATUS 0x18
+#define MMU_IRQENABLE 0x1c
+#define MMU_WALKING_ST 0x40
+#define MMU_CNTL 0x44
+#define MMU_FAULT_AD 0x48
+#define MMU_TTB0x4c
+#define MMU_LOCK 0x50
+#define MMU_LD_TLB 0x54
+#define MMU_CAM0x58
+#define MMU_RAM0x5c
+#define MMU_GFLUSH 0x60
+#define MMU_FLUSH_ENTRY0x64
+#define MMU_READ_CAM 0x68
+#define MMU_READ_RAM 0x6c
+#define MMU_EMU_FAULT_AD 0x70
+
+#define MMU_REG_SIZE 256
+
+/*
+ * MMU Register bit definitions
+ */
+#define MMU_LOCK_BASE_SHIFT10
+#define MMU_LOCK_BASE_MASK (0x1f << MMU_LOCK_BASE_SHIFT)
+#define MMU_LOCK_BASE(x) \
+ ((x & MMU_LOCK_BASE_MASK) >> MMU_LOCK_BASE_SHIFT)
+
+#define MMU_LOCK_VICT_SHIFT4
+#define MMU_LOCK_VICT_MASK (0x1f << MMU_LOCK_VICT_SHIFT)
+#define MMU_LOCK_VICT(x) \
+ ((x & MMU_LOCK_VICT_MASK) >> MMU_LOCK_VICT_SHIFT)
+
+#define MMU_CAM_VATAG_SHIFT12
+#define MMU_CAM_VATAG_MASK \
+ ((~0UL >> MMU_CAM_VATAG_SHIFT) << MMU_CAM_VATAG_SHIFT)
+#define MMU_CAM_P (1 << 3)
+#define MMU_CAM_V (1 << 2)
+#define MMU_CAM_PGSZ_MASK 3
+#define MMU_CAM_PGSZ_1M(0 << 0)
+#define MMU_CAM_PGSZ_64K (1 << 0)
+#define MMU_CAM_PGSZ_4K(2 << 0)
+#define MMU_CAM_PGSZ_16M (3 << 0)
+
+#define MMU_RAM_PADDR_SHIFT12
+#define MMU_RAM_PADDR_MASK \
+ ((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT)
+#define MMU_RAM_ENDIAN_SHIFT 9
+#define MMU_RAM_ENDIAN_MASK(1 << MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ENDIAN_BIG (1 << MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT)
+#define MMU_RAM_ELSZ_SHIFT 7
+#define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_16(1 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_32(2 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT)
+#define MMU_RAM_MIXED_SHIFT6
+#define MMU_RAM_MIXED_MASK (1 << MMU_RAM_MIXED_SHIFT)
+#define MMU_RAM_MIXED MMU_RAM_MIXED_MASK
/*
* utilities for super page(16MB, 1MB, 64KB and 4KB)
@@ -218,4 +283,17 @@ omap_iommu_dump_ctx(struct omap_iommu *obj, char *buf,
ssize_t len);
extern size_t
omap_dump_tlb_entries(struct omap_iommu *obj, char *buf, ssize_t len);
+/*
+ * register accessors
+ */
+static inline u32 iommu_read_reg(struct omap_iommu *obj, size_t offs)
+{
+ return __raw_readl(obj->regbase + offs);
+}
+
+static inline void iommu_write_reg(struct omap_iommu *obj, u32 val, size_t
offs)
+{
+ __raw_writel(val, obj->regbase + offs);
+}
+
#endif /* __MACH_IOMMU_H */
diff --git a/arch/arm/plat-omap/include/plat/iommu2.h
b/arch/arm/plat-omap/include/plat/iommu2.h
deleted file mode 100644
index d4116b5..000
--- a/arch/arm/plat-omap/include/plat/iommu2.h
+++ /dev/null
@@ -1,96 +0,0 @@
-/*
- * omap iommu: omap2 architecture specific definitions
- *
- * Copyright (C) 2008-2009 Nokia Corporation
- *
- * Written by Hiroshi DOYU
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
[PATCH v4 0/6] omap iommu changes to remove plat includes
Hi all, Here are these posted again after updating patch 3/6 the following patches no longer applied. Regards, Tony --- Ido Yariv (3): ARM: OMAP: Merge iommu2.h into iommu.h ARM: OMAP2+: Move iopgtable header to drivers/iommu/ ARM: OMAP2+: Make some definitions local Tony Lindgren (3): ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h ARM: OMAP2+: Move iommu2 to drivers/iommu/omap-iommu2.c ARM: OMAP2+: Move iommu/iovmm headers to platform_data arch/arm/mach-omap2/Makefile|2 arch/arm/mach-omap2/devices.c |2 arch/arm/mach-omap2/omap-iommu.c|2 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |2 arch/arm/mach-omap2/omap_hwmod_44xx_data.c |2 arch/arm/plat-omap/include/plat/iommu2.h| 96 --- arch/arm/plat-omap/include/plat/iovmm.h | 89 -- drivers/iommu/Makefile |1 drivers/iommu/omap-iommu-debug.c|8 +- drivers/iommu/omap-iommu.c | 39 drivers/iommu/omap-iommu.h | 133 ++- drivers/iommu/omap-iommu2.c | 11 ++ drivers/iommu/omap-iopgtable.h | 22 drivers/iommu/omap-iovmm.c | 50 ++ drivers/media/platform/omap3isp/isp.c |1 drivers/media/platform/omap3isp/isp.h |4 - drivers/media/platform/omap3isp/ispccdc.c |1 drivers/media/platform/omap3isp/ispstat.c |1 drivers/media/platform/omap3isp/ispvideo.c |3 - include/linux/omap-iommu.h | 52 +++ include/linux/platform_data/iommu-omap.h| 49 ++ 21 files changed, 279 insertions(+), 291 deletions(-) delete mode 100644 arch/arm/plat-omap/include/plat/iommu2.h delete mode 100644 arch/arm/plat-omap/include/plat/iovmm.h rename arch/arm/plat-omap/include/plat/iommu.h => drivers/iommu/omap-iommu.h (69%) rename arch/arm/mach-omap2/iommu2.c => drivers/iommu/omap-iommu2.c (96%) rename arch/arm/plat-omap/include/plat/iopgtable.h => drivers/iommu/omap-iopgtable.h (85%) create mode 100644 include/linux/omap-iommu.h create mode 100644 include/linux/platform_data/iommu-omap.h -- -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARM: OMAP2+: first set of PRM/CM cleanups for 3.8
* Paul Walmsley [121021 12:15]: > Hi Tony > > The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: > > Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git > tags/omap-cleanup-a-for-3.8 > > for you to fetch changes up to 2bb2a5d30abb0dc99d074877bfad2056142c730b: > > ARM: OMAP2+: PRM: create PRM reset source API for the watchdog timer driver > (2012-10-21 01:01:13 -0600) > > > The first set of OMAP PRM/CM-related cleanup patches for 3.8. > Prepares for the future move of the PRM/CM code to drivers/. Also > includes some prcm.[ch] cleanup patches from the WDTIMER cleanup > series that don't need external acks. > > Basic test logs for this branch on top of v3.7-rc2 are here: > > http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121021123719/ > > But due to the number of unrelated regressions present in v3.7-rc[12], > it's not particularly usable as a testing base. With reverts, fixes, > and workarounds applied as documented in: > > http://www.pwsan.com/omap/testlogs/test_v3.7-rc2/20121020134755/README.txt > > the following test logs were obtained: > > http://www.pwsan.com/omap/testlogs/prcm_cleanup_a_3.8/20121020231757/ > > which indicate that the series tests cleanly. Thanks pulling into omap-for-v3.8/cleanup-prcm. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
Hi Tony, On Wednesday 24 October 2012 15:34:12 Tony Lindgren wrote: > * Laurent Pinchart [121019 02:41]: > > On Thursday 18 October 2012 13:28:42 Tony Lindgren wrote: > > > --- a/arch/arm/mach-omap2/iommu2.c > > > +++ b/arch/arm/mach-omap2/iommu2.c > > > @@ -17,6 +17,7 @@ > > > > > > #include > > > #include > > > #include > > > > > > +#include > > > > Nitpicking, please keep the headers sorted alphabetically, here and in all > > locations below (especially the OMAP3 ISP driver). > > > > (OK, there's already one misplaced #include, but let's not make it worse > > :-)) > > This is fixed now. > > > > --- /dev/null > > > +++ b/include/linux/omap-iommu.h > > > @@ -0,0 +1,47 @@ > > > +/* > > > + * omap iommu: simple virtual address space management > > > + * > > > + * Copyright (C) 2008-2009 Nokia Corporation > > > + * > > > + * Written by Hiroshi DOYU > > > + * > > > + * This program is free software; you can redistribute it and/or modify > > > + * it under the terms of the GNU General Public License version 2 as > > > + * published by the Free Software Foundation. > > > + */ > > > > Missing #ifndef #define ... #endif > > I've added it as _OMAP_IOMMU_H_, looks like both intel-iommu.h and > amd-iommu.h have it. > > Hopefully that's OK for you as a base to do further iommu patches > on, updated patch below. > > BTW, doing a test compile on v3.7-rc2, I'm seeing the following warnings > for omap3isp for isp_video_ioctl_ops: > > drivers/media/platform/omap3isp/ispvideo.c:1213: warning: initialization > from incompatible pointer type > drivers/media/platform/omap3isp/ispccdc.c:2303: warning: initialization > from incompatible pointer type > drivers/media/platform/omap3isp/ispccdc.c:2304: warning: initialization > from incompatible pointer type > drivers/media/platform/omap3isp/isph3a_aewb.c:282: warning: initialization > from incompatible pointer type > drivers/media/platform/omap3isp/isph3a_aewb.c:283: warning: initialization > from incompatible pointer type > drivers/media/platform/omap3isp/isph3a_af.c:347: warning: initialization > from incompatible pointer type > drivers/media/platform/omap3isp/isph3a_af.c:348: warning: initialization > from incompatible pointer type > drivers/media/platform/omap3isp/isphist.c:453: warning: initialization from > incompatible pointer type > drivers/media/platform/omap3isp/isphist.c:454: warning: initialization from > incompatible pointer type I've just sent a pull request to linux-media for v3.7 with fixes for those. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: OMAP2+: Make some definitions local
Hi Tony, On Wednesday 24 October 2012 16:33:18 Tony Lindgren wrote: > * Laurent Pinchart [121024 16:26]: > > On Friday 19 October 2012 09:17:43 Tony Lindgren wrote: > > > * Laurent Pinchart [121019 02:45]: > > > > On Thursday 18 October 2012 13:28:48 Tony Lindgren wrote: > > > > > @@ -117,13 +112,6 @@ static inline struct omap_iommu > > > > > *dev_to_omap_iommu(struct device *dev) } > > > > > > > > > > #endif > > > > > > > > > > -/* IOMMU errors */ > > > > > -#define OMAP_IOMMU_ERR_TLB_MISS (1 << 0) > > > > > -#define OMAP_IOMMU_ERR_TRANS_FAULT (1 << 1) > > > > > -#define OMAP_IOMMU_ERR_EMU_MISS (1 << 2) > > > > > -#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 << 3) > > > > > -#define OMAP_IOMMU_ERR_MULTIHIT_FAULT(1 << 4) > > > > > - > > > > > > > > I'll use those in the tidspbridge driver, in patches that I plan to > > > > push soon. > > > > > > > > I will apply this patch set on top of mine, see what breaks. Would you > > > > like me to propose a modified version of this set, or add additional > > > > patches in my set ? > > > > > > Sure, let's try to expose only the minimal amount of omap iommu things > > > with this patch set so we don't break things. Then the iommu development > > > can continue on it's own independent of the core omap code except for > > > the platform data. > > > > I'll rebase my DSP patches on top of this patch set then, it will be > > easier. > > OK sounds good to me. > > Once we have the minimal changes acked by you and Joerg, I'll push > it into an immutable branch that we all can merge in as needed. > > BTW, after updating patch 3/6 I noticed patches 4 - 6 had trivial merge > conflicts with the includes, so let me know if you want met to repost the > whole set. Please do. I'll then ack it (provided I have no more comments to make of course :-)). > > > But again, if there are nasty layering violations using this code, I > > > would just remove those features. Those things tend to just get worse > > > unless they are fixed properly to start with. > > > > The long-term goal is to move the tidspbridge driver to the IOMMU API, but > > we'll need a step by step approach. > > Yes agreed. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: OMAP2+: Make some definitions local
* Laurent Pinchart [121024 16:26]: > Ho Tony, > > On Friday 19 October 2012 09:17:43 Tony Lindgren wrote: > > * Laurent Pinchart [121019 02:45]: > > > On Thursday 18 October 2012 13:28:48 Tony Lindgren wrote: > > > > @@ -117,13 +112,6 @@ static inline struct omap_iommu > > > > *dev_to_omap_iommu(struct device *dev) } > > > > > > > > #endif > > > > > > > > -/* IOMMU errors */ > > > > -#define OMAP_IOMMU_ERR_TLB_MISS(1 << 0) > > > > -#define OMAP_IOMMU_ERR_TRANS_FAULT (1 << 1) > > > > -#define OMAP_IOMMU_ERR_EMU_MISS(1 << 2) > > > > -#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 << 3) > > > > -#define OMAP_IOMMU_ERR_MULTIHIT_FAULT (1 << 4) > > > > - > > > > > > I'll use those in the tidspbridge driver, in patches that I plan to push > > > soon. > > > > > > I will apply this patch set on top of mine, see what breaks. Would you > > > like me to propose a modified version of this set, or add additional > > > patches in my set ? > > > > Sure, let's try to expose only the minimal amount of omap iommu things with > > this patch set so we don't break things. Then the iommu development can > > continue on it's own independent of the core omap code except for the > > platform data. > > I'll rebase my DSP patches on top of this patch set then, it will be easier. OK sounds good to me. Once we have the minimal changes acked by you and Joerg, I'll push it into an immutable branch that we all can merge in as needed. BTW, after updating patch 3/6 I noticed patches 4 - 6 had trivial merge conflicts with the includes, so let me know if you want met to repost the whole set. > > But again, if there are nasty layering violations using this code, I would > > just remove those features. Those things tend to just get worse unless they > > are fixed properly to start with. > > The long-term goal is to move the tidspbridge driver to the IOMMU API, but > we'll need a step by step approach. Yes agreed. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
On 25.10.2012 01:27, Tony Lindgren wrote: > * Daniel Mack [121022 12:57]: >> This patch adds basic DT bindings for OMAP GPMC. >> >> The actual peripherals are instanciated from child nodes within the GPMC >> node, and the only type of device that is currently supported is NAND. >> >> Code was added to parse the generic GPMC timing parameters and some >> documentation with examples on how to use them. >> >> Successfully tested on an AM33xx board. > > That's great, looks good to me. Please repost at least the > binding patch with devicetree-discuss and Rob Herring cc:d > so hopefully we'll get an ack for the binding. Thanks for the review. I'll wait for feedback from Afzal next week and then repost. Wanted to see first if that goes in the right direction at all before bordering the DT people with binding details :) Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] OMAP: mtd: gpmc: add DT bindings for GPMC timings and NAND
* Daniel Mack [121022 12:57]: > This patch adds basic DT bindings for OMAP GPMC. > > The actual peripherals are instanciated from child nodes within the GPMC > node, and the only type of device that is currently supported is NAND. > > Code was added to parse the generic GPMC timing parameters and some > documentation with examples on how to use them. > > Successfully tested on an AM33xx board. That's great, looks good to me. Please repost at least the binding patch with devicetree-discuss and Rob Herring cc:d so hopefully we'll get an ack for the binding. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 5/6] ARM: OMAP2+: Make some definitions local
Ho Tony, On Friday 19 October 2012 09:17:43 Tony Lindgren wrote: > * Laurent Pinchart [121019 02:45]: > > On Thursday 18 October 2012 13:28:48 Tony Lindgren wrote: > > > @@ -117,13 +112,6 @@ static inline struct omap_iommu > > > *dev_to_omap_iommu(struct device *dev) } > > > > > > #endif > > > > > > -/* IOMMU errors */ > > > -#define OMAP_IOMMU_ERR_TLB_MISS (1 << 0) > > > -#define OMAP_IOMMU_ERR_TRANS_FAULT (1 << 1) > > > -#define OMAP_IOMMU_ERR_EMU_MISS (1 << 2) > > > -#define OMAP_IOMMU_ERR_TBLWALK_FAULT (1 << 3) > > > -#define OMAP_IOMMU_ERR_MULTIHIT_FAULT(1 << 4) > > > - > > > > I'll use those in the tidspbridge driver, in patches that I plan to push > > soon. > > > > I will apply this patch set on top of mine, see what breaks. Would you > > like me to propose a modified version of this set, or add additional > > patches in my set ? > > Sure, let's try to expose only the minimal amount of omap iommu things with > this patch set so we don't break things. Then the iommu development can > continue on it's own independent of the core omap code except for the > platform data. I'll rebase my DSP patches on top of this patch set then, it will be easier. > But again, if there are nasty layering violations using this code, I would > just remove those features. Those things tend to just get worse unless they > are fixed properly to start with. The long-term goal is to move the tidspbridge driver to the IOMMU API, but we'll need a step by step approach. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/5] ARM: dts: OMAP: Add timer nodes
On 10/24/2012 01:17 PM, Hiremath, Vaibhav wrote: > On Wed, Oct 17, 2012 at 23:31:09, Hunter, Jon wrote: >> Add the 12 GP timers nodes present in OMAP2. >> Add the 12 GP timers nodes present in OMAP3. >> Add the 11 GP timers nodes present in OMAP4. >> Add the 7 GP timers nodes present in AM33xx. >> >> Add documentation for timer properties specific to OMAP. >> >> Please note that for OMAP2/3 devices, there is only one interrupt controller >> for the ARM CPU (which has the label "intc") and so globally define this as >> the >> interrupt parent to save duplicating the interrupt parent for all device >> nodes. >> >> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have >> modified >> Vaibhav's original nodes adding information on which timers support a PWM >> output. >> >> Cc: Benoit Cousson >> Signed-off-by: Jon Hunter >> --- >> .../devicetree/bindings/arm/omap/timer.txt | 29 ++ >> arch/arm/boot/dts/am33xx.dtsi | 61 + >> arch/arm/boot/dts/omap2.dtsi | 86 ++ >> arch/arm/boot/dts/omap2420.dtsi|8 ++ >> arch/arm/boot/dts/omap2430.dtsi|8 ++ >> arch/arm/boot/dts/omap3.dtsi | 96 >> >> arch/arm/boot/dts/omap4.dtsi | 86 ++ >> 7 files changed, 374 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt >> > > Although I have not tested this version of patch series at my end, but > whole patch-series Looks ok to me. > > Acked-By: Vaibhav Hiremath Thanks. I made a couple cosmetic changes in V4 apart from the "interrupt-parent" addition which we are now dropping. Care to ACK patches 2-5 of V4? Thanks Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] gpio/omap: fix off-mode bug: clear debounce clock enable mask on free/reset
On 10/24/2012 12:10 PM, Kevin Hilman wrote: > From: Kevin Hilman > > When a GPIO bank is freed or shutdown, ensure that the banks > dbck_enable_mask is cleared also. Otherwise, context restore on > subsequent off-mode transition will restore previous value from the > shadow copies (bank->context.debounce*) leading to mismatch state > between driver state and hardware state. > > This was discovered when board code was doing > > gpio_request_one() > gpio_set_debounce() > gpio_free() > > which was leaving the GPIO debounce settings in a confused state. If > that GPIO bank is subsequently used with off-mode enabled, bogus state > would be restored, leaving GPIO debounce enabled which then prevented > the CORE powerdomain from transitioning. > > To fix, ensure that bank->dbck_enable_mask is cleared when the bank > is freed/shutdown so debounce state doesn't persist. > > Special thanks to Grazvydas Ignotas for pointing out a bug in an > earlier version that would've disabled debounce on any runtime PM > transition. > > Reported-by: Paul Walmsley > Cc: Igor Grinberg > Cc: Grazvydas Ignotas > Signed-off-by: Kevin Hilman > --- > v2: only clear mask in free/shutdown, not in runtime PM paths, > clarified changelog > Applies on v3.7-rc2. > > drivers/gpio/gpio-omap.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c > index 94cbc84..113b167 100644 > --- a/drivers/gpio/gpio-omap.c > +++ b/drivers/gpio/gpio-omap.c > @@ -539,6 +539,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio) > _set_gpio_irqenable(bank, gpio, 0); > _clear_gpio_irqstatus(bank, gpio); > _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE); > + bank->dbck_enable_mask = 0; > } Does this need to be ... + bank->dbck_enable_mask &= ~(GPIO_BIT(bank, gpio)); + _gpio_dbck_disable(bank); There could be more than one gpio using debounce and so we should only clear the appropriate bit. Also after clearing a bit we could see if we can disable the debounce clock too. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Beagleboard xM - play video file : BUG: scheduling while atomic: queue1:src/92/0x0000008e , then kernel panic
Hi, On Wed, Oct 24, 2012 at 10:34 AM, Felipe Contreras wrote: > Hi, > > Selso, hopefully you don't mind, but I'll forward this to the > linux-omap mailing list, as this seems to be an interesting kernel > problem in tidspbridge. > > Omar, any ideas? I don't see tidspbridge trace paths (but I don't discard something wrong either ;)), however I do see a framebuffer, dss, dispc trace, might be a good point to start checking: [ 467.404663] BUG: scheduling while atomic: >> dspvdec0:src/94/0x008d >> ht=(int)400, pix[ 467.420623] Modules linked in:el-aspect-ratio= >> tidspbridge(C)(fraction)1/1, f mailbox_machramerate=(fracti mailboxon)143/6 >> Pipeli >> ne is PREROLLED [ 467.442810] [] (unwind_backtrace+0x0/0xe0) from >> [] (__schedule_bug+0x48/0x5c) >> ... >> Setting pip[ 467.462066] [] (__schedule_bug+0x48/0x5c) from >> [] (__schedule+0x60/0x798) >> eline to PLAYING[ 467.480987] [] (__schedule+0x60/0x798) from >> [] (schedule_timeout+0x1dc/0x218) >> ... >> New clock:[ 467.500213] [] (schedule_timeout+0x1dc/0x218) from >> [] (wait_for_common+0x104/0x1bc) >> [ 467.520050] [] (wait_for_common+0x104/0x1bc) from [] >> (omap_dispc_wait_for_irq_interruptible_timeout+0x4c/0x84) >> >> [ 467.542510] [] >> (omap_dispc_wait_for_irq_interruptible_timeout+0x4c/0x84) from [] >> (dss_mgr_wait_for_vsync+0x50/0x60) >> [ 467.564208] [] (dss_mgr_wait_for_vsync+0x50/0x60) from >> [] (omapfb_ioctl+0x9cc/0xed0) >> [ 467.583099] [] (omapfb_ioctl+0x9cc/0xed0) from [] >> (do_fb_ioctl+0x56c/0x5a8) >> [ 467.601196] [] (do_fb_ioctl+0x56c/0x5a8) from [] >> (vfs_ioctl+0x24/0x40) >> [ 467.618804] [] (vfs_ioctl+0x24/0x40) from [] >> (do_vfs_ioctl+0x560/0x5a8) >> [ 467.636535] [] (do_vfs_ioctl+0x560/0x5a8) from [] >> (sys_ioctl+0x4c/0x6c) >> [ 467.654205] [] (sys_ioctl+0x4c/0x6c) from [] >> (ret_fast_syscall+0x0/0x30) ... >> CONFIG_TIDSPBRIDGE_CACHE_LINE_CHECK=y I wasn't aware that now gst-dsp supported this, might be time to update mine. Anyway, right now I have lots of debugging enabled and specifically the one that spits "scheduling while atomic" with kernel 3.7-rc2, and I'm not seeing this with the fakesink decode, and the encoder to a file, I don't have framebuffer nor display though. What kernel is this? If non-mainline, I might try it out of curiosity. Regards, Omar -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h
* Laurent Pinchart [121019 02:41]: > On Thursday 18 October 2012 13:28:42 Tony Lindgren wrote: > > --- a/arch/arm/mach-omap2/iommu2.c > > +++ b/arch/arm/mach-omap2/iommu2.c > > @@ -17,6 +17,7 @@ > > #include > > #include > > #include > > +#include > > Nitpicking, please keep the headers sorted alphabetically, here and in all > locations below (especially the OMAP3 ISP driver). > > (OK, there's already one misplaced #include, but let's not make it worse :-)) This is fixed now. > > --- /dev/null > > +++ b/include/linux/omap-iommu.h > > @@ -0,0 +1,47 @@ > > +/* > > + * omap iommu: simple virtual address space management > > + * > > + * Copyright (C) 2008-2009 Nokia Corporation > > + * > > + * Written by Hiroshi DOYU > > + * > > + * This program is free software; you can redistribute it and/or modify > > + * it under the terms of the GNU General Public License version 2 as > > + * published by the Free Software Foundation. > > + */ > > Missing #ifndef #define ... #endif I've added it as _OMAP_IOMMU_H_, looks like both intel-iommu.h and amd-iommu.h have it. Hopefully that's OK for you as a base to do further iommu patches on, updated patch below. BTW, doing a test compile on v3.7-rc2, I'm seeing the following warnings for omap3isp for isp_video_ioctl_ops: drivers/media/platform/omap3isp/ispvideo.c:1213: warning: initialization from incompatible pointer type drivers/media/platform/omap3isp/ispccdc.c:2303: warning: initialization from incompatible pointer type drivers/media/platform/omap3isp/ispccdc.c:2304: warning: initialization from incompatible pointer type drivers/media/platform/omap3isp/isph3a_aewb.c:282: warning: initialization from incompatible pointer type drivers/media/platform/omap3isp/isph3a_aewb.c:283: warning: initialization from incompatible pointer type drivers/media/platform/omap3isp/isph3a_af.c:347: warning: initialization from incompatible pointer type drivers/media/platform/omap3isp/isph3a_af.c:348: warning: initialization from incompatible pointer type drivers/media/platform/omap3isp/isphist.c:453: warning: initialization from incompatible pointer type drivers/media/platform/omap3isp/isphist.c:454: warning: initialization from incompatible pointer type Regards, Tony From: Tony Lindgren Date: Thu, 18 Oct 2012 11:03:16 -0700 Subject: [PATCH] ARM: OMAP2+: Move plat/iovmm.h to include/linux/omap-iommu.h Looks like the iommu framework does not have generic functions exported for all the needs yet. The hardware specific functions are defined in files like intel-iommu.h and amd-iommu.h. Follow the same standard for omap-iommu.h. This is needed because we are removing plat and mach includes for ARM common zImage support. Further work should continue in the iommu framework context as only pure platform data will be communicated from arch/arm/*omap*/* code to the iommu framework. Cc: Joerg Roedel Cc: Ohad Ben-Cohen Cc: Ido Yariv Cc: Laurent Pinchart Cc: Mauro Carvalho Chehab Cc: Omar Ramirez Luna Cc: linux-me...@vger.kernel.org Signed-off-by: Tony Lindgren diff --git a/arch/arm/mach-omap2/iommu2.c b/arch/arm/mach-omap2/iommu2.c index eefc379..e8116cf 100644 --- a/arch/arm/mach-omap2/iommu2.c +++ b/arch/arm/mach-omap2/iommu2.c @@ -15,6 +15,7 @@ #include #include #include +#include #include #include diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h index 7e8c7b6..a4b71b1 100644 --- a/arch/arm/plat-omap/include/plat/iommu.h +++ b/arch/arm/plat-omap/include/plat/iommu.h @@ -216,13 +216,10 @@ static inline struct omap_iommu *dev_to_omap_iommu(struct device *dev) #define MMU_RAM_PADDR_SHIFT12 #define MMU_RAM_PADDR_MASK \ ((~0UL >> MMU_RAM_PADDR_SHIFT) << MMU_RAM_PADDR_SHIFT) -#define MMU_RAM_ENDIAN_SHIFT 9 + #define MMU_RAM_ENDIAN_MASK(1 << MMU_RAM_ENDIAN_SHIFT) -#define MMU_RAM_ENDIAN_BIG (1 << MMU_RAM_ENDIAN_SHIFT) -#define MMU_RAM_ENDIAN_LITTLE (0 << MMU_RAM_ENDIAN_SHIFT) -#define MMU_RAM_ELSZ_SHIFT 7 #define MMU_RAM_ELSZ_MASK (3 << MMU_RAM_ELSZ_SHIFT) -#define MMU_RAM_ELSZ_8 (0 << MMU_RAM_ELSZ_SHIFT) + #define MMU_RAM_ELSZ_16(1 << MMU_RAM_ELSZ_SHIFT) #define MMU_RAM_ELSZ_32(2 << MMU_RAM_ELSZ_SHIFT) #define MMU_RAM_ELSZ_NONE (3 << MMU_RAM_ELSZ_SHIFT) @@ -269,9 +266,6 @@ extern int omap_iommu_set_isr(const char *name, void *priv), void *isr_priv); -extern void omap_iommu_save_ctx(struct device *dev); -extern void omap_iommu_restore_ctx(struct device *dev); - extern int omap_install_iommu_arch(const struct iommu_functions *ops); extern void omap_uninstall_iommu_arch(const struct iommu_functions *ops); diff --git a/arch/arm/plat-omap/include/plat/iovmm.h b/arch/arm/plat-omap/include/plat/iovmm.h deleted file mode 100644 index 498e57c..000 --- a/arch/arm/plat-omap/include/plat/iovmm.h +++ /dev/null @@ -1,89 +0,0 @@ -/* - * omap iommu: simple virtual add
Re: [PATCH V4 1/5] ARM: dts: OMAP: Add timer nodes
On 10/24/2012 10:41 AM, Benoit Cousson wrote: > Hi Jon, > > On 10/19/2012 04:59 PM, Jon Hunter wrote: >> Add the 12 GP timers nodes present in OMAP2. >> Add the 12 GP timers nodes present in OMAP3. >> Add the 11 GP timers nodes present in OMAP4. >> Add the 7 GP timers nodes present in AM33xx. >> >> Add documentation for timer properties specific to OMAP. >> >> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have >> modified >> Vaibhav's original nodes adding information on which timers support a PWM >> output. >> >> Cc: Benoit Cousson >> Signed-off-by: Jon Hunter > > I updated the patch to remove the interrupt-parent from the DTS nodes and the > documentation, as discussed on the list in the context of OMAP5 DTS for GPIO. > > If you are OK with that version, I'll push it to Tony along with the others > DTS patches. Thanks! Yes fine with me. I have boot tested on OMAP2420, OMAP3430 and OMAP4430. Tested-by: Jon Hunter Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] ARM: OMAP2+: Introduce local usb.h
* Felipe Balbi [121019 00:45]: > On Thu, Oct 18, 2012 at 07:20:05PM -0700, Tony Lindgren wrote: > > Let's move what we can from plat/usb.h to the local usb.h > > for ARM common zImage support. > > > > This is needed so we can remove plat/usb.h for ARM common > > zImage support. > > > > Cc: Felipe Balbi > > Acked-by: Felipe Balbi Thanks, I've now pushed these two patches on v3.7-rc1 to omap-for-v3.8/cleanup-headers-usb branch. Greg and Samuel, in case you need to, it's OK to merge the branch above now that plat/usb.h is moved. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi, On Wed, Oct 24, 2012 at 12:38:44PM -0700, Dmitry Torokhov wrote: > On Wednesday, October 24, 2012 10:10:42 PM Felipe Balbi wrote: > > > > > > > > > That is a valid concern and we'll need to find a compromise here. As I > > > said, > > WHAT ?? Silicon erratas are not a valid concern ? Power waste isn't a > > valid concern ? Tell that to the millions of devices shipped with Linux > > everyday. Power usage if it's the top concern in any product, is right > > there as the top five. Likewise for silicon erratas. > > I think we should come back to this discussion when you get more coffee > and start parsing other party e-mails properly. indeed. I really misparsed it. My bad. comments withdrawn. -- balbi signature.asc Description: Digital signature
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Wednesday, October 24, 2012 10:10:42 PM Felipe Balbi wrote: > > > > > > That is a valid concern and we'll need to find a compromise here. As I > > said, > WHAT ?? Silicon erratas are not a valid concern ? Power waste isn't a > valid concern ? Tell that to the millions of devices shipped with Linux > everyday. Power usage if it's the top concern in any product, is right > there as the top five. Likewise for silicon erratas. I think we should come back to this discussion when you get more coffee and start parsing other party e-mails properly. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi, On Wed, Oct 24, 2012 at 10:58:53AM -0700, Dmitry Torokhov wrote: > On Wednesday, October 24, 2012 07:57:49 PM Felipe Balbi wrote: > > Hi, > > > > On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote: > > > On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote: > > > > On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov > > > > > > > > wrote: > > > > > I have seen just in a few days 3 or 4 drivers having exactly the same > > > > > change - call to devm_pinctrl_get_select_default(), and I guess I will > > > > > receive the same patches for the rest of input drivers shortly. > > > > > This suggests that the operation is done at the wrong level. Do the > > > > > pin configuration as you parse DT data, the same way you set up i2c > > > > > devices registers in of_i2c.c, and leave the individual drivers that > > > > > do > > > > > not care about specifics alone. > > > > > > > > Exactly this can be done with pinctrl hogs. > > > > > > > > The problem with that is that it removes the cross-reference > > > > between the device and it's pinctrl handle (also from the device > > > > tree). Instead the pinctrl handle gets referenced to the pin controller > > > > itself. So from a modelling perpective this looks a bit ugly. > > > > > > > > So we have two kinds of ugly: > > > > > > > > - Sprinke devm_pinctrl_get_select_default() over all drivers > > > > > > > > which makes pinctrl handles properly reference their devices > > > > > > > > - Use hogs and loose coupling between pinctrl handles and their > > > > > > > > devices > > > > > > > > A third alternative as outlined is to use notifiers and some > > > > resource core in drivers/base/* > > > > > > OK, so with drivers/base/, have you considered doing default pinctrl > > > selection in bus's probe() methods? Yo would select the default > > > configuration before starting probing the device and maybe select idle > > > when probe fails or device is unbound? That would still keep the link > > > between device object and pinctrl and there less busses than device > > > drivers out there. > > > > it starts to become confusing after a while. I mean, there's a reason > > why all drivers explictly call pm_runtim_enable(), right ? > > Right. Because not all of them support runtime PM and quite usually their > PM methods are not ready to go until initialization is complete. And again, > the driver here controls its own behavior. likewise not all devices will need pin muxing, those which do (granted, an increasing number of them since transistor size continue to shrink, allowing chip manufacturers to pack more features inside a single die, while the number of external pins/balls remain the same), will call pinctrl to setup muxing right. > > From a first thought, one could think of just yanking that into bus' > > probe() as you may suggest, but sometimes the device is already enabled, > > so we need extra tricks: > > > > pm_runtime_set_active(); > > pm_runtime_enable(); > > pm_runtime_get(); > > > > the same could happen with pinctrl eventually. What if a device needs to > > do something else (an errata fix as an example) before requesting > > pinctrl's default state ? > > That is a valid concern and we'll need to find a compromise here. As I said, WHAT ?? Silicon erratas are not a valid concern ? Power waste isn't a valid concern ? Tell that to the millions of devices shipped with Linux everyday. Power usage if it's the top concern in any product, is right there as the top five. Likewise for silicon erratas. Let's face it, just like SW, HW has bugs; the difference is that no company will continue to do several spins of an ASIC just because some SW engineer doesn't get concerned about a silicon bug. It's just too expensive to re-spin the ASIC. And even if we get another revision of the ASIC, we still need to support the older version as there might be cellphones, laser welding machines, IPTVs and whatever product already shipped. > I am not saying that no driver should ever touch pinctrl. I can see, for > example, input drivers actually disabling pins until they are ->open()ed, > in addition of doing that at [runtime] suspend/resume. But it would be nice > if we could have "dumb" drivers not care about pins. Like I replied on another sub-thread, this will just create exceptions to the rule which is far more messy than having a couple of extra lines of code in a few drivers. We can even argue that eventually all drivers will need to toggle pins in runtime in order to save that extra microwatt of runtime power consumption, so why bother adding exceptions ? In fact, we already have the exception: drivers which don't need to fiddle with pin muxing, just don't use pinctrl. The ones you're receiving today are the one which, for whatever reason, need to make sure pin muxing is right. If it's not toggling in runtime, it might just be because $AUTHOR decided that it would be best to do thing in small steps (don't we all agree with that ?). Mayb
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi, On Wed, Oct 24, 2012 at 10:28:46AM -0700, Dmitry Torokhov wrote: > > for more complex pinctrl use cases. These are my dogfood drivers ... > > Most of these will request more than one state and switch the driver > > between these different states at runtime, in these examples for power > > saving there are states named "default", "sleep" and in the I2C driver > > also "idle". > > > > These examples are more typical to how the ux500 platform will > > look, also the SKE input driver will move the devise to sleep/default > > states but we need to merge PM code before we can do that. > > I do not say that no drivers should ever touch pinctrl, just that most > of them do not have to if you have other layers to the right thing for > them. It will be a much bigger mess. Some drivers don't need to care about pinctrl because drivers/base handle it for them, while some others will need a way to tell drivers/base "hey, don't touch pinctrl at all because I know what I'm doing" and that has to happen before probe() too, otherwise it's already too late and, according to what you suggest, drivers/base will already have touched pinctrl. The only way I see would be to add an extra "dont_touch_my_pins" field to every driver structure in the kernel. Clearly what you say is nonsense. -- balbi signature.asc Description: Digital signature
Re: [PATCH] Revert "serial: omap: fix software flow control"
On Wed, Oct 24, 2012 at 11:57:42AM -0700, Greg KH wrote: > On Wed, Oct 24, 2012 at 01:02:55PM +0300, Felipe Balbi wrote: > > Hi Greg, > > > > On Tue, Oct 16, 2012 at 08:13:59AM -0700, Tony Lindgren wrote: > > > * Felipe Balbi [121016 07:16]: > > > > This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 > > > > (serial: omap: fix software flow control). > > > > > > > > As Russell has pointed out, that commit isn't fixing > > > > Software Flow Control at all, and it actually makes > > > > it even more broken. > > > > > > > > It was agreed to revert this commit and use Russell's > > > > latest UART patches instead. > > > > > > > > Cc: Russell King > > > > Signed-off-by: Felipe Balbi > > > > > > This seems like the best way to go for the -rc series: > > > > > > Acked-by: Tony Lindgren > > > > Any chance you can pick this one up for v3.7-rc3 ? > > Now queued up, sorry for the delay. no problems, thanks a lot. -- balbi signature.asc Description: Digital signature
Re: [PATCH] Revert "serial: omap: fix software flow control"
On Wed, Oct 24, 2012 at 01:02:55PM +0300, Felipe Balbi wrote: > Hi Greg, > > On Tue, Oct 16, 2012 at 08:13:59AM -0700, Tony Lindgren wrote: > > * Felipe Balbi [121016 07:16]: > > > This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 > > > (serial: omap: fix software flow control). > > > > > > As Russell has pointed out, that commit isn't fixing > > > Software Flow Control at all, and it actually makes > > > it even more broken. > > > > > > It was agreed to revert this commit and use Russell's > > > latest UART patches instead. > > > > > > Cc: Russell King > > > Signed-off-by: Felipe Balbi > > > > This seems like the best way to go for the -rc series: > > > > Acked-by: Tony Lindgren > > Any chance you can pick this one up for v3.7-rc3 ? Now queued up, sorry for the delay. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] omap fixes for v3.7-rc2
The following changes since commit 6f0c0580b70c89094b3422ba81118c7b959c7556: Linux 3.7-rc2 (2012-10-20 12:11:32 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.7-rc2/fixes-signed for you to fetch changes up to 12ac7f9e117facfe128d6e569953fa73d2d676b3: ARM: AM33XX: Fix configuration of dmtimer parent clock by dmtimer driverDate:Wed, 17 Oct 2012 13:55:55 -0500 (2012-10-23 18:58:21 -0700) Timer fix for am33xx, runtime PM fix for UART, audio McBSP fixes, mux and pinctrl fixes, and Beagle OPP fix. Kevin Hilman (2): ARM: OMAP2: UART: fix console UART mismatched runtime PM status ARM: OMAP3: Beagle: fix OPP customization and initcall ordering Paul Walmsley (1): ARM: OMAP3: PM: apply part of the erratum i582 workaround Peter Ujfalusi (1): ARM/dts: omap3: Fix mcbsp2/3 hwmods to be able to probe the drivers for audio Tony Lindgren (3): ARM: OMAP2+: Fix location of select PINCTRL ARM: OMAP3: Fix 3430 legacy mux names for ssi1 signals. Merge tag 'for_3.7-rc3-fixes-pm' of git://git.kernel.org/.../khilman/linux-omap-pm into omap-for-v3.7-rc2/fixes Vaibhav Hiremath (1): ARM: AM33XX: Fix configuration of dmtimer parent clock by dmtimer driverDate:Wed, 17 Oct 2012 13:55:55 -0500 arch/arm/boot/dts/omap3.dtsi|4 ++-- arch/arm/mach-omap2/Kconfig |1 - arch/arm/mach-omap2/board-omap3beagle.c | 22 +- arch/arm/mach-omap2/clock33xx_data.c|2 ++ arch/arm/mach-omap2/mux34xx.c |8 arch/arm/mach-omap2/pm.h|1 + arch/arm/mach-omap2/pm34xx.c| 30 -- arch/arm/mach-omap2/serial.c|5 + arch/arm/plat-omap/Kconfig |1 + 9 files changed, 56 insertions(+), 18 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH V3 1/5] ARM: dts: OMAP: Add timer nodes
On Wed, Oct 17, 2012 at 23:31:09, Hunter, Jon wrote:
> Add the 12 GP timers nodes present in OMAP2.
> Add the 12 GP timers nodes present in OMAP3.
> Add the 11 GP timers nodes present in OMAP4.
> Add the 7 GP timers nodes present in AM33xx.
>
> Add documentation for timer properties specific to OMAP.
>
> Please note that for OMAP2/3 devices, there is only one interrupt controller
> for the ARM CPU (which has the label "intc") and so globally define this as
> the
> interrupt parent to save duplicating the interrupt parent for all device
> nodes.
>
> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have
> modified
> Vaibhav's original nodes adding information on which timers support a PWM
> output.
>
> Cc: Benoit Cousson
> Signed-off-by: Jon Hunter
> ---
> .../devicetree/bindings/arm/omap/timer.txt | 29 ++
> arch/arm/boot/dts/am33xx.dtsi | 61 +
> arch/arm/boot/dts/omap2.dtsi | 86 ++
> arch/arm/boot/dts/omap2420.dtsi|8 ++
> arch/arm/boot/dts/omap2430.dtsi|8 ++
> arch/arm/boot/dts/omap3.dtsi | 96
>
> arch/arm/boot/dts/omap4.dtsi | 86 ++
> 7 files changed, 374 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
>
Although I have not tested this version of patch series at my end, but
whole patch-series Looks ok to me.
Acked-By: Vaibhav Hiremath
Thanks,
Vaibhav
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
> b/Documentation/devicetree/bindings/arm/omap/timer.txt
> new file mode 100644
> index 000..d9449d0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -0,0 +1,29 @@
> +OMAP Timer bindings
> +
> +Required properties:
> +- compatible:Must be "ti,omap2-timer" for OMAP2+ controllers
> +- reg: Contains timer register address range (base address and
> length)
> +- interrupts:Contains the interrupt information for the timer. The
> format is
> + being dependent on which interrupt controller the OMAP device
> + uses.
> +- ti,hwmods: Name of the hwmod associated to the timer, "timer", where
> + is the instance number of the timer from the HW spec.
> +
> +Optional properties:
> +- ti,timer-alwon:Indicates the timer is in an alway-on power domain.
> +- ti,timer-dsp: Indicates the timer can interrupt the on-chip
> DSP in
> + addition to the ARM CPU.
> +- ti,timer-pwm: Indicates the timer can generate a PWM output.
> +- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
> + and therefore cannot be used by the kernel.
> +
> +Example:
> +
> +timer12: timer@48304000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48304000 0xfff>;
> + interrupts = <95>;
> + ti,hwmods = "timer12"
> + ti,timer-alwon;
> + ti,timer-secure;
> +};
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index bb31bff..fd5074c 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -210,5 +210,66 @@
> interrupt-parent = <&intc>;
> interrupts = <91>;
> };
> +
> + timer1: timer@44e31000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x44e31000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <67>;
> + ti,hwmods = "timer1";
> + ti,timer-alwon;
> + };
> +
> + timer2: timer@4804 {
> + compatible = "ti,omap2-timer";
> + reg = <0x4804 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <68>;
> + ti,hwmods = "timer2";
> + };
> +
> + timer3: timer@48042000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48042000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <69>;
> + ti,hwmods = "timer3";
> + };
> +
> + timer4: timer@48044000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48044000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <92>;
> + ti,hwmods = "timer4";
> + ti,timer-pwm;
> + };
> +
> + timer5: timer@48046000 {
> + compatible = "ti,omap2-timer";
> + reg = <0x48046000 0x1000>;
> + interrupt-parent = <&intc>;
> + interrupts = <93>;
> +
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Wednesday, October 24, 2012 07:57:49 PM Felipe Balbi wrote: > Hi, > > On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote: > > On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote: > > > On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov > > > > > > wrote: > > > > I have seen just in a few days 3 or 4 drivers having exactly the same > > > > change - call to devm_pinctrl_get_select_default(), and I guess I will > > > > receive the same patches for the rest of input drivers shortly. > > > > This suggests that the operation is done at the wrong level. Do the > > > > pin configuration as you parse DT data, the same way you set up i2c > > > > devices registers in of_i2c.c, and leave the individual drivers that > > > > do > > > > not care about specifics alone. > > > > > > Exactly this can be done with pinctrl hogs. > > > > > > The problem with that is that it removes the cross-reference > > > between the device and it's pinctrl handle (also from the device > > > tree). Instead the pinctrl handle gets referenced to the pin controller > > > itself. So from a modelling perpective this looks a bit ugly. > > > > > > So we have two kinds of ugly: > > > > > > - Sprinke devm_pinctrl_get_select_default() over all drivers > > > > > > which makes pinctrl handles properly reference their devices > > > > > > - Use hogs and loose coupling between pinctrl handles and their > > > > > > devices > > > > > > A third alternative as outlined is to use notifiers and some > > > resource core in drivers/base/* > > > > OK, so with drivers/base/, have you considered doing default pinctrl > > selection in bus's probe() methods? Yo would select the default > > configuration before starting probing the device and maybe select idle > > when probe fails or device is unbound? That would still keep the link > > between device object and pinctrl and there less busses than device > > drivers out there. > > it starts to become confusing after a while. I mean, there's a reason > why all drivers explictly call pm_runtim_enable(), right ? Right. Because not all of them support runtime PM and quite usually their PM methods are not ready to go until initialization is complete. And again, the driver here controls its own behavior. > > From a first thought, one could think of just yanking that into bus' > probe() as you may suggest, but sometimes the device is already enabled, > so we need extra tricks: > > pm_runtime_set_active(); > pm_runtime_enable(); > pm_runtime_get(); > > the same could happen with pinctrl eventually. What if a device needs to > do something else (an errata fix as an example) before requesting > pinctrl's default state ? That is a valid concern and we'll need to find a compromise here. As I said, I am not saying that no driver should ever touch pinctrl. I can see, for example, input drivers actually disabling pins until they are ->open()ed, in addition of doing that at [runtime] suspend/resume. But it would be nice if we could have "dumb" drivers not care about pins. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi Dmitry, On 10/24/2012 06:14 PM, Dmitry Torokhov wrote: > On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote: >> Hi, >> >> On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote: >>> On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote: Hi Dimitry, On 10/22/2012 05:50 PM, Dmitry Torokhov wrote: > Hi Sourav, > > On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote: >> Adapt keypad to use pinctrl framework. >> >> Tested on omap4430 sdp with 3.7-rc1 kernel. > > I do not see anything in the driver that would directly use pinctrl. Is > there a better place to select default pin configuration; maybe when > instantiating platform device? Why? The devm_pinctrl_get_select_default is using the pinctrl. >>> >>> No, I guess we ihave different understanding of what "directly use" means. >>> This particular driver does directly use interrupts: it requests it and >>> performs some actions when interrupt arrives. Same goes for IO memory - >>> it gets requested, then we access it. With pinctrl we do not do anything >>> - we just ask another layer to configure it and that is it. >> >> this is true for almost anything we do: >> >> - we ask another layer to allocate memory for us >> - we ask another layer to call our ISR once the IRQ line is asserted >> - we ask another layer to handle the input events we just received >> - we ask another layer to transfer data through DMA for us >> - we ask another layer to turn regulators on and off. > > But we are _directly_ _using_ all of these. You allocate memory and you > (the driver) stuff data into that memory. You ask for DMA and you take > the DMAed data and work with it. Not so with pinctrl in omap keypad and > other drivers I have seen so far. That's not really true. You select a pin mode and thanks to that you get the signal from an external pin that goes to your IP. And thanks to that the IP is doing what your are expecting it to do. Without that your IP will not get any input signal, which will make it a little bit useless, isn't it? >> and so on. This is just how abstractions work, we group common parts in >> a framework so that users don't need to know the details, but still need >> to tell the framework when to fiddle with those resources. >> >>> I have seen just in a few days 3 or 4 drivers having exactly the same >>> change - call to devm_pinctrl_get_select_default(), and I guess I will >>> receive the same patches for the rest of input drivers shortly. >>> This suggests that the operation is done at the wrong level. Do the >>> pin configuration as you parse DT data, the same way you set up i2c >>> devices registers in of_i2c.c, and leave the individual drivers that do >>> not care about specifics alone. >> >> Makes no sense to hide that from drivers. The idea here is that driver >> should know when it needs its pins to muxed correctly. > > The driver also needs memory controller to be initialized, gpio chip be > ready and registered, DMA subsystem ready, input core reade, etc, etc, > etc. You however do not have every driver explicitly initialize any of > that; you expect certain working environment to be already operable. The > driver does manage resources it controls, it has ultimate knowledge > about, pin configuration is normally is not it. We just need to know > that we wired/muxed properly, otherwise we won't work. So please let > parent layers deal with it. > >> 95% of the time >> it will be done during probe() but then again, so what ? >> >> doing that when parsing DT, or on bus notifiers is just plain wrong. >> Drivers should be required to handle all of their resources. > > All of _their_ resources, exactly. They do not own nor control pins so > they should not be bothered with them either. Look, when you see that > potentially _every_ driver in the system needs to set up the same object > that it doe snot use otherwise you should realize that individual driver > is not the proper place to do that. What your are missing as well in that case is the explicit dependency that this API is creating with the pinctrl driver that we are going to miss otherwise. Hence the following code. + if (PTR_ERR(keypad_data->pins) == -EPROBE_DEFER) + return -EPROBE_DEFER; If the pinctrl is not already there you defer the probe until it is there. Moreover, as already said, we are probably at some point going to handle as well the low power mode and thus change the pin mode upon idle/suspend. And again, selecting a pin mode during probe is doing something with the pins when and only when it is useful. It is not different than getting an IRQ or DMA request at probe time. You get it, use it for registration and that all you are doing with it. It is no different here. Doing that during device creation does not make sense, since that device might never be used. Is it like allocating the memory by default for every devices at bo
Re: [PATCH] ARM: PMU: fix runtime PM enable
On 10/24/2012 12:23 PM, Will Deacon wrote: > On Wed, Oct 24, 2012 at 04:06:07PM +0100, Jon Hunter wrote: >> On 10/24/2012 09:32 AM, Will Deacon wrote: >>> Hmmm, now I start to wonder whether your original idea of having separate >>> callbacks for enable/disable irq and resume/suspend doesn't make more sense. >>> Then the CTI magic can go in the irq management code and be totally separate >>> to the PM stuff. >>> >>> What do you reckon? >> >> The resume/suspend calls really replaced the enable/disable irq >> callbacks. That still seems like a good approach given that we need >> runtime PM for OMAP and PMU. > > Ok, perhaps splitting it up isn't worth it then. I'm still not convinced > either way. Given that we needed to employ runtime PM for OMAP, adding the handlers is a natural progression and fits more with the PM framework model. >>> Nah, we should be able to fix this in the platdata, I'd just rather have >>> function pointers instead of state variables in there. >> >> Well, we could pass a pointer to pm_runtime_enable() function in the >> platdata. > > What do other drivers do? Grepping around, I see calls to pm_runtime_enable > made in various drivers and, given that you pass the device in there, what's > the problem with us just calling that unconditionally from perf? I know you > said that will work for OMAP, but I'm trying to understand the effect that > has on PM-aware platforms that don't require this for the PMU (since this > seems to be per-device). I had done this initially when testing on OMAP platforms that do and don't require runtime PM for PMU. I don't see any side affect of this, however, may be Kevin could comment on if that is ok. It would be the best approach. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Wednesday, October 24, 2012 07:52:16 PM Felipe Balbi wrote: > Hi, > > On Wed, Oct 24, 2012 at 09:14:29AM -0700, Dmitry Torokhov wrote: > > > > > > > No, I guess we ihave different understanding of what "directly use" > > > > means. > > > > This particular driver does directly use interrupts: it requests it > > > > and > > > > performs some actions when interrupt arrives. Same goes for IO memory > > > > - > > > > it gets requested, then we access it. With pinctrl we do not do > > > > anything > > > > - we just ask another layer to configure it and that is it. > > > > > > this is true for almost anything we do: > > > > > > - we ask another layer to allocate memory for us > > > - we ask another layer to call our ISR once the IRQ line is asserted > > > - we ask another layer to handle the input events we just received > > > - we ask another layer to transfer data through DMA for us > > > - we ask another layer to turn regulators on and off. > > > > But we are _directly_ _using_ all of these. You allocate memory and you > > (the driver) stuff data into that memory. You ask for DMA and you take > > the DMAed data and work with it. Not so with pinctrl in omap keypad and > > other drivers I have seen so far. > > of course we are. If we don't mux the pins to their correct setting, we > can't realy use the HW. So while you don't see any SW control of the > requested pins, we're still making use of them. So we make use of CPU too, and the main power supply, and memory chips. > > > > and so on. This is just how abstractions work, we group common parts in > > > a framework so that users don't need to know the details, but still need > > > to tell the framework when to fiddle with those resources. > > > > > > > I have seen just in a few days 3 or 4 drivers having exactly the same > > > > change - call to devm_pinctrl_get_select_default(), and I guess I will > > > > receive the same patches for the rest of input drivers shortly. > > > > This suggests that the operation is done at the wrong level. Do the > > > > pin configuration as you parse DT data, the same way you set up i2c > > > > devices registers in of_i2c.c, and leave the individual drivers that > > > > do > > > > not care about specifics alone. > > > > > > Makes no sense to hide that from drivers. The idea here is that driver > > > should know when it needs its pins to muxed correctly. > > > > The driver also needs memory controller to be initialized, gpio chip be > > ready and registered, DMA subsystem ready, input core reade, etc, etc, > > etc. You however do not have every driver explicitly initialize any of > > that; you expect certain working environment to be already operable. The > > driver does manage resources it controls, it has ultimate knowledge > > about, pin configuration is normally is not it. We just need to know > > that we wired/muxed properly, otherwise we won't work. So please let > > parent layers deal with it. > > > > > 95% of the time > > > it will be done during probe() but then again, so what ? > > > > > > doing that when parsing DT, or on bus notifiers is just plain wrong. > > > Drivers should be required to handle all of their resources. > > > > All of _their_ resources, exactly. They do not own nor control pins so > > they should not be bothered with them either. Look, when you see that > > except that they *own* the pins. Now that the muxer has been setup > properly, this particular IP owns the pins. > > > potentially _every_ driver in the system needs to set up the same object > > that it doe snot use otherwise you should realize that individual driver > > is not the proper place to do that. > > fair enough, but IMHO, we're not there yet. We can't make that claim > yet. Besides, we don't know what's the default pin state in a system. It > might be that certain pins start out in a way which consumes less power > due to the internal construction of the SoC. If we set pins up before > driver probes, and probe fails or the driver is never really used, then > we could be falling into a situation where we're wasting power. So what about moving this into bus code - have bus's probe() request default pin config before probe, revert to original setup when unbinding or probe fails. You can even plug PM switching into bus code as well. > > Granted, you can undo everything you did before, Right, the same way as we undo every other initialization when something goes wrong. > but I guess keeping > track of everything we setup before probe() just to remove a couple of > lines from drivers is wrong. If it was just about a couple lines in a couple of drivers that would be fine. But the way I see it eventually every driver will need to do this. > > > > > > That's why it is named "get_select_default" and not "get" only. > > > > > This API ensure that the pin will be set to the default state, and > > > > > this > > > > > is all we need to do during the probe. > > > > > > > > Why during the probe and not by default? Reali
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Wednesday, October 24, 2012 06:51:47 PM Linus Walleij wrote: > On Wed, Oct 24, 2012 at 6:14 PM, Dmitry Torokhov > > wrote: > > On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote: > >> - we ask another layer to allocate memory for us > >> - we ask another layer to call our ISR once the IRQ line is asserted > >> - we ask another layer to handle the input events we just received > >> - we ask another layer to transfer data through DMA for us > >> - we ask another layer to turn regulators on and off. > > > > But we are _directly_ _using_ all of these. You allocate memory and you > > (the driver) stuff data into that memory. You ask for DMA and you take > > the DMAed data and work with it. Not so with pinctrl in omap keypad and > > other drivers I have seen so far. > > Consult: > drivers/tty/serial/amba-pl011.c OK. > drivers/spi/spi-pl022.c Default/sleep transitions could be moved into bus code. > drivers/i2c/busses/i2c-nomadik.c Don't see pinctrl in linux-next. > for more complex pinctrl use cases. These are my dogfood drivers ... > Most of these will request more than one state and switch the driver > between these different states at runtime, in these examples for power > saving there are states named "default", "sleep" and in the I2C driver > also "idle". > > These examples are more typical to how the ux500 platform will > look, also the SKE input driver will move the devise to sleep/default > states but we need to merge PM code before we can do that. I do not say that no drivers should ever touch pinctrl, just that most of them do not have to if you have other layers to the right thing for them. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: PMU: fix runtime PM enable
On Wed, Oct 24, 2012 at 04:06:07PM +0100, Jon Hunter wrote: > On 10/24/2012 09:32 AM, Will Deacon wrote: > > Hmmm, now I start to wonder whether your original idea of having separate > > callbacks for enable/disable irq and resume/suspend doesn't make more sense. > > Then the CTI magic can go in the irq management code and be totally separate > > to the PM stuff. > > > > What do you reckon? > > The resume/suspend calls really replaced the enable/disable irq > callbacks. That still seems like a good approach given that we need > runtime PM for OMAP and PMU. Ok, perhaps splitting it up isn't worth it then. I'm still not convinced either way. > > Nah, we should be able to fix this in the platdata, I'd just rather have > > function pointers instead of state variables in there. > > Well, we could pass a pointer to pm_runtime_enable() function in the > platdata. What do other drivers do? Grepping around, I see calls to pm_runtime_enable made in various drivers and, given that you pass the device in there, what's the problem with us just calling that unconditionally from perf? I know you said that will work for OMAP, but I'm trying to understand the effect that has on PM-aware platforms that don't require this for the PMU (since this seems to be per-device). Will -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] ARM: dts: OMAP: Move interrupt-parent to the root node to avoid duplication
On Wed, Oct 24, 2012 at 15:32:14, Cousson, Benoit wrote:
> The interrupt-parent attribute does not have to be added in each
> node since the DT framework will check for the parent as well to get it.
>
> Create an interrupt-parent for OMAP2, OMAP3, AM33xx and remove the
> attributes from every nodes that were using it.
>
> Signed-off-by: Benoit Cousson
> Cc: Vaibhav Hiremath
> Cc: Peter Ujfalusi
> Cc: Sebastien Guiriec
> ---
>
> This patch was triggered by the thread about Seb's patch [1].
> So let's clean the current OMAP/AM stuff right now to be consistent.
>
> The patch applies on top of the for_3.8/dts [2] branch.
>
> Regards,
> Benoit
>
> [1] https://lkml.org/lkml/2012/10/24/85
> [2] git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
>
>
> arch/arm/boot/dts/am33xx.dtsi | 17 +
> arch/arm/boot/dts/omap2.dtsi|1 +
> arch/arm/boot/dts/omap2420.dtsi |2 --
> arch/arm/boot/dts/omap2430.dtsi |5 -
> arch/arm/boot/dts/omap3.dtsi|6 +-
> arch/arm/boot/dts/omap4.dtsi|6 --
> arch/arm/boot/dts/omap5.dtsi|5 -
> 7 files changed, 3 insertions(+), 39 deletions(-)
>
Looks good to me.
Acked-by: Vaibhav Hiremath
Thanks,
Vaibhav
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 64c2efe..4709269 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -12,6 +12,7 @@
>
> / {
> compatible = "ti,am33xx";
> + interrupt-parent = <&intc>;
>
> aliases {
> serial0 = &uart1;
> @@ -94,7 +95,6 @@
> interrupt-controller;
> #interrupt-cells = <1>;
> reg = <0x44e07000 0x1000>;
> - interrupt-parent = <&intc>;
> interrupts = <96>;
> };
>
> @@ -106,7 +106,6 @@
> interrupt-controller;
> #interrupt-cells = <1>;
> reg = <0x4804c000 0x1000>;
> - interrupt-parent = <&intc>;
> interrupts = <98>;
> };
>
> @@ -118,7 +117,6 @@
> interrupt-controller;
> #interrupt-cells = <1>;
> reg = <0x481ac000 0x1000>;
> - interrupt-parent = <&intc>;
> interrupts = <32>;
> };
>
> @@ -130,7 +128,6 @@
> interrupt-controller;
> #interrupt-cells = <1>;
> reg = <0x481ae000 0x1000>;
> - interrupt-parent = <&intc>;
> interrupts = <62>;
> };
>
> @@ -139,7 +136,6 @@
> ti,hwmods = "uart1";
> clock-frequency = <4800>;
> reg = <0x44e09000 0x2000>;
> - interrupt-parent = <&intc>;
> interrupts = <72>;
> status = "disabled";
> };
> @@ -149,7 +145,6 @@
> ti,hwmods = "uart2";
> clock-frequency = <4800>;
> reg = <0x48022000 0x2000>;
> - interrupt-parent = <&intc>;
> interrupts = <73>;
> status = "disabled";
> };
> @@ -159,7 +154,6 @@
> ti,hwmods = "uart3";
> clock-frequency = <4800>;
> reg = <0x48024000 0x2000>;
> - interrupt-parent = <&intc>;
> interrupts = <74>;
> status = "disabled";
> };
> @@ -169,7 +163,6 @@
> ti,hwmods = "uart4";
> clock-frequency = <4800>;
> reg = <0x481a6000 0x2000>;
> - interrupt-parent = <&intc>;
> interrupts = <44>;
> status = "disabled";
> };
> @@ -179,7 +172,6 @@
> ti,hwmods = "uart5";
> clock-frequency = <4800>;
> reg = <0x481a8000 0x2000>;
> - interrupt-parent = <&intc>;
> interrupts = <45>;
> status = "disabled";
> };
> @@ -189,7 +181,6 @@
> ti,hwmods = "uart6";
> clock-frequency = <4800>;
> reg = <0x481aa000 0x2000>;
> - interrupt-parent = <&intc>;
> interrupts = <46>;
> status = "disabled";
> };
> @@ -200,7 +191,6 @@
> #size-cells = <0>;
> ti,hwmods = "i2c1";
> reg = <0x44e0b000 0x1000>;
> - interrupt-parent = <&intc>;
> interrupts = <70>;
> sta
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Wed, Oct 24, 2012 at 6:57 PM, Felipe Balbi wrote: > On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote: >> OK, so with drivers/base/, have you considered doing default pinctrl >> selection in bus's probe() methods? Yo would select the default >> configuration before starting probing the device and maybe select idle >> when probe fails or device is unbound? That would still keep the link >> between device object and pinctrl and there less busses than device >> drivers out there. > > it starts to become confusing after a while. I mean, there's a reason > why all drivers explictly call pm_runtim_enable(), right ? > > From a first thought, one could think of just yanking that into bus' > probe() as you may suggest, but sometimes the device is already enabled, > so we need extra tricks: > > pm_runtime_set_active(); > pm_runtime_enable(); > pm_runtime_get(); > > the same could happen with pinctrl eventually. What if a device needs to > do something else (an errata fix as an example) before requesting > pinctrl's default state ? I can confirm this. Just the ordering between enabling/disabling resources like clock/pins/powerdomain screw things up for us and even if we can surely centralize parts of this code as such into the drivers/base or pm_* namespace we would still need explicit calls from the driver. I'm thinking that maybe the best helpers are actually static inline functions in the header rather than moving anything into drivers/base/* if the code duplication is the real problem. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [balbi-usb:i2c-transferred-bytes-on-NACK 7/9] drivers/media/i2c/adv7604.c:406:9: warning: initialization makes integer from pointer without a cast
On Wed, Oct 24, 2012 at 04:37:20PM +0300, Felipe Balbi wrote: > Hi, > > On Wed, Oct 24, 2012 at 09:23:23PM +0800, Fengguang Wu wrote: > > Sorry, this should really be CCed to the media list. > > I'll use the list recommended by get_maintainer.pl in future. > > Actually, I would suggest only testing the following branches from my > tree: > > dwc3, musb, xceiv, gadget and fixes > > Those are my final branches, everything else is a temporary branch that > I'm using just so I don't loose some patches, or to make it easy for > other guys to test patches. Balbi, thanks for the instructions. I'll limit future tests to the above branches. Thanks, Fengguang -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Wed, Oct 24, 2012 at 6:52 PM, Felipe Balbi wrote: > On Wed, Oct 24, 2012 at 09:14:29AM -0700, Dmitry Torokhov wrote: >> All of _their_ resources, exactly. They do not own nor control pins so >> they should not be bothered with them either. Look, when you see that > > except that they *own* the pins. Now that the muxer has been setup > properly, this particular IP owns the pins. This is true. It is then also reflected in the device model. And in debugfs, which is very helpful when debugging. If I cat /sys/kernel/debug/pinctrl/pinctrl-db8500/pins I can see a list of all pins on this ASIC and what device is using it. It is all due to the fact that each driver use [devm_]pinctrl_get(&dev) ad the struct device * pointer is used with dev_name() to print the corresponding device name. When using hogs it just says the name of the pin controller and the pins aren't really connected to their real consumers :-P Example: Pinmux settings per pin Format: pin (name): mux_owner gpio_owner hog? pin 0 (GPIO0_AJ5): (MUX UNCLAIMED) (GPIO UNCLAIMED) pin 1 (GPIO1_AJ3): (MUX UNCLAIMED) (GPIO UNCLAIMED) pin 2 (GPIO2_AH4): (MUX UNCLAIMED) (GPIO UNCLAIMED) pin 3 (GPIO3_AH3): (MUX UNCLAIMED) (GPIO UNCLAIMED) pin 4 (GPIO4_AH6): (MUX UNCLAIMED) (GPIO UNCLAIMED) pin 5 (GPIO5_AG6): (MUX UNCLAIMED) DB8500:5 pin 6 (GPIO6_AF6): pinctrl-db8500 (GPIO UNCLAIMED) function ipgpio group ipgpio0_c_1 pin 7 (GPIO7_AG5): pinctrl-db8500 (GPIO UNCLAIMED) function ipgpio group ipgpio1_c_1 pin 8 (GPIO8_AD5): (MUX UNCLAIMED) (GPIO UNCLAIMED) pin 9 (GPIO9_AE4): (MUX UNCLAIMED) (GPIO UNCLAIMED) pin 10 (GPIO10_AF5): nmk-i2c.2 (GPIO UNCLAIMED) function i2c2 group i2c2_b_2 pin 11 (GPIO11_AG4): nmk-i2c.2 (GPIO UNCLAIMED) function i2c2 group i2c2_b_2 pin 12 (GPIO12_AC4): pinctrl-db8500 (GPIO UNCLAIMED) function msp0 group msp0txrx_a_1 pin 13 (GPIO13_AF3): pinctrl-db8500 (GPIO UNCLAIMED) function msp0 group msp0tfstck_a_1 pin 14 (GPIO14_AE3): pinctrl-db8500 (GPIO UNCLAIMED) function msp0 group msp0tfstck_a_1 pin 15 (GPIO15_AC3): pinctrl-db8500 (GPIO UNCLAIMED) function msp0 group msp0txrx_a_1 pin 16 (GPIO16_AD3): nmk-i2c.1 (GPIO UNCLAIMED) function i2c1 group i2c1_b_2 pin 17 (GPIO17_AD4): nmk-i2c.1 (GPIO UNCLAIMED) function i2c1 group i2c1_b_2 As you can see pins 6,7,12-15 are using hogs. Sure I can see the name of the function but that is just a string albeit helpful. Pins 10,11,16,17 are requested directly from the i2c driver and shows up connected to its device. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] gpio/omap: fix off-mode bug: clear debounce clock enable mask on free/reset
From: Kevin Hilman When a GPIO bank is freed or shutdown, ensure that the banks dbck_enable_mask is cleared also. Otherwise, context restore on subsequent off-mode transition will restore previous value from the shadow copies (bank->context.debounce*) leading to mismatch state between driver state and hardware state. This was discovered when board code was doing gpio_request_one() gpio_set_debounce() gpio_free() which was leaving the GPIO debounce settings in a confused state. If that GPIO bank is subsequently used with off-mode enabled, bogus state would be restored, leaving GPIO debounce enabled which then prevented the CORE powerdomain from transitioning. To fix, ensure that bank->dbck_enable_mask is cleared when the bank is freed/shutdown so debounce state doesn't persist. Special thanks to Grazvydas Ignotas for pointing out a bug in an earlier version that would've disabled debounce on any runtime PM transition. Reported-by: Paul Walmsley Cc: Igor Grinberg Cc: Grazvydas Ignotas Signed-off-by: Kevin Hilman --- v2: only clear mask in free/shutdown, not in runtime PM paths, clarified changelog Applies on v3.7-rc2. drivers/gpio/gpio-omap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index 94cbc84..113b167 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -539,6 +539,7 @@ static void _reset_gpio(struct gpio_bank *bank, int gpio) _set_gpio_irqenable(bank, gpio, 0); _clear_gpio_irqstatus(bank, gpio); _set_gpio_triggering(bank, GPIO_INDEX(bank, gpio), IRQ_TYPE_NONE); + bank->dbck_enable_mask = 0; } /* Use disable_irq_wake() and enable_irq_wake() functions from drivers */ -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi, On Wed, Oct 24, 2012 at 09:18:01AM -0700, Dmitry Torokhov wrote: > On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote: > > On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov > > wrote: > > > > > I have seen just in a few days 3 or 4 drivers having exactly the same > > > change - call to devm_pinctrl_get_select_default(), and I guess I will > > > receive the same patches for the rest of input drivers shortly. > > > This suggests that the operation is done at the wrong level. Do the > > > pin configuration as you parse DT data, the same way you set up i2c > > > devices registers in of_i2c.c, and leave the individual drivers that do > > > not care about specifics alone. > > > > Exactly this can be done with pinctrl hogs. > > > > The problem with that is that it removes the cross-reference > > between the device and it's pinctrl handle (also from the device > > tree). Instead the pinctrl handle gets referenced to the pin controller > > itself. So from a modelling perpective this looks a bit ugly. > > > > So we have two kinds of ugly: > > > > - Sprinke devm_pinctrl_get_select_default() over all drivers > > which makes pinctrl handles properly reference their devices > > > > - Use hogs and loose coupling between pinctrl handles and their > > devices > > > > A third alternative as outlined is to use notifiers and some > > resource core in drivers/base/* > > OK, so with drivers/base/, have you considered doing default pinctrl > selection in bus's probe() methods? Yo would select the default > configuration before starting probing the device and maybe select idle > when probe fails or device is unbound? That would still keep the link > between device object and pinctrl and there less busses than device > drivers out there. it starts to become confusing after a while. I mean, there's a reason why all drivers explictly call pm_runtim_enable(), right ? From a first thought, one could think of just yanking that into bus' probe() as you may suggest, but sometimes the device is already enabled, so we need extra tricks: pm_runtime_set_active(); pm_runtime_enable(); pm_runtime_get(); the same could happen with pinctrl eventually. What if a device needs to do something else (an errata fix as an example) before requesting pinctrl's default state ? -- balbi signature.asc Description: Digital signature
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Wed, Oct 24, 2012 at 6:18 PM, Dmitry Torokhov wrote: > On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote: >> >> A third alternative as outlined is to use notifiers and some >> resource core in drivers/base/* > > OK, so with drivers/base/, have you considered doing default pinctrl > selection in bus's probe() methods? Yo would select the default > configuration before starting probing the device and maybe select idle > when probe fails or device is unbound? That would still keep the link > between device object and pinctrl and there less busses than device > drivers out there. One of our major important busses is the AMBA (PrimeCell) bus. As it happens, this bus actually already do limited resource handling by requesting the silicon block clock for the device, which is necessary to perform auto-probing on the bus level. (You won't be able to read the auto-detect registers unless the silicon is clocked...) When it comes to pin control is turns out in the AMBA drivers we have that we need to do more complex stuff than just select a default configuration. (I assure this is not just for fun, it is saving considerable amounts of power). So the examples I outlined just in the previous mail: drivers/tty/serial/amba-pl011.c drivers/spi/spi-pl022.c drivers/i2c/busses/i2c-nomadik.c Hm it turns out that Wolfram has not yet merged the i2c patch, here it is: http://marc.info/?l=linux-i2c&m=134986995731695&w=2 There are complex state switches involved. It can arguably be centralized, but then it needs to go into drivers/base/[power] or similar, not into a specific piece of bus code, because the needs won't be any different for e.g. a platform device. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Hi, On Wed, Oct 24, 2012 at 09:14:29AM -0700, Dmitry Torokhov wrote: > > > No, I guess we ihave different understanding of what "directly use" means. > > > This particular driver does directly use interrupts: it requests it and > > > performs some actions when interrupt arrives. Same goes for IO memory - > > > it gets requested, then we access it. With pinctrl we do not do anything > > > - we just ask another layer to configure it and that is it. > > > > this is true for almost anything we do: > > > > - we ask another layer to allocate memory for us > > - we ask another layer to call our ISR once the IRQ line is asserted > > - we ask another layer to handle the input events we just received > > - we ask another layer to transfer data through DMA for us > > - we ask another layer to turn regulators on and off. > > But we are _directly_ _using_ all of these. You allocate memory and you > (the driver) stuff data into that memory. You ask for DMA and you take > the DMAed data and work with it. Not so with pinctrl in omap keypad and > other drivers I have seen so far. of course we are. If we don't mux the pins to their correct setting, we can't realy use the HW. So while you don't see any SW control of the requested pins, we're still making use of them. > > and so on. This is just how abstractions work, we group common parts in > > a framework so that users don't need to know the details, but still need > > to tell the framework when to fiddle with those resources. > > > > > I have seen just in a few days 3 or 4 drivers having exactly the same > > > change - call to devm_pinctrl_get_select_default(), and I guess I will > > > receive the same patches for the rest of input drivers shortly. > > > This suggests that the operation is done at the wrong level. Do the > > > pin configuration as you parse DT data, the same way you set up i2c > > > devices registers in of_i2c.c, and leave the individual drivers that do > > > not care about specifics alone. > > > > Makes no sense to hide that from drivers. The idea here is that driver > > should know when it needs its pins to muxed correctly. > > The driver also needs memory controller to be initialized, gpio chip be > ready and registered, DMA subsystem ready, input core reade, etc, etc, > etc. You however do not have every driver explicitly initialize any of > that; you expect certain working environment to be already operable. The > driver does manage resources it controls, it has ultimate knowledge > about, pin configuration is normally is not it. We just need to know > that we wired/muxed properly, otherwise we won't work. So please let > parent layers deal with it. > > > 95% of the time > > it will be done during probe() but then again, so what ? > > > > doing that when parsing DT, or on bus notifiers is just plain wrong. > > Drivers should be required to handle all of their resources. > > All of _their_ resources, exactly. They do not own nor control pins so > they should not be bothered with them either. Look, when you see that except that they *own* the pins. Now that the muxer has been setup properly, this particular IP owns the pins. > potentially _every_ driver in the system needs to set up the same object > that it doe snot use otherwise you should realize that individual driver > is not the proper place to do that. fair enough, but IMHO, we're not there yet. We can't make that claim yet. Besides, we don't know what's the default pin state in a system. It might be that certain pins start out in a way which consumes less power due to the internal construction of the SoC. If we set pins up before driver probes, and probe fails or the driver is never really used, then we could be falling into a situation where we're wasting power. Granted, you can undo everything you did before, but I guess keeping track of everything we setup before probe() just to remove a couple of lines from drivers is wrong. > > > > That's why it is named "get_select_default" and not "get" only. > > > > This API ensure that the pin will be set to the default state, and this > > > > is all we need to do during the probe. > > > > > > Why during the probe and not by default? Realistically, the driver will > > > be loaded as long as there is a matching device and pins will need to be > > > configured. > > > > likewise memory will be allocated when matching happens, IRQs will be > > allocated, regulators will be turned on. So why don't we do all that by > > default ? Because it is wrong. > > No, because we do not know how. The generic layer does not know the ISR > to install, how much memory to allocate, etc. Having regulator turned on > before getting to probe might not be a bad idea. what if your driver never probes ? Will you really leave regulators on consuming extra, valuable power ? > > > > There is no point to change the mux if the driver is not probed, because > > > > potentially the pin can be use be another driver. > > > > > > What other driver would use it? W
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Wed, Oct 24, 2012 at 6:14 PM, Dmitry Torokhov wrote: > On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote: >> - we ask another layer to allocate memory for us >> - we ask another layer to call our ISR once the IRQ line is asserted >> - we ask another layer to handle the input events we just received >> - we ask another layer to transfer data through DMA for us >> - we ask another layer to turn regulators on and off. > > But we are _directly_ _using_ all of these. You allocate memory and you > (the driver) stuff data into that memory. You ask for DMA and you take > the DMAed data and work with it. Not so with pinctrl in omap keypad and > other drivers I have seen so far. Consult: drivers/tty/serial/amba-pl011.c drivers/spi/spi-pl022.c drivers/i2c/busses/i2c-nomadik.c for more complex pinctrl use cases. These are my dogfood drivers ... Most of these will request more than one state and switch the driver between these different states at runtime, in these examples for power saving there are states named "default", "sleep" and in the I2C driver also "idle". These examples are more typical to how the ux500 platform will look, also the SKE input driver will move the devise to sleep/default states but we need to merge PM code before we can do that. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 20/20] OMAPDSS: split hdmi muxing function
* Tomi Valkeinen [121024 02:32]: > Split the omap4_hdmi_mux_pads() function into two parts, one handles the > tpd12s015 gpio muxing, the other handles the hdmi pins. > > This is clearer, as hdmi and tpd12s015 are separate devices, and it also > allows us to mux those separately with DT. > > Signed-off-by: Tomi Valkeinen > Cc: Ricardo Neri Looks OK to me to merge with the rest of the DSS patches: Acked-by: Tony Lindgren -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP NAND driver issue with subpage reads
* Juha Kuikka [121023 13:40]:
> Hi,
>
> There seems to be an issue in the omap nand driver
> (drivers/mtd/nand/omap2.c) concerning sub-page reads (visible when
> using 16bit LP NAND, SOFT_ECC and UBI).
>
> Problem is caused by the omap_read_buf_pref() function using 32bit
> reads from the pre-fetch engine. It takes care of the mis-aligned
> length but not a mis-aligned buffer pointer. Combined with how the
> nand_read_subpage() function aligns the pointer and length to NAND
> width (8 or 16 bits) this can lead to situation where the handling of
> the mis-aligned length in omap_read_buf_pref() causes the pointer to
> not be aligned to 32bits and the data gets corrupted in the read. This
> of course leds to ECC issues.
>
> The way I see is there are several ways to fix this:
>
> 1. Change nand_read_subpage() to be more strict about alignment
> 2. Change omap_read_buf_pref() to handle any reads (len % 4) || (buf %
> 4) with omap_read_bufX() completely
> 3. Change omap_read_buf_pref() to use ioread16_rep() since buffer and
> length are already aligned for us.
>
> I'm leaning towards #2 because, assuming that the nand driver cannot
> make assumptions of alignment, we need to be able to handle them all
> anyway. The common case of reading big chunks of page data would still
> be fast (since reads are always sub-page aligned) but the special case
> of reading small OOB chunks would be handled gracefully.
>
> Something like this:
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 5c8978e..8a929cf 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -334,13 +334,12 @@ static void omap_read_buf_pref(struct mtd_info
> *mtd, u_char *buf, int len)
> u32 *p = (u32 *)buf;
>
> /* take care of subpage reads */
> - if (len % 4) {
> + if (len % 4 || (unsigned long) buf % 4) {
> if (info->nand.options & NAND_BUSWIDTH_16)
> omap_read_buf16(mtd, buf, len % 4);
> else
> omap_read_buf8(mtd, buf, len % 4);
> - p = (u32 *) (buf + len % 4);
> - len -= len % 4;
> + return;
> }
>
> /* configure and start prefetch transfer */
>
> Comments?
Seems OK to me, but please cc the MTD list as this is more in the
MTD driver area.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Wed, Oct 24, 2012 at 02:54:23PM +0200, Linus Walleij wrote: > On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov > wrote: > > > I have seen just in a few days 3 or 4 drivers having exactly the same > > change - call to devm_pinctrl_get_select_default(), and I guess I will > > receive the same patches for the rest of input drivers shortly. > > This suggests that the operation is done at the wrong level. Do the > > pin configuration as you parse DT data, the same way you set up i2c > > devices registers in of_i2c.c, and leave the individual drivers that do > > not care about specifics alone. > > Exactly this can be done with pinctrl hogs. > > The problem with that is that it removes the cross-reference > between the device and it's pinctrl handle (also from the device > tree). Instead the pinctrl handle gets referenced to the pin controller > itself. So from a modelling perpective this looks a bit ugly. > > So we have two kinds of ugly: > > - Sprinke devm_pinctrl_get_select_default() over all drivers > which makes pinctrl handles properly reference their devices > > - Use hogs and loose coupling between pinctrl handles and their > devices > > A third alternative as outlined is to use notifiers and some > resource core in drivers/base/* OK, so with drivers/base/, have you considered doing default pinctrl selection in bus's probe() methods? Yo would select the default configuration before starting probing the device and maybe select idle when probe fails or device is unbound? That would still keep the link between device object and pinctrl and there less busses than device drivers out there. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Wed, Oct 24, 2012 at 11:37:04AM +0300, Felipe Balbi wrote: > Hi, > > On Tue, Oct 23, 2012 at 01:02:49PM -0700, Dmitry Torokhov wrote: > > On Tue, Oct 23, 2012 at 11:18:12AM +0200, Benoit Cousson wrote: > > > Hi Dimitry, > > > > > > On 10/22/2012 05:50 PM, Dmitry Torokhov wrote: > > > > Hi Sourav, > > > > > > > > On Mon, Oct 22, 2012 at 06:43:00PM +0530, Sourav Poddar wrote: > > > >> Adapt keypad to use pinctrl framework. > > > >> > > > >> Tested on omap4430 sdp with 3.7-rc1 kernel. > > > > > > > > I do not see anything in the driver that would directly use pinctrl. Is > > > > there a better place to select default pin configuration; maybe when > > > > instantiating platform device? > > > > > > Why? > > > The devm_pinctrl_get_select_default is using the pinctrl. > > > > No, I guess we ihave different understanding of what "directly use" means. > > This particular driver does directly use interrupts: it requests it and > > performs some actions when interrupt arrives. Same goes for IO memory - > > it gets requested, then we access it. With pinctrl we do not do anything > > - we just ask another layer to configure it and that is it. > > this is true for almost anything we do: > > - we ask another layer to allocate memory for us > - we ask another layer to call our ISR once the IRQ line is asserted > - we ask another layer to handle the input events we just received > - we ask another layer to transfer data through DMA for us > - we ask another layer to turn regulators on and off. But we are _directly_ _using_ all of these. You allocate memory and you (the driver) stuff data into that memory. You ask for DMA and you take the DMAed data and work with it. Not so with pinctrl in omap keypad and other drivers I have seen so far. > > and so on. This is just how abstractions work, we group common parts in > a framework so that users don't need to know the details, but still need > to tell the framework when to fiddle with those resources. > > > I have seen just in a few days 3 or 4 drivers having exactly the same > > change - call to devm_pinctrl_get_select_default(), and I guess I will > > receive the same patches for the rest of input drivers shortly. > > This suggests that the operation is done at the wrong level. Do the > > pin configuration as you parse DT data, the same way you set up i2c > > devices registers in of_i2c.c, and leave the individual drivers that do > > not care about specifics alone. > > Makes no sense to hide that from drivers. The idea here is that driver > should know when it needs its pins to muxed correctly. The driver also needs memory controller to be initialized, gpio chip be ready and registered, DMA subsystem ready, input core reade, etc, etc, etc. You however do not have every driver explicitly initialize any of that; you expect certain working environment to be already operable. The driver does manage resources it controls, it has ultimate knowledge about, pin configuration is normally is not it. We just need to know that we wired/muxed properly, otherwise we won't work. So please let parent layers deal with it. > 95% of the time > it will be done during probe() but then again, so what ? > > doing that when parsing DT, or on bus notifiers is just plain wrong. > Drivers should be required to handle all of their resources. All of _their_ resources, exactly. They do not own nor control pins so they should not be bothered with them either. Look, when you see that potentially _every_ driver in the system needs to set up the same object that it doe snot use otherwise you should realize that individual driver is not the proper place to do that. > > > > That's why it is named "get_select_default" and not "get" only. > > > This API ensure that the pin will be set to the default state, and this > > > is all we need to do during the probe. > > > > Why during the probe and not by default? Realistically, the driver will > > be loaded as long as there is a matching device and pins will need to be > > configured. > > likewise memory will be allocated when matching happens, IRQs will be > allocated, regulators will be turned on. So why don't we do all that by > default ? Because it is wrong. No, because we do not know how. The generic layer does not know the ISR to install, how much memory to allocate, etc. Having regulator turned on before getting to probe might not be a bad idea. > > > > There is no point to change the mux if the driver is not probed, because > > > potentially the pin can be use be another driver. > > > > What other driver would use it? Who would chose what driver to load? > > Well, you _do_ know that on a SoC we have a limited amount of pins > right ? > > Considering the amont of features which are packed inside a single die, > it's not farfetched to assume we will have a lot less pins then we > actually need, so we need muxers behind each pin in order to choose > which functionality we want. > > If it happens that keypad's pins are shared with anot
Re: Beagleboard xM - play video file : BUG: scheduling while atomic: queue1:src/92/0x0000008e , then kernel panic
On Wed, Oct 24, 2012 at 5:49 PM, Selso Liberado wrote: > I wished that someone agreed to mail him about this. > Is the mailing list your talking about is located with this url ? > http://linux.omap.com/mailman/listinfo Yes, they are in CC now. > I did also work with the linux-omap tree repo, and may repeat the test with > this one. It should work with a vanilla kernel. I think you might have better luck with older kernels, 3.2, or maybe even 3.0. I don't recall the last one I tried, but it was working fine. Cheers. -- Felipe Contreras -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] ARM: dts: OMAP: Add timer nodes
Hi Jon,
On 10/19/2012 04:59 PM, Jon Hunter wrote:
> Add the 12 GP timers nodes present in OMAP2.
> Add the 12 GP timers nodes present in OMAP3.
> Add the 11 GP timers nodes present in OMAP4.
> Add the 7 GP timers nodes present in AM33xx.
>
> Add documentation for timer properties specific to OMAP.
>
> Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have
> modified
> Vaibhav's original nodes adding information on which timers support a PWM
> output.
>
> Cc: Benoit Cousson
> Signed-off-by: Jon Hunter
I updated the patch to remove the interrupt-parent from the DTS nodes and the
documentation, as discussed on the list in the context of OMAP5 DTS for GPIO.
If you are OK with that version, I'll push it to Tony along with the others DTS
patches.
Regards,
Benoit
---
>From 531cc8142ecd6da7929628772c4035dcf7996fef Mon Sep 17 00:00:00 2001
From: Jon Hunter
Date: Fri, 19 Oct 2012 09:59:00 -0500
Subject: [PATCH] ARM: dts: OMAP: Add timer nodes
Add the 12 GP timers nodes present in OMAP2.
Add the 12 GP timers nodes present in OMAP3.
Add the 11 GP timers nodes present in OMAP4.
Add the 7 GP timers nodes present in AM33xx.
Add documentation for timer properties specific to OMAP.
Thanks to Vaibhav Hiremath for creating the AM33xx timer nodes. I have modified
Vaibhav's original nodes adding information on which timers support a PWM
output.
Signed-off-by: Jon Hunter
[b-cous...@ti.com: Remove the interrupt-parent from nodes]
Signed-off-by: Benoit Cousson
---
.../devicetree/bindings/arm/omap/timer.txt | 31 +++
arch/arm/boot/dts/am33xx.dtsi | 54 +++
arch/arm/boot/dts/omap2.dtsi | 85 +
arch/arm/boot/dts/omap2420.dtsi|8 ++
arch/arm/boot/dts/omap2430.dtsi|8 ++
arch/arm/boot/dts/omap3.dtsi | 95
arch/arm/boot/dts/omap4.dtsi | 86 ++
7 files changed, 367 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt
b/Documentation/devicetree/bindings/arm/omap/timer.txt
new file mode 100644
index 000..b073d89
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
@@ -0,0 +1,31 @@
+OMAP Timer bindings
+
+Required properties:
+- compatible: Must be "ti,omap2-timer" for OMAP2+ controllers.
+- reg: Contains timer register address range (base address and
+ length).
+- interrupts: Contains the interrupt information for the timer. The
+ format is being dependent on which interrupt controller
+ the OMAP device uses.
+- ti,hwmods: Name of the hwmod associated to the timer, "timer",
+ where is the instance number of the timer from the
+ HW spec.
+
+Optional properties:
+- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
+- ti,timer-dsp:Indicates the timer can interrupt the on-chip
DSP in
+ addition to the ARM CPU.
+- ti,timer-pwm:Indicates the timer can generate a PWM output.
+- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
+ and therefore cannot be used by the kernel.
+
+Example:
+
+timer12: timer@48304000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48304000 0xfff>;
+ interrupts = <95>;
+ ti,hwmods = "timer12"
+ ti,timer-alwon;
+ ti,timer-secure;
+};
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 4709269..7522e16 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -237,5 +237,59 @@
interrupts = <55>;
status = "disabled";
};
+
+ timer1: timer@44e31000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x44e31000 0x1000>;
+ interrupts = <67>;
+ ti,hwmods = "timer1";
+ ti,timer-alwon;
+ };
+
+ timer2: timer@4804 {
+ compatible = "ti,omap2-timer";
+ reg = <0x4804 0x1000>;
+ interrupts = <68>;
+ ti,hwmods = "timer2";
+ };
+
+ timer3: timer@48042000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48042000 0x1000>;
+ interrupts = <69>;
+ ti,hwmods = "timer3";
+ };
+
+ timer4: timer@48044000 {
+ compatible = "ti,omap2-timer";
+ reg = <0x48044000 0x1000>;
+ interrupts = <92>;
+
Re: Beagleboard xM - play video file : BUG: scheduling while atomic: queue1:src/92/0x0000008e , then kernel panic
Hi, Selso, hopefully you don't mind, but I'll forward this to the linux-omap mailing list, as this seems to be an interesting kernel problem in tidspbridge. Omar, any ideas? On Wed, Oct 24, 2012 at 5:24 PM, Selso Liberado wrote: > Hi ! > > So I did have the best result with the beagleboard kernel community on 3.6. > I'am a planning to test their older kernel (ie 3.0). > Attached is a captured video file of a playback to see what is happenning on > the screen. > > A the end of the playback I always get a kernel panic event with TI samples. > > Got EOS from element "pipeline0". > > Execution ended after 100096570255 ns. > > Setting pipeline to PAUSED ... > > Setting pipeline to READY ... > > Setting pipeline to NULL ... > > Freeing pipeline ... > > [ 503.568176] Kernel panic - not syncing: Aiee, killing interrupt handler! > > [ 503.581512] [] (unwind_backtrace+0x0/0xe0) from [] > (panic+0x84/0x1e0) > > [ 503.596252] [] (panic+0x84/0x1e0) from [] > (do_exit+0x9c/0x7d0) > > [ 503.610412] [] (do_exit+0x9c/0x7d0) from [] > (do_group_exit+0xa8/0xd4) > > [ 503.625274] [] (do_group_exit+0xa8/0xd4) from [] > (get_signal_to_deliver+0x5ac/0x624) > > [ 503.641601] [] (get_signal_to_deliver+0x5ac/0x624) from > [] (do_signal+0x88/0x450) > > [ 503.657775] [] (do_signal+0x88/0x450) from [] > (do_work_pending+0x40/0xa0) > > [ 503.673217] [] (do_work_pending+0x40/0xa0) from [] > (work_pending+0xc/0x20) > > > If I don't disable kernel prink to the minimum I get these errors looping on > playback : > [ 143.113586] BUG: scheduling while atomic: queue0:src/88/0x008e > [ 143.126251] Modules linked in: tidspbridge(C) mailbox_mach mailbox > [ 143.138916] [] (unwind_backtrace+0x0/0xe0) from [] > (__schedule_bug+0x48/0x5c) > [ 143.154449] [] (__schedule_bug+0x48/0x5c) from [] > (__schedule+0x60/0x798) > [ 143.169616] [] (__schedule+0x60/0x798) from [] > (do_work_pending+0x18/0xa0) > [ 143.184936] [] (do_work_pending+0x18/0xa0) from [] > (work_pending+0xc/0x20) > [ 143.200561] BUG: scheduling while atomic: queue0:src/88/0x008e > [ 143.213409] Modules linked in: tidspbridge(C) mailbox_mach mailbox > [ 143.226470] [] (unwind_backtrace+0x0/0xe0) from [] > (__schedule_bug+0x48/0x5c) > [ 143.242401] [] (__schedule_bug+0x48/0x5c) from [] > (__schedule+0x60/0x798) > [ 143.257995] [] (__schedule+0x60/0x798) from [] > (do_work_pending+0x18/0xa0) > [ 143.273742] [] (do_work_pending+0x18/0xa0) from [] > (work_pending+0xc/0x20) > [ 143.290374] BUG: scheduling while atomic: queue0:src/88/0x011b > > > > Here are the cmds for loading dsp and initializing gstreamer env : > modprobe mailbox_mach > sleep 1 > modprobe tidspbridge base_img=/lib/dsp/baseimage.dof dsp_test_sleepstate=1 > shm_size=0x50 > > Here is the config for tidspbrige driver : > CONFIG_TIDSPBRIDGE=m > CONFIG_TIDSPBRIDGE_MEMPOOL_SIZE=0x60 > CONFIG_TIDSPBRIDGE_RECOVERY=y > CONFIG_TIDSPBRIDGE_CACHE_LINE_CHECK=y > # CONFIG_TIDSPBRIDGE_NTFY_PWRERR is not set > # CONFIG_TIDSPBRIDGE_BACKTRACE is not set > > > Notice that even with the dvsdk from ti (old kernel) I manage to have by > chance the "scheduling while atomic" > > Is there any way to trace the bug ? I can't event say where it is happening > (gst plugins, glib, gstreamer plugins, tidspbridge) ! > Is there another way to test video decode ? > > I also tested another pipeline with quite the same result : > root@maia:~# gst-launch -v filesrc > location=/home/mntfat/video_720x400_avc1_low_ > profile_noaudio.mp4 ! qtdemux ! queue ! dspvdec ! omapfbsink > Setting pipeline to PAUSED ... > Pipeline is PREROLLING ... > /GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = video/x-h264, > stream-format=(string)avc, alignment=(string)au, level=(string)3, > profile=(string)constrained-baseline, > codec_data=(buffer)0142c01effe100186742c01e9a7201686760220300520fa51e2c5c9001000468ce32c8, > width=(int)720, height=(int)400, framerate=(fraction)143/6, > pixel-aspect-ratio=(fraction)1/1 > /GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps = video/x-h264, > stream-format=(string)avc, alignment=(string)au, level=(string)3, > profile=(string)constrained-baseline, > codec_data=(buffer)0142c01effe100186742c01e9a7201686760220300520fa51e2c5c9001000468ce32c8, > width=(int)720, height=(int)400, framerate=(fraction)143/6, > pixel-aspect-ratio=(fraction)1/1 > /GstPipeline:pipeline0/GstDspVDec:dspvdec0.GstPad:sink: caps = video/x-h264, > stream-format=(string)avc, alignment=(string)au, level=(string)3, > profile=(string)constrained-baseline, > codec_data=(buffer)0142c01effe100186742c01e9a7201686760220300520fa51e2c5c9001000468ce32c8, > width=(int)720, height=(int)400, framerate=(fraction)143/6, > pixel-aspect-ratio=(fraction)1/1 > > (gst-launch-0.10:90): GStreamer-CRITICAL **: gst_mini_object_unref: > assertion `GST_IS_MINI_OBJECT (mini_object)' failed > /GstPipeline:pipeline0/GstDspVDec:dspvdec0.GstPad:sink: caps = video/x-h264, > stream-format=(string)avc, alignment=(string)au, level=(string)3
[PATCH] ARM: dts: OMAP: Rename pandaES and var_som for consistency
Rename the files to have consistent names across OMAP boards.
Update the Makefile to use the new names.
Signed-off-by: Benoit Cousson
Cc: Uri Yosef
---
arch/arm/boot/dts/Makefile |4 ++--
.../dts/{omap4-pandaES.dts => omap4-panda-es.dts} |0
.../dts/{omap4-var_som.dts => omap4-var-som.dts} |0
3 files changed, 2 insertions(+), 2 deletions(-)
rename arch/arm/boot/dts/{omap4-pandaES.dts => omap4-panda-es.dts} (100%)
rename arch/arm/boot/dts/{omap4-var_som.dts => omap4-var-som.dts} (100%)
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e69c921..634bd42 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -68,8 +68,8 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
omap3-evm.dtb \
omap3-tobi.dtb \
omap4-panda.dtb \
- omap4-pandaES.dtb \
- omap4-var_som.dtb \
+ omap4-panda-es.dtb \
+ omap4-var-som.dtb \
omap4-sdp.dtb \
omap5-evm.dtb \
am335x-evm.dtb \
diff --git a/arch/arm/boot/dts/omap4-pandaES.dts
b/arch/arm/boot/dts/omap4-panda-es.dts
similarity index 100%
rename from arch/arm/boot/dts/omap4-pandaES.dts
rename to arch/arm/boot/dts/omap4-panda-es.dts
diff --git a/arch/arm/boot/dts/omap4-var_som.dts
b/arch/arm/boot/dts/omap4-var-som.dts
similarity index 100%
rename from arch/arm/boot/dts/omap4-var_som.dts
rename to arch/arm/boot/dts/omap4-var-som.dts
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: PMU: fix runtime PM enable
On 10/24/2012 09:32 AM, Will Deacon wrote: > On Wed, Oct 24, 2012 at 03:16:43PM +0100, Jon Hunter wrote: >> Hi Will, >> >> On 10/24/2012 04:31 AM, Will Deacon wrote: >>> Can we not just use the presence of the resume/suspend function pointers to >>> indicate whether we should enable runtime pm or not? i.e. if they're not >>> NULL, then enable the thing? >> >> I wondered if you would ask that :-) >> >> Unfortunately, we can't. For example, OMAP3430 and OMAP4460 both require >> runtime_pm to be enabled to turn on the debug sub-system in OMAP for PMU >> to work. However, neither of these devices are using the suspend/resume >> callbacks because the HWMOD framework is doing this for us behind the >> scenes. >> >> So then you ask, why do we need the resume/suspend callbacks, well we >> will need them for OMAP4430 where in addition to turning on the debug >> sub-system we need to configure the CTI module. Therefore, I had to add >> another plat data variable. > > Hmmm, now I start to wonder whether your original idea of having separate > callbacks for enable/disable irq and resume/suspend doesn't make more sense. > Then the CTI magic can go in the irq management code and be totally separate > to the PM stuff. > > What do you reckon? The resume/suspend calls really replaced the enable/disable irq callbacks. That still seems like a good approach given that we need runtime PM for OMAP and PMU. The problem is going to be with device-tree. When booting with device-tree we will not call the current OMAP specific code that is creating the PMU device and calling pm_runtime_enable(). So calling pm_runtime_enable() needs to be done somewhere in the PERF driver and that's the real problem here. >> By the way, I did add a comment in the above changelog about this. See >> the last paragraph, not sure if this is 100% clear. > > Sorry, I missed that this morning. > >> One alternative I had thought about was always calling >> pm_runtime_enable() on registering the PMU device and avoid having a >> use_runtime_pm variable. For ARM platforms that don't use runtime PM the >> pm_runtime_enable() function does nothing. However, I was more concerned >> about adding unnecessary overhead for ARM platforms that are using >> runtime PM but don't need runtime PM for PMU. I don't see any side >> affects on our OMAP2 platform that does not need runtime PM for PMU. >> However, was not sure what is best here. > > Nah, we should be able to fix this in the platdata, I'd just rather have > function pointers instead of state variables in there. Well, we could pass a pointer to pm_runtime_enable() function in the platdata. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/8] i2c: omap: fix error checking
Hi
On 10/22/2012 11:46 AM, Felipe Balbi wrote:
> It's impossible to have Arbitration Lost,
> Read Overflow, and Tranmist Underflow all
> asserted at the same time.
>
> Those error conditions are mutually exclusive
> so what the code should be doing, instead, is
> check each error flag separataly.
>
> Signed-off-by: Felipe Balbi
> ---
> drivers/i2c/busses/i2c-omap.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
> index bea0277..e0eab38 100644
> --- a/drivers/i2c/busses/i2c-omap.c
> +++ b/drivers/i2c/busses/i2c-omap.c
> @@ -587,9 +587,9 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
> goto err_i2c_init;
> }
>
> - /* We have an error */
> - if (dev->cmd_err & (OMAP_I2C_STAT_AL | OMAP_I2C_STAT_ROVR |
> - OMAP_I2C_STAT_XUDF)) {
> + if ((dev->cmd_err & OMAP_I2C_STAT_AL)
> + || (dev->cmd_err & OMAP_I2C_STAT_ROVR)
> + || (dev->cmd_err & OMAP_I2C_STAT_XUDF)) {
Sorry, what is the difference? I didn't understand the optimisation and why now
is more clear. Can you just add a comment?
Michael
> ret = -EIO;
> goto err_i2c_init;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
On Wednesday 24 October 2012 07:49 PM, Kevin Hilman wrote: Grazvydas Ignotas writes: On Tue, Oct 23, 2012 at 9:09 PM, Kevin Hilman wrote: From: Kevin Hilman When debounce clocks are disabled, ensure that the banks dbck_enable_mask is cleared also. Otherwise, context restore on subsequent off-mode transition will restore previous value from the shadow copies (bank->context.debounce*) leading to mismatch state between driver state and hardware state. This doesn't look right to me, aren't you effectively disabling debounce forever here? _gpio_dbck_disable is called from omap_gpio_runtime_suspend() and nothing will ever restore dbck_enable_mask back to what it was set by _set_gpio_debounce and debounce functionality is lost. Yes, you're right. Good catch. I need a fix that's more targetted to the free/reset path. Right. Just clearing the debounce mask in omap_gpio_free() should do the trick. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: PMU: fix runtime PM enable
On Wed, Oct 24, 2012 at 03:16:43PM +0100, Jon Hunter wrote: > Hi Will, > > On 10/24/2012 04:31 AM, Will Deacon wrote: > > Can we not just use the presence of the resume/suspend function pointers to > > indicate whether we should enable runtime pm or not? i.e. if they're not > > NULL, then enable the thing? > > I wondered if you would ask that :-) > > Unfortunately, we can't. For example, OMAP3430 and OMAP4460 both require > runtime_pm to be enabled to turn on the debug sub-system in OMAP for PMU > to work. However, neither of these devices are using the suspend/resume > callbacks because the HWMOD framework is doing this for us behind the > scenes. > > So then you ask, why do we need the resume/suspend callbacks, well we > will need them for OMAP4430 where in addition to turning on the debug > sub-system we need to configure the CTI module. Therefore, I had to add > another plat data variable. Hmmm, now I start to wonder whether your original idea of having separate callbacks for enable/disable irq and resume/suspend doesn't make more sense. Then the CTI magic can go in the irq management code and be totally separate to the PM stuff. What do you reckon? > By the way, I did add a comment in the above changelog about this. See > the last paragraph, not sure if this is 100% clear. Sorry, I missed that this morning. > One alternative I had thought about was always calling > pm_runtime_enable() on registering the PMU device and avoid having a > use_runtime_pm variable. For ARM platforms that don't use runtime PM the > pm_runtime_enable() function does nothing. However, I was more concerned > about adding unnecessary overhead for ARM platforms that are using > runtime PM but don't need runtime PM for PMU. I don't see any side > affects on our OMAP2 platform that does not need runtime PM for PMU. > However, was not sure what is best here. Nah, we should be able to fix this in the platdata, I'd just rather have function pointers instead of state variables in there. Will -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
Grazvydas Ignotas writes: > On Tue, Oct 23, 2012 at 9:09 PM, Kevin Hilman > wrote: >> From: Kevin Hilman >> >> When debounce clocks are disabled, ensure that the banks >> dbck_enable_mask is cleared also. Otherwise, context restore on >> subsequent off-mode transition will restore previous value from the >> shadow copies (bank->context.debounce*) leading to mismatch state >> between driver state and hardware state. > > This doesn't look right to me, aren't you effectively disabling > debounce forever here? _gpio_dbck_disable is called from > omap_gpio_runtime_suspend() and nothing will ever restore > dbck_enable_mask back to what it was set by _set_gpio_debounce and > debounce functionality is lost. Yes, you're right. Good catch. I need a fix that's more targetted to the free/reset path. Linus, please revert if it's not too late, and I'll come up with a more targetted fix. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: PMU: fix runtime PM enable
Hi Will,
On 10/24/2012 04:31 AM, Will Deacon wrote:
> Hi Jon,
>
> On Tue, Oct 23, 2012 at 09:31:08PM +0100, Jon Hunter wrote:
>> Commit 7be2958 (ARM: PMU: Add runtime PM Support) updated the ARM PMU code to
>> use runtime PM which was prototyped and validated on the OMAP devices. In
>> this
>> commit, there is no call pm_runtime_enable() and for OMAP devices
>> pm_runtime_enable() is currently being called from the OMAP PMU code when the
>> PMU device is created. However, there are two problems with this:
>>
>> 1. For any other ARM device wishing to use runtime PM for PMU they will need
>>to call pm_runtime_enable() for runtime PM to work.
>> 2. When booting with device-tree and using device-tree to create the PMU
>>device, pm_runtime_enable() needs to be called from within the ARM PERF
>>driver as we are no longer calling any device specific code to create the
>>device. Hence, PMU does not work on OMAP devices that use the runtime PM
>>callbacks when using device-tree to create the PMU device.
>>
>> Therefore, add a new platform data variable to indicate whether runtime PM is
>> used and if so call pm_runtime_enable() when the PMU device is registered.
>> Note
>> that devices using runtime PM may not use the runtime_resume/suspend
>> callbacks
>> and so we cannot use the presence of these handlers in the platform data to
>> determine whether we should call pm_runtime_enable().
>
> [...]
>
>> diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
>> index a26170d..50a6c3b 100644
>> --- a/arch/arm/include/asm/pmu.h
>> +++ b/arch/arm/include/asm/pmu.h
>> @@ -36,6 +36,7 @@
>> struct arm_pmu_platdata {
>> irqreturn_t (*handle_irq)(int irq, void *dev,
>>irq_handler_t pmu_handler);
>> +bool use_runtime_pm;
>> int (*runtime_resume)(struct device *dev);
>> int (*runtime_suspend)(struct device *dev);
>
> Can we not just use the presence of the resume/suspend function pointers to
> indicate whether we should enable runtime pm or not? i.e. if they're not
> NULL, then enable the thing?
I wondered if you would ask that :-)
Unfortunately, we can't. For example, OMAP3430 and OMAP4460 both require
runtime_pm to be enabled to turn on the debug sub-system in OMAP for PMU
to work. However, neither of these devices are using the suspend/resume
callbacks because the HWMOD framework is doing this for us behind the
scenes.
So then you ask, why do we need the resume/suspend callbacks, well we
will need them for OMAP4430 where in addition to turning on the debug
sub-system we need to configure the CTI module. Therefore, I had to add
another plat data variable.
By the way, I did add a comment in the above changelog about this. See
the last paragraph, not sure if this is 100% clear.
One alternative I had thought about was always calling
pm_runtime_enable() on registering the PMU device and avoid having a
use_runtime_pm variable. For ARM platforms that don't use runtime PM the
pm_runtime_enable() function does nothing. However, I was more concerned
about adding unnecessary overhead for ARM platforms that are using
runtime PM but don't need runtime PM for PMU. I don't see any side
affects on our OMAP2 platform that does not need runtime PM for PMU.
However, was not sure what is best here.
Cheers
Jon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [balbi-usb:i2c-transferred-bytes-on-NACK 7/9] drivers/media/i2c/adv7604.c:406:9: warning: initialization makes integer from pointer without a cast
Hi, On Wed, Oct 24, 2012 at 09:23:23PM +0800, Fengguang Wu wrote: > Sorry, this should really be CCed to the media list. > I'll use the list recommended by get_maintainer.pl in future. Actually, I would suggest only testing the following branches from my tree: dwc3, musb, xceiv, gadget and fixes Those are my final branches, everything else is a temporary branch that I'm using just so I don't loose some patches, or to make it easy for other guys to test patches. cheers -- balbi signature.asc Description: Digital signature
Re: [balbi-usb:i2c-transferred-bytes-on-NACK 7/9] drivers/media/i2c/adv7604.c:406:9: warning: initialization makes integer from pointer without a cast
Hi, On Wed, Oct 24, 2012 at 08:56:15PM +0800, Fengguang Wu wrote: > Hi Shubhrajyoti, > > FYI, there are new compile warnings show up in > > tree: git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git > i2c-transferred-bytes-on-NACK can you *not* test this branch ? Specially since it has nothing to do with USB. I just used kernel.org to backup those patches for me :-) Besides, I already got a report related to this and the fixes are just waiting to be sent to mainline :-) cheers ps: thanks for the great work guys. -- balbi signature.asc Description: Digital signature
Re: [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
On Wed, Oct 24, 2012 at 3:49 PM, Santosh Shilimkar wrote: > On Wednesday 24 October 2012 05:32 PM, Grazvydas Ignotas wrote: >> >> On Tue, Oct 23, 2012 at 9:09 PM, Kevin Hilman >> wrote: >>> >>> From: Kevin Hilman >>> >>> When debounce clocks are disabled, ensure that the banks >>> dbck_enable_mask is cleared also. Otherwise, context restore on >>> subsequent off-mode transition will restore previous value from the >>> shadow copies (bank->context.debounce*) leading to mismatch state >>> between driver state and hardware state. >> >> >> This doesn't look right to me, aren't you effectively disabling >> debounce forever here? _gpio_dbck_disable is called from >> omap_gpio_runtime_suspend() and nothing will ever restore >> dbck_enable_mask back to what it was set by _set_gpio_debounce and >> debounce functionality is lost. >> > As per commit log, the issue seen with request->debounce->free() > sequence and hence on free, debounce state needs to be cleared. > Next gpio_set_debounce() should set the debounce mask right so > the patch seems to be right. > > >>> >>> This was discovered when board code was doing >>> >>>gpio_request_one() >>>gpio_set_debounce() >>>gpio_free() >>> >>> which was leaving the GPIO debounce settings in a confused state. >>> Then, enabling off mode causing bogus state to be restored, leaving >>> GPIO debounce enabled which then prevented the CORE powerdomain from >>> transitioning. >>> > > But there is one more case which might break because of this patch. > As part of idle, we might end up with below without gpio_free() > omap2_gpio_prepare_for_idle() > ->pm_runtime_put_sync_suspend() > -> omap_gpio_runtime_suspend() >->_gpio_dbck_disable() > > And last call will clear the debounce mask state which will lost and > hence the debounce clock won't be enabled on resume. > > I let Kevin comment whether this is the valid case or not. That's exactly what I had in mind - we lose debounce functionality on first runtime suspend. -- Gražvydas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Tue, Oct 23, 2012 at 10:02 PM, Dmitry Torokhov wrote: > I have seen just in a few days 3 or 4 drivers having exactly the same > change - call to devm_pinctrl_get_select_default(), and I guess I will > receive the same patches for the rest of input drivers shortly. > This suggests that the operation is done at the wrong level. Do the > pin configuration as you parse DT data, the same way you set up i2c > devices registers in of_i2c.c, and leave the individual drivers that do > not care about specifics alone. Exactly this can be done with pinctrl hogs. The problem with that is that it removes the cross-reference between the device and it's pinctrl handle (also from the device tree). Instead the pinctrl handle gets referenced to the pin controller itself. So from a modelling perpective this looks a bit ugly. So we have two kinds of ugly: - Sprinke devm_pinctrl_get_select_default() over all drivers which makes pinctrl handles properly reference their devices - Use hogs and loose coupling between pinctrl handles and their devices A third alternative as outlined is to use notifiers and some resource core in drivers/base/* >> That's why it is named "get_select_default" and not "get" only. >> This API ensure that the pin will be set to the default state, and this >> is all we need to do during the probe. > > Why during the probe and not by default? Realistically, the driver will > be loaded as long as there is a matching device and pins will need to be > configured. Hogs will do it by default but will disassociate the pinctrl from its device as described. >> There is no point to change the mux if the driver is not probed, because >> potentially the pin can be use be another driver. > > What other driver would use it? Who would chose what driver to load? I don't know about this specific driver, but for the SKE keypad driver we have a runtime case switching around the pins. We recently patched the pinctrl core for a specific usecase like this, and in that case both drivers are loaded, but one will be disabled at runtime and the other become active. In the ux500, if you need to perform deep debugging on a running system (an ordinary cell phone, say) you can at runtime convert the SD card output into an STM trace port and start monitoring different messages coming out on a MIPI-type bus. So basically it is not an SD card slot anymore, it turns into something else, the silicon core for MMC/SD is decoupled from its pins, and they are re-routed to the STM tracer. And you plug a special piece of hardware into the SD-card slot and it has a USB cord or something collection standard MIPI traces. We have the same for the SKE keypad actually. We can shunt the STM tracing signals out on this as well, you "just" unmount the physical keypad and start using the lines on the PCB as a trace collecting mechanism. Thus we need - at runtime, in systems produced in the the millions, it's not "just for fun" - to recouple pins from one IP block to another and turn it into a totally different thing. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
On Wednesday 24 October 2012 05:32 PM, Grazvydas Ignotas wrote: On Tue, Oct 23, 2012 at 9:09 PM, Kevin Hilman wrote: From: Kevin Hilman When debounce clocks are disabled, ensure that the banks dbck_enable_mask is cleared also. Otherwise, context restore on subsequent off-mode transition will restore previous value from the shadow copies (bank->context.debounce*) leading to mismatch state between driver state and hardware state. This doesn't look right to me, aren't you effectively disabling debounce forever here? _gpio_dbck_disable is called from omap_gpio_runtime_suspend() and nothing will ever restore dbck_enable_mask back to what it was set by _set_gpio_debounce and debounce functionality is lost. As per commit log, the issue seen with request->debounce->free() sequence and hence on free, debounce state needs to be cleared. Next gpio_set_debounce() should set the debounce mask right so the patch seems to be right. This was discovered when board code was doing gpio_request_one() gpio_set_debounce() gpio_free() which was leaving the GPIO debounce settings in a confused state. Then, enabling off mode causing bogus state to be restored, leaving GPIO debounce enabled which then prevented the CORE powerdomain from transitioning. But there is one more case which might break because of this patch. As part of idle, we might end up with below without gpio_free() omap2_gpio_prepare_for_idle() ->pm_runtime_put_sync_suspend() -> omap_gpio_runtime_suspend() ->_gpio_dbck_disable() And last call will clear the debounce mask state which will lost and hence the debounce clock won't be enabled on resume. I let Kevin comment whether this is the valid case or not. Regards Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gpio/omap: fix off-mode bug: clear debounce clock enable mask on disable
On Tue, Oct 23, 2012 at 9:09 PM, Kevin Hilman wrote: > From: Kevin Hilman > > When debounce clocks are disabled, ensure that the banks > dbck_enable_mask is cleared also. Otherwise, context restore on > subsequent off-mode transition will restore previous value from the > shadow copies (bank->context.debounce*) leading to mismatch state > between driver state and hardware state. This doesn't look right to me, aren't you effectively disabling debounce forever here? _gpio_dbck_disable is called from omap_gpio_runtime_suspend() and nothing will ever restore dbck_enable_mask back to what it was set by _set_gpio_debounce and debounce functionality is lost. > > This was discovered when board code was doing > > gpio_request_one() > gpio_set_debounce() > gpio_free() > > which was leaving the GPIO debounce settings in a confused state. > Then, enabling off mode causing bogus state to be restored, leaving > GPIO debounce enabled which then prevented the CORE powerdomain from > transitioning. > > Reported-by: Paul Walmsley > Cc: Igor Grinberg > Signed-off-by: Kevin Hilman > --- > Applies on v3.7-rc2, targetted for v3.7. > > drivers/gpio/gpio-omap.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c > index 94cbc84..dee2856 100644 > --- a/drivers/gpio/gpio-omap.c > +++ b/drivers/gpio/gpio-omap.c > @@ -187,6 +187,7 @@ static inline void _gpio_dbck_disable(struct gpio_bank > *bank) > * to detect events and generate interrupts at least on OMAP3. > */ > __raw_writel(0, bank->base + bank->regs->debounce_en); > + bank->dbck_enable_mask = 0; > > clk_disable(bank->dbck); > bank->dbck_enabled = false; > -- > 1.8.0 > > > ___ > linux-arm-kernel mailing list > linux-arm-ker...@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Gražvydas -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Errors at boot time from OMAP4430SDP (and a whinge about serial stuff)
On Wed, Oct 24, 2012 at 3:54 AM, Tony Lindgren wrote:
> I don't think mach-davinci has wl12xx_board_init() available?
> Maybe leave this out or define also also somewhere for mach-davinci?
Yeah let's leave davinci out for now:
>From 665bcaa7ef0ed385cf1765f2d4503bf84aaf488a Mon Sep 17 00:00:00 2001
From: Ohad Ben-Cohen
Date: Sun, 14 Oct 2012 20:16:01 +0200
Subject: [PATCH] ARM: OMAP: don't print any error when wl12xx isn't
configured
Stop intimidating users with scary wlan error messages in case wl12xx
support wasn't even built.
In addition, when wl12xx_set_platform_data() fails, don't bother
registering wl12xx's fixed regulator device (on the relevant
boards).
While we're at it, extract the wlan init code to a dedicated function to
make (the relevant boards') init code look a bit nicer.
Compile tested only.
Reported-by: Russell King
Signed-off-by: Ohad Ben-Cohen
---
arch/arm/mach-omap2/board-4430sdp.c | 7 +++---
arch/arm/mach-omap2/board-omap3evm.c | 6 ++---
arch/arm/mach-omap2/board-omap3pandora.c | 9 +++-
arch/arm/mach-omap2/board-omap4panda.c | 20 -
arch/arm/mach-omap2/board-zoom-peripherals.c | 15 -
arch/arm/mach-omap2/common-board-devices.c | 33
arch/arm/mach-omap2/common-board-devices.h | 2 ++
7 files changed, 69 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 3669c12..bc48679 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -825,10 +825,11 @@ static void __init omap4_sdp4430_wifi_init(void)
int ret;
omap4_sdp4430_wifi_mux_init();
- omap4_sdp4430_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
- ret = wl12xx_set_platform_data(&omap4_sdp4430_wlan_data);
+
+ ret = wl12xx_board_init(&omap4_sdp4430_wlan_data, GPIO_WIFI_IRQ);
if (ret)
- pr_err("Error setting wl12xx data: %d\n", ret);
+ return;
+
ret = platform_device_register(&omap_vwlan_device);
if (ret)
pr_err("Error registering wl12xx device: %d\n", ret);
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index b9b776b..8e3a075 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -636,10 +636,10 @@ static void __init omap3_evm_wl12xx_init(void)
int ret;
/* WL12xx WLAN Init */
- omap3evm_wlan_data.irq = gpio_to_irq(OMAP3EVM_WLAN_IRQ_GPIO);
- ret = wl12xx_set_platform_data(&omap3evm_wlan_data);
+ ret = wl12xx_board_init(&omap3evm_wlan_data, OMAP3EVM_WLAN_IRQ_GPIO);
if (ret)
- pr_err("error setting wl12xx data: %d\n", ret);
+ return;
+
ret = platform_device_register(&omap3evm_wlan_regulator);
if (ret)
pr_err("error registering wl12xx device: %d\n", ret);
diff --git a/arch/arm/mach-omap2/board-omap3pandora.c
b/arch/arm/mach-omap2/board-omap3pandora.c
index 00a1f4a..bfdc7aa 100644
--- a/arch/arm/mach-omap2/board-omap3pandora.c
+++ b/arch/arm/mach-omap2/board-omap3pandora.c
@@ -543,13 +543,10 @@ static void __init pandora_wl1251_init(void)
if (ret < 0)
goto fail;
- pandora_wl1251_pdata.irq = gpio_to_irq(PANDORA_WIFI_IRQ_GPIO);
- if (pandora_wl1251_pdata.irq < 0)
- goto fail_irq;
-
pandora_wl1251_pdata.use_eeprom = true;
- ret = wl12xx_set_platform_data(&pandora_wl1251_pdata);
- if (ret < 0)
+
+ ret = wl12xx_board_init(&pandora_wl1251_pdata, PANDORA_WIFI_IRQ_GPIO);
+ if (ret)
goto fail_irq;
return;
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index bfcd397..f203cd9 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -486,24 +486,32 @@ static void omap4_panda_init_rev(void)
}
}
+static void __init omap4_panda_wlan_init(void)
+{
+ int ret;
+
+ ret = wl12xx_board_init(&omap_panda_wlan_data, GPIO_WIFI_IRQ);
+ if (ret)
+ return;
+
+ ret = platform_device_register(&omap_vwlan_device);
+ if (ret)
+ pr_err("error registering wl12xx's fixed regulator: %d\n", ret);
+}
+
static void __init omap4_panda_init(void)
{
int package = OMAP_PACKAGE_CBS;
- int ret;
if (omap_rev() == OMAP4430_REV_ES1_0)
package = OMAP_PACKAGE_CBL;
omap4_mux_init(board_mux, NULL, package);
- omap_panda_wlan_data.irq = gpio_to_irq(GPIO_WIFI_IRQ);
- ret = wl12xx_set_platform_data(&omap_panda_wlan_data);
- if (ret)
- pr_err("error setting wl12xx data: %d\n", ret);
+ omap4_panda_wlan_init();
omap4_panda_init_rev();
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
- pla
Re: [PATCH] ARM: dts: OMAP: Move interrupt-parent to the root node to avoid duplication
On 10/24/2012 12:02 PM, Benoit Cousson wrote: > The interrupt-parent attribute does not have to be added in each > node since the DT framework will check for the parent as well to get it. > > Create an interrupt-parent for OMAP2, OMAP3, AM33xx and remove the > attributes from every nodes that were using it. > > Signed-off-by: Benoit Cousson > Cc: Vaibhav Hiremath > Cc: Peter Ujfalusi > Cc: Sebastien Guiriec Thanks Benoit, looks good from my side. Acked-by: Peter Ujfalusi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 0/4] ARM: dts: Update OMAP5 with address space and interrupts
On 10/24/2012 11:27 AM, Sebastien Guiriec wrote: > Hi Benoit, > > On 10/24/2012 11:15 AM, Benoit Cousson wrote: >> Hi Seb, >> >> Sorry, I missed your previous email, your v2 was the right one. >> We do have a single INTC in every OMAP, there is no point to repeat the >> same data hundred times. >> The DTS are already big enough. > > So in such case we should send a series for audio IP interrupt-parent > removal for OMAP3/4/5 dtsi file in order to be coherent. Yes. AM33xx was as well using that in some other IPs. > Do you want me to do it? Thanks, but I've just done the patch, I'll sent it in a couple of minutes. Benoit > >> >> On 10/24/2012 09:07 AM, Sebastien Guiriec wrote: >>> Since kernel 3.7 the DTS data are not overwriten by hwmod data we can >>> add the address space >>> and interrupt line description inside dtsi file for OMAP5. This serie >>> is updating the >>> current OMAP5 IP with missing entry. >>> >>> It has been tested on OMAP5 with 3.7-audio-display feature tree. >>> - MMC is probing and functional >>> - TWL6041 probing (GPIO/I2C) >>> - booting (UART) >>> >>> Update since v1: >>> - Add Ack and review >>> - Fix up commit messages. >>> >>> Update since v2: >>> - Add interrupt-parent. >> >> I will take the previous one to avoid the duplication of attributes. >> >> On top of that I will remove the ones introduce in audio IPs for >> consistency on OMAP3/4/5 platforms. >> >> Regards, >> Benoit >> > -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Revert "serial: omap: fix software flow control"
Hi Greg, On Tue, Oct 16, 2012 at 08:13:59AM -0700, Tony Lindgren wrote: > * Felipe Balbi [121016 07:16]: > > This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6 > > (serial: omap: fix software flow control). > > > > As Russell has pointed out, that commit isn't fixing > > Software Flow Control at all, and it actually makes > > it even more broken. > > > > It was agreed to revert this commit and use Russell's > > latest UART patches instead. > > > > Cc: Russell King > > Signed-off-by: Felipe Balbi > > This seems like the best way to go for the -rc series: > > Acked-by: Tony Lindgren Any chance you can pick this one up for v3.7-rc3 ? cheers -- balbi signature.asc Description: Digital signature
[PATCH] ARM: dts: OMAP: Move interrupt-parent to the root node to avoid duplication
The interrupt-parent attribute does not have to be added in each
node since the DT framework will check for the parent as well to get it.
Create an interrupt-parent for OMAP2, OMAP3, AM33xx and remove the
attributes from every nodes that were using it.
Signed-off-by: Benoit Cousson
Cc: Vaibhav Hiremath
Cc: Peter Ujfalusi
Cc: Sebastien Guiriec
---
This patch was triggered by the thread about Seb's patch [1].
So let's clean the current OMAP/AM stuff right now to be consistent.
The patch applies on top of the for_3.8/dts [2] branch.
Regards,
Benoit
[1] https://lkml.org/lkml/2012/10/24/85
[2] git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
arch/arm/boot/dts/am33xx.dtsi | 17 +
arch/arm/boot/dts/omap2.dtsi|1 +
arch/arm/boot/dts/omap2420.dtsi |2 --
arch/arm/boot/dts/omap2430.dtsi |5 -
arch/arm/boot/dts/omap3.dtsi|6 +-
arch/arm/boot/dts/omap4.dtsi|6 --
arch/arm/boot/dts/omap5.dtsi|5 -
7 files changed, 3 insertions(+), 39 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 64c2efe..4709269 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -12,6 +12,7 @@
/ {
compatible = "ti,am33xx";
+ interrupt-parent = <&intc>;
aliases {
serial0 = &uart1;
@@ -94,7 +95,6 @@
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x44e07000 0x1000>;
- interrupt-parent = <&intc>;
interrupts = <96>;
};
@@ -106,7 +106,6 @@
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x4804c000 0x1000>;
- interrupt-parent = <&intc>;
interrupts = <98>;
};
@@ -118,7 +117,6 @@
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x481ac000 0x1000>;
- interrupt-parent = <&intc>;
interrupts = <32>;
};
@@ -130,7 +128,6 @@
interrupt-controller;
#interrupt-cells = <1>;
reg = <0x481ae000 0x1000>;
- interrupt-parent = <&intc>;
interrupts = <62>;
};
@@ -139,7 +136,6 @@
ti,hwmods = "uart1";
clock-frequency = <4800>;
reg = <0x44e09000 0x2000>;
- interrupt-parent = <&intc>;
interrupts = <72>;
status = "disabled";
};
@@ -149,7 +145,6 @@
ti,hwmods = "uart2";
clock-frequency = <4800>;
reg = <0x48022000 0x2000>;
- interrupt-parent = <&intc>;
interrupts = <73>;
status = "disabled";
};
@@ -159,7 +154,6 @@
ti,hwmods = "uart3";
clock-frequency = <4800>;
reg = <0x48024000 0x2000>;
- interrupt-parent = <&intc>;
interrupts = <74>;
status = "disabled";
};
@@ -169,7 +163,6 @@
ti,hwmods = "uart4";
clock-frequency = <4800>;
reg = <0x481a6000 0x2000>;
- interrupt-parent = <&intc>;
interrupts = <44>;
status = "disabled";
};
@@ -179,7 +172,6 @@
ti,hwmods = "uart5";
clock-frequency = <4800>;
reg = <0x481a8000 0x2000>;
- interrupt-parent = <&intc>;
interrupts = <45>;
status = "disabled";
};
@@ -189,7 +181,6 @@
ti,hwmods = "uart6";
clock-frequency = <4800>;
reg = <0x481aa000 0x2000>;
- interrupt-parent = <&intc>;
interrupts = <46>;
status = "disabled";
};
@@ -200,7 +191,6 @@
#size-cells = <0>;
ti,hwmods = "i2c1";
reg = <0x44e0b000 0x1000>;
- interrupt-parent = <&intc>;
interrupts = <70>;
status = "disabled";
};
@@ -211,7 +201,6 @@
#size-cells = <0>;
ti,hwmods = "i2c2";
reg = <0x4802a000 0x1000>;
- interrupt-parent
Re: [PATCH] ARM: PMU: fix runtime PM enable
Hi Jon,
On Tue, Oct 23, 2012 at 09:31:08PM +0100, Jon Hunter wrote:
> Commit 7be2958 (ARM: PMU: Add runtime PM Support) updated the ARM PMU code to
> use runtime PM which was prototyped and validated on the OMAP devices. In this
> commit, there is no call pm_runtime_enable() and for OMAP devices
> pm_runtime_enable() is currently being called from the OMAP PMU code when the
> PMU device is created. However, there are two problems with this:
>
> 1. For any other ARM device wishing to use runtime PM for PMU they will need
>to call pm_runtime_enable() for runtime PM to work.
> 2. When booting with device-tree and using device-tree to create the PMU
>device, pm_runtime_enable() needs to be called from within the ARM PERF
>driver as we are no longer calling any device specific code to create the
>device. Hence, PMU does not work on OMAP devices that use the runtime PM
>callbacks when using device-tree to create the PMU device.
>
> Therefore, add a new platform data variable to indicate whether runtime PM is
> used and if so call pm_runtime_enable() when the PMU device is registered.
> Note
> that devices using runtime PM may not use the runtime_resume/suspend callbacks
> and so we cannot use the presence of these handlers in the platform data to
> determine whether we should call pm_runtime_enable().
[...]
> diff --git a/arch/arm/include/asm/pmu.h b/arch/arm/include/asm/pmu.h
> index a26170d..50a6c3b 100644
> --- a/arch/arm/include/asm/pmu.h
> +++ b/arch/arm/include/asm/pmu.h
> @@ -36,6 +36,7 @@
> struct arm_pmu_platdata {
> irqreturn_t (*handle_irq)(int irq, void *dev,
> irq_handler_t pmu_handler);
> + bool use_runtime_pm;
> int (*runtime_resume)(struct device *dev);
> int (*runtime_suspend)(struct device *dev);
Can we not just use the presence of the resume/suspend function pointers to
indicate whether we should enable runtime pm or not? i.e. if they're not
NULL, then enable the thing?
Cheers,
Will
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 10/20] OMAPDSS: DISPC: Add IRQ enable/status helpers
DISPC irqs need to be handled from the compat layer and also in the
future by the omapdrm. To make this possible, this patchs adds a set of
helper functions, so that the irqs can be managed without direct
register reads/writes.
The following functions are added, and all the current direct reg
reads/writes are changed to use these.
u32 dispc_read_irqstatus(void);
void dispc_clear_irqstatus(u32 mask);
u32 dispc_read_irqenable(void);
void dispc_write_irqenable(u32 mask);
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc.c | 44 ---
drivers/video/omap2/dss/dss.h |4
2 files changed, 36 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 3fd60ce..d294873 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -497,7 +497,7 @@ static void dispc_restore_context(void)
if (dss_has_feature(FEAT_MGR_LCD3))
RR(CONTROL3);
/* clear spurious SYNC_LOST_DIGIT interrupts */
- dispc_write_reg(DISPC_IRQSTATUS, DISPC_IRQ_SYNC_LOST_DIGIT);
+ dispc_clear_irqstatus(DISPC_IRQ_SYNC_LOST_DIGIT);
/*
* enable last so IRQs won't trigger before
@@ -3627,11 +3627,35 @@ int dispc_mgr_get_clock_div(enum omap_channel channel,
return 0;
}
+u32 dispc_read_irqstatus(void)
+{
+ return dispc_read_reg(DISPC_IRQSTATUS);
+}
+
+void dispc_clear_irqstatus(u32 mask)
+{
+ dispc_write_reg(DISPC_IRQSTATUS, mask);
+}
+
+u32 dispc_read_irqenable(void)
+{
+ return dispc_read_reg(DISPC_IRQENABLE);
+}
+
+void dispc_write_irqenable(u32 mask)
+{
+ u32 old_mask = dispc_read_reg(DISPC_IRQENABLE);
+
+ /* clear the irqstatus for newly enabled irqs */
+ dispc_clear_irqstatus((mask ^ old_mask) & mask);
+
+ dispc_write_reg(DISPC_IRQENABLE, mask);
+}
+
/* dispc.irq_lock has to be locked by the caller */
static void _omap_dispc_set_irqs(void)
{
u32 mask;
- u32 old_mask;
int i;
struct omap_dispc_isr_data *isr_data;
@@ -3646,11 +3670,7 @@ static void _omap_dispc_set_irqs(void)
mask |= isr_data->mask;
}
- old_mask = dispc_read_reg(DISPC_IRQENABLE);
- /* clear the irqstatus for newly enabled irqs */
- dispc_write_reg(DISPC_IRQSTATUS, (mask ^ old_mask) & mask);
-
- dispc_write_reg(DISPC_IRQENABLE, mask);
+ dispc_write_irqenable(mask);
}
int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask)
@@ -3777,8 +3797,8 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
*arg)
spin_lock(&dispc.irq_lock);
- irqstatus = dispc_read_reg(DISPC_IRQSTATUS);
- irqenable = dispc_read_reg(DISPC_IRQENABLE);
+ irqstatus = dispc_read_irqstatus();
+ irqenable = dispc_read_irqenable();
/* IRQ is not for us */
if (!(irqstatus & irqenable)) {
@@ -3797,9 +3817,9 @@ static irqreturn_t omap_dispc_irq_handler(int irq, void
*arg)
/* Ack the interrupt. Do it here before clocks are possibly turned
* off */
- dispc_write_reg(DISPC_IRQSTATUS, irqstatus);
+ dispc_clear_irqstatus(irqstatus);
/* flush posted write */
- dispc_read_reg(DISPC_IRQSTATUS);
+ dispc_read_irqstatus();
/* make a copy and unlock, so that isrs can unregister
* themselves */
@@ -4008,7 +4028,7 @@ static void _omap_dispc_initialize_irq(void)
/* there's SYNC_LOST_DIGIT waiting after enabling the DSS,
* so clear it */
- dispc_write_reg(DISPC_IRQSTATUS, dispc_read_reg(DISPC_IRQSTATUS));
+ dispc_clear_irqstatus(dispc_read_irqstatus());
_omap_dispc_set_irqs();
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index be7678c..8bf9047 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -398,6 +398,10 @@ void dpi_uninit_platform_driver(void) __exit;
int dispc_init_platform_driver(void) __init;
void dispc_uninit_platform_driver(void) __exit;
void dispc_dump_clocks(struct seq_file *s);
+u32 dispc_read_irqstatus(void);
+void dispc_clear_irqstatus(u32 mask);
+u32 dispc_read_irqenable(void);
+void dispc_write_irqenable(u32 mask);
int dispc_runtime_get(void);
void dispc_runtime_put(void);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 13/20] OMAPDSS: HDMI: add 1920x1200 video mode
Add 1920x1200 video mode to hdmi driver's static modelist.
Signed-off-by: Tomi Valkeinen
Cc: Ricardo Neri
---
drivers/video/omap2/dss/hdmi.c |6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index b809490..dfbc1e7 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -295,6 +295,12 @@ static const struct hdmi_config vesa_timings[] = {
false, },
{ 0x55, HDMI_DVI },
},
+ {
+ { 1920, 1200, 154000, 32, 48, 80, 6, 3, 26,
+ OMAPDSS_SIG_ACTIVE_LOW, OMAPDSS_SIG_ACTIVE_HIGH,
+ false, },
+ { 0x44, HDMI_DVI },
+ },
};
static int hdmi_runtime_get(void)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 16/20] OMAPFB: improve mode selection from EDID
The current omapfb code goes over all the modes found from the monitors
EDID data, and searches for a mode that is compatible with the DSS
hardware and has the highest x-res.
While this works ok as such, it proves problematic when using DSI PLL
for pixel clock. Calculating DSI PLL dividers is not the fastest of the
operations, and while doing it for one mode is usually ok, doing it for
20 modes is noticable.
Also, the first mode given in the EDID data should be the native mode of
the monitor, and thus also the best mode, so if that can be used, no
need to look further.
This patch changes the code to use the first mode that is compatible
with the DSS hardware.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/omapfb/omapfb-main.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
b/drivers/video/omap2/omapfb/omapfb-main.c
index fe37039..1017832 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2256,7 +2256,7 @@ static int omapfb_find_best_mode(struct omap_dss_device
*display,
{
struct fb_monspecs *specs;
u8 *edid;
- int r, i, best_xres, best_idx, len;
+ int r, i, best_idx, len;
if (!display->driver->read_edid)
return -ENODEV;
@@ -2272,7 +2272,6 @@ static int omapfb_find_best_mode(struct omap_dss_device
*display,
fb_edid_to_monspecs(edid, specs);
- best_xres = 0;
best_idx = -1;
for (i = 0; i < specs->modedb_len; ++i) {
@@ -2288,16 +2287,20 @@ static int omapfb_find_best_mode(struct omap_dss_device
*display,
if (m->xres == 2880 || m->xres == 1440)
continue;
+ if (m->vmode & FB_VMODE_INTERLACED ||
+ m->vmode & FB_VMODE_DOUBLE)
+ continue;
+
fb_videomode_to_omap_timings(m, display, &t);
r = display->driver->check_timings(display, &t);
- if (r == 0 && best_xres < m->xres) {
- best_xres = m->xres;
+ if (r == 0) {
best_idx = i;
+ break;
}
}
- if (best_xres == 0) {
+ if (best_idx == -1) {
r = -ENOENT;
goto err2;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 20/20] OMAPDSS: split hdmi muxing function
Split the omap4_hdmi_mux_pads() function into two parts, one handles the
tpd12s015 gpio muxing, the other handles the hdmi pins.
This is clearer, as hdmi and tpd12s015 are separate devices, and it also
allows us to mux those separately with DT.
Signed-off-by: Tomi Valkeinen
Cc: Ricardo Neri
---
arch/arm/mach-omap2/display.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 28f5087..282c814e 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -100,17 +100,20 @@ static const struct omap_dss_hwmod_data
omap4_dss_hwmod_data[] __initconst = {
{ "dss_hdmi", "omapdss_hdmi", -1 },
};
-static void __init omap4_hdmi_mux_pads(enum omap_hdmi_flags flags)
+static void __init omap4_tpd12s015_mux_pads(void)
{
- u32 reg;
- u16 control_i2c_1;
-
omap_mux_init_signal("hdmi_cec",
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal("hdmi_ddc_scl",
OMAP_PIN_INPUT_PULLUP);
omap_mux_init_signal("hdmi_ddc_sda",
OMAP_PIN_INPUT_PULLUP);
+}
+
+static void __init omap4_hdmi_mux_pads(enum omap_hdmi_flags flags)
+{
+ u32 reg;
+ u16 control_i2c_1;
/*
* CONTROL_I2C_1: HDMI_DDC_SDA_PULLUPRESX (bit 28) and
@@ -161,8 +164,10 @@ static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
int __init omap_hdmi_init(enum omap_hdmi_flags flags)
{
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
omap4_hdmi_mux_pads(flags);
+ omap4_tpd12s015_mux_pads();
+ }
return 0;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 12/20] OMAPDSS: HDMI: use core power on/off with edid & detect
This patch makes use of the hdmi_power_[on|off]_core() functions added
in the previous patch. The functions are used when reading EDID or
detecting if a monitor is connected.
Signed-off-by: Tomi Valkeinen
Cc: Ricardo Neri
---
drivers/video/omap2/dss/dss.h|2 ++
drivers/video/omap2/dss/hdmi.c | 35 ++
drivers/video/omap2/dss/hdmi_panel.c |8
3 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 8bf9047..2305b80 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -510,6 +510,8 @@ static inline unsigned long hdmi_get_pixel_clock(void)
#endif
int omapdss_hdmi_display_enable(struct omap_dss_device *dssdev);
void omapdss_hdmi_display_disable(struct omap_dss_device *dssdev);
+int omapdss_hdmi_core_enable(struct omap_dss_device *dssdev);
+void omapdss_hdmi_core_disable(struct omap_dss_device *dssdev);
void omapdss_hdmi_display_set_timing(struct omap_dss_device *dssdev,
struct omap_video_timings *timings);
int omapdss_hdmi_display_check_timing(struct omap_dss_device *dssdev,
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index 50d5a10..b809490 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -759,6 +759,41 @@ void omapdss_hdmi_display_disable(struct omap_dss_device
*dssdev)
mutex_unlock(&hdmi.lock);
}
+int omapdss_hdmi_core_enable(struct omap_dss_device *dssdev)
+{
+ int r = 0;
+
+ DSSDBG("ENTER omapdss_hdmi_core_enable\n");
+
+ mutex_lock(&hdmi.lock);
+
+ hdmi.ip_data.hpd_gpio = hdmi.hpd_gpio;
+
+ r = hdmi_power_on_core(dssdev);
+ if (r) {
+ DSSERR("failed to power on device\n");
+ goto err0;
+ }
+
+ mutex_unlock(&hdmi.lock);
+ return 0;
+
+err0:
+ mutex_unlock(&hdmi.lock);
+ return r;
+}
+
+void omapdss_hdmi_core_disable(struct omap_dss_device *dssdev)
+{
+ DSSDBG("Enter omapdss_hdmi_core_disable\n");
+
+ mutex_lock(&hdmi.lock);
+
+ hdmi_power_off_core(dssdev);
+
+ mutex_unlock(&hdmi.lock);
+}
+
static int hdmi_get_clocks(struct platform_device *pdev)
{
struct clk *clk;
diff --git a/drivers/video/omap2/dss/hdmi_panel.c
b/drivers/video/omap2/dss/hdmi_panel.c
index 3f9a4b9..a385b69 100644
--- a/drivers/video/omap2/dss/hdmi_panel.c
+++ b/drivers/video/omap2/dss/hdmi_panel.c
@@ -334,7 +334,7 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
u8 *buf, int len)
need_enable = dssdev->state == OMAP_DSS_DISPLAY_DISABLED;
if (need_enable) {
- r = omapdss_hdmi_display_enable(dssdev);
+ r = omapdss_hdmi_core_enable(dssdev);
if (r)
goto err;
}
@@ -342,7 +342,7 @@ static int hdmi_read_edid(struct omap_dss_device *dssdev,
u8 *buf, int len)
r = omapdss_hdmi_read_edid(buf, len);
if (need_enable)
- omapdss_hdmi_display_disable(dssdev);
+ omapdss_hdmi_core_disable(dssdev);
err:
mutex_unlock(&hdmi.lock);
@@ -359,7 +359,7 @@ static bool hdmi_detect(struct omap_dss_device *dssdev)
need_enable = dssdev->state == OMAP_DSS_DISPLAY_DISABLED;
if (need_enable) {
- r = omapdss_hdmi_display_enable(dssdev);
+ r = omapdss_hdmi_core_enable(dssdev);
if (r)
goto err;
}
@@ -367,7 +367,7 @@ static bool hdmi_detect(struct omap_dss_device *dssdev)
r = omapdss_hdmi_detect();
if (need_enable)
- omapdss_hdmi_display_disable(dssdev);
+ omapdss_hdmi_core_disable(dssdev);
err:
mutex_unlock(&hdmi.lock);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 09/20] OMAPDSS: add dispc_ovl_enabled()
Add new dispc function, dispc_ovl_enabled(). This returns if the overlay
enable bit is set in the registers.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc.c |5 +
drivers/video/omap2/dss/dss.h |1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index b5cdbaf..3fd60ce 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2589,6 +2589,11 @@ int dispc_ovl_enable(enum omap_plane plane, bool enable)
return 0;
}
+bool dispc_ovl_enabled(enum omap_plane plane)
+{
+ return REG_GET(DISPC_OVL_ATTRIBUTES(plane), 0, 0);
+}
+
static void dispc_mgr_disable_isr(void *data, u32 mask)
{
struct completion *compl = data;
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index b007aee..be7678c 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -428,6 +428,7 @@ int dispc_ovl_setup(enum omap_plane plane, const struct
omap_overlay_info *oi,
bool replication, const struct omap_video_timings *mgr_timings,
bool mem_to_mem);
int dispc_ovl_enable(enum omap_plane plane, bool enable);
+bool dispc_ovl_enabled(enum omap_plane plane);
void dispc_ovl_set_channel_out(enum omap_plane plane,
enum omap_channel channel);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 18/20] OMAPDSS: DISPC: fix loop in error handler
The dispc's error handler has a loop inside another loop, and both use
the same loop variable. This is clearly wrong, and this patch makes a
new variable for the inner loop.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index d294873..070ce30 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3901,6 +3901,7 @@ static void dispc_error_worker(struct work_struct *work)
bit = mgr_desc[i].sync_lost_irq;
if (bit & errors) {
+ int j;
struct omap_dss_device *dssdev = mgr->get_device(mgr);
bool enable;
@@ -3911,9 +3912,9 @@ static void dispc_error_worker(struct work_struct *work)
enable = dssdev->state == OMAP_DSS_DISPLAY_ACTIVE;
dssdev->driver->disable(dssdev);
- for (i = 0; i < omap_dss_get_num_overlays(); ++i) {
+ for (j = 0; j < omap_dss_get_num_overlays(); ++j) {
struct omap_overlay *ovl;
- ovl = omap_dss_get_overlay(i);
+ ovl = omap_dss_get_overlay(j);
if (ovl->id != OMAP_DSS_GFX &&
ovl->manager == mgr)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 17/20] OMAPDSS: fix DSI2 PLL clk names
dss_generic_clk_source_names is missing the names for clocks from DSI2
PLL. Add them.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dss.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index d90de37..456118b 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -97,6 +97,8 @@ static const char * const dss_generic_clk_source_names[] = {
[OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC] = "DSI_PLL_HSDIV_DISPC",
[OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI]= "DSI_PLL_HSDIV_DSI",
[OMAP_DSS_CLK_SRC_FCK] = "DSS_FCK",
+ [OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC] = "DSI_PLL2_HSDIV_DISPC",
+ [OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI] = "DSI_PLL2_HSDIV_DSI",
};
static inline void dss_write_reg(const struct dss_reg idx, u32 val)
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 19/20] OMAPDSS: DISPC: remove dssdev depependency from error handler
The dispc error handler tries to "fix" issues by disabling and enabling
panel. This is problematic, as we're trying to remove the dependency
from omapdss to the omap_dss_devices. It's also racy, and doesn't really
fix anything.
This patch removes the use of omap_dss_device from the error handler,
and just disables and enables the associated overlay manager. This
should produce similar results as the previous solution, without using
dssdev.
However, the error handling is still horrible. But the problem boils
down to one question, to which I don't have a clear answer: what to do
when a HW error happens?
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc.c | 19 ---
1 file changed, 4 insertions(+), 15 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 070ce30..61b48ca 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3902,15 +3902,12 @@ static void dispc_error_worker(struct work_struct *work)
if (bit & errors) {
int j;
- struct omap_dss_device *dssdev = mgr->get_device(mgr);
- bool enable;
DSSERR("SYNC_LOST on channel %s, restarting the output "
"with video overlays disabled\n",
mgr->name);
- enable = dssdev->state == OMAP_DSS_DISPLAY_ACTIVE;
- dssdev->driver->disable(dssdev);
+ dss_mgr_disable(mgr);
for (j = 0; j < omap_dss_get_num_overlays(); ++j) {
struct omap_overlay *ovl;
@@ -3918,14 +3915,10 @@ static void dispc_error_worker(struct work_struct *work)
if (ovl->id != OMAP_DSS_GFX &&
ovl->manager == mgr)
- dispc_ovl_enable(ovl->id, false);
+ dss_ovl_disable(ovl);
}
- dispc_mgr_go(mgr->id);
- msleep(50);
-
- if (enable)
- dssdev->driver->enable(dssdev);
+ dss_mgr_enable(mgr);
}
}
@@ -3933,13 +3926,9 @@ static void dispc_error_worker(struct work_struct *work)
DSSERR("OCP_ERR\n");
for (i = 0; i < omap_dss_get_num_overlay_managers(); ++i) {
struct omap_overlay_manager *mgr;
- struct omap_dss_device *dssdev;
mgr = omap_dss_get_overlay_manager(i);
- dssdev = mgr->get_device(mgr);
-
- if (dssdev && dssdev->driver)
- dssdev->driver->disable(dssdev);
+ dss_mgr_disable(mgr);
}
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 14/20] OMAPDSS: HDMI: make hdmi pclk check more permissive
The hdmi driver tries to find the given video timings from its static
list of timings, to find the required ID for the mode. The check tries
to find exact match for the pixel clock, among other checks.
with omapfb driver there can be some amount of error in the give pixel
clock, as the pixel clock is converted between Hz and ps, thus the
hdmi's check fails to find the mode.
This patch makes the check more allowing, by rounding the pixel clocks
to nearest MHz.
Signed-off-by: Tomi Valkeinen
Cc: Ricardo Neri
---
drivers/video/omap2/dss/hdmi.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index dfbc1e7..90cc1b1 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -404,7 +404,8 @@ static bool hdmi_timings_compare(struct omap_video_timings
*timing1,
{
int timing1_vsync, timing1_hsync, timing2_vsync, timing2_hsync;
- if ((timing2->pixel_clock == timing1->pixel_clock) &&
+ if ((DIV_ROUND_CLOSEST(timing2->pixel_clock, 1000) ==
+ DIV_ROUND_CLOSEST(timing1->pixel_clock, 1000)) &&
(timing2->x_res == timing1->x_res) &&
(timing2->y_res == timing1->y_res)) {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 15/20] OMAPFB: remove use of extended edid block
It seems that using the second EDID block causes more problems than is of any help. The first mode in the extended block will get FB_MODE_IS_FIRST set, which will override the first mode from the first EDID block, thus making the default videomode selection not to work properly. This patch removes the use of the extended edid block for now. Signed-off-by: Tomi Valkeinen --- drivers/video/omap2/omapfb/omapfb-main.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c index c0ff8b5ad..fe37039 100644 --- a/drivers/video/omap2/omapfb/omapfb-main.c +++ b/drivers/video/omap2/omapfb/omapfb-main.c @@ -2272,9 +2272,6 @@ static int omapfb_find_best_mode(struct omap_dss_device *display, fb_edid_to_monspecs(edid, specs); - if (edid[126] > 0) - fb_edid_add_monspecs(edid + 0x80, specs); - best_xres = 0; best_idx = -1; -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 11/20] OMAPDSS: HDMI: split power_on/off to two parts
There's currently just one power-on function for HDMI, which enables the
IP and the video output. When reading EDID or detecting if a monitor is
connected, we don't need the video output.
Enabling the video output for these operations is not a big problem in
itself, but the quick enable/disable cycles caused by the operations
seem to cause sync lost errors from time to time. Also, this makes it
possible to read the EDID before the full video path has been set up.
This patch splits the hdmi_power_on into two parts, hdmi_power_on_core
and hdmi_power_on_full. The "full" version does what hdmi_power_on does
currently, and hdmi_power_on_core only enables the core IP. Similar
changes are made for power_off.
Note that these don't allow the HDMI IP to be first enabled, and later
enable the video output, but the HDMI IP will first need to be powered
off before calling the full version. So this is rather limited
implementation, but it fills the needs for reading EDID.
Signed-off-by: Tomi Valkeinen
Cc: Ricardo Neri
---
drivers/video/omap2/dss/hdmi.c | 75
1 file changed, 46 insertions(+), 29 deletions(-)
diff --git a/drivers/video/omap2/dss/hdmi.c b/drivers/video/omap2/dss/hdmi.c
index c1c5488..50d5a10 100644
--- a/drivers/video/omap2/dss/hdmi.c
+++ b/drivers/video/omap2/dss/hdmi.c
@@ -500,12 +500,9 @@ static void hdmi_compute_pll(struct omap_dss_device
*dssdev, int phy,
DSSDBG("range = %d sd = %d\n", pi->dcofreq, pi->regsd);
}
-static int hdmi_power_on(struct omap_dss_device *dssdev)
+static int hdmi_power_on_core(struct omap_dss_device *dssdev)
{
int r;
- struct omap_video_timings *p;
- struct omap_overlay_manager *mgr = dssdev->output->manager;
- unsigned long phy;
gpio_set_value(hdmi.ct_cp_hpd_gpio, 1);
gpio_set_value(hdmi.ls_oe_gpio, 1);
@@ -521,6 +518,46 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
if (r)
goto err_runtime_get;
+ /* Make selection of HDMI in DSS */
+ dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
+
+ /* Select the dispc clock source as PRCM clock, to ensure that it is not
+* DSI PLL source as the clock selected by DSI PLL might not be
+* sufficient for the resolution selected / that can be changed
+* dynamically by user. This can be moved to single location , say
+* Boardfile.
+*/
+ dss_select_dispc_clk_source(dssdev->clocks.dispc.dispc_fclk_src);
+
+ return 0;
+
+err_runtime_get:
+ regulator_disable(hdmi.vdda_hdmi_dac_reg);
+err_vdac_enable:
+ gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
+ gpio_set_value(hdmi.ls_oe_gpio, 0);
+ return r;
+}
+
+static void hdmi_power_off_core(struct omap_dss_device *dssdev)
+{
+ hdmi_runtime_put();
+ regulator_disable(hdmi.vdda_hdmi_dac_reg);
+ gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
+ gpio_set_value(hdmi.ls_oe_gpio, 0);
+}
+
+static int hdmi_power_on_full(struct omap_dss_device *dssdev)
+{
+ int r;
+ struct omap_video_timings *p;
+ struct omap_overlay_manager *mgr = dssdev->output->manager;
+ unsigned long phy;
+
+ r = hdmi_power_on_core(dssdev);
+ if (r)
+ return r;
+
dss_mgr_disable(mgr);
p = &hdmi.ip_data.cfg.timings;
@@ -548,17 +585,6 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)
hdmi.ip_data.ops->video_configure(&hdmi.ip_data);
- /* Make selection of HDMI in DSS */
- dss_select_hdmi_venc_clk_source(DSS_HDMI_M_PCLK);
-
- /* Select the dispc clock source as PRCM clock, to ensure that it is not
-* DSI PLL source as the clock selected by DSI PLL might not be
-* sufficient for the resolution selected / that can be changed
-* dynamically by user. This can be moved to single location , say
-* Boardfile.
-*/
- dss_select_dispc_clk_source(dssdev->clocks.dispc.dispc_fclk_src);
-
/* bypass TV gamma table */
dispc_enable_gamma_table(0);
@@ -582,16 +608,11 @@ err_vid_enable:
err_phy_enable:
hdmi.ip_data.ops->pll_disable(&hdmi.ip_data);
err_pll_enable:
- hdmi_runtime_put();
-err_runtime_get:
- regulator_disable(hdmi.vdda_hdmi_dac_reg);
-err_vdac_enable:
- gpio_set_value(hdmi.ct_cp_hpd_gpio, 0);
- gpio_set_value(hdmi.ls_oe_gpio, 0);
+ hdmi_power_off_core(dssdev);
return -EIO;
}
-static void hdmi_power_off(struct omap_dss_device *dssdev)
+static void hdmi_power_off_full(struct omap_dss_device *dssdev)
{
struct omap_overlay_manager *mgr = dssdev->output->manager;
@@ -600,12 +621,8 @@ static void hdmi_power_off(struct omap_dss_device *dssdev)
hdmi.ip_data.ops->video_disable(&hdmi.ip_data);
hdmi.ip_data.ops->phy_disable(&hdmi.ip_data);
hdmi.ip_data.ops->pll_disable(&hdmi.ip_data);
- hdmi_runtime_put();
- regulator_disable(hdmi.vdda_hdmi_dac_reg)
[PATCH 08/20] OMAPDSS: DISPC: make _enable_mgr_out public as "dispc_mgr_enable"
We need a low level manager-enable function for omapdrm. We have that
function as dispc internal func, _enable_mgr_out().
This patch exposes that function, and renames it to dispc_mgr_enable().
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/dispc.c | 10 +-
drivers/video/omap2/dss/dss.h |1 +
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 600a412..b5cdbaf 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2595,7 +2595,7 @@ static void dispc_mgr_disable_isr(void *data, u32 mask)
complete(compl);
}
-static void _enable_mgr_out(enum omap_channel channel, bool enable)
+void dispc_mgr_enable(enum omap_channel channel, bool enable)
{
mgr_fld_write(channel, DISPC_MGR_FLD_ENABLE, enable);
/* flush posted write */
@@ -2609,7 +2609,7 @@ bool dispc_mgr_is_enabled(enum omap_channel channel)
static void dispc_mgr_enable_lcd_out(enum omap_channel channel)
{
- _enable_mgr_out(channel, true);
+ dispc_mgr_enable(channel, true);
}
static void dispc_mgr_disable_lcd_out(enum omap_channel channel)
@@ -2633,7 +2633,7 @@ static void dispc_mgr_disable_lcd_out(enum omap_channel
channel)
if (r)
DSSERR("failed to register FRAMEDONE isr\n");
- _enable_mgr_out(channel, false);
+ dispc_mgr_enable(channel, false);
/* if we couldn't register for framedone, just sleep and exit */
if (r) {
@@ -2685,7 +2685,7 @@ static void dispc_mgr_enable_digit_out(void)
return;
}
- _enable_mgr_out(OMAP_DSS_CHANNEL_DIGIT, true);
+ dispc_mgr_enable(OMAP_DSS_CHANNEL_DIGIT, true);
/* wait for the first evsync */
if (!wait_for_completion_timeout(&vsync_compl, msecs_to_jiffies(100)))
@@ -2735,7 +2735,7 @@ static void dispc_mgr_disable_digit_out(void)
if (r)
DSSERR("failed to register %x isr\n", irq_mask);
- _enable_mgr_out(OMAP_DSS_CHANNEL_DIGIT, false);
+ dispc_mgr_enable(OMAP_DSS_CHANNEL_DIGIT, false);
/* if we couldn't register the irq, just sleep and exit */
if (r) {
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index efe8984..b007aee 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -436,6 +436,7 @@ u32 dispc_mgr_get_framedone_irq(enum omap_channel channel);
u32 dispc_mgr_get_sync_lost_irq(enum omap_channel channel);
bool dispc_mgr_go_busy(enum omap_channel channel);
void dispc_mgr_go(enum omap_channel channel);
+void dispc_mgr_enable(enum omap_channel channel, bool enable);
bool dispc_mgr_is_enabled(enum omap_channel channel);
void dispc_mgr_enable_sync(enum omap_channel channel);
void dispc_mgr_disable_sync(enum omap_channel channel);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 07/20] OMAPDSS: DISPC: rename dispc_mgr_enable/disable to _sync
The current dispc_mgr_enable/disable function are blocking, and do a bit
too much for omapdrm. We'll expose new enable & disable functions that
will just set the bits in the registers in the following patches.
This patch renames the current functions to *_sync, to make it clear
that they are blocking, and also to free up the dispc_mgr_enable/disable
names for these new functions.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/apply.c |6 +++---
drivers/video/omap2/dss/dispc.c |4 ++--
drivers/video/omap2/dss/dss.h |4 ++--
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/video/omap2/dss/apply.c b/drivers/video/omap2/dss/apply.c
index 7a61a2f..6a21443 100644
--- a/drivers/video/omap2/dss/apply.c
+++ b/drivers/video/omap2/dss/apply.c
@@ -772,7 +772,7 @@ void dss_mgr_start_update(struct omap_overlay_manager *mgr)
if (!dss_data.irq_enabled && need_isr())
dss_register_vsync_isr();
- dispc_mgr_enable(mgr->id);
+ dispc_mgr_enable_sync(mgr->id);
mgr_clear_shadow_dirty(mgr);
@@ -1027,7 +1027,7 @@ int dss_mgr_enable(struct omap_overlay_manager *mgr)
spin_unlock_irqrestore(&data_lock, flags);
if (!mgr_manual_update(mgr))
- dispc_mgr_enable(mgr->id);
+ dispc_mgr_enable_sync(mgr->id);
out:
mutex_unlock(&apply_lock);
@@ -1052,7 +1052,7 @@ void dss_mgr_disable(struct omap_overlay_manager *mgr)
goto out;
if (!mgr_manual_update(mgr))
- dispc_mgr_disable(mgr->id);
+ dispc_mgr_disable_sync(mgr->id);
spin_lock_irqsave(&data_lock, flags);
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 392445a..600a412 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -2755,7 +2755,7 @@ static void dispc_mgr_disable_digit_out(void)
DSSERR("failed to unregister %x isr\n", irq_mask);
}
-void dispc_mgr_enable(enum omap_channel channel)
+void dispc_mgr_enable_sync(enum omap_channel channel)
{
if (dss_mgr_is_lcd(channel))
dispc_mgr_enable_lcd_out(channel);
@@ -2765,7 +2765,7 @@ void dispc_mgr_enable(enum omap_channel channel)
WARN_ON(1);
}
-void dispc_mgr_disable(enum omap_channel channel)
+void dispc_mgr_disable_sync(enum omap_channel channel)
{
if (dss_mgr_is_lcd(channel))
dispc_mgr_disable_lcd_out(channel);
diff --git a/drivers/video/omap2/dss/dss.h b/drivers/video/omap2/dss/dss.h
index 00e0a36..efe8984 100644
--- a/drivers/video/omap2/dss/dss.h
+++ b/drivers/video/omap2/dss/dss.h
@@ -437,8 +437,8 @@ u32 dispc_mgr_get_sync_lost_irq(enum omap_channel channel);
bool dispc_mgr_go_busy(enum omap_channel channel);
void dispc_mgr_go(enum omap_channel channel);
bool dispc_mgr_is_enabled(enum omap_channel channel);
-void dispc_mgr_enable(enum omap_channel channel);
-void dispc_mgr_disable(enum omap_channel channel);
+void dispc_mgr_enable_sync(enum omap_channel channel);
+void dispc_mgr_disable_sync(enum omap_channel channel);
bool dispc_mgr_is_channel_enabled(enum omap_channel channel);
void dispc_mgr_set_lcd_config(enum omap_channel channel,
const struct dss_lcd_mgr_config *config);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 05/20] OMAPDSS: remove initial display code from omapdss
Currently omapdss driver sets up the initial connections between
overlays, overlay manager and a panel, based on default display
parameter coming from the board file or via module parameters.
This is unnecessary, as it's the higher level component that should
decide what display to use and how. This patch removes the code from
omapdss, and implements similar code to omapfb.
The def_disp module parameter and the default display platform_data
parameter are kept in omapdss, but omapdss doesn't do anything with
them. It will just return the default display name with
dss_get_default_display_name() call, which omapfb uses. This is done to
keep the backward compatibility.
Signed-off-by: Tomi Valkeinen
---
drivers/video/omap2/dss/core.c |1 +
drivers/video/omap2/dss/display.c| 78 +++---
drivers/video/omap2/omapfb/omapfb-main.c | 77 -
include/video/omapdss.h |1 +
4 files changed, 75 insertions(+), 82 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 685d9a9..4cb669e 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -57,6 +57,7 @@ const char *dss_get_default_display_name(void)
{
return core.default_display_name;
}
+EXPORT_SYMBOL(dss_get_default_display_name);
enum omapdss_version omapdss_get_version(void)
{
diff --git a/drivers/video/omap2/dss/display.c
b/drivers/video/omap2/dss/display.c
index 1e58730..6d33112 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -320,86 +320,21 @@ void omapdss_default_get_timings(struct omap_dss_device
*dssdev,
}
EXPORT_SYMBOL(omapdss_default_get_timings);
-/*
- * Connect dssdev to a manager if the manager is free or if force is specified.
- * Connect all overlays to that manager if they are free or if force is
- * specified.
- */
-static int dss_init_connections(struct omap_dss_device *dssdev, bool force)
+int dss_init_device(struct platform_device *pdev,
+ struct omap_dss_device *dssdev)
{
+ struct device_attribute *attr;
struct omap_dss_output *out;
- struct omap_overlay_manager *mgr;
int i, r;
out = omapdss_get_output_from_dssdev(dssdev);
- WARN_ON(dssdev->output);
- WARN_ON(out->device);
-
r = omapdss_output_set_device(out, dssdev);
if (r) {
DSSERR("failed to connect output to new device\n");
return r;
}
- mgr = omap_dss_get_overlay_manager(dssdev->channel);
-
- if (mgr->output && !force)
- return 0;
-
- if (mgr->output)
- mgr->unset_output(mgr);
-
- r = mgr->set_output(mgr, out);
- if (r) {
- DSSERR("failed to connect manager to output of new device\n");
-
- /* remove the output-device connection we just made */
- omapdss_output_unset_device(out);
- return r;
- }
-
- for (i = 0; i < omap_dss_get_num_overlays(); ++i) {
- struct omap_overlay *ovl = omap_dss_get_overlay(i);
-
- if (!ovl->manager || force) {
- if (ovl->manager)
- ovl->unset_manager(ovl);
-
- r = ovl->set_manager(ovl, mgr);
- if (r) {
- DSSERR("failed to set initial overlay\n");
- return r;
- }
- }
- }
-
- return 0;
-}
-
-static void dss_uninit_connections(struct omap_dss_device *dssdev)
-{
- if (dssdev->output) {
- struct omap_overlay_manager *mgr = dssdev->output->manager;
-
- if (mgr)
- mgr->unset_output(mgr);
-
- omapdss_output_unset_device(dssdev->output);
- }
-}
-
-int dss_init_device(struct platform_device *pdev,
- struct omap_dss_device *dssdev)
-{
- struct device_attribute *attr;
- int i, r;
- const char *def_disp_name = dss_get_default_display_name();
- bool force;
-
- force = def_disp_name && strcmp(def_disp_name, dssdev->name) == 0;
- dss_init_connections(dssdev, force);
-
/* create device sysfs files */
i = 0;
while ((attr = display_sysfs_attrs[i++]) != NULL) {
@@ -410,7 +345,7 @@ int dss_init_device(struct platform_device *pdev,
device_remove_file(&dssdev->dev, attr);
}
- dss_uninit_connections(dssdev);
+ omapdss_output_unset_device(dssdev->output);
DSSERR("failed to create sysfs file\n");
return r;
@@ -424,7 +359,7 @@ int dss_init_device(struct platform_device *pdev,
while ((attr = display_sysfs_attrs[i++]) != NULL)
device_remove_file(&dssdev->dev, a
