Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 03/12/15 11:52, Brian Norris wrote:
> Hi,
> 
> On Thu, Dec 03, 2015 at 11:38:14AM +0530, Roger Quadros wrote:
>> On 03/12/15 10:39, Brian Norris wrote:
>>> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>>>> We do a couple of things in this series which result in
>>>> cleaner device tree implementation, faster perfomance and
>>>> multi-platform support. As an added bonus we get new GPI/Interrupt pins
>>>> for use in the system.
>>>>
>>>> - Establish a custom interface between NAND and GPMC driver. This is
>>>> needed because all of the NAND registers sit in the GPMC register space.
>>>> Some bits like NAND IRQ are even shared with GPMC.
>>>>
>>>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>>>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>>>> This causes performance increase when using prefetch-irq mode.
>>>> 30% increase in read, 17% increase in write in prefetch-irq mode.
>>>>
>>>> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
>>>> driver can be used on non-OMAP platforms. e.g. Keystone.
>>>>
>>>> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
>>>> 2 to 4 of these and most of them would be unused otherwise. It also
>>>> allows a cleaner implementation of NAND Ready pin status for the NAND 
>>>> driver.
>>>>
>>>> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
>>>>
>>>> This series is available at
>>>> g...@github.com:rogerq/linux.git
>>>> in branch
>>>> for-v4.4/gpmc-v3
>>>>
>>>> cheers,
>>>> -roger
>>>>
>>>> Changelog:
>>>> v3:
>>>> -Fixed and tested NAND using legacy boot on omap3-beagle.
>>>> -Support rising and falling edge interrupts on WAITpins.
>>>> -Update DT node of all gpmc users.
>>>
>>> The MTD stuff looks mostly good to me know. I've made all my comments
>>> for now, but I'm not sure how you're going to end up rebasing/splitting
>>> and what you're going to do with the irqchip removal, so I'll refrain
>>> from ack's for now. Hopefully I can either ack or merge v4.
>>
>> I'll retain the irqchip model for now and send a v4 with all comments
>> addressed and better subsystem wise patch split.
>>
>>>
>>> I brought it up on one other patch, but it's not really clear to me what
>>> the split is on board file vs. device tree handling, since you seem to
>>> have a combination of both (i.e., platform data that passes along device
>>> nodes). What's the plan on that?
>>
>> Platform data no longer passes device nodes. We're either true device tree
>> or plain legacy. The deprecated fields are no longer used once the series is
>> applied.
> 
> Well, they're still sorta used (you assign info->of_node =
> pdata->of_node, for instance). As dicussed in the other thread, I think
> we can avoid the deprecation part and just kill the fields though, and
> that would make things clearer.
> 
>>> And of course, there's the question of how exactly to merge this, given
>>> the:
>>> (1) conflicts already existing in the MTD dev tree
>>
>> I'll rebase the series on top of MTD dev tree.
> 
> OK. FWIW, we so far only need to base them on commit a61ae81a1907 ("mtd:
> nand: drop unnecessary partition parser data"). Maybe when queueing up a
> branch, that'd be the best starting point for Tony, so he doesn't need
> to have all of MTD's stuff in his tree too? I can set up a signed tag or
> something, if that would be helpful.
> 
> But for sending patches, the latest l2-mtd.git is fine too.
> 
>>> (2) this touches several trees, often in the same patch and
>>
>> I'll try my best to split the patches but not sure if this could be 100%
>> clean split without functional breakage.
>>
>>> (3) even if the patches were split out a little better into MTD and
>>> non-MTD stuff, I think there would still be dependencies such that
>>> we'd need at least 1 (probably 2) cross merges to get it all
>>> straight
>>
>> That is correct.
>> Is it OK if functionality breaks if for example only MTD changes are 
>> considered?
> 
> I think I may have misunderstood the branch proposal. If Tony queues up:
> 
>   l2-mtd.git (or just up to commit a61ae81a1907)
>   +
>   your patches
> 
> and I pull that back into l2-mtd.git as well, then we don't need to
> worry about patches that touch multiple "trees". Just do whatever makes
> things clearest, including disregarding some of my comments along the
> line of (3).

Tony,

Are you fine with this?

cheers,
-roger
--
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 00/13] USB: OTG/DRD Core functionality

[Roger Quadros]

Peter,

On 03/12/15 13:49, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:11PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> This series centralizes OTG/Dual-role functionality in the kernel.
>> As of now I've got Dual-role functionality working pretty reliably on
>> dra7-evm and am437x-gp-evm.
>>
>> DWC3 controller and platform related patches will be sent separately.
>>
>> Series is based on Greg's usb-next tree.
> 
> Hi Roger,
> 
> Will you go on for this patch set?

Yes, but I can only work on this from Feb onwards.

cheers,
-roger
> 
> Peter
>>
>> Changelog:
>> -
>> v4:
>> - Added DT support for tying otg-controller to host and gadget
>>  controllers. For DT we no longer have the constraint that
>>  OTG controller needs to be parent of host and gadget. They can be
>>  tied together using the "otg-controller" property.
>> - Relax the requirement for DT case that otg controller must register before
>>  host/gadget. We maintain a wait list of host/gadget devices
>>  waiting on the otg controller.
>> - Use a single struct usb_otg for otg data.
>> - Don't override host/gadget start/stop APIs. Let the controller
>>  drivers do what they want as they know best. Helper API is provided
>>  for controller start/stop that controller driver can use.
>> - Introduce struct usb_otg_config to pass the otg capabilities,
>>  otg ops and otg timer timeouts during otg controller registration.
>> - rebased on Greg's usb.git/usb-next
>>
>> v3:
>> - all otg related definations now in otg.h
>> - single kernel config USB_OTG to enable OTG core and FSM.
>> - resolved symbol dependency issues.
>> - use dev_vdbg instead of VDBG() in usb-otg-fsm.c
>> - rebased on v4.2-rc1
>>
>> v2:
>> - Use add/remove_hcd() instead of start/stop_hcd() to enable/disable
>>  the host controller
>> - added dual-role-device (DRD) state machine which is a much simpler
>>  mode of operation when compared to OTG. Here we don't support fancy
>>  OTG features like HNP, SRP, on the fly role-swap. The mode of operation
>>  is determined based on ID pin (cable type) and the role doesn't change
>>  till the cable type changes.
>>
>> Why?:
>> 
>>
>> Most of the OTG drivers have been dealing with the OTG state machine
>> themselves and there is a scope for code re-use. This has been
>> partly addressed by the usb/common/usb-otg-fsm.c but it still
>> leaves the instantiation of the state machine and OTG timers
>> to the controller drivers. We re-use usb-otg-fsm.c but
>> go one step further by instantiating the state machine and timers
>> thus making it easier for drivers to implement OTG functionality.
>>
>> Newer OTG cores support standard host interface (e.g. xHCI) so
>> host and gadget functionality are no longer closely knit like older
>> cores. There needs to be a way to co-ordinate the operation of the
>> host and gadget in OTG mode. i.e. to stop and start them from a
>> central location. This central location should be the USB OTG core.
>>
>> Host and gadget controllers might be sharing resources and can't
>> be always running. One has to be stopped for the other to run.
>> This can't be done as of now and can be done from the OTG core.
>>
>> What?:
>> -
>>
>> The OTG core instantiates the OTG/DRD Finite State Machine
>> per OTG controller and manages starting/stopping the
>> host and gadget controllers based on the bus state.
>> 
>> It provides APIs for the following
>> 
>> - Registering an OTG capable controller
>> struct otg_fsm *usb_otg_register(struct device *dev,
>>  struct usb_otg_config *config);
>>
>> int usb_otg_unregister(struct device *dev);
>>
>> - Registering Host controllers to OTG core (used by hcd-core)
>> int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>>  unsigned long irqflags, struct otg_hcd_ops *ops);
>> int usb_otg_unregister_hcd(struct usb_hcd *hcd);
>>
>>
>> - Registering Gadget controllers to OTG core (used by udc-core)
>> int usb_otg_register_gadget(struct usb_gadget *gadget,
>> struct otg_gadget_ops *ops);
>> int usb_otg_unregister_gadget(struct usb_gadget *gadget);
>>
>>
>> - Providing inputs to and kicking the OTG state machine
>> void usb_otg_sync_inputs(struct otg_fsm *fsm);
>> int usb_otg_kick_fsm(struct device *hcd_gcd_device);
>>
>> - Getting controller device structure from OTG state machine ins

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Brian,

On 03/12/15 10:39, Brian Norris wrote:
> Hi,
> 
> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>> Hi,
>>
>> We do a couple of things in this series which result in
>> cleaner device tree implementation, faster perfomance and
>> multi-platform support. As an added bonus we get new GPI/Interrupt pins
>> for use in the system.
>>
>> - Establish a custom interface between NAND and GPMC driver. This is
>> needed because all of the NAND registers sit in the GPMC register space.
>> Some bits like NAND IRQ are even shared with GPMC.
>>
>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>> This causes performance increase when using prefetch-irq mode.
>> 30% increase in read, 17% increase in write in prefetch-irq mode.
>>
>> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
>> driver can be used on non-OMAP platforms. e.g. Keystone.
>>
>> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
>> 2 to 4 of these and most of them would be unused otherwise. It also
>> allows a cleaner implementation of NAND Ready pin status for the NAND driver.
>>
>> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
>>
>> This series is available at
>> g...@github.com:rogerq/linux.git
>> in branch
>> for-v4.4/gpmc-v3
>>
>> cheers,
>> -roger
>>
>> Changelog:
>> v3:
>> -Fixed and tested NAND using legacy boot on omap3-beagle.
>> -Support rising and falling edge interrupts on WAITpins.
>> -Update DT node of all gpmc users.
> 
> The MTD stuff looks mostly good to me know. I've made all my comments
> for now, but I'm not sure how you're going to end up rebasing/splitting
> and what you're going to do with the irqchip removal, so I'll refrain
> from ack's for now. Hopefully I can either ack or merge v4.

I'll retain the irqchip model for now and send a v4 with all comments
addressed and better subsystem wise patch split.

> 
> I brought it up on one other patch, but it's not really clear to me what
> the split is on board file vs. device tree handling, since you seem to
> have a combination of both (i.e., platform data that passes along device
> nodes). What's the plan on that?

Platform data no longer passes device nodes. We're either true device tree
or plain legacy. The deprecated fields are no longer used once the series is
applied.

> 
> And of course, there's the question of how exactly to merge this, given
> the:
> (1) conflicts already existing in the MTD dev tree

I'll rebase the series on top of MTD dev tree.

> (2) this touches several trees, often in the same patch and

I'll try my best to split the patches but not sure if this could be 100%
clean split without functional breakage.

> (3) even if the patches were split out a little better into MTD and
> non-MTD stuff, I think there would still be dependencies such that
> we'd need at least 1 (probably 2) cross merges to get it all
> straight

That is correct.
Is it OK if functionality breaks if for example only MTD changes are considered?

cheers,
-roger
--
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 11/27] mtd: nand: omap: Clean up device tree support

[Roger Quadros]

Brian,

On 03/12/15 09:59, Brian Norris wrote:
> Hi Roger,
> 
> On Tue, Oct 06, 2015 at 01:35:48PM +0300, Roger Quadros wrote:
>> Move NAND specific device tree parsing to NAND driver.
>>
>> The NAND controller node must have a compatible id, register space
>> resource and interrupt resource.
>>
>> Signed-off-by: Roger Quadros <rog...@ti.com>
> 
> This one's going to need rebased, as there are some conflicting of_node
> changes in l2-mtd.git.

Al right. I'll rebase on top of l2-mtd.git
> 
>> ---
>> v4: Warn if using older incompatible DT i.e. compatible property not present
>> in nand node.
>>
>>  arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
>>  drivers/memory/omap-gpmc.c   | 143 
>> +++
>>  drivers/mtd/nand/omap2.c | 136 +
>>  include/linux/platform_data/mtd-nand-omap2.h |   3 +-
>>  4 files changed, 155 insertions(+), 132 deletions(-)
> 
> Also, this is going to be hard to manage across trees, as you touch
> three drivers all at once. Is it not possible to split any of this apart
> better?

Will need some more effort and I can do it. Butm if we're going to start
an with immutable branch with everything in, is it worth the effort?
> 
>>
>> diff --git a/arch/arm/mach-omap2/gpmc-nand.c 
>> b/arch/arm/mach-omap2/gpmc-nand.c
>> index ffe646a..e07ca27 100644
>> --- a/arch/arm/mach-omap2/gpmc-nand.c
>> +++ b/arch/arm/mach-omap2/gpmc-nand.c
>> @@ -95,10 +95,7 @@ int gpmc_nand_init(struct omap_nand_platform_data 
>> *gpmc_nand_data,
>>  gpmc_nand_res[1].start = gpmc_get_irq();
>>  
>>  memset(, 0, sizeof(struct gpmc_settings));
>> -if (gpmc_nand_data->of_node)
>> -gpmc_read_settings_dt(gpmc_nand_data->of_node, );
>> -else
>> -gpmc_set_legacy(gpmc_nand_data, );
>> +gpmc_set_legacy(gpmc_nand_data, );
>>  
>>  s.device_nand = true;
>>  
>> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
>> index e75226d..318c187 100644
>> --- a/drivers/memory/omap-gpmc.c
>> +++ b/drivers/memory/omap-gpmc.c
>> @@ -29,7 +29,6 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>>  #include 
>>  



>>  
>> -ppdata.of_node = pdata->of_node;
>> -mtd_device_parse_register(mtd, NULL, , pdata->parts,
>> -  pdata->nr_parts);
>> +if (dev->of_node) {
>> +ppdata.of_node = dev->of_node;
> 
> The latest l2-mtd.git changed how the partitions' of_node is passed. Now
> this is handled by nand_set_flash_node().

OK.
> 
>> +mtd_device_parse_register(mtd, NULL, , NULL, 0);
>> +
>> +} else {
>> +mtd_device_register(mtd, pdata->parts, pdata->nr_parts);
>> +}
>>  
>>  platform_set_drvdata(pdev, mtd);
>>  
>> @@ -2083,11 +2173,17 @@ static int omap_nand_remove(struct platform_device 
>> *pdev)
>>  return 0;
>>  }
>>  
>> +static const struct of_device_id omap_nand_ids[] = {
>> +{ .compatible = "ti,omap2-nand", },
>> +{},
>> +};
>> +
>>  static struct platform_driver omap_nand_driver = {
>>  .probe  = omap_nand_probe,
>>  .remove = omap_nand_remove,
>>  .driver = {
>>  .name   = DRIVER_NAME,
>> +.of_match_table = of_match_ptr(omap_nand_ids),
>>  },
>>  };
>>  
>> diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
>> b/include/linux/platform_data/mtd-nand-omap2.h
>> index a067f58..ff27e5a 100644
>> --- a/include/linux/platform_data/mtd-nand-omap2.h
>> +++ b/include/linux/platform_data/mtd-nand-omap2.h
>> @@ -76,11 +76,10 @@ struct omap_nand_platform_data {
>>  int devsize;
>>  enum omap_ecc   ecc_opt;
>>  
>> -/* for passing the partitions */
>> -struct device_node  *of_node;
>>  struct device_node  *elm_of_node;
>>  
>>  /* deprecated */
>>  struct gpmc_nand_regs   reg;
>> +struct device_node  *of_node;
> 
> I'm a little confused here. Do you have a mixed platform data / device
> tree setup here? That's odd. (It also seems if that was really
> necessary, you could have the board file set pdev->dev.of_node before
> registering it, then you don't need this field.) But really, if you're
> partly using device tree, can't you just convert completely? Or is this
> a two-phase p

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Brian,

On 02/12/15 08:56, Brian Norris wrote:
> Hi Roger,
> 
> On Tue, Dec 01, 2015 at 04:41:16PM +0200, Roger Quadros wrote:
>> On 30/11/15 21:54, Brian Norris wrote:
>>> On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote:
>>>> On 26/10/15 23:23, Brian Norris wrote:
>>>>> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>>>>>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>>>>>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>>>>>> This causes performance increase when using prefetch-irq mode.
>>>>>> 30% increase in read, 17% increase in write in prefetch-irq mode.
>>>>>
>>>>> Have you pinpointed the exact causes for the performance increase, or
>>>>> can you give an educated guess? AIUI, you're reducing the number of
>>>>> interrupts needed for NAND prefetch mode, but you're also removing a bit
>>>>> of abstraction and implementing hooks that look awfully like the
>>>>> existing abstractions:
>>>>>
>>>>> +   int (*nand_irq_enable)(enum gpmc_nand_irq irq);
>>>>> +   int (*nand_irq_disable)(enum gpmc_nand_irq irq);
>>>>> +   void (*nand_irq_clear)(enum gpmc_nand_irq irq);
>>>>> +   u32 (*nand_irq_status)(void);
>>>>>
>>>>> That's not really a problem if there's a good reason for them (brcmnand
>>>>> implements similar hooks because of quirks in the implementation of
>>>>> interrupts across various BRCM SoCs, and it's not worth writing irqchip
>>>>> drivers for those cases). I'm mainly curious for an explanation.
>>>>
>>>> I have both implementations with me. My guess is that the 20% performance
>>>> gain is due to absence of irqchip/irqdomain translation code.
>>>> I haven't investigated further though.
>>>
>>> I don't have much context for whether this makes sense or not. According
>>> to your tests, you're getting ~800K interrupts over ~15 seconds. So
>>> should you start noticing performance hits due to abstraction at 53K
>>> interrupts per second?
>>
>> Yes, this was my understanding.
> 
> Am I computing wrong, or is that a pretty insane rate of interrupts?

I don't have the test board with me right now and so can't tell you
for sure if the mtd tests took 15 seconds or more.

I can try it out on a different board that I have and let you know
for sure about how many interrupts we get per second.
> 
>>> But anyway, I'm not sure that completely answered my question. My
>>> question was whether you were removing the irqchip code solely for
>>> performance reasons, or are there others?
>>
>> Yes. Only for performance reasons.
> 
> Hmm, that's not my favorite answer. I'd prefer that more analysis was
> done here before scrapping irqchip...

I agree. We could retain the irqchip model till we have more satisfying
analysis.

> 
> But maybe that's not too bad. It seems like your patch set overall is a
> net positive for disentangling some of arch/ and drivers/.

:)

> 
> I'll take another pass over your patch set, but if things are looking
> better, how do you expect to merge this? There are significant portions
> that touch at least 2 or 3 different subsystem trees, AFAICT.

Tony could create an immutable branch with all the dts and memory changes.
You could base the mtd changes on top of that?

cheers,
-roger
--
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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Hi Brian,

On 30/11/15 21:54, Brian Norris wrote:
> Hi Roger,
> 
> On Tue, Oct 27, 2015 at 11:37:03AM +0200, Roger Quadros wrote:
>> On 26/10/15 23:23, Brian Norris wrote:
>>> I'm not too familiar with OMAP platforms, and I might have missed out on
>>> prior discussions/context, so please forgive if I'm asking silly or old
>>> questions here.
>>
>> No worries at all.
>>
>>>
>>> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>>>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>>>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>>>> This causes performance increase when using prefetch-irq mode.
>>>> 30% increase in read, 17% increase in write in prefetch-irq mode.
>>>
>>> Have you pinpointed the exact causes for the performance increase, or
>>> can you give an educated guess? AIUI, you're reducing the number of
>>> interrupts needed for NAND prefetch mode, but you're also removing a bit
>>> of abstraction and implementing hooks that look awfully like the
>>> existing abstractions:
>>>
>>> +   int (*nand_irq_enable)(enum gpmc_nand_irq irq);
>>> +   int (*nand_irq_disable)(enum gpmc_nand_irq irq);
>>> +   void (*nand_irq_clear)(enum gpmc_nand_irq irq);
>>> +   u32 (*nand_irq_status)(void);
>>>
>>> That's not really a problem if there's a good reason for them (brcmnand
>>> implements similar hooks because of quirks in the implementation of
>>> interrupts across various BRCM SoCs, and it's not worth writing irqchip
>>> drivers for those cases). I'm mainly curious for an explanation.
>>
>> I have both implementations with me. My guess is that the 20% performance
>> gain is due to absence of irqchip/irqdomain translation code.
>> I haven't investigated further though.
> 
> I don't have much context for whether this makes sense or not. According
> to your tests, you're getting ~800K interrupts over ~15 seconds. So
> should you start noticing performance hits due to abstraction at 53K
> interrupts per second?

Yes, this was my understanding.

> 
> But anyway, I'm not sure that completely answered my question. My
> question was whether you were removing the irqchip code solely for
> performance reasons, or are there others?

Yes. Only for performance reasons.

> 
>> Another concern I have is that I'm not using any locking around
>> gpmc_nand_irq_enable/disable(). Could this pose problems in multiple NAND
>> use cases? My understanding is that it should not as the controller access
>> is serialized between multiple NAND chips.
> 
> Right, if you're touching just a NAND interrupt, and it's only used by a
> single instance of this NAND controller, then the NAND controller
> serialization code will handle this for you.

OK.

cheers,
-roger
--
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: Clock usbhost_48m_fck didn't enable in 100000 tries and crash

[Roger Quadros]

Daniel,

On 24/11/15 15:36, Daniel. wrote:
> Hi Michael
> 
> About this:
> "Two bugs are fixed by this patch.  First, OMAP hardware only supports
> target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
> should not wait for these clocks to enable.  So, split the appropriate
> clocks into ES1 and ES2+ variants, so that kernels running on ES1
> devices won't try to wait."
> 
> My chip is ES1. I think that ES2+ code is running since I see these waits
> ocurring on code... I'll take a better look in this, thanks again!

Did you figure out if this clock is really present in the ES1 TRM?
If it is not then why is the kernel trying to enable this clock?

If it is present in the ES1 TRM then why is the kernel trying to wait
for it to be enabled? AFAIK there is no need to wait for the clock to be
enabled as there is no such status bit on ES1.

cheers,
-roger

> 
> Does anyone know how to check if a clock is enabled?
> 
> Regards,
> 
> 2015-11-23 18:24 GMT-02:00 Daniel. :
>> I've already tried, it fails to apply. My tree is based on last commit from
>> TI linux-omap3 (4f1fb3bea4cc381c76e8e439f8af393c1a698dfc) so I *think*
>> that this is already applied (since come from the same tree).
>>
>> I will try to apply it by hand
>> Thanks!
>> Regards,
>>
>> 2015-11-23 18:10 GMT-02:00 Michael Trimarchi :
>>> Hi
>>>
>>> Can you check if you have this patch in?
>>>
>>> commit 3c82e229f09a6acc8d24dc27c5e0e60b1d7161c2
>>> Author: Paul Walmsley 
>>> Date:   Fri Jul 24 19:44:06 2009 -0600
>>>
>>> OMAP3 clock: correct module IDLEST bits: SSI; DSS; USBHOST; HSOTGUSB
>>>
>>> Fix two bugs in the OMAP3 clock tree pertaining to the SSI, DSS,
>>> USBHOST, and HSOTGUSB devices.  These devices are both interconnect
>>> initiators and targets.  Without this patch, clk_enable()s on clocks for
>>> these modules can be very high latency (potentially up to ~200
>>> milliseconds) and message such as the following are generated:
>>>
>>> Clock usbhost_48m_fck didn't enable in 10 tries
>>>
>>> Two bugs are fixed by this patch.  First, OMAP hardware only supports
>>> target CM_IDLEST register bits on ES2+ chips and beyond.  ES1 chips
>>> should not wait for these clocks to enable.  So, split the appropriate
>>> clocks into ES1 and ES2+ variants, so that kernels running on ES1
>>> devices won't try to wait.
>>>
>>> Second, the current heuristic in omap2_clk_dflt_find_idlest() will
>>> fail for these clocks.  It assumes that the CM_IDLEST bit to wait upon
>>> is the same as the CM_*CLKEN bit, which is false[1].  Fix by
>>> implementing custom clkops .find_idlest function pointers for the
>>> appropriate clocks that return the correct slave IDLEST bit shift.
>>>
>>> This was originally fixed in the linux-omap kernel during 2.6.29 in a
>>> slightly different manner[2][3].
>>>
>>>
>>> On Mon, Nov 23, 2015 at 9:06 PM, Daniel.  wrote:
 Hi,

 Building as built-in doesn't solve my problem. The difference is that
 when compiled as module the dump shows up when I load it, and when is
 built-in the dump shows up at boot time. Also when built-in the
 problem seems to ocurr when device is reseted (on ehci_omap_stop) and
 the first stack dump is followed by much more other dumps. At the end
 I can see something like: "Fixing recursive fault but reboot is
 needed!"


 Here is the module info:
 root@csi:~# modinfo ehci-hcd
 filename:   /lib/modules/2.6.37+/kernel/drivers/usb/host/ehci-hcd.ko
 author: Felipe Balbi 
 author: Texas Instruments, Inc.
 alias:  platform:omap-ehci
 license:GPL
 author: David Brownell
 description:USB 2.0 'Enhanced' Host Controller (EHCI) Driver
 srcversion: B282C11CACFB9E75921367C
 depends:
 vermagic:   2.6.37+ mod_unload modversions ARMv7
 parm:   log2_irq_thresh:log2 IRQ latency, 1-64 microframes (int)
 parm:   park:park setting; 1-3 back-to-back async packets (uint)
 parm:   ignore_oc:ignore bogus hardware overcurrent indications 
 (bool)
 parm:   hird:host initiated resume duration, +1 for each 75us
  (int)
 root@csi:~#


 Best regards,

 2015-11-23 17:55 GMT-02:00 Michael Trimarchi 
 :
> Hi
>
> On Mon, Nov 23, 2015 at 8:05 PM, Daniel.  wrote:
>> Hi Michael,
>>
>> It's a plain linux. I'm considering upgrading kernel as last option.
>> Variscite doesn't
>> support another kernel for this SoM so this would be a really hard
>> work. I'm looking
>> for a solution on this kernel and mainly trying to understand why
>> usbhost_48m_fck
>> is not getting enabled. I'm contacting Variscite in 

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Brian,

On 27/10/15 11:37, Roger Quadros wrote:
> Hi Brian,
> 
> On 26/10/15 23:23, Brian Norris wrote:
>> Hi Roger,
>>
>> I'm not too familiar with OMAP platforms, and I might have missed out on
>> prior discussions/context, so please forgive if I'm asking silly or old
>> questions here.
> 
> No worries at all.
> 
>>
>> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>>> This causes performance increase when using prefetch-irq mode.
>>> 30% increase in read, 17% increase in write in prefetch-irq mode.
>>
>> Have you pinpointed the exact causes for the performance increase, or
>> can you give an educated guess? AIUI, you're reducing the number of
>> interrupts needed for NAND prefetch mode, but you're also removing a bit
>> of abstraction and implementing hooks that look awfully like the
>> existing abstractions:
>>
>> +   int (*nand_irq_enable)(enum gpmc_nand_irq irq);
>> +   int (*nand_irq_disable)(enum gpmc_nand_irq irq);
>> +   void (*nand_irq_clear)(enum gpmc_nand_irq irq);
>> +   u32 (*nand_irq_status)(void);
>>
>> That's not really a problem if there's a good reason for them (brcmnand
>> implements similar hooks because of quirks in the implementation of
>> interrupts across various BRCM SoCs, and it's not worth writing irqchip
>> drivers for those cases). I'm mainly curious for an explanation.
> 
> I have both implementations with me. My guess is that the 20% performance
> gain is due to absence of irqchip/irqdomain translation code.
> I haven't investigated further though.
> 
> Another concern I have is that I'm not using any locking around
> gpmc_nand_irq_enable/disable(). Could this pose problems in multiple NAND
> use cases? My understanding is that it should not as the controller access
> is serialized between multiple NAND chips.
> 
> However I do need to add some locking as the GPMC_IRQENABLE register is shared
> between NAND and GPMC driver.
> 
> NOTE: We are not using prefetch-irq mode for any of the OMAP boards because
> of lesser performance than prefetch-polled mode. So if the less performance
> for an unused mode is a lesser concern compared to cleaner code then
> I can resend this with the irqdomain implementation.
> 
> Below are performance logs of irqdomain vs hooks.

Any further comments?

cheers,
-roger

> 
> --
> cheers,
> -roger
> 
> test logs.
> 
> for-v4.4/gpmc-v2 - irqdomain with prefetch-irq. No ready pin.
> 
> 
> [   67.696631] 
> [   67.698201] =
> [   67.704254] mtd_speedtest: MTD device: 8
> [   67.708373] mtd_speedtest: MTD device size 8388608, eraseblock size 
> 131072, page size 2048, count of eraseblocks 64, pages per eraseblock 64, OOB 
> size 64
> [   67.723701] mtd_test: scanning for bad eraseblocks
> [   67.735468] mtd_test: scanned 64 eraseblocks, 0 are bad
> [   67.772861] mtd_speedtest: testing eraseblock write speed
> [   70.372903] mtd_speedtest: eraseblock write speed is 3156 KiB/s
> [   70.379104] mtd_speedtest: testing eraseblock read speed
> [   72.594169] mtd_speedtest: eraseblock read speed is 3708 KiB/s
> [   72.656375] mtd_speedtest: testing page write speed
> [   75.213646] mtd_speedtest: page write speed is 3208 KiB/s
> [   75.219311] mtd_speedtest: testing page read speed
> [   77.343639] mtd_speedtest: page read speed is 3865 KiB/s
> [   77.405236] mtd_speedtest: testing 2 page write speed
> [   80.039702] mtd_speedtest: 2 page write speed is 3114 KiB/s
> [   80.045561] mtd_speedtest: testing 2 page read speed
> [   82.175098] mtd_speedtest: 2 page read speed is 3856 KiB/s
> [   82.180849] mtd_speedtest: Testing erase speed
> [   82.241548] mtd_speedtest: erase speed is 146285 KiB/s
> [   82.246920] mtd_speedtest: Testing 2x multi-block erase speed
> [   82.284789] mtd_speedtest: 2x multi-block erase speed is 264258 KiB/s
> [   82.291551] mtd_speedtest: Testing 4x multi-block erase speed
> [   82.329358] mtd_speedtest: 4x multi-block erase speed is 264258 KiB/s
> [   82.336116] mtd_speedtest: Testing 8x multi-block erase speed
> [   82.373903] mtd_speedtest: 8x multi-block erase speed is 264258 KiB/s
> [   82.380648] mtd_speedtest: Testing 16x multi-block erase speed
> [   82.418503] mtd_speedtest: 16x multi-block erase speed is 264258 KiB/s
> [   82.425356] mtd_speedtest: Testing 32x multi-block erase speed
> [   82.463227] mtd_speedtest: 32x multi-block erase speed is 264258 KiB/s
> [   82.470066] mtd_speedtest: Testing 64x multi-

Re: [PATCH 1/3] ARM: OMAP2+: clockdomain: Add mechanism for disabling HW_AUTO

[Roger Quadros]

Hi,

On 03/09/15 10:39, Roger Quadros wrote:
> On 28/07/15 14:34, Roger Quadros wrote:
>> Paul,
>>
>> On 16/07/15 16:56, Roger Quadros wrote:
>>> On 16/07/15 04:25, Paul Walmsley wrote:
>>>> Hi
>>>>
>>>> On Tue, 23 Jun 2015, Roger Quadros wrote:
>>>>
>>>>> For some hwmods (e.g. DCAN on DRA7) we need the possibility to
>>>>> disable HW_AUTO for the clockdomain while the module is active.
>>>>>
>>>>> To achieve this there needs to be a refcounting mechanism to
>>>>> indicate whether any module in the clockdomain has requested
>>>>> to disable HW_AUTO. We keep track of this in 'noidlecount'.
>>>>>
>>>>> Hwmod code must use clkdm_hwmod_prevent_hwauto() to prevent
>>>>> HW_AUTO of the clockdomain in the future clkdm_hwmod_hwauto() calls.
>>>>>
>>>>> It must use clkdm_hwmod_allow_hwauto() to allow HW_AUTO in
>>>>> the future clkdm_hwmod_hwauto() calls.
>>>>>
>>>>> Hwmod code must use clkdm_hwmod_allow_hwauto() whenever it needs
>>>>> to request HW_AUTO of any clockdomain. (Typically after it has
>>>>> enabled the module).
>>>>
>>>> How about just modifying clkdm_{allow,deny}_idle*() to do the 
>>>> idle-block-counting?  The default state would be to allow idle, assuming 
>>>> that the clockdomain flags support that state, and then clkdm_deny_idle*() 
>>>> would increment the idle-blocking count, clkdm_allow_idle*() would 
>>>> decrement it.  Then on the 0 -> 1 or 1 -> 0 transitions, the hardware 
>>>> would be reprogrammed appropiately.
>>>
>>> That is not possible with current hwmod code as clkdm_allow_idle() and 
>>> clkdm_deny_idle()
>>> are not symmetrically placed.
>>>
>>> The usual flow is
>>> clkdm_enable_hwmod();
>>> if (hwsup)
>>> clkdm_allow_idle();
>>>
>>> This is mainly because it is redundant to disable auto idle before enableing
>>> (SW_WKUP) the clockdomain.
>>>
>>> If we take your proposal above then we have to modify all users like so.
>>>
>>> if (hwsup)
>>> clkdm_deny_idle();
>>> clkdm_enable_hwmod();
>>> if (hwsup)
>>> clkdm_allow_idle();
>>>
>>> Is this really what we want?
>>
>> Any comments on this?
> 
> Paul. I'm waiting on your input to rework this series if needed.
> Early input would be much appreciated. Thanks.

Not sure if Paul is receiving my e-mails but I'd like
others to give their opinion on how we can proceed with this. Thanks.

cheers,
-roger

> 
>>
>>>
>>>>
>>>> Anyway, seems like that would avoid races with any 
>>>> clkdm_{allow,deny}_idle*() users.  
>>>>
>>>> A few other comments below:
>>>>
>>>>
>>>>>
>>>>> Signed-off-by: Roger Quadros <rog...@ti.com>
>>>>> ---
>>>>>  arch/arm/mach-omap2/clockdomain.c | 71 
>>>>> +++
>>>>>  arch/arm/mach-omap2/clockdomain.h |  5 +++
>>>>>  2 files changed, 76 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm/mach-omap2/clockdomain.c 
>>>>> b/arch/arm/mach-omap2/clockdomain.c
>>>>> index 2da3b5e..a7190d2 100644
>>>>> --- a/arch/arm/mach-omap2/clockdomain.c
>>>>> +++ b/arch/arm/mach-omap2/clockdomain.c
>>>>> @@ -1212,6 +1212,77 @@ ccd_exit:
>>>>>   return 0;
>>>>>  }
>>>>>  
>>>>> +/*
>>>>> + * prevent future hwauto for this clkdm. If clkdm->usecount becomes 
>>>>> hwauto isn't prevented.
>>>>> + * It will only prevnt future hwauto but not bring it out of hwauto.
>>>>> + */
>>>>
>>>> If you modify clkdm_{allow,deny}_idle*(), this shouldn't be a major issue 
>>>> - but all of the function comments should be fixed so that they are 
>>>> understandable and follow kernel-doc-nano specs.
>>>
>>> OK for updating the comments.
>>>
>>>
>>> cheers,
>>> -roger
>>>
>>>>
>>>>> +int clkdm_hwmod_prevent_hwauto(struct clockdomain *clkdm, struct 
>>>>> omap_hwmod *oh)
>>>>> +{
>>>>> + /* The clkdm attribute does not exist yet prior OMAP4 */

Re: [PATCH v2 16/16] mmc: host: omap_hsmmc: use "mmc_of_parse_voltage" to get ocr_avail

[Roger Quadros]

Hi,

On 25/08/15 17:50, Ulf Hansson wrote:
> On 3 August 2015 at 14:26, Kishon Vijay Abraham I <kis...@ti.com> wrote:
>> From: Roger Quadros <rog...@ti.com>
>>
>> For platforms that doesn't have explicit regulator control in MMC,
>> populate voltage-ranges in MMC device tree node and use
>> mmc_of_parse_voltage to get ocr_avail
> 
> I don't like this.
> 
> If we are able to fetch the OCR mask via an external regulator, that
> shall be done.

Agreed.
> 
> I think the mmc_of_parse_voltage() API and the corresponding DT
> binding it parses, should be used for those HW when we don't have an
> external regulator to use. For example if the MMC controller itself
> somehow controls the voltage levels. Is that really the case for you?

What shall be done if there is no software control of the external regulator
and it is fixed at a certain voltage?

cheers,
-roger

> 
> Kind regards
> Uffe
> 
>>
>> Signed-off-by: Roger Quadros <rog...@ti.com>
>> Signed-off-by: Lokesh Vutla <lokeshvu...@ti.com>
>> Signed-off-by: Murali Karicheri <m-kariche...@ti.com>
>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
>> Signed-off-by: Kishon Vijay Abraham I <kis...@ti.com>
>> ---
>>  .../devicetree/bindings/mmc/ti-omap-hsmmc.txt  |2 ++
>>  drivers/mmc/host/omap_hsmmc.c  |9 -
>>  2 files changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt 
>> b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> index 76bf087..2408e87 100644
>> --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
>> @@ -22,6 +22,8 @@ ti,dual-volt: boolean, supports dual voltage cards
>>  ti,non-removable: non-removable slot (like eMMC)
>>  ti,needs-special-reset: Requires a special softreset sequence
>>  ti,needs-special-hs-handling: HSMMC IP needs special setting for handling 
>> High Speed
>> +voltage-ranges: Specify the voltage range supported if regulator framework
>> +isn't enabled.
>>  dmas: List of DMA specifiers with the controller specific format
>>  as described in the generic DMA client binding. A tx and rx
>>  specifier is required.
>> diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
>> index 15973f1..d884d8f 100644
>> --- a/drivers/mmc/host/omap_hsmmc.c
>> +++ b/drivers/mmc/host/omap_hsmmc.c
>> @@ -2184,7 +2184,13 @@ static int omap_hsmmc_probe(struct platform_device 
>> *pdev)
>> goto err_irq;
>> }
>>
>> -   mmc->ocr_avail = mmc_pdata(host)->ocr_mask;
>> +   if (!mmc_pdata(host)->ocr_mask) {
>> +   ret = mmc_of_parse_voltage(pdev->dev.of_node, 
>> >ocr_avail);
>> +   if (ret)
>> +   goto err_parse_voltage;
>> +   } else {
>> +   mmc->ocr_avail = mmc_pdata(host)->ocr_mask;
>> +   }
>>
>> omap_hsmmc_disable_irq(host);
>>
>> @@ -2224,6 +2230,7 @@ static int omap_hsmmc_probe(struct platform_device 
>> *pdev)
>>
>>  err_slot_name:
>> mmc_remove_host(mmc);
>> +err_parse_voltage:
>> omap_hsmmc_reg_put(host);
>>  err_irq:
>> device_init_wakeup(>dev, false);
>> --
>> 1.7.9.5
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Roger Quadros]

On 26/10/15 22:49, Brian Norris wrote:
> + others
> 
> A few comments below.
> 
> On Fri, Sep 18, 2015 at 05:53:40PM +0300, Roger Quadros wrote:
>> The GPMC WAIT pin status are now available over gpiolib.
>> Update the omap_dev_ready() function to use gpio instead of
>> directly accessing GPMC register space.
>>
>> Signed-off-by: Roger Quadros <rog...@ti.com>
>> ---
>>  drivers/mtd/nand/omap2.c | 29 
>> +---
>>  include/linux/platform_data/mtd-nand-omap2.h |  2 +-
>>  2 files changed, 19 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index 228f498..d0f2620 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -12,6 +12,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -184,6 +185,8 @@ struct omap_nand_info {
>>  /* fields specific for BCHx_HW ECC scheme */
>>  struct device   *elm_dev;
>>  struct device_node  *of_node;
>> +/* NAND ready gpio */
>> +struct gpio_desc*ready_gpiod;
>>  };
>>  
>>  /**
>> @@ -1047,22 +1050,17 @@ static int omap_wait(struct mtd_info *mtd, struct 
>> nand_chip *chip)
>>  }
>>  
>>  /**
>> - * omap_dev_ready - calls the platform specific dev_ready function
>> + * omap_dev_ready - checks the NAND Ready GPIO line
>>   * @mtd: MTD device structure
>> + *
>> + * Returns true if ready and false if busy.
>>   */
>>  static int omap_dev_ready(struct mtd_info *mtd)
>>  {
>> -unsigned int val = 0;
>>  struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
>>  mtd);
>>  
>> -val = readl(info->reg.gpmc_status);
>> -
>> -if ((val & 0x100) == 0x100) {
>> -return 1;
>> -} else {
>> -return 0;
>> -}
>> +return gpiod_get_value(info->ready_gpiod);
>>  }
>>  
>>  /**
>> @@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device 
>> *pdev)
>>  info->reg = pdata->reg;
>>  info->of_node = pdata->of_node;
>>  info->ecc_opt = pdata->ecc_opt;
>> -info->dev_ready = pdata->dev_ready;
>> +if (pdata->dev_ready)
>> +dev_info(>dev, "pdata->dev_ready is 
>> deprecated\n");
>> +
>>  info->xfer_type = pdata->xfer_type;
>>  info->devsize = pdata->devsize;
>>  info->elm_of_node = pdata->elm_of_node;
>> @@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device 
>> *pdev)
>>  nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
>>  nand_chip->cmd_ctrl  = omap_hwcontrol;
>>  
>> +info->ready_gpiod = devm_gpiod_get_optional(>dev, "ready",
>> +GPIOD_IN);
> 
> Others have been looking at using GPIOs for the ready/busy pin too. At a
> minimum, we need an updated DT binding doc for this, since I see you're
> adding this via device tree in a later patch (I don't see any DT binding
> patch for this; but I could just be overlooking it). It'd also be great
> if this support was moved to nand_dt_init() so other platforms can
> benefit, but I won't require that.
> 
> Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio'
> (the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't
> really care, but the name should be going into a doc, so we can choose
> the same one everywhere.
> 
> EDIT: looks like the discussion was partly here [1] and it seems we're
> landing on "rb-gpios" in the latest version [2]. Can we stick with that?

Why should it be "rb-gpios" and not "rb-gpio"?
I don't think there are multiple gpios for r/b# function.

cheers,
-roger

> 
> Regards,
> Brian
> 
> [0] "Previous" may be subject to debate, as both series have been going
> for several revisions.
> [1] http://patchwork.ozlabs.org/patch/515327/
> [2] http://patchwork.ozlabs.org/patch/526819/
> 
>> +if (IS_ERR(info->ready_gpiod)) {
>> +dev_err(dev, "failed to get ready gpio\n");
>> +return PTR_ERR(info->ready_gpiod);
>> +}
>> +
>>  /*
>>   * If RDY/BSY line is connec

Re: [PATCH v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Roger Quadros]

Boris,

On 27/10/15 10:12, Boris Brezillon wrote:
> Hi Roger,
> 
> On Tue, 27 Oct 2015 10:03:02 +0200
> Roger Quadros <rog...@ti.com> wrote:
> 
>> On 26/10/15 22:49, Brian Norris wrote:
>>>
>>> Others have been looking at using GPIOs for the ready/busy pin too. At a
>>> minimum, we need an updated DT binding doc for this, since I see you're
>>> adding this via device tree in a later patch (I don't see any DT binding
>>> patch for this; but I could just be overlooking it). It'd also be great
>>> if this support was moved to nand_dt_init() so other platforms can
>>> benefit, but I won't require that.
>>>
>>> Also, previous [0] proposers had suggested 'rb-gpios', not 'ready-gpio'
>>> (the hardware docs typically call it 'rb' for ready/busy, FWIW). I don't
>>> really care, but the name should be going into a doc, so we can choose
>>> the same one everywhere.
>>>
>>> EDIT: looks like the discussion was partly here [1] and it seems we're
>>> landing on "rb-gpios" in the latest version [2]. Can we stick with that?
>>
>> Why should it be "rb-gpios" and not "rb-gpio"?
>> I don't think there are multiple gpios for r/b# function.
> 
> Because it's supposed to be a generic binding, and some NAND chips
> embed several dies, thus exposing several CS and RB pins, hence the
> rb-gpios name.
> Also, as described here [1], the convention is to name your property
> -gpios even if you only need one gpio.

Makes sense now. Thanks for the explanation.
I'll update this patch to use rb-gpios and update the binding doc as well.

--
cheers,
-roger
--
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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Hi Brian,

On 26/10/15 23:23, Brian Norris wrote:
> Hi Roger,
> 
> I'm not too familiar with OMAP platforms, and I might have missed out on
> prior discussions/context, so please forgive if I'm asking silly or old
> questions here.

No worries at all.

> 
> On Fri, Sep 18, 2015 at 05:53:22PM +0300, Roger Quadros wrote:
>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>> This causes performance increase when using prefetch-irq mode.
>> 30% increase in read, 17% increase in write in prefetch-irq mode.
> 
> Have you pinpointed the exact causes for the performance increase, or
> can you give an educated guess? AIUI, you're reducing the number of
> interrupts needed for NAND prefetch mode, but you're also removing a bit
> of abstraction and implementing hooks that look awfully like the
> existing abstractions:
> 
> +   int (*nand_irq_enable)(enum gpmc_nand_irq irq);
> +   int (*nand_irq_disable)(enum gpmc_nand_irq irq);
> +   void (*nand_irq_clear)(enum gpmc_nand_irq irq);
> +   u32 (*nand_irq_status)(void);
> 
> That's not really a problem if there's a good reason for them (brcmnand
> implements similar hooks because of quirks in the implementation of
> interrupts across various BRCM SoCs, and it's not worth writing irqchip
> drivers for those cases). I'm mainly curious for an explanation.

I have both implementations with me. My guess is that the 20% performance
gain is due to absence of irqchip/irqdomain translation code.
I haven't investigated further though.

Another concern I have is that I'm not using any locking around
gpmc_nand_irq_enable/disable(). Could this pose problems in multiple NAND
use cases? My understanding is that it should not as the controller access
is serialized between multiple NAND chips.

However I do need to add some locking as the GPMC_IRQENABLE register is shared
between NAND and GPMC driver.

NOTE: We are not using prefetch-irq mode for any of the OMAP boards because
of lesser performance than prefetch-polled mode. So if the less performance
for an unused mode is a lesser concern compared to cleaner code then
I can resend this with the irqdomain implementation.

Below are performance logs of irqdomain vs hooks.

--
cheers,
-roger

test logs.

for-v4.4/gpmc-v2 - irqdomain with prefetch-irq. No ready pin.


[   67.696631] 
[   67.698201] =
[   67.704254] mtd_speedtest: MTD device: 8
[   67.708373] mtd_speedtest: MTD device size 8388608, eraseblock size 131072, 
page size 2048, count of eraseblocks 64, pages per eraseblock 64, OOB size 64
[   67.723701] mtd_test: scanning for bad eraseblocks
[   67.735468] mtd_test: scanned 64 eraseblocks, 0 are bad
[   67.772861] mtd_speedtest: testing eraseblock write speed
[   70.372903] mtd_speedtest: eraseblock write speed is 3156 KiB/s
[   70.379104] mtd_speedtest: testing eraseblock read speed
[   72.594169] mtd_speedtest: eraseblock read speed is 3708 KiB/s
[   72.656375] mtd_speedtest: testing page write speed
[   75.213646] mtd_speedtest: page write speed is 3208 KiB/s
[   75.219311] mtd_speedtest: testing page read speed
[   77.343639] mtd_speedtest: page read speed is 3865 KiB/s
[   77.405236] mtd_speedtest: testing 2 page write speed
[   80.039702] mtd_speedtest: 2 page write speed is 3114 KiB/s
[   80.045561] mtd_speedtest: testing 2 page read speed
[   82.175098] mtd_speedtest: 2 page read speed is 3856 KiB/s
[   82.180849] mtd_speedtest: Testing erase speed
[   82.241548] mtd_speedtest: erase speed is 146285 KiB/s
[   82.246920] mtd_speedtest: Testing 2x multi-block erase speed
[   82.284789] mtd_speedtest: 2x multi-block erase speed is 264258 KiB/s
[   82.291551] mtd_speedtest: Testing 4x multi-block erase speed
[   82.329358] mtd_speedtest: 4x multi-block erase speed is 264258 KiB/s
[   82.336116] mtd_speedtest: Testing 8x multi-block erase speed
[   82.373903] mtd_speedtest: 8x multi-block erase speed is 264258 KiB/s
[   82.380648] mtd_speedtest: Testing 16x multi-block erase speed
[   82.418503] mtd_speedtest: 16x multi-block erase speed is 264258 KiB/s
[   82.425356] mtd_speedtest: Testing 32x multi-block erase speed
[   82.463227] mtd_speedtest: 32x multi-block erase speed is 264258 KiB/s
[   82.470066] mtd_speedtest: Testing 64x multi-block erase speed
[   82.507908] mtd_speedtest: 64x multi-block erase speed is 264258 KiB/s
[   82.514758] mtd_speedtest: finished
[   82.518417] =

root@rockdesk:~# cat /proc/interrupts 
   CPU0   CPU1   
324: 798720  0  CBAR  15 Level gpmc
397: 798720  0  gpmc   0 Edge  gpmc-nand-fifo
398:  24576  0  gpmc   1 Edge  gpmc-nand-count


root@rockdesk:~# ./nandthroughput.sh 
Test file blobs/50M.bin

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 21/10/15 18:20, Tony Lindgren wrote:
> * Roger Quadros <rog...@ti.com> [151021 01:31]:
>> On 19/10/15 10:08, Roger Quadros wrote:
>>> On 17/10/15 00:25, Tony Lindgren wrote:
>>>> * Roger Quadros <rog...@ti.com> [151006 04:13]:
>>>>>
>>>>> Fine. The updated series is now at
>>>>>
>>>>> g...@github.com:rogerq/linux.git
>>>>>  * [new branch]  for-v4.4/gpmc-v4
>>>>
>>>> Looks like it produces some build errors, this with RMKs 3430 and 4430
>>>> only .configs:
>>>>
>>>> drivers/memory/omap-gpmc.c:2035:43: error: ‘struct gpio_chip’ has no
>>>> member named ‘irqdomain’
>>>> drivers/memory/omap-gpmc.c:2116:8: error: implicit declaration of
>>>> function ‘gpiochip_irqchip_add’ [-Werror=implicit-function-declaration]
>>>>
>>>
>>> Good catch. We'll have to select GPIOLIB_IRQCHIP for this driver.
>>>
>>>> Maybe run randconfig builds on it for overnight?
>>>
>>> OK. I'll do that.
>>
>> I couldn't run randconfig beyond few iterations as it keeps failing
>> everywhere. How do we limit the randconfig options to OMAP only
>> platforms?
> 
> You can use Felipe's scripts from github.

Thanks. I used his scripts and ran 10 randconfigs per platform.
Didn't find any issues with this series.

How can we proceed?
Patches are on https://github.com/rogerq/linux/commits/for-v4.4/gpmc-v4

cheers,
-roger
--
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/2] ARM: dts: omap3: keep ssi ports by default

[Roger Quadros]

On 19/10/15 19:01, Tony Lindgren wrote:
> * Roger Quadros <rog...@ti.com> [151014 03:48]:
>> Let's keep the SSI ports disabled in the omap3.dtsi to avoid
>> getting the following noise on the console for boards that don't
>> use the SSI ports.
>>
>> "omap_ssi_port 4805a000.ssi-port: DT data is missing cawake gpio (err=-2)"
>>
>> As omap3-n900 uses one SSI port, mark it enabled there.
> 
> This is the wrong way around.. The SSI ports are there on all omap3 SoCs,
> we do want to have the struct device created for them. It's best to have
> the driver probe and then idle SSI and bail out. Marking something with
> status = "disabled" should be only used if you really want to avoid kernel
> touching the device at all, for example, if something is managed from
> the start by a copropcessor.

Agreed. Please ignore this patch.

cheers,
-roger

> 
> 
>> Signed-off-by: Roger Quadros <rog...@ti.com>
>> ---
>>  arch/arm/boot/dts/omap3-n900.dts | 1 +
>>  arch/arm/boot/dts/omap3.dtsi | 2 ++
>>  2 files changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap3-n900.dts 
>> b/arch/arm/boot/dts/omap3-n900.dts
>> index 5f5e0f3..bdb72fb 100644
>> --- a/arch/arm/boot/dts/omap3-n900.dts
>> +++ b/arch/arm/boot/dts/omap3-n900.dts
>> @@ -949,6 +949,7 @@
>>  };
>>  
>>  _port1 {
>> +status = "ok";
>>  pinctrl-names = "default";
>>  pinctrl-0 = <_pins>;
>>  
>> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
>> index 8a2b253..25b0b37 100644
>> --- a/arch/arm/boot/dts/omap3.dtsi
>> +++ b/arch/arm/boot/dts/omap3.dtsi
>> @@ -815,6 +815,7 @@
>>  interrupt-parent = <>;
>>  interrupts = <67>,
>>   <68>;
>> +status = "disabled";
>>  };
>>  
>>  ssi_port2: ssi-port@4805b000 {
>> @@ -828,6 +829,7 @@
>>  interrupt-parent = <>;
>>  interrupts = <69>,
>>   <70>;
>> +status = "disabled";
>>  };
>>  };
>>  };
>> -- 
>> 2.1.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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 19/10/15 10:08, Roger Quadros wrote:
> On 17/10/15 00:25, Tony Lindgren wrote:
>> * Roger Quadros <rog...@ti.com> [151006 04:13]:
>>>
>>> Fine. The updated series is now at
>>>
>>> g...@github.com:rogerq/linux.git
>>>  * [new branch]  for-v4.4/gpmc-v4
>>
>> Looks like it produces some build errors, this with RMKs 3430 and 4430
>> only .configs:
>>
>> drivers/memory/omap-gpmc.c:2035:43: error: ‘struct gpio_chip’ has no
>> member named ‘irqdomain’
>> drivers/memory/omap-gpmc.c:2116:8: error: implicit declaration of
>> function ‘gpiochip_irqchip_add’ [-Werror=implicit-function-declaration]
>>
> 
> Good catch. We'll have to select GPIOLIB_IRQCHIP for this driver.
> 
>> Maybe run randconfig builds on it for overnight?
> 
> OK. I'll do that.

I couldn't run randconfig beyond few iterations as it keeps failing
everywhere. How do we limit the randconfig options to OMAP only
platforms?

cheers,
-roger
--
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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 17/10/15 00:25, Tony Lindgren wrote:
> * Roger Quadros <rog...@ti.com> [151006 04:13]:
>>
>> Fine. The updated series is now at
>>
>> g...@github.com:rogerq/linux.git
>>  * [new branch]  for-v4.4/gpmc-v4
> 
> Looks like it produces some build errors, this with RMKs 3430 and 4430
> only .configs:
> 
> drivers/memory/omap-gpmc.c:2035:43: error: ‘struct gpio_chip’ has no
> member named ‘irqdomain’
> drivers/memory/omap-gpmc.c:2116:8: error: implicit declaration of
> function ‘gpiochip_irqchip_add’ [-Werror=implicit-function-declaration]
> 

Good catch. We'll have to select GPIOLIB_IRQCHIP for this driver.

> Maybe run randconfig builds on it for overnight?

OK. I'll do that.

> 
> Other than that your series seems to behave for me now, so feel
> free to add:
> 
> Acked-by: Tony Lindgren <t...@atomide.com>

Thanks for the tests :)

cheers,
-roger
--
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 0/5] mtd: nand: Fix support for NAND DMA prefetch

[Roger Quadros]

On 15/10/15 20:37, Franklin S Cooper Jr wrote:
> NAND DMA prefetch has been broken for awhile and seems to have only
> worked for SDMA based devices
> 
> This patchset fixes DMA prefetch to work on both EDMA and SDMA devices
> 
> Test on:
> am335x gp evm
> am437x gp evm
> am37x gp evm
> 
> This patchset depends on Roger Quadros recent v4 GPMC/NAND patchset
> https://github.com/rogerq/linux.git
> branch: for-v4.4/gpmc-v4
> 
> Franklin S Cooper Jr (5):
>   mtd: nand: omap2: Support parsing dma channel information from DT
>   mtd: nand: omap2: Start dma request before enabling prefetch
>   mtd: nand: omap2: Fix high memory dma prefetch transfer
>   ARM: dts: am437x/am33xx/omap/dm816x: Add gpmc dma channel
>   ARM: OMAP2+: Update GPMC and NAND DT binding documentation
> 
>  .../bindings/memory-controllers/omap-gpmc.txt  |  7 +-
>  .../devicetree/bindings/mtd/gpmc-nand.txt  |  2 ++
>  arch/arm/boot/dts/am33xx.dtsi  |  2 ++
>  arch/arm/boot/dts/am4372.dtsi  |  2 ++
>  arch/arm/boot/dts/dm816x.dtsi  |  2 ++
>  arch/arm/boot/dts/omap3.dtsi   |  2 ++
>  arch/arm/boot/dts/omap4.dtsi   |  2 ++
>  arch/arm/boot/dts/omap5.dtsi   |  2 ++
>  drivers/mtd/nand/omap2.c   | 27 
> +-----
>  9 files changed, 31 insertions(+), 17 deletions(-)
> 

For all patches,

Acked-by: Roger Quadros <rog...@ti.com>

--
cheers,
-roger
--
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/2 v2] ARM: DRA7/335x/437x: hwmod: Remove gpmc address space from hwmod data

[Roger Quadros]

On 15/10/15 19:27, Franklin S Cooper Jr wrote:
> GPMC address information is provided by device tree. No longer need
> to include this information within hwmod.
> 
> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>

Acked-by: Roger Quadros <rog...@ti.com>

--
cheers,
-roger
--
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 v2] ARM: DRA7/335x/437x/OMAP4: hwmod: Remove elm address space from hwmod data

[Roger Quadros]

On 15/10/15 19:27, Franklin S Cooper Jr wrote:
> ELM address information is provided by device tree. No longer need
> to include this information within hwmod.
> 
> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>

Acked-by: Roger Quadros <rog...@ti.com>

--
cheers,
-roger
--
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/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

On 14/10/15 23:03, Franklin S Cooper Jr. wrote:
> 
> 
> On 10/14/2015 01:13 PM, Tony Lindgren wrote:
>> * Franklin S Cooper Jr. <fcoo...@ti.com> [151014 09:27]:
>>>
>>> On 10/14/2015 11:18 AM, Tony Lindgren wrote:
>>>> * Franklin S Cooper Jr. <fcoo...@ti.com> [151014 07:37]:
>>>>> On 10/14/2015 09:11 AM, Roger Quadros wrote:
>>>>>> On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
>>>>>>> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>>>>>>>> Franklin,
>>>>>>>>
>>>>>>>> On 14/10/15 14:36, Roger Quadros wrote:
>>>>>>>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>>>>>>>> Switch from dma_request_channel to allow passing dma channel
>>>>>>>>>> information from DT rather than hardcoding a value.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
>>>>>>>>> Acked-by: Roger Quadros <rog...@ti.com>
>>>>>>>>>
>>>>>>>>>> ---
>>>>>>>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>>>>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>>>>>>>> index d0f2620..957c32f 100644
>>>>>>>>>> --- a/drivers/mtd/nand/omap2.c
>>>>>>>>>> +++ b/drivers/mtd/nand/omap2.c
>>>>>>>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct 
>>>>>>>>>> platform_device *pdev)
>>>>>>>>>>  dma_cap_zero(mask);
>>>>>>>>>>  dma_cap_set(DMA_SLAVE, mask);
>>>>>>>>>>  sig = OMAP24XX_DMA_GPMC;
>>>>>>>>>> -info->dma = dma_request_channel(mask, 
>>>>>>>>>> omap_dma_filter_fn, );
>>>>>>>>>> +info->dma = dma_request_slave_channel_compat(mask,
>>>>>>>>>> +omap_dma_filter_fn, , pdev->dev.parent, 
>>>>>>>>>> "rxtx");
>>>>>>>>>> +
>>>>>>>> Just discovered that you are using the parent device node.
>>>>>>>>
>>>>>>>> How about moving the dma bindings to the nand node instead and using
>>>>>>>> pdev->dev here?
>>>>>>> Roger,
>>>>>>>
>>>>>>> From what I can tell the interrupt number and the dma channel will 
>>>>>>> always be
>>>>>>> the same no matter what. Doesn't matter if you have multiple nands or a
>>>>>>> combination of nands and nors. Since that is the case I think it just 
>>>>>>> makes
>>>>>>> sense to leave it in the gpmc parent node and define it once.
>>>>>> Is prefetch/writepost dma used for NOR or any other GPMC peripheral
>>>>>> or only for NAND?
>>>>> The dma seems tied to the prefetch. From what I can tell the prefetch is 
>>>>> only
>>>>> used by nand.
>>>>>> Let's also get Tony's inputs on this.
>>>>> Sure.
>>>> Hmm so what would keep other devices from using the prefetch
>>> Looking at the TRM any references to the prefetch are always with respect to
>>> NAND.
>>>
>>> I also see the below mentioned in the TRM.
>>> Pre-fetch and write posting engine associated with system DMA to get full 
>>> performance from NAND
>>> device with minimum impact on NOR/SRAM concurrent access.
>> OK up to you guys to figure out if it may be usable in a generic way then :)
> Ok I just got clarification from hw folks. DMA for GPMC can be used for any 
> of the
> various modes. But the prefetch is specific to NAND.

In that case the dma information must be in the GPMC node.

cheers,
-roger
--
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 20/27] ARM: dts: dra7: Fix NAND device nodes.

[Roger Quadros]

On 14/10/15 16:34, Franklin S Cooper Jr. wrote:
> 
> 
> On 09/18/2015 09:53 AM, Roger Quadros wrote:
>> Add compatible id, GPMC register resource and interrupt
>> resource to NAND controller nodes.
>>
>> The GPMC driver now implements gpiochip and irqchip so
>> enable gpio-controller and interrupt-controller properties.
>>
>> With this the interrupt parent of NAND node changes so fix it
>> accordingly.
>>
>> Signed-off-by: Roger Quadros <rog...@ti.com>
>> ---
>>  arch/arm/boot/dts/dra7-evm.dts  | 5 -
>>  arch/arm/boot/dts/dra7.dtsi | 4 
>>  arch/arm/boot/dts/dra72-evm.dts | 5 -
>>  3 files changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
>> index a6c82e5..8a31161 100644
>> --- a/arch/arm/boot/dts/dra7-evm.dts
>> +++ b/arch/arm/boot/dts/dra7-evm.dts
>> @@ -585,9 +585,12 @@
>>  status = "okay";
>>  pinctrl-names = "default";
>>  pinctrl-0 = <_flash_x16>;
>> -ranges = <0 0 0 0x0100>;/* minimum GPMC partition = 16MB */
>> +ranges = <0 0 0x0800 0x0100>;   /* minimum GPMC partition = 
>> 16MB */
>>  nand@0,0 {
>> +compatible = "ti,omap2-nand";
>>  reg = <0 0 4>;  /* device IO registers */
>> +interrupt-parent = <_mpu>;
>> +interrupts = ;
>>  ti,nand-ecc-opt = "bch8";
>>  ti,elm-id = <>;
>>  nand-bus-width = <16>;
>> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
>> index 5d65db9..f0a3616 100644
>> --- a/arch/arm/boot/dts/dra7.dtsi
>> +++ b/arch/arm/boot/dts/dra7.dtsi
>> @@ -1389,6 +1389,10 @@
>>  gpmc,num-waitpins = <2>;
>>  #address-cells = <2>;
>>  #size-cells = <1>;
>> +gpio-controller;
>> +#gpio-cells = <2>;
>> +interrupt-controller;
>> +#interrupt-cells = <2>;
>>  status = "disabled";
>>  };
> Based on the discussion on my patchset I noticed that the nand node defines 
> the
> interrupt but it is also defined in the parent node. Similar to the dma 
> channel we
> should conclude where the best place for it to be defined.  But to me it 
> seems at
> least it should only be defined once.

The interrupt is defined at both places because it is used at both places.
It is used as a shared interrupt. Wait_pin interrupts are managed by the
gpmc driver and NAND specific interrupts are managed by the NAND driver.

If GPMC dma channel is going to be used only by the NAND driver then
we should define the channel in the NAND node.

> 
> This is true for your other patches making similar changes to the dt.

Yes, GPMC IRQ is defined in both GPMC and NAND nodes.

--
cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: DRA7: hwmod: Remove elm address space from hwmod data

[Roger Quadros]

On 13/10/15 16:44, Franklin S Cooper Jr wrote:
> ELM address information is provided by device tree. No longer need
> to include this information within hwmod.
> 
> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>

Acked-by: Roger Quadros <rog...@ti.com>

Franklin,

Can you please do the same for gpmc_addr as well?

And looks like elm_addr needs to be removed from
omap_hwmod_33xx_43xx_interconnect_data.c and omap_hwmod_44xx_data.c as well, no?

cheers,
-roger

> ---
>  arch/arm/mach-omap2/omap_hwmod_7xx_data.c | 10 --
>  1 file changed, 10 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> index 562247b..ad2cc7a 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_7xx_data.c
> @@ -2566,21 +2566,11 @@ static struct omap_hwmod_ocp_if 
> dra7xx_l3_main_1__hdmi = {
>   .user   = OCP_USER_MPU | OCP_USER_SDMA,
>  };
>  
> -static struct omap_hwmod_addr_space dra7xx_elm_addrs[] = {
> - {
> - .pa_start   = 0x48078000,
> - .pa_end = 0x48078fff,
> - .flags  = ADDR_TYPE_RT
> - },
> - { }
> -};
> -
>  /* l4_per1 -> elm */
>  static struct omap_hwmod_ocp_if dra7xx_l4_per1__elm = {
>   .master = _l4_per1_hwmod,
>   .slave  = _elm_hwmod,
>   .clk= "l3_iclk_div",
> - .addr   = dra7xx_elm_addrs,
>   .user   = OCP_USER_MPU | OCP_USER_SDMA,
>  };
>  
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: am437x-gp-evm: Add wakeup interrupt source for pixcir_i2c_ts

[Roger Quadros]

+Dave

On 14/10/15 08:52, Vignesh R wrote:
> On am437x-gp-evm, pixcir_i2c_ts can wakeup the system from lower power
> state via pinctrl and IO daisy chain using generic wakeirq framework.
> With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
> interrupt in device tree") i2c core allows optional wakeirq to be
> specified via device tree. Add wakeup irq entry to enable pixcir_i2c_ts
> to wake the system from low power state.
> 
> Signed-off-by: Vignesh R 
> ---
>  arch/arm/boot/dts/am437x-gp-evm.dts | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
> b/arch/arm/boot/dts/am437x-gp-evm.dts
> index 22038f21f228..69e93af7df0d 100644
> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
> @@ -581,8 +581,13 @@
>  
>   attb-gpio = < 22 GPIO_ACTIVE_HIGH>;
>  
> + interrupts-extended = < 22 GPIO_ACTIVE_HIGH>,
> +   <_pinmux 0x264>;

How does this work?

interrupts-extended property must have
1) interrupt parent
2) interrupt number
3) interrupt flags

Your change doesn't seem to comply with those requirements.

> + interrupt-names = "tsc", "wakeup";
> +
>   touchscreen-size-x = <1024>;
>   touchscreen-size-y = <600>;
> + wakeup-source;
>   };
>  
>   ov2659@30 {
> 

cheers,
-roger
--
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 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes

[Roger Quadros]

Tony,

On 13/10/15 18:18, Tony Lindgren wrote:
> * Roger Quadros <rog...@ti.com> [151012 23:33]:
>> On 13/10/15 03:43, Tony Lindgren wrote:
>>> * Roger Quadros <rog...@ti.com> [150918 08:00]:
>>>> Add compatible id, GPMC register resource and interrupt
>>>> resource to NAND controller nodes.
>>>>
>>>> The GPMC driver now implements gpiochip and irqchip so
>>>> enable gpio-controller and interrupt-controller properties.
>>>>
>>>> With this the interrupt parent of NAND node changes so fix it
>>>> accordingly.
>>> ...
>>>> --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
>>>> +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
>>>> @@ -35,11 +35,14 @@
>>>>  };
>>>>  
>>>>   {
>>>> -  ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
>>>> +  ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
>>>>  
>>>>nand@0,0 {
>>>> -  linux,mtd-name = "micron,mt29f4g16abbda3w";
>>>> +  compatible = "ti,omap2-nand";
>>>>reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
>>>> +  interrupt-parent = <>;
>>>> +  interrupts = <20>;
>>>> +  linux,mtd-name = "micron,mt29f4g16abbda3w";
>>>>nand-bus-width = <16>;
>>>>ti,nand-ecc-opt = "bch8";
>>>>gpmc,sync-clk-ps = <0>;
>>>
>>> At least torpedo breaks for NFSroot as NAND now overlaps with
>>> Ethernet.. What's the policy you have for moving the addresses
>>> around?
>>
>> For OMAP3 I intended to use 0x3000 for NAND but incorrectly
>> used 0x0800 for the torpedo.
> 
> Might be worth adding some documentation of suggested standardized
> mappings.. For most of theme we could just add them as 16MB chunks,
> then reserve some larger area for NOR?

As GPMC peripherals are not plug and play the GPMC map is specific to
the board and need not necessarily apply to all boards.
So I don't think we need to have any standardized mappings.

> 
>> Does setting it to 0x3000 work? If not what is the original
>> NAND address for this board?
> 
> The u-boot addresses are probably what were used in the .dts* files.
> Setting NAND to 0x3000 is not enough though, looks like there's
> a bug where the logicpd-torpedo-37xx-devkit.dts ranges is missing
> the NAND range in logicpd-torpedo-som.dtsi. Something like the
> patch below seems to make things work again, might be worth
> checking what ranges make sense to standardize on though. Please
> feel free to fold it into your patches.

Thanks. I'll post a revised patch.

> 
>>> There may be other similar cases to check too.
>>
>> Just checked that all other OMAP3 boards I've set to 0x3000
>> if they were 0x0.
> 
> Do you want to reserve a large chunk for NOR at cs0 or what's
> the reason for picking 0x3000 for NAND?

All of the OMAP3 boards were using 0x3000. Probably copy paste effect? :)
What's the point of reserving anything for NOR. If the board doesn't already
have NOR it never will. Future board having NOR can have its own GPMC map.
> 
> I guess NOR can be also on other chipselects.. Not sure we can
> standardize on any specific partition scheme?

Exactly.

cheers,
-roger

> 
> Regards,
> 
> Tony
> 
> 8< 
> --- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> +++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
> @@ -73,7 +73,8 @@
>  };
>  
>   {
> - ranges = <1 0 0x0800 0x100>;/* CS1: 16MB for LAN9221 */
> + ranges = <0 0 0x3000 0x100  /* CS0: 16MB for NAND */
> +   1 0 0x2c00 0x100>;/* CS1: 16MB for LAN9221 */
>  
>   ethernet@gpmc {
>   pinctrl-names = "default";
> --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
> @@ -35,7 +35,7 @@
>  };
>  
>   {
> - ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
> + ranges = <0 0 0x3000 0x100>;/* CS0: 16MB for NAND */
>  
>   nand@0,0 {
>   compatible = "ti,omap2-nand";
> 
--
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 v4 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes

[Roger Quadros]

Add compatible id, GPMC register resource and interrupt
resource to NAND controller nodes.

The GPMC driver now implements gpiochip and irqchip so
enable gpio-controller and interrupt-controller properties.

With this the interrupt parent of NAND node changes so fix it
accordingly.

Signed-off-by: Roger Quadros <rog...@ti.com>
---

v4: Applied Tony's patch to fix broken ethernet on torpedo.

updated v4 series available at

g...@github.com:rogerq/linux.git
 * [branch]  for-v4.4/gpmc-v4

 arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts | 3 ++-
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi| 7 +--
 arch/arm/boot/dts/omap3-beagle.dts| 2 ++
 arch/arm/boot/dts/omap3-cm-t3x.dtsi   | 5 -
 arch/arm/boot/dts/omap3-devkit8000-common.dtsi| 3 +++
 arch/arm/boot/dts/omap3-evm-37xx.dts  | 7 +--
 arch/arm/boot/dts/omap3-gta04.dtsi| 3 +++
 arch/arm/boot/dts/omap3-igep.dtsi | 5 -
 arch/arm/boot/dts/omap3-igep0020-common.dtsi  | 4 ++--
 arch/arm/boot/dts/omap3-igep0030-common.dtsi  | 4 
 arch/arm/boot/dts/omap3-ldp.dts   | 9 ++---
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi   | 5 -
 arch/arm/boot/dts/omap3-pandora-common.dtsi   | 3 +++
 arch/arm/boot/dts/omap3-tao3530.dtsi  | 5 -
 arch/arm/boot/dts/omap3.dtsi  | 4 
 arch/arm/boot/dts/omap3430-sdp.dts| 5 -
 16 files changed, 59 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts 
b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
index 91146c3..20e157d 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
+++ b/arch/arm/boot/dts/logicpd-torpedo-37xx-devkit.dts
@@ -73,7 +73,8 @@
 };
 
  {
-   ranges = <1 0 0x0800 0x100>;/* CS1: 16MB for LAN9221 */
+   ranges = <0 0 0x3000 0x100  /* CS0: 16MB for NAND */
+ 1 0 0x2c00 0x100>;/* CS1: 16MB for LAN9221 */
 
ethernet@gpmc {
pinctrl-names = "default";
diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index 36387b1..f108e55 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -35,11 +35,14 @@
 };
 
  {
-   ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
+   ranges = <0 0 0x3000 0x100>;/* CS0: 16MB for NAND */
 
nand@0,0 {
-   linux,mtd-name = "micron,mt29f4g16abbda3w";
+   compatible = "ti,omap2-nand";
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <20>;
+   linux,mtd-name = "micron,mt29f4g16abbda3w";
nand-bus-width = <16>;
ti,nand-ecc-opt = "bch8";
gpmc,sync-clk-ps = <0>;
diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index 67659a0..9b145dd 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -384,7 +384,9 @@
 
/* Chip select 0 */
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>;  /* NAND I/O window, 4 bytes */
+   interrupt-parent = <>;
interrupts = <20>;
ti,nand-ecc-opt = "ham1";
nand-bus-width = <16>;
diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi 
b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
index 4d091ca..e9d7e28 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
@@ -261,10 +261,13 @@
 };
 
  {
-   ranges = <0 0 0x 0x0100>;
+   ranges = <0 0 0x3000 0x0100>;   /* CS0: 16MB for NAND */
 
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>;  /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <20>;
nand-bus-width = <8>;
gpmc,device-width = <1>;
ti,nand-ecc-opt = "sw";
diff --git a/arch/arm/boot/dts/omap3-devkit8000-common.dtsi 
b/arch/arm/boot/dts/omap3-devkit8000-common.dtsi
index 9ca2865..e7b46ad 100644
--- a/arch/arm/boot/dts/omap3-devkit8000-common.dtsi
+++ b/arch/arm/boot/dts/omap3-devkit8000-common.dtsi
@@ -204,7 +204,10 @@
ranges = <0 0 0x3000 0x100>;   /* CS0: 16MB for NAND */
 
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <20>;
nand-bus-width = <1

[PATCH 0/2] omap: hsi: Fix warnings on boards that don't use ssi ports

[Roger Quadros]

Hi,

This series fixes warnings and console noise for boards that don't use
ssi ports. Tested on beagleboard-c4.

cheers,
-roger

Roger Quadros (2):
  hsi: omap_ssi_port: Prevent warning if cawake_gpio is not defined.
  ARM: dts: omap3: keep ssi ports by default

 arch/arm/boot/dts/omap3-n900.dts| 1 +
 arch/arm/boot/dts/omap3.dtsi| 2 ++
 drivers/hsi/controllers/omap_ssi_port.c | 2 +-
 3 files changed, 4 insertions(+), 1 deletion(-)

-- 
2.1.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] hsi: omap_ssi_port: Prevent warning if cawake_gpio is not defined.

[Roger Quadros]

The error handling path is broken as cawake_gpio was defined as
unsigned integer causing the following warnings on boards that don't
use SSI port and so don't have cawake_gpio defined. e.g. beagleboard C4.

[   30.094635] WARNING: CPU: 0 PID: 322 at drivers/gpio/gpiolib.c:86 
gpio_to_desc+0xa4/0xb8()
[   30.103363] invalid GPIO -2
[   30.106292] Modules linked in: omap_ssi_port(+) cpufreq_dt cfbfillrect 
cfbimgblt leds_gpio cfbcopyarea thermal_sys led_class hwmon gpio_keys 
encoder_tfp410 connector_analog_tv connector_dvi omap_hdq snd phy_i
[   30.145477] CPU: 0 PID: 322 Comm: modprobe Not tainted 
4.3.0-rc4-00030-gca978c0-dirty #335
[   30.154174] Hardware name: Generic OMAP3-GP (Flattened Device Tree)
[   30.160827] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   30.168975] [] (show_stack) from [] 
(dump_stack+0x80/0x9c)
[   30.176635] [] (dump_stack) from [] 
(warn_slowpath_common+0x7c/0xb8)
[   30.185180] [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[   30.194366] [] (warn_slowpath_fmt) from [] 
(gpio_to_desc+0xa4/0xb8)
[   30.202819] [] (gpio_to_desc) from [] 
(gpio_request_one+0x14/0x11c)
[   30.211273] [] (gpio_request_one) from [] 
(devm_gpio_request_one+0x3c/0x78)
[   30.220458] [] (devm_gpio_request_one) from [] 
(ssi_port_probe+0x118/0x504 [omap_ssi_port])
[   30.231170] [] (ssi_port_probe [omap_ssi_port]) from [] 
(platform_drv_probe+0x48/0xa4)
[   30.241424] [] (platform_drv_probe) from [] 
(driver_probe_device+0x1dc/0x2a0)
[   30.250793] [] (driver_probe_device) from [] 
(__driver_attach+0x94/0x98)
[   30.259643] [] (__driver_attach) from [] 
(bus_for_each_dev+0x54/0x88)
[   30.268249] [] (bus_for_each_dev) from [] 
(bus_add_driver+0xe8/0x1f8)
[   30.276916] [] (bus_add_driver) from [] 
(driver_register+0x78/0xf4)
[   30.285369] [] (driver_register) from [] 
(__platform_driver_probe+0x34/0xd8)
[   30.294647] [] (__platform_driver_probe) from [] 
(do_one_initcall+0x80/0x1d8)
[   30.303985] [] (do_one_initcall) from [] 
(do_init_module+0x5c/0x1cc)
[   30.312561] [] (do_init_module) from [] 
(load_module+0x18c8/0x1f0c)
[   30.320983] [] (load_module) from [] 
(SyS_init_module+0xdc/0x150)
[   30.329223] [] (SyS_init_module) from [] 
(ret_fast_syscall+0x0/0x1c)

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/hsi/controllers/omap_ssi_port.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/hsi/controllers/omap_ssi_port.c 
b/drivers/hsi/controllers/omap_ssi_port.c
index 1f8652b..02e6603 100644
--- a/drivers/hsi/controllers/omap_ssi_port.c
+++ b/drivers/hsi/controllers/omap_ssi_port.c
@@ -,7 +,7 @@ static int __init ssi_port_probe(struct platform_device 
*pd)
struct omap_ssi_port *omap_port;
struct hsi_controller *ssi = dev_get_drvdata(pd->dev.parent);
struct omap_ssi_controller *omap_ssi = hsi_controller_drvdata(ssi);
-   u32 cawake_gpio = 0;
+   int cawake_gpio = 0;
u32 port_id;
int err;
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: dts: am437x-gp-evm: Add wakeup interrupt source for pixcir_i2c_ts

[Roger Quadros]

Vignesh,

On 14/10/15 12:12, Vignesh R wrote:
> 
> 
> On 10/14/2015 02:16 PM, Roger Quadros wrote:
> 
>>
>> On 14/10/15 08:52, Vignesh R wrote:
>>> On am437x-gp-evm, pixcir_i2c_ts can wakeup the system from lower power
>>> state via pinctrl and IO daisy chain using generic wakeirq framework.
>>> With commit 3fffd1283927 ("i2c: allow specifying separate wakeup
>>> interrupt in device tree") i2c core allows optional wakeirq to be
>>> specified via device tree. Add wakeup irq entry to enable pixcir_i2c_ts
>>> to wake the system from low power state.
>>>
>>> Signed-off-by: Vignesh R <vigne...@ti.com>
>>> ---
>>>  arch/arm/boot/dts/am437x-gp-evm.dts | 5 +
>>>  1 file changed, 5 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
>>> b/arch/arm/boot/dts/am437x-gp-evm.dts
>>> index 22038f21f228..69e93af7df0d 100644
>>> --- a/arch/arm/boot/dts/am437x-gp-evm.dts
>>> +++ b/arch/arm/boot/dts/am437x-gp-evm.dts
>>> @@ -581,8 +581,13 @@
>>>  
>>> attb-gpio = < 22 GPIO_ACTIVE_HIGH>;
>>>  
>>> +   interrupts-extended = < 22 GPIO_ACTIVE_HIGH>,
>>> + <_pinmux 0x264>;
>>
>> How does this work?
>>
>> interrupts-extended property must have
>> 1) interrupt parent
>> 2) interrupt number
>> 3) interrupt flags
>>
>> Your change doesn't seem to comply with those requirements.
> 
> AFAIU, interrupts-extended has two parts: interrupt parent phandle and
> interrupt specifier.
> The number of cells in interrupt specifier is determined by
> interrupt-cells property of interrupt parent node.

Got it.

> In above case, gpio3 has interrupt-cells = 2 hence interrupt specifier
> has interrupt number and interrupt flag field.

But is GPIO_ACTIVE_HIGH an interrupt flag?

> But in case am43xx_pinmux node, interrupt-cells is 1 hence has no
> interrupt flag field.
> 
Understood, thanks. Might be worth adding a comment as to what 0x264 means 
though.

cheers,
-roger
--
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/2] ARM: dts: omap3: keep ssi ports by default

[Roger Quadros]

On 14/10/15 14:19, Sebastian Reichel wrote:
> Hi,
> 
> On Wed, Oct 14, 2015 at 01:44:16PM +0300, Roger Quadros wrote:
>> Let's keep the SSI ports disabled in the omap3.dtsi to avoid
>> getting the following noise on the console for boards that don't
>> use the SSI ports.
>>
>> "omap_ssi_port 4805a000.ssi-port: DT data is missing cawake gpio (err=-2)"
>>
>> As omap3-n900 uses one SSI port, mark it enabled there.
>>
>> Signed-off-by: Roger Quadros <rog...@ti.com>
> 
> Acked-By: Sebastian Reichel <s...@kernel.org>

Would it be preferable to disable the ssi-controller node as well in the
omap3.dtsi file?

cheers,
-roger



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> Switch from dma_request_channel to allow passing dma channel
> information from DT rather than hardcoding a value.
> 
> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>

Acked-by: Roger Quadros <rog...@ti.com>

> ---
>  drivers/mtd/nand/omap2.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index d0f2620..957c32f 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device *pdev)
>   dma_cap_zero(mask);
>   dma_cap_set(DMA_SLAVE, mask);
>   sig = OMAP24XX_DMA_GPMC;
> - info->dma = dma_request_channel(mask, omap_dma_filter_fn, );
> + info->dma = dma_request_slave_channel_compat(mask,
> + omap_dma_filter_fn, , pdev->dev.parent, "rxtx");
> +
>   if (!info->dma) {
>   dev_err(>dev, "DMA engine request failed\n");
>   err = -ENXIO;
> 

cheers,
-roger
--
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/2] ARM: dts: omap3: keep ssi ports by default

[Roger Quadros]

On 14/10/15 14:37, Sebastian Reichel wrote:
> Hi,
> 
> On Wed, Oct 14, 2015 at 02:27:27PM +0300, Roger Quadros wrote:
>> On 14/10/15 14:19, Sebastian Reichel wrote:
>>> On Wed, Oct 14, 2015 at 01:44:16PM +0300, Roger Quadros wrote:
>>>> Let's keep the SSI ports disabled in the omap3.dtsi to avoid
>>>> getting the following noise on the console for boards that don't
>>>> use the SSI ports.
>>>>
>>>> "omap_ssi_port 4805a000.ssi-port: DT data is missing cawake gpio (err=-2)"
>>>>
>>>> As omap3-n900 uses one SSI port, mark it enabled there.
>>
>> Would it be preferable to disable the ssi-controller node as well in the
>> omap3.dtsi file?
> 
> If I remember it correctly, existing, but unused IP-Cores
> should not be disabled in DT, so that hwmod picks them up
> for power management.

OK.
> 
> Note, that it actually is disabled in omap3.dtsi and then enabled in
> omap34xx/omap36xx dts files (the other variants do not have an ssi
> module).

Thanks for the info :)

cheers,
-roger



signature.asc
Description: OpenPGP digital signature

Re: [PATCH 2/5] mtd: nand: omap2: Start dma request before enabling prefetch

[Roger Quadros]

On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> The prefetch engine sends a dma request once a FIFO threshold has
> been met. No other requests are received until the previous request
> is handled.
> 
> Starting an edma transfer (dma_async_issue_pending) results in any
> previous event for the dma channel to be cleared. Therefore, starting
> the prefetch engine before initiating the dma transfer may result in
> the prefetch triggering a dma request but instead of it being handled
> it can end up being cleared. This will result in a hang since the code
> will continue to wait for the dma request to complete.
> 
> By initiating the dma request before enabling the prefetch engine this
> race condition is avoided and no dma request are missed/cleared.
> 
> Signed-off-by: Franklin S Cooper Jr 
> ---
>  drivers/mtd/nand/omap2.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index 957c32f..94d11de 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -509,6 +509,9 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
> *mtd, void *addr,
>   tx->callback_param = >comp;
>   dmaengine_submit(tx);
>  
> + init_completion(>comp);
> + dma_async_issue_pending(info->dma);
> +
>   /*  configure and start prefetch transfer */
>   ret = omap_prefetch_enable(info->gpmc_cs,
>   PREFETCH_FIFOTHRESHOLD_MAX, 0x1, len, is_write, info);
> @@ -516,9 +519,6 @@ static inline int omap_nand_dma_transfer(struct mtd_info 
> *mtd, void *addr,
>   /* PFPW engine is busy, use cpu copy method */
>   goto out_copy_unmap;
>  
> - init_completion(>comp);
> - dma_async_issue_pending(info->dma);
> -
>   /* setup and start DMA using dma_addr */

Is the above comment misplaced after this change?

>   wait_for_completion(>comp);
>   tim = 0;
> 

cheers,
-roger
--
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] ARM: OMAP2+: Update gpmc and nand DT binding documentation

[Roger Quadros]

On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> Add additional details to the gpmc and nand documentation to clarify
> what is needed to enable nand dma prefetch.
> 
> Signed-off-by: Franklin S Cooper Jr 
> ---
>  Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt | 7 
> ++-
>  Documentation/devicetree/bindings/mtd/gpmc-nand.txt| 2 ++
>  2 files changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git 
> a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt 
> b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
> index 704be93..b1e2802 100644
> --- a/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
> +++ b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
> @@ -33,6 +33,10 @@ Required properties:
>   As this will change in the future, filling correct
>   values here is a requirement.
>  
> +GPMC DMA information. Required only when GPMC nand prefetch is enabled.
> + - dmas  GPMC nand prefetch dma channel

s/nand/NAND

> + - dma-names DMA channel name use as a reference within the Nand 
> driver

s/Nand/NAND

This is inevitably going to be "rxtx". So why not say that it should be "rxtx"

Should these bindings go in bindings/mtd/gpmc-nand.txt instead?

> +
>  Timing properties for child nodes. All are optional and default to 0.
>  
>   - gpmc,sync-clk-ps: Minimum clock period for synchronous mode, in 
> picoseconds
> @@ -119,7 +123,8 @@ Example for an AM33xx board:
>   ti,hwmods = "gpmc";
>   reg = <0x5000 0x2000>;
>   interrupts = <100>;
> -
> + dmas = < 52>;
> + dma-names = "rxtx";

Why not define these in the NAND node instead of gpmc node?

>   gpmc,num-cs = <8>;
>   gpmc,num-waitpins = <2>;
>   #address-cells = <2>;
> diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
> b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> index 253e6de..4b0c240 100644
> --- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> +++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
> @@ -61,6 +61,8 @@ Example for an AM33xx board:
>   ti,hwmods = "gpmc";
>   reg = <0x5000 0x36c>;
>   interrupts = <100>;
> + dmas = < 52>;
> + dma-names = "rxtx";
>   gpmc,num-cs = <8>;
>   gpmc,num-waitpins = <2>;
>   #address-cells = <2>;
> 

cheers,
-roger
--
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/5] ARM: dts: am437x/am33xx/omap3/dm816x: Add gpmc dma channel

[Roger Quadros]

On 13/10/15 04:38, Franklin S Cooper Jr wrote:
> Add dma channel information to the gpmc. Although not enabled by
> default this will allow prefetch-dma to be used.
> 
> Signed-off-by: Franklin S Cooper Jr 
> ---
>  arch/arm/boot/dts/am33xx.dtsi | 2 ++
>  arch/arm/boot/dts/am4372.dtsi | 2 ++
>  arch/arm/boot/dts/dm816x.dtsi | 2 ++
>  arch/arm/boot/dts/omap3.dtsi  | 2 ++

How about fixing up omap4/5 and dra7 as well?

cheers,
-roger

>  4 files changed, 8 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index e065f21..f2d8eed 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -819,6 +819,8 @@
>   ti,no-idle-on-init;
>   reg = <0x5000 0x2000>;
>   interrupts = <100>;
> + dmas = < 52>;
> + dma-names = "rxtx";
>   gpmc,num-cs = <7>;
>   gpmc,num-waitpins = <2>;
>   #address-cells = <2>;
> diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
> index ec8b7a3..c02061b 100644
> --- a/arch/arm/boot/dts/am4372.dtsi
> +++ b/arch/arm/boot/dts/am4372.dtsi
> @@ -841,6 +841,8 @@
>   gpmc: gpmc@5000 {
>   compatible = "ti,am3352-gpmc";
>   ti,hwmods = "gpmc";
> + dmas = < 52>;
> + dma-names = "rxtx";
>   clocks = <_gclk>;
>   clock-names = "fck";
>   reg = <0x5000 0x2000>;
> diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
> index 68fb444..d2e5d31 100644
> --- a/arch/arm/boot/dts/dm816x.dtsi
> +++ b/arch/arm/boot/dts/dm816x.dtsi
> @@ -180,6 +180,8 @@
>   #address-cells = <2>;
>   #size-cells = <1>;
>   interrupts = <100>;
> + dmas = < 52>;
> + dma-names = "rxtx";
>   gpmc,num-cs = <6>;
>   gpmc,num-waitpins = <2>;
>   gpio-controller;
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index 7f212b6..9dbbcf6 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -717,6 +717,8 @@
>   ti,hwmods = "gpmc";
>   reg = <0x6e00 0x02d0>;
>   interrupts = <20>;
> + dmas = < 4>;
> + dma-names = "rxtx";
>   gpmc,num-cs = <8>;
>   gpmc,num-waitpins = <4>;
>   #address-cells = <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

Re: [PATCH 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

Franklin,

On 14/10/15 14:36, Roger Quadros wrote:
> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>> Switch from dma_request_channel to allow passing dma channel
>> information from DT rather than hardcoding a value.
>>
>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
> 
> Acked-by: Roger Quadros <rog...@ti.com>
> 
>> ---
>>  drivers/mtd/nand/omap2.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>> index d0f2620..957c32f 100644
>> --- a/drivers/mtd/nand/omap2.c
>> +++ b/drivers/mtd/nand/omap2.c
>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device 
>> *pdev)
>>  dma_cap_zero(mask);
>>  dma_cap_set(DMA_SLAVE, mask);
>>  sig = OMAP24XX_DMA_GPMC;
>> -info->dma = dma_request_channel(mask, omap_dma_filter_fn, );
>> +info->dma = dma_request_slave_channel_compat(mask,
>> +omap_dma_filter_fn, , pdev->dev.parent, "rxtx");
>> +

Just discovered that you are using the parent device node.

How about moving the dma bindings to the nand node instead and using
pdev->dev here?

>>  if (!info->dma) {
>>  dev_err(>dev, "DMA engine request failed\n");
>>  err = -ENXIO;
>>
> 

cheers,
-roger

--
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: dts: omap3: keep ssi ports by default

[Roger Quadros]

Let's keep the SSI ports disabled in the omap3.dtsi to avoid
getting the following noise on the console for boards that don't
use the SSI ports.

"omap_ssi_port 4805a000.ssi-port: DT data is missing cawake gpio (err=-2)"

As omap3-n900 uses one SSI port, mark it enabled there.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 arch/arm/boot/dts/omap3-n900.dts | 1 +
 arch/arm/boot/dts/omap3.dtsi | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/omap3-n900.dts b/arch/arm/boot/dts/omap3-n900.dts
index 5f5e0f3..bdb72fb 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -949,6 +949,7 @@
 };
 
 _port1 {
+   status = "ok";
pinctrl-names = "default";
pinctrl-0 = <_pins>;
 
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index 8a2b253..25b0b37 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -815,6 +815,7 @@
interrupt-parent = <>;
interrupts = <67>,
 <68>;
+   status = "disabled";
};
 
ssi_port2: ssi-port@4805b000 {
@@ -828,6 +829,7 @@
interrupt-parent = <>;
interrupts = <69>,
 <70>;
+   status = "disabled";
};
};
};
-- 
2.1.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 1/5] mtd: nand: omap2: Support parsing dma channel information from DT

[Roger Quadros]

On 14/10/15 16:26, Franklin S Cooper Jr. wrote:
> 
> 
> On 10/14/2015 06:52 AM, Roger Quadros wrote:
>> Franklin,
>>
>> On 14/10/15 14:36, Roger Quadros wrote:
>>> On 13/10/15 04:38, Franklin S Cooper Jr wrote:
>>>> Switch from dma_request_channel to allow passing dma channel
>>>> information from DT rather than hardcoding a value.
>>>>
>>>> Signed-off-by: Franklin S Cooper Jr <fcoo...@ti.com>
>>> Acked-by: Roger Quadros <rog...@ti.com>
>>>
>>>> ---
>>>>  drivers/mtd/nand/omap2.c | 4 +++-
>>>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
>>>> index d0f2620..957c32f 100644
>>>> --- a/drivers/mtd/nand/omap2.c
>>>> +++ b/drivers/mtd/nand/omap2.c
>>>> @@ -1866,7 +1866,9 @@ static int omap_nand_probe(struct platform_device 
>>>> *pdev)
>>>>dma_cap_zero(mask);
>>>>dma_cap_set(DMA_SLAVE, mask);
>>>>sig = OMAP24XX_DMA_GPMC;
>>>> -  info->dma = dma_request_channel(mask, omap_dma_filter_fn, );
>>>> +  info->dma = dma_request_slave_channel_compat(mask,
>>>> +  omap_dma_filter_fn, , pdev->dev.parent, "rxtx");
>>>> +
>> Just discovered that you are using the parent device node.
>>
>> How about moving the dma bindings to the nand node instead and using
>> pdev->dev here?
> Roger,
> 
> From what I can tell the interrupt number and the dma channel will always be
> the same no matter what. Doesn't matter if you have multiple nands or a
> combination of nands and nors. Since that is the case I think it just makes
> sense to leave it in the gpmc parent node and define it once.

Is prefetch/writepost dma used for NOR or any other GPMC peripheral
or only for NAND?

Let's also get Tony's inputs on this.

>>>>if (!info->dma) {
>>>>dev_err(>dev, "DMA engine request failed\n");
>>>>err = -ENXIO;
>>>>

--
cheers,
-roger
--
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] mfd: omap-usb-host: AM3715 OHCI needs 120m functional clock

[Roger Quadros]

Ben,

On 13/10/15 11:23, Ben Dooks wrote:
> On 12/10/15 20:19, Tony Lindgren wrote:
>> * Ben Dooks  [151012 11:22]:
>>> On 12/10/15 18:45, Tony Lindgren wrote:
 * Ben Dooks  [151012 10:38]:
> The AM3715 OHCI controller will not function without the EHCI
> unit's 120m fclk being enabled. If all the ports in the system
> are set to OHCI then the 120m_fclk will not get enabled and no
> devices are detected.
>
> Add a new (optional) property to signal the system must enable
> the 120m_fck for OHCI so that if no EHCI ports are signalled
> then the 120m_fclk should be enabled.
>
> We have found no information about why this is necessary, but
> it is suspected the EHCI controller does not complete the initial
> reset sequence and therefore does not hand control of the USB
> port back.
>
> Signed-off-by: Ben Dooks 
> ---
>  Documentation/devicetree/bindings/usb/omap-usb.txt | 3 +++
>  drivers/mfd/omap-usb-host.c| 4 
>  2 files changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt 
> b/Documentation/devicetree/bindings/usb/omap-usb.txt
> index 38d9bb8..fb5fea5 100644
> --- a/Documentation/devicetree/bindings/usb/omap-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
> @@ -23,6 +23,9 @@ OMAP MUSB GLUE
>  Optional properties:
>   - ctrl-module : phandle of the control module this glue uses to write to
> mailbox
> + - ti,ohci-needs-120m-fck : bool, enable the 120m ehci clock even if just
> +   using ohci. Needed for AM3517 in OHCI only mode.
> +
>  
>  SOC specific device node entry
>  usb_otg_hs: usb_otg_hs@4a0ab000 {
> diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
> index 1d924d1..13880cf 100644
> --- a/drivers/mfd/omap-usb-host.c
> +++ b/drivers/mfd/omap-usb-host.c
> @@ -680,6 +680,10 @@ static int usbhs_omap_probe(struct platform_device 
> *pdev)
>   need_logic_fck |= true;
>   }
>  
> + /* The AM3517 requries the 120m-fck active to allow the OHCI to 
> work */
> + if (of_property_read_bool(dev->of_node, 
> "ti,ohci-needs-120m-fck"))
> + need_logic_fck |= true;
> +
>   if (need_logic_fck) {
>   omap->ehci_logic_fck = devm_clk_get(dev,
>   "usbhost_120m_fck");

 Hmm why not just use the standard device tree clocks property and then do
 clk_get_rate() on the clock?
>>>
>>> I don't see that helps enabling the clock. The code decideds if
>>> no EHCI ports in use that it doesn't need to enable the EHCI fclk.
>>
>> Right, you need to do clk_prepare_enable() in it first? :)
> 
> No, if that was the case the driver would never work for the EHCI case.
> 
> The issue is:
> 
> 1) All ports on the system are set to OHCI
> 2) The omap-usb-host.c does not touch usbhost_120m_fck if no EHCI ports
> 3) The OHCI fails to detect any devices due to point 2.
> 

Instead of your existing approach why not just modify the preceeding
if condition that sets need_logic_fck to suit the OHCI case.

That way you don't need to add a new DT binding.

The old assumption was that 120m_fck logic clock is only needed for
EHCI mode but it looks like OHCI mode needs it as well.

You should also rename omap->ehci_logic_fck to omap->hci_logic_fck
as it is no longer ehci specific.

cheers,
-roger
--
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 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes

[Roger Quadros]

On 13/10/15 03:43, Tony Lindgren wrote:
> * Roger Quadros <rog...@ti.com> [150918 08:00]:
>> Add compatible id, GPMC register resource and interrupt
>> resource to NAND controller nodes.
>>
>> The GPMC driver now implements gpiochip and irqchip so
>> enable gpio-controller and interrupt-controller properties.
>>
>> With this the interrupt parent of NAND node changes so fix it
>> accordingly.
> ...
>> --- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
>> +++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
>> @@ -35,11 +35,14 @@
>>  };
>>  
>>   {
>> -ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
>> +ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
>>  
>>  nand@0,0 {
>> -linux,mtd-name = "micron,mt29f4g16abbda3w";
>> +compatible = "ti,omap2-nand";
>>  reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
>> +interrupt-parent = <>;
>> +interrupts = <20>;
>> +linux,mtd-name = "micron,mt29f4g16abbda3w";
>>  nand-bus-width = <16>;
>>  ti,nand-ecc-opt = "bch8";
>>  gpmc,sync-clk-ps = <0>;
> 
> At least torpedo breaks for NFSroot as NAND now overlaps with
> Ethernet.. What's the policy you have for moving the addresses
> around?

For OMAP3 I intended to use 0x3000 for NAND but incorrectly
used 0x0800 for the torpedo.

Does setting it to 0x3000 work? If not what is the original
NAND address for this board?

> 
> There may be other similar cases to check too.

Just checked that all other OMAP3 boards I've set to 0x3000
if they were 0x0.

cheers,
-roger
--
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] memory: omap-gpmc: dump "before" state before first modification

[Roger Quadros]

On 06/10/15 23:07, Uwe Kleine-König wrote:
> When gpmc_cs_show_timings is called in gpmc_cs_set_timings()
> gpmc_cs_program_settings() was already run which modifies the CONFIG1
> register. So to be more useful do the "before" dump earlier.
> 
> Signed-off-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de>

Acked-by: Roger Quadros <rog...@ti.com>

> ---
>  drivers/memory/omap-gpmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
> index 32ac049f2bc4..6515dfc2b805 100644
> --- a/drivers/memory/omap-gpmc.c
> +++ b/drivers/memory/omap-gpmc.c
> @@ -696,7 +696,6 @@ int gpmc_cs_set_timings(int cs, const struct gpmc_timings 
> *t,
>   int div;
>   u32 l;
>  
> - gpmc_cs_show_timings(cs, "before gpmc_cs_set_timings");
>   div = gpmc_calc_divider(t->sync_clk);
>   if (div < 0)
>   return div;
> @@ -1988,6 +1987,7 @@ static int gpmc_probe_generic_child(struct 
> platform_device *pdev,
>   if (ret < 0)
>   goto err;
>  
> + gpmc_cs_show_timings(cs, "before gpmc_cs_program_settings");
>   ret = gpmc_cs_program_settings(cs, _s);
>   if (ret < 0)
>   goto err;
> 

cheers,
-roger
--
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/2] memory: omap-gpmc: expand the description of the debug facility

[Roger Quadros]

On 06/10/15 23:07, Uwe Kleine-König wrote:
> Most register values for the chip select setup depend on the frequency
> of the fck clock.
> So add a hint that the values setup by the bootloader might differ from
> the right setup for Linux if the bootloader uses a different frequency.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  drivers/memory/Kconfig | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/memory/Kconfig b/drivers/memory/Kconfig
> index c6a644b22af4..1414dd53be57 100644
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -64,6 +64,9 @@ config OMAP_GPMC_DEBUG
> Enables verbose debugging mostly to decode the bootloader provided
> timings. Enable this during development to configure devices
> connected to the GPMC bus.
> +   Note that you cannot just tweak your device tree until the registers
> +   setup by linux match what the bootloader did because that one might
> +   use a different fck frequency influencing most register settings.

Looks like we can't know for sure the GPMC fclk used at the bootloader
else we could have just printed the GPMC fclk pre and post gpmc settings.

How about this instead?

NOTE: Apart from matching the register setup with the bootloader you also need 
to
match the GPMC FCLK frequency used by the bootloader else the GPMC timings
won't be identical with the bootloader timings.

Also you might need to build this patch on top of
http://article.gmane.org/gmane.linux.kernel/2054796

>  
>  config MVEBU_DEVBUS
>   bool "Marvell EBU Device Bus Controller"
> 

cheers,
-roger
--
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/2] memory: omap-gpmc: expand the description of the debug facility

[Roger Quadros]

On 07/10/15 14:02, Uwe Kleine-König wrote:
> Hello Tony,
> 
> On Wed, Oct 07, 2015 at 03:41:19AM -0700, Tony Lindgren wrote:
>> * Uwe Kleine-König <u.kleine-koe...@pengutronix.de> [151007 00:57]:
>>> On Wed, Oct 07, 2015 at 10:45:50AM +0300, Roger Quadros wrote:
>>>>
>>>> How about this instead?
>>>>
>>>> NOTE: Apart from matching the register setup with the bootloader you also 
>>>> need to
>>>> match the GPMC FCLK frequency used by the bootloader else the GPMC timings
>>>> won't be identical with the bootloader timings.
>>> Yeah, sounds better, thanks.
>>>
>>>> Also you might need to build this patch on top of
>>>> http://article.gmane.org/gmane.linux.kernel/2054796
>>> I talked to Tony about this patch yesterday on irc, but I didn't find it
>>> in the archives yet when I sent my mail.
>>
>> Yes sorry here's a repost with your and Roger's changes folded in and
>> edited a bit. Probably best to keep them together with this patch.
>>
>> Does the following look OK to you guys?
> Yes,
> Acked-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de>

Looks good to me too.

cheers,
-roger
--
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/2] memory: omap-gpmc: expand the description of the debug facility

[Roger Quadros]

On 07/10/15 16:40, Tony Lindgren wrote:
> * Roger Quadros <rog...@ti.com> [151007 04:12]:
>> On 07/10/15 14:02, Uwe Kleine-König wrote:
>>> Hello Tony,
>>>
>>> On Wed, Oct 07, 2015 at 03:41:19AM -0700, Tony Lindgren wrote:
>>>> * Uwe Kleine-König <u.kleine-koe...@pengutronix.de> [151007 00:57]:
>>>>> On Wed, Oct 07, 2015 at 10:45:50AM +0300, Roger Quadros wrote:
>>>>>>
>>>>>> How about this instead?
>>>>>>
>>>>>> NOTE: Apart from matching the register setup with the bootloader you 
>>>>>> also need to
>>>>>> match the GPMC FCLK frequency used by the bootloader else the GPMC 
>>>>>> timings
>>>>>> won't be identical with the bootloader timings.
>>>>> Yeah, sounds better, thanks.
>>>>>
>>>>>> Also you might need to build this patch on top of
>>>>>> http://article.gmane.org/gmane.linux.kernel/2054796
>>>>> I talked to Tony about this patch yesterday on irc, but I didn't find it
>>>>> in the archives yet when I sent my mail.
>>>>
>>>> Yes sorry here's a repost with your and Roger's changes folded in and
>>>> edited a bit. Probably best to keep them together with this patch.
>>>>
>>>> Does the following look OK to you guys?
>>> Yes,
>>> Acked-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de>
>>
>> Looks good to me too.
> 
> Are you OK if I use your Acked-by from the previous version on
> this updated version?

Yes please.

cheers,
-roger
--
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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 06/10/15 11:33, Tony Lindgren wrote:
> * Roger Quadros <rog...@ti.com> [150930 04:04]:
>> Tony,
>>
>> On 18/09/15 17:53, Roger Quadros wrote:
>>> Hi,
>>>
>>> We do a couple of things in this series which result in
>>> cleaner device tree implementation, faster perfomance and
>>> multi-platform support. As an added bonus we get new GPI/Interrupt pins
>>> for use in the system.
>>>
>>> - Establish a custom interface between NAND and GPMC driver. This is
>>> needed because all of the NAND registers sit in the GPMC register space.
>>> Some bits like NAND IRQ are even shared with GPMC.
>>>
>>> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
>>> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
>>> This causes performance increase when using prefetch-irq mode.
>>> 30% increase in read, 17% increase in write in prefetch-irq mode.
>>>
>>> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
>>> driver can be used on non-OMAP platforms. e.g. Keystone.
>>>
>>> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
>>> 2 to 4 of these and most of them would be unused otherwise. It also
>>> allows a cleaner implementation of NAND Ready pin status for the NAND 
>>> driver.
>>>
>>> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
>>>
>>> This series is available at
>>> g...@github.com:rogerq/linux.git
>>> in branch
>>> for-v4.4/gpmc-v3
> 
> In general, very nice work :)

Thanks :)

> 
>> I've verified this series with the following boards
>> -dra7-evm
>> -am437x-gp-evm
>> -am335x-evm
>> -beagleboard-c4
>>
>> For legacy boot I've checked only on beagleboard-c4.
> 
> Great.
> 
> Does build and boot and use NAND work throughtout the series?
> Otherwise we'll have hard time bisecting anything..

Yes it does with the following exceptions.

- Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode
but none of the boards seem to be using it so it shouldn't break NAND on 
existing boards.
At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is 
working again.
Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken at 
any point?

- Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break 
NAND on all DT
boards as we expect NAND to be a real child node with compatible id. Simply 
applying the
DT patch at this point makes it work again.

> 
>> Test procedure was to read an existing ubifs partition,
>> create a new one and read it back.
>>
>> Need you to Ack if it looks good.
>> Do you mind taking it via omap-soc once MTD maintainers ack their relevant 
>> parts?
> 
> Sure. I'll try to do some testing on the series first too.
> 
Thanks.

> Can the dts changes be merged separtely? Otherwise we'll have
> a dependency between dts branch and the GPMC/NAND changes.

I'm afraid no. Patch 11 makes us incompatible with the old DT.

cheers,
-roger
--
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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 06/10/15 13:00, Tony Lindgren wrote:
> * Roger Quadros <rog...@ti.com> [151006 02:59]:
>> On 06/10/15 11:33, Tony Lindgren wrote:
>>> Does build and boot and use NAND work throughtout the series?
>>> Otherwise we'll have hard time bisecting anything..
>>
>> Yes it does with the following exceptions.
>>
>> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode
>> but none of the boards seem to be using it so it shouldn't break NAND on 
>> existing boards.
>> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is 
>> working again.
>> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken 
>> at any point?
> 
> OK, no that's fine, no need to squash them together then.
> 
>> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break 
>> NAND on all DT
>> boards as we expect NAND to be a real child node with compatible id. Simply 
>> applying the
>> DT patch at this point makes it work again.
> 
> Hmm can we at least warn about incompatible DT entry when somebody boots
> with an older dtb?

Yes that could be done. It looks like we can use the missing compatible 
property to identify
that it is and old DT entry.

I'll send a v4 of patch 11.

cheers,
-roger


> 
>>>> Test procedure was to read an existing ubifs partition,
>>>> create a new one and read it back.
>>>>
>>>> Need you to Ack if it looks good.
>>>> Do you mind taking it via omap-soc once MTD maintainers ack their relevant 
>>>> parts?
>>>
>>> Sure. I'll try to do some testing on the series first too.
>>>
>> Thanks.
>>
>>> Can the dts changes be merged separtely? Otherwise we'll have
>>> a dependency between dts branch and the GPMC/NAND changes.
>>
>> I'm afraid no. Patch 11 makes us incompatible with the old DT.
> 
> OK. If we can warn about that, then the out of tree users will
> have easier time to update their dts file.
> 
> 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 v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 06/10/15 13:05, Roger Quadros wrote:
> On 06/10/15 13:00, Tony Lindgren wrote:
>> * Roger Quadros <rog...@ti.com> [151006 02:59]:
>>> On 06/10/15 11:33, Tony Lindgren wrote:
>>>> Does build and boot and use NAND work throughtout the series?
>>>> Otherwise we'll have hard time bisecting anything..
>>>
>>> Yes it does with the following exceptions.
>>>
>>> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq mode
>>> but none of the boards seem to be using it so it shouldn't break NAND on 
>>> existing boards.
>>> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode is 
>>> working again.
>>> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not broken 
>>> at any point?
>>
>> OK, no that's fine, no need to squash them together then.
>>
>>> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we break 
>>> NAND on all DT
>>> boards as we expect NAND to be a real child node with compatible id. Simply 
>>> applying the
>>> DT patch at this point makes it work again.
>>
>> Hmm can we at least warn about incompatible DT entry when somebody boots
>> with an older dtb?
> 
> Yes that could be done. It looks like we can use the missing compatible 
> property to identify
> that it is and old DT entry.
> 
> I'll send a v4 of patch 11.

There is another issue. Some of the old DT nodes set the NAND IO address to 0.
As we prevent mapping into first 16MB we see the following message for those 
nodes. e.g. dra7-evm

[1.727598] omap-gpmc 5000.gpmc: cannot remap GPMC CS 0 to 0x
[1.727605] omap-gpmc 5000.gpmc: GPMC CS 0 start cannot be lesser than 
0x100
[1.727611] omap-gpmc 5000.gpmc: failed to probe DT children

Hope this is good enough information that DT needs to be updated?

cheers,
-roger
--
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 v4 11/27] mtd: nand: omap: Clean up device tree support

[Roger Quadros]

Move NAND specific device tree parsing to NAND driver.

The NAND controller node must have a compatible id, register space
resource and interrupt resource.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
v4: Warn if using older incompatible DT i.e. compatible property not present
in nand node.

 arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
 drivers/memory/omap-gpmc.c   | 143 +++
 drivers/mtd/nand/omap2.c | 136 +
 include/linux/platform_data/mtd-nand-omap2.h |   3 +-
 4 files changed, 155 insertions(+), 132 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index ffe646a..e07ca27 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -95,10 +95,7 @@ int gpmc_nand_init(struct omap_nand_platform_data 
*gpmc_nand_data,
gpmc_nand_res[1].start = gpmc_get_irq();
 
memset(, 0, sizeof(struct gpmc_settings));
-   if (gpmc_nand_data->of_node)
-   gpmc_read_settings_dt(gpmc_nand_data->of_node, );
-   else
-   gpmc_set_legacy(gpmc_nand_data, );
+   gpmc_set_legacy(gpmc_nand_data, );
 
s.device_nand = true;
 
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index e75226d..318c187 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -1716,105 +1715,6 @@ static void __maybe_unused gpmc_read_timings_dt(struct 
device_node *np,
of_property_read_bool(np, "gpmc,time-para-granularity");
 }
 
-#if IS_ENABLED(CONFIG_MTD_NAND)
-
-static const char * const nand_xfer_types[] = {
-   [NAND_OMAP_PREFETCH_POLLED] = "prefetch-polled",
-   [NAND_OMAP_POLLED]  = "polled",
-   [NAND_OMAP_PREFETCH_DMA]= "prefetch-dma",
-   [NAND_OMAP_PREFETCH_IRQ]= "prefetch-irq",
-};
-
-static int gpmc_probe_nand_child(struct platform_device *pdev,
-struct device_node *child)
-{
-   u32 val;
-   const char *s;
-   struct gpmc_timings gpmc_t;
-   struct omap_nand_platform_data *gpmc_nand_data;
-
-   if (of_property_read_u32(child, "reg", ) < 0) {
-   dev_err(>dev, "%s has no 'reg' property\n",
-   child->full_name);
-   return -ENODEV;
-   }
-
-   gpmc_nand_data = devm_kzalloc(>dev, sizeof(*gpmc_nand_data),
- GFP_KERNEL);
-   if (!gpmc_nand_data)
-   return -ENOMEM;
-
-   gpmc_nand_data->cs = val;
-   gpmc_nand_data->of_node = child;
-
-   /* Detect availability of ELM module */
-   gpmc_nand_data->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
-   if (gpmc_nand_data->elm_of_node == NULL)
-   gpmc_nand_data->elm_of_node =
-   of_parse_phandle(child, "elm_id", 0);
-
-   /* select ecc-scheme for NAND */
-   if (of_property_read_string(child, "ti,nand-ecc-opt", )) {
-   pr_err("%s: ti,nand-ecc-opt not found\n", __func__);
-   return -ENODEV;
-   }
-
-   if (!strcmp(s, "sw"))
-   gpmc_nand_data->ecc_opt = OMAP_ECC_HAM1_CODE_SW;
-   else if (!strcmp(s, "ham1") ||
-!strcmp(s, "hw") || !strcmp(s, "hw-romcode"))
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_HAM1_CODE_HW;
-   else if (!strcmp(s, "bch4"))
-   if (gpmc_nand_data->elm_of_node)
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH4_CODE_HW;
-   else
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH4_CODE_HW_DETECTION_SW;
-   else if (!strcmp(s, "bch8"))
-   if (gpmc_nand_data->elm_of_node)
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH8_CODE_HW;
-   else
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
-   else if (!strcmp(s, "bch16"))
-   if (gpmc_nand_data->elm_of_node)
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH16_CODE_HW;
-   else
-   pr_err("%s: BCH16 requires ELM support\n", __func__);
-   else
-   pr_err("%s: ti,nand-ecc-opt invalid value\n", __func__);
-
-   /* select data transfer mode for NAND controller */
-   if (!of_property_read_string(chil

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

On 06/10/15 14:01, Tony Lindgren wrote:
> * Roger Quadros <rog...@ti.com> [151006 03:32]:
>> On 06/10/15 13:05, Roger Quadros wrote:
>>> On 06/10/15 13:00, Tony Lindgren wrote:
>>>> * Roger Quadros <rog...@ti.com> [151006 02:59]:
>>>>> On 06/10/15 11:33, Tony Lindgren wrote:
>>>>>> Does build and boot and use NAND work throughtout the series?
>>>>>> Otherwise we'll have hard time bisecting anything..
>>>>>
>>>>> Yes it does with the following exceptions.
>>>>>
>>>>> - Patch 7 "memory: omap-gpmc: Remove NAND IRQ code" breaks prefetch-irq 
>>>>> mode
>>>>> but none of the boards seem to be using it so it shouldn't break NAND on 
>>>>> existing boards.
>>>>> At patch 9 "mtd: nand: omap2: manage NAND interrupts" prefetch-irq mode 
>>>>> is working again.
>>>>> Do you want me to squash patches 7,8,9 so that pre-fetch irq is not 
>>>>> broken at any point?
>>>>
>>>> OK, no that's fine, no need to squash them together then.
>>>>
>>>>> - Then at patch 11 "mtd: nand: omap: Clean up device tree support" we 
>>>>> break NAND on all DT
>>>>> boards as we expect NAND to be a real child node with compatible id. 
>>>>> Simply applying the
>>>>> DT patch at this point makes it work again.
>>>>
>>>> Hmm can we at least warn about incompatible DT entry when somebody boots
>>>> with an older dtb?
>>>
>>> Yes that could be done. It looks like we can use the missing compatible 
>>> property to identify
>>> that it is and old DT entry.
>>>
>>> I'll send a v4 of patch 11.
>>
>> There is another issue. Some of the old DT nodes set the NAND IO address to 
>> 0.
>> As we prevent mapping into first 16MB we see the following message for those 
>> nodes. e.g. dra7-evm
>>
>> [1.727598] omap-gpmc 5000.gpmc: cannot remap GPMC CS 0 to 0x
>> [1.727605] omap-gpmc 5000.gpmc: GPMC CS 0 start cannot be lesser 
>> than 0x100
>> [1.727611] omap-gpmc 5000.gpmc: failed to probe DT children
>>
>> Hope this is good enough information that DT needs to be updated?
> 
> Yes I think that should allow users update the out of tree dts file
> easily.

Fine. The updated series is now at

g...@github.com:rogerq/linux.git
 * [new branch]  for-v4.4/gpmc-v4

cheers,
-roger
--
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] memory: omap-gpmc: Fix unselectable debug option for GPMC

[Roger Quadros]

On 06/10/15 15:13, Tony Lindgren wrote:
> Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> added a debug option for GPMC, but somehow managed to keep it unselectable.
> 
> This probably happened because I had some uncommitted changes and the
> GPMC option is selected in the platform specific Kconfig.
> 
> Let's also update the description a bit, it does not mention that
> enabling the debug option also disables the reset of GPMC controller
> during the init as pointed out by Uwe Kleine-König
> <u.kleine-koe...@pengutronix.de>.
> 
> Fixes: 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> Reported-by: Uwe Kleine-König <u.kleine-koe...@pengutronix.de>
> Signed-off-by: Tony Lindgren <t...@atomide.com>

Acked-by: Roger Quadros <rog...@ti.com>

> ---
>  drivers/memory/Kconfig | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -58,12 +58,13 @@ config OMAP_GPMC
> memory drives like NOR, NAND, OneNAND, SRAM.
>  
>  config OMAP_GPMC_DEBUG
> - bool
> + bool "Enable GPMC debug output and skip reset of GPMC during init"
>   depends on OMAP_GPMC
>   help
> Enables verbose debugging mostly to decode the bootloader provided
> -   timings. Enable this during development to configure devices
> -   connected to the GPMC bus.
> +   timings. To preserve the bootloader provided timings, the reset
> +   of GPMC is skipped during init. Enable this during development to
> +   configure devices connected to the GPMC bus.
>  
>  config MVEBU_DEVBUS
>   bool "Marvell EBU Device Bus Controller"
> 

--
cheers,
-roger
--
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 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Brian/David,

On 18/09/15 17:53, Roger Quadros wrote:
> Hi,
> 
> We do a couple of things in this series which result in
> cleaner device tree implementation, faster perfomance and
> multi-platform support. As an added bonus we get new GPI/Interrupt pins
> for use in the system.
> 
> - Establish a custom interface between NAND and GPMC driver. This is
> needed because all of the NAND registers sit in the GPMC register space.
> Some bits like NAND IRQ are even shared with GPMC.
> 
> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
> This causes performance increase when using prefetch-irq mode.
> 30% increase in read, 17% increase in write in prefetch-irq mode.
> 
> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
> driver can be used on non-OMAP platforms. e.g. Keystone.
> 
> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
> 2 to 4 of these and most of them would be unused otherwise. It also
> allows a cleaner implementation of NAND Ready pin status for the NAND driver.
> 
> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
> 
> This series is available at
> g...@github.com:rogerq/linux.git
> in branch
> for-v4.4/gpmc-v3

Could you please ack the patches affecting the omap2 nand driver?
These would be patches 4, 6, 9, 10, 11, 12, 18. Thanks.

cheers,
-roger

> 
> Changelog:
> v3:
> -Fixed and tested NAND using legacy boot on omap3-beagle.
> -Support rising and falling edge interrupts on WAITpins.
> -Update DT node of all gpmc users.
> 
> Roger Quadros (27):
>   ARM: OMAP2+: gpmc: Add platform data
>   ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data
>   memory: omap-gpmc: Introduce GPMC to NAND interface
>   mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers
>   memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status
>   mtd: nand: omap2: Switch to using GPMC-NAND ops for writebuffer empty
> check
>   memory: omap-gpmc: Remove NAND IRQ code
>   memory: omap-gpmc: Add IRQ ops for GPMC-NAND interface
>   mtd: nand: omap2: manage NAND interrupts
>   mtd: nand: omap: Copy platform data parameters to omap_nand_info data
>   mtd: nand: omap: Clean up device tree support
>   mtd: nand: omap: Update DT binding documentation
>   memory: omap-gpmc: Prevent mapping into 1st 16MB
>   memory: omap-gpmc: Move device tree binding to correct location
>   memory: omap-gpmc: Support general purpose input for WAITPINs
>   memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring
>   memory: omap-gpmc: Add irqchip support to the gpiochip
>   mtd: nand: omap2: Implement NAND ready using gpiolib
>   memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via
> gpmc_regs
>   ARM: dts: dra7: Fix NAND device nodes.
>   ARM: dts: dra7x-evm: Provide NAND ready pin
>   ARM: dts: am437x: Fix NAND device nodes
>   ARM: dts: am437x-gp-evm: Provide NAND ready pin
>   ARM: dts: am335x: Fix NAND device nodes
>   ARM: dts: am335x: Provide NAND ready pin
>   ARM: dts: dm816x: Fix gpmc and NAND node
>   ARM: dts: omap3: Fix gpmc and NAND nodes
> 
>  Documentation/devicetree/bindings/bus/ti-gpmc.txt  | 130 -
>  .../bindings/memory-controllers/omap-gpmc.txt  | 130 +
>  .../devicetree/bindings/mtd/gpmc-nand.txt  |  16 +-
>  arch/arm/boot/dts/am335x-chilisom.dtsi |   7 +-
>  arch/arm/boot/dts/am335x-evm.dts   |   7 +-
>  arch/arm/boot/dts/am335x-igep0033.dtsi |   7 +-
>  arch/arm/boot/dts/am33xx.dtsi  |   4 +
>  arch/arm/boot/dts/am4372.dtsi  |   4 +
>  arch/arm/boot/dts/am437x-gp-evm.dts|   8 +-
>  arch/arm/boot/dts/am43x-epos-evm.dts   |   8 +-
>  arch/arm/boot/dts/dm8168-evm.dts   |   7 +-
>  arch/arm/boot/dts/dm816x.dtsi  |   4 +
>  arch/arm/boot/dts/dra7-evm.dts |   6 +-
>  arch/arm/boot/dts/dra7.dtsi|   4 +
>  arch/arm/boot/dts/dra72-evm.dts|   6 +-
>  arch/arm/boot/dts/logicpd-torpedo-som.dtsi |   7 +-
>  arch/arm/boot/dts/omap3-beagle.dts |   2 +
>  arch/arm/boot/dts/omap3-cm-t3x.dtsi|   5 +-
>  arch/arm/boot/dts/omap3-devkit8000-common.dtsi |   3 +
>  arch/arm/boot/dts/omap3-evm-37xx.dts   |   7 +-
>  arch/arm/boot/dts/omap3-gta04.dtsi |   3 +
>  arch/arm/boot/dts/omap3-igep.dtsi  |   5 +-
>  arch/arm/boot/dts/omap3-igep0020-common.dtsi   |   4 +-
>  arch/arm/boot/dts/omap3-igep0030-common.dtsi   |   4 +
>  arc

Re: [PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Tony,

On 18/09/15 17:53, Roger Quadros wrote:
> Hi,
> 
> We do a couple of things in this series which result in
> cleaner device tree implementation, faster perfomance and
> multi-platform support. As an added bonus we get new GPI/Interrupt pins
> for use in the system.
> 
> - Establish a custom interface between NAND and GPMC driver. This is
> needed because all of the NAND registers sit in the GPMC register space.
> Some bits like NAND IRQ are even shared with GPMC.
> 
> - Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
> with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
> This causes performance increase when using prefetch-irq mode.
> 30% increase in read, 17% increase in write in prefetch-irq mode.
> 
> - Clean up device tree support so that omap-gpmc IP and the omap2 NAND
> driver can be used on non-OMAP platforms. e.g. Keystone.
> 
> - Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
> 2 to 4 of these and most of them would be unused otherwise. It also
> allows a cleaner implementation of NAND Ready pin status for the NAND driver.
> 
> - Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.
> 
> This series is available at
> g...@github.com:rogerq/linux.git
> in branch
> for-v4.4/gpmc-v3

I've verified this series with the following boards
-dra7-evm
-am437x-gp-evm
-am335x-evm
-beagleboard-c4

For legacy boot I've checked only on beagleboard-c4.

Test procedure was to read an existing ubifs partition,
create a new one and read it back.

Need you to Ack if it looks good.
Do you mind taking it via omap-soc once MTD maintainers ack their relevant 
parts?

cheers,
-roger

> 
> Changelog:
> v3:
> -Fixed and tested NAND using legacy boot on omap3-beagle.
> -Support rising and falling edge interrupts on WAITpins.
> -Update DT node of all gpmc users.
> 
> Roger Quadros (27):
>   ARM: OMAP2+: gpmc: Add platform data
>   ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data
>   memory: omap-gpmc: Introduce GPMC to NAND interface
>   mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers
>   memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status
>   mtd: nand: omap2: Switch to using GPMC-NAND ops for writebuffer empty
> check
>   memory: omap-gpmc: Remove NAND IRQ code
>   memory: omap-gpmc: Add IRQ ops for GPMC-NAND interface
>   mtd: nand: omap2: manage NAND interrupts
>   mtd: nand: omap: Copy platform data parameters to omap_nand_info data
>   mtd: nand: omap: Clean up device tree support
>   mtd: nand: omap: Update DT binding documentation
>   memory: omap-gpmc: Prevent mapping into 1st 16MB
>   memory: omap-gpmc: Move device tree binding to correct location
>   memory: omap-gpmc: Support general purpose input for WAITPINs
>   memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring
>   memory: omap-gpmc: Add irqchip support to the gpiochip
>   mtd: nand: omap2: Implement NAND ready using gpiolib
>   memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via
> gpmc_regs
>   ARM: dts: dra7: Fix NAND device nodes.
>   ARM: dts: dra7x-evm: Provide NAND ready pin
>   ARM: dts: am437x: Fix NAND device nodes
>   ARM: dts: am437x-gp-evm: Provide NAND ready pin
>   ARM: dts: am335x: Fix NAND device nodes
>   ARM: dts: am335x: Provide NAND ready pin
>   ARM: dts: dm816x: Fix gpmc and NAND node
>   ARM: dts: omap3: Fix gpmc and NAND nodes
> 
>  Documentation/devicetree/bindings/bus/ti-gpmc.txt  | 130 -
>  .../bindings/memory-controllers/omap-gpmc.txt  | 130 +
>  .../devicetree/bindings/mtd/gpmc-nand.txt  |  16 +-
>  arch/arm/boot/dts/am335x-chilisom.dtsi |   7 +-
>  arch/arm/boot/dts/am335x-evm.dts   |   7 +-
>  arch/arm/boot/dts/am335x-igep0033.dtsi |   7 +-
>  arch/arm/boot/dts/am33xx.dtsi  |   4 +
>  arch/arm/boot/dts/am4372.dtsi  |   4 +
>  arch/arm/boot/dts/am437x-gp-evm.dts|   8 +-
>  arch/arm/boot/dts/am43x-epos-evm.dts   |   8 +-
>  arch/arm/boot/dts/dm8168-evm.dts   |   7 +-
>  arch/arm/boot/dts/dm816x.dtsi  |   4 +
>  arch/arm/boot/dts/dra7-evm.dts |   6 +-
>  arch/arm/boot/dts/dra7.dtsi|   4 +
>  arch/arm/boot/dts/dra72-evm.dts|   6 +-
>  arch/arm/boot/dts/logicpd-torpedo-som.dtsi |   7 +-
>  arch/arm/boot/dts/omap3-beagle.dts |   2 +
>  arch/arm/boot/dts/omap3-cm-t3x.dtsi|   5 +-
>  arch/arm/boot/dts/omap3-devkit8000-common.dtsi |   3 +
>  arch/arm/boot/dts/omap3-evm-37xx.dts   |   7 +-
>  arch/arm/boot/dts

Re: [PATCH 1/3] ARM: OMAP2+: clockdomain: Add mechanism for disabling HW_AUTO

[Roger Quadros]

Paul,

On 16/07/15 16:56, Roger Quadros wrote:
> On 16/07/15 04:25, Paul Walmsley wrote:
>> Hi
>>
>> On Tue, 23 Jun 2015, Roger Quadros wrote:
>>
>>> For some hwmods (e.g. DCAN on DRA7) we need the possibility to
>>> disable HW_AUTO for the clockdomain while the module is active.
>>>
>>> To achieve this there needs to be a refcounting mechanism to
>>> indicate whether any module in the clockdomain has requested
>>> to disable HW_AUTO. We keep track of this in 'noidlecount'.
>>>
>>> Hwmod code must use clkdm_hwmod_prevent_hwauto() to prevent
>>> HW_AUTO of the clockdomain in the future clkdm_hwmod_hwauto() calls.
>>>
>>> It must use clkdm_hwmod_allow_hwauto() to allow HW_AUTO in
>>> the future clkdm_hwmod_hwauto() calls.
>>>
>>> Hwmod code must use clkdm_hwmod_allow_hwauto() whenever it needs
>>> to request HW_AUTO of any clockdomain. (Typically after it has
>>> enabled the module).
>>
>> How about just modifying clkdm_{allow,deny}_idle*() to do the 
>> idle-block-counting?  The default state would be to allow idle, assuming 
>> that the clockdomain flags support that state, and then clkdm_deny_idle*() 
>> would increment the idle-blocking count, clkdm_allow_idle*() would 
>> decrement it.  Then on the 0 -> 1 or 1 -> 0 transitions, the hardware 
>> would be reprogrammed appropiately.
> 
> That is not possible with current hwmod code as clkdm_allow_idle() and 
> clkdm_deny_idle()
> are not symmetrically placed.
> 
> The usual flow is
>   clkdm_enable_hwmod();
>   if (hwsup)
>   clkdm_allow_idle();
> 
> This is mainly because it is redundant to disable auto idle before enableing
> (SW_WKUP) the clockdomain.
> 
> If we take your proposal above then we have to modify all users like so.
> 
>   if (hwsup)
>   clkdm_deny_idle();
>   clkdm_enable_hwmod();
>   if (hwsup)
>   clkdm_allow_idle();
> 
> Is this really what we want?

Need your view on this before I can re-spin this series. Thanks.

cheers,
-roger

> 
>>
>> Anyway, seems like that would avoid races with any 
>> clkdm_{allow,deny}_idle*() users.  
>>
>> A few other comments below:
>>
>>
>>>
>>> Signed-off-by: Roger Quadros <rog...@ti.com>
>>> ---
>>>  arch/arm/mach-omap2/clockdomain.c | 71 
>>> +++
>>>  arch/arm/mach-omap2/clockdomain.h |  5 +++
>>>  2 files changed, 76 insertions(+)
>>>
>>> diff --git a/arch/arm/mach-omap2/clockdomain.c 
>>> b/arch/arm/mach-omap2/clockdomain.c
>>> index 2da3b5e..a7190d2 100644
>>> --- a/arch/arm/mach-omap2/clockdomain.c
>>> +++ b/arch/arm/mach-omap2/clockdomain.c
>>> @@ -1212,6 +1212,77 @@ ccd_exit:
>>> return 0;
>>>  }
>>>  
>>> +/*
>>> + * prevent future hwauto for this clkdm. If clkdm->usecount becomes hwauto 
>>> isn't prevented.
>>> + * It will only prevnt future hwauto but not bring it out of hwauto.
>>> + */
>>
>> If you modify clkdm_{allow,deny}_idle*(), this shouldn't be a major issue 
>> - but all of the function comments should be fixed so that they are 
>> understandable and follow kernel-doc-nano specs.
> 
> OK for updating the comments.
> 
> 
> cheers,
> -roger
> 
>>
>>> +int clkdm_hwmod_prevent_hwauto(struct clockdomain *clkdm, struct 
>>> omap_hwmod *oh)
>>> +{
>>> +   /* The clkdm attribute does not exist yet prior OMAP4 */
>>> +   if (cpu_is_omap24xx() || cpu_is_omap34xx())
>>> +   return 0;
>>> +
>>> +   if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
>>> +   return -EINVAL;
>>> +
>>> +
>>> +   pwrdm_lock(clkdm->pwrdm.ptr);
>>> +   clkdm->noidlecount++;
>>> +   pwrdm_unlock(clkdm->pwrdm.ptr);
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +/*
>>> + * allow future hwauto for this clkdm
>>> + * It won't put clkdm into hwauto. use clkdm_hwmod_hwauto() for that.
>>> + */
>>> +int clkdm_hwmod_allow_hwauto(struct clockdomain *clkdm, struct omap_hwmod 
>>> *oh)
>>> +{
>>> +   /* The clkdm attribute does not exist yet prior OMAP4 */
>>> +   if (cpu_is_omap24xx() || cpu_is_omap34xx())
>>> +   return 0;
>>> +
>>> +   if (!clkdm || !oh || !arch_clkdm || !arch_clkdm->clkdm_clk_disable)
>>> +   

usb: dwc3: gadget: warning on v4.3-rc1

[Roger Quadros]

Hi Felipe,

I see the following warning when g_zero is loaded
and USB cable is plugged to host on dra7-evm's USB1 port.

It happens only once and no longer appears on re-loading gadget
or plugging/unplugging cable.

root@rockdesk:~# modprobe g_zero
[   28.414895] zero gadget: Gadget Zero, version: Cinco de Mayo 2008
[   28.421284] zero gadget: zero ready
root@rockdesk:~# [   35.298997] zero gadget: high-speed config #3: source/sink
[   35.305079] [ cut here ]
[   35.309948] WARNING: CPU: 1 PID: 2269 at drivers/usb/dwc3/gadget.c:697 
dwc3_gadget_ep_disable+0xa8/0xc8 [dwc3]()
[   35.320613] dwc3 4889.usb: ep1in is already disabled
[   35.326174] Modules linked in: usb_f_ss_lb g_zero libcomposite xhci_plat_hcd 
xhci_hcd usbcore dwc3 m25p80 spi_nor udc_core usb_common c_can_platform c_can 
spi_ti_qspi can_dev cpufreq_dt omap_wdt extcon_usb_gx
[   35.353787] CPU: 1 PID: 2269 Comm: irq/415-dwc3 Not tainted 
4.3.0-rc2-1-g895eac6 #289
[   35.362349] Hardware name: Generic DRA74X (Flattened Device Tree)
[   35.368749] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[   35.376877] [] (show_stack) from [] 
(dump_stack+0x80/0x9c)
[   35.384459] [] (dump_stack) from [] 
(warn_slowpath_common+0x7c/0xb8)
[   35.392952] [] (warn_slowpath_common) from [] 
(warn_slowpath_fmt+0x30/0x40)
[   35.402088] [] (warn_slowpath_fmt) from [] 
(dwc3_gadget_ep_disable+0xa8/0xc8 [dwc3])
[   35.412080] [] (dwc3_gadget_ep_disable [dwc3]) from [] 
(disable_ep+0x2c/0x6c [usb_f_ss_lb])
[   35.422676] [] (disable_ep [usb_f_ss_lb]) from [] 
(disable_endpoints+0x18/0x50 [usb_f_ss_lb])
[   35.433445] [] (disable_endpoints [usb_f_ss_lb]) from [] 
(disable_source_sink+0x2c/0x34 [usb_f_ss_lb])
[   35.445032] [] (disable_source_sink [usb_f_ss_lb]) from 
[] (sourcesink_set_alt+0x2c/0x264 [usb_f_ss_lb])
[   35.456810] [] (sourcesink_set_alt [usb_f_ss_lb]) from 
[] (composite_setup+0xc28/0x1574 [libcomposite])
[   35.468500] [] (composite_setup [libcomposite]) from [] 
(dwc3_ep0_delegate_req+0x2c/0x40 [dwc3])
[   35.479559] [] (dwc3_ep0_delegate_req [dwc3]) from [] 
(dwc3_ep0_interrupt+0x984/0xc40 [dwc3])
[   35.490353] [] (dwc3_ep0_interrupt [dwc3]) from [] 
(dwc3_thread_interrupt+0x7a8/0x9c8 [dwc3])
[   35.501195] [] (dwc3_thread_interrupt [dwc3]) from [] 
(irq_thread_fn+0x1c/0x34)
[   35.510689] [] (irq_thread_fn) from [] 
(irq_thread+0x148/0x1a4)
[   35.518724] [] (irq_thread) from [] (kthread+0xd0/0xec)
[   35.526024] [] (kthread) from [] 
(ret_from_fork+0x14/0x24)
[   35.533593] ---[ end trace fe01e35c4677ca2f ]---

cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ARM: OMAP: Remove duplicated operand in OR operation

[Roger Quadros]

On 17/09/15 16:22, Javier Martinez Canillas wrote:
> Commit b483a4a5a711 ("ARM: OMAP4+: hwmod data: Don't prevent RESET of
> USB Host module") added the SYSC_HAS_RESET_STATUS flag to both OMAP4
> and OMAP5 USB host module hwmon sysconfig but that flag was already
> set for OMAP5. So now the flag appears twice in the expression.
> 
> make coccicheck complains with the following message:
> 
> omap_hwmod_54xx_data.c:1846:37-58: duplicated argument to & or |
> 
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>

Acked-by: Roger Quadros <rog...@ti.com>

> 
> ---
> 
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c 
> b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> index 7c3fac035e93..8cdfd9b7ab4f 100644
> --- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> +++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
> @@ -1844,8 +1844,7 @@ static struct omap_hwmod_class_sysconfig 
> omap54xx_usb_host_hs_sysc = {
>   .rev_offs   = 0x,
>   .sysc_offs  = 0x0010,
>   .sysc_flags = (SYSC_HAS_MIDLEMODE | SYSC_HAS_RESET_STATUS |
> -SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET |
> -SYSC_HAS_RESET_STATUS),
> +SYSC_HAS_SIDLEMODE | SYSC_HAS_SOFTRESET),
>   .idlemodes  = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART |
>  SIDLE_SMART_WKUP | MSTANDBY_FORCE | MSTANDBY_NO |
>  MSTANDBY_SMART | MSTANDBY_SMART_WKUP),
> 

--
cheers,
-roger
--
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 v3 07/27] memory: omap-gpmc: Remove NAND IRQ code

[Roger Quadros]

NAND IRQs will now be managed directly in the OMAP NAND driver
so remove the IRQchip model.

Another patch will add back GPIO-IRQchip code to handle the
WAITPIN interrupts.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 arch/arm/mach-omap2/gpmc-nand.c |   4 +-
 drivers/memory/omap-gpmc.c  | 163 +---
 include/linux/omap-gpmc.h   |  11 +--
 3 files changed, 10 insertions(+), 168 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 04e6998..ffe646a 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -80,7 +80,6 @@ int gpmc_nand_init(struct omap_nand_platform_data 
*gpmc_nand_data,
struct resource gpmc_nand_res[] = {
{ .flags = IORESOURCE_MEM, },
{ .flags = IORESOURCE_IRQ, },
-   { .flags = IORESOURCE_IRQ, },
};
 
BUG_ON(gpmc_nand_data->cs >= GPMC_CS_NUM);
@@ -93,8 +92,7 @@ int gpmc_nand_init(struct omap_nand_platform_data 
*gpmc_nand_data,
return err;
}
gpmc_nand_res[0].end = gpmc_nand_res[0].start + NAND_IO_SIZE - 1;
-   gpmc_nand_res[1].start = gpmc_get_client_irq(GPMC_IRQ_FIFOEVENTENABLE);
-   gpmc_nand_res[2].start = gpmc_get_client_irq(GPMC_IRQ_COUNT_EVENT);
+   gpmc_nand_res[1].start = gpmc_get_irq();
 
memset(, 0, sizeof(struct gpmc_settings));
if (gpmc_nand_data->of_node)
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 174c45b..a9071bb 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -123,12 +123,6 @@
 #define GPMC_CS_NAND_ADDRESS   0x20
 #define GPMC_CS_NAND_DATA  0x24
 
-/* Control Commands */
-#define GPMC_CONFIG_RDY_BSY0x0001
-#define GPMC_CONFIG_DEV_SIZE   0x0002
-#define GPMC_CONFIG_DEV_TYPE   0x0003
-#define GPMC_SET_IRQ_STATUS0x0004
-
 #define GPMC_CONFIG1_WRAPBURST_SUPP (1 << 31)
 #define GPMC_CONFIG1_READMULTIPLE_SUPP  (1 << 30)
 #define GPMC_CONFIG1_READTYPE_ASYNC (0 << 29)
@@ -176,17 +170,11 @@
 #define GPMC_CONFIG_WRITEPROTECT   0x0010
 #define WR_RD_PIN_MONITORING   0x0060
 
-#define GPMC_ENABLE_IRQ0x000d
-
 /* ECC commands */
 #define GPMC_ECC_READ  0 /* Reset Hardware ECC for read */
 #define GPMC_ECC_WRITE 1 /* Reset Hardware ECC for write */
 #define GPMC_ECC_READSYN   2 /* Reset before syndrom is read back */
 
-/* XXX: Only NAND irq has been considered,currently these are the only ones 
used
- */
-#defineGPMC_NR_IRQ 2
-
 enum gpmc_clk_domain {
GPMC_CD_FCLK,
GPMC_CD_CLK
@@ -201,11 +189,6 @@ struct gpmc_cs_data {
struct resource mem;
 };
 
-struct gpmc_client_irq {
-   unsignedirq;
-   u32 bitmask;
-};
-
 /* Structure to save gpmc cs context */
 struct gpmc_cs_config {
u32 config1;
@@ -233,10 +216,6 @@ 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 int gpmc_irq_start;
-
 static struct resource gpmc_mem_root;
 static struct gpmc_cs_data gpmc_cs[GPMC_CS_NUM];
 static DEFINE_SPINLOCK(gpmc_mem_lock);
@@ -244,15 +223,13 @@ static DEFINE_SPINLOCK(gpmc_mem_lock);
 static unsigned int gpmc_cs_num = GPMC_CS_NUM;
 static unsigned int gpmc_nr_waitpins;
 static struct device *gpmc_dev;
-static int gpmc_irq;
+static int gpmc_irq = -EINVAL;
 static resource_size_t phys_base, mem_size;
 static unsigned gpmc_capability;
 static void __iomem *gpmc_base;
 
 static struct clk *gpmc_l3_clk;
 
-static irqreturn_t gpmc_handle_irq(int irq, void *dev);
-
 static void gpmc_write_reg(int idx, u32 val)
 {
writel_relaxed(val, gpmc_base + idx);
@@ -1037,14 +1014,6 @@ int gpmc_configure(int cmd, int wval)
u32 regval;
 
switch (cmd) {
-   case GPMC_ENABLE_IRQ:
-   gpmc_write_reg(GPMC_IRQENABLE, wval);
-   break;
-
-   case GPMC_SET_IRQ_STATUS:
-   gpmc_write_reg(GPMC_IRQSTATUS, wval);
-   break;
-
case GPMC_CONFIG_WP:
regval = gpmc_read_reg(GPMC_CONFIG);
if (wval)
@@ -1132,112 +1101,9 @@ struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct 
gpmc_nand_regs *reg, int cs)
 }
 EXPORT_SYMBOL_GPL(gpmc_omap_get_nand_ops);
 
-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) {

[PATCH v3 01/27] ARM: OMAP2+: gpmc: Add platform data

[Roger Quadros]

Add a platform data structure for GPMC. It contains all the necessary
platform information that needs to be passed from platform init code
to GPMC driver.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 include/linux/omap-gpmc.h   |  3 +--
 include/linux/platform_data/gpmc-omap.h | 30 ++
 2 files changed, 31 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/platform_data/gpmc-omap.h

diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 7dee0014..5c79190 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -7,8 +7,7 @@
  *  option) any later version.
  */
 
-/* Maximum Number of Chip Selects */
-#define GPMC_CS_NUM8
+#include 
 
 #define GPMC_CONFIG_WP 0x0005
 
diff --git a/include/linux/platform_data/gpmc-omap.h 
b/include/linux/platform_data/gpmc-omap.h
new file mode 100644
index 000..d32d9de
--- /dev/null
+++ b/include/linux/platform_data/gpmc-omap.h
@@ -0,0 +1,30 @@
+/*
+ * OMAP GPMC Platform data
+ *
+ * Copyright (C) 2014 Texas Instruments, Inc. - http://www.ti.com
+ * Roger Quadros <rog...@ti.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ */
+
+#ifndef _GPMC_OMAP_H_
+#define _GPMC_OMAP_H_
+
+/* Maximum Number of Chip Selects */
+#define GPMC_CS_NUM8
+
+/* Data for each chip select */
+struct gpmc_omap_cs_data {
+   bool valid; /* data is valid */
+   bool is_nand;   /* device within this CS is NAND */
+   struct platform_device *pdev;   /* device within this CS region */
+   unsigned pdata_size;
+};
+
+struct gpmc_omap_platform_data {
+   struct gpmc_omap_cs_data cs[GPMC_CS_NUM];
+};
+
+#endif /* _GPMC_OMAP_H */
-- 
2.1.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 v3 22/27] ARM: dts: am437x: Fix NAND device nodes

[Roger Quadros]

Add compatible id, GPMC register resource and interrupt
resource to NAND controller nodes.

The GPMC driver now implements gpiochip and irqchip so
enable gpio-controller and interrupt-controller properties.

With this the interrupt parent of NAND node changes so fix it
accordingly.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 arch/arm/boot/dts/am4372.dtsi| 4 
 arch/arm/boot/dts/am437x-gp-evm.dts  | 5 -
 arch/arm/boot/dts/am43x-epos-evm.dts | 5 -
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am4372.dtsi b/arch/arm/boot/dts/am4372.dtsi
index 0447c04a..ec8b7a3 100644
--- a/arch/arm/boot/dts/am4372.dtsi
+++ b/arch/arm/boot/dts/am4372.dtsi
@@ -849,6 +849,10 @@
gpmc,num-waitpins = <2>;
#address-cells = <2>;
#size-cells = <1>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index 22038f2..aa96c99 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -794,9 +794,12 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_flash_x8>;
-   ranges = <0 0 0 0x0100>;/* minimum GPMC partition = 16MB */
+   ranges = <0 0 0x0800 0x0100>;   /* CS0 space. Min partition = 
16MB */
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>;  /* device IO registers */
+   interrupt-parent = <>;
+   interrupts = ;
ti,nand-ecc-opt = "bch16";
ti,elm-id = <>;
nand-bus-width = <8>;
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 86c2dfb..9a7786d 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -561,9 +561,12 @@
status = "okay";/* Disable QSPI when enabling GPMC (NAND) */
pinctrl-names = "default";
pinctrl-0 = <_flash_x8>;
-   ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
+   ranges = <0 0 0x0800 0x0100>;   /* CS0 space. Min partition = 
16MB */
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = ;
ti,nand-ecc-opt = "bch16";
ti,elm-id = <>;
nand-bus-width = <8>;
-- 
2.1.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 v3 26/27] ARM: dts: dm816x: Fix gpmc and NAND node

[Roger Quadros]

Make gpmc node gpio+interrupt capable.

Add compatible id, interrupt and wait pin to NAND node.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 arch/arm/boot/dts/dm8168-evm.dts | 7 ---
 arch/arm/boot/dts/dm816x.dtsi| 4 
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/dm8168-evm.dts b/arch/arm/boot/dts/dm8168-evm.dts
index 169a855..faa7abe 100644
--- a/arch/arm/boot/dts/dm8168-evm.dts
+++ b/arch/arm/boot/dts/dm8168-evm.dts
@@ -85,8 +85,12 @@
ranges = <0 0 0x0400 0x0100>;   /* CS0: 16MB for NAND */
 
nand@0,0 {
+   compatible = "ti,omap2-nand";
linux,mtd-name= "micron,mt29f2g16aadwp";
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <100>;
+   ready-gpio = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
#address-cells = <1>;
#size-cells = <1>;
ti,nand-ecc-opt = "bch8";
@@ -106,12 +110,9 @@
gpmc,access-ns = <64>;
gpmc,rd-cycle-ns = <82>;
gpmc,wr-cycle-ns = <82>;
-   gpmc,wait-on-read = "true";
-   gpmc,wait-on-write = "true";
gpmc,bus-turnaround-ns = <0>;
gpmc,cycle2cycle-delay-ns = <0>;
gpmc,clk-activation-ns = <0>;
-   gpmc,wait-monitoring-ns = <0>;
gpmc,wr-access-ns = <40>;
gpmc,wr-data-mux-bus-ns = <0>;
partition@0 {
diff --git a/arch/arm/boot/dts/dm816x.dtsi b/arch/arm/boot/dts/dm816x.dtsi
index 3c99cfa..68fb444 100644
--- a/arch/arm/boot/dts/dm816x.dtsi
+++ b/arch/arm/boot/dts/dm816x.dtsi
@@ -182,6 +182,10 @@
interrupts = <100>;
gpmc,num-cs = <6>;
gpmc,num-waitpins = <2>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
};
 
i2c1: i2c@48028000 {
-- 
2.1.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 v3 25/27] ARM: dts: am335x: Provide NAND ready pin

[Roger Quadros]

On these boards NAND ready pin status is avilable over
GPMC_WAIT0 pin.

For NAND we don't use GPMC wait pin monitoring but
get the NAND Ready/Busy# status using GPIOlib.
GPMC driver provides the WAIT0 pin status over GPIOlib.

Read speed increases from 7869 KiB/ to 8875 KiB/s
and write speed was unchanged at 5100 KiB/s.

Measured using mtd_speedtest.ko.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 arch/arm/boot/dts/am335x-chilisom.dtsi | 4 +---
 arch/arm/boot/dts/am335x-evm.dts   | 4 +---
 arch/arm/boot/dts/am335x-igep0033.dtsi | 4 +---
 3 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-chilisom.dtsi 
b/arch/arm/boot/dts/am335x-chilisom.dtsi
index e2b5e22..3c71c5d 100644
--- a/arch/arm/boot/dts/am335x-chilisom.dtsi
+++ b/arch/arm/boot/dts/am335x-chilisom.dtsi
@@ -212,6 +212,7 @@
reg = <0 0 4>;  /* CS0, offset 0, IO size 4 */
interrupt-parent = <>;
interrupts = <100>;
+   ready-gpio = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
ti,nand-ecc-opt = "bch8";
ti,elm-id = <>;
nand-bus-width = <8>;
@@ -230,12 +231,9 @@
gpmc,access-ns = <64>;
gpmc,rd-cycle-ns = <82>;
gpmc,wr-cycle-ns = <82>;
-   gpmc,wait-on-read = "true";
-   gpmc,wait-on-write = "true";
gpmc,bus-turnaround-ns = <0>;
gpmc,cycle2cycle-delay-ns = <0>;
gpmc,clk-activation-ns = <0>;
-   gpmc,wait-monitoring-ns = <0>;
gpmc,wr-access-ns = <40>;
gpmc,wr-data-mux-bus-ns = <0>;
};
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index bea36e1..c7dfc21 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -523,6 +523,7 @@
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
interrupt-parent = <>;
interrupts = <100>;
+   ready-gpio = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
ti,nand-ecc-opt = "bch8";
ti,elm-id = <>;
nand-bus-width = <8>;
@@ -541,12 +542,9 @@
gpmc,access-ns = <64>;
gpmc,rd-cycle-ns = <82>;
gpmc,wr-cycle-ns = <82>;
-   gpmc,wait-on-read = "true";
-   gpmc,wait-on-write = "true";
gpmc,bus-turnaround-ns = <0>;
gpmc,cycle2cycle-delay-ns = <0>;
gpmc,clk-activation-ns = <0>;
-   gpmc,wait-monitoring-ns = <0>;
gpmc,wr-access-ns = <40>;
gpmc,wr-data-mux-bus-ns = <0>;
/* MTD partition table */
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi 
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index 9252ff1..84d4d50 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -133,6 +133,7 @@
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
interrupt-parent = <>;
interrupts = <100>;
+   ready-gpio = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 */
nand-bus-width = <8>;
ti,nand-ecc-opt = "bch8";
gpmc,device-width = <1>;
@@ -150,12 +151,9 @@
gpmc,access-ns = <64>;
gpmc,rd-cycle-ns = <82>;
gpmc,wr-cycle-ns = <82>;
-   gpmc,wait-on-read = "true";
-   gpmc,wait-on-write = "true";
gpmc,bus-turnaround-ns = <0>;
gpmc,cycle2cycle-delay-ns = <0>;
gpmc,clk-activation-ns = <0>;
-   gpmc,wait-monitoring-ns = <0>;
gpmc,wr-access-ns = <40>;
gpmc,wr-data-mux-bus-ns = <0>;
 
-- 
2.1.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 v3 20/27] ARM: dts: dra7: Fix NAND device nodes.

[Roger Quadros]

Add compatible id, GPMC register resource and interrupt
resource to NAND controller nodes.

The GPMC driver now implements gpiochip and irqchip so
enable gpio-controller and interrupt-controller properties.

With this the interrupt parent of NAND node changes so fix it
accordingly.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 arch/arm/boot/dts/dra7-evm.dts  | 5 -
 arch/arm/boot/dts/dra7.dtsi | 4 
 arch/arm/boot/dts/dra72-evm.dts | 5 -
 3 files changed, 12 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index a6c82e5..8a31161 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -585,9 +585,12 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_flash_x16>;
-   ranges = <0 0 0 0x0100>;/* minimum GPMC partition = 16MB */
+   ranges = <0 0 0x0800 0x0100>;   /* minimum GPMC partition = 
16MB */
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>;  /* device IO registers */
+   interrupt-parent = <_mpu>;
+   interrupts = ;
ti,nand-ecc-opt = "bch8";
ti,elm-id = <>;
nand-bus-width = <16>;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5d65db9..f0a3616 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1389,6 +1389,10 @@
gpmc,num-waitpins = <2>;
#address-cells = <2>;
#size-cells = <1>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
status = "disabled";
};
 
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 6f6bd98..245f5f9 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -395,13 +395,16 @@
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <_default>;
-   ranges = <0 0 0 0x0100>;/* minimum GPMC partition = 16MB */
+   ranges = <0 0 0x0800 0x0100>;   /* minimum GPMC partition = 
16MB */
nand@0,0 {
/* To use NAND, DIP switch SW5 must be set like so:
 * SW5.1 (NAND_SELn) = ON (LOW)
 * SW5.9 (GPMC_WPN) = OFF (HIGH)
 */
+   compatible = "ti,omap2-nand";
reg = <0 0 4>;  /* device IO registers */
+   interrupt-parent = <_mpu>;
+   interrupts = ;
ti,nand-ecc-opt = "bch8";
ti,elm-id = <>;
nand-bus-width = <16>;
-- 
2.1.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 v3 19/27] memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via gpmc_regs

[Roger Quadros]

GPMC_STATUS register is private to the GPMC module and must not be
accessed directly by NAND driver through the gpmc_regs.

They must use gpmc_omap_get_nand_ops() instead.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/memory/omap-gpmc.c   | 2 +-
 include/linux/platform_data/mtd-nand-omap2.h | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 764e24a..4c630ad 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1051,7 +1051,7 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int 
cs)
 {
int i;
 
-   reg->gpmc_status = gpmc_base + GPMC_STATUS;
+   reg->gpmc_status = NULL;/* deprecated */
reg->gpmc_nand_command = gpmc_base + GPMC_CS0_OFFSET +
GPMC_CS_NAND_COMMAND + GPMC_CS_SIZE * cs;
reg->gpmc_nand_address = gpmc_base + GPMC_CS0_OFFSET +
diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
b/include/linux/platform_data/mtd-nand-omap2.h
index 19e509d..17d57a1 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -45,7 +45,6 @@ enum omap_ecc {
 };
 
 struct gpmc_nand_regs {
-   void __iomem*gpmc_status;
void __iomem*gpmc_nand_command;
void __iomem*gpmc_nand_address;
void __iomem*gpmc_nand_data;
@@ -64,6 +63,8 @@ struct gpmc_nand_regs {
void __iomem*gpmc_bch_result4[GPMC_BCH_NUM_REMAINDER];
void __iomem*gpmc_bch_result5[GPMC_BCH_NUM_REMAINDER];
void __iomem*gpmc_bch_result6[GPMC_BCH_NUM_REMAINDER];
+   /* Deprecated. Do not use */
+   void __iomem*gpmc_status;
 };
 
 struct omap_nand_platform_data {
-- 
2.1.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 v3 18/27] mtd: nand: omap2: Implement NAND ready using gpiolib

[Roger Quadros]

The GPMC WAIT pin status are now available over gpiolib.
Update the omap_dev_ready() function to use gpio instead of
directly accessing GPMC register space.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/mtd/nand/omap2.c | 29 +---
 include/linux/platform_data/mtd-nand-omap2.h |  2 +-
 2 files changed, 19 insertions(+), 12 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 228f498..d0f2620 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -184,6 +185,8 @@ struct omap_nand_info {
/* fields specific for BCHx_HW ECC scheme */
struct device   *elm_dev;
struct device_node  *of_node;
+   /* NAND ready gpio */
+   struct gpio_desc*ready_gpiod;
 };
 
 /**
@@ -1047,22 +1050,17 @@ static int omap_wait(struct mtd_info *mtd, struct 
nand_chip *chip)
 }
 
 /**
- * omap_dev_ready - calls the platform specific dev_ready function
+ * omap_dev_ready - checks the NAND Ready GPIO line
  * @mtd: MTD device structure
+ *
+ * Returns true if ready and false if busy.
  */
 static int omap_dev_ready(struct mtd_info *mtd)
 {
-   unsigned int val = 0;
struct omap_nand_info *info = container_of(mtd, struct omap_nand_info,
mtd);
 
-   val = readl(info->reg.gpmc_status);
-
-   if ((val & 0x100) == 0x100) {
-   return 1;
-   } else {
-   return 0;
-   }
+   return gpiod_get_value(info->ready_gpiod);
 }
 
 /**
@@ -1782,7 +1780,9 @@ static int omap_nand_probe(struct platform_device *pdev)
info->reg = pdata->reg;
info->of_node = pdata->of_node;
info->ecc_opt = pdata->ecc_opt;
-   info->dev_ready = pdata->dev_ready;
+   if (pdata->dev_ready)
+   dev_info(>dev, "pdata->dev_ready is 
deprecated\n");
+
info->xfer_type = pdata->xfer_type;
info->devsize = pdata->devsize;
info->elm_of_node = pdata->elm_of_node;
@@ -1815,6 +1815,13 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip->IO_ADDR_W = nand_chip->IO_ADDR_R;
nand_chip->cmd_ctrl  = omap_hwcontrol;
 
+   info->ready_gpiod = devm_gpiod_get_optional(>dev, "ready",
+   GPIOD_IN);
+   if (IS_ERR(info->ready_gpiod)) {
+   dev_err(dev, "failed to get ready gpio\n");
+   return PTR_ERR(info->ready_gpiod);
+   }
+
/*
 * If RDY/BSY line is connected to OMAP then use the omap ready
 * function and the generic nand_wait function which reads the status
@@ -1822,7 +1829,7 @@ static int omap_nand_probe(struct platform_device *pdev)
 * chip delay which is slightly more than tR (AC Timing) of the NAND
 * device and read status register until you get a failure or success
 */
-   if (info->dev_ready) {
+   if (info->ready_gpiod) {
nand_chip->dev_ready = omap_dev_ready;
nand_chip->chip_delay = 0;
} else {
diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
b/include/linux/platform_data/mtd-nand-omap2.h
index ff27e5a..19e509d 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -70,7 +70,6 @@ struct omap_nand_platform_data {
int cs;
struct mtd_partition*parts;
int nr_parts;
-   booldev_ready;
boolflash_bbt;
enum nand_ioxfer_type;
int devsize;
@@ -81,5 +80,6 @@ struct omap_nand_platform_data {
/* deprecated */
struct gpmc_nand_regs   reg;
struct device_node  *of_node;
+   booldev_ready;
 };
 #endif
-- 
2.1.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 v3 17/27] memory: omap-gpmc: Add irqchip support to the gpiochip

[Roger Quadros]

The WAIT pins support either rising or falling edge interrupts
so add irqchip support to the gpiochip model.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/memory/omap-gpmc.c | 132 +
 1 file changed, 132 insertions(+)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index fdf19eeb..764e24a 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -13,6 +13,7 @@
  * published by the Free Software Foundation.
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -227,6 +228,7 @@ struct omap3_gpmc_regs {
 struct gpmc_device {
struct device *dev;
struct gpio_chip gpio_chip;
+   struct irq_chip irq_chip;
 };
 
 static struct resource gpmc_mem_root;
@@ -1944,6 +1946,99 @@ err:
return ret;
 }
 
+static int gpmc_irq_endis(unsigned long hwirq, bool endis)
+{
+   u32 regval;
+
+   /* WAITPIN starts at BIT 8 */
+   hwirq += 8;
+
+   regval = gpmc_read_reg(GPMC_IRQENABLE);
+   if (endis)
+   regval |= BIT(hwirq);
+   else
+   regval &= ~BIT(hwirq);
+   gpmc_write_reg(GPMC_IRQENABLE, regval);
+
+   return 0;
+}
+
+static void gpmc_irq_edge_config(unsigned long hwirq, bool rising_edge)
+{
+   u32 regval;
+
+   /* WAITPIN starts at BIT 8 */
+   hwirq += 8;
+
+   regval = gpmc_read_reg(GPMC_CONFIG);
+   if (rising_edge)
+   regval &= ~BIT(hwirq);
+   else
+   regval |= BIT(hwirq);
+
+   gpmc_write_reg(GPMC_CONFIG, regval);
+}
+
+static void gpmc_irq_mask(struct irq_data *d)
+{
+   gpmc_irq_endis(d->hwirq, false);
+}
+
+static void gpmc_irq_unmask(struct irq_data *d)
+{
+   gpmc_irq_endis(d->hwirq, true);
+}
+
+static void gpmc_irq_ack(struct irq_data *d)
+{
+   unsigned hwirq = d->hwirq + 8;
+
+   /* Setting bit to 1 clears (or Acks) the interrupt */
+   gpmc_write_reg(GPMC_IRQSTATUS, BIT(hwirq));
+}
+
+static int gpmc_irq_set_type(struct irq_data *d, unsigned trigger)
+{
+   /* We can support either rising or falling edge at a time */
+   if (trigger == IRQ_TYPE_EDGE_FALLING)
+   gpmc_irq_edge_config(d->hwirq, false);
+   else if (trigger == IRQ_TYPE_EDGE_RISING)
+   gpmc_irq_edge_config(d->hwirq, true);
+   else
+   return -EINVAL;
+
+   return 0;
+}
+
+static irqreturn_t gpmc_handle_irq(int irq, void *data)
+{
+   int hwirq, virq;
+   u32 regval;
+   struct gpmc_device *gpmc = data;
+
+   regval = gpmc_read_reg(GPMC_IRQSTATUS);
+   regval >>= 8;   /* we're only interested in WAIT pins */
+
+   if (!regval)
+   return IRQ_NONE;
+
+   for (hwirq = 0; hwirq < gpmc->gpio_chip.ngpio; hwirq++) {
+   if (regval & BIT(hwirq)) {
+   virq = irq_find_mapping(gpmc->gpio_chip.irqdomain,
+   hwirq);
+   if (!virq) {
+   dev_warn(gpmc_dev,
+"spurious irq detected hwirq %d, virq 
%d\n",
+hwirq, virq);
+   }
+
+   generic_handle_irq(virq);
+   }
+   }
+
+   return IRQ_HANDLED;
+}
+
 static int gpmc_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
 {
return 1;   /* we're input only */
@@ -1978,6 +2073,7 @@ static int gpmc_gpio_get(struct gpio_chip *chip, unsigned 
offset)
 static int gpmc_gpio_init(struct gpmc_device *gpmc)
 {
int ret;
+   u32 regval;
 
gpmc->gpio_chip.dev = gpmc->dev;
gpmc->gpio_chip.owner = THIS_MODULE;
@@ -1996,7 +2092,43 @@ static int gpmc_gpio_init(struct gpmc_device *gpmc)
return ret;
}
 
+   /* Disable interrupts */
+   gpmc_write_reg(GPMC_IRQENABLE, 0);
+
+   /* clear interrupts */
+   regval = gpmc_read_reg(GPMC_IRQSTATUS);
+   gpmc_write_reg(GPMC_IRQSTATUS, regval);
+
+   gpmc->irq_chip.name = DEVICE_NAME;
+   gpmc->irq_chip.irq_ack = gpmc_irq_ack;
+   gpmc->irq_chip.irq_mask = gpmc_irq_mask;
+   gpmc->irq_chip.irq_unmask = gpmc_irq_unmask;
+   gpmc->irq_chip.irq_set_type = gpmc_irq_set_type;
+
+   ret = gpiochip_irqchip_add(>gpio_chip, >irq_chip, 0,
+  handle_edge_irq, IRQ_TYPE_NONE);
+
+   if (ret) {
+   dev_err(gpmc->dev, "could not add irqchip to gpiochip: %d\n",
+   ret);
+   goto fail;
+   }
+
+   /* We're sharing this IRQ with OMAP NAND driver */
+   ret = devm_request_irq(gpmc->dev, gpmc_irq, gpmc_handle_irq,
+  IRQF_SHARED, DEVICE_NAME, gpmc);
+   if (ret) {
+   dev_err(gpmc->dev, "could not request gpmc irq (%d):

[PATCH v3 15/27] memory: omap-gpmc: Support general purpose input for WAITPINs

[Roger Quadros]

OMAPs can have 2 to 4 WAITPINs that can be used as general purpose
input if not used for memory wait state insertion.

The first user will be the OMAP NAND chip to get the NAND
read/busy status using gpiolib.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/memory/omap-gpmc.c | 130 +
 1 file changed, 120 insertions(+), 10 deletions(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index bcf4b05..518b418 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -223,6 +224,11 @@ struct omap3_gpmc_regs {
struct gpmc_cs_config cs_context[GPMC_CS_NUM];
 };
 
+struct gpmc_device {
+   struct device *dev;
+   struct gpio_chip gpio_chip;
+};
+
 static struct resource gpmc_mem_root;
 static struct gpmc_cs_data gpmc_cs[GPMC_CS_NUM];
 static DEFINE_SPINLOCK(gpmc_mem_lock);
@@ -1919,10 +1925,69 @@ err:
return ret;
 }
 
+static int gpmc_gpio_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+   return 1;   /* we're input only */
+}
+
+static int gpmc_gpio_direction_input(struct gpio_chip *chip, unsigned offset)
+{
+   return 0;   /* we're input only */
+}
+
+static int gpmc_gpio_direction_output(struct gpio_chip *chip, unsigned offset,
+ int value)
+{
+   return -EINVAL; /* we're input only */
+}
+
+static void gpmc_gpio_set(struct gpio_chip *chip, unsigned offset, int value)
+{
+}
+
+static int gpmc_gpio_get(struct gpio_chip *chip, unsigned offset)
+{
+   u32 reg;
+
+   offset += 8;
+
+   reg = gpmc_read_reg(GPMC_STATUS) & BIT(offset);
+
+   return !!reg;
+}
+
+static int gpmc_gpio_init(struct gpmc_device *gpmc)
+{
+   int ret;
+
+   gpmc->gpio_chip.dev = gpmc->dev;
+   gpmc->gpio_chip.owner = THIS_MODULE;
+   gpmc->gpio_chip.label = DEVICE_NAME;
+   gpmc->gpio_chip.ngpio = gpmc_nr_waitpins;
+   gpmc->gpio_chip.get_direction = gpmc_gpio_get_direction;
+   gpmc->gpio_chip.direction_input = gpmc_gpio_direction_input;
+   gpmc->gpio_chip.direction_output = gpmc_gpio_direction_output;
+   gpmc->gpio_chip.set = gpmc_gpio_set;
+   gpmc->gpio_chip.get = gpmc_gpio_get;
+   gpmc->gpio_chip.base = -1;
+
+   ret = gpiochip_add(>gpio_chip);
+   if (ret < 0) {
+   dev_err(gpmc->dev, "could not register gpio chip: %d\n", ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void gpmc_gpio_exit(struct gpmc_device *gpmc)
+{
+   gpiochip_remove(>gpio_chip);
+}
+
 static int gpmc_probe_dt(struct platform_device *pdev)
 {
int ret;
-   struct device_node *child;
const struct of_device_id *of_id =
of_match_device(gpmc_dt_ids, >dev);
 
@@ -1950,6 +2015,14 @@ static int gpmc_probe_dt(struct platform_device *pdev)
return ret;
}
 
+   return 0;
+}
+
+static int gpmc_probe_dt_children(struct platform_device *pdev)
+{
+   int ret;
+   struct device_node *child;
+
for_each_available_child_of_node(pdev->dev.of_node, child) {
 
if (!child->name)
@@ -1959,6 +2032,9 @@ static int gpmc_probe_dt(struct platform_device *pdev)
ret = gpmc_probe_onenand_child(pdev, child);
else
ret = gpmc_probe_generic_child(pdev, child);
+
+   if (ret)
+   return ret;
}
 
return 0;
@@ -1968,6 +2044,11 @@ static int gpmc_probe_dt(struct platform_device *pdev)
 {
return 0;
 }
+
+static int gpmc_probe_dt_children(struct platform_device *pdev)
+{
+   return 0;
+}
 #endif
 
 static int gpmc_probe(struct platform_device *pdev)
@@ -1975,6 +2056,7 @@ static int gpmc_probe(struct platform_device *pdev)
int rc;
u32 l;
struct resource *res;
+   struct gpmc_device *gpmc;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (res == NULL)
@@ -2005,6 +2087,24 @@ static int gpmc_probe(struct platform_device *pdev)
return -EINVAL;
}
 
+
+   if (pdev->dev.of_node) {
+   rc = gpmc_probe_dt(pdev);
+   if (rc)
+   return rc;
+   } else {
+   gpmc_cs_num = GPMC_CS_NUM;
+   gpmc_nr_waitpins = GPMC_NR_WAITPINS;
+   }
+
+
+   gpmc = devm_kzalloc(>dev, sizeof(*gpmc), GFP_KERNEL);
+   if (!gpmc)
+   return -ENOMEM;
+
+   gpmc->dev = >dev;
+   platform_set_drvdata(pdev, gpmc);
+
pm_runtime_enable(>dev);
pm_runtime_get_sync(>dev);
 
@@ -2032,24 +2132,34 @@ static int gpmc_probe(struct platform_device *pdev)
 GPMC_REVISION_MINOR(l));
 
gpmc_mem_init();
+   rc = gpmc_gpio_init(gp

[PATCH v3 27/27] ARM: dts: omap3: Fix gpmc and NAND nodes

[Roger Quadros]

Add compatible id, GPMC register resource and interrupt
resource to NAND controller nodes.

The GPMC driver now implements gpiochip and irqchip so
enable gpio-controller and interrupt-controller properties.

With this the interrupt parent of NAND node changes so fix it
accordingly.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi | 7 +--
 arch/arm/boot/dts/omap3-beagle.dts | 2 ++
 arch/arm/boot/dts/omap3-cm-t3x.dtsi| 5 -
 arch/arm/boot/dts/omap3-devkit8000-common.dtsi | 3 +++
 arch/arm/boot/dts/omap3-evm-37xx.dts   | 7 +--
 arch/arm/boot/dts/omap3-gta04.dtsi | 3 +++
 arch/arm/boot/dts/omap3-igep.dtsi  | 5 -
 arch/arm/boot/dts/omap3-igep0020-common.dtsi   | 4 ++--
 arch/arm/boot/dts/omap3-igep0030-common.dtsi   | 4 
 arch/arm/boot/dts/omap3-ldp.dts| 9 ++---
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi| 5 -
 arch/arm/boot/dts/omap3-pandora-common.dtsi| 3 +++
 arch/arm/boot/dts/omap3-tao3530.dtsi   | 5 -
 arch/arm/boot/dts/omap3.dtsi   | 4 
 arch/arm/boot/dts/omap3430-sdp.dts | 5 -
 15 files changed, 57 insertions(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi 
b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
index 36387b1..4ba73c9 100644
--- a/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
+++ b/arch/arm/boot/dts/logicpd-torpedo-som.dtsi
@@ -35,11 +35,14 @@
 };
 
  {
-   ranges = <0 0 0x 0x100>;/* CS0: 16MB for NAND */
+   ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
 
nand@0,0 {
-   linux,mtd-name = "micron,mt29f4g16abbda3w";
+   compatible = "ti,omap2-nand";
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <20>;
+   linux,mtd-name = "micron,mt29f4g16abbda3w";
nand-bus-width = <16>;
ti,nand-ecc-opt = "bch8";
gpmc,sync-clk-ps = <0>;
diff --git a/arch/arm/boot/dts/omap3-beagle.dts 
b/arch/arm/boot/dts/omap3-beagle.dts
index a547411..bb4df5d 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -384,7 +384,9 @@
 
/* Chip select 0 */
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>;  /* NAND I/O window, 4 bytes */
+   interrupt-parent = <>;
interrupts = <20>;
ti,nand-ecc-opt = "ham1";
nand-bus-width = <16>;
diff --git a/arch/arm/boot/dts/omap3-cm-t3x.dtsi 
b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
index 4d091ca..e9d7e28 100644
--- a/arch/arm/boot/dts/omap3-cm-t3x.dtsi
+++ b/arch/arm/boot/dts/omap3-cm-t3x.dtsi
@@ -261,10 +261,13 @@
 };
 
  {
-   ranges = <0 0 0x 0x0100>;
+   ranges = <0 0 0x3000 0x0100>;   /* CS0: 16MB for NAND */
 
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>;  /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <20>;
nand-bus-width = <8>;
gpmc,device-width = <1>;
ti,nand-ecc-opt = "sw";
diff --git a/arch/arm/boot/dts/omap3-devkit8000-common.dtsi 
b/arch/arm/boot/dts/omap3-devkit8000-common.dtsi
index 9ca2865..e7b46ad 100644
--- a/arch/arm/boot/dts/omap3-devkit8000-common.dtsi
+++ b/arch/arm/boot/dts/omap3-devkit8000-common.dtsi
@@ -204,7 +204,10 @@
ranges = <0 0 0x3000 0x100>;   /* CS0: 16MB for NAND */
 
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <20>;
nand-bus-width = <16>;
gpmc,device-width = <2>;
ti,nand-ecc-opt = "sw";
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts 
b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 16e8ce3..7081e07 100644
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -154,12 +154,15 @@
 };
 
  {
-   ranges = <0 0 0x 0x100>,/* CS0: 16MB for NAND */
+   ranges = <0 0 0x3000 0x100>,/* CS0: 16MB for NAND */
 <5 0 0x2c00 0x0100>;
 
nand@0,0 {
+   compatible = "ti,omap2-nand";
+   reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <20>;
linux,mtd-name= "hynix,h8kds0un0mer-4em";
- 

[PATCH v3 24/27] ARM: dts: am335x: Fix NAND device nodes

[Roger Quadros]

Add compatible id, GPMC register resource and interrupt
resource to NAND controller nodes.

The GPMC driver now implements gpiochip and irqchip so
enable gpio-controller and interrupt-controller properties.

With this the interrupt parent of NAND node changes so fix it
accordingly.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 arch/arm/boot/dts/am335x-chilisom.dtsi | 3 +++
 arch/arm/boot/dts/am335x-evm.dts   | 3 +++
 arch/arm/boot/dts/am335x-igep0033.dtsi | 3 +++
 arch/arm/boot/dts/am33xx.dtsi  | 4 
 4 files changed, 13 insertions(+)

diff --git a/arch/arm/boot/dts/am335x-chilisom.dtsi 
b/arch/arm/boot/dts/am335x-chilisom.dtsi
index 7e9a34d..e2b5e22 100644
--- a/arch/arm/boot/dts/am335x-chilisom.dtsi
+++ b/arch/arm/boot/dts/am335x-chilisom.dtsi
@@ -208,7 +208,10 @@
pinctrl-0 = <_pins>;
ranges = <0 0 0x0800 0x0100>; /* CS0 0 @addr 0x0800, size 
0x0100 */
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>;  /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <100>;
ti,nand-ecc-opt = "bch8";
ti,elm-id = <>;
nand-bus-width = <8>;
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 1942a5c..bea36e1 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -519,7 +519,10 @@
pinctrl-0 = <_pins_s0>;
ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <100>;
ti,nand-ecc-opt = "bch8";
ti,elm-id = <>;
nand-bus-width = <8>;
diff --git a/arch/arm/boot/dts/am335x-igep0033.dtsi 
b/arch/arm/boot/dts/am335x-igep0033.dtsi
index c0e1135..9252ff1 100644
--- a/arch/arm/boot/dts/am335x-igep0033.dtsi
+++ b/arch/arm/boot/dts/am335x-igep0033.dtsi
@@ -129,7 +129,10 @@
ranges = <0 0 0x0800 0x100>;/* CS0: 16MB for NAND */
 
nand@0,0 {
+   compatible = "ti,omap2-nand";
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
+   interrupt-parent = <>;
+   interrupts = <100>;
nand-bus-width = <8>;
ti,nand-ecc-opt = "bch8";
gpmc,device-width = <1>;
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index d23e252..e065f21 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -823,6 +823,10 @@
gpmc,num-waitpins = <2>;
#address-cells = <2>;
#size-cells = <1>;
+   gpio-controller;
+   #gpio-cells = <2>;
+   interrupt-controller;
+   #interrupt-cells = <2>;
status = "disabled";
};
 
-- 
2.1.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 v3 23/27] ARM: dts: am437x-gp-evm: Provide NAND ready pin

[Roger Quadros]

On these boards NAND ready pin status is avilable over
GPMC_WAIT0 pin.

For NAND we don't use GPMC wait pin monitoring but
get the NAND Ready/Busy# status using GPIOlib.
GPMC driver provides the WAIT0 pin status over GPIOlib.

Read speed increases from 16516 KiB/ to 18813 KiB/s
and write speed was unchanged at 9941 KiB/s.

Measured using mtd_speedtest.ko.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 arch/arm/boot/dts/am437x-gp-evm.dts  | 3 +--
 arch/arm/boot/dts/am43x-epos-evm.dts | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/am437x-gp-evm.dts 
b/arch/arm/boot/dts/am437x-gp-evm.dts
index aa96c99..d7bfe9f 100644
--- a/arch/arm/boot/dts/am437x-gp-evm.dts
+++ b/arch/arm/boot/dts/am437x-gp-evm.dts
@@ -800,6 +800,7 @@
reg = <0 0 4>;  /* device IO registers */
interrupt-parent = <>;
interrupts = ;
+   ready-gpio = < 0 GPIO_ACTIVE_HIGH>;/* gpmc_wait0 */
ti,nand-ecc-opt = "bch16";
ti,elm-id = <>;
nand-bus-width = <8>;
@@ -818,11 +819,9 @@
gpmc,access-ns = <30>;
gpmc,rd-cycle-ns = <40>;
gpmc,wr-cycle-ns = <40>;
-   gpmc,wait-pin = <0>;
gpmc,bus-turnaround-ns = <0>;
gpmc,cycle2cycle-delay-ns = <0>;
gpmc,clk-activation-ns = <0>;
-   gpmc,wait-monitoring-ns = <0>;
gpmc,wr-access-ns = <40>;
gpmc,wr-data-mux-bus-ns = <0>;
/* MTD partition table */
diff --git a/arch/arm/boot/dts/am43x-epos-evm.dts 
b/arch/arm/boot/dts/am43x-epos-evm.dts
index 9a7786d..4b26762 100644
--- a/arch/arm/boot/dts/am43x-epos-evm.dts
+++ b/arch/arm/boot/dts/am43x-epos-evm.dts
@@ -567,6 +567,7 @@
reg = <0 0 4>; /* CS0, offset 0, IO size 4 */
interrupt-parent = <>;
interrupts = ;
+   ready-gpio = < 0 GPIO_ACTIVE_HIGH>;/* gpmc_wait0 */
ti,nand-ecc-opt = "bch16";
ti,elm-id = <>;
nand-bus-width = <8>;
@@ -585,11 +586,9 @@
gpmc,access-ns = <30>; /* tCEA + 4*/
gpmc,rd-cycle-ns = <40>;
gpmc,wr-cycle-ns = <40>;
-   gpmc,wait-pin = <0>;
gpmc,bus-turnaround-ns = <0>;
gpmc,cycle2cycle-delay-ns = <0>;
gpmc,clk-activation-ns = <0>;
-   gpmc,wait-monitoring-ns = <0>;
gpmc,wr-access-ns = <40>;
gpmc,wr-data-mux-bus-ns = <0>;
/* MTD partition table */
-- 
2.1.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 v3 21/27] ARM: dts: dra7x-evm: Provide NAND ready pin

[Roger Quadros]

On these boards NAND ready pin status is avilable over
GPMC_WAIT0 pin.

Read speed increases from 13768 KiB/ to 17246 KiB/s.
Write speed was unchanged at 7123 KiB/s.
Measured using mtd_speedtest.ko.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 arch/arm/boot/dts/dra7-evm.dts  | 1 +
 arch/arm/boot/dts/dra72-evm.dts | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 8a31161..4760562 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -591,6 +591,7 @@
reg = <0 0 4>;  /* device IO registers */
interrupt-parent = <_mpu>;
interrupts = ;
+   ready-gpio = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 pin */
ti,nand-ecc-opt = "bch8";
ti,elm-id = <>;
nand-bus-width = <16>;
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index 245f5f9..a11a646 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -405,6 +405,7 @@
reg = <0 0 4>;  /* device IO registers */
interrupt-parent = <_mpu>;
interrupts = ;
+   ready-gpio = < 0 GPIO_ACTIVE_HIGH>; /* gpmc_wait0 pin */
ti,nand-ecc-opt = "bch8";
ti,elm-id = <>;
nand-bus-width = <16>;
-- 
2.1.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 v3 11/27] mtd: nand: omap: Clean up device tree support

[Roger Quadros]

Move NAND specific device tree parsing to NAND driver.

The NAND controller node must have a compatible id, register space
resource and interrupt resource.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 arch/arm/mach-omap2/gpmc-nand.c  |   5 +-
 drivers/memory/omap-gpmc.c   | 135 ++
 drivers/mtd/nand/omap2.c | 136 +++
 include/linux/platform_data/mtd-nand-omap2.h |   3 +-
 4 files changed, 147 insertions(+), 132 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index ffe646a..e07ca27 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -95,10 +95,7 @@ int gpmc_nand_init(struct omap_nand_platform_data 
*gpmc_nand_data,
gpmc_nand_res[1].start = gpmc_get_irq();
 
memset(, 0, sizeof(struct gpmc_settings));
-   if (gpmc_nand_data->of_node)
-   gpmc_read_settings_dt(gpmc_nand_data->of_node, );
-   else
-   gpmc_set_legacy(gpmc_nand_data, );
+   gpmc_set_legacy(gpmc_nand_data, );
 
s.device_nand = true;
 
diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index e75226d..b09e1bc 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -29,7 +29,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include 
@@ -1716,105 +1715,6 @@ static void __maybe_unused gpmc_read_timings_dt(struct 
device_node *np,
of_property_read_bool(np, "gpmc,time-para-granularity");
 }
 
-#if IS_ENABLED(CONFIG_MTD_NAND)
-
-static const char * const nand_xfer_types[] = {
-   [NAND_OMAP_PREFETCH_POLLED] = "prefetch-polled",
-   [NAND_OMAP_POLLED]  = "polled",
-   [NAND_OMAP_PREFETCH_DMA]= "prefetch-dma",
-   [NAND_OMAP_PREFETCH_IRQ]= "prefetch-irq",
-};
-
-static int gpmc_probe_nand_child(struct platform_device *pdev,
-struct device_node *child)
-{
-   u32 val;
-   const char *s;
-   struct gpmc_timings gpmc_t;
-   struct omap_nand_platform_data *gpmc_nand_data;
-
-   if (of_property_read_u32(child, "reg", ) < 0) {
-   dev_err(>dev, "%s has no 'reg' property\n",
-   child->full_name);
-   return -ENODEV;
-   }
-
-   gpmc_nand_data = devm_kzalloc(>dev, sizeof(*gpmc_nand_data),
- GFP_KERNEL);
-   if (!gpmc_nand_data)
-   return -ENOMEM;
-
-   gpmc_nand_data->cs = val;
-   gpmc_nand_data->of_node = child;
-
-   /* Detect availability of ELM module */
-   gpmc_nand_data->elm_of_node = of_parse_phandle(child, "ti,elm-id", 0);
-   if (gpmc_nand_data->elm_of_node == NULL)
-   gpmc_nand_data->elm_of_node =
-   of_parse_phandle(child, "elm_id", 0);
-
-   /* select ecc-scheme for NAND */
-   if (of_property_read_string(child, "ti,nand-ecc-opt", )) {
-   pr_err("%s: ti,nand-ecc-opt not found\n", __func__);
-   return -ENODEV;
-   }
-
-   if (!strcmp(s, "sw"))
-   gpmc_nand_data->ecc_opt = OMAP_ECC_HAM1_CODE_SW;
-   else if (!strcmp(s, "ham1") ||
-!strcmp(s, "hw") || !strcmp(s, "hw-romcode"))
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_HAM1_CODE_HW;
-   else if (!strcmp(s, "bch4"))
-   if (gpmc_nand_data->elm_of_node)
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH4_CODE_HW;
-   else
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH4_CODE_HW_DETECTION_SW;
-   else if (!strcmp(s, "bch8"))
-   if (gpmc_nand_data->elm_of_node)
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH8_CODE_HW;
-   else
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH8_CODE_HW_DETECTION_SW;
-   else if (!strcmp(s, "bch16"))
-   if (gpmc_nand_data->elm_of_node)
-   gpmc_nand_data->ecc_opt =
-   OMAP_ECC_BCH16_CODE_HW;
-   else
-   pr_err("%s: BCH16 requires ELM support\n", __func__);
-   else
-   pr_err("%s: ti,nand-ecc-opt invalid value\n", __func__);
-
-   /* select data transfer mode for NAND controller */
-   if (!of_property_read_string(child, "ti,nand-xfer-type", ))
-   for (val = 0; val < ARRAY_SIZE(nand_xfer_types); val++)

[PATCH v3 10/27] mtd: nand: omap: Copy platform data parameters to omap_nand_info data

[Roger Quadros]

Copy all the platform data parameters to the driver's local data
structure 'omap_nand_info' and use it in the entire driver. This will
make it easer for device tree migration.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/mtd/nand/omap2.c | 26 ++
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 267bcdd..c35405c 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -152,14 +152,18 @@ static struct nand_hw_control omap_gpmc_controller = {
 };
 
 struct omap_nand_info {
-   struct omap_nand_platform_data  *pdata;
struct mtd_info mtd;
struct nand_chipnand;
struct platform_device  *pdev;
 
int gpmc_cs;
-   unsigned long   phys_base;
+   booldev_ready;
+   enum nand_ioxfer_type;
+   int devsize;
enum omap_ecc   ecc_opt;
+   struct device_node  *elm_of_node;
+
+   unsigned long   phys_base;
struct completion   comp;
struct dma_chan *dma;
int gpmc_irq;
@@ -1656,7 +1660,7 @@ static bool omap2_nand_ecc_check(struct omap_nand_info 
*info,
"CONFIG_MTD_NAND_OMAP_BCH not enabled\n");
return false;
}
-   if (ecc_needs_elm && !is_elm_present(info, pdata->elm_of_node)) {
+   if (ecc_needs_elm && !is_elm_present(info, info->elm_of_node)) {
dev_err(>pdev->dev, "ELM not available\n");
return false;
}
@@ -1701,6 +1705,11 @@ static int omap_nand_probe(struct platform_device *pdev)
info->gpmc_cs   = pdata->cs;
info->of_node   = pdata->of_node;
info->ecc_opt   = pdata->ecc_opt;
+   info->dev_ready = pdata->dev_ready;
+   info->xfer_type = pdata->xfer_type;
+   info->devsize = pdata->devsize;
+   info->elm_of_node = pdata->elm_of_node;
+
mtd = >mtd;
mtd->priv   = >nand;
mtd->name   = dev_name(>dev);
@@ -1727,7 +1736,7 @@ static int omap_nand_probe(struct platform_device *pdev)
 * chip delay which is slightly more than tR (AC Timing) of the NAND
 * device and read status register until you get a failure or success
 */
-   if (pdata->dev_ready) {
+   if (info->dev_ready) {
nand_chip->dev_ready = omap_dev_ready;
nand_chip->chip_delay = 0;
} else {
@@ -1741,15 +1750,16 @@ static int omap_nand_probe(struct platform_device *pdev)
nand_chip->options |= NAND_SKIP_BBTSCAN;
 
/* scan NAND device connected to chip controller */
-   nand_chip->options |= pdata->devsize & NAND_BUSWIDTH_16;
+   nand_chip->options |= info->devsize & NAND_BUSWIDTH_16;
if (nand_scan_ident(mtd, 1, NULL)) {
-   dev_err(>pdev->dev, "scan failed, may be bus-width 
mismatch\n");
+   dev_err(>pdev->dev,
+   "scan failed, may be bus-width mismatch\n");
err = -ENXIO;
goto return_error;
}
 
/* re-populate low-level callbacks based on xfer modes */
-   switch (pdata->xfer_type) {
+   switch (info->xfer_type) {
case NAND_OMAP_PREFETCH_POLLED:
nand_chip->read_buf   = omap_read_buf_pref;
nand_chip->write_buf  = omap_write_buf_pref;
@@ -1812,7 +1822,7 @@ static int omap_nand_probe(struct platform_device *pdev)
 
default:
dev_err(>dev,
-   "xfer_type(%d) not supported!\n", pdata->xfer_type);
+   "xfer_type(%d) not supported!\n", info->xfer_type);
err = -EINVAL;
goto return_error;
}
-- 
2.1.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 v3 04/27] mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers

[Roger Quadros]

Deprecate nand register passing via platform data and use
gpmc_omap_get_nand_ops() instead.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 arch/arm/mach-omap2/gpmc-nand.c  | 2 --
 drivers/mtd/nand/omap2.c | 9 -
 include/linux/platform_data/mtd-nand-omap2.h | 4 +++-
 3 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 72918c4..04e6998 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -121,8 +121,6 @@ int gpmc_nand_init(struct omap_nand_platform_data 
*gpmc_nand_data,
if (err < 0)
goto out_free_cs;
 
-   gpmc_update_nand_reg(_nand_data->reg, gpmc_nand_data->cs);
-
if (!gpmc_hwecc_bch_capable(gpmc_nand_data->ecc_opt)) {
pr_err("omap2-nand: Unsupported NAND ECC scheme selected\n");
err = -EINVAL;
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 60fa899..f214fe2 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 
+#include 
 #include 
 
 #defineDRIVER_NAME "omap2-nand"
@@ -169,7 +170,9 @@ struct omap_nand_info {
} iomode;
u_char  *buf;
int buf_len;
+   /* Interface to GPMC */
struct gpmc_nand_regs   reg;
+   struct gpmc_nand_ops*ops;
/* generated at runtime depending on ECC algorithm and layout selected 
*/
struct nand_ecclayout   oobinfo;
/* fields specific for BCHx_HW ECC scheme */
@@ -1677,9 +1680,13 @@ static int omap_nand_probe(struct platform_device *pdev)
 
platform_set_drvdata(pdev, info);
 
+   info->ops = gpmc_omap_get_nand_ops(>reg, info->gpmc_cs);
+   if (!info->ops) {
+   dev_err(>dev, "Failed to get GPMC->NAND interface\n");
+   return -ENODEV;
+   }
info->pdev  = pdev;
info->gpmc_cs   = pdata->cs;
-   info->reg   = pdata->reg;
info->of_node   = pdata->of_node;
info->ecc_opt   = pdata->ecc_opt;
mtd = >mtd;
diff --git a/include/linux/platform_data/mtd-nand-omap2.h 
b/include/linux/platform_data/mtd-nand-omap2.h
index 090bbab..a067f58 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -75,10 +75,12 @@ struct omap_nand_platform_data {
enum nand_ioxfer_type;
int devsize;
enum omap_ecc   ecc_opt;
-   struct gpmc_nand_regs   reg;
 
/* for passing the partitions */
struct device_node  *of_node;
struct device_node  *elm_of_node;
+
+   /* deprecated */
+   struct gpmc_nand_regs   reg;
 };
 #endif
-- 
2.1.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 v3 12/27] mtd: nand: omap: Update DT binding documentation

[Roger Quadros]

Add compatible id and interrupts. The NAND interrupts are
provided by the GPMC controller node.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 Documentation/devicetree/bindings/mtd/gpmc-nand.txt | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt 
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index fb733c4..253e6de 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -13,7 +13,11 @@ Documentation/devicetree/bindings/mtd/nand.txt
 
 Required properties:
 
- - reg:The CS line the peripheral is connected to
+ - compatible: "ti,omap2-nand"
+ - reg:range id (CS number), base offset and length of the
+   NAND I/O space
+ - interrupt-parent: must point to gpmc node
+ - interrupts: gpmc interrupt
 
 Optional properties:
 
@@ -55,20 +59,24 @@ Example for an AM33xx board:
gpmc: gpmc@5000 {
compatible = "ti,am3352-gpmc";
ti,hwmods = "gpmc";
-   reg = <0x5000 0x100>;
+   reg = <0x5000 0x36c>;
interrupts = <100>;
gpmc,num-cs = <8>;
gpmc,num-waitpins = <2>;
#address-cells = <2>;
#size-cells = <1>;
-   ranges = <0 0 0x0800 0x2000>;   /* CS0: NAND */
+   ranges = <0 0 0x0800 0x100>;/* CS0 space, 16MB */
elm_id = <>;
 
nand@0,0 {
-   reg = <0 0 0>; /* CS0, offset 0 */
+   compatible = "ti,omap2-nand";
+   reg = <0 0 4>;  /* CS0, offset 0, NAND I/O 
window 4 */
+   interrupts = <100>;
nand-bus-width = <16>;
ti,nand-ecc-opt = "bch8";
ti,nand-xfer-type = "polled";
+   interrupt-parent = <>;
+   interrupts = <0>, <1>;
 
gpmc,sync-clk-ps = <0>;
gpmc,cs-on-ns = <0>;
-- 
2.1.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 v3 14/27] memory: omap-gpmc: Move device tree binding to correct location

[Roger Quadros]

omap-gpmc.c is a memory controller so move the binding to the
right place.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 .../bindings/{bus/ti-gpmc.txt => memory-controllers/omap-gpmc.txt}| 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename Documentation/devicetree/bindings/{bus/ti-gpmc.txt => 
memory-controllers/omap-gpmc.txt} (100%)

diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt 
b/Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
similarity index 100%
rename from Documentation/devicetree/bindings/bus/ti-gpmc.txt
rename to Documentation/devicetree/bindings/memory-controllers/omap-gpmc.txt
-- 
2.1.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 v3 16/27] memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring

[Roger Quadros]

If the device attached to GPMC wants to use the WAIT pin
for WAIT monitoring then we reserve it internally for
exclusive use.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/memory/omap-gpmc.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 518b418..fdf19eeb 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1779,6 +1779,8 @@ static int gpmc_probe_generic_child(struct 
platform_device *pdev,
const char *name;
int ret, cs;
u32 val;
+   struct gpio_desc *waitpin_desc = NULL;
+   struct gpmc_device *gpmc = platform_get_drvdata(pdev);
 
if (of_property_read_u32(child, "reg", ) < 0) {
dev_err(>dev, "%s has no 'reg' property\n",
@@ -1880,15 +1882,28 @@ static int gpmc_probe_generic_child(struct 
platform_device *pdev,
goto err;
}
 
+   /* Reserve wait pin if it is required and valid */
+   if (gpmc_s.wait_on_read || gpmc_s.wait_on_write) {
+   unsigned wait_pin = gpmc_s.wait_pin;
+
+   waitpin_desc = gpiochip_request_own_desc(>gpio_chip,
+wait_pin, "WAITPIN");
+   if (IS_ERR(waitpin_desc)) {
+   dev_err(>dev, "invalid wait-pin: %d\n", wait_pin);
+   ret = PTR_ERR(waitpin_desc);
+   goto err;
+   }
+   }
+
ret = gpmc_cs_program_settings(cs, _s);
if (ret < 0)
-   goto err;
+   goto err_cs;
 
ret = gpmc_cs_set_timings(cs, _t, _s);
if (ret) {
dev_err(>dev, "failed to set gpmc timings for: %s\n",
child->name);
-   goto err;
+   goto err_cs;
}
 
/* Clear limited address i.e. enable A26-A11 */
@@ -1919,6 +1934,10 @@ err_child_fail:
dev_err(>dev, "failed to create gpmc child %s\n", child->name);
ret = -ENODEV;
 
+err_cs:
+   if (waitpin_desc)
+   gpiochip_free_own_desc(waitpin_desc);
+
 err:
gpmc_cs_free(cs);
 
-- 
2.1.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 v3 13/27] memory: omap-gpmc: Prevent mapping into 1st 16MB

[Roger Quadros]

We have been preventing mapping GPMC children in the
first 1MB but really it has to be the first 16MB as
the minimum GPMC partition size is 16MB.

Also print an error message if CS mapping fails
due to DT requesting address outside the GPMC
map.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/memory/omap-gpmc.c | 24 ++--
 1 file changed, 18 insertions(+), 6 deletions(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index b09e1bc..bcf4b05 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -93,6 +93,14 @@
 #define GPMC_CS_SIZE   0x30
 #defineGPMC_BCH_SIZE   0x10
 
+/*
+ * The first 1MB of GPMC address space is typically mapped to
+ * the internal ROM. Never allocate the first page, to
+ * facilitate bug detection; even if we didn't boot from ROM.
+ * As GPMC minimum partition size is 16MB we can only start from
+ * there.
+ */
+#define GPMC_MEM_START 0x100
 #define GPMC_MEM_END   0x3FFF
 
 #define GPMC_CHUNK_SHIFT   24  /* 16 MB */
@@ -1171,12 +1179,7 @@ static void gpmc_mem_init(void)
 {
int cs;
 
-   /*
-* The first 1MB of GPMC address space is typically mapped to
-* the internal ROM. Never allocate the first page, to
-* facilitate bug detection; even if we didn't boot from ROM.
-*/
-   gpmc_mem_root.start = SZ_1M;
+   gpmc_mem_root.start = GPMC_MEM_START;
gpmc_mem_root.end = GPMC_MEM_END;
 
/* Reserve all regions that has been set up by bootloader */
@@ -1830,6 +1833,15 @@ static int gpmc_probe_generic_child(struct 
platform_device *pdev,
if (ret < 0) {
dev_err(>dev, "cannot remap GPMC CS %d to %pa\n",
cs, );
+   if (res.start < GPMC_MEM_START) {
+   dev_info(>dev,
+"GPMC CS %d start cannot be lesser than 
0x%x\n",
+cs, GPMC_MEM_START);
+   } else if (res.end > GPMC_MEM_END) {
+   dev_info(>dev,
+"GPMC CS %d end cannot be greater than 0x%x\n",
+cs, GPMC_MEM_END);
+   }
goto err;
}
 
-- 
2.1.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 v3 03/27] memory: omap-gpmc: Introduce GPMC to NAND interface

[Roger Quadros]

The OMAP GPMC module has certain registers dedicated for NAND
access and some NAND bits mixed with other GPMC functionality.

For the NAND dedicated registers we have the struct gpmc_nand_regs.

The NAND driver needs to access NAND specific bits from the
following non-dedicated registers
1) FIFOEVENT and TERMCOUNT from GPMC_IRQENABLE and GPMC_IRQSTATUS
2) EMPTYWRITEBUFFERSTATUS from GPMC_STATUS

For accessing these bits we introduce the struct gpmc_nand_ops.

Rename the gpmc_update_nand_reg() API to gpmc_omap_get_nand_ops()
and make it return the gpmc_nand_ops along with updating the
gpmc_nand_regs. This API will be called by the OMAP NAND driver
to access the necessary bits in GPMC register space.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/memory/omap-gpmc.c | 21 
 include/linux/omap-gpmc.h  | 49 --
 2 files changed, 68 insertions(+), 2 deletions(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index 32ac049..a80c53e 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1099,6 +1099,27 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, 
int cs)
}
 }
 
+static struct gpmc_nand_ops nand_ops;
+
+/**
+ * gpmc_omap_get_nand_ops - Get the GPMC NAND interface
+ * @regs: the GPMC NAND register map exclusive for NAND use.
+ * @cs: GPMC chip select number on which the NAND sits. The
+ *  register map returned will be specific to this chip select.
+ *
+ * Returns NULL on error e.g. invalid cs.
+ */
+struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *reg, int 
cs)
+{
+   if (cs >= gpmc_cs_num)
+   return NULL;
+
+   gpmc_update_nand_reg(reg, cs);
+
+   return _ops;
+}
+EXPORT_SYMBOL_GPL(gpmc_omap_get_nand_ops);
+
 int gpmc_get_client_irq(unsigned irq_config)
 {
int i;
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 2dcef1c..7de9f9b 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -14,14 +14,59 @@
 #define GPMC_IRQ_FIFOEVENTENABLE   0x01
 #define GPMC_IRQ_COUNT_EVENT   0x02
 
+enum gpmc_nand_irq {
+   GPMC_NAND_IRQ_FIFOEVENT = 0,
+   GPMC_NAND_IRQ_TERMCOUNT,
+};
+
+/**
+ * gpmc_nand_ops - Interface between NAND and GPMC
+ * @nand_irq_enable: enable the requested GPMC NAND interrupt event.
+ * @nand_irq_disable: disable the requested GPMC NAND interrupt event.
+ * @nand_irq_clear: clears the GPMC NAND interrupt event status.
+ * @nand_irq_status: get the NAND interrupt event status.
+ * @nand_write_buffer_empty: get the NAND write buffer empty status.
+ */
+struct gpmc_nand_ops {
+   int (*nand_irq_enable)(enum gpmc_nand_irq irq);
+   int (*nand_irq_disable)(enum gpmc_nand_irq irq);
+   void (*nand_irq_clear)(enum gpmc_nand_irq irq);
+   u32 (*nand_irq_status)(void);
+   bool (*nand_writebuffer_empty)(void);
+};
+
+struct gpmc_nand_regs;
+
+#if IS_ENABLED(CONFIG_OMAP_GPMC)
+struct gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs *regs,
+int cs);
+#else
+static inline gpmc_nand_ops *gpmc_omap_get_nand_ops(struct gpmc_nand_regs 
*regs,
+   int cs)
+{
+   return NULL;
+}
+#endif /* CONFIG_OMAP_GPMC */
+
+/**/
+
+/* deprecated APIs */
+#if IS_ENABLED(CONFIG_OMAP_GPMC)
+void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
+#else
+static inline void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs)
+{
+   reg = NULL;
+}
+#endif /* CONFIG_OMAP_GPMC */
+/**/
+
 extern int gpmc_calc_timings(struct gpmc_timings *gpmc_t,
 struct gpmc_settings *gpmc_s,
 struct gpmc_device_timings *dev_t);
 
-struct gpmc_nand_regs;
 struct device_node;
 
-extern void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, int cs);
 extern int gpmc_get_client_irq(unsigned irq_config);
 
 extern unsigned int gpmc_ticks_to_ns(unsigned int ticks);
-- 
2.1.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 v3 08/27] memory: omap-gpmc: Add IRQ ops for GPMC-NAND interface

[Roger Quadros]

Provide functions to enable/disable NAND IRQs, get
NAND event status and clear NAND events.

The NAND events of interest are TERMCOUNT and FIFOEVENT.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/memory/omap-gpmc.c | 50 ++
 include/linux/omap-gpmc.h  |  4 
 2 files changed, 54 insertions(+)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index a9071bb..e75226d 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -1078,8 +1078,58 @@ static bool gpmc_nand_writebuffer_empty(void)
return false;
 }
 
+static int gpmc_nand_irq_enable(enum gpmc_nand_irq irq)
+{
+   u32 reg;
+
+   if (irq > GPMC_NAND_IRQ_TERMCOUNT)
+   return -EINVAL;
+
+   reg = gpmc_read_reg(GPMC_IRQENABLE);
+   reg |= BIT(irq);
+   gpmc_write_reg(GPMC_IRQENABLE, reg);
+
+   return 0;
+}
+
+static int gpmc_nand_irq_disable(enum gpmc_nand_irq irq)
+{
+   u32 reg;
+
+   if (irq > GPMC_NAND_IRQ_TERMCOUNT)
+   return -EINVAL;
+
+   reg = gpmc_read_reg(GPMC_IRQENABLE);
+   reg &= ~BIT(irq);
+   gpmc_write_reg(GPMC_IRQENABLE, reg);
+
+   return 0;
+}
+
+static void gpmc_nand_irq_clear(enum gpmc_nand_irq irq)
+{
+   if (irq > GPMC_NAND_IRQ_TERMCOUNT)
+   return;
+
+   /* setting bit to 1 clears the bit in IRQSTATUS */
+   gpmc_write_reg(GPMC_IRQSTATUS, BIT(irq));
+}
+
+static u32 gpmc_nand_irq_status(void)
+{
+   u32 reg = gpmc_read_reg(GPMC_IRQSTATUS);
+
+   /* Mask out non-NAND bits */
+   reg &= GPMC_IRQENABLE_FIFOEVENT | GPMC_IRQENABLE_TERMCOUNT;
+   return reg;
+}
+
 static struct gpmc_nand_ops nand_ops = {
.nand_writebuffer_empty = gpmc_nand_writebuffer_empty,
+   .nand_irq_enable = gpmc_nand_irq_enable,
+   .nand_irq_disable = gpmc_nand_irq_disable,
+   .nand_irq_clear = gpmc_nand_irq_clear,
+   .nand_irq_status = gpmc_nand_irq_status,
 };
 
 /**
diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 58f6bd2..b76cec3 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -11,6 +11,10 @@
 
 #define GPMC_CONFIG_WP 0x0005
 
+/* GPMC IRQENABLE/IRQSTATUS BIT defs */
+#define GPMC_IRQENABLE_FIFOEVENT   BIT(0)
+#define GPMC_IRQENABLE_TERMCOUNT   BIT(1)
+
 enum gpmc_nand_irq {
GPMC_NAND_IRQ_FIFOEVENT = 0,
GPMC_NAND_IRQ_TERMCOUNT,
-- 
2.1.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 v3 06/27] mtd: nand: omap2: Switch to using GPMC-NAND ops for writebuffer empty check

[Roger Quadros]

Instead of accessing the gpmc_status register directly start
using the gpmc_nand_ops->nand_writebuffer_empty() helper
to check write buffer empty status.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/mtd/nand/omap2.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index f214fe2..0eb0b8c 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -289,14 +289,13 @@ static void omap_write_buf8(struct mtd_info *mtd, const 
u_char *buf, int len)
struct omap_nand_info *info = container_of(mtd,
struct omap_nand_info, mtd);
u_char *p = (u_char *)buf;
-   u32 status = 0;
+   bool status;
 
while (len--) {
iowrite8(*p++, info->nand.IO_ADDR_W);
/* wait until buffer is available for write */
do {
-   status = readl(info->reg.gpmc_status) &
-   STATUS_BUFF_EMPTY;
+   status = info->ops->nand_writebuffer_empty();
} while (!status);
}
 }
@@ -325,7 +324,7 @@ static void omap_write_buf16(struct mtd_info *mtd, const 
u_char * buf, int len)
struct omap_nand_info *info = container_of(mtd,
struct omap_nand_info, mtd);
u16 *p = (u16 *) buf;
-   u32 status = 0;
+   bool status;
/* FIXME try bursts of writesw() or DMA ... */
len >>= 1;
 
@@ -333,8 +332,7 @@ static void omap_write_buf16(struct mtd_info *mtd, const 
u_char * buf, int len)
iowrite16(*p++, info->nand.IO_ADDR_W);
/* wait until buffer is available for write */
do {
-   status = readl(info->reg.gpmc_status) &
-   STATUS_BUFF_EMPTY;
+   status = info->ops->nand_writebuffer_empty();
} while (!status);
}
 }
-- 
2.1.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 v3 09/27] mtd: nand: omap2: manage NAND interrupts

[Roger Quadros]

Manage NAND interrupts here using the GPMC IRQ ops.

This causes performance in prefetch-irq mode to be increased

from
[   38.252811] mtd_speedtest: eraseblock write speed is 5576 KiB/s
[   39.265259] mtd_speedtest: eraseblock read speed is 8192 KiB/s

to
[   35.666446] mtd_speedtest: eraseblock write speed is 6537 KiB/s
[   36.444842] mtd_speedtest: eraseblock read speed is 10680 KiB/s

Test results on dra7-evm using mtd_speedtest.ko

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/mtd/nand/omap2.c | 65 +++-
 1 file changed, 31 insertions(+), 34 deletions(-)

diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 0eb0b8c..267bcdd 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -162,8 +162,7 @@ struct omap_nand_info {
enum omap_ecc   ecc_opt;
struct completion   comp;
struct dma_chan *dma;
-   int gpmc_irq_fifo;
-   int gpmc_irq_count;
+   int gpmc_irq;
enum {
OMAP_NAND_IO_READ = 0,  /* read */
OMAP_NAND_IO_WRITE, /* write */
@@ -579,12 +578,17 @@ static irqreturn_t omap_nand_irq(int this_irq, void *dev)
 {
struct omap_nand_info *info = (struct omap_nand_info *) dev;
u32 bytes;
+   u32 irqstatus;
+
+   irqstatus = info->ops->nand_irq_status();
+   if (!irqstatus)
+   return IRQ_NONE;
 
bytes = readl(info->reg.gpmc_prefetch_status);
bytes = 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 (this_irq == info->gpmc_irq_count)
+   if (irqstatus & GPMC_IRQENABLE_TERMCOUNT)
goto done;
 
if (info->buf_len && (info->buf_len < bytes))
@@ -601,17 +605,25 @@ static irqreturn_t omap_nand_irq(int this_irq, void *dev)
(u32 *)info->buf, bytes >> 2);
info->buf = info->buf + bytes;
 
-   if (this_irq == info->gpmc_irq_count)
+   if (irqstatus & GPMC_IRQENABLE_TERMCOUNT)
goto done;
}
 
+   /* Clear FIFOEVENT STATUS */
+   info->ops->nand_irq_clear(GPMC_NAND_IRQ_FIFOEVENT);
+
return IRQ_HANDLED;
 
 done:
complete(>comp);
 
-   disable_irq_nosync(info->gpmc_irq_fifo);
-   disable_irq_nosync(info->gpmc_irq_count);
+   /* Clear FIFOEVENT and TERMCOUNT STATUS */
+   info->ops->nand_irq_clear(GPMC_NAND_IRQ_FIFOEVENT);
+   info->ops->nand_irq_clear(GPMC_NAND_IRQ_TERMCOUNT);
+
+   /* Disable Interrupt generation */
+   info->ops->nand_irq_disable(GPMC_NAND_IRQ_FIFOEVENT);
+   info->ops->nand_irq_disable(GPMC_NAND_IRQ_TERMCOUNT);
 
return IRQ_HANDLED;
 }
@@ -646,8 +658,9 @@ static void omap_read_buf_irq_pref(struct mtd_info *mtd, 
u_char *buf, int len)
 
info->buf_len = len;
 
-   enable_irq(info->gpmc_irq_count);
-   enable_irq(info->gpmc_irq_fifo);
+   /* Enable Interrupt generation */
+   info->ops->nand_irq_enable(GPMC_NAND_IRQ_TERMCOUNT);
+   info->ops->nand_irq_enable(GPMC_NAND_IRQ_FIFOEVENT);
 
/* waiting for read to complete */
wait_for_completion(>comp);
@@ -696,8 +709,9 @@ static void omap_write_buf_irq_pref(struct mtd_info *mtd,
 
info->buf_len = len;
 
-   enable_irq(info->gpmc_irq_count);
-   enable_irq(info->gpmc_irq_fifo);
+   /* Enable Interrupt generation */
+   info->ops->nand_irq_enable(GPMC_NAND_IRQ_TERMCOUNT);
+   info->ops->nand_irq_enable(GPMC_NAND_IRQ_FIFOEVENT);
 
/* waiting for write to complete */
wait_for_completion(>comp);
@@ -1776,35 +1790,18 @@ static int omap_nand_probe(struct platform_device *pdev)
break;
 
case NAND_OMAP_PREFETCH_IRQ:
-   info->gpmc_irq_fifo = platform_get_irq(pdev, 0);
-   if (info->gpmc_irq_fifo <= 0) {
-   dev_err(>dev, "error getting fifo irq\n");
-   err = -ENODEV;
-   goto return_error;
-   }
-   err = devm_request_irq(>dev, info->gpmc_irq_fifo,
-   omap_nand_irq, IRQF_SHARED,
-   "gpmc-nand-fifo", info);
-   if (err) {
-   dev_err(>dev, "requesting irq(%d) error:%d",
-   info->gpmc_irq_fifo, err);
-   info->gpmc_irq_fifo = 0;
-   goto r

[PATCH v3 05/27] memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status

[Roger Quadros]

This is needed by OMAP NAND driver to poll the empty status
of the writebuffer.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 drivers/memory/omap-gpmc.c | 14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c
index a80c53e..174c45b 100644
--- a/drivers/memory/omap-gpmc.c
+++ b/drivers/memory/omap-gpmc.c
@@ -81,6 +81,8 @@
 
 #define GPMC_CONFIG_LIMITEDADDRESS BIT(1)
 
+#define GPMC_STATUS_EMPTYWRITEBUFFERSTATUS BIT(0)
+
 #defineGPMC_CONFIG2_CSEXTRADELAY   BIT(7)
 #defineGPMC_CONFIG3_ADVEXTRADELAY  BIT(7)
 #defineGPMC_CONFIG4_OEEXTRADELAY   BIT(7)
@@ -1099,7 +1101,17 @@ void gpmc_update_nand_reg(struct gpmc_nand_regs *reg, 
int cs)
}
 }
 
-static struct gpmc_nand_ops nand_ops;
+static bool gpmc_nand_writebuffer_empty(void)
+{
+   if (gpmc_read_reg(GPMC_STATUS) & GPMC_STATUS_EMPTYWRITEBUFFERSTATUS)
+   return true;
+
+   return false;
+}
+
+static struct gpmc_nand_ops nand_ops = {
+   .nand_writebuffer_empty = gpmc_nand_writebuffer_empty,
+};
 
 /**
  * gpmc_omap_get_nand_ops - Get the GPMC NAND interface
-- 
2.1.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 v3 02/27] ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data

[Roger Quadros]

Add device_timings, gpmc_timings and gpmc_setting to
gpmc platform data.

Signed-off-by: Roger Quadros <rog...@ti.com>
---
 include/linux/omap-gpmc.h   | 134 ---
 include/linux/platform_data/gpmc-omap.h | 137 
 2 files changed, 137 insertions(+), 134 deletions(-)

diff --git a/include/linux/omap-gpmc.h b/include/linux/omap-gpmc.h
index 5c79190..2dcef1c 100644
--- a/include/linux/omap-gpmc.h
+++ b/include/linux/omap-gpmc.h
@@ -14,140 +14,6 @@
 #define GPMC_IRQ_FIFOEVENTENABLE   0x01
 #define GPMC_IRQ_COUNT_EVENT   0x02
 
-#define GPMC_BURST_4   4   /* 4 word burst */
-#define GPMC_BURST_8   8   /* 8 word burst */
-#define GPMC_BURST_16  16  /* 16 word burst */
-#define GPMC_DEVWIDTH_8BIT 1   /* 8-bit device width */
-#define GPMC_DEVWIDTH_16BIT2   /* 16-bit device width */
-#define GPMC_MUX_AAD   1   /* Addr-Addr-Data multiplex */
-#define GPMC_MUX_AD2   /* Addr-Data multiplex */
-
-/* bool type time settings */
-struct gpmc_bool_timings {
-   bool cycle2cyclediffcsen;
-   bool cycle2cyclesamecsen;
-   bool we_extra_delay;
-   bool oe_extra_delay;
-   bool adv_extra_delay;
-   bool cs_extra_delay;
-   bool time_para_granularity;
-};
-
-/*
- * Note that all values in this struct are in nanoseconds except sync_clk
- * (which is in picoseconds), while the register values are in gpmc_fck cycles.
- */
-struct gpmc_timings {
-   /* Minimum clock period for synchronous mode (in picoseconds) */
-   u32 sync_clk;
-
-   /* Chip-select signal timings corresponding to GPMC_CS_CONFIG2 */
-   u32 cs_on;  /* Assertion time */
-   u32 cs_rd_off;  /* Read deassertion time */
-   u32 cs_wr_off;  /* Write deassertion time */
-
-   /* ADV signal timings corresponding to GPMC_CONFIG3 */
-   u32 adv_on; /* Assertion time */
-   u32 adv_rd_off; /* Read deassertion time */
-   u32 adv_wr_off; /* Write deassertion time */
-
-   /* WE signals timings corresponding to GPMC_CONFIG4 */
-   u32 we_on;  /* WE assertion time */
-   u32 we_off; /* WE deassertion time */
-
-   /* OE signals timings corresponding to GPMC_CONFIG4 */
-   u32 oe_on;  /* OE assertion time */
-   u32 oe_off; /* OE deassertion time */
-
-   /* Access time and cycle time timings corresponding to GPMC_CONFIG5 */
-   u32 page_burst_access;  /* Multiple access word delay */
-   u32 access; /* Start-cycle to first data valid delay */
-   u32 rd_cycle;   /* Total read cycle time */
-   u32 wr_cycle;   /* Total write cycle time */
-
-   u32 bus_turnaround;
-   u32 cycle2cycle_delay;
-
-   u32 wait_monitoring;
-   u32 clk_activation;
-
-   /* The following are only on OMAP3430 */
-   u32 wr_access;  /* WRACCESSTIME */
-   u32 wr_data_mux_bus;/* WRDATAONADMUXBUS */
-
-   struct gpmc_bool_timings bool_timings;
-};
-
-/* Device timings in picoseconds */
-struct gpmc_device_timings {
-   u32 t_ceasu;/* address setup to CS valid */
-   u32 t_avdasu;   /* address setup to ADV valid */
-   /* XXX: try to combine t_avdp_r & t_avdp_w. Issue is
-* of tusb using these timings even for sync whilst
-* ideally for adv_rd/(wr)_off it should have considered
-* t_avdh instead. This indirectly necessitates r/w
-* variations of t_avdp as it is possible to have one
-* sync & other async
-*/
-   u32 t_avdp_r;   /* ADV low time (what about t_cer ?) */
-   u32 t_avdp_w;
-   u32 t_aavdh;/* address hold time */
-   u32 t_oeasu;/* address setup to OE valid */
-   u32 t_aa;   /* access time from ADV assertion */
-   u32 t_iaa;  /* initial access time */
-   u32 t_oe;   /* access time from OE assertion */
-   u32 t_ce;   /* access time from CS asertion */
-   u32 t_rd_cycle; /* read cycle time */
-   u32 t_cez_r;/* read CS deassertion to high Z */
-   u32 t_cez_w;/* write CS deassertion to high Z */
-   u32 t_oez;  /* OE deassertion to high Z */
-   u32 t_weasu;/* address setup to WE valid */
-   u32 t_wpl;  /* write assertion time */
-   u32 t_wph;  /* write deassertion time */
-   u32 t_wr_cycle; /* write cycle time */
-
-   u32 clk;
-   u32 t_bacc; /* burst access valid clock to output delay */
-   u32 t_ces;  /* CS setup time to clk */
-   u32 t_avds; /* ADV setup time to clk */
-   u32 t_avdh; /* ADV hold time from clk */
-   u32 t_ach;  /* address hold time from clk */
-   u32 t_rdyo; /* clk to ready valid */
-
-   u32 t_ce_rdyz;  /* XXX: description ?

[PATCH v3 00/27] memory: omap-gpmc: mtd: nand: Support GPMC NAND on non-OMAP platforms

[Roger Quadros]

Hi,

We do a couple of things in this series which result in
cleaner device tree implementation, faster perfomance and
multi-platform support. As an added bonus we get new GPI/Interrupt pins
for use in the system.

- Establish a custom interface between NAND and GPMC driver. This is
needed because all of the NAND registers sit in the GPMC register space.
Some bits like NAND IRQ are even shared with GPMC.

- Remove NAND IRQ handling from omap-gpmc driver, share the GPMC IRQ
with the omap2-nand driver and handle NAND IRQ events in the NAND driver.
This causes performance increase when using prefetch-irq mode.
30% increase in read, 17% increase in write in prefetch-irq mode.

- Clean up device tree support so that omap-gpmc IP and the omap2 NAND
driver can be used on non-OMAP platforms. e.g. Keystone.

- Implement GPIOCHIP + IRQCHIP for the GPMC WAITPINS. SoCs can contain
2 to 4 of these and most of them would be unused otherwise. It also
allows a cleaner implementation of NAND Ready pin status for the NAND driver.

- Implement GPIOlib based NAND ready pin checking for OMAP NAND driver.

This series is available at
g...@github.com:rogerq/linux.git
in branch
for-v4.4/gpmc-v3

cheers,
-roger

Changelog:
v3:
-Fixed and tested NAND using legacy boot on omap3-beagle.
-Support rising and falling edge interrupts on WAITpins.
-Update DT node of all gpmc users.

Roger Quadros (27):
  ARM: OMAP2+: gpmc: Add platform data
  ARM: OMAP2+: gpmc: Add gpmc timings and settings to platform data
  memory: omap-gpmc: Introduce GPMC to NAND interface
  mtd: nand: omap2: Use gpmc_omap_get_nand_ops() to get NAND registers
  memory: omap-gpmc: Add GPMC-NAND ops to get writebufferempty status
  mtd: nand: omap2: Switch to using GPMC-NAND ops for writebuffer empty
check
  memory: omap-gpmc: Remove NAND IRQ code
  memory: omap-gpmc: Add IRQ ops for GPMC-NAND interface
  mtd: nand: omap2: manage NAND interrupts
  mtd: nand: omap: Copy platform data parameters to omap_nand_info data
  mtd: nand: omap: Clean up device tree support
  mtd: nand: omap: Update DT binding documentation
  memory: omap-gpmc: Prevent mapping into 1st 16MB
  memory: omap-gpmc: Move device tree binding to correct location
  memory: omap-gpmc: Support general purpose input for WAITPINs
  memory: omap-gpmc: Reserve WAITPIN if needed for WAIT monitoring
  memory: omap-gpmc: Add irqchip support to the gpiochip
  mtd: nand: omap2: Implement NAND ready using gpiolib
  memory: omap-gpmc: Prevent GPMC_STATUS from being accessed via
gpmc_regs
  ARM: dts: dra7: Fix NAND device nodes.
  ARM: dts: dra7x-evm: Provide NAND ready pin
  ARM: dts: am437x: Fix NAND device nodes
  ARM: dts: am437x-gp-evm: Provide NAND ready pin
  ARM: dts: am335x: Fix NAND device nodes
  ARM: dts: am335x: Provide NAND ready pin
  ARM: dts: dm816x: Fix gpmc and NAND node
  ARM: dts: omap3: Fix gpmc and NAND nodes

 Documentation/devicetree/bindings/bus/ti-gpmc.txt  | 130 -
 .../bindings/memory-controllers/omap-gpmc.txt  | 130 +
 .../devicetree/bindings/mtd/gpmc-nand.txt  |  16 +-
 arch/arm/boot/dts/am335x-chilisom.dtsi |   7 +-
 arch/arm/boot/dts/am335x-evm.dts   |   7 +-
 arch/arm/boot/dts/am335x-igep0033.dtsi |   7 +-
 arch/arm/boot/dts/am33xx.dtsi  |   4 +
 arch/arm/boot/dts/am4372.dtsi  |   4 +
 arch/arm/boot/dts/am437x-gp-evm.dts|   8 +-
 arch/arm/boot/dts/am43x-epos-evm.dts   |   8 +-
 arch/arm/boot/dts/dm8168-evm.dts   |   7 +-
 arch/arm/boot/dts/dm816x.dtsi  |   4 +
 arch/arm/boot/dts/dra7-evm.dts |   6 +-
 arch/arm/boot/dts/dra7.dtsi|   4 +
 arch/arm/boot/dts/dra72-evm.dts|   6 +-
 arch/arm/boot/dts/logicpd-torpedo-som.dtsi |   7 +-
 arch/arm/boot/dts/omap3-beagle.dts |   2 +
 arch/arm/boot/dts/omap3-cm-t3x.dtsi|   5 +-
 arch/arm/boot/dts/omap3-devkit8000-common.dtsi |   3 +
 arch/arm/boot/dts/omap3-evm-37xx.dts   |   7 +-
 arch/arm/boot/dts/omap3-gta04.dtsi |   3 +
 arch/arm/boot/dts/omap3-igep.dtsi  |   5 +-
 arch/arm/boot/dts/omap3-igep0020-common.dtsi   |   4 +-
 arch/arm/boot/dts/omap3-igep0030-common.dtsi   |   4 +
 arch/arm/boot/dts/omap3-ldp.dts|   9 +-
 arch/arm/boot/dts/omap3-lilly-a83x.dtsi|   5 +-
 arch/arm/boot/dts/omap3-pandora-common.dtsi|   3 +
 arch/arm/boot/dts/omap3-tao3530.dtsi   |   5 +-
 arch/arm/boot/dts/omap3.dtsi   |   4 +
 arch/arm/boot/dts/omap3430-sdp.dts |   5 +-
 arch/arm/mach-omap2/gpmc-nand.c|  11 +-
 drivers/memory/omap-gpmc.c | 640 -
 drivers/mtd/nand/omap2.c   | 261 ++---
 include/linux/omap-gpmc.h  | 183 ++
 include/linux

Re: [PATCH v2 2/2] ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2

[Roger Quadros]

Tony,

On 03/09/15 10:36, Roger Quadros wrote:
> Chanwoo,
> 
> On 06/08/15 02:36, Chanwoo Choi wrote:
>> On 08/05/2015 07:37 PM, Tony Lindgren wrote:
>>> * Roger Quadros <rog...@ti.com> [150727 06:13]:
>>>> The VBUS line of USB2 is connected to VBUS detect logic on
>>>> the PMIC. Use the palmas-usb driver to report VBUS events
>>>> to the USB driver.
>>>>
>>>> As the palmas-usb driver supports GPIO based ID reporting
>>>> provide the GPIO for ID pin as well.
>>>>
>>>> Signed-off-by: Roger Quadros <rog...@ti.com>
>>>
>>> This should not cause merge conflicts with what I have queeud
>>> for v4.3, so Chanwoo please feel free to apply with the rest
>>> of the extcon series:
>>>
>>> Acked-by: Tony Lindgren <t...@atomide.com>
>>>
>>,
>> I reviewd this patchset related to extcon and give the acked-by message.
>> but patch1 must need the acked-by message from MFD maintainer.
>>
>> If patch1 receive the acked-by message from MFD maintainer,
>> I'll apply it for v4.3.
>>
>> Roger,
>> I think that you better to recevie the acked-by message before v4.2-rc6 
>> release.
>> I have the plan about pull request of extcon for v4.3 after v4.2-rc6 releas.
> 
> Seems like you picked patch 1 but not this one. As Tony has already Acked it
> can you please include patch 2 as well in your tree for -next? Thanks.
> 

Is it possible for you to pick this up for -rc cycle via omap-soc tree?
Thanks.

--
cheers,
-roger
--
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 5/9] usb: dwc3: core: make dual-role work with OTG irq

[Roger Quadros]

On 06/09/15 05:20, Peter Chen wrote:
> On Wed, Sep 02, 2015 at 09:43:38AM -0500, Felipe Balbi wrote:
>> Hi,
>>
>>> +
>>> +static irqreturn_t dwc3_otg_irq(int irq, void *_dwc)
>>> +{
>>> +   struct dwc3 *dwc = _dwc;
>>> +   irqreturn_t ret = IRQ_NONE;
>>> +   u32 reg;
>>> +
>>> +   spin_lock(>lock);
>>
>> this seems unnecessary, we're already in hardirq with IRQs disabled.
>> What sort of race could we have ? (in fact, this also needs change in
>> dwc3/gadget.c).
>>
> 
> Is it possible the kernel process is accessing the content you will 
> access?
> 
When kernel process accesses the data we'll never reach here
as we're protecting it with spinlock_irqsave(), spinunlock_irqrestore().

cheers,
-roger
--
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 07/13] usb: otg: add OTG core

[Roger Quadros]

On 10/09/15 08:35, Peter Chen wrote:
> On Wed, Sep 09, 2015 at 01:21:50PM +0300, Roger Quadros wrote:
>> On 09/09/15 11:45, Peter Chen wrote:
>>> On Wed, Sep 09, 2015 at 12:33:20PM +0300, Roger Quadros wrote:
>>>> On 09/09/15 11:13, Peter Chen wrote:
>>>>> On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
>>>>>> On 09/09/15 05:21, Peter Chen wrote:
>>>>>>> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 08/09/15 11:31, Peter Chen wrote:
>>>>>>>>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
>>>>>>>>>> On 07/09/15 04:23, Peter Chen wrote:
>>>>>>>>>>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>>>>>>>>>>>> + * This is used by the USB Host stack to register the Host 
>>>>>>>>>>>> controller
>>>>>>>>>>>> + * to the OTG core. Host controller must not be started by the
>>>>>>>>>>>> + * caller as it is left upto the OTG state machine to do so.
>>>>>>>>>>>> + *
>>>>>>>>>>>> + * Returns: 0 on success, error value otherwise.
>>>>>>>>>>>> + */
>>>>>>>>>>>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>>>>>>>>>>>> +   unsigned long irqflags, struct otg_hcd_ops 
>>>>>>>>>>>> *ops)
>>>>>>>>>>>> +{
>>>>>>>>>>>> +  struct usb_otg *otgd;
>>>>>>>>>>>> +  struct device *hcd_dev = hcd->self.controller;
>>>>>>>>>>>> +  struct device *otg_dev = usb_otg_get_device(hcd_dev);
>>>>>>>>>>>> +
>>>>>>>>>>>
>>>>>>>>>>> One big problem here is: there are two designs for current (IP) 
>>>>>>>>>>> driver
>>>>>>>>>>> code, one creates dedicated hcd device as roothub's parent, like 
>>>>>>>>>>> dwc3.
>>>>>>>>>>> Another one doesn't do this, roothub's parent is core device (or 
>>>>>>>>>>> otg device
>>>>>>>>>>> in your patch), like chipidea and dwc2.
>>>>>>>>>>>
>>>>>>>>>>> Then, otg_dev will be glue layer device for chipidea after that.
>>>>>>>>>>
>>>>>>>>>> OK. Let's add a way for the otg controller driver to provide the 
>>>>>>>>>> host and gadget
>>>>>>>>>> information to the otg core for such devices like chipidea and dwc2.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Roger, not only chipidea and dwc2, I think the musb uses the same
>>>>>>>>> hierarchy. If the host, device, and otg share the same register
>>>>>>>>> region, host part can't be a platform driver since we don't want
>>>>>>>>> to remap the same register region again.
>>>>>>>>>
>>>>>>>>> So, in the design, we may need to consider both situations, one
>>>>>>>>> is otg/host/device has its own register region, and host is a
>>>>>>>>> separate platform device (A), the other is three parts share the
>>>>>>>>> same register region, there is only one platform driver (B).
>>>>>>>>>
>>>>>>>>> A:
>>>>>>>>>
>>>>>>>>>   IP core device 
>>>>>>>>>   |
>>>>>>>>>   |
>>>>>>>>> |-|-|
>>>>>>>>> gadget   host platform device 
>>>>>>>>>   |
>>>>>>>>>   roothub
>>>>>>>>>
>>>>>>>>> B:
>>>>>>>>>
>>>>>>>>> 

Re: [PATCH v4 07/13] usb: otg: add OTG core

[Roger Quadros]

On 10/09/15 12:28, Li Jun wrote:
> On Wed, Sep 09, 2015 at 01:01:14PM +0300, Roger Quadros wrote:
> ... ...
> 
>>>>>> +return -EINVAL;
>>>>>
>>>>> Return non-zero, then if err, do we need call usb_otg_add_hcd() after
>>>>> usb_otg_register_hcd() fails?
>>>>
>>>> You should not call usb_otg_register_hcd() but usb_add_hcd().
>>>> If that fails then you fail as ususal.
>>>
>>> My point is if we use usb_add_hcd(), but failed in usb_otg_register_hcd(),
>>> then usb_otg_add_hcd() will be called in *all* error case, is this your
>>> expectation?
>>> if (usb_otg_register_hcd(hcd, irqnum, irqflags, _hcd_intf))
>>> return usb_otg_add_hcd(hcd, irqnum, irqflags);
>>>
>>
>> Yes, my intention was that if otg fails then it is a non otg HCD so register 
>> normally.
>> Let me correct my previous statement. If you are absolutely sure
>> that the HCD is for otg/dual-role usage then you should call 
>> usb_otg_register_hcd().
>>
> 
> I think this is not just about a statement, in your usb_otg_register_hcd()
> implementation, there are several places will return error, I think only
> the first two are for a non-otg HCD case, the following error cases seems
> mean this is for otg usage, but it fails in middle of registration, if that
> is the case, is it reasonable to call usb_otg_add_hcd()?

OK. We need to check the return value then and differentiate if it is non-otg
or otg with failure.
If it is non-otg then only we must call usb_otg_add_hcd().

I will fix usb_add_hcd().

> 
>>>>>> + * @fsm_running: state machine running/stopped indicator
>>>>>> + */
>>>>>>  struct usb_otg {
>>>>>>  u8  default_a;
>>>>>>  
>>>>>>  struct phy  *phy;
>>>>>>  /* old usb_phy interface */
>>>>>>  struct usb_phy  *usb_phy;
>>>>>> +
>>>>>
>>>>> add a blank line?
>>>>>
>>>
>>> You missed this.
>>
>> Sorry. Did you suggest to remove that blank line
>> or add a new one before usb_phy?
>>
> 
> Remove it.

OK.

> 
>>>
>>>>>>  struct usb_bus  *host;
>>>>>>  struct usb_gadget   *gadget;
>>>>>>  
>>>>>>  enum usb_otg_state  state;
>>>>>>  
>>>>>> +struct device *dev;
>>>>>> +struct usb_otg_caps *caps;
>>>>>> +struct otg_fsm fsm;
>>>>>> +struct otg_fsm_ops fsm_ops;
>>>>>> +
>>>>>> +/* internal use only */
>>>>>> +struct otg_hcd primary_hcd;
>>>>>> +struct otg_hcd shared_hcd;
>>>>>> +struct otg_gadget_ops *gadget_ops;
>>>>>> +struct otg_timer timers[NUM_OTG_FSM_TIMERS];
>>>>>> +struct list_head list;
>>>>>> +struct work_struct work;
>>>>>> -- 
>>>>>> 2.1.4
>>>
--
cheers,
-roger
--
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 07/13] usb: otg: add OTG core

[Roger Quadros]

On 09/09/15 05:21, Peter Chen wrote:
> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
>>
>>
>> On 08/09/15 11:31, Peter Chen wrote:
>>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
>>>> On 07/09/15 04:23, Peter Chen wrote:
>>>>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>>>>>> + * This is used by the USB Host stack to register the Host controller
>>>>>> + * to the OTG core. Host controller must not be started by the
>>>>>> + * caller as it is left upto the OTG state machine to do so.
>>>>>> + *
>>>>>> + * Returns: 0 on success, error value otherwise.
>>>>>> + */
>>>>>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>>>>>> + unsigned long irqflags, struct otg_hcd_ops 
>>>>>> *ops)
>>>>>> +{
>>>>>> +struct usb_otg *otgd;
>>>>>> +struct device *hcd_dev = hcd->self.controller;
>>>>>> +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>>>>>> +
>>>>>
>>>>> One big problem here is: there are two designs for current (IP) driver
>>>>> code, one creates dedicated hcd device as roothub's parent, like dwc3.
>>>>> Another one doesn't do this, roothub's parent is core device (or otg 
>>>>> device
>>>>> in your patch), like chipidea and dwc2.
>>>>>
>>>>> Then, otg_dev will be glue layer device for chipidea after that.
>>>>
>>>> OK. Let's add a way for the otg controller driver to provide the host and 
>>>> gadget
>>>> information to the otg core for such devices like chipidea and dwc2.
>>>>
>>>
>>> Roger, not only chipidea and dwc2, I think the musb uses the same
>>> hierarchy. If the host, device, and otg share the same register
>>> region, host part can't be a platform driver since we don't want
>>> to remap the same register region again.
>>>
>>> So, in the design, we may need to consider both situations, one
>>> is otg/host/device has its own register region, and host is a
>>> separate platform device (A), the other is three parts share the
>>> same register region, there is only one platform driver (B).
>>>
>>> A:
>>>
>>> IP core device 
>>> |
>>> |
>>>   |-|-|
>>>   gadget   host platform device 
>>> |
>>> roothub
>>>
>>> B:
>>>
>>> IP core device
>>> |
>>> |
>>>   |-|-|
>>>   gadget roothub
>>> 
>>>
>>>> This API must be called before the hcd/gadget-driver is added so that the 
>>>> otg
>>>> core knows it's linked to an OTG controller.
>>>>
>>>> Any better idea?
>>>>
>>>
>>> A flag stands for this hcd controller is the same with otg controller
>>> can be used, this flag can be stored at struct usb_otg_config.
>>
>> What if there is another architecture like so?
>>
>> C:
>>  [Parent]
>> |
>> |
>>  |--|--|
>>  [OTG core]  [gadget][host]
>>
>> We need a more flexible mechanism to link the gadget and
>> host device to the otg core for non DT case.
>>
>> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
>>
>> e.g.
>> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
>>
>> If otg is NULL it will try DT otg-controller property or parent to
>> get the otg controller.
> 
> How usb_otg_register_hcd get struct usb_otg, from where?

This only works when the parent driver creating the hcd has registered the
otg controller too.

> 
>>
>>>
>>> Peter
>>>
>>> P.S: I still read your code, I find not all APIs in this file are used
>>> in your dwc3 example. 
>>
>> Which ones? The ones for registering/unregistered host/gadget are used
>> by hcd/udc core as part of usb_add/remov

Re: [PATCH v4 07/13] usb: otg: add OTG core

[Roger Quadros]

On 09/09/15 11:13, Peter Chen wrote:
> On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
>> On 09/09/15 05:21, Peter Chen wrote:
>>> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
>>>>
>>>>
>>>> On 08/09/15 11:31, Peter Chen wrote:
>>>>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
>>>>>> On 07/09/15 04:23, Peter Chen wrote:
>>>>>>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>>>>>>>> + * This is used by the USB Host stack to register the Host controller
>>>>>>>> + * to the OTG core. Host controller must not be started by the
>>>>>>>> + * caller as it is left upto the OTG state machine to do so.
>>>>>>>> + *
>>>>>>>> + * Returns: 0 on success, error value otherwise.
>>>>>>>> + */
>>>>>>>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>>>>>>>> +   unsigned long irqflags, struct otg_hcd_ops 
>>>>>>>> *ops)
>>>>>>>> +{
>>>>>>>> +  struct usb_otg *otgd;
>>>>>>>> +  struct device *hcd_dev = hcd->self.controller;
>>>>>>>> +  struct device *otg_dev = usb_otg_get_device(hcd_dev);
>>>>>>>> +
>>>>>>>
>>>>>>> One big problem here is: there are two designs for current (IP) driver
>>>>>>> code, one creates dedicated hcd device as roothub's parent, like dwc3.
>>>>>>> Another one doesn't do this, roothub's parent is core device (or otg 
>>>>>>> device
>>>>>>> in your patch), like chipidea and dwc2.
>>>>>>>
>>>>>>> Then, otg_dev will be glue layer device for chipidea after that.
>>>>>>
>>>>>> OK. Let's add a way for the otg controller driver to provide the host 
>>>>>> and gadget
>>>>>> information to the otg core for such devices like chipidea and dwc2.
>>>>>>
>>>>>
>>>>> Roger, not only chipidea and dwc2, I think the musb uses the same
>>>>> hierarchy. If the host, device, and otg share the same register
>>>>> region, host part can't be a platform driver since we don't want
>>>>> to remap the same register region again.
>>>>>
>>>>> So, in the design, we may need to consider both situations, one
>>>>> is otg/host/device has its own register region, and host is a
>>>>> separate platform device (A), the other is three parts share the
>>>>> same register region, there is only one platform driver (B).
>>>>>
>>>>> A:
>>>>>
>>>>>   IP core device 
>>>>>   |
>>>>>   |
>>>>> |-|-|
>>>>> gadget   host platform device 
>>>>>   |
>>>>>   roothub
>>>>>
>>>>> B:
>>>>>
>>>>>   IP core device
>>>>>   |
>>>>>   |
>>>>> |-|-|
>>>>> gadget roothub
>>>>>   
>>>>>
>>>>>> This API must be called before the hcd/gadget-driver is added so that 
>>>>>> the otg
>>>>>> core knows it's linked to an OTG controller.
>>>>>>
>>>>>> Any better idea?
>>>>>>
>>>>>
>>>>> A flag stands for this hcd controller is the same with otg controller
>>>>> can be used, this flag can be stored at struct usb_otg_config.
>>>>
>>>> What if there is another architecture like so?
>>>>
>>>> C:
>>>>[Parent]
>>>>   |
>>>>   |
>>>>|--|--|
>>>>[OTG core]  [gadget][host]
>>>>
>>>> We need a more flexible mechanism to link the gadget and
>>>> host device to the otg core for non DT case.
>>>>
>>>> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
>>>>
>>>> e.g.
>>>> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
>>>>
>>>> If otg is NULL it will try DT otg-controller property or parent to
>>>> get the otg controller.
>>>
>>> How usb_otg_register_hcd get struct usb_otg, from where?
>>
>> This only works when the parent driver creating the hcd has registered the
>> otg controller too.
>>
> 
> Sorry? So we need to find another way to solve this issue, right?

For existing cases this is sufficient.
The otg device is either the one supplied during usb_otg_register_hcd
(cases B and C) or it is the parent device (case A).

It does not work when the 3 devices are totally independent and get registered
at different times.
I don't think there is such a case for non-DT yet, but let's not have this
limitation. So yes, we need to look for better solution :).

--
cheers,
-roger
--
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 07/13] usb: otg: add OTG core

[Roger Quadros]

(adding back folks in cc)

On 08/09/15 20:35, Alan Stern wrote:
> On Tue, 8 Sep 2015, Roger Quadros wrote:
> 
>>>> What if there is another architecture like so?
>>>>
>>>> C:
>>>>[Parent]
>>>>   |
>>>>   |
>>>>|--|--|
>>>>[OTG core]  [gadget][host]
>>>>
>>>> We need a more flexible mechanism to link the gadget and
>>>> host device to the otg core for non DT case.
>>>>
>>>> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
>>>>
>>>> e.g.
>>>> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
>>>>
>>>> If otg is NULL it will try DT otg-controller property or parent to
>>>> get the otg controller.
>>>
>>> This seems a lot like something Peter and I discussed recently.  See
>>>
>>> http://marc.info/?l=linux-usb=143977568021328=2
>>>
>>> and the following messages in that thread.
>>>
>>
>> If I understood right, your proposal was to add a usb_pointers data
>> struct to the device's drvdata?
> 
> Right.
> 
>> This is fine only if the otg/gadget/host share the same device.
>> It does not solve the problem where each have different platform devices.
> 
> Why not?  Each of the platform devices can store a pointer to the same 
> usb_pointers structure.  Wouldn't that be suitable?
> 

I didn't understand how all of them get the reference to the
same usb_pointer structure (or contents) when their respective platform devices
get created so that they can store it in their respective drvdata.

Worst case, the 3 devices could be totally independent of each other without a
common parent, and get registered at different times.

The common resource here is the physical USB port for which the 3 drivers
otg/host/gadget are being registered.
There should be a mechanism for each device to tell that it is part of
this particular USB port. (or usb_pointers struct)

cheers,
-roger
--
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 07/13] usb: otg: add OTG core

[Roger Quadros]

On 09/09/15 11:45, Peter Chen wrote:
> On Wed, Sep 09, 2015 at 12:33:20PM +0300, Roger Quadros wrote:
>> On 09/09/15 11:13, Peter Chen wrote:
>>> On Wed, Sep 09, 2015 at 12:08:10PM +0300, Roger Quadros wrote:
>>>> On 09/09/15 05:21, Peter Chen wrote:
>>>>> On Tue, Sep 08, 2015 at 03:25:25PM +0300, Roger Quadros wrote:
>>>>>>
>>>>>>
>>>>>> On 08/09/15 11:31, Peter Chen wrote:
>>>>>>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
>>>>>>>> On 07/09/15 04:23, Peter Chen wrote:
>>>>>>>>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>>>>>>>>>> + * This is used by the USB Host stack to register the Host 
>>>>>>>>>> controller
>>>>>>>>>> + * to the OTG core. Host controller must not be started by the
>>>>>>>>>> + * caller as it is left upto the OTG state machine to do so.
>>>>>>>>>> + *
>>>>>>>>>> + * Returns: 0 on success, error value otherwise.
>>>>>>>>>> + */
>>>>>>>>>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>>>>>>>>>> + unsigned long irqflags, struct otg_hcd_ops 
>>>>>>>>>> *ops)
>>>>>>>>>> +{
>>>>>>>>>> +struct usb_otg *otgd;
>>>>>>>>>> +struct device *hcd_dev = hcd->self.controller;
>>>>>>>>>> +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>>>>>>>>>> +
>>>>>>>>>
>>>>>>>>> One big problem here is: there are two designs for current (IP) driver
>>>>>>>>> code, one creates dedicated hcd device as roothub's parent, like dwc3.
>>>>>>>>> Another one doesn't do this, roothub's parent is core device (or otg 
>>>>>>>>> device
>>>>>>>>> in your patch), like chipidea and dwc2.
>>>>>>>>>
>>>>>>>>> Then, otg_dev will be glue layer device for chipidea after that.
>>>>>>>>
>>>>>>>> OK. Let's add a way for the otg controller driver to provide the host 
>>>>>>>> and gadget
>>>>>>>> information to the otg core for such devices like chipidea and dwc2.
>>>>>>>>
>>>>>>>
>>>>>>> Roger, not only chipidea and dwc2, I think the musb uses the same
>>>>>>> hierarchy. If the host, device, and otg share the same register
>>>>>>> region, host part can't be a platform driver since we don't want
>>>>>>> to remap the same register region again.
>>>>>>>
>>>>>>> So, in the design, we may need to consider both situations, one
>>>>>>> is otg/host/device has its own register region, and host is a
>>>>>>> separate platform device (A), the other is three parts share the
>>>>>>> same register region, there is only one platform driver (B).
>>>>>>>
>>>>>>> A:
>>>>>>>
>>>>>>> IP core device 
>>>>>>> |
>>>>>>> |
>>>>>>>   |-|-|
>>>>>>>   gadget   host platform device 
>>>>>>> |
>>>>>>> roothub
>>>>>>>
>>>>>>> B:
>>>>>>>
>>>>>>> IP core device
>>>>>>> |
>>>>>>> |
>>>>>>>   |-|-|
>>>>>>>   gadget roothub
>>>>>>> 
>>>>>>>
>>>>>>>> This API must be called before the hcd/gadget-driver is added so that 
>>>>>>>> the otg
>>>>>>>> core knows it's linked to an OTG controller.
>>>>>>>>
>>>>>>>> Any better idea?

Re: [PATCH v4 07/13] usb: otg: add OTG core

[Roger Quadros]

On 09/09/15 09:20, Li Jun wrote:
> On Mon, Sep 07, 2015 at 01:53:19PM +0300, Roger Quadros wrote:
>> On 07/09/15 10:40, Li Jun wrote:
>>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>>>> The OTG core instantiates the OTG Finite State Machine
>>>> per OTG controller and manages starting/stopping the
>>>> host and gadget controllers based on the bus state.
>>>>
>>>> It provides APIs for the following tasks
>>>>
>>>> - Registering an OTG capable controller
>>>> - Registering Host and Gadget controllers to OTG core
>>>> - Providing inputs to and kicking the OTG state machine
>>>>
>>>> Signed-off-by: Roger Quadros <rog...@ti.com>
>>>> ---
>>>>  MAINTAINERS  |4 +-
>>>>  drivers/usb/Kconfig  |2 +-
>>>>  drivers/usb/Makefile |1 +
>>>>  drivers/usb/common/Makefile  |3 +-
>>>>  drivers/usb/common/usb-otg.c | 1061 
>>>> ++
>>>>  drivers/usb/common/usb-otg.h |   71 +++
>>>>  drivers/usb/core/Kconfig |   11 +-
>>>>  include/linux/usb/otg.h  |  189 +++-
>>>>  8 files changed, 1321 insertions(+), 21 deletions(-)
>>>>  create mode 100644 drivers/usb/common/usb-otg.c
>>>>  create mode 100644 drivers/usb/common/usb-otg.h
>>>>
>>>
>>> ... ...
>>>
>>>> +
>>>> +/**
>>>> + * Get OTG device from host or gadget device.
>>>> + *
>>>> + * For non device tree boot, the OTG controller is assumed to be
>>>> + * the parent of the host/gadget device.
>>>
>>> This assumption/restriction maybe a problem, as I pointed in your previous
>>> version, usb_create_hcd() use the passed dev as its dev, but,
>>> usb_add_gadget_udc() use the passed dev as its parent dev, so often the
>>> host and gadget don't share the same parent device, at least it doesn't
>>> apply to chipidea case.
>>
>> Let's provide a way for OTG driver to provide the OTG core exactly which is
>> the related host/gadget device.
>>
>>>
>>>> + * For device tree boot, the OTG controller is derived from the
>>>> + * "otg-controller" property.
>>>> + */
>>>> +static struct device *usb_otg_get_device(struct device *hcd_gcd_dev)
>>>> +{
>>>> +  struct device *otg_dev;
>>>> +
>>>> +  if (!hcd_gcd_dev)
>>>> +  return NULL;
>>>> +
>>>> +  if (hcd_gcd_dev->of_node) {
>>>> +  struct device_node *np;
>>>> +  struct platform_device *pdev;
>>>> +
>>>> +  np = of_parse_phandle(hcd_gcd_dev->of_node, "otg-controller",
>>>> +0);
>>>> +  if (!np)
>>>> +  goto legacy;/* continue legacy way */
>>>> +
>>>> +  pdev = of_find_device_by_node(np);
>>>> +  of_node_put(np);
>>>> +  if (!pdev) {
>>>> +  dev_err(>dev, "couldn't get otg-controller 
>>>> device\n");
>>>> +  return NULL;
>>>> +  }
>>>> +
>>>> +  otg_dev = >dev;
>>>> +  return otg_dev;
>>>> +  }
>>>> +
>>>> +legacy:
>>>> +  /* otg device is parent and must be registered */
>>>> +  otg_dev = hcd_gcd_dev->parent;
>>>> +  if (!usb_otg_get_data(otg_dev))
>>>> +  return NULL;
>>>> +
>>>> +  return otg_dev;
>>>> +}
>>>> +
>>>
>>> ... ...
>>>
>>>> +static void usb_otg_init_timers(struct usb_otg *otgd, unsigned *timeouts)
>>>> +{
>>>> +  struct otg_fsm *fsm = >fsm;
>>>> +  unsigned long tmouts[NUM_OTG_FSM_TIMERS];
>>>> +  int i;
>>>> +
>>>> +  /* set default timeouts */
>>>> +  tmouts[A_WAIT_VRISE] = TA_WAIT_VRISE;
>>>> +  tmouts[A_WAIT_VFALL] = TA_WAIT_VFALL;
>>>> +  tmouts[A_WAIT_BCON] = TA_WAIT_BCON;
>>>> +  tmouts[A_AIDL_BDIS] = TA_AIDL_BDIS;
>>>> +  tmouts[A_BIDL_ADIS] = TA_BIDL_ADIS;
>>>> +  tmouts[B_ASE0_BRST] = TB_ASE0_BRST;
>>>> +  tmouts[B_SE0_SRP] = TB_SE0_SRP;
>>>> +  tmouts[B_SRP_FAIL] = TB_SRP_FAIL;
>>>> +

Re: [PATCH v4 10/13] usb: hcd: Adapt to OTG core

[Roger Quadros]

On 09/09/15 05:23, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:21PM +0300, Roger Quadros wrote:
>> The existing usb_add/remove_hcd() functionality
>> remains unchanged for non-OTG devices. For OTG
>> devices they only register the HCD with the OTG core.
>>
>> Introduce usb_otg_add/remove_hcd() for use by OTG core.
>> These functions actually add/remove the HCD.
>>
>> Signed-off-by: Roger Quadros <rog...@ti.com>
>> ---
>>  drivers/usb/core/hcd.c | 55 
>> +-
>>  1 file changed, 50 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
>> index c0fd1f6..4851682 100644
>> --- a/drivers/usb/core/hcd.c
>> +++ b/drivers/usb/core/hcd.c
>> @@ -46,6 +46,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  
>>  #include "usb.h"
>>  
>> @@ -2625,8 +2626,8 @@ static void usb_put_invalidate_rhdev(struct usb_hcd 
>> *hcd)
>>   * buffers of consistent memory, register the bus, request the IRQ line,
>>   * and call the driver's reset() and start() routines.
>>   */
>> -int usb_add_hcd(struct usb_hcd *hcd,
>> -unsigned int irqnum, unsigned long irqflags)
>> +static int usb_otg_add_hcd(struct usb_hcd *hcd,
>> +   unsigned int irqnum, unsigned long irqflags)
> 
> You may change the kernel doc to this name too.

Yes.

> 
>>  {
>>  int retval;
>>  struct usb_device *rhdev;
>> @@ -2839,17 +2840,16 @@ err_phy:
>>  }
>>  return retval;
>>  }
>> -EXPORT_SYMBOL_GPL(usb_add_hcd);
>>  
>>  /**
>> - * usb_remove_hcd - shutdown processing for generic HCDs
>> + * usb_otg_remove_hcd - shutdown processing for generic HCDs
>>   * @hcd: the usb_hcd structure to remove
>>   * Context: !in_interrupt()
>>   *
>>   * Disconnects the root hub, then reverses the effects of usb_add_hcd(),
>>   * invoking the HCD's stop() method.
>>   */
>> -void usb_remove_hcd(struct usb_hcd *hcd)
>> +static void usb_otg_remove_hcd(struct usb_hcd *hcd)
>>  {
>>  struct usb_device *rhdev = hcd->self.root_hub;
>>  
>> @@ -2923,6 +2923,51 @@ void usb_remove_hcd(struct usb_hcd *hcd)
>>  
>>  usb_put_invalidate_rhdev(hcd);
>>  }
>> +
>> +static struct otg_hcd_ops otg_hcd_intf = {
>> +.add = usb_otg_add_hcd,
>> +.remove = usb_otg_remove_hcd,
>> +};
>> +
>> +/**
>> + * usb_add_hcd - finish generic HCD structure initialization and register
>> + * @hcd: the usb_hcd structure to initialize
>> + * @irqnum: Interrupt line to allocate
>> + * @irqflags: Interrupt type flags
>> + *
>> + * Finish the remaining parts of generic HCD initialization: allocate the
>> + * buffers of consistent memory, register the bus, request the IRQ line,
>> + * and call the driver's reset() and start() routines.
>> + * If it is an OTG device then it only registers the HCD with OTG core.
>> + *
>> + */
>> +int usb_add_hcd(struct usb_hcd *hcd,
>> +unsigned int irqnum, unsigned long irqflags)
>> +{
>> +/* If OTG device, OTG core takes care of adding HCD */
>> +if (usb_otg_register_hcd(hcd, irqnum, irqflags, _hcd_intf))
>> +return usb_otg_add_hcd(hcd, irqnum, irqflags);
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL_GPL(usb_add_hcd);
>> +
>> +/**
>> + * usb_remove_hcd - shutdown processing for generic HCDs
>> + * @hcd: the usb_hcd structure to remove
>> + * Context: !in_interrupt()
>> + *
>> + * Disconnects the root hub, then reverses the effects of usb_add_hcd(),
>> + * invoking the HCD's stop() method.
>> + * If it is an OTG device then it unregisters the HCD from OTG core
>> + * as well.
>> + */
>> +void usb_remove_hcd(struct usb_hcd *hcd)
>> +{
>> +/* If OTG device, OTG core takes care of stopping HCD */
>> +if (usb_otg_unregister_hcd(hcd))
>> +usb_otg_remove_hcd(hcd);
>> +}
>>  EXPORT_SYMBOL_GPL(usb_remove_hcd);
>>  
>>  void
>> -- 
>> 2.1.4
>>
> 
--
cheers,
-roger
--
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 04/13] otg-fsm: move usb_bus_start_enum into otg-fsm->ops

[Roger Quadros]

On 08/09/15 09:54, Peter Chen wrote:
> On Mon, Sep 07, 2015 at 12:57:21PM +0300, Roger Quadros wrote:
>> On 07/09/15 04:24, Peter Chen wrote:
>>> On Mon, Aug 24, 2015 at 04:21:15PM +0300, Roger Quadros wrote:
>>>> This is to prevent missing symbol build error if OTG is
>>>> enabled (built-in) and HCD core (CONFIG_USB) is module.
>>>>
>>>> Signed-off-by: Roger Quadros <rog...@ti.com>
>>>> Acked-by: Peter Chen <peter.c...@freescale.com>
>>>> ---
>>>>  drivers/usb/common/usb-otg-fsm.c | 6 --
>>>>  drivers/usb/phy/phy-fsl-usb.c| 2 ++
>>>>  include/linux/usb/otg-fsm.h  | 1 +
>>>>  3 files changed, 7 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/drivers/usb/common/usb-otg-fsm.c 
>>>> b/drivers/usb/common/usb-otg-fsm.c
>>>> index a46f29a..6e56c8c 100644
>>>> --- a/drivers/usb/common/usb-otg-fsm.c
>>>> +++ b/drivers/usb/common/usb-otg-fsm.c
>>>> @@ -165,8 +165,10 @@ static int otg_set_state(struct otg_fsm *fsm, enum 
>>>> usb_otg_state new_state)
>>>>otg_loc_conn(fsm, 0);
>>>>otg_loc_sof(fsm, 1);
>>>>otg_set_protocol(fsm, PROTO_HOST);
>>>> -  usb_bus_start_enum(fsm->otg->host,
>>>> -  fsm->otg->host->otg_port);usb_bus_start_enum
>>>> +  if (fsm->ops->start_enum) {
>>>> +  fsm->ops->start_enum(fsm->otg->host,
>>>> +   fsm->otg->host->otg_port);
>>>> +  }
>>>>break;
>>>>case OTG_STATE_A_IDLE:
>>>>otg_drv_vbus(fsm, 0);
>>>> diff --git a/drivers/usb/phy/phy-fsl-usb.c b/drivers/usb/phy/phy-fsl-usb.c
>>>> index ee3f2c2..19541ed 100644
>>>> --- a/drivers/usb/phy/phy-fsl-usb.c
>>>> +++ b/drivers/usb/phy/phy-fsl-usb.c
>>>> @@ -783,6 +783,8 @@ static struct otg_fsm_ops fsl_otg_ops = {
>>>>  
>>>>.start_host = fsl_otg_start_host,
>>>>.start_gadget = fsl_otg_start_gadget,
>>>> +
>>>> +  .start_enum = usb_bus_start_enum,
>>>>  };
>>>>  
>>>>  /* Initialize the global variable fsl_otg_dev and request IRQ for OTG */
>>>> diff --git a/include/linux/usb/otg-fsm.h b/include/linux/usb/otg-fsm.h
>>>> index 672551c..75e82cc 100644
>>>> --- a/include/linux/usb/otg-fsm.h
>>>> +++ b/include/linux/usb/otg-fsm.h
>>>> @@ -199,6 +199,7 @@ struct otg_fsm_ops {
>>>>void(*del_timer)(struct otg_fsm *fsm, enum otg_fsm_timer timer);
>>>>int (*start_host)(struct otg_fsm *fsm, int on);
>>>>int (*start_gadget)(struct otg_fsm *fsm, int on);
>>>> +  int (*start_enum)(struct usb_bus *bus, unsigned port_num);
>>>>  };
>>>>  
>>>>  
>>>
>>> Get one build warning:
>>>
>>> In file included from 
>>> /u/home/b29397/work/projects/usb/drivers/usb/chipidea/udc.c:23:0:
>>> /u/home/b29397/work/projects/usb/include/linux/usb/otg-fsm.h:207:27: 
>>> warning: 'struct usb_bus' declared inside parameter list
>>>   int (*start_enum)(struct usb_bus *bus, unsigned port_num);
>>>  ^
>>> /u/home/b29397/work/projects/usb/include/linux/usb/otg-fsm.h:207:27: 
>>> warning: its scope is only this definition or declaration, which is 
>>> probably not what you want
>>>
>>> It probably dues to we should not have struct usb_bus* at udc driver
>>>
>> How about changing it to struct otg_fsm instead like the other APIs?
>> And do we leave usb_bus_start_enum() as it is?
>>
> 
> You have defined struct otg_hcd_ops to let otg visit hcd stuff, how
> about move this to otg_hcd_ops?

Yes, this is a better idea. Thanks.

cheers,
-roger
--
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 07/13] usb: otg: add OTG core

[Roger Quadros]

On 08/09/15 11:31, Peter Chen wrote:
> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
>> On 07/09/15 04:23, Peter Chen wrote:
>>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>>>> + * This is used by the USB Host stack to register the Host controller
>>>> + * to the OTG core. Host controller must not be started by the
>>>> + * caller as it is left upto the OTG state machine to do so.
>>>> + *
>>>> + * Returns: 0 on success, error value otherwise.
>>>> + */
>>>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>>>> +   unsigned long irqflags, struct otg_hcd_ops *ops)
>>>> +{
>>>> +  struct usb_otg *otgd;
>>>> +  struct device *hcd_dev = hcd->self.controller;
>>>> +  struct device *otg_dev = usb_otg_get_device(hcd_dev);
>>>> +
>>>
>>> One big problem here is: there are two designs for current (IP) driver
>>> code, one creates dedicated hcd device as roothub's parent, like dwc3.
>>> Another one doesn't do this, roothub's parent is core device (or otg device
>>> in your patch), like chipidea and dwc2.
>>>
>>> Then, otg_dev will be glue layer device for chipidea after that.
>>
>> OK. Let's add a way for the otg controller driver to provide the host and 
>> gadget
>> information to the otg core for such devices like chipidea and dwc2.
>>
> 
> Roger, not only chipidea and dwc2, I think the musb uses the same
> hierarchy. If the host, device, and otg share the same register
> region, host part can't be a platform driver since we don't want
> to remap the same register region again.
> 
> So, in the design, we may need to consider both situations, one
> is otg/host/device has its own register region, and host is a
> separate platform device (A), the other is three parts share the
> same register region, there is only one platform driver (B).
> 
> A:
> 
>   IP core device 
>   |
>   |
> |-|-|
> gadget   host platform device 
>   |
>   roothub
> 
> B:
> 
>   IP core device
>   |
>   |
> |-|-|
> gadget roothub
>   
> 
>> This API must be called before the hcd/gadget-driver is added so that the otg
>> core knows it's linked to an OTG controller.
>>
>> Any better idea?
>>
> 
> A flag stands for this hcd controller is the same with otg controller
> can be used, this flag can be stored at struct usb_otg_config.

What if there is another architecture like so?

C:
[Parent]
   |
   |
|--|--|
[OTG core]  [gadget][host]

We need a more flexible mechanism to link the gadget and
host device to the otg core for non DT case.

How about adding struct usb_otg parameter to usb_otg_register_hcd()?

e.g.
int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)

If otg is NULL it will try DT otg-controller property or parent to
get the otg controller.

> 
> Peter
> 
> P.S: I still read your code, I find not all APIs in this file are used
> in your dwc3 example. 

Which ones? The ones for registering/unregistered host/gadget are used
by hcd/udc core as part of usb_add/remove_hcd() and
udc_bind_to_driver()/usb_gadget_remove_driver()

cheers,
-roger
--
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 07/13] usb: otg: add OTG core

[Roger Quadros]

Alan,

On 08/09/15 17:34, Alan Stern wrote:
> On Tue, 8 Sep 2015, Roger Quadros wrote:
> 
>> On 08/09/15 11:31, Peter Chen wrote:
>>> On Mon, Sep 07, 2015 at 01:23:01PM +0300, Roger Quadros wrote:
>>>> On 07/09/15 04:23, Peter Chen wrote:
>>>>> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>>>>>> + * This is used by the USB Host stack to register the Host controller
>>>>>> + * to the OTG core. Host controller must not be started by the
>>>>>> + * caller as it is left upto the OTG state machine to do so.
>>>>>> + *
>>>>>> + * Returns: 0 on success, error value otherwise.
>>>>>> + */
>>>>>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>>>>>> + unsigned long irqflags, struct otg_hcd_ops 
>>>>>> *ops)
>>>>>> +{
>>>>>> +struct usb_otg *otgd;
>>>>>> +struct device *hcd_dev = hcd->self.controller;
>>>>>> +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>>>>>> +
>>>>>
>>>>> One big problem here is: there are two designs for current (IP) driver
>>>>> code, one creates dedicated hcd device as roothub's parent, like dwc3.
>>>>> Another one doesn't do this, roothub's parent is core device (or otg 
>>>>> device
>>>>> in your patch), like chipidea and dwc2.
>>>>>
>>>>> Then, otg_dev will be glue layer device for chipidea after that.
>>>>
>>>> OK. Let's add a way for the otg controller driver to provide the host and 
>>>> gadget
>>>> information to the otg core for such devices like chipidea and dwc2.
>>>>
>>>
>>> Roger, not only chipidea and dwc2, I think the musb uses the same
>>> hierarchy. If the host, device, and otg share the same register
>>> region, host part can't be a platform driver since we don't want
>>> to remap the same register region again.
>>>
>>> So, in the design, we may need to consider both situations, one
>>> is otg/host/device has its own register region, and host is a
>>> separate platform device (A), the other is three parts share the
>>> same register region, there is only one platform driver (B).
>>>
>>> A:
>>>
>>> IP core device 
>>> |
>>> |
>>>   |-|-|
>>>   gadget   host platform device 
>>> |
>>> roothub
>>>
>>> B:
>>>
>>> IP core device
>>> |
>>> |
>>>   |-|-|
>>>   gadget roothub
>>> 
>>>
>>>> This API must be called before the hcd/gadget-driver is added so that the 
>>>> otg
>>>> core knows it's linked to an OTG controller.
>>>>
>>>> Any better idea?
>>>>
>>>
>>> A flag stands for this hcd controller is the same with otg controller
>>> can be used, this flag can be stored at struct usb_otg_config.
>>
>> What if there is another architecture like so?
>>
>> C:
>>  [Parent]
>> |
>> |
>>  |--|--|
>>  [OTG core]  [gadget][host]
>>
>> We need a more flexible mechanism to link the gadget and
>> host device to the otg core for non DT case.
>>
>> How about adding struct usb_otg parameter to usb_otg_register_hcd()?
>>
>> e.g.
>> int usb_otg_register_hcd(struct usb_otg *otg, struct usb_hcd *hcd, ..)
>>
>> If otg is NULL it will try DT otg-controller property or parent to
>> get the otg controller.
> 
> This seems a lot like something Peter and I discussed recently.  See
> 
>   http://marc.info/?l=linux-usb=143977568021328=2
> 
> and the following messages in that thread.
> 

If I understood right, your proposal was to add a usb_pointers data
struct to the device's drvdata?

This is fine only if the otg/gadget/host share the same device.
It does not solve the problem where each have different platform devices.

cheers,
-roger

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/9] usb: dwc3: add dual-role support

[Roger Quadros]

Peter,

On 06/09/15 05:02, Peter Chen wrote:
> On Wed, Sep 02, 2015 at 05:24:16PM +0300, Roger Quadros wrote:
>> Register with the USB OTG core. Since we don't support
>> OTG yet we just work as a dual-role device even
>> if device tree says "otg".
>>
>> +
>> +static int dwc3_drd_init(struct dwc3 *dwc)
>> +{
>> +int ret, id, vbus;
>> +struct usb_otg_caps *otgcaps = >otg_config.otg_caps;
>> +
>> +otgcaps->otg_rev = 0;
>> +otgcaps->hnp_support = false;
>> +otgcaps->srp_support = false;
>> +otgcaps->adp_support = false;
>> +dwc->otg_config.fsm_ops = _drd_ops;
>> +
>> +if (!dwc->edev) {
>> +dev_err(dwc->dev, "No extcon device found for OTG mode\n");
>> +return -ENODEV;
>> +}
>> +
> 
> Do All dwc3 platforms id/vbus need to get through extcon? Do the
> SoCs have id/vbus pin?
> 
> 

Extcon access is in fact not needed from dwc3 driver and I will be getting
rid of this patch. We will support dual-role only via the OTG irq as in patch 5.

The way it works is that the OMAP glue layer dwc3-omap.c requests extcon device
and sets some mailbox register and this causes the VBUS/ID events to come over
OTG irq/status. So this patch is redundant.

The extcon device is not needed for all TI platforms. e.g. we need it for
DRA7 but not for AM437x.

cheers,
-roger
--
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 07/13] usb: otg: add OTG core

[Roger Quadros]

On 07/09/15 04:23, Peter Chen wrote:
> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>> + * This is used by the USB Host stack to register the Host controller
>> + * to the OTG core. Host controller must not be started by the
>> + * caller as it is left upto the OTG state machine to do so.
>> + *
>> + * Returns: 0 on success, error value otherwise.
>> + */
>> +int usb_otg_register_hcd(struct usb_hcd *hcd, unsigned int irqnum,
>> + unsigned long irqflags, struct otg_hcd_ops *ops)
>> +{
>> +struct usb_otg *otgd;
>> +struct device *hcd_dev = hcd->self.controller;
>> +struct device *otg_dev = usb_otg_get_device(hcd_dev);
>> +
> 
> One big problem here is: there are two designs for current (IP) driver
> code, one creates dedicated hcd device as roothub's parent, like dwc3.
> Another one doesn't do this, roothub's parent is core device (or otg device
> in your patch), like chipidea and dwc2.
> 
> Then, otg_dev will be glue layer device for chipidea after that.

OK. Let's add a way for the otg controller driver to provide the host and gadget
information to the otg core for such devices like chipidea and dwc2.

This API must be called before the hcd/gadget-driver is added so that the otg
core knows it's linked to an OTG controller.

Any better idea?

cheers,
-roger

> 
> Peter
> 
>> +if (!otg_dev)
>> +return -EINVAL; /* we're definitely not OTG */
>> +
>> +/* we're otg but otg controller might not yet be registered */
>> +mutex_lock(_list_mutex);
>> +otgd = usb_otg_get_data(otg_dev);
>> +mutex_unlock(_list_mutex);
>> +if (!otgd) {
>> +dev_dbg(hcd_dev,
>> +"otg: controller not yet registered. waiting..\n");
>> +/*
>> + * otg controller might register later. Put the hcd in
>> + * wait list and call us back when ready
>> + */
>> +if (usb_otg_hcd_wait_add(otg_dev, hcd, irqnum, irqflags, ops)) {
>> +dev_dbg(hcd_dev, "otg: failed to add to wait list\n");
>> +return -EINVAL;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +/* HCD will be started by OTG fsm when needed */
>> +mutex_lock(>fsm.lock);
>> +if (otgd->primary_hcd.hcd) {
>> +/* probably a shared HCD ? */
>> +if (usb_otg_hcd_is_primary_hcd(hcd)) {
>> +dev_err(otg_dev, "otg: primary host already 
>> registered\n");
>> +goto err;
>> +}
>> +
>> +if (hcd->shared_hcd == otgd->primary_hcd.hcd) {
>> +if (otgd->shared_hcd.hcd) {
>> +dev_err(otg_dev, "otg: shared host already 
>> registered\n");
>> +goto err;
>> +}
>> +
>> +otgd->shared_hcd.hcd = hcd;
>> +otgd->shared_hcd.irqnum = irqnum;
>> +otgd->shared_hcd.irqflags = irqflags;
>> +otgd->shared_hcd.ops = ops;
>> +dev_info(otg_dev, "otg: shared host %s registered\n",
>> + dev_name(hcd->self.controller));
>> +} else {
>> +dev_err(otg_dev, "otg: invalid shared host %s\n",
>> +dev_name(hcd->self.controller));
>> +goto err;
>> +}
>> +} else {
>> +if (!usb_otg_hcd_is_primary_hcd(hcd)) {
>> +dev_err(otg_dev, "otg: primary host must be registered 
>> first\n");
>> +goto err;
>> +}
>> +
>> +otgd->primary_hcd.hcd = hcd;
>> +otgd->primary_hcd.irqnum = irqnum;
>> +otgd->primary_hcd.irqflags = irqflags;
>> +otgd->primary_hcd.ops = ops;
>> +dev_info(otg_dev, "otg: primary host %s registered\n",
>> + dev_name(hcd->self.controller));
>> +}
>> +
>> +/*
>> + * we're ready only if we have shared HCD
>> + * or we don't need shared HCD.
>> + */
>> +if (otgd->shared_hcd.hcd || !otgd->primary_hcd.hcd->shared_hcd) {
>> +otgd->fsm.otg->host = hcd_to_bus(hcd);
>> +/* FIXME: set bus->otg_port if this is true OTG port 

Re: [PATCH v4 07/13] usb: otg: add OTG core

[Roger Quadros]

On 07/09/15 10:40, Li Jun wrote:
> On Mon, Aug 24, 2015 at 04:21:18PM +0300, Roger Quadros wrote:
>> The OTG core instantiates the OTG Finite State Machine
>> per OTG controller and manages starting/stopping the
>> host and gadget controllers based on the bus state.
>>
>> It provides APIs for the following tasks
>>
>> - Registering an OTG capable controller
>> - Registering Host and Gadget controllers to OTG core
>> - Providing inputs to and kicking the OTG state machine
>>
>> Signed-off-by: Roger Quadros <rog...@ti.com>
>> ---
>>  MAINTAINERS  |4 +-
>>  drivers/usb/Kconfig  |2 +-
>>  drivers/usb/Makefile |1 +
>>  drivers/usb/common/Makefile  |3 +-
>>  drivers/usb/common/usb-otg.c | 1061 
>> ++
>>  drivers/usb/common/usb-otg.h |   71 +++
>>  drivers/usb/core/Kconfig |   11 +-
>>  include/linux/usb/otg.h  |  189 +++-
>>  8 files changed, 1321 insertions(+), 21 deletions(-)
>>  create mode 100644 drivers/usb/common/usb-otg.c
>>  create mode 100644 drivers/usb/common/usb-otg.h
>>
> 
> ... ...
> 
>> +
>> +/**
>> + * Get OTG device from host or gadget device.
>> + *
>> + * For non device tree boot, the OTG controller is assumed to be
>> + * the parent of the host/gadget device.
> 
> This assumption/restriction maybe a problem, as I pointed in your previous
> version, usb_create_hcd() use the passed dev as its dev, but,
> usb_add_gadget_udc() use the passed dev as its parent dev, so often the
> host and gadget don't share the same parent device, at least it doesn't
> apply to chipidea case.

Let's provide a way for OTG driver to provide the OTG core exactly which is
the related host/gadget device.

> 
>> + * For device tree boot, the OTG controller is derived from the
>> + * "otg-controller" property.
>> + */
>> +static struct device *usb_otg_get_device(struct device *hcd_gcd_dev)
>> +{
>> +struct device *otg_dev;
>> +
>> +if (!hcd_gcd_dev)
>> +return NULL;
>> +
>> +if (hcd_gcd_dev->of_node) {
>> +struct device_node *np;
>> +struct platform_device *pdev;
>> +
>> +np = of_parse_phandle(hcd_gcd_dev->of_node, "otg-controller",
>> +  0);
>> +if (!np)
>> +goto legacy;/* continue legacy way */
>> +
>> +pdev = of_find_device_by_node(np);
>> +of_node_put(np);
>> +if (!pdev) {
>> +dev_err(>dev, "couldn't get otg-controller 
>> device\n");
>> +return NULL;
>> +}
>> +
>> +otg_dev = >dev;
>> +return otg_dev;
>> +}
>> +
>> +legacy:
>> +/* otg device is parent and must be registered */
>> +otg_dev = hcd_gcd_dev->parent;
>> +if (!usb_otg_get_data(otg_dev))
>> +return NULL;
>> +
>> +return otg_dev;
>> +}
>> +
> 
> ... ...
> 
>> +static void usb_otg_init_timers(struct usb_otg *otgd, unsigned *timeouts)
>> +{
>> +struct otg_fsm *fsm = >fsm;
>> +unsigned long tmouts[NUM_OTG_FSM_TIMERS];
>> +int i;
>> +
>> +/* set default timeouts */
>> +tmouts[A_WAIT_VRISE] = TA_WAIT_VRISE;
>> +tmouts[A_WAIT_VFALL] = TA_WAIT_VFALL;
>> +tmouts[A_WAIT_BCON] = TA_WAIT_BCON;
>> +tmouts[A_AIDL_BDIS] = TA_AIDL_BDIS;
>> +tmouts[A_BIDL_ADIS] = TA_BIDL_ADIS;
>> +tmouts[B_ASE0_BRST] = TB_ASE0_BRST;
>> +tmouts[B_SE0_SRP] = TB_SE0_SRP;
>> +tmouts[B_SRP_FAIL] = TB_SRP_FAIL;
>> +
>> +/* set controller provided timeouts */
>> +if (timeouts) {
>> +for (i = 0; i < NUM_OTG_FSM_TIMERS; i++) {
>> +if (timeouts[i])
>> +tmouts[i] = timeouts[i];
>> +}
>> +}
>> +
>> +otg_timer_init(A_WAIT_VRISE, otgd, set_tmout, TA_WAIT_VRISE,
>> +   >a_wait_vrise_tmout);
>> +otg_timer_init(A_WAIT_VFALL, otgd, set_tmout, TA_WAIT_VFALL,
>> +   >a_wait_vfall_tmout);
>> +otg_timer_init(A_WAIT_BCON, otgd, set_tmout, TA_WAIT_BCON,
>> +   >a_wait_bcon_tmout);
>> +otg_timer_init(A_AIDL_BDIS, otgd, set_tmout, TA_AIDL_BDIS,
>> +   >a_aidl_bdis_tmout);
>> +otg_timer_init(A_BIDL_ADIS, otgd

Re: [PATCH v4 1/9] usb: dwc3: add dual-role support

[Roger Quadros]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/09/15 12:06, Roger Quadros wrote:
> Felipe,
> 
> On 03/09/15 18:44, Felipe Balbi wrote:
>> Hi,
> 
>> On Thu, Sep 03, 2015 at 03:21:48PM +0300, Roger Quadros wrote:
>>>>> + dwc->fsm->id = id;
>>>>> + dwc->fsm->b_sess_vld = vbus;
>>>>> + usb_otg_sync_inputs(dwc->fsm);
>>>>> +}
>>>>> +
>>>>> +static int dwc3_drd_start_host(struct otg_fsm *fsm, int on)
>>>>> +{
>>>>> + struct device *dev = usb_otg_fsm_to_dev(fsm);
>>>>> + struct dwc3 *dwc = dev_get_drvdata(dev);
>>>>
>>>> how about adding a usb_otg_get_drvdata(fsm) ?
>>>
>>> You meant for otg core? That can be done.
> 
>> yeah. BTW, I think otg core needs quite a few changes to become actually
>> useful. Currently it's just too much pointer ping-pong going back and
>> forth between phy, otg core, udc and hcd.
> 
> Sure, any inputs for improvement appreciated.
> 
> 
>> Also, I caught a ton of issues with it and suspend/resume. You might
>> want to fix them before adding more users to it.
> 
> OK.
> 
> 
>> It's also rather racy and that needs fixing too. On top of all that, I
>> think there's too much being added to UDC just to get Dual-Role, let's
>> see if we can improve that too.
> 
> Would appreciate if you could give all your inputs on the otg core thread
> as early as you can :)
> 
> 
>>>>> @@ -843,6 +998,16 @@ static int dwc3_probe(struct platform_device *pdev)
>>>>>   hird_threshold = 12;
>>>>>  
>>>>>   if (node) {
>>>>> + if (of_property_read_bool(node, "extcon"))
>>>>> + dwc->edev = extcon_get_edev_by_phandle(dev, 0);
>>>>> + else if (of_property_read_bool(dev->parent->of_node, "extcon"))
>>>>> + dwc->edev = extcon_get_edev_by_phandle(dev->parent, 0);
>>>>
>>>> why do you need to check the parent ? Why isn't that done on the glue
>>>> layer ?
>>>
>>> On DRA7-evm, the extcon device is defined in the glue layer node. But
>>> we need the device both at the glue layer and at the core layer.
> 
>> why do you need extcon here ? Glue updates core via UTMI about the
>> states, right ? So you should get proper VBUS and ID status via OTG IRQ.
>> Is that not working ?
> 
> I didn't even expect that would work. Let me give that a try.
> 
> 
>>> We do get the extcon device in dwc3-omap.c
>>>
>>> Any suggestion how to pass the extcon device from glue layer to core.c?
>>> Or should I add the extcon property to dwc3 USB node as well in the DT?
> 
>> GPIO toggles
>>   dwc3-omap extcon event
>> update status via UTMI STATUS register
>>   OTG IRQ on core
>> Horray!
> 
>> :-)
> 
> That's great. Thanks :)

This approach worked. Had to do the following change to the dwc3-omap glue
to make it work.

From: Roger Quadros <rog...@ti.com>
Date: Fri, 4 Sep 2015 15:13:59 +0300
Subject: [PATCH] usb: dwc3: omap: Pass VBUS and ID events transparently

Don't make any decisions regarding VBUS session based on ID
status. That is best left to the OTG core.

Pass ID and VBUS events independent of each other so that OTG
core knows exactly what to do.

This makes dual-role with extcon work with OTG irq on OMAP platforms.

Signed-off-by: Roger Quadros <rog...@ti.com>
- ---
 drivers/usb/dwc3/dwc3-omap.c | 15 ++-
 1 file changed, 6 insertions(+), 9 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index b18f2a3..751feee 100644
- --- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -233,19 +233,14 @@ static void dwc3_omap_set_mailbox(struct dwc3_omap *omap,
}
 
val = dwc3_omap_read_utmi_ctrl(omap);
- - val &= ~(USBOTGSS_UTMI_OTG_CTRL_IDDIG
- - | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID
- - | USBOTGSS_UTMI_OTG_CTRL_SESSEND);
- - val |= USBOTGSS_UTMI_OTG_CTRL_SESSVALID
- - | USBOTGSS_UTMI_OTG_CTRL_POWERPRESENT;
+   val &= ~USBOTGSS_UTMI_OTG_CTRL_IDDIG;
dwc3_omap_write_utmi_ctrl(omap, val);
break;
 
case OMAP_DWC3_VBUS_VALID:
val = dwc3_omap_read_utmi_ctrl(omap);
val &= ~USBOTGSS_UTMI_OTG_CTRL_SESSEND;
- - val |= USBOTGSS_UTMI_OTG_CTRL_IDDIG
- - | USBOTGSS_UTMI_OTG_CTRL_VBUSVALID
+