From: Kishon Vijay Abraham I <kishon@ti.com>
To: Felipe Balbi <balbi@kernel.org>, Tony Lindgren <tony@atomide.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: linux-kernel@vger.kernel.org, linux-omap@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mmc@vger.kernel.org,
afenkart@gmail.com, ulf.hansson@linaro.org,
linux@armlinux.org.uk, rogerq@ti.com, bcousson@baylibre.com,
galak@codeaurora.org, ijc+devicetree@hellion.org.uk,
mark.rutland@arm.com, pawel.moll@arm.com, robh+dt@kernel.org,
nsekhar@ti.com
Subject: Re: [RFC PATCH 2/3] mmc: host: omap_hsmmc: Enable ADMA2
Date: Mon, 23 May 2016 11:52:01 +0530 [thread overview]
Message-ID: <5742A189.4060803@ti.com> (raw)
In-Reply-To: <87shxdlws6.fsf@linux.intel.com>
Hi Felipe,
On Friday 20 May 2016 12:06 AM, Felipe Balbi wrote:
>
> Hi,
>
> Tony Lindgren <tony@atomide.com> writes:
>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [160519 01:10]:
>>> On 05/18/2016 10:30 PM, Tony Lindgren wrote:
>>>> Ideally the adma support would be a separate loadable module,
>>>> similar how the cppi41dma is a child of the OTG controller.
>>>
>>> The Master DMA is part of the hsmmc IP block. If the same ADMA module is
>>> present on other IPs it might be beneficial to have a helper library to handle
>>> it (allocating the descriptor pool, wrinting, updating descriptors, etc).
>>
>> OK. Yeah if it's part of the MMC controller it makes no sense to
>> separate it. So then the conecrns are using alternate DMA
>> implementations and keeping PM runtime working :)
>>
>> BTW, Felipe mentioned that the best thing to do in the long run would
>> be to set up sdhci-omap.c operating in ADMA mode.
>>
>> Felipe, care to summarize what you had in mind?
>
> yeah, just write a new sdhci-omap.c to start moving away from
> omap-hsmmc.c, just like it was done for 8250-omap.
>
> At the beginning, it could be just the bare minimum to get it working
> and slowly move over stuff like pm runtime, dmaengine, PIO. Move more
> platforms over to that driver and, eventually, get rid of omap-hsmmc.c
> altogether.
>
> That way, development can be focussed on generic layers (SDHCI) to which
> OMAP MMC controller is compliant (apart from the VERSION register
> quirk).
About an year back, when I tried using SDHCI for OMAP I ran into issues and was
not able to get it working. IIRC SDHCI_PRESENT_STATE (or OMAP_HSMMC_PSTATE) was
not showing the correct state for card present and is unable to raise an
interrupt when a card is inserted. I didn't debug this further.
It also kept me wondering why gpio interrupt was always used for card detect
instead of using mmci_sdcd line of the controller.
Thanks
Kishon
WARNING: multiple messages have this Message-ID (diff)
From: kishon@ti.com (Kishon Vijay Abraham I)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 2/3] mmc: host: omap_hsmmc: Enable ADMA2
Date: Mon, 23 May 2016 11:52:01 +0530 [thread overview]
Message-ID: <5742A189.4060803@ti.com> (raw)
In-Reply-To: <87shxdlws6.fsf@linux.intel.com>
Hi Felipe,
On Friday 20 May 2016 12:06 AM, Felipe Balbi wrote:
>
> Hi,
>
> Tony Lindgren <tony@atomide.com> writes:
>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [160519 01:10]:
>>> On 05/18/2016 10:30 PM, Tony Lindgren wrote:
>>>> Ideally the adma support would be a separate loadable module,
>>>> similar how the cppi41dma is a child of the OTG controller.
>>>
>>> The Master DMA is part of the hsmmc IP block. If the same ADMA module is
>>> present on other IPs it might be beneficial to have a helper library to handle
>>> it (allocating the descriptor pool, wrinting, updating descriptors, etc).
>>
>> OK. Yeah if it's part of the MMC controller it makes no sense to
>> separate it. So then the conecrns are using alternate DMA
>> implementations and keeping PM runtime working :)
>>
>> BTW, Felipe mentioned that the best thing to do in the long run would
>> be to set up sdhci-omap.c operating in ADMA mode.
>>
>> Felipe, care to summarize what you had in mind?
>
> yeah, just write a new sdhci-omap.c to start moving away from
> omap-hsmmc.c, just like it was done for 8250-omap.
>
> At the beginning, it could be just the bare minimum to get it working
> and slowly move over stuff like pm runtime, dmaengine, PIO. Move more
> platforms over to that driver and, eventually, get rid of omap-hsmmc.c
> altogether.
>
> That way, development can be focussed on generic layers (SDHCI) to which
> OMAP MMC controller is compliant (apart from the VERSION register
> quirk).
About an year back, when I tried using SDHCI for OMAP I ran into issues and was
not able to get it working. IIRC SDHCI_PRESENT_STATE (or OMAP_HSMMC_PSTATE) was
not showing the correct state for card present and is unable to raise an
interrupt when a card is inserted. I didn't debug this further.
It also kept me wondering why gpio interrupt was always used for card detect
instead of using mmci_sdcd line of the controller.
Thanks
Kishon
WARNING: multiple messages have this Message-ID (diff)
From: Kishon Vijay Abraham I <kishon@ti.com>
To: Felipe Balbi <balbi@kernel.org>, Tony Lindgren <tony@atomide.com>,
Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: <linux-kernel@vger.kernel.org>, <linux-omap@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-mmc@vger.kernel.org>, <afenkart@gmail.com>,
<ulf.hansson@linaro.org>, <linux@armlinux.org.uk>,
<rogerq@ti.com>, <bcousson@baylibre.com>, <galak@codeaurora.org>,
<ijc+devicetree@hellion.org.uk>, <mark.rutland@arm.com>,
<pawel.moll@arm.com>, <robh+dt@kernel.org>, <nsekhar@ti.com>
Subject: Re: [RFC PATCH 2/3] mmc: host: omap_hsmmc: Enable ADMA2
Date: Mon, 23 May 2016 11:52:01 +0530 [thread overview]
Message-ID: <5742A189.4060803@ti.com> (raw)
In-Reply-To: <87shxdlws6.fsf@linux.intel.com>
Hi Felipe,
On Friday 20 May 2016 12:06 AM, Felipe Balbi wrote:
>
> Hi,
>
> Tony Lindgren <tony@atomide.com> writes:
>> * Peter Ujfalusi <peter.ujfalusi@ti.com> [160519 01:10]:
>>> On 05/18/2016 10:30 PM, Tony Lindgren wrote:
>>>> Ideally the adma support would be a separate loadable module,
>>>> similar how the cppi41dma is a child of the OTG controller.
>>>
>>> The Master DMA is part of the hsmmc IP block. If the same ADMA module is
>>> present on other IPs it might be beneficial to have a helper library to handle
>>> it (allocating the descriptor pool, wrinting, updating descriptors, etc).
>>
>> OK. Yeah if it's part of the MMC controller it makes no sense to
>> separate it. So then the conecrns are using alternate DMA
>> implementations and keeping PM runtime working :)
>>
>> BTW, Felipe mentioned that the best thing to do in the long run would
>> be to set up sdhci-omap.c operating in ADMA mode.
>>
>> Felipe, care to summarize what you had in mind?
>
> yeah, just write a new sdhci-omap.c to start moving away from
> omap-hsmmc.c, just like it was done for 8250-omap.
>
> At the beginning, it could be just the bare minimum to get it working
> and slowly move over stuff like pm runtime, dmaengine, PIO. Move more
> platforms over to that driver and, eventually, get rid of omap-hsmmc.c
> altogether.
>
> That way, development can be focussed on generic layers (SDHCI) to which
> OMAP MMC controller is compliant (apart from the VERSION register
> quirk).
About an year back, when I tried using SDHCI for OMAP I ran into issues and was
not able to get it working. IIRC SDHCI_PRESENT_STATE (or OMAP_HSMMC_PSTATE) was
not showing the correct state for card present and is unable to raise an
interrupt when a card is inserted. I didn't debug this further.
It also kept me wondering why gpio interrupt was always used for card detect
instead of using mmci_sdcd line of the controller.
Thanks
Kishon
next prev parent reply other threads:[~2016-05-23 6:22 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-18 8:45 [RFC PATCH 0/3] dra7/omap4/omap5: Enable ADMA2 Kishon Vijay Abraham I
2016-05-18 8:45 ` Kishon Vijay Abraham I
2016-05-18 8:45 ` Kishon Vijay Abraham I
2016-05-18 8:45 ` [RFC PATCH 1/3] mmc: host: omap_hsmmc: remove *use_dma* member Kishon Vijay Abraham I
2016-05-18 8:45 ` Kishon Vijay Abraham I
2016-05-18 8:45 ` Kishon Vijay Abraham I
2016-05-18 8:45 ` [RFC PATCH 2/3] mmc: host: omap_hsmmc: Enable ADMA2 Kishon Vijay Abraham I
2016-05-18 8:45 ` Kishon Vijay Abraham I
2016-05-18 8:45 ` Kishon Vijay Abraham I
2016-05-18 10:24 ` Peter Ujfalusi
2016-05-18 10:24 ` Peter Ujfalusi
2016-05-18 10:24 ` Peter Ujfalusi
2016-05-18 19:30 ` Tony Lindgren
2016-05-18 19:30 ` Tony Lindgren
2016-05-19 6:14 ` Kishon Vijay Abraham I
2016-05-19 6:14 ` Kishon Vijay Abraham I
2016-05-19 6:14 ` Kishon Vijay Abraham I
2016-05-19 8:07 ` Peter Ujfalusi
2016-05-19 8:07 ` Peter Ujfalusi
2016-05-19 8:07 ` Peter Ujfalusi
2016-05-19 14:57 ` Tony Lindgren
2016-05-19 14:57 ` Tony Lindgren
2016-05-19 18:36 ` Felipe Balbi
2016-05-19 18:36 ` Felipe Balbi
2016-05-23 6:22 ` Kishon Vijay Abraham I [this message]
2016-05-23 6:22 ` Kishon Vijay Abraham I
2016-05-23 6:22 ` Kishon Vijay Abraham I
2016-05-23 7:18 ` Felipe Balbi
2016-05-23 7:18 ` Felipe Balbi
2016-05-23 8:00 ` Kishon Vijay Abraham I
2016-05-23 8:00 ` Kishon Vijay Abraham I
2016-05-23 8:00 ` Kishon Vijay Abraham I
2016-05-19 6:06 ` Kishon Vijay Abraham I
2016-05-19 6:06 ` Kishon Vijay Abraham I
2016-05-19 6:06 ` Kishon Vijay Abraham I
2016-05-19 8:02 ` Peter Ujfalusi
2016-05-19 8:02 ` Peter Ujfalusi
2016-05-19 8:02 ` Peter Ujfalusi
2016-05-18 11:07 ` Peter Ujfalusi
2016-05-18 11:07 ` Peter Ujfalusi
2016-05-18 11:07 ` Peter Ujfalusi
2016-05-19 8:25 ` Peter Ujfalusi
2016-05-19 8:25 ` Peter Ujfalusi
2016-05-19 8:25 ` Peter Ujfalusi
2016-05-18 8:45 ` [RFC PATCH 3/3] ARM: dts: dra7/omap4/omap5: " Kishon Vijay Abraham I
2016-05-18 8:45 ` Kishon Vijay Abraham I
2016-05-18 8:45 ` Kishon Vijay Abraham I
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5742A189.4060803@ti.com \
--to=kishon@ti.com \
--cc=afenkart@gmail.com \
--cc=balbi@kernel.org \
--cc=bcousson@baylibre.com \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mmc@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=mark.rutland@arm.com \
--cc=nsekhar@ti.com \
--cc=pawel.moll@arm.com \
--cc=peter.ujfalusi@ti.com \
--cc=robh+dt@kernel.org \
--cc=rogerq@ti.com \
--cc=tony@atomide.com \
--cc=ulf.hansson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.