Re: [PATCH] OMAP: Beagle: fix TFP410 powerdown GPIO init
On Wed, Jun 13, 2012 at 2:20 AM, Tomi Valkeinen wrote:
> Commit e813a55eb9c9bc6c8039fb16332cf43402125b30 ("OMAP: board-files:
> remove custom PD GPIO handling for DVI output") moved TFP410 chip's
> powerdown-gpio handling from the board files to the tfp410 driver. One
> gpio_request_one(powerdown-gpio, ...) was mistakenly left unremoved in
> the Beagle board file. This causes the tfp410 driver to fail to request
> the gpio on Beagle, causing the driver to fail and thus the DVI output
> doesn't work.
Can you take the one I sent earlier instead?
http://www.spinics.net/lists/linux-omap/msg69913.html
--
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 5/5] Input: ads7846: set proper debounce time in driver level
On 06/14/12 07:46, Zumeng Chen wrote:
> 于 2012年06月13日 20:18, Hiremath, Vaibhav 写道:
>> On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
>>> From: Zumeng Chen
>>>
>>> If we don't set proper debouce time for ads7846, then there are
>>> flooded interrupt counters of ads7846 responding to one time
>>> touch on screen, so the driver couldn't work well.
>>>
>>> And since most OMAP3 series boards pass NULL pointer of board_pdata
>>> to omap_ads7846_init, so it's more proper to set it in driver level
>>> after having gpio_request done.
>>>
>>> This patch has been validated on 3530evm.
>>>
>>> Signed-off-by: Zumeng Chen
>>> Signed-off-by: Syed Mohammed Khasim
>>> ---
>>> drivers/input/touchscreen/ads7846.c |4
>>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/drivers/input/touchscreen/ads7846.c
>>> b/drivers/input/touchscreen/ads7846.c
>>> index f02028e..459ff29 100644
>>> --- a/drivers/input/touchscreen/ads7846.c
>>> +++ b/drivers/input/touchscreen/ads7846.c
>>> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct
>>> spi_device *spi, struct ads784
>>> }
>>>
>>> ts->gpio_pendown = pdata->gpio_pendown;
>>> +#ifdef CONFIG_ARCH_OMAP3
>>> +/* 310 means about 10 microsecond for omap3 */
>>> +gpio_set_debounce(pdata->gpio_pendown, 310);
>>> +#endif
>>>
>> Zumeng,
>>
>> With my sign-off you are changing the original code, that too
>> without my sign-off and ack.
>> I wouldn't mind you to submit patches from my tree, but the expectation is
>> if you are changing the original code, it should be under your sign-off.
> Thanks, good to learn. I'll remove in next time.
>> Coming to the patch, #ifdef in driver is not recommended, and this 10msec
>> delay is specific to OMAP GPIO and driver should not be aware of this,
>> that's where you will find the original patch handling it in board file.
> According to the git blame of the board-omap3evm.c I think
> 96974a24 did a good thing to all the related codes for omap3
> boards. So I think we can call board and driver as BSP level :-)
>
> If #ifdef in driver can save many codes, I guess it's deserved.
No, platform/board specific ifdefs in the generic driver code are never
deserved.
How about the attached patch, does it fix the problem for you?
--
Regards,
Igor.
diff --git a/arch/arm/mach-omap2/common-board-devices.c b/arch/arm/mach-omap2/common-board-devices.c
index 1706ebc..c187586 100644
--- a/arch/arm/mach-omap2/common-board-devices.c
+++ b/arch/arm/mach-omap2/common-board-devices.c
@@ -63,28 +63,30 @@ void __init omap_ads7846_init(int bus_num, int gpio_pendown, int gpio_debounce,
struct spi_board_info *spi_bi = &ads7846_spi_board_info;
int err;
- if (board_pdata && board_pdata->get_pendown_state) {
- err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
- if (err) {
- pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
- return;
- }
- gpio_export(gpio_pendown, 0);
-
- if (gpio_debounce)
- gpio_set_debounce(gpio_pendown, gpio_debounce);
+ err = gpio_request_one(gpio_pendown, GPIOF_IN, "TSPenDown");
+ if (err) {
+ pr_err("Couldn't obtain gpio for TSPenDown: %d\n", err);
+ return;
}
+ if (gpio_debounce)
+ gpio_set_debounce(gpio_pendown, gpio_debounce);
+
spi_bi->bus_num = bus_num;
spi_bi->irq = gpio_to_irq(gpio_pendown);
if (board_pdata) {
board_pdata->gpio_pendown = gpio_pendown;
spi_bi->platform_data = board_pdata;
+ if (board_pdata->get_pendown_state)
+ gpio_export(gpio_pendown, 0);
} else {
ads7846_config.gpio_pendown = gpio_pendown;
}
+ if (!board_pdata || (board_pdata && !board_pdata->get_pendown_state))
+ gpio_free(gpio_pendown);
+
spi_register_board_info(&ads7846_spi_board_info, 1);
}
#else
RE: [PATCH v5 04/14] ARM: OMAP2+: gpmc: minimal driver support
Hi Tony, On Thu, Jun 14, 2012 at 12:05:25, Tony Lindgren wrote: > * Mohammed, Afzal [120613 06:56]: > > Or you meant, even there read revision register ? > > Yeah that should be fine as this really should only happen > during init and whatever revision specific features can > be initialized for GPMC. Sorry, I got confused, we need revision to be available while setting time also, so you meant to store it as a variable or read revision at probe as well as during setting time ? Regards Afzal -- 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 v5 04/14] ARM: OMAP2+: gpmc: minimal driver support
* Mohammed, Afzal [120613 06:56]: > Hi Tony, > > On Wed, Jun 13, 2012 at 19:20:35, Mohammed, Afzal wrote: > > Hi Tony, > > > > On Wed, Jun 13, 2012 at 19:14:08, Tony Lindgren wrote: > > > > > Actually why do you even need to store the revision? You can > > > just read it from the hardware as needed. > > > > Earlier for wr_access & wr_data_mux_bus, we were checking, > > cpu_is_34xx, but I feel it should instead be based on > > IP revision as it is the IP revision that decides the > > availability of those register bits. > > Or you meant, even there read revision register ? Yeah that should be fine as this really should only happen during init and whatever revision specific features can be initialized for GPMC. 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 v5 03/14] ARM: OMAP2+: gpmc: driver migration helper
* Mohammed, Afzal [120613 06:50]: > Hi Tony, > > On Wed, Jun 13, 2012 at 17:48:15, Mohammed, Afzal wrote: > > On Wed, Jun 13, 2012 at 17:34:58, Tony Lindgren wrote: > > > > There should no longer be any need to initialize GPMC early. It should > > > behave like any other device driver, and also work as a loadable module. > > > > Once driver migration is complete for all the boards, we can remove the > > initcall and make it loadable. > > > > But till that time as we need to support both old & new interface, > > I feel this is necessary as old interface would happen in arch initcall, > > and old gpmc_init is now gpmc_probe, and hence it needs to get executed > > before arch initcall, necessitating this. > > Seems you missed this in the flood of mails, please let me know your > comments on this. This is a commit that has to be reverted once driver > migration is complete for all boards. Yes sounds good to me. 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/3] ARM: OMAP2+: gpmc: handle additional timings
* Mohammed, Afzal [120613 07:09]: > Hi Tony, > > On Wed, Jun 13, 2012 at 18:12:15, Tony Lindgren wrote: > > > > Or should additional timings be achieved without affecting old > > > interface, but that it seems would necessitate more code > > > duplication. > > > > We should just keep the same timings as before, with values > > added for the newly added registers. > > What I understood from above is to get values bootloader used to > set for those new timings & put in Kernel, right ? Yeah and eventually to the .dts files. 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 5/5] Input: ads7846: set proper debounce time in driver level
On Thu, Jun 14, 2012 at 10:16:55, Zumeng Chen wrote: > 于 2012年06月13日 20:18, Hiremath, Vaibhav 写道: > > On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote: > >> From: Zumeng Chen > >> > >> If we don't set proper debouce time for ads7846, then there are > >> flooded interrupt counters of ads7846 responding to one time > >> touch on screen, so the driver couldn't work well. > >> > >> And since most OMAP3 series boards pass NULL pointer of board_pdata > >> to omap_ads7846_init, so it's more proper to set it in driver level > >> after having gpio_request done. > >> > >> This patch has been validated on 3530evm. > >> > >> Signed-off-by: Zumeng Chen > >> Signed-off-by: Syed Mohammed Khasim > >> --- > >> drivers/input/touchscreen/ads7846.c |4 > >> 1 files changed, 4 insertions(+), 0 deletions(-) > >> > >> diff --git a/drivers/input/touchscreen/ads7846.c > >> b/drivers/input/touchscreen/ads7846.c > >> index f02028e..459ff29 100644 > >> --- a/drivers/input/touchscreen/ads7846.c > >> +++ b/drivers/input/touchscreen/ads7846.c > >> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct > >> spi_device *spi, struct ads784 > >>} > >> > >>ts->gpio_pendown = pdata->gpio_pendown; > >> +#ifdef CONFIG_ARCH_OMAP3 > >> + /* 310 means about 10 microsecond for omap3 */ > >> + gpio_set_debounce(pdata->gpio_pendown, 310); > >> +#endif > >> > > Zumeng, > > > > With my sign-off you are changing the original code, that too > > without my sign-off and ack. > > I wouldn't mind you to submit patches from my tree, but the expectation is > > if you are changing the original code, it should be under your sign-off. > Thanks, good to learn. I'll remove in next time. > > Coming to the patch, #ifdef in driver is not recommended, and this 10msec > > delay is specific to OMAP GPIO and driver should not be aware of this, > > that's where you will find the original patch handling it in board file. > According to the git blame of the board-omap3evm.c I think > 96974a24 did a good thing to all the related codes for omap3 > boards. So I think we can call board and driver as BSP level :-) > > If #ifdef in driver can save many codes, I guess it's deserved. > No, not really. In the same commit, the debounce time is already handled as an argument to the function omap_ads7846_init(), and that’s the way it should be. So no need for #ifdefs in driver... Thanks, Vaibhav -- 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 v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Jon, On Thu, Jun 14, 2012 at 11:47:03, Mohammed, Afzal wrote: > gpmc_cs_set_timings() does currently convert time to clock cycles required, > and this gpmc driver have the capability to do it. > > What I was saying is a different issue, input to gpmc_cs_set_timings, which > is time sometimes in turn is a function of time or to be exact depends on > gpmc clock period also. So timings provided to gpmc_cs_set_timings for a > particular frequency may not hold good for another frequency, unless we > change the input time to gpmc_cs_set_timings based on gpmc clock. > > If you see gpmc-* files, many a times, they need to know value of gpmc fclk, > to calculate the input time to be fed for gpmc_cs_set_timings And the way value of gpmc period has to be handled differs depending on the peripheral. Regards Afzal -- 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 v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Jon, On Wed, Jun 13, 2012 at 20:21:50, Hunter, Jon wrote: > > I do not think it is practically possible. Please see timing calculations > > in arch/arm/mach-omap2/gpmc-*, the way it is done for different > > peripherals are different, and we cannot expect gpmc driver to do those as > > that would require gpmc driver being aware of type of peripheral connected. > > > > And all those gpmc-* timing calculation needs to be done before driver > > is ready, they rely on functions like gpmc_get_fclk_rate(), which in turn > > requires the clk rate to be available before driver is probed. > > So I see that the various gpmc-*.c files have some form of _retime() > function. However, at the end of the day they all call > gpmc_cs_set_timings() to convert time into gpmc clocks. Converting time > to gpmc clocks is completely independent of the actual device and so > this can be performed by the driver. We just need to populate the > gpmc_timings struct and pass to the driver to convert to clocks and > program into the registers. gpmc_cs_set_timings() does currently convert time to clock cycles required, and this gpmc driver have the capability to do it. What I was saying is a different issue, input to gpmc_cs_set_timings, which is time sometimes in turn is a function of time or to be exact depends on gpmc clock period also. So timings provided to gpmc_cs_set_timings for a particular frequency may not hold good for another frequency, unless we change the input time to gpmc_cs_set_timings based on gpmc clock. If you see gpmc-* files, many a times, they need to know value of gpmc fclk, to calculate the input time to be fed for gpmc_cs_set_timings Regards Afzal -- 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 0/3] Prepare for GPMC driver conversion
Hi Jon, On Wed, Jun 13, 2012 at 22:16:57, Hunter, Jon wrote: > Afzal, let me know if you have been able to test. I have a omap2430 with > onenand I could try. Yes, this has been tested with omap3evm. Let me try if I can get another onenand board to test. If you can test, that would be really helpful. Regards Afzal -- 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 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion
Hi Jon, On Wed, Jun 13, 2012 at 22:08:47, Hunter, Jon wrote: > On 06/13/2012 12:03 AM, Mohammed, Afzal wrote: > > As gpmc_onenand_setup is a callback by onenand driver, we would have > > lost the opportunity to configure onenand before driver is probed. > > Is that a problem? Looks like it is called early in the probe and so I > would hope no one is attempting to access the onenand itself before the > probe has completed. During gpmc driver probe, it will configure all the connected peripherals, if configuration details are not present at that point of time, gpmc driver will cry out saying that configuration & timings has not been configured, (please see holler if no configuration patch). And I do not see any reason why gpmc driver should not be fed with async mode configuration initially, as it has to be done always. > > > This would cause requirement of double GPMC configuring and we lost > > the opportunity to configure GPMC before driver is probed. > > I am not convinced we need to. Furthermore with your change you do not > actually set async mode in the onenand until _set_sync() is called. Yes, setting async mode in onenand is done in set_sync function, and it is always called by onenand driver indirectly. Seems if setting async mode in onenand is taken out of set_sync & placed it before set_sync invocation in gpmc_onenand_setup, intention will be clear, right ? (even though sequence wise same thing is happening now) > > > And the first step for onenand configuration is always to set it > > to async mode (with the way it is done now), so it seems reasonable > > to rely on normal GPMC configuration for async & then do reconfigure > > for sync. > > Yes but as far as I can see, it seems that this is the intent of the > onenand_setup() function to perform the necessary initialisation. I believe doing it in gpmc_onenand_init is better, due to the reasons mentioned above as well as because function name will correspond to what it is doing, i.e. initialization > > Have you tested onenand? Do you have a board with onenand? Yes, on omap3evm, with help of local patches (as mainline doesn't have those). It was mentioned in cover letter of gpmc driver conversion series Regards Afzal -- 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/5] Input: ads7846: set proper debounce time in driver level
于 2012年06月13日 20:55, Tony Lindgren 写道: * Zumeng Chen [120612 09:41]: 2012/6/12 Tony Lindgren * Zumeng Chen [120611 07:05]: If we don't set proper debouce time for ads7846, then there are flooded interrupt counters of ads7846 responding to one time touch on screen, so the driver couldn't work well. And since most OMAP3 series boards pass NULL pointer of board_pdata to omap_ads7846_init, so it's more proper to set it in driver level after having gpio_request done. This patch has been validated on 3530evm. Signed-off-by: Zumeng Chen Signed-off-by: Syed Mohammed Khasim Signed-off-by: Tony Lindgren Please remove my Signed-off-by, where does that come from? HI Tony, This comes from git://arago-project.org/git/projects/linux-omap3.git The commit ID is 53c5ec31, we set gpio_debounce in arch/board level. Weird, I have no recollection of doing anything with that file.. Just remove my Signed-off-by please. NP, Tony, done, sorry for inconvenience. Regards, Zumeng 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 5/5] Input: ads7846: set proper debounce time in driver level
于 2012年06月13日 20:18, Hiremath, Vaibhav 写道:
On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
From: Zumeng Chen
If we don't set proper debouce time for ads7846, then there are
flooded interrupt counters of ads7846 responding to one time
touch on screen, so the driver couldn't work well.
And since most OMAP3 series boards pass NULL pointer of board_pdata
to omap_ads7846_init, so it's more proper to set it in driver level
after having gpio_request done.
This patch has been validated on 3530evm.
Signed-off-by: Zumeng Chen
Signed-off-by: Syed Mohammed Khasim
---
drivers/input/touchscreen/ads7846.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/input/touchscreen/ads7846.c
b/drivers/input/touchscreen/ads7846.c
index f02028e..459ff29 100644
--- a/drivers/input/touchscreen/ads7846.c
+++ b/drivers/input/touchscreen/ads7846.c
@@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct
spi_device *spi, struct ads784
}
ts->gpio_pendown = pdata->gpio_pendown;
+#ifdef CONFIG_ARCH_OMAP3
+ /* 310 means about 10 microsecond for omap3 */
+ gpio_set_debounce(pdata->gpio_pendown, 310);
+#endif
Zumeng,
With my sign-off you are changing the original code, that too
without my sign-off and ack.
I wouldn't mind you to submit patches from my tree, but the expectation is
if you are changing the original code, it should be under your sign-off.
Thanks, good to learn. I'll remove in next time.
Coming to the patch, #ifdef in driver is not recommended, and this 10msec
delay is specific to OMAP GPIO and driver should not be aware of this,
that's where you will find the original patch handling it in board file.
According to the git blame of the board-omap3evm.c I think
96974a24 did a good thing to all the related codes for omap3
boards. So I think we can call board and driver as BSP level :-)
If #ifdef in driver can save many codes, I guess it's deserved.
Regards,
Zumeng
Thanks,
Vaibhav
} else {
dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
--
1.7.5.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 V3 1/2] of: Add generic device tree DMA helpers
On 14 June 2012 04:02, Jon Hunter wrote: > On 06/08/2012 07:04 PM, Arnd Bergmann wrote: > >> As I said previously, I think just encoding the direction but not >> the client specific ID (meaning we would have to disambiguate >> the more complex cases that Stephen mentioned using a dma-names >> property) would be the best because it keeps the common case simple, >> but I could live with other things going in there too. > > Ok, so you are saying that there are some DMA controllers where there is > no channel/request ID and only a direction is needed? So an even simpler > case than what I had imagined. > I am curious to know which DMA controllers don't need any client ID ? unless it is Mem->Mem (for which even specifying direction is meaningless). Rather, I think specifying direction is even lesser useful, since usually the client's ID imply the (bi/uni)direction. -- 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 v8 8/8] x86/tlb: do flush_tlb_kernel_range by 'invlpg'
On 06/14/2012 09:26 AM, Alex Shi wrote: > On 06/14/2012 09:10 AM, Alex Shi wrote: > >> On 06/13/2012 10:56 PM, Andi Kleen wrote: >> >>> On Tue, Jun 12, 2012 at 05:06:45PM +0800, Alex Shi wrote: This patch do flush_tlb_kernel_range by 'invlpg'. The performance pay and gain was analysed in my patch (x86/flush_tlb: try flush_tlb_single one by one in flush_tlb_range). Now we move this logical into kernel part. The pay is multiple 'invlpg' execution cost, that is same. but the gain(cost reducing of TLB entries refilling) is absolutely increased. >>> >>> The subtle point is whether INVLPG flushes global pages or not. >>> After some digging I found a sentence in the SDM that says it does. >>> So it may be safe. >> >> >> Many thanks for your time! >> >>> >>> What does it improve? >> >> >> I have not specific benchmark for this. partly due to the gain theory >> was proved since it is same as previous user process's page table flush. >> >> The user of tlb kernel flush in kernel is vmalloc. and Android binder >> IPC subsystem is using it(drivers/staging/android/binder.c) >> >> I am wondering if it can help Andriod on this? >> So, add cc to android-ker...@googlegroups.com > > > Sorry, Andriod reject posting without register, so cc to > linux-omap@vger.kernel.org and linux-te...@vger.kernel.org instead. Ops, forget the architecture different again This will help x86 android, not arm system. Forget above 2 mailing lists. :( > >> >>> -Andi >> >> > > -- 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 v8 8/8] x86/tlb: do flush_tlb_kernel_range by 'invlpg'
On 06/14/2012 09:10 AM, Alex Shi wrote: > On 06/13/2012 10:56 PM, Andi Kleen wrote: > >> On Tue, Jun 12, 2012 at 05:06:45PM +0800, Alex Shi wrote: >>> This patch do flush_tlb_kernel_range by 'invlpg'. The performance pay >>> and gain was analysed in my patch (x86/flush_tlb: try flush_tlb_single >>> one by one in flush_tlb_range). Now we move this logical into kernel >>> part. The pay is multiple 'invlpg' execution cost, that is same. but >>> the gain(cost reducing of TLB entries refilling) is absolutely >>> increased. >> >> The subtle point is whether INVLPG flushes global pages or not. >> After some digging I found a sentence in the SDM that says it does. >> So it may be safe. > > > Many thanks for your time! > >> >> What does it improve? > > > I have not specific benchmark for this. partly due to the gain theory > was proved since it is same as previous user process's page table flush. > > The user of tlb kernel flush in kernel is vmalloc. and Android binder > IPC subsystem is using it(drivers/staging/android/binder.c) > > I am wondering if it can help Andriod on this? > So, add cc to android-ker...@googlegroups.com Sorry, Andriod reject posting without register, so cc to linux-omap@vger.kernel.org and linux-te...@vger.kernel.org instead. > >> -Andi > > -- 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] gpio/omap: cleanups for v3.5
On Fri, 11 May 2012 17:30:48 -0700 Kevin Hilman wrote: > Hi Grant, > > Here's the final round of GPIO cleanups for v3.5. This branch is based > on my for_3.5/fixes/gpio branch you just pulled. > > Kevin Hi. I'm not sure if it was this series or the following cleanups which broke things for me, but I've been trying 3.5-rc2 on my GTA04 and the serial console (ttyO2) dies as soon as the omap-gpio driver initialises. After some digging I came up with this patch to gpio-omap.c @@ -1124,6 +1124,9 @@ static int __devinit omap_gpio_probe(struct platform_device *pdev) platform_set_drvdata(pdev, bank); + if (bank->get_context_loss_count) + bank->context_loss_count = + bank->get_context_loss_count(bank->dev); pm_runtime_enable(bank->dev); pm_runtime_irq_safe(bank->dev); pm_runtime_get_sync(bank->dev); which fixes it. What was happening was that when omap_gpio_probe calls pm_runtime_get_sync, it calls _od_runtime_resume -> pm_generic_runtime_resume -> omap_gpio_runtime_resume -> omap_gpio_restore_context and then the serial port stops. I reasoned that the context probably hadn't been set up yet, so restoring from it broke things. Initialising bank->context_loss_count seems sensible and would ensure that we didn't try to restore the context until it has actually been lost. Thanks, NeilBrown signature.asc Description: PGP signature
Re: [PATCH 00/11] ARM: OMAP: core/hwmod: first set of fixes for 3.5-rc
Hi Tero, On Fri, 8 Jun 2012, Tero Kristo wrote: > Tested this set on top of v3.5-rc1 with omap3 / omap4 suspend + my omap4 > core retention / dev-off patches. There are a couple of minor issues, > like the bug in patch 5, and the fact that counter_32k hwmod data is > broken for omap4. This fix is needed on omap4 to fix the counter_32k, if > this is not done, device off does not work: Thanks for the testing and the reminder. Will send the next version of this soon to address more comments from Tony. - Paul -- 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 05/12] ARM: OMAP2+: HWMOD: Correct timer device attributes
On Fri, 8 Jun 2012, Tony Lindgren wrote: > Care to review and potentially ack the hwmod parts of this series? Done. - Paul -- 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 05/12] ARM: OMAP2+: HWMOD: Correct timer device attributes
On Tue, 5 Jun 2012, Jon Hunter wrote: > Fix the following issues with the timer device attributes for OMAP2+ devices: > > 1. For OMAP24xx devices, timers 2-8 have the ALWAYS-ON attribute indicating >that these timers are in an ALWAYS-ON power domain. This is not the case >only timer1 is in an ALWAYS-ON power domain. > 2. For OMAP3xxx devices, timers 2-7 have the ALWAYS-ON attribute indicating >that these timers are in an ALWAYS-ON power domain. This is not the case >only timer1 and timer12 are in an ALWAYS-ON power domain. > 3. For OMAP3xxx devices, timer12 does not have the ALWAYS-ON attribute but >is in an always-on power domain. > > Signed-off-by: Jon Hunter Thanks Jon. Acked-by: Paul Walmsley - Paul -- 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+: hwmod data: Fix the wrong clkdm assigned to PRCM modules
Benoît and I discussed this today, at length. Our views still differ.
In an attempt to move on to more useful work, a compromise was agreed.
The following patch removes the requirement for hwmods to have a
clkdm_name, and removes the PRM and CM clockdomains from the data.
It is intended for 3.6.
- Paul
From: Paul Walmsley
Date: Wed, 13 Jun 2012 17:16:05 -0600
Subject: [PATCH] ARM: OMAP2+: hwmod: remove prm_clkdm, cm_clkdm; allow hwmods
to have no clockdomain
Remove prm_clkdm and cm_clkdm and allow hwmods to have no clockdomain.
Signed-off-by: Paul Walmsley
Cc: Benoît Cousson
---
arch/arm/mach-omap2/Makefile |1 -
arch/arm/mach-omap2/clockdomain.h |2 --
arch/arm/mach-omap2/clockdomains2420_data.c|2 --
arch/arm/mach-omap2/clockdomains2430_data.c|2 --
arch/arm/mach-omap2/clockdomains3xxx_data.c|2 --
arch/arm/mach-omap2/clockdomains44xx_data.c|2 --
arch/arm/mach-omap2/clockdomains_common_data.c | 24
arch/arm/mach-omap2/omap_hwmod.c |9 -
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |3 ---
9 files changed, 4 insertions(+), 43 deletions(-)
delete mode 100644 arch/arm/mach-omap2/clockdomains_common_data.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index fa742f3..bc7d239 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -116,7 +116,6 @@ obj-$(CONFIG_ARCH_OMAP4)+=
powerdomains44xx_data.o
# PRCM clockdomain control
clockdomain-common += clockdomain.o
-clockdomain-common += clockdomains_common_data.o
obj-$(CONFIG_ARCH_OMAP2) += $(clockdomain-common)
obj-$(CONFIG_ARCH_OMAP2) += clockdomain2xxx_3xxx.o
obj-$(CONFIG_ARCH_OMAP2) += clockdomains2xxx_3xxx_data.o
diff --git a/arch/arm/mach-omap2/clockdomain.h
b/arch/arm/mach-omap2/clockdomain.h
index f7b5860..349dcbb 100644
--- a/arch/arm/mach-omap2/clockdomain.h
+++ b/arch/arm/mach-omap2/clockdomain.h
@@ -206,7 +206,5 @@ extern struct clkdm_ops omap4_clkdm_operations;
extern struct clkdm_dep gfx_24xx_wkdeps[];
extern struct clkdm_dep dsp_24xx_wkdeps[];
extern struct clockdomain wkup_common_clkdm;
-extern struct clockdomain prm_common_clkdm;
-extern struct clockdomain cm_common_clkdm;
#endif
diff --git a/arch/arm/mach-omap2/clockdomains2420_data.c
b/arch/arm/mach-omap2/clockdomains2420_data.c
index 0ab8e46..5c74185 100644
--- a/arch/arm/mach-omap2/clockdomains2420_data.c
+++ b/arch/arm/mach-omap2/clockdomains2420_data.c
@@ -131,8 +131,6 @@ static struct clockdomain dss_2420_clkdm = {
static struct clockdomain *clockdomains_omap242x[] __initdata = {
&wkup_common_clkdm,
- &cm_common_clkdm,
- &prm_common_clkdm,
&mpu_2420_clkdm,
&iva1_2420_clkdm,
&dsp_2420_clkdm,
diff --git a/arch/arm/mach-omap2/clockdomains2430_data.c
b/arch/arm/mach-omap2/clockdomains2430_data.c
index 3645ed0..f096175 100644
--- a/arch/arm/mach-omap2/clockdomains2430_data.c
+++ b/arch/arm/mach-omap2/clockdomains2430_data.c
@@ -157,8 +157,6 @@ static struct clockdomain dss_2430_clkdm = {
static struct clockdomain *clockdomains_omap243x[] __initdata = {
&wkup_common_clkdm,
- &cm_common_clkdm,
- &prm_common_clkdm,
&mpu_2430_clkdm,
&mdm_clkdm,
&dsp_2430_clkdm,
diff --git a/arch/arm/mach-omap2/clockdomains3xxx_data.c
b/arch/arm/mach-omap2/clockdomains3xxx_data.c
index 6038adb..2cdc17c 100644
--- a/arch/arm/mach-omap2/clockdomains3xxx_data.c
+++ b/arch/arm/mach-omap2/clockdomains3xxx_data.c
@@ -347,8 +347,6 @@ static struct clkdm_autodep clkdm_autodeps[] = {
static struct clockdomain *clockdomains_omap3430_common[] __initdata = {
&wkup_common_clkdm,
- &cm_common_clkdm,
- &prm_common_clkdm,
&mpu_3xxx_clkdm,
&neon_clkdm,
&iva2_clkdm,
diff --git a/arch/arm/mach-omap2/clockdomains44xx_data.c
b/arch/arm/mach-omap2/clockdomains44xx_data.c
index c534258..bd7ed13 100644
--- a/arch/arm/mach-omap2/clockdomains44xx_data.c
+++ b/arch/arm/mach-omap2/clockdomains44xx_data.c
@@ -430,8 +430,6 @@ static struct clockdomain *clockdomains_omap44xx[]
__initdata = {
&l4_wkup_44xx_clkdm,
&emu_sys_44xx_clkdm,
&l3_dma_44xx_clkdm,
- &prm_common_clkdm,
- &cm_common_clkdm,
NULL
};
diff --git a/arch/arm/mach-omap2/clockdomains_common_data.c
b/arch/arm/mach-omap2/clockdomains_common_data.c
deleted file mode 100644
index 615b1f0..000
--- a/arch/arm/mach-omap2/clockdomains_common_data.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/*
- * OMAP2+-common clockdomain data
- *
- * Copyright (C) 2008-2012 Texas Instruments, Inc.
- * Copyright (C) 2008-2010 Nokia Corporation
- *
- * Paul Walmsley, Jouni Högander
- */
-
-#include
-#include
-
-#include "clockdomain.h"
-
-/* These are implicit clockdomains - they are never defined as such in TRM */
-st
Problems in the DaVinci EMAC driver & AM35xx?
All,
I believe I may have uncovered a problem in the DaVinci EMAC driver as it is
used on the AM35xx. I suspect this is likely related to the slab crashing I
reported here (http://thread.gmane.org/gmane.linux.ports.arm.omap/78039/). Your
help and thoughts on this would be greatly appreciated.
and
*A QUICK BACKSTORY:*
We've been working with AM3517 modules (CM-T3517 and TAM3517) for about 6
months now, and in that time have tried many different versions of OS software.
We started with the 2.6.37 kernel supported by TI's PSP and quickly migrated
through 3.2, 3.3, 3.4, and as of yeterday, 3.5rc1. In that same time, we've
tried several versions of both bootloaders as well. One consistent factor we've
noticed is a relatively odd DaVinci EMAC performance issue. Using just basic
iperf ("iperf -s" on one side, "iperf -c " on the other), we noted that
whenever we used our DaVinci EMAC port on the AM3517, we saw poor performance
when connecting AM3517 EMAC <=> AM3517 EMAC, but great performance when
connecting the EMAC to another, non-EMAC Ethernet device. Here is a real
example capture:
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
{{ DaVinci EMAC server, PC client }}
[ 4] local 192.168.2.192 port 5001 connected with 192.168.2.40 port 44452
[ ID] Interval Transfer Bandwidth
[ 4] 0.0-10.1 sec 114 MBytes 94.1 Mbits/sec
[ 5] local 192.168.2.192 port 5001 connected with 192.168.2.40 port 44459
[ 5] 0.0-10.1 sec 114 MBytes 94.0 Mbits/sec
[ 4] local 192.168.2.192 port 5001 connected with 192.168.2.40 port 44467
[ 4] 0.0-10.1 sec 113 MBytes 94.1 Mbits/sec
[ 5] local 192.168.2.192 port 5001 connected with 192.168.2.40 port 44474
[ 5] 0.0-10.1 sec 114 MBytes 94.1 Mbits/sec
[ 4] local 192.168.2.192 port 5001 connected with 192.168.2.40 port 44481
[ 4] 0.0-10.1 sec 114 MBytes 94.1 Mbits/sec
[ 5] local 192.168.2.192 port 5001 connected with 192.168.2.40 port 44488
[ 5] 0.0- 9.8 sec 110 MBytes 94.1 Mbits/sec
{{ same DaVinci EMAC server, still running, just changed to DaVinci EMAC client
}}
[ 5] local 192.168.2.192 port 5001 connected with 192.168.2.74 port 37325
[ 5] 0.0-10.4 sec 73.9 MBytes 59.6 Mbits/sec
[ 6] local 192.168.2.192 port 5001 connected with 192.168.2.74 port 37326
[ 6] 0.0-10.8 sec 61.5 MBytes 47.8 Mbits/sec
[ 5] local 192.168.2.192 port 5001 connected with 192.168.2.74 port 37327
[ 5] 0.0-10.3 sec 64.6 MBytes 52.6 Mbits/sec
[ 6] local 192.168.2.192 port 5001 connected with 192.168.2.74 port 37328
[ 6] 0.0-10.0 sec 78.2 MBytes 65.5 Mbits/sec
See how the data rates drop from high 80s - 90s+ Mbps down into the 50s+ Mbps?
Despite that data rate slowdown, we only show having dropped 1 packet. There
are no errors or xruns reported. We've long been frustrated by this, but not
having time to invest in it, we were willing to accept the slower performance
for the time being. As we upgraded versions of Linux, we hoped that perhaps it
would simply get better. Unfortunately it did not.
*NOW FOR THE "BUG"?:*
Several months ago, we started seeing that slab error that is being discussed
on this list (http://thread.gmane.org/gmane.linux.ports.arm.omap/78039/). The
error was generic enough that we could not put our finger on it. We could not
figure out a way of reliably reproducing it. We assumed something in our
software immediately, and spent the last several months constantly updating our
BSP to include the latest bootloaders and Linux sources. However, that never
made it go away. It was a very sporadic error. Some days the boards would crash
constantly with it, and then mysteriously weeks would pass without incident.
Right when we started to think our latest kernel update had killed it, it would
come roaring back
Last week was one of those weeks where the issues came roaring back. Since they
coincided with us enabling the EMAC from within u-boot, we turned our attention
to the EMAC immediately and started running constant iperf loop tests against
it. For a while, it seemed it could create the slab error relatively easily,
but then as fast as it came, it disappeared again.
Today I was running a combination test of iperf and the stress utility
(http://weather.ou.edu/~apw/projects/stress/), and even with relatively mild
stress loads I was seeing other memory allocation crashes being blamed on the
EMAC. (For those that have read the other thread, my SMSC LAN911x port has been
disabled in the bootloaders and kernel for these tests. So, it cannot play a
role here.) We saw several errors on two different platforms and across both
the 3.4rc6 and 3.5rc1 kernels. All the different errors are reported below.
I'm definitely not a Linux memory management expert, but it's looking like the
Davinci EMAC driver, at least as it pertains to the AM35xx platform, may be
malf
Re: [PATCH V3 1/2] of: Add generic device tree DMA helpers
Hi Arnd, On 06/08/2012 07:04 PM, Arnd Bergmann wrote: > On Friday 08 June 2012, Jon Hunter wrote: >> On 05/21/2012 03:32 PM, Stephen Warren wrote: >>> On 05/21/2012 12:18 PM, Arnd Bergmann wrote: On Monday 21 May 2012, Stephen Warren wrote: > > If so, that seems a little odd; you have to request a DMA channel for > "TX", but then end up having the common code check all the entries in > the dmas property since it can't know which are TX, and then have the > wrong ones almost accidentally fail, since the DMAC will then determine > that it can't support TX on the RX DMA request IDs. I think the direction must be encoded in a way that does not depend on the binding for the specific controller. There are two ways I can see how we might do it: 1. have separate property names for tx and rx channels, and probably one for combined rx/tx channels >>> 2. define the second cell in each channel specifier to be the direction in a predefined format, followed by the other (controller specific) attributes, if any. >>> >>> In this option, lets say bit 0 is 0==TX, 1==RX (or perhaps 2 bits if >>> combined TX/RX is needed) >>> >>> Then, we could reserve say bits 7:1 as client DMA request ID. >>> >>> And then have bits 31:8 as DMAC specific data. >>> >>> Wouldn't that allow us to have our cake and eat it? >> >> Sorry for not responding sooner. >> >> It seems to me we were pretty close on alignment. In fact, I was quite >> happy with Steven's 2nd to last proposal of ... >> >> simple 1 req: >> dmas = <0 &dmac1 xxx>; >> >> simple 2 req: >> dmas = <0 &dmac1 xxx 1 &dmac1 yyy>; >> >> multiple dmacs: >> dmas = <0 &dmac1 xxx 0 &dmac2 zzz 1 &dmac1 yyy>; >> >> Arnd, I know that you had some concerns. However, in the above case I >> would expect that the 3rd parameter be optional and it can be some sort >> of match variable. In other words, we don't care how the 32-bits are >> encoded or what they represent but they would be used appropriately by >> the xlate function being used. So the xlate and this "match" variable >> would have to speak the same language. > > I would at least put the &dmac part first to be consistent with other > bindings that refer to some node. That controller should then be > able to specify the number of additional cells used to describe the > dma request. We can define that the first cell after the controller > phandle is always the same thing, e.g. the direction (in/out/inout) > or a client-specific ID or a combination of that with other predefined > bits that are not dependent on dma controller specifics. I agree with putting the &dmac phandle first, that makes sense. > As I said previously, I think just encoding the direction but not > the client specific ID (meaning we would have to disambiguate > the more complex cases that Stephen mentioned using a dma-names > property) would be the best because it keeps the common case simple, > but I could live with other things going in there too. Ok, so you are saying that there are some DMA controllers where there is no channel/request ID and only a direction is needed? So an even simpler case than what I had imagined. So in that case, I don't see why the first cell after the phandle could not be an index which could be either a direction or request-id and then the next cell after that be a secondary match variable. So simple case with just a index (either req-id or direction) ... dmas = <&dmac0 index> More complex case ... dmas = <&dmac0 index match> For example, for OMAP index = req-id and match = direction ... dmas = <&dmac0 req-id direction> Or am I way off the page? 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 04/12] ARM: OMAP4: hwmod data: fix 32k sync timer idle modes
On Mon, 11 Jun 2012, Cousson, Benoit wrote: > On 6/11/2012 2:46 AM, Paul Walmsley wrote: > > The 32k sync timer IP block target idle modes are incorrect in the > > hwmod data are incorrect. > > Nit: Is there too many "incorrect" in this sentence? Thanks; patch updated. - Paul -- 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 v5 04/14] ARM: OMAP2+: gpmc: minimal driver support
On 06/13/2012 08:40 AM, Tony Lindgren wrote: > * Mohammed, Afzal [120613 06:16]: >> Hi Tony, >> >> On Wed, Jun 13, 2012 at 17:37:17, Tony Lindgren wrote: >>> * Jon Hunter [120612 11:01]: On 06/12/2012 02:16 AM, Mohammed, Afzal wrote: >> > Does having minor revision add any value ?, at least as of now, > I do not see any. May be not but it does not hurt either. >>> >>> Yeah might as well show the full revision. >> >> We are already showing full version, but only storing major, it seems you >> want to store minor version along with major version in the same variable, >> right ? > > Ah OK, yeah might as well just store the minor version. Actually, you really need the major version. However, IMO if you are going to store it, then store the whole thing, you have allocated 32-bits and the major and minor combined are 8-bits. 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 0/3] Prepare for GPMC driver conversion
Hi Tony, Afzal, On 06/13/2012 07:40 AM, Mohammed, Afzal wrote: > Hi Tony, > > On Wed, Jun 13, 2012 at 17:03:59, Tony Lindgren wrote: > >> NAND for untested boards if timings change. Are Jon's comments all handled? > > I have explained the justification, why those changes were done so, > waiting for his comments. My only real concern right now is for onenand. Afzal, let me know if you have been able to test. I have a omap2430 with onenand I could try. 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 2/3] ARM: OMAP2+: onenand: cleanup for gpmc driver conversion
Hi Afzal, On 06/13/2012 12:03 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 23:00:48, Hunter, Jon wrote: > >> On 06/12/2012 01:16 AM, Mohammed, Afzal wrote: >>> With the existing code, set_async was done as part of set_sync, hence >>> requiring GPMC to be configured twice after driver takes control, with >>> your suggestion too, GPMC would have to be configured twice. >> >> I am just suggesting that you place the call to set_async_mode in the >> gpmc_onenand_setup() instead of the gpmc_onenand_init() and remove the >> calls from set_sync (like you have done). So I don't see that these >> would configure the GPMC twice. > > As gpmc_onenand_setup is a callback by onenand driver, we would have > lost the opportunity to configure onenand before driver is probed. Is that a problem? Looks like it is called early in the probe and so I would hope no one is attempting to access the onenand itself before the probe has completed. > This would cause requirement of double GPMC configuring and we lost > the opportunity to configure GPMC before driver is probed. I am not convinced we need to. Furthermore with your change you do not actually set async mode in the onenand until _set_sync() is called. > And the first step for onenand configuration is always to set it > to async mode (with the way it is done now), so it seems reasonable > to rely on normal GPMC configuration for async & then do reconfigure > for sync. Yes but as far as I can see, it seems that this is the intent of the onenand_setup() function to perform the necessary initialisation. Have you tested onenand? Do you have a board with onenand? 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 v5 14/14] ARM: OMAP2+: gpmc: writeprotect helper
Hi Afzal, On 06/13/2012 01:10 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Wed, Jun 13, 2012 at 00:12:27, Hunter, Jon wrote: > >> I am still wondering if we should warn against multiple devices using >> the wait pin. I see that if could be valid to have multiple memory >> devices of the same type using the WP pin spanning multiple CS. However, >> in that case would/should the memory devices be registered as a single >> child? If so then we could still impose a policy of only one child >> device using the WP. > > Presently there are no peripherals in mainline turning on writeprotect, > initially intention was to just disable writeprotect at the end of probe > and not provide platforms opportunity to enable writeprotect as none > need it, still a provision has been provided for platform to enable it. > > Probably these to be taken care when there is a requirement. Ok, but I am still not happy about this. So I did find that our omap2420h4 board does route the write protect to both NOR and NAND. Therefore, it does appear to be a valid use-case that multiple child devices can share the write-protect. So maybe we do not need to reserve the write-protect like we are doing for chip-selects, but I think that devices should indicate if they use the write-protect pin and we should either have this "enable on boot" as a global setting not specific to a child device or ensure that multiple devices using the wp have the same configuration of the wp on boot. In other words, if one device says enable on boot and the other does not, then warn. 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
[rft/rfc/patch 20/22] i2c: omap: avoid unnecessary register read
dev->buf_len will always contain the correct
number we're looking for. No need to read
from BUFSTAT register.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5a7a223..f2ab95a 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -934,18 +934,15 @@ omap_i2c_threaded_isr(int this_irq, void *dev_id)
if (stat & OMAP_I2C_STAT_RDR) {
u8 num_bytes = 1;
- if (dev->errata & I2C_OMAP_ERRATA_I207)
- i2c_omap_errata_i207(dev, stat);
-
- if (dev->fifo_size) {
- num_bytes = omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG);
- num_bytes >>= 8;
- num_bytes &= 0x3f;
- }
+ if (dev->fifo_size)
+ num_bytes = dev->buf_len;
omap_i2c_receive_data(dev, num_bytes, true);
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+
+ if (dev->errata & I2C_OMAP_ERRATA_I207)
+ i2c_omap_errata_i207(dev, stat);
+
continue;
}
@@ -964,11 +961,8 @@ omap_i2c_threaded_isr(int this_irq, void *dev_id)
int ret;
u8 num_bytes = 1;
- if (dev->fifo_size) {
- num_bytes = omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG);
- num_bytes &= 0x3f;
- }
+ if (dev->fifo_size)
+ num_bytes = dev->buf_len;
ret = omap_i2c_transmit_data(dev, num_bytes, true);
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
--
1.7.10.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
[rft/rfc/patch 22/22] i2c: omap: simplify errata check
omap_i2c_dev is allocated with kzalloc(), so we need not initialize b_hw to zero. Signed-off-by: Felipe Balbi --- drivers/i2c/busses/i2c-omap.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 492e340..45c2bf7 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -1135,9 +1135,7 @@ omap_i2c_probe(struct platform_device *pdev) dev->fifo_size = (dev->fifo_size / 2); - if (dev->rev >= OMAP_I2C_REV_ON_3530_4430) - dev->b_hw = 0; /* Disable hardware fixes */ - else + if (dev->rev < OMAP_I2C_REV_ON_3530_4430) dev->b_hw = 1; /* Enable hardware fixes */ /* calculate wakeup latency constraint for MPU */ -- 1.7.10.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
[rft/rfc/patch 21/22] i2c: omap: no need to reinitialize "stat"
we will already loop again and that variable
will be reinitialized at the beginning of the
loop.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c |2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f2ab95a..492e340 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -965,7 +965,6 @@ omap_i2c_threaded_isr(int this_irq, void *dev_id)
num_bytes = dev->buf_len;
ret = omap_i2c_transmit_data(dev, num_bytes, true);
- stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret < 0) {
err |= OMAP_I2C_STAT_XUDF;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF |
@@ -985,7 +984,6 @@ omap_i2c_threaded_isr(int this_irq, void *dev_id)
num_bytes = dev->fifo_size;
ret = omap_i2c_transmit_data(dev, num_bytes, false);
- stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret < 0) {
err |= OMAP_I2C_STAT_XUDF;
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF |
--
1.7.10.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
[rft/rfc/patch 19/22] i2c: omap: bus: add a receiver flag
that way we can ignore TX IRQs while in receiver
mode and ignore RX IRQs while in transmitter mode.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c |9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9274fcb..5a7a223 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -199,6 +199,7 @@ struct omap_i2c_dev {
*/
u8 rev;
unsignedb_hw:1; /* bad h/w fixes */
+ unsignedreceiver:1; /* true when we're in receiver
mode */
u16 iestate;/* Saved interrupt register */
u16 pscstate;
u16 scllstate;
@@ -537,6 +538,7 @@ static int omap_i2c_xfer_msg(struct i2c_adapter *adap,
init_completion(&dev->cmd_complete);
dev->cmd_err = 0;
+ dev->receiver = !!(msg->flags & I2C_M_RD);
w = OMAP_I2C_CON_EN | OMAP_I2C_CON_MST | OMAP_I2C_CON_STT;
@@ -898,6 +900,13 @@ omap_i2c_threaded_isr(int this_irq, void *dev_id)
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
stat &= bits;
+ /* If we're in receiver mode, ignore XDR/XRDY */
+ if (dev->receiver) {
+ stat &= ~(OMAP_I2C_STAT_XDR | OMAP_I2C_STAT_XRDY);
+ } else {
+ stat &= ~(OMAP_I2C_STAT_RDR | OMAP_I2C_STAT_RRDY);
+ }
+
if (!stat) {
/* my work here is done */
omap_i2c_complete_cmd(dev, err);
--
1.7.10.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
[rft/rfc/patch 17/22] i2c: omap: drop Access Ready IRQ
documentation is very unclear about how that
works and testing shows that driver works without
it.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 22 ++
1 file changed, 2 insertions(+), 20 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index b9c9407..20f854d 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -474,9 +474,8 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
dev->errata |= I2C_OMAP_ERRATA_I207;
/* Enable interrupts */
- dev->iestate = (OMAP_I2C_IE_XRDY | OMAP_I2C_IE_RRDY |
- OMAP_I2C_IE_ARDY | OMAP_I2C_IE_NACK |
- OMAP_I2C_IE_AL) | ((dev->fifo_size) ?
+ 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) {
@@ -923,23 +922,6 @@ omap_i2c_threaded_isr(int this_irq, void *dev_id)
return IRQ_HANDLED;
}
- if (stat & OMAP_I2C_STAT_ARDY)
- omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ARDY);
-
- /*
-* ProDB0017052: Clear ARDY bit twice
-*/
- if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
- OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
- OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY |
- OMAP_I2C_STAT_XDR |
- OMAP_I2C_STAT_ARDY));
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
- }
-
if (stat & OMAP_I2C_STAT_RDR) {
u8 num_bytes = 1;
--
1.7.10.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
[rft/rfc/patch 18/22] i2c: omap: drop errata i207 from RRDY interrupt
that errata refers only to RDR interrupt. It's safe
to drop it.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 20f854d..9274fcb 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -943,9 +943,6 @@ omap_i2c_threaded_isr(int this_irq, void *dev_id)
if (stat & OMAP_I2C_STAT_RRDY) {
u8 num_bytes = 1;
- if (dev->errata & I2C_OMAP_ERRATA_I207)
- i2c_omap_errata_i207(dev, stat);
-
if (dev->fifo_size)
num_bytes = dev->fifo_size;
--
1.7.10.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
[rft/rfc/patch 16/22] i2c: omap: switch to platform_get_irq()
that's a nice helper from drivers core which
will give us the exact IRQ number, instead
of a pointer to an IRQ resource.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 5e9e165..b9c9407 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1071,10 +1071,11 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq;
+ struct resource *mem;
struct omap_i2c_bus_platform_data *pdata = pdev->dev.platform_data;
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
+ int irq;
int r;
/* NOTE: driver uses the static register mapping */
@@ -1084,10 +1085,10 @@ omap_i2c_probe(struct platform_device *pdev)
return -ENODEV;
}
- irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
- if (!irq) {
+ irq = platform_get_irq(pdev, 0);
+ if (irq < 0) {
dev_err(&pdev->dev, "no irq resource?\n");
- return -ENODEV;
+ return irq;
}
dev = devm_kzalloc(&pdev->dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
@@ -1115,7 +1116,7 @@ omap_i2c_probe(struct platform_device *pdev)
}
dev->dev = &pdev->dev;
- dev->irq = irq->start;
+ dev->irq = irq;
dev->base = devm_request_and_ioremap(&pdev->dev, mem);
if (!dev->base) {
dev_err(&pdev->dev, "ioremap failed\n");
--
1.7.10.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
[rft/rfc/patch 15/22] i2c: omap: switch to devm_* API
that helps deleting some boiler plate code
and lets driver-core manage our resources
for us.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 50 +
1 file changed, 15 insertions(+), 35 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index f30eb45..5e9e165 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -1071,7 +1071,7 @@ omap_i2c_probe(struct platform_device *pdev)
{
struct omap_i2c_dev *dev;
struct i2c_adapter *adap;
- struct resource *mem, *irq, *ioarea;
+ struct resource *mem, *irq;
struct omap_i2c_bus_platform_data *pdata = pdev->dev.platform_data;
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
@@ -1083,23 +1083,17 @@ omap_i2c_probe(struct platform_device *pdev)
dev_err(&pdev->dev, "no mem resource?\n");
return -ENODEV;
}
+
irq = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!irq) {
dev_err(&pdev->dev, "no irq resource?\n");
return -ENODEV;
}
- ioarea = request_mem_region(mem->start, resource_size(mem),
- pdev->name);
- if (!ioarea) {
- dev_err(&pdev->dev, "I2C region already claimed\n");
- return -EBUSY;
- }
-
- dev = kzalloc(sizeof(struct omap_i2c_dev), GFP_KERNEL);
+ dev = devm_kzalloc(&pdev->dev, sizeof(struct omap_i2c_dev), GFP_KERNEL);
if (!dev) {
- r = -ENOMEM;
- goto err_release_region;
+ dev_err(&pdev->dev, "not enough memory\n");
+ return -ENOMEM;
}
match = of_match_device(of_match_ptr(omap_i2c_of_match), &pdev->dev);
@@ -1122,10 +1116,10 @@ omap_i2c_probe(struct platform_device *pdev)
dev->dev = &pdev->dev;
dev->irq = irq->start;
- dev->base = ioremap(mem->start, resource_size(mem));
+ dev->base = devm_request_and_ioremap(&pdev->dev, mem);
if (!dev->base) {
- r = -ENOMEM;
- goto err_free_mem;
+ dev_err(&pdev->dev, "ioremap failed\n");
+ return -ENOMEM;
}
platform_set_drvdata(pdev, dev);
@@ -1175,11 +1169,12 @@ omap_i2c_probe(struct platform_device *pdev)
omap_i2c_init(dev);
if (dev->rev < OMAP_I2C_OMAP1_REV_2)
- r = request_irq(dev->irq, omap_i2c_omap1_isr, 0,
- pdev->name, dev);
+ r = devm_request_irq(&pdev->dev, dev->irq, omap_i2c_omap1_isr,
+ 0, pdev->name, dev);
else
- r = request_threaded_irq(dev->irq, omap_i2c_isr,
- omap_i2c_threaded_isr, 0, pdev->name, dev);
+ r = devm_request_threaded_irq(&pdev->dev, dev->irq,
+ omap_i2c_isr, omap_i2c_threaded_isr, 0,
+ pdev->name, dev);
if (r) {
dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
@@ -1205,24 +1200,16 @@ omap_i2c_probe(struct platform_device *pdev)
r = i2c_add_numbered_adapter(adap);
if (r) {
dev_err(dev->dev, "failure adding adapter\n");
- goto err_free_irq;
+ goto err_unuse_clocks;
}
of_i2c_register_devices(adap);
return 0;
-err_free_irq:
- free_irq(dev->irq, dev);
err_unuse_clocks:
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
pm_runtime_put(dev->dev);
- iounmap(dev->base);
-err_free_mem:
- platform_set_drvdata(pdev, NULL);
- kfree(dev);
-err_release_region:
- release_mem_region(mem->start, resource_size(mem));
return r;
}
@@ -1231,17 +1218,10 @@ static int
omap_i2c_remove(struct platform_device *pdev)
{
struct omap_i2c_dev *dev = platform_get_drvdata(pdev);
- struct resource *mem;
-
- platform_set_drvdata(pdev, NULL);
- free_irq(dev->irq, dev);
i2c_del_adapter(&dev->adapter);
omap_i2c_write_reg(dev, OMAP_I2C_CON_REG, 0);
- iounmap(dev->base);
- kfree(dev);
- mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(mem->start, resource_size(mem));
+
return 0;
}
--
1.7.10.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
[rft/rfc/patch 14/22] i2c: omap: ack ARDY IRQ
comment asks us to clear it twice, so let's do so. Signed-off-by: Felipe Balbi --- drivers/i2c/busses/i2c-omap.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index e555681..f30eb45 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -923,6 +923,9 @@ omap_i2c_threaded_isr(int this_irq, void *dev_id) return IRQ_HANDLED; } + if (stat & OMAP_I2C_STAT_ARDY) + omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ARDY); + /* * ProDB0017052: Clear ARDY bit twice */ -- 1.7.10.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
[rft/rfc/patch 12/22] i2c: omap: get rid of the "complete" label
we can ack stat and complete the command from
the errata handling itself.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index dba174c..9dadfb1 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -903,7 +903,7 @@ omap_i2c_threaded_isr(int this_irq, void *dev_id)
}
dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
-complete:
+
if (stat & OMAP_I2C_STAT_NACK) {
dev_err(dev->dev, "No Acknowledge\n");
err |= OMAP_I2C_STAT_NACK;
@@ -980,7 +980,9 @@ complete:
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret < 0) {
err |= OMAP_I2C_STAT_XUDF;
- goto complete;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF |
+ OMAP_I2C_STAT_XDR);
+ omap_i2c_complete_cmd(dev, err);
}
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XDR);
@@ -998,7 +1000,9 @@ complete:
stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
if (ret < 0) {
err |= OMAP_I2C_STAT_XUDF;
- goto complete;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF |
+ OMAP_I2C_STAT_XRDY);
+ omap_i2c_complete_cmd(dev, err);
}
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XRDY);
--
1.7.10.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
[rft/rfc/patch 13/22] i2c: omap: if controller is suspended, bail out
same check we had on the threaded IRQ handler, copy it to the bottom half. Signed-off-by: Felipe Balbi --- drivers/i2c/busses/i2c-omap.c |3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c index 9dadfb1..e555681 100644 --- a/drivers/i2c/busses/i2c-omap.c +++ b/drivers/i2c/busses/i2c-omap.c @@ -871,6 +871,9 @@ omap_i2c_isr(int irq, void *_dev) u16 stat; u16 bits; + if (pm_runtime_suspended(dev->dev)) + return IRQ_NONE; + stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG); bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG); -- 1.7.10.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
[rft/rfc/patch 11/22] i2c: omap: get rid of "count" variable
now that we're running on a thread, there's
no problem in doing lots of work as IRQs won't
be disabled anymore.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 10 ++
1 file changed, 2 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 6e0b406..dba174c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -886,7 +886,7 @@ omap_i2c_threaded_isr(int this_irq, void *dev_id)
struct omap_i2c_dev *dev = dev_id;
u16 bits;
u16 stat;
- int err = 0, count = 0;
+ int err = 0;
if (pm_runtime_suspended(dev->dev))
return IRQ_NONE;
@@ -903,12 +903,6 @@ omap_i2c_threaded_isr(int this_irq, void *dev_id)
}
dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
- if (count++ == 100) {
- dev_warn(dev->dev, "Too much work in one IRQ\n");
- omap_i2c_complete_cmd(dev, err);
- return IRQ_HANDLED;
- }
-
complete:
if (stat & OMAP_I2C_STAT_NACK) {
dev_err(dev->dev, "No Acknowledge\n");
@@ -1028,7 +1022,7 @@ complete:
}
} while (stat);
- return count ? IRQ_HANDLED : IRQ_NONE;
+ return IRQ_HANDLED;
}
static const struct i2c_algorithm omap_i2c_algo = {
--
1.7.10.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
[rft/rfc/patch 10/22] i2c: omap: switch I2C REV2 to threaded IRQ
that way all our IRQ handling will happen in
thread.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index a9c1fa6..6e0b406 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -865,7 +865,23 @@ static int omap_i2c_transmit_data(struct omap_i2c_dev
*dev, u8 num_bytes,
}
static irqreturn_t
-omap_i2c_isr(int this_irq, void *dev_id)
+omap_i2c_isr(int irq, void *_dev)
+{
+ struct omap_i2c_dev *dev = _dev;
+ u16 stat;
+ u16 bits;
+
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
+
+ if (stat & bits)
+ return IRQ_WAKE_THREAD;
+
+ return IRQ_HANDLED;
+}
+
+static irqreturn_t
+omap_i2c_threaded_isr(int this_irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
u16 bits;
@@ -1055,7 +1071,6 @@ omap_i2c_probe(struct platform_device *pdev)
struct omap_i2c_bus_platform_data *pdata = pdev->dev.platform_data;
struct device_node *node = pdev->dev.of_node;
const struct of_device_id *match;
- irq_handler_t isr;
int r;
/* NOTE: driver uses the static register mapping */
@@ -1155,9 +1170,12 @@ omap_i2c_probe(struct platform_device *pdev)
/* reset ASAP, clearing any IRQs */
omap_i2c_init(dev);
- isr = (dev->rev < OMAP_I2C_OMAP1_REV_2) ? omap_i2c_omap1_isr :
- omap_i2c_isr;
- r = request_irq(dev->irq, isr, 0, pdev->name, dev);
+ if (dev->rev < OMAP_I2C_OMAP1_REV_2)
+ r = request_irq(dev->irq, omap_i2c_omap1_isr, 0,
+ pdev->name, dev);
+ else
+ r = request_threaded_irq(dev->irq, omap_i2c_isr,
+ omap_i2c_threaded_isr, 0, pdev->name, dev);
if (r) {
dev_err(dev->dev, "failure requesting irq %i\n", dev->irq);
--
1.7.10.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
[rft/rfc/patch 06/22] i2c: omap: improve 1p153 errata handling
Make it not depend on ISR's local variables
in order to make it easier to re-factor the
transmit data loop.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 47 +
1 file changed, 34 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9e6be9f..d53ec25 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -768,21 +768,24 @@ omap_i2c_omap1_isr(int this_irq, void *dev_id)
* data to DATA_REG. Otherwise some data bytes can be lost while transferring
* them from the memory to the I2C interface.
*/
-static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16 *stat, int *err)
+static int errata_omap3_1p153(struct omap_i2c_dev *dev)
{
- unsigned long timeout = 1;
+ unsigned long timeout = 1;
+ u16 stat;
- while (--timeout && !(*stat & OMAP_I2C_STAT_XUDF)) {
- if (*stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
+ do {
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ if (stat & OMAP_I2C_STAT_XUDF)
+ break;
+
+ if (stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
- *err |= OMAP_I2C_STAT_XUDF;
return -ETIMEDOUT;
}
cpu_relax();
- *stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
- }
+ } while (--timeout);
if (!timeout) {
dev_err(dev->dev, "timeout waiting on XUDF bit\n");
@@ -956,9 +959,18 @@ complete:
}
}
- if ((dev->errata & I2C_OMAP3_1P153) &&
- errata_omap3_1p153(dev, &stat, &err))
- goto complete;
+ if (dev->errata & I2C_OMAP3_1P153) {
+ int ret;
+
+ ret = errata_omap3_1p153(dev);
+ stat = omap_i2c_read_reg(dev,
+ OMAP_I2C_STAT_REG);
+
+ if (ret < 0) {
+ err |= OMAP_I2C_STAT_XUDF;
+ goto complete;
+ }
+ }
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
@@ -996,9 +1008,18 @@ complete:
}
}
- if ((dev->errata & I2C_OMAP3_1P153) &&
- errata_omap3_1p153(dev, &stat, &err))
- goto complete;
+ if (dev->errata & I2C_OMAP3_1P153) {
+ int ret;
+
+ ret = errata_omap3_1p153(dev);
+ stat = omap_i2c_read_reg(dev,
+ OMAP_I2C_STAT_REG);
+
+ if (ret < 0) {
+ err |= OMAP_I2C_STAT_XUDF;
+ goto complete;
+ }
+ }
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
--
1.7.10.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
[rft/rfc/patch 09/22] i2c: omap: ack IRQ in parts
According to flow diagrams on OMAP TRMs,
we should ACK the IRQ as they happen.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index cf13a3e..a9c1fa6 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -894,21 +894,20 @@ omap_i2c_isr(int this_irq, void *dev_id)
}
complete:
- /*
-* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
-* acked after the data operation is complete.
-* Ref: TRM SWPU114Q Figure 18-31
-*/
- omap_i2c_write_reg(dev, OMAP_I2C_STAT_REG, stat &
- ~(OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR));
-
- if (stat & OMAP_I2C_STAT_NACK)
+ if (stat & OMAP_I2C_STAT_NACK) {
+ dev_err(dev->dev, "No Acknowledge\n");
err |= OMAP_I2C_STAT_NACK;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
+ }
if (stat & OMAP_I2C_STAT_AL) {
dev_err(dev->dev, "Arbitration lost\n");
err |= OMAP_I2C_STAT_AL;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_NACK);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
/*
@@ -999,11 +998,17 @@ complete:
if (stat & OMAP_I2C_STAT_ROVR) {
dev_err(dev->dev, "Receive overrun\n");
dev->cmd_err |= OMAP_I2C_STAT_ROVR;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_ROVR);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
if (stat & OMAP_I2C_STAT_XUDF) {
dev_err(dev->dev, "Transmit underflow\n");
dev->cmd_err |= OMAP_I2C_STAT_XUDF;
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_XUDF);
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
} while (stat);
--
1.7.10.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
[rft/rfc/patch 08/22] i2c: omap: switch over to do {} while loop
this will make sure that we execute at least once.
No functional changes otherwise.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 3d714a0c..cf13a3e 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -870,20 +870,29 @@ omap_i2c_isr(int this_irq, void *dev_id)
struct omap_i2c_dev *dev = dev_id;
u16 bits;
u16 stat;
- int err, count = 0;
+ int err = 0, count = 0;
if (pm_runtime_suspended(dev->dev))
return IRQ_NONE;
- bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
- while ((stat = (omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG))) & bits) {
+ do {
+ bits = omap_i2c_read_reg(dev, OMAP_I2C_IE_REG);
+ stat = omap_i2c_read_reg(dev, OMAP_I2C_STAT_REG);
+ stat &= bits;
+
+ if (!stat) {
+ /* my work here is done */
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
+ }
+
dev_dbg(dev->dev, "IRQ (ISR = 0x%04x)\n", stat);
if (count++ == 100) {
dev_warn(dev->dev, "Too much work in one IRQ\n");
- break;
+ omap_i2c_complete_cmd(dev, err);
+ return IRQ_HANDLED;
}
- err = 0;
complete:
/*
* Ack the stat in one go, but [R/X]DR and [R/X]RDY should be
@@ -996,7 +1005,7 @@ complete:
dev_err(dev->dev, "Transmit underflow\n");
dev->cmd_err |= OMAP_I2C_STAT_XUDF;
}
- }
+ } while (stat);
return count ? IRQ_HANDLED : IRQ_NONE;
}
--
1.7.10.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
[rft/rfc/patch 07/22] i2c: omap: re-factor receive/transmit data loop
re-factor the common parts to a separate function,
so that code is easier to read and understand.
No functional changes.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 209 +
1 file changed, 84 insertions(+), 125 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index d53ec25..3d714a0c 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -795,12 +795,81 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev)
return 0;
}
+static void omap_i2c_receive_data(struct omap_i2c_dev *dev, u8 num_bytes,
+ bool is_rdr)
+{
+ u16 w;
+
+ while (num_bytes--) {
+ if (!dev->buf_len) {
+ dev_err(dev->dev, "%s without data",
+ is_rdr ? "RDR" : "RRDY");
+ break;
+ }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev->buf++ = w;
+ dev->buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags & OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ *dev->buf++ = w >> 8;
+ dev->buf_len--;
+ }
+ }
+ }
+}
+
+static int omap_i2c_transmit_data(struct omap_i2c_dev *dev, u8 num_bytes,
+ bool is_xdr)
+{
+ u16 w;
+
+ while (num_bytes--) {
+ if (!dev->buf_len) {
+ dev_err(dev->dev, "%s without data",
+ is_xdr ? "XDR" : "XRDY");
+ break;
+ }
+
+ w = *dev->buf++;
+ dev->buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags & OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ w |= *dev->buf++ << 8;
+ dev->buf_len--;
+ }
+ }
+
+ if (dev->errata & I2C_OMAP3_1P153) {
+ int ret;
+
+ ret = errata_omap3_1p153(dev);
+ if (ret < 0)
+ return ret;
+ }
+
+ omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
+ }
+
+ return 0;
+}
+
static irqreturn_t
omap_i2c_isr(int this_irq, void *dev_id)
{
struct omap_i2c_dev *dev = dev_id;
u16 bits;
- u16 stat, w;
+ u16 stat;
int err, count = 0;
if (pm_runtime_suspended(dev->dev))
@@ -860,31 +929,7 @@ complete:
num_bytes &= 0x3f;
}
- while (num_bytes--) {
- if (!dev->buf_len) {
- dev_err(dev->dev,
- "RDR IRQ while no data"
- " requested\n");
- break;
- }
-
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- *dev->buf++ = w;
- dev->buf_len--;
-
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev->flags &
- OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev->buf_len) {
- *dev->buf++ = w >> 8;
- dev->buf_len--;
- }
- }
- }
-
+ omap_i2c_receive_data(dev, num_bytes, true);
omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
continue;
}
@@ -898,36 +943,13 @@ complete:
if (dev->fifo_size)
num_bytes = dev->fifo_size;
- while (num_bytes--) {
- if (!dev->buf_len) {
- dev_err(dev->dev,
- "RRDY IRQ while no data"
- " requested\n");
- break;
- }
-
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
-
[rft/rfc/patch 05/22] i2c: omap: split out [XR]DR and [XR]RDY
While they do pretty much the same thing, there
are a few peculiarities. Specially WRT erratas,
it's best to split those out and re-factor the
read/write loop to another function which both
cases call.
This last part will be done on another patch.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 130 +++--
1 file changed, 99 insertions(+), 31 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index fa9ddb6..9e6be9f 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -844,36 +844,31 @@ complete:
return IRQ_HANDLED;
}
- if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
+ if (stat & OMAP_I2C_STAT_RDR) {
u8 num_bytes = 1;
if (dev->errata & I2C_OMAP_ERRATA_I207)
i2c_omap_errata_i207(dev, stat);
if (dev->fifo_size) {
- if (stat & OMAP_I2C_STAT_RRDY)
- num_bytes = dev->fifo_size;
- else/* read RXSTAT on RDR interrupt */
- num_bytes = (omap_i2c_read_reg(dev,
- OMAP_I2C_BUFSTAT_REG)
- >> 8) & 0x3F;
+ num_bytes = omap_i2c_read_reg(dev,
+ OMAP_I2C_BUFSTAT_REG);
+ num_bytes >>= 8;
+ num_bytes &= 0x3f;
}
+
while (num_bytes--) {
if (!dev->buf_len) {
- if (stat & OMAP_I2C_STAT_RRDY)
- dev_err(dev->dev,
- "RRDY IRQ while no data"
- " requested\n");
- if (stat & OMAP_I2C_STAT_RDR)
- dev_err(dev->dev,
+ dev_err(dev->dev,
"RDR IRQ while no data"
- " requested\n");
+ " requested\n");
break;
}
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
*dev->buf++ = w;
dev->buf_len--;
+
/*
* Data reg in 2430, omap3 and
* omap4 is 8 bit wide
@@ -886,29 +881,61 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
- OMAP_I2C_STAT_RDR));
+
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RDR);
+ continue;
+ }
+
+ if (stat & OMAP_I2C_STAT_RRDY) {
+ u8 num_bytes = 1;
+
+ if (dev->errata & I2C_OMAP_ERRATA_I207)
+ i2c_omap_errata_i207(dev, stat);
+
+ if (dev->fifo_size)
+ num_bytes = dev->fifo_size;
+
+ while (num_bytes--) {
+ if (!dev->buf_len) {
+ dev_err(dev->dev,
+ "RRDY IRQ while no data"
+ " requested\n");
+ break;
+ }
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev->buf++ = w;
+ dev->buf_len--;
+
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags &
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ *dev->buf++ = w >> 8;
+ dev->buf_len--;
+ }
+ }
+ }
+
+ omap_i2c_ack_stat(dev, OMAP_I2C_STAT_RRDY);
continue;
}
[rft/rfc/patch 04/22] i2c: omap: simplify omap_i2c_ack_stat()
stat & BIT(1) is the same as BIT(1), so let's
simplify things a bit by removing "stat &" from
all omap_i2c_ack_stat() calls.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 07ae391..fa9ddb6 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -774,8 +774,8 @@ static int errata_omap3_1p153(struct omap_i2c_dev *dev, u16
*stat, int *err)
while (--timeout && !(*stat & OMAP_I2C_STAT_XUDF)) {
if (*stat & (OMAP_I2C_STAT_NACK | OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, *stat & (OMAP_I2C_STAT_XRDY |
- OMAP_I2C_STAT_XDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR));
*err |= OMAP_I2C_STAT_XUDF;
return -ETIMEDOUT;
}
@@ -835,10 +835,11 @@ complete:
*/
if (stat & (OMAP_I2C_STAT_ARDY | OMAP_I2C_STAT_NACK |
OMAP_I2C_STAT_AL)) {
- omap_i2c_ack_stat(dev, stat &
- (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR |
- OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR |
- OMAP_I2C_STAT_ARDY));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR |
+ OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR |
+ OMAP_I2C_STAT_ARDY));
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
@@ -885,8 +886,8 @@ complete:
}
}
}
- omap_i2c_ack_stat(dev,
- stat & (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_RRDY |
+ OMAP_I2C_STAT_RDR));
continue;
}
@@ -933,8 +934,8 @@ complete:
omap_i2c_write_reg(dev, OMAP_I2C_DATA_REG, w);
}
- omap_i2c_ack_stat(dev,
- stat & (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
+ omap_i2c_ack_stat(dev, (OMAP_I2C_STAT_XRDY |
+ OMAP_I2C_STAT_XDR));
continue;
}
--
1.7.10.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
[rft/rfc/patch 02/22] i2c: omap: decrease indentation level on data handling
trivial patch, no functional changes.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c | 63 -
1 file changed, 31 insertions(+), 32 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 9b532cd..39d5583 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -856,22 +856,7 @@ complete:
>> 8) & 0x3F;
}
while (num_bytes--) {
- w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
- if (dev->buf_len) {
- *dev->buf++ = w;
- dev->buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev->flags &
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev->buf_len) {
- *dev->buf++ = w >> 8;
- dev->buf_len--;
- }
- }
- } else {
+ if (!dev->buf_len) {
if (stat & OMAP_I2C_STAT_RRDY)
dev_err(dev->dev,
"RRDY IRQ while no data"
@@ -882,6 +867,21 @@ complete:
" requested\n");
break;
}
+
+ w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
+ *dev->buf++ = w;
+ dev->buf_len--;
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags &
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ *dev->buf++ = w >> 8;
+ dev->buf_len--;
+ }
+ }
}
omap_i2c_ack_stat(dev,
stat & (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
@@ -898,22 +898,7 @@ complete:
& 0x3F;
}
while (num_bytes--) {
- w = 0;
- if (dev->buf_len) {
- w = *dev->buf++;
- dev->buf_len--;
- /*
-* Data reg in 2430, omap3 and
-* omap4 is 8 bit wide
-*/
- if (dev->flags &
-OMAP_I2C_FLAG_16BIT_DATA_REG) {
- if (dev->buf_len) {
- w |= *dev->buf++ << 8;
- dev->buf_len--;
- }
- }
- } else {
+ if (!dev->buf_len) {
if (stat & OMAP_I2C_STAT_XRDY)
dev_err(dev->dev,
"XRDY IRQ while no "
@@ -925,6 +910,20 @@ complete:
break;
}
+ w = *dev->buf++;
+ dev->buf_len--;
+ /*
+* Data reg in 2430, omap3 and
+* omap4 is 8 bit wide
+*/
+ if (dev->flags &
+ OMAP_I2C_FLAG_16BIT_DATA_REG) {
+ if (dev->buf_len) {
+ w |= *dev->buf++ << 8;
+ dev->buf_len--;
+
[rft/rfc/patch 03/22] i2c: omap: add blank lines
trivial patch to aid readability. No functional
changes.
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c |5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 39d5583..07ae391 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -829,6 +829,7 @@ complete:
dev_err(dev->dev, "Arbitration lost\n");
err |= OMAP_I2C_STAT_AL;
}
+
/*
* ProDB0017052: Clear ARDY bit twice
*/
@@ -841,6 +842,7 @@ complete:
omap_i2c_complete_cmd(dev, err);
return IRQ_HANDLED;
}
+
if (stat & (OMAP_I2C_STAT_RRDY | OMAP_I2C_STAT_RDR)) {
u8 num_bytes = 1;
@@ -887,6 +889,7 @@ complete:
stat & (OMAP_I2C_STAT_RRDY |
OMAP_I2C_STAT_RDR));
continue;
}
+
if (stat & (OMAP_I2C_STAT_XRDY | OMAP_I2C_STAT_XDR)) {
u8 num_bytes = 1;
if (dev->fifo_size) {
@@ -934,10 +937,12 @@ complete:
stat & (OMAP_I2C_STAT_XRDY |
OMAP_I2C_STAT_XDR));
continue;
}
+
if (stat & OMAP_I2C_STAT_ROVR) {
dev_err(dev->dev, "Receive overrun\n");
dev->cmd_err |= OMAP_I2C_STAT_ROVR;
}
+
if (stat & OMAP_I2C_STAT_XUDF) {
dev_err(dev->dev, "Transmit underflow\n");
dev->cmd_err |= OMAP_I2C_STAT_XUDF;
--
1.7.10.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
[rft/rfc/patch 01/22] i2c: omap: simplify num_bytes handling
trivial patch, no functional changes
Signed-off-by: Felipe Balbi
---
drivers/i2c/busses/i2c-omap.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-omap.c b/drivers/i2c/busses/i2c-omap.c
index 801df60..9b532cd 100644
--- a/drivers/i2c/busses/i2c-omap.c
+++ b/drivers/i2c/busses/i2c-omap.c
@@ -855,8 +855,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
>> 8) & 0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = omap_i2c_read_reg(dev, OMAP_I2C_DATA_REG);
if (dev->buf_len) {
*dev->buf++ = w;
@@ -898,8 +897,7 @@ complete:
OMAP_I2C_BUFSTAT_REG)
& 0x3F;
}
- while (num_bytes) {
- num_bytes--;
+ while (num_bytes--) {
w = 0;
if (dev->buf_len) {
w = *dev->buf++;
--
1.7.10.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
[rft/rfc/patch 00/22] Big I2C cleanup
First of all, this isn't fully tested yet. I can
see some issues poping up after this patchset which
I'm not sure if it's a race condition somewhere or
the HW is just misbehaving.
All in all, the IRQ handler looks cleaner now. There's
still lots of things to be done and before I'm going any
further, I'd like help testing this patchset.
Note that on multiple boots you might face some issues
with the XDR IRQ which aparently keeps getting retriggered
even though it gets acked and properly cleared. I didn't
look yet if there's an errata for that.
I'll give myself a break of the I2C driver because it's
just driving me nuts already. If you have the balls to
look over the unfinished patches (see that there are
a few patches which could be combined, will do that later)
and help out testing, reviewing, commenting...
Next steps (after this set is done) would be to get rid
of that stupid, nonsensical FIFO clear before starting
every transfer, fix up NAK handling, clean up debugging
messages, figure out why sometimes IRQs don't fire (AKA
"controller timed out" crap) and lots more.
For convenience it's also located on the following git
branch:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git i2c
ps: boot tested on OMAP4 Panda. When it boots fine, it's actually
quite stable, I managed to do many transfers with the PMIC (checking
regulators' state) and it works very reliably (while true; cat
/sys/class/regulators/*/state; done works fine for multiple iterations);
Felipe Balbi (22):
i2c: omap: simplify num_bytes handling
i2c: omap: decrease indentation level on data handling
i2c: omap: add blank lines
i2c: omap: simplify omap_i2c_ack_stat()
i2c: omap: split out [XR]DR and [XR]RDY
i2c: omap: improve 1p153 errata handling
i2c: omap: re-factor receive/transmit data loop
i2c: omap: switch over to do {} while loop
i2c: omap: ack IRQ in parts
i2c: omap: switch I2C REV2 to threaded IRQ
i2c: omap: get rid of "count" variable
i2c: omap: get rid of the "complete" label
i2c: omap: if controller is suspended, bail out
i2c: omap: ack ARDY IRQ
i2c: omap: switch to devm_* API
i2c: omap: switch to platform_get_irq()
i2c: omap: drop Access Ready IRQ
i2c: omap: drop errata i207 from RRDY interrupt
i2c: omap: bus: add a receiver flag
i2c: omap: avoid unnecessary register read
i2c: omap: no need to reinitialize "stat"
i2c: omap: simplify errata check
drivers/i2c/busses/i2c-omap.c | 386 +++--
1 file changed, 216 insertions(+), 170 deletions(-)
--
1.7.10.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 v5 10/14] ARM: OMAP2+: gpmc: waitpin helper
Hi Afzal, On 06/13/2012 02:37 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 23:45:36, Hunter, Jon wrote: > >> GPMC_WAITPIN_IDX0 = 0 >> GPMC_WAITPIN_0 = 1 >> >> So, GPMC_WAITPIN_IDX0 = GPMC_WAITPIN_0 - 1, assuming that you want idx = >> 0 and not 1. Or you could change you shift value too. I was just >> highlighting that they are not equal but one set of definitions could be >> used. > > In that case we would be directly depending on user flag whose value may > or may not change and I don't think it is good to directly depend on it > for waitpin # calculation. You are already dependent on it. In other words, you are going to set the waitpin # according to these flags in the first place. I don't see the difference. Bottom line is that we don't need to have multiple definitions for the same thing. 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 v5 06/14] ARM: OMAP2+: gpmc: CS configuration helper
Hi Afzal, On 06/13/2012 12:50 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 23:39:32, Hunter, Jon wrote: >> On 06/12/2012 07:58 AM, Mohammed, Afzal wrote: > >>> Thinking again over it, I am feeling above is sufficient, reason same as >>> said earlier, to keep code simple & currently this is sufficient to >>> handle GPMC bit patterns for IPs presently available. What you are >>> suggesting is to take care of the imaginary case when new GPMC IP happens >>> with new device type or size, I think that should be handled when such a >>> scenario happens. Probably, it is better here to add a comment to make >>> intention clear. >> >> That is one possibility but I think that more important reasons are ... >> >> 1. Readability, at first it appears that we are always configuring the >> CS for NAND. However, this is not the case. Maybe a comment here can >> help as you mentioned. > > As far as the users of GPMC is considered there is no confusion. Eg. For > device type, they have been provided with two macros, > > GPMC_CONFIG1_DEVICETYPE_NOR, GPMC_CONFIG1_DEVICETYPE_NAND > > So for NOR, user can feel satisfied by giving NOR flag, little does he know > that driver doesn't do anything with the flag, but he still gets what he want > NOR flag is defined as zero. Yes even if he doesn't specify any type, device > type will be set as NOR, but then that is the default - the only other option Sure, but reviewing the function it still looks odd from a readability standpoint. At least it made me think "what is going on here ...". So a comment is definitely needed. >> >> 2. A bad setting in the configuration passed. Hopefully, people will >> stick to the flags but we know that we expect the device type to be a 0 >> or 2 and so should we check? > > Value of device type is something driver has to worry about, not its users, > they have been provided with two flags, one for NAND & other for NOR. Yes, but the driver does not seem to worry about it. In other words, there is no error checking. Ok so not a big deal a comment should suffice. 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 v5 05/14] ARM: OMAP2+: gpmc: resource creation helpers
Hi Afzal, On 06/13/2012 12:29 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 23:32:05, Hunter, Jon wrote: > >> Well looking at the function it seems that you either return an error >> code or 1. So if you are never going to return anything other than 1 on >> success it may as well be 0. > > Irq & memory resource creation functions returns number of resources, > if memory function only is modified, that will cause loss of uniformity > w.r.t irq function, even though both does similar things. Ok, I see what you mean but from a readability standpoint it looked odd. The other function is returning "n" where as this is just returning 1 on success but it is not clear that this actually means 1 resource. 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 v5 11/14] ARM: OMAP2+: gpmc: handle connected peripherals
Hi Afzal,
On 06/11/2012 09:27 AM, Afzal Mohammed wrote:
> Platform will provide driver with configuration details for
> each CS like configuration, timing, interrupts. Setup GPMC
> based on it. Platform data also provides platform data &
> resources used for connected peripheral (eg. gpio irq).
> GPMC driver tunnels those information to respective driver.
>
> Signed-off-by: Afzal Mohammed
> ---
> arch/arm/mach-omap2/gpmc.c | 146
>
> 1 file changed, 146 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> index 9073a8a..281bd23 100644
> --- a/arch/arm/mach-omap2/gpmc.c
> +++ b/arch/arm/mach-omap2/gpmc.c
> @@ -155,6 +155,8 @@ struct gpmc_peripheral {
> struct platform_device *pdev;
> };
>
> +static struct gpmc_peripheral gpmc_peripheral[GPMC_CS_NUM];
> +static unsigned gpmc_num_peripheral;
> static unsigned gpmc_waitpin_map;
>
> static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
> @@ -1235,6 +1237,39 @@ static int gpmc_setup_cs_waitpin(struct
> gpmc_peripheral *g_per, unsigned cs,
> return 0;
> }
>
> +static int gpmc_setup_cs_config_timing(struct gpmc_peripheral *g_per,
> + struct gpmc_cs_data *cs)
> +{
> + int ret;
> +
> + /* some boards rely on bootloader for configuration */
> + if (cs->have_config) {
> + gpmc_setup_cs_config(cs->cs, cs->config);
> + ret = gpmc_setup_cs_waitpin(g_per, cs->cs, cs->config);
> + if (IS_ERR_VALUE(ret)) {
> + dev_err(gpmc_dev, "error: waitpin on CS %d\n", cs->cs);
> + return ret;
> + }
> + } else
> + gpmc_print_cs_config(cs->cs);
> +
> + /* some boards rely on bootloader for timing */
> + if (cs->time_ctrl.type == has_period) {
> + ret = gpmc_cs_set_timings(cs->cs, &cs->time_ctrl.timings);
> + if (IS_ERR_VALUE(ret)) {
> + dev_err(gpmc_dev, "error: timing on CS: %d\n", cs->cs);
> + return ret;
> + }
> + gpmc_cs_misc_timings(cs->cs, &cs->time_ctrl.bool_timings);
> + } else if (cs->time_ctrl.type == has_clock) {
> + gpmc_cs_set_register_timings(cs->cs, &cs->time_ctrl.timings);
> + gpmc_cs_misc_timings(cs->cs, &cs->time_ctrl.bool_timings);
> + } else
> + gpmc_print_cs_timings(cs->cs);
> +
> + return 0;
> +}
> +
> static inline unsigned gpmc_bit_to_irq(unsigned bitmask)
> {
> return bitmask;
> @@ -1307,10 +1342,100 @@ static int gpmc_setup_waitpin(struct gpmc_peripheral
> *g_per)
> return 0;
> }
>
> +static __devinit int gpmc_setup_cs(struct gpmc_peripheral *g_per,
> + struct gpmc_cs_data *cs, struct resource *res)
> +{
> + int num, ret;
> +
> + num = gpmc_setup_cs_mem(cs, res);
> + if (IS_ERR_VALUE(num))
> + return num;
> +
> + ret = gpmc_setup_cs_config_timing(g_per, cs);
> + if (IS_ERR_VALUE(ret))
> + return ret;
> +
> + num += gpmc_setup_cs_irq(cs, res + num);
What happens if the above function returns an error?
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: [PATCHv3 03/20] ARM: OMAP4: PM: add support for device off
Hi Tero,
I have a few remarks regarding the genericity of this code. I think it
is better if the code in powerdomain.c stays generic and that the
platform specific checks and operations be moved in the specific
functions (via the pwrdm_ops struct).
On Tue, Jun 12, 2012 at 5:31 PM, Tero Kristo wrote:
> On OMAP4+, device wide off-mode has its own enable mechanism in addition
> to powerdomain target states. This patch adds support for this on top
> of functional power states by overloading the OFF state for core pwrdm.
> On pwrdm level, the deepest power state supported by core pwrdm is OSWR.
> When user (e.g. suspend) programs core pwrdm target as OFF, the functional
> power state for the domain will be OSWR with the additional device off
> enabled. Previous power state information will reflect this also.
>
> Signed-off-by: Tero Kristo
> ---
> arch/arm/mach-omap2/powerdomain.c | 17 +
> arch/arm/mach-omap2/powerdomain.h | 13 +++-
> arch/arm/mach-omap2/powerdomain44xx.c | 48
> +++
> arch/arm/mach-omap2/powerdomains44xx_data.c | 3 +-
> 4 files changed, 79 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/powerdomain.c
> b/arch/arm/mach-omap2/powerdomain.c
> index ac63f86..78a9308 100644
> --- a/arch/arm/mach-omap2/powerdomain.c
> +++ b/arch/arm/mach-omap2/powerdomain.c
> @@ -677,6 +677,8 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
> func_pwrst)
> int sleep_switch = -1, ret = 0, hwsup = 0;
> int new_func_pwrst, next_func_pwrst, pwrst, logic;
> u8 curr_pwrst;
> + bool extra_off_enable = false;
> + bool has_extra_off = false;
>
> if (!pwrdm || IS_ERR(pwrdm)) {
> pr_debug("%s: invalid params: pwrdm=%p\n", __func__, pwrdm);
> @@ -687,6 +689,13 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
> func_pwrst)
>
> mutex_lock(&pwrdm->lock);
>
> + /* Check if powerdomain has extra off mode handling */
> + if (pwrdm->flags & PWRDM_HAS_EXTRA_OFF_ENABLE) {
> + has_extra_off = true;
> + if (func_pwrst == PWRDM_FUNC_PWRST_OFF)
> + extra_off_enable = true;
> + }
Could those checks be moved in the OMAP4 specific functions, so that
the power domain code stays generic?
> +
> new_func_pwrst = pwrdm_get_achievable_func_pwrst(pwrdm, func_pwrst);
> pwrst = pwrdm_func_to_pwrst(pwrdm, new_func_pwrst);
> logic = pwrdm_func_to_logic_pwrst(pwrdm, new_func_pwrst);
> @@ -741,6 +750,9 @@ int omap_set_pwrdm_state(struct powerdomain *pwrdm, u32
> func_pwrst)
> break;
> }
>
> + if (has_extra_off && arch_pwrdm->pwrdm_enable_off)
> + arch_pwrdm->pwrdm_enable_off(pwrdm, extra_off_enable);
> +
> out:
> mutex_unlock(&pwrdm->lock);
> return ret;
> @@ -810,6 +822,11 @@ int pwrdm_read_next_func_pwrst(struct powerdomain *pwrdm)
> int next_pwrst = pwrdm_read_next_pwrst(pwrdm);
> int next_logic = pwrdm_read_logic_retst(pwrdm);
>
> + if (pwrdm->flags & PWRDM_HAS_EXTRA_OFF_ENABLE &&
> + arch_pwrdm->pwrdm_read_next_off &&
> + arch_pwrdm->pwrdm_read_next_off(pwrdm))
> + return PWRDM_FUNC_PWRST_OFF;
> +
Same comment here. The OMAP4 specific function for
pwrdm_read_next_pwrst could return PWRDM_FUNC_PWRST_OFF.
> return pwrdm_pwrst_to_func(pwrdm, next_pwrst, next_logic);
> }
>
> diff --git a/arch/arm/mach-omap2/powerdomain.h
> b/arch/arm/mach-omap2/powerdomain.h
> index 0729d91..cc30b94 100644
> --- a/arch/arm/mach-omap2/powerdomain.h
> +++ b/arch/arm/mach-omap2/powerdomain.h
> @@ -75,6 +75,13 @@
> * state without waking up the
> * powerdomain
> */
> +/*
> + * OMAP4+ has device off feature, which must be enabled separately in
> + * addition to power domain next state setup. This feature is overloaded
> + * as EXTRA_OFF_ENABLE for core_pwrdm, and is implemented on top of
> + * functional power state
> + */
> +#define PWRDM_HAS_EXTRA_OFF_ENABLE (1 << 3)
>
> /*
> * Number of memory banks that are power-controllable. On OMAP4430, the
> @@ -173,7 +180,9 @@ struct powerdomain {
> * @pwrdm_disable_hdwr_sar: Disable Hardware Save-Restore feature for a pd
> * @pwrdm_set_lowpwrstchange: Enable pd transitions from a shallow to deep
> sleep
> * @pwrdm_wait_transition: Wait for a pd state transition to complete
> - * @pwrdm_lost_context_rff: Check if pd has lost RFF context (entered off)
> + * @pwrdm_lost_context_rff: Check if pd has lost RFF context (omap4+ device
> off)
> + * @pwrdm_enable_off: Extra off mode enable for pd (omap4+ device off)
> + * @pwrdm_read_next_off: Check if pd next state is off (omap4+ device off)
> */
> struct pwrdm_ops {
> int (*pwrdm_func_to_pwrst)(struct powerdomain *pwrdm, u8
> func_pwrs
Re: [PATCH v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Afzal, On 06/13/2012 08:05 AM, Mohammed, Afzal wrote: > Hi Tony, > > On Wed, Jun 13, 2012 at 17:32:09, Tony Lindgren wrote: >> * Mohammed, Afzal [120612 22:24]: >>> Hi Jon, >>> >>> On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote: > Right but potentially, this could be done by the driver. >>> >>> I do not think it is practically possible. Please see timing calculations >>> in arch/arm/mach-omap2/gpmc-*, the way it is done for different >>> peripherals are different, and we cannot expect gpmc driver to do those as >>> that would require gpmc driver being aware of type of peripheral connected. >>> >>> And all those gpmc-* timing calculation needs to be done before driver >>> is ready, they rely on functions like gpmc_get_fclk_rate(), which in turn >>> requires the clk rate to be available before driver is probed. >> >> Yeah I also think the GPMC code should handle the L3 timings, and dynamically >> calculate them for DVFS when L3 frequency changes. Does the GPMC have enough >> information now to do that? > > Do you mean that gpmc driver should have the capability to calculate > peripheral > timings at runtime based on frequency ?, I am not sure how this can be handled > by gpmc driver as calculation for different peripherals are done in different > way, requiring gpmc driver to know about connected peripheral, that would > imply > that gpmc driver would not be peripheral agnostic. I guess I still don't agree with this. From the gpmc timing point of view it should not care what device is connected, it just needs to know the associated timings. Therefore, the gpmc driver just needs the time associated with the different timings fields in the various GPMC_CONFIGx registers and then convert to clocks based upon the gpmc fclk. The only item that is device specific here is the actual timing values and these can be passed to the driver. Furthermore, gpmc_cs_set_timings function is completely device agnostic. Why can we not call this from within the driver? Why does it need to be called outside the driver? I am looking for you to prove me wrong about this, but if the only reason is because we need to fclk rate and timings, then as I have mentioned before we can pass these to the driver. So I am looking for a stronger reason than this of why this would not work. 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 v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Afzal, On 06/13/2012 12:20 AM, Mohammed, Afzal wrote: > Hi Jon, > > On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote: >> On 06/12/2012 01:53 AM, Mohammed, Afzal wrote: >>> On Tue, Jun 12, 2012 at 01:26:29, Hunter, Jon wrote: > My preference would be to store gpmc_l3_clk in the pdata and pass to probe via the pdata. The aim would be to remove the global gpmc_l3_clk altogether. >>> >>> For timing calculation by platform outside of driver, we need clk rate >> >> Right but potentially, this could be done by the driver. > > I do not think it is practically possible. Please see timing calculations > in arch/arm/mach-omap2/gpmc-*, the way it is done for different > peripherals are different, and we cannot expect gpmc driver to do those as > that would require gpmc driver being aware of type of peripheral connected. > > And all those gpmc-* timing calculation needs to be done before driver > is ready, they rely on functions like gpmc_get_fclk_rate(), which in turn > requires the clk rate to be available before driver is probed. So I see that the various gpmc-*.c files have some form of _retime() function. However, at the end of the day they all call gpmc_cs_set_timings() to convert time into gpmc clocks. Converting time to gpmc clocks is completely independent of the actual device and so this can be performed by the driver. We just need to populate the gpmc_timings struct and pass to the driver to convert to clocks and program into the registers. If the clk handle for the gpmc is passed to the gpmc driver, then there is no reason why the driver cannot do this. Obviously, I could be missing something fundamental here, but my assumption is that if the driver has the handle the fclk (and hence can query the clock rate) and has then gpmc_timings struct (with timings in time), then that is all it needs. 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: [RFC PATCH 0/3] usb: musb: add new phy driver
Hi, On Tue, Jun 12, 2012 at 4:18 PM, Felipe Balbi wrote: > On Wed, May 30, 2012 at 08:04:23PM +0530, Kishon Vijay Abraham I wrote: >> This series adds a new usb2 phy driver. The device for which is created >> by the ocp2scp driver. This also uses control module driver. >> >> This series converts twl6030 as a comparator driver (previously it was >> also the phy driver) and makes use of omap-usb2 as the phy driver. >> >> Instead of notification mechanism by power chip to omap glue to pass >> detection >> of any events, an export API has been added in omap glue. Both twl4030 and >> twl6030 will call to this API to pass any event. (twl6030 is used in omap4 >> and >> twl4030 is used in omap3). >> >> This series depends on: >> *[RFC PATCH 00/11] OMAP System Control Module* patch series >> However System Control Module driver has only dt support, so wouldn't >> be able to test this patch series. However I'll adapt omap usb2 phy >> driver and musb driver for dt and send it asap to the list. >> >> This series also depends on: >> *[PATCH v3 0/3] usb: multi-phy support* patch series >> *[RFC PATCH 0/5] omap: add ocp2scp as a misc driver* patch series >> >> Compile tested only. > > are we getting new version of this series ? Yes. I'm planning to send a new version with only dt support by next week. Thanks Kishon -- 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/3] ARM: OMAP2+: gpmc: handle additional timings
Hi Tony, On Wed, Jun 13, 2012 at 18:12:15, Tony Lindgren wrote: > > Or should additional timings be achieved without affecting old > > interface, but that it seems would necessitate more code > > duplication. > > We should just keep the same timings as before, with values > added for the newly added registers. What I understood from above is to get values bootloader used to set for those new timings & put in Kernel, right ? Regards Afzal -- 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 v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Tony, On Wed, Jun 13, 2012 at 19:09:38, Tony Lindgren wrote: > * Mohammed, Afzal [120613 06:10]: > > On Wed, Jun 13, 2012 at 17:32:09, Tony Lindgren wrote: > > Do you mean that gpmc driver should have the capability to calculate > > peripheral > > timings at runtime based on frequency ?, I am not sure how this can be > > handled > > by gpmc driver as calculation for different peripherals are done in > > different > > way, requiring gpmc driver to know about connected peripheral, that would > > imply > > that gpmc driver would not be peripheral agnostic. > > > > Or else some sort of a callback to be used ? > > Oops yeah right, we have some platform_retime functions that are in the > driver platform init code. It would be best that the drivers can do the > recalculation with no platform init code callbacks needed. Other than using a platform callback, I am not getting any idea as of now, how this can be achieved, let me think over it, if you have any suggestions on ways to deal it, please let me know. > > > Out of the 20,14 are depending on bootloader, both omap3evm & beagle has > > been > > converted to utilize runtime calculation, but for other 12 boards, first > > we need to get values used by bootloader (those include peripherals that > > doesn't > > have gpmc-* helpers), then derive it based on expression, after that only, > > we > > will have information to achieve it and those are the ones that I do not > > have access to. > > It's OK to use fixed timings as long as we disable L3 scaling. Some of > these values we'll probably never be able to calculate dynamically. Ok Regards Afzal -- 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 v5 04/14] ARM: OMAP2+: gpmc: minimal driver support
Hi Tony, On Wed, Jun 13, 2012 at 19:20:35, Mohammed, Afzal wrote: > Hi Tony, > > On Wed, Jun 13, 2012 at 19:14:08, Tony Lindgren wrote: > > > Actually why do you even need to store the revision? You can > > just read it from the hardware as needed. > > Earlier for wr_access & wr_data_mux_bus, we were checking, > cpu_is_34xx, but I feel it should instead be based on > IP revision as it is the IP revision that decides the > availability of those register bits. Or you meant, even there read revision register ? Regards Afzal -- 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 v5 04/14] ARM: OMAP2+: gpmc: minimal driver support
Hi Tony, On Wed, Jun 13, 2012 at 19:14:08, Tony Lindgren wrote: > Actually why do you even need to store the revision? You can > just read it from the hardware as needed. Earlier for wr_access & wr_data_mux_bus, we were checking, cpu_is_34xx, but I feel it should instead be based on IP revision as it is the IP revision that decides the availability of those register bits. Regards Afzal -- 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 v5 03/14] ARM: OMAP2+: gpmc: driver migration helper
Hi Tony, On Wed, Jun 13, 2012 at 17:48:15, Mohammed, Afzal wrote: > On Wed, Jun 13, 2012 at 17:34:58, Tony Lindgren wrote: > > There should no longer be any need to initialize GPMC early. It should > > behave like any other device driver, and also work as a loadable module. > > Once driver migration is complete for all the boards, we can remove the > initcall and make it loadable. > > But till that time as we need to support both old & new interface, > I feel this is necessary as old interface would happen in arch initcall, > and old gpmc_init is now gpmc_probe, and hence it needs to get executed > before arch initcall, necessitating this. Seems you missed this in the flood of mails, please let me know your comments on this. This is a commit that has to be reverted once driver migration is complete for all boards. Regards Afzal
Re: [PATCH v5 04/14] ARM: OMAP2+: gpmc: minimal driver support
* Tony Lindgren [120613 06:45]: > * Mohammed, Afzal [120613 06:16]: > > Hi Tony, > > > > On Wed, Jun 13, 2012 at 17:37:17, Tony Lindgren wrote: > > > * Jon Hunter [120612 11:01]: > > > > > > > > On 06/12/2012 02:16 AM, Mohammed, Afzal wrote: > > > > > > > Does having minor revision add any value ?, at least as of now, > > > > > I do not see any. > > > > > > > > May be not but it does not hurt either. > > > > > > Yeah might as well show the full revision. > > > > We are already showing full version, but only storing major, it seems you > > want to store minor version along with major version in the same variable, > > right ? > > Ah OK, yeah might as well just store the minor version. Actually why do you even need to store the revision? You can just read it from the hardware as needed. 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/9] ARM: OMAP2+: gpmc-smc91x: Adapt to use gpmc driver
* Mohammed, Afzal [120613 06:43]: > Hi Tony, > > On Wed, Jun 13, 2012 at 17:59:50, Tony Lindgren wrote: > > > Here too we just need to care about the mainline kernel users > > and convert them to use the new interface. No need to keep > > gpmc_cs_set_timings around. The same applies for other similar > > patches. > > Not sure whether I follow you here. > > Do you mean for all the gpmc-* helpers existing initialization > needs to be modified to use the new interface, the previous version > was doing so. But then that will cause all boards using the same > gpmc-* helper to be converted at once (tusb6010 is not an issue as > only one board uses it), then the problem will be that there would > be a few commits where gpmc may not work properly. > > And for a particular board, either it has to use old interface > or either the new interface, it cannot use both. > > Consider the case of this one, smc91x, all sdp boards use it, > that requires nand, onenand, nor gpmc-* helpers to be converted > before board migration for say 3430sdp board, that would mean > that 2430sdp board would be broken w.r.t gpmc at that commit as > board modifications are not yet done for 2430. That in turn means > all the boards using nand, onenand would be broken at that point. What I mean is keep the old interface in gpmc.c, then convert users one at a time to the new interface, and remove the old interface code from the users. But yeah you're right, it may not be immediately doable for the smc91x case before we dump out the register values. But at least tusb6010 should be able to just convert to use the new interface and drop the old code. 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 v5 04/14] ARM: OMAP2+: gpmc: minimal driver support
* Mohammed, Afzal [120613 06:16]: > Hi Tony, > > On Wed, Jun 13, 2012 at 17:37:17, Tony Lindgren wrote: > > * Jon Hunter [120612 11:01]: > > > > > > On 06/12/2012 02:16 AM, Mohammed, Afzal wrote: > > > > > Does having minor revision add any value ?, at least as of now, > > > > I do not see any. > > > > > > May be not but it does not hurt either. > > > > Yeah might as well show the full revision. > > We are already showing full version, but only storing major, it seems you > want to store minor version along with major version in the same variable, > right ? Ah OK, yeah might as well just store the minor version. 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 v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
* Mohammed, Afzal [120613 06:10]: > Hi Tony, > > On Wed, Jun 13, 2012 at 17:32:09, Tony Lindgren wrote: > > * Mohammed, Afzal [120612 22:24]: > > > Hi Jon, > > > > > > On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote: > > > > > Right but potentially, this could be done by the driver. > > > > > > I do not think it is practically possible. Please see timing calculations > > > in arch/arm/mach-omap2/gpmc-*, the way it is done for different > > > peripherals are different, and we cannot expect gpmc driver to do those as > > > that would require gpmc driver being aware of type of peripheral > > > connected. > > > > > > And all those gpmc-* timing calculation needs to be done before driver > > > is ready, they rely on functions like gpmc_get_fclk_rate(), which in turn > > > requires the clk rate to be available before driver is probed. > > > > Yeah I also think the GPMC code should handle the L3 timings, and > > dynamically > > calculate them for DVFS when L3 frequency changes. Does the GPMC have enough > > information now to do that? > > Do you mean that gpmc driver should have the capability to calculate > peripheral > timings at runtime based on frequency ?, I am not sure how this can be handled > by gpmc driver as calculation for different peripherals are done in different > way, requiring gpmc driver to know about connected peripheral, that would > imply > that gpmc driver would not be peripheral agnostic. > > Or else some sort of a callback to be used ? Oops yeah right, we have some platform_retime functions that are in the driver platform init code. It would be best that the drivers can do the recalculation with no platform init code callbacks needed. > Out of the 20,14 are depending on bootloader, both omap3evm & beagle has been > converted to utilize runtime calculation, but for other 12 boards, first > we need to get values used by bootloader (those include peripherals that > doesn't > have gpmc-* helpers), then derive it based on expression, after that only, we > will have information to achieve it and those are the ones that I do not > have access to. It's OK to use fixed timings as long as we disable L3 scaling. Some of these values we'll probably never be able to calculate dynamically. 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/9] ARM: OMAP2+: gpmc-smc91x: Adapt to use gpmc driver
Hi Tony, On Wed, Jun 13, 2012 at 17:59:50, Tony Lindgren wrote: > Here too we just need to care about the mainline kernel users > and convert them to use the new interface. No need to keep > gpmc_cs_set_timings around. The same applies for other similar > patches. Not sure whether I follow you here. Do you mean for all the gpmc-* helpers existing initialization needs to be modified to use the new interface, the previous version was doing so. But then that will cause all boards using the same gpmc-* helper to be converted at once (tusb6010 is not an issue as only one board uses it), then the problem will be that there would be a few commits where gpmc may not work properly. And for a particular board, either it has to use old interface or either the new interface, it cannot use both. Consider the case of this one, smc91x, all sdp boards use it, that requires nand, onenand, nor gpmc-* helpers to be converted before board migration for say 3430sdp board, that would mean that 2430sdp board would be broken w.r.t gpmc at that commit as board modifications are not yet done for 2430. That in turn means all the boards using nand, onenand would be broken at that point. Regards Afzal -- 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 0/2] Add mt9t001 and tvp5150 support to cm-t3x board.
This patch set adds mt9t001 camera sensor and tvp5150 video decoder registration to cm-t35/cm-t3730 board support file. Base board (SB-T35) CIP of cm-t3x module can be connected to external video input adapter like Compulab VIP-ADP board. VIP-ADP has a digital camera sensor connection port and two composite video input ports. Analog composite video is processed by TVP5151 NTSC/PAL/SECAM Video Decoder chip. Dmitry Lifshitz (2): ARM: OMAP3: cm-t35: add mt9t001 camera sensor support ARM: OMAP3: cm-t35: add tvp5150 decoder support arch/arm/mach-omap2/board-cm-t35.c | 89 1 files changed, 89 insertions(+), 0 deletions(-) -- 1.7.5.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
[PATCH 2/2] ARM: OMAP3: cm-t35: add tvp5150 decoder support
Register the tvp5150 video decoder in ISP subsystem.
Signed-off-by: Dmitry Lifshitz
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t35.c | 20
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index 05c66e8..97d7190 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -498,6 +498,9 @@ static struct i2c_board_info cm_t35_isp_i2c_boardinfo[] = {
{
I2C_BOARD_INFO("mt9t001", 0x5d),
},
+ {
+ I2C_BOARD_INFO("tvp5150", 0x5c),
+ },
};
static struct isp_subdev_i2c_board_info cm_t35_isp_primary_subdevs[] = {
@@ -508,6 +511,14 @@ static struct isp_subdev_i2c_board_info
cm_t35_isp_primary_subdevs[] = {
{ NULL, 0, },
};
+static struct isp_subdev_i2c_board_info cm_t35_isp_secondary_subdevs[] = {
+ {
+ .board_info = &cm_t35_isp_i2c_boardinfo[1],
+ .i2c_adapter_id = 3,
+ },
+ { NULL, 0, },
+};
+
static struct isp_v4l2_subdevs_group cm_t35_isp_subdevs[] = {
{
.subdevs = cm_t35_isp_primary_subdevs,
@@ -518,6 +529,15 @@ static struct isp_v4l2_subdevs_group cm_t35_isp_subdevs[]
= {
},
},
},
+ {
+ .subdevs = cm_t35_isp_secondary_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .clk_pol = 0,
+ },
+ },
+ },
{ NULL, 0, },
};
--
1.7.5.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
[PATCH 1/2] ARM: OMAP3: cm-t35: add mt9t001 camera sensor support
Setup pinmux for CPI and register the mt9t001 camera sensor
in ISP subsystem.
Signed-off-by: Dmitry Lifshitz
Signed-off-by: Igor Grinberg
---
arch/arm/mach-omap2/board-cm-t35.c | 69
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-cm-t35.c
b/arch/arm/mach-omap2/board-cm-t35.c
index ded100c..05c66e8 100644
--- a/arch/arm/mach-omap2/board-cm-t35.c
+++ b/arch/arm/mach-omap2/board-cm-t35.c
@@ -490,6 +490,51 @@ static struct twl4030_platform_data cm_t35_twldata = {
.power = &cm_t35_power_data,
};
+#if defined(CONFIG_VIDEO_OMAP3) || defined(CONFIG_VIDEO_OMAP3_MODULE)
+#include
+#include "devices.h"
+
+static struct i2c_board_info cm_t35_isp_i2c_boardinfo[] = {
+ {
+ I2C_BOARD_INFO("mt9t001", 0x5d),
+ },
+};
+
+static struct isp_subdev_i2c_board_info cm_t35_isp_primary_subdevs[] = {
+ {
+ .board_info = &cm_t35_isp_i2c_boardinfo[0],
+ .i2c_adapter_id = 3,
+ },
+ { NULL, 0, },
+};
+
+static struct isp_v4l2_subdevs_group cm_t35_isp_subdevs[] = {
+ {
+ .subdevs = cm_t35_isp_primary_subdevs,
+ .interface = ISP_INTERFACE_PARALLEL,
+ .bus = {
+ .parallel = {
+ .clk_pol = 1,
+ },
+ },
+ },
+ { NULL, 0, },
+};
+
+static struct isp_platform_data cm_t35_isp_pdata = {
+ .subdevs = cm_t35_isp_subdevs,
+};
+
+static void __init cm_t35_init_camera(void)
+{
+ if (omap3_init_camera(&cm_t35_isp_pdata) < 0)
+ pr_warn("CM-T3x: Failed registering camera device!\n");
+}
+
+#else
+static inline void cm_t35_init_camera(void) {}
+#endif /* CONFIG_VIDEO_OMAP3 */
+
static void __init cm_t35_init_i2c(void)
{
omap3_pmic_get_config(&cm_t35_twldata, TWL_COMMON_PDATA_USB,
@@ -497,6 +542,8 @@ static void __init cm_t35_init_i2c(void)
TWL_COMMON_PDATA_AUDIO);
omap3_pmic_init("tps65930", &cm_t35_twldata);
+
+ omap_register_i2c_bus(3, 400, NULL, 0);
}
#ifdef CONFIG_OMAP_MUX
@@ -574,6 +621,27 @@ static struct omap_board_mux board_mux[] __initdata = {
OMAP3_MUX(DSS_DATA16, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
OMAP3_MUX(DSS_DATA17, OMAP_MUX_MODE0 | OMAP_PIN_OUTPUT),
+ /* Camera */
+ OMAP3_MUX(CAM_HS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_VS, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_XCLKA, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_PCLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_FLD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D4, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D5, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D6, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D7, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+ OMAP3_MUX(CAM_D8, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP3_MUX(CAM_D9, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP3_MUX(CAM_STROBE, OMAP_MUX_MODE0 | OMAP_PIN_INPUT),
+
+ OMAP3_MUX(CAM_D10, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLDOWN),
+ OMAP3_MUX(CAM_D11, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLDOWN),
+
/* display controls */
OMAP3_MUX(MCBSP1_FSR, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
OMAP3_MUX(GPMC_NCS7, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
@@ -646,6 +714,7 @@ static void __init cm_t3x_common_init(void)
usb_musb_init(NULL);
cm_t35_init_usbh();
+ cm_t35_init_camera();
}
static void __init cm_t35_init(void)
--
1.7.5.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 4/9] ARM: OMAP2+: gpmc-tusb6010: Adapt to use gpmc driver
Hi Tony, On Wed, Jun 13, 2012 at 17:57:48, Tony Lindgren wrote: > We can drop the old interface for non-mainline cases. In this case > tusb6010 is only used by board-n8x0.c, so it's best to just convert > it all to use the new interface. Right, I will do accordingly Regards Afzal -- 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 v5 04/14] ARM: OMAP2+: gpmc: minimal driver support
Hi Tony, On Wed, Jun 13, 2012 at 17:37:17, Tony Lindgren wrote: > * Jon Hunter [120612 11:01]: > > > > On 06/12/2012 02:16 AM, Mohammed, Afzal wrote: > > > Does having minor revision add any value ?, at least as of now, > > > I do not see any. > > > > May be not but it does not hurt either. > > Yeah might as well show the full revision. We are already showing full version, but only storing major, it seems you want to store minor version along with major version in the same variable, right ? Regards Afzal -- 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 v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
Hi Tony, On Wed, Jun 13, 2012 at 17:32:09, Tony Lindgren wrote: > * Mohammed, Afzal [120612 22:24]: > > Hi Jon, > > > > On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote: > > > Right but potentially, this could be done by the driver. > > > > I do not think it is practically possible. Please see timing calculations > > in arch/arm/mach-omap2/gpmc-*, the way it is done for different > > peripherals are different, and we cannot expect gpmc driver to do those as > > that would require gpmc driver being aware of type of peripheral connected. > > > > And all those gpmc-* timing calculation needs to be done before driver > > is ready, they rely on functions like gpmc_get_fclk_rate(), which in turn > > requires the clk rate to be available before driver is probed. > > Yeah I also think the GPMC code should handle the L3 timings, and dynamically > calculate them for DVFS when L3 frequency changes. Does the GPMC have enough > information now to do that? Do you mean that gpmc driver should have the capability to calculate peripheral timings at runtime based on frequency ?, I am not sure how this can be handled by gpmc driver as calculation for different peripherals are done in different way, requiring gpmc driver to know about connected peripheral, that would imply that gpmc driver would not be peripheral agnostic. Or else some sort of a callback to be used ? Out of the 20,14 are depending on bootloader, both omap3evm & beagle has been converted to utilize runtime calculation, but for other 12 boards, first we need to get values used by bootloader (those include peripherals that doesn't have gpmc-* helpers), then derive it based on expression, after that only, we will have information to achieve it and those are the ones that I do not have access to. Regards Afzal > > Additionally GPMC should add constraints to DVFS if not enough data is know > to scale L3. > > 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/5] Input: ads7846: set proper debounce time in driver level
* Zumeng Chen [120612 09:41]: > 2012/6/12 Tony Lindgren > > > * Zumeng Chen [120611 07:05]: > > > If we don't set proper debouce time for ads7846, then there are > > > flooded interrupt counters of ads7846 responding to one time > > > touch on screen, so the driver couldn't work well. > > > > > > And since most OMAP3 series boards pass NULL pointer of board_pdata > > > to omap_ads7846_init, so it's more proper to set it in driver level > > > after having gpio_request done. > > > > > > This patch has been validated on 3530evm. > > > > > > Signed-off-by: Zumeng Chen > > > Signed-off-by: Syed Mohammed Khasim > > > Signed-off-by: Tony Lindgren > > > > Please remove my Signed-off-by, where does that come from? > > > HI Tony, > > This comes from git://arago-project.org/git/projects/linux-omap3.git > The commit ID is 53c5ec31, we set gpio_debounce in arch/board > level. Weird, I have no recollection of doing anything with that file.. Just remove my Signed-off-by please. 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/3] ARM: OMAP2+: gpmc: handle additional timings
* Mohammed, Afzal [120613 05:43]: > Hi Tony, > > On Wed, Jun 13, 2012 at 17:02:17, Tony Lindgren wrote: > > * Mohammed, Afzal [120612 22:00]: > > > Yes, that would be better except for too much logging, if Tony > > > prefers that way I will add. > > > > If there's a chance it causing file system corruption, we should > > test it carefully on the boards before applying. If that's done, > > then there's probably no need for warnings. It's safer to disable > > NAND for untested boards if there's a chance of breaking the timings. > > By disabling NAND, I understand that you are suggesting to remove > nand initialization done in board file, right ? Yes, but before we do that, let's fix things first for cases that we can test, like tusb6010 DMA. > And boards that can be tested here are omap3evm & beagleboard, > both of which can't be tested for this change. > > Or should additional timings be achieved without affecting old > interface, but that it seems would necessitate more code > duplication. We should just keep the same timings as before, with values added for the newly added registers. 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 0/3] Prepare for GPMC driver conversion
Hi Tony, On Wed, Jun 13, 2012 at 17:03:59, Tony Lindgren wrote: > NAND for untested boards if timings change. Are Jon's comments all handled? I have explained the justification, why those changes were done so, waiting for his comments. Regards Afzal -- 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/3] ARM: OMAP2+: gpmc: handle additional timings
Hi Tony, On Wed, Jun 13, 2012 at 17:02:17, Tony Lindgren wrote: > * Mohammed, Afzal [120612 22:00]: > > Yes, that would be better except for too much logging, if Tony > > prefers that way I will add. > > If there's a chance it causing file system corruption, we should > test it carefully on the boards before applying. If that's done, > then there's probably no need for warnings. It's safer to disable > NAND for untested boards if there's a chance of breaking the timings. By disabling NAND, I understand that you are suggesting to remove nand initialization done in board file, right ? And boards that can be tested here are omap3evm & beagleboard, both of which can't be tested for this change. Or should additional timings be achieved without affecting old interface, but that it seems would necessitate more code duplication. Regards Afzal -- 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 v5 00/14] GPMC driver conversion
* Mohammed, Afzal [120612 03:44]:
> Hi Tony,
>
> On Mon, Jun 11, 2012 at 19:55:02, Mohammed, Afzal wrote:
> > Hi,
> >
> > This series is based on 3.5-rc1, and is dependent on [1,2,3]
> >
> > This series has been tested on omap3evm (smsc911x) rev G & C and
> > beagle board(nand) using patch series which is going to be posted
> > shortly (this series only creates a driver out of GPMC code)
> >
> > Also using private patches, nand & onenand was tested on omap3evm,
> > rev G & C respectively (as support for these were not in mainline)
> >
> > Many of GPMC peripherals depend on bootloader for configuration.
> > This is going to be deprecated. feature-removal-schedule.txt will be
> > updated in one of the upcoming patch series regarding the same.
> >
> >
> > [PATCH 03/13] ARM: OMAP2+: gpmc: driver migration helper, is to be
> > reverted once all GPMC peripherals are migrated to use driver
> > interface.
>
> Please let me know your comments on this series. I had tried to
> go as per your requirements.
>
> This series keeps old interface while providing a new driver interface.
> Old interface will work (to the best of my knowledge; omap3evm &
> beagle are the ones available here to test) at each of the commits.
Cool, yeah looks like the old interface almost works. I had to undo the
new additions for tusb6010 DMA to work as below. Then Jon has some good
comments. I also made few comments to the GPMC using driver changes.
In general, please keep in mind that eventually we want this to be
a regular device driver that also works as a loadable module.
And we need the device tree bindings for GPMC so we can start dropping
board-*.c files as the GPMC seems to be last remaining blocker for
making rarely used legacy boards DT only. So it might be worth
playing with that so we don't again have to redo some parts.
Regards,
Tony
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -363,13 +363,13 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings
*t)
GPMC_SET_ONE(GPMC_CS_CONFIG5, 16, 20, access);
GPMC_SET_ONE(GPMC_CS_CONFIG5, 24, 27, page_burst_access);
-
+#if 0
GPMC_SET_ONE(GPMC_CS_CONFIG6, 0, 3, bus_turnaround);
GPMC_SET_ONE(GPMC_CS_CONFIG6, 8, 11, cycle2cycle_delay);
GPMC_SET_ONE(GPMC_CS_CONFIG1, 18, 19, wait_monitoring);
GPMC_SET_ONE(GPMC_CS_CONFIG1, 25, 26, clk_activation);
-
+#endif
if (cpu_is_omap34xx()) {
GPMC_SET_ONE(GPMC_CS_CONFIG6, 16, 19, wr_data_mux_bus);
GPMC_SET_ONE(GPMC_CS_CONFIG6, 24, 28, wr_access);
--
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/9] ARM: OMAP2+: gpmc-smc91x: Adapt to use gpmc driver
* Afzal Mohammed [120611 08:19]:
> --- a/arch/arm/mach-omap2/gpmc-smc91x.c
> +++ b/arch/arm/mach-omap2/gpmc-smc91x.c
> @@ -114,7 +136,13 @@ static int smc91c96_gpmc_retime(void)
> if (gpmc_cfg->flags & GPMC_MUX_ADD_DATA)
> return 0;
>
> - return gpmc_cs_set_timings(gpmc_cfg->cs, &t);
> + /* gpmc driver interface */
> + if (gpmc_smc91x_cs_data.mem_size == 0x10) {
> + gpmc_smc91x_cs_data.time_ctrl.type = has_period;
> + gpmc_smc91x_cs_data.time_ctrl.timings = t;
> + return 0;
> + } else
> + return gpmc_cs_set_timings(gpmc_cfg->cs, &t);
> }
>
> /*
Here too we just need to care about the mainline kernel users
and convert them to use the new interface. No need to keep
gpmc_cs_set_timings around. The same applies for other similar
patches.
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/9] ARM: OMAP2+: gpmc-tusb6010: Adapt to use gpmc driver
* Afzal Mohammed [120611 08:19]:
> @@ -106,7 +123,14 @@ static int tusb_set_async_mode(unsigned sysclk_ps,
> unsigned fclk_ps)
> tmp = t.cs_wr_off * 1000 + 7000 /* t_acsn_rdy_z */;
> t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
>
> - return gpmc_cs_set_timings(async_cs, &t);
> + /* gpmc driver interface */
> + if (gpmc_tusb_data.pdata != NULL) {
> + gpmc_tusb_cs_data[CS_ASYNC_IDX].time_ctrl.type = has_period;
> + gpmc_tusb_cs_data[CS_ASYNC_IDX].time_ctrl.timings = t;
> + return 0;
> + /* old interface */
> + } else
> + return gpmc_cs_set_timings(async_cs, &t);
> }
>
> static int tusb_set_sync_mode(unsigned sysclk_ps, unsigned fclk_ps)
> @@ -174,7 +198,16 @@ static int tusb_set_sync_mode(unsigned sysclk_ps,
> unsigned fclk_ps)
> tmp = t.cs_wr_off * 1000 + 7000 /* t_scsn_rdy_z */;
> t.wr_cycle = next_clk(t.cs_wr_off, tmp, fclk_ps);
>
> - return gpmc_cs_set_timings(sync_cs, &t);
> + t.clk_activation = gpmc_ticks_to_ns(1);
> +
> + /* gpmc driver interface */
> + if (gpmc_tusb_data.pdata != NULL) {
> + gpmc_tusb_cs_data[CS_SYNC_IDX].time_ctrl.type = has_period;
> + gpmc_tusb_cs_data[CS_SYNC_IDX].time_ctrl.timings = t;
> + return 0;
> + /* old interface */
> + } else
> + return gpmc_cs_set_timings(sync_cs, &t);
> }
We can drop the old interface for non-mainline cases. In this case
tusb6010 is only used by board-n8x0.c, so it's best to just convert
it all to use the new interface.
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 5/5] Input: ads7846: set proper debounce time in driver level
On Wed, Jun 13, 2012 at 07:14:10, Zumeng Chen wrote:
> From: Zumeng Chen
>
> If we don't set proper debouce time for ads7846, then there are
> flooded interrupt counters of ads7846 responding to one time
> touch on screen, so the driver couldn't work well.
>
> And since most OMAP3 series boards pass NULL pointer of board_pdata
> to omap_ads7846_init, so it's more proper to set it in driver level
> after having gpio_request done.
>
> This patch has been validated on 3530evm.
>
> Signed-off-by: Zumeng Chen
> Signed-off-by: Syed Mohammed Khasim
> ---
> drivers/input/touchscreen/ads7846.c |4
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/input/touchscreen/ads7846.c
> b/drivers/input/touchscreen/ads7846.c
> index f02028e..459ff29 100644
> --- a/drivers/input/touchscreen/ads7846.c
> +++ b/drivers/input/touchscreen/ads7846.c
> @@ -980,6 +980,10 @@ static int __devinit ads7846_setup_pendown(struct
> spi_device *spi, struct ads784
> }
>
> ts->gpio_pendown = pdata->gpio_pendown;
> +#ifdef CONFIG_ARCH_OMAP3
> + /* 310 means about 10 microsecond for omap3 */
> + gpio_set_debounce(pdata->gpio_pendown, 310);
> +#endif
>
Zumeng,
With my sign-off you are changing the original code, that too
without my sign-off and ack.
I wouldn't mind you to submit patches from my tree, but the expectation is
if you are changing the original code, it should be under your sign-off.
Coming to the patch, #ifdef in driver is not recommended, and this 10msec
delay is specific to OMAP GPIO and driver should not be aware of this,
that's where you will find the original patch handling it in board file.
Thanks,
Vaibhav
> } else {
> dev_err(&spi->dev, "no get_pendown_state nor gpio_pendown?\n");
> --
> 1.7.5.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 v5 03/14] ARM: OMAP2+: gpmc: driver migration helper
Hi Tony, On Wed, Jun 13, 2012 at 17:34:58, Tony Lindgren wrote: > > I am not sure if I am missing something, but it appears that pdev will > > always be NULL here as it is a local uninitialised variable. > > This also creates a new warning: > > arch/arm/mach-omap2/gpmc.c: In function ‘gpmc_create_device’: > arch/arm/mach-omap2/gpmc.c:1434: warning: ‘pdev’ may be used uninitialized in > this function I use an internal toolchain, that does not give warning, seems I need to check with codesourcery. > > > Not sure I see the point in the above function. Why not declare the > > gpmc_device_data struct as static in the file and access it directly > > instead of passing it in omap_gpmc_init(). The postcore_init can then > > call omap_gpmc_init() directly. > > > > Shouldn't the post_initcall be added in patch #4, when the driver is > > created? > > There should no longer be any need to initialize GPMC early. It should > behave like any other device driver, and also work as a loadable module. Once driver migration is complete for all the boards, we can remove the initcall and make it loadable. But till that time as we need to support both old & new interface, I feel this is necessary as old interface would happen in arch initcall, and old gpmc_init is now gpmc_probe, and hence it needs to get executed before arch initcall, necessitating this. Regards Afzal
Re: [PATCH v5 04/14] ARM: OMAP2+: gpmc: minimal driver support
* Jon Hunter [120612 11:01]: > > On 06/12/2012 02:16 AM, Mohammed, Afzal wrote: > > Hi Jon, > > > > On Tue, Jun 12, 2012 at 02:13:22, Hunter, Jon wrote: > > > >>> + gpmc_revision = (l >> 4) & 0xf; > >> > >> Why are you only storing the major part of the rev? Why not keep both > >> parts? > > > > Does having minor revision add any value ?, at least as of now, > > I do not see any. > > May be not but it does not hurt either. Yeah might as well show the full revision. 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 v5 03/14] ARM: OMAP2+: gpmc: driver migration helper
* Jon Hunter [120611 13:34]:
> Hi Afzal,
>
> On 06/11/2012 09:26 AM, Afzal Mohammed wrote:
> > A driver is being created out of GPMC code. This is being
> > attempted to acheive by not breaking existing interface,
> > necessitating requirement of GPMC peripherals being able
> > to work with as well as without the help of driver. To not
> > break existing, initcall is required as in old interface
> > GPMC is configured at arch initcall and GPMC should be
> > ready to handle old interface by that time
> >
> > Signed-off-by: Afzal Mohammed
> > ---
> > arch/arm/mach-omap2/gpmc.c | 19 ++-
> > 1 file changed, 18 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
> > index b471c2f..6dbddb9 100644
> > --- a/arch/arm/mach-omap2/gpmc.c
> > +++ b/arch/arm/mach-omap2/gpmc.c
> > @@ -902,7 +902,7 @@ postcore_initcall(gpmc_init);
> > __init int omap_gpmc_init(struct gpmc_pdata *pdata)
> > {
> > struct omap_hwmod *oh;
> > - struct platform_device *pdev;
> > + static struct platform_device *pdev;
> > char *name = "omap-gpmc";
> > char *oh_name = "gpmc";
> >
> > @@ -912,6 +912,12 @@ __init int omap_gpmc_init(struct gpmc_pdata *pdata)
> > return -ENODEV;
> > }
> >
> > + if (pdev != NULL) {
> > + clk_put(gpmc_l3_clk);
> > + omap_device_delete(pdev->archdata.od);
> > + platform_device_unregister(pdev);
> > + }
> > +
>
> I am not sure if I am missing something, but it appears that pdev will
> always be NULL here as it is a local uninitialised variable.
This also creates a new warning:
arch/arm/mach-omap2/gpmc.c: In function ‘gpmc_create_device’:
arch/arm/mach-omap2/gpmc.c:1434: warning: ‘pdev’ may be used uninitialized in
this function
> Not sure I see the point in the above function. Why not declare the
> gpmc_device_data struct as static in the file and access it directly
> instead of passing it in omap_gpmc_init(). The postcore_init can then
> call omap_gpmc_init() directly.
>
> Shouldn't the post_initcall be added in patch #4, when the driver is
> created?
There should no longer be any need to initialize GPMC early. It should
behave like any other device driver, and also work as a loadable module.
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 v5 02/14] ARM: OMAP2+: gpmc: Adapt to HWMOD
* Mohammed, Afzal [120612 22:24]: > Hi Jon, > > On Tue, Jun 12, 2012 at 23:10:01, Hunter, Jon wrote: > > On 06/12/2012 01:53 AM, Mohammed, Afzal wrote: > > > On Tue, Jun 12, 2012 at 01:26:29, Hunter, Jon wrote: > > > >> My preference would be to store gpmc_l3_clk in the pdata and pass to > > >> probe via the pdata. The aim would be to remove the global gpmc_l3_clk > > >> altogether. > > > > > > For timing calculation by platform outside of driver, we need clk rate > > > > Right but potentially, this could be done by the driver. > > I do not think it is practically possible. Please see timing calculations > in arch/arm/mach-omap2/gpmc-*, the way it is done for different > peripherals are different, and we cannot expect gpmc driver to do those as > that would require gpmc driver being aware of type of peripheral connected. > > And all those gpmc-* timing calculation needs to be done before driver > is ready, they rely on functions like gpmc_get_fclk_rate(), which in turn > requires the clk rate to be available before driver is probed. Yeah I also think the GPMC code should handle the L3 timings, and dynamically calculate them for DVFS when L3 frequency changes. Does the GPMC have enough information now to do that? Additionally GPMC should add constraints to DVFS if not enough data is know to scale L3. 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/3] ARM: OMAP2+: gpmc: handle additional timings
Hi Tony, On Wed, Jun 13, 2012 at 17:24:45, Tony Lindgren wrote: > > If there's a chance it causing file system corruption, we should > > test it carefully on the boards before applying. If that's done, > > then there's probably no need for warnings. It's safer to disable > > NAND for untested boards if there's a chance of breaking the timings. > > Actually this patch breaks at least DMA on tusb6010 on n8x0. That's > a MUSB hardware in a wrapper connected to GPMC that's very picky with > the timings. > > Got any hints what should be done with the cycle2cycle stuff for > tusb6010? Not as of now, let me try to find out. Regards Afzal -- 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 08/10] ARM: OMAP2+: gpmc: Modify interrupt handling
Hi Artem, On Wed, Jun 13, 2012 at 17:25:58, Artem Bityutskiy wrote: > On Wed, 2012-06-13 at 17:03 +0530, Afzal Mohammed wrote: > > +/* XXX: Only NAND irq has been considered,currently these are the only > > ones used > > + */ > > +#defineGPMC_NR_IRQ 2 > > I guess "XXX" means "Warning"? Why not to use plain English? :-) It was made so that in editor (vim, maybe got biased towards it as I use it) it gets highlighted, do you want me to send an updated series ? Regards Afzal
Re: [PATCH 3/3] ARM: OMAP2+: gpmc: handle additional timings
* Tony Lindgren [120613 04:36]: > * Mohammed, Afzal [120612 22:00]: > > Hi Jon, > > > > On Tue, Jun 12, 2012 at 23:06:53, Hunter, Jon wrote: > > > > > Should you at least warn, if you are going to over-write a value? > > > > Yes, that would be better except for too much logging, if Tony > > prefers that way I will add. > > If there's a chance it causing file system corruption, we should > test it carefully on the boards before applying. If that's done, > then there's probably no need for warnings. It's safer to disable > NAND for untested boards if there's a chance of breaking the timings. Actually this patch breaks at least DMA on tusb6010 on n8x0. That's a MUSB hardware in a wrapper connected to GPMC that's very picky with the timings. Got any hints what should be done with the cycle2cycle stuff for tusb6010? 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 08/10] ARM: OMAP2+: gpmc: Modify interrupt handling
On Wed, 2012-06-13 at 17:03 +0530, Afzal Mohammed wrote: > +/* XXX: Only NAND irq has been considered,currently these are the only ones > used > + */ > +#define GPMC_NR_IRQ 2 I guess "XXX" means "Warning"? Why not to use plain English? :-) -- Best Regards, Artem Bityutskiy signature.asc Description: This is a digitally signed message part
[PATCH v2 10/10] mtd: nand: omap2: use gpmc provided irqs
GPMC platform initialization provides it's clients
with interrupts that can be used through struct
resource. Make use of it for irq mode functionality.
Also now write protect disable is done by GPMC,
hence remove it.
Signed-off-by: Afzal Mohammed
---
drivers/mtd/nand/omap2.c | 70 +++---
1 file changed, 42 insertions(+), 28 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 318ed8a..5193ebb 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -135,7 +135,8 @@ struct omap_nand_info {
unsigned long mem_size;
struct completion comp;
int dma_ch;
- int gpmc_irq;
+ int gpmc_irq_fifo;
+ int gpmc_irq_count;
enum {
OMAP_NAND_IO_READ = 0, /* read */
OMAP_NAND_IO_WRITE, /* write */
@@ -564,14 +565,12 @@ static irqreturn_t omap_nand_irq(int this_irq, void *dev)
{
struct omap_nand_info *info = (struct omap_nand_info *) dev;
u32 bytes;
- u32 irq_stat;
- irq_stat = gpmc_read_status(GPMC_GET_IRQ_STATUS);
bytes = readl(info->reg.gpmc_prefetch_status);
bytes = GPMC_PREFETCH_STATUS_FIFO_CNT(bytes);
bytes = bytes & 0xFFFC; /* io in multiple of 4 bytes */
if (info->iomode == OMAP_NAND_IO_WRITE) { /* checks for write io */
- if (irq_stat & 0x2)
+ if (this_irq == info->gpmc_irq_count)
goto done;
if (info->buf_len && (info->buf_len < bytes))
@@ -588,20 +587,17 @@ static irqreturn_t omap_nand_irq(int this_irq, void *dev)
(u32 *)info->buf, bytes >> 2);
info->buf = info->buf + bytes;
- if (irq_stat & 0x2)
+ if (this_irq == info->gpmc_irq_count)
goto done;
}
- gpmc_cs_configure(info->gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
return IRQ_HANDLED;
done:
complete(&info->comp);
- /* disable irq */
- gpmc_cs_configure(info->gpmc_cs, GPMC_ENABLE_IRQ, 0);
- /* clear status */
- gpmc_cs_configure(info->gpmc_cs, GPMC_SET_IRQ_STATUS, irq_stat);
+ disable_irq_nosync(info->gpmc_irq_fifo);
+ disable_irq_nosync(info->gpmc_irq_count);
return IRQ_HANDLED;
}
@@ -635,9 +631,9 @@ static void omap_read_buf_irq_pref(struct mtd_info *mtd,
u_char *buf, int len)
goto out_copy;
info->buf_len = len;
- /* enable irq */
- gpmc_cs_configure(info->gpmc_cs, GPMC_ENABLE_IRQ,
- (GPMC_IRQ_FIFOEVENTENABLE | GPMC_IRQ_COUNT_EVENT));
+
+ enable_irq(info->gpmc_irq_count);
+ enable_irq(info->gpmc_irq_fifo);
/* waiting for read to complete */
wait_for_completion(&info->comp);
@@ -685,12 +681,13 @@ static void omap_write_buf_irq_pref(struct mtd_info *mtd,
goto out_copy;
info->buf_len = len;
- /* enable irq */
- gpmc_cs_configure(info->gpmc_cs, GPMC_ENABLE_IRQ,
- (GPMC_IRQ_FIFOEVENTENABLE | GPMC_IRQ_COUNT_EVENT));
+
+ enable_irq(info->gpmc_irq_count);
+ enable_irq(info->gpmc_irq_fifo);
/* waiting for write to complete */
wait_for_completion(&info->comp);
+
/* wait for data to flushed-out before reset the prefetch */
tim = 0;
limit = (loops_per_jiffy * msecs_to_jiffies(OMAP_NAND_TIMEOUT_MS));
@@ -1309,9 +1306,6 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info->nand.options = pdata->devsize;
info->nand.options |= NAND_SKIP_BBTSCAN;
- /* NAND write protect off */
- gpmc_cs_configure(info->gpmc_cs, GPMC_CONFIG_WP, 0);
-
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL) {
err = -EINVAL;
@@ -1334,6 +1328,14 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
goto out_release_mem_region;
}
+ info->gpmc_irq_fifo = platform_get_irq(pdev, 0);
+ if (info->gpmc_irq_fifo == -ENXIO)
+ dev_warn(&pdev->dev, "error getting FIFO IRQ\n");
+
+ info->gpmc_irq_count = platform_get_irq(pdev, 1);
+ if (info->gpmc_irq_count == -ENXIO)
+ dev_warn(&pdev->dev, "error getting TERMINALCOUNT IRQ\n");
+
info->nand.controller = &info->controller;
info->nand.IO_ADDR_W = info->nand.IO_ADDR_R;
@@ -1389,17 +1391,24 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
break;
case NAND_OMAP_PREFETCH_IRQ:
- err = request_irq(pdata->gpmc_irq,
- omap_nand_irq, IRQF_SHARED, "gpmc-nand", info);
+ err = request_irq(info->gpmc_irq_fifo, omap_na
[PATCH v2 09/10] ARM: OMAP2+: gpmc-nand: Modify Interrupt handling
Now GPMC provides its client with interrupts that can be handled
using the standard interrupt API. Modify GPMC NAND setup to work
with it.
Also disable write protect in GPMC code, so that NAND driver can
be ignorant of GPMC configuration.
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/gpmc-nand.c | 26 --
1 file changed, 20 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index c0320d2..045596a 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -21,15 +21,23 @@
#include
#include
-static struct resource gpmc_nand_resource = {
- .flags = IORESOURCE_MEM,
+static struct resource gpmc_nand_resource[] = {
+ {
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ },
+ {
+ .flags = IORESOURCE_IRQ,
+ },
};
static struct platform_device gpmc_nand_device = {
.name = "omap2-nand",
.id = 0,
- .num_resources = 1,
- .resource = &gpmc_nand_resource,
+ .num_resources = ARRAY_SIZE(gpmc_nand_resource),
+ .resource = gpmc_nand_resource,
};
static int omap2_nand_gpmc_retime(struct omap_nand_platform_data
*gpmc_nand_data)
@@ -75,6 +83,7 @@ static int omap2_nand_gpmc_retime(struct
omap_nand_platform_data *gpmc_nand_data
gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_DEV_SIZE, 0);
gpmc_cs_configure(gpmc_nand_data->cs,
GPMC_CONFIG_DEV_TYPE, GPMC_DEVICETYPE_NAND);
+ gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_WP, 0);
err = gpmc_cs_set_timings(gpmc_nand_data->cs, &t);
if (err)
return err;
@@ -90,14 +99,19 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data)
gpmc_nand_device.dev.platform_data = gpmc_nand_data;
err = gpmc_cs_request(gpmc_nand_data->cs, NAND_IO_SIZE,
- (unsigned long *)&gpmc_nand_resource.start);
+ (unsigned long *)&gpmc_nand_resource[0].start);
if (err < 0) {
dev_err(dev, "Cannot request GPMC CS\n");
return err;
}
- gpmc_nand_resource.end = gpmc_nand_resource.start + NAND_IO_SIZE - 1;
+ gpmc_nand_resource[0].end = gpmc_nand_resource[0].start +
+ NAND_IO_SIZE - 1;
+ gpmc_nand_resource[1].start =
+ gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
+ gpmc_nand_resource[2].start =
+ gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
/* Set timings in GPMC */
err = omap2_nand_gpmc_retime(gpmc_nand_data);
if (err < 0) {
--
1.7.10.2
--
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 08/10] ARM: OMAP2+: gpmc: Modify interrupt handling
Modify interrupt handling such that interrupts can be handled by GPMC
client drivers using standard interrupt APIs rather than requiring
the drivers to have knowledge about GPMC interrupt handling. Currently
only NAND related interrupts has been considered (which is the case
even without this change) as the only user of GPMC interrupt is NAND.
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/gpmc.c | 136
arch/arm/plat-omap/include/plat/gpmc.h |1 +
2 files changed, 120 insertions(+), 17 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index a2c0588..578fd4c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -78,6 +78,15 @@
#define ENABLE_PREFETCH(0x1 << 7)
#define DMA_MPU_MODE 2
+/* XXX: Only NAND irq has been considered,currently these are the only ones
used
+ */
+#defineGPMC_NR_IRQ 2
+
+struct gpmc_client_irq {
+ unsignedirq;
+ u32 bitmask;
+};
+
/* Structure to save gpmc cs context */
struct gpmc_cs_config {
u32 config1;
@@ -105,6 +114,10 @@ struct omap3_gpmc_regs {
struct gpmc_cs_config cs_context[GPMC_CS_NUM];
};
+static struct gpmc_client_irq gpmc_client_irq[GPMC_NR_IRQ];
+static struct irq_chip gpmc_irq_chip;
+static unsigned gpmc_irq_start;
+
static struct resource gpmc_mem_root;
static struct resource gpmc_cs_mem[GPMC_CS_NUM];
static DEFINE_SPINLOCK(gpmc_mem_lock);
@@ -702,6 +715,97 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int
cs)
reg->gpmc_bch_result0 = gpmc_base + GPMC_ECC_BCH_RESULT_0;
}
+int gpmc_get_client_irq(unsigned irq_config)
+{
+ int i;
+
+ if (hweight32(irq_config) > 1)
+ return 0;
+
+ for (i = 0; i < GPMC_NR_IRQ; i++)
+ if (gpmc_client_irq[i].bitmask & irq_config)
+ return gpmc_client_irq[i].irq;
+
+ return 0;
+}
+
+static int gpmc_irq_endis(unsigned irq, bool endis)
+{
+ int i;
+ u32 regval;
+
+ for (i = 0; i < GPMC_NR_IRQ; i++)
+ if (irq == gpmc_client_irq[i].irq) {
+ regval = gpmc_read_reg(GPMC_IRQENABLE);
+ if (endis)
+ regval |= gpmc_client_irq[i].bitmask;
+ else
+ regval &= ~gpmc_client_irq[i].bitmask;
+ gpmc_write_reg(GPMC_IRQENABLE, regval);
+ break;
+ }
+
+ return 0;
+}
+
+static void gpmc_irq_disable(struct irq_data *p)
+{
+ gpmc_irq_endis(p->irq, false);
+}
+
+static void gpmc_irq_enable(struct irq_data *p)
+{
+ gpmc_irq_endis(p->irq, true);
+}
+
+static void gpmc_irq_noop(struct irq_data *data) { }
+
+static unsigned int gpmc_irq_noop_ret(struct irq_data *data) { return 0; }
+
+static int gpmc_setup_irq(int gpmc_irq)
+{
+ int i;
+ u32 regval;
+
+ if (!gpmc_irq)
+ return -EINVAL;
+
+ gpmc_irq_start = irq_alloc_descs(-1, 0, GPMC_NR_IRQ, 0);
+ if (IS_ERR_VALUE(gpmc_irq_start)) {
+ pr_err("irq_alloc_descs failed\n");
+ return gpmc_irq_start;
+ }
+
+ gpmc_irq_chip.name = "gpmc";
+ gpmc_irq_chip.irq_startup = gpmc_irq_noop_ret;
+ gpmc_irq_chip.irq_enable = gpmc_irq_enable;
+ gpmc_irq_chip.irq_disable = gpmc_irq_disable;
+ gpmc_irq_chip.irq_shutdown = gpmc_irq_noop;
+ gpmc_irq_chip.irq_ack = gpmc_irq_noop;
+ gpmc_irq_chip.irq_mask = gpmc_irq_noop;
+ gpmc_irq_chip.irq_unmask = gpmc_irq_noop;
+
+ gpmc_client_irq[0].bitmask = GPMC_IRQ_FIFOEVENTENABLE;
+ gpmc_client_irq[1].bitmask = GPMC_IRQ_COUNT_EVENT;
+
+ for (i = 0; i < GPMC_NR_IRQ; i++) {
+ gpmc_client_irq[i].irq = gpmc_irq_start + i;
+ irq_set_chip_and_handler(gpmc_client_irq[i].irq,
+ &gpmc_irq_chip, handle_simple_irq);
+ set_irq_flags(gpmc_client_irq[i].irq,
+ IRQF_VALID | IRQF_NOAUTOEN);
+ }
+
+ /* Disable interrupts */
+ gpmc_write_reg(GPMC_IRQENABLE, 0);
+
+ /* clear interrupts */
+ regval = gpmc_read_reg(GPMC_IRQSTATUS);
+ gpmc_write_reg(GPMC_IRQSTATUS, regval);
+
+ return request_irq(gpmc_irq, gpmc_handle_irq, 0, "gpmc", NULL);
+}
+
static void __init gpmc_mem_init(void)
{
int cs;
@@ -731,8 +835,8 @@ static void __init gpmc_mem_init(void)
static int __init gpmc_init(void)
{
- u32 l, irq;
- int cs, ret = -EINVAL;
+ u32 l;
+ int ret = -EINVAL;
int gpmc_irq;
char *ck = NULL;
@@ -780,16 +884,7 @@ static int __init gpmc_init(void)
gpmc_write_reg(GPMC_SYSCONFIG, l);
gpmc_mem_init();
- /* initalize the irq_chained */
- irq = OMAP_GPMC_IRQ_BASE;
- for (cs = 0; cs < GPMC_CS_NUM; cs++
[PATCH v2 07/10] mtd: onenand: omap2: obtain memory from resource
gpmc initialization for onenand done by platform code now provides
onenand address space as memory resource. Hence remove usage of
gpmc_cs_request in onenand driver and obtain memory details from
resource structure.
Signed-off-by: Afzal Mohammed
---
drivers/mtd/onenand/omap2.c | 29 -
1 file changed, 16 insertions(+), 13 deletions(-)
diff --git a/drivers/mtd/onenand/omap2.c b/drivers/mtd/onenand/omap2.c
index 398a827..3ff893d 100644
--- a/drivers/mtd/onenand/omap2.c
+++ b/drivers/mtd/onenand/omap2.c
@@ -48,13 +48,13 @@
#define DRIVER_NAME "omap2-onenand"
-#define ONENAND_IO_SIZESZ_128K
#define ONENAND_BUFRAM_SIZE(1024 * 5)
struct omap2_onenand {
struct platform_device *pdev;
int gpmc_cs;
unsigned long phys_base;
+ unsigned int mem_size;
int gpio_irq;
struct mtd_info mtd;
struct onenand_chip onenand;
@@ -626,6 +626,7 @@ static int __devinit omap2_onenand_probe(struct
platform_device *pdev)
struct omap2_onenand *c;
struct onenand_chip *this;
int r;
+ struct resource *res;
pdata = pdev->dev.platform_data;
if (pdata == NULL) {
@@ -647,20 +648,24 @@ static int __devinit omap2_onenand_probe(struct
platform_device *pdev)
c->gpio_irq = 0;
}
- r = gpmc_cs_request(c->gpmc_cs, ONENAND_IO_SIZE, &c->phys_base);
- if (r < 0) {
- dev_err(&pdev->dev, "Cannot request GPMC CS\n");
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res == NULL) {
+ r = -EINVAL;
+ dev_err(&pdev->dev, "error getting memory resource\n");
goto err_kfree;
}
- if (request_mem_region(c->phys_base, ONENAND_IO_SIZE,
+ c->phys_base = res->start;
+ c->mem_size = resource_size(res);
+
+ if (request_mem_region(c->phys_base, c->mem_size,
pdev->dev.driver->name) == NULL) {
- dev_err(&pdev->dev, "Cannot reserve memory region at 0x%08lx, "
- "size: 0x%x\n", c->phys_base, ONENAND_IO_SIZE);
+ dev_err(&pdev->dev, "Cannot reserve memory region at 0x%08lx,
size: 0x%x\n",
+ c->phys_base, c->mem_size);
r = -EBUSY;
- goto err_free_cs;
+ goto err_kfree;
}
- c->onenand.base = ioremap(c->phys_base, ONENAND_IO_SIZE);
+ c->onenand.base = ioremap(c->phys_base, c->mem_size);
if (c->onenand.base == NULL) {
r = -ENOMEM;
goto err_release_mem_region;
@@ -776,9 +781,7 @@ err_release_gpio:
err_iounmap:
iounmap(c->onenand.base);
err_release_mem_region:
- release_mem_region(c->phys_base, ONENAND_IO_SIZE);
-err_free_cs:
- gpmc_cs_free(c->gpmc_cs);
+ release_mem_region(c->phys_base, c->mem_size);
err_kfree:
kfree(c);
@@ -800,7 +803,7 @@ static int __devexit omap2_onenand_remove(struct
platform_device *pdev)
gpio_free(c->gpio_irq);
}
iounmap(c->onenand.base);
- release_mem_region(c->phys_base, ONENAND_IO_SIZE);
+ release_mem_region(c->phys_base, c->mem_size);
gpmc_cs_free(c->gpmc_cs);
kfree(c);
--
1.7.10.2
--
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 06/10] mtd: nand: omap2: obtain memory from resource
gpmc initialization done by platform code now updates struct resource
with the address space alloted for nand. Use this interface to obtain
memory rather than relying on platform data field - phys_base.
Signed-off-by: Afzal Mohammed
---
arch/arm/plat-omap/include/plat/nand.h |1 -
drivers/mtd/nand/omap2.c | 19 +++
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 86e4d9c..290cef5 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -26,7 +26,6 @@ struct omap_nand_platform_data {
booldev_ready;
int gpmc_irq;
enum nand_ioxfer_type;
- unsigned long phys_base;
int devsize;
enum omap_ecc ecc_opt;
struct gpmc_nand_regs reg;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 1d138fe..318ed8a 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -132,6 +132,7 @@ struct omap_nand_info {
int gpmc_cs;
unsigned long phys_base;
+ unsigned long mem_size;
struct completion comp;
int dma_ch;
int gpmc_irq;
@@ -1279,6 +1280,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
struct omap_nand_platform_data *pdata;
int err;
int i, offset;
+ struct resource *res;
pdata = pdev->dev.platform_data;
if (pdata == NULL) {
@@ -1298,7 +1300,6 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
info->pdev = pdev;
info->gpmc_cs = pdata->cs;
- info->phys_base = pdata->phys_base;
info->reg = pdata->reg;
info->mtd.priv = &info->nand;
@@ -1311,13 +1312,23 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
/* NAND write protect off */
gpmc_cs_configure(info->gpmc_cs, GPMC_CONFIG_WP, 0);
- if (!request_mem_region(info->phys_base, NAND_IO_SIZE,
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (res == NULL) {
+ err = -EINVAL;
+ dev_err(&pdev->dev, "error getting memory resource\n");
+ goto out_free_info;
+ }
+
+ info->phys_base = res->start;
+ info->mem_size = resource_size(res);
+
+ if (!request_mem_region(info->phys_base, info->mem_size,
pdev->dev.driver->name)) {
err = -EBUSY;
goto out_free_info;
}
- info->nand.IO_ADDR_R = ioremap(info->phys_base, NAND_IO_SIZE);
+ info->nand.IO_ADDR_R = ioremap(info->phys_base, info->mem_size);
if (!info->nand.IO_ADDR_R) {
err = -ENOMEM;
goto out_release_mem_region;
@@ -1474,7 +1485,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
return 0;
out_release_mem_region:
- release_mem_region(info->phys_base, NAND_IO_SIZE);
+ release_mem_region(info->phys_base, info->mem_size);
out_free_info:
kfree(info);
--
1.7.10.2
--
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 05/10] ARM: OMAP2+: gpmc-onenand: provide memory as resource
Currently omap onenand driver invokes gpmc_cs_request, obtains address
space allocated by gpmc to onenand. Remove this, instead use resource
structure; this is now updated with address space for onenand by gpmc
initialization with the help of gpmc_cs_request. And remove usage of
gpmc_cs_request in onenand driver.
This helps in smooth migration of gpmc to driver.
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/gpmc-onenand.c | 23 ++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc-onenand.c
b/arch/arm/mach-omap2/gpmc-onenand.c
index a0fa9bb..71d7c07 100644
--- a/arch/arm/mach-omap2/gpmc-onenand.c
+++ b/arch/arm/mach-omap2/gpmc-onenand.c
@@ -23,11 +23,19 @@
#include
#include
+#defineONENAND_IO_SIZE SZ_128K
+
static struct omap_onenand_platform_data *gpmc_onenand_data;
+static struct resource gpmc_onenand_resource = {
+ .flags = IORESOURCE_MEM,
+};
+
static struct platform_device gpmc_onenand_device = {
.name = "omap2-onenand",
.id = -1,
+ .num_resources = 1,
+ .resource = &gpmc_onenand_resource,
};
static int omap2_onenand_set_async_mode(int cs, void __iomem *onenand_base)
@@ -390,6 +398,8 @@ static int gpmc_onenand_setup(void __iomem *onenand_base,
int *freq_ptr)
void __init gpmc_onenand_init(struct omap_onenand_platform_data *_onenand_data)
{
+ int err;
+
gpmc_onenand_data = _onenand_data;
gpmc_onenand_data->onenand_setup = gpmc_onenand_setup;
gpmc_onenand_device.dev.platform_data = gpmc_onenand_data;
@@ -401,8 +411,19 @@ void __init gpmc_onenand_init(struct
omap_onenand_platform_data *_onenand_data)
gpmc_onenand_data->flags |= ONENAND_SYNC_READ;
}
+ err = gpmc_cs_request(gpmc_onenand_data->cs, ONENAND_IO_SIZE,
+ (unsigned long *)&gpmc_onenand_resource.start);
+ if (err < 0) {
+ pr_err("%s: Cannot request GPMC CS\n", __func__);
+ return;
+ }
+
+ gpmc_onenand_resource.end = gpmc_onenand_resource.start +
+ ONENAND_IO_SIZE - 1;
+
if (platform_device_register(&gpmc_onenand_device) < 0) {
- printk(KERN_ERR "Unable to register OneNAND device\n");
+ pr_err("%s: Unable to register OneNAND device\n", __func__);
+ gpmc_cs_free(gpmc_onenand_data->cs);
return;
}
}
--
1.7.10.2
--
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 04/10] ARM: OMAP2+: gpmc-nand: update resource with memory
Currently omap nand driver uses a field in platform data - phys_base
for passing the address space allocated by gpmc for nand. Use struct
resource instead. With this change omap nand driver has to get
address space from memory resource.
This helps in smooth migration of gpmc to driver.
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/gpmc-nand.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index d4e803c..c0320d2 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -90,12 +90,14 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data)
gpmc_nand_device.dev.platform_data = gpmc_nand_data;
err = gpmc_cs_request(gpmc_nand_data->cs, NAND_IO_SIZE,
- &gpmc_nand_data->phys_base);
+ (unsigned long *)&gpmc_nand_resource.start);
if (err < 0) {
dev_err(dev, "Cannot request GPMC CS\n");
return err;
}
+ gpmc_nand_resource.end = gpmc_nand_resource.start + NAND_IO_SIZE - 1;
+
/* Set timings in GPMC */
err = omap2_nand_gpmc_retime(gpmc_nand_data);
if (err < 0) {
--
1.7.10.2
--
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 03/10] mtd: nand: omap2: handle nand on gpmc
GPMC platform initialization has been modified to fill NAND
platform data with GPMC NAND register details. As these
registers are accessible in NAND driver itself, configure
NAND in GPMC by itself.
Modified prefetch and ecc functions are logically same as
the corresponding exported symbols from GPMC code.
Note: Verfying that other CS have not yet enabled for
prefetch & ecc has to be incorporated. Currently this
causes no issues as there are no boards that use NAND
on multiple CS. With ongoing GPMC driver migration,
perhaps it would be better to consider NAND connected
on multiple CS as a single peripheral using multiple CS.
This would make handling multiple CS issues easier.
Signed-off-by: Afzal Mohammed
---
v2: simplify omap_prefetch_enable function
drivers/mtd/nand/omap2.c | 204 --
1 file changed, 160 insertions(+), 44 deletions(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index d7f681d..1d138fe 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -99,6 +99,16 @@
#define P4e_s(a) (TF(a & NAND_Ecc_P4e) << 0)
#define P4o_s(a) (TF(a & NAND_Ecc_P4o) << 1)
+#definePREFETCH_CONFIG1_CS_SHIFT 24
+#defineECC_CONFIG_CS_SHIFT 1
+#defineCS_MASK 0x7
+#defineENABLE_PREFETCH (0x1 << 7)
+#defineDMA_MPU_MODE_SHIFT 2
+#defineECCSIZE1_SHIFT 22
+#defineECC1RESULTSIZE 0x1
+#defineECCCLEAR0x100
+#defineECC10x1
+
/* oob info generated runtime depending on ecc algorithm and layout selected */
static struct nand_ecclayout omap_oobinfo;
/* Define some generic bad / good block scan pattern which are used
@@ -131,6 +141,7 @@ struct omap_nand_info {
} iomode;
u_char *buf;
int buf_len;
+ struct gpmc_nand_regs reg;
#ifdef CONFIG_MTD_NAND_OMAP_BCH
struct bch_control *bch;
@@ -139,6 +150,63 @@ struct omap_nand_info {
};
/**
+ * omap_prefetch_enable - configures and starts prefetch transfer
+ * @cs: cs (chip select) number
+ * @fifo_th: fifo threshold to be used for read/ write
+ * @dma_mode: dma mode enable (1) or disable (0)
+ * @u32_count: number of bytes to be transferred
+ * @is_write: prefetch read(0) or write post(1) mode
+ */
+static int omap_prefetch_enable(int cs, int fifo_th, int dma_mode,
+ unsigned int u32_count, int is_write, struct omap_nand_info *info)
+{
+ u32 val;
+
+ if (fifo_th > PREFETCH_FIFOTHRESHOLD_MAX)
+ return -1;
+
+ if (readl(info->reg.gpmc_prefetch_control))
+ return -EBUSY;
+
+ /* Set the amount of bytes to be prefetched */
+ writel(u32_count, info->reg.gpmc_prefetch_config2);
+
+ /* Set dma/mpu mode, the prefetch read / post write and
+* enable the engine. Set which cs is has requested for.
+*/
+ val = ((cs << PREFETCH_CONFIG1_CS_SHIFT) |
+ PREFETCH_FIFOTHRESHOLD(fifo_th) | ENABLE_PREFETCH |
+ (dma_mode << DMA_MPU_MODE_SHIFT) | (0x1 & is_write));
+ writel(val, info->reg.gpmc_prefetch_config1);
+
+ /* Start the prefetch engine */
+ writel(0x1, info->reg.gpmc_prefetch_control);
+
+ return 0;
+}
+
+/**
+ * omap_prefetch_reset - disables and stops the prefetch engine
+ */
+static int omap_prefetch_reset(int cs, struct omap_nand_info *info)
+{
+ u32 config1;
+
+ /* check if the same module/cs is trying to reset */
+ config1 = readl(info->reg.gpmc_prefetch_config1);
+ if (((config1 >> PREFETCH_CONFIG1_CS_SHIFT) & CS_MASK) != cs)
+ return -EINVAL;
+
+ /* Stop the PFPW engine */
+ writel(0x0, info->reg.gpmc_prefetch_control);
+
+ /* Reset/disable the PFPW engine */
+ writel(0x0, info->reg.gpmc_prefetch_config1);
+
+ return 0;
+}
+
+/**
* omap_hwcontrol - hardware specific access to control-lines
* @mtd: MTD device structure
* @cmd: command to device
@@ -156,13 +224,13 @@ static void omap_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
if (cmd != NAND_CMD_NONE) {
if (ctrl & NAND_CLE)
- gpmc_nand_write(info->gpmc_cs, GPMC_NAND_COMMAND, cmd);
+ writeb(cmd, info->reg.gpmc_nand_command);
else if (ctrl & NAND_ALE)
- gpmc_nand_write(info->gpmc_cs, GPMC_NAND_ADDRESS, cmd);
+ writeb(cmd, info->reg.gpmc_nand_address);
else /* NAND_NCE */
- gpmc_nand_write(info->gpmc_cs, GPMC_NAND_DATA, cmd);
+ writeb(cmd, info->reg.gpmc_nand_data);
}
}
@@ -196,7 +264,8 @@ static void omap_write_buf8(struct mtd_info *mtd, const
u_
[PATCH v2 02/10] ARM: OMAP2+: gpmc-nand: update gpmc-nand regs
GPMC has NAND registers, update nand platform data with those details
so that NAND driver can configure those by itself instead of using
exported symbols.
Signed-off-by: Afzal Mohammed
---
arch/arm/mach-omap2/gpmc-nand.c|2 ++
arch/arm/plat-omap/include/plat/nand.h |1 +
2 files changed, 3 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 386dec8..d4e803c 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -108,6 +108,8 @@ int __init gpmc_nand_init(struct omap_nand_platform_data
*gpmc_nand_data)
gpmc_cs_configure(gpmc_nand_data->cs, GPMC_CONFIG_RDY_BSY, 1);
}
+ gpmc_update_nand_reg(&gpmc_nand_data->reg, gpmc_nand_data->cs);
+
err = platform_device_register(&gpmc_nand_device);
if (err < 0) {
dev_err(dev, "Unable to register NAND device\n");
diff --git a/arch/arm/plat-omap/include/plat/nand.h
b/arch/arm/plat-omap/include/plat/nand.h
index 67fc506..86e4d9c 100644
--- a/arch/arm/plat-omap/include/plat/nand.h
+++ b/arch/arm/plat-omap/include/plat/nand.h
@@ -29,6 +29,7 @@ struct omap_nand_platform_data {
unsigned long phys_base;
int devsize;
enum omap_ecc ecc_opt;
+ struct gpmc_nand_regs reg;
};
/* minimum size for IO mapping */
--
1.7.10.2
--
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
