outstanding TMIO MMC patches

outstanding TMIO MMC patches

[Guennadi Liakhovetski]

Hi Ian

There are a number of outstanding tmio-mmc patches from Arnd Hannemann and 
myself, many of them posted weeks ago. We really would like to have them 
in 2.6.38. Would you have time to process them? Otherwise, could someone 
else maybe apply them? Listed in the order, in which they should be 
applied.

my patches:

mmc: tmio_mmc: allow multi-element scatter-gather lists
	https://patchwork.kernel.org/patch/317142/
	should go in via linux-mmc

mmc: tmio_mmc: fix PIO fallback on DMA descriptor allocation failure
	https://patchwork.kernel.org/patch/317162/
	should go in via linux-mmc

[1/3] mmc: tmio: merge the private header into the driver
	https://patchwork.kernel.org/patch/349931/
	should go in via linux-mmc

[2/3] mmc: tmio: implement a bounce buffer for unaligned DMA
	https://patchwork.kernel.org/patch/426661/
	should go in via linux-mmc

[3/3] mfd: sdhi: require the tmio-mmc driver to bounce unaligned buffers
	https://patchwork.kernel.org/patch/349961/
	acked by Samuel Ortiz, should go in via linux-mmc

patches from Arnd Hannemann:

mmc: tmio_mmc: silence compiler warnings
	https://patchwork.kernel.org/patch/418931/
	should go in via linux-mmc

[1/6] mmc: tmio: implement SDIO IRQ
	https://patchwork.kernel.org/patch/437441/
	should go in via linux-mmc

[2/6] mfd: sh_mobile_sdhi: activate SDIO IRQ for tmio_mmc
	https://patchwork.kernel.org/patch/437451/
	acked by Samual Ortiz, should go in via linux-mmc

[3/6] ARM: mach-shmobile: sh7372 Enable SDIO IRQs
	https://patchwork.kernel.org/patch/437491/
	Either via linux-mmc: Ack needed by Paul Mundt
	or later separately via sh-2.6

[4/6] sh: sh7724 Enable SDIO IRQs
	https://patchwork.kernel.org/patch/437471/
	Either via linux-mmc: Ack needed by Paul Mundt
	or later separately via sh-2.6

[5/6] sh: sh7722 Enable SDIO IRQs
	https://patchwork.kernel.org/patch/437521/
	Either via linux-mmc: Ack needed by Paul Mundt
	or later separately via sh-2.6

[6/6] sh: sh7723 / ap325rxa enable SDIO IRQs
	https://patchwork.kernel.org/patch/437511/
	Either via linux-mmc: Ack needed by Paul Mundt
	or later separately via sh-2.6

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: outstanding TMIO MMC patches

[Arnd Hannemann]

Hi Guennadi,

Am 29.12.2010 00:32, schrieb Guennadi Liakhovetski:
> Hi Ian
> 
> There are a number of outstanding tmio-mmc patches from Arnd Hannemann and 
> myself, many of them posted weeks ago. We really would like to have them 
> in 2.6.38. Would you have time to process them? Otherwise, could someone 
> else maybe apply them? Listed in the order, in which they should be 
> applied.
> 
> my patches:
> 
> mmc: tmio_mmc: allow multi-element scatter-gather lists
> 	https://patchwork.kernel.org/patch/317142/
> 	should go in via linux-mmc
> 
> mmc: tmio_mmc: fix PIO fallback on DMA descriptor allocation failure
> 	https://patchwork.kernel.org/patch/317162/
> 	should go in via linux-mmc
> 
> [1/3] mmc: tmio: merge the private header into the driver
> 	https://patchwork.kernel.org/patch/349931/
> 	should go in via linux-mmc
> 
> [2/3] mmc: tmio: implement a bounce buffer for unaligned DMA
> 	https://patchwork.kernel.org/patch/426661/
> 	should go in via linux-mmc
> 
> [3/3] mfd: sdhi: require the tmio-mmc driver to bounce unaligned buffers
> 	https://patchwork.kernel.org/patch/349961/
> 	acked by Samuel Ortiz, should go in via linux-mmc
> 
> patches from Arnd Hannemann:
> 
> mmc: tmio_mmc: silence compiler warnings
> 	https://patchwork.kernel.org/patch/418931/
> 	should go in via linux-mmc
> 
> [1/6] mmc: tmio: implement SDIO IRQ
> 	https://patchwork.kernel.org/patch/437441/
> 	should go in via linux-mmc
> 
> [2/6] mfd: sh_mobile_sdhi: activate SDIO IRQ for tmio_mmc
> 	https://patchwork.kernel.org/patch/437451/
> 	acked by Samual Ortiz, should go in via linux-mmc
> 
> [3/6] ARM: mach-shmobile: sh7372 Enable SDIO IRQs
> 	https://patchwork.kernel.org/patch/437491/
> 	Either via linux-mmc: Ack needed by Paul Mundt
> 	or later separately via sh-2.6
> 
> [4/6] sh: sh7724 Enable SDIO IRQs
> 	https://patchwork.kernel.org/patch/437471/
> 	Either via linux-mmc: Ack needed by Paul Mundt
> 	or later separately via sh-2.6
> 
> [5/6] sh: sh7722 Enable SDIO IRQs
> 	https://patchwork.kernel.org/patch/437521/
> 	Either via linux-mmc: Ack needed by Paul Mundt
> 	or later separately via sh-2.6
> 
> [6/6] sh: sh7723 / ap325rxa enable SDIO IRQs
> 	https://patchwork.kernel.org/patch/437511/
> 	Either via linux-mmc: Ack needed by Paul Mundt
> 	or later separately via sh-2.6
> 

There are also these two:

[1/2] tmio_mmc: handle missing HW interrupts
	https://patchwork.kernel.org/patch/201962/
[2/2] tmio_mmc: fix CMD irq handling
	https://patchwork.kernel.org/patch/201982/

I reposted them rebased on top of your header merge, otherwise
that would have been a mess:

http://marc.info/?l=linux-mmc&m\x129362888209455&w=2

Thanks,
Arnd

Re: outstanding TMIO MMC patches

[Magnus Damm]

On Wed, Dec 29, 2010 at 8:32 AM, Guennadi Liakhovetski
<g.liakhovetski@gmx.de> wrote:
> Hi Ian
>
> There are a number of outstanding tmio-mmc patches from Arnd Hannemann and
> myself, many of them posted weeks ago. We really would like to have them
> in 2.6.38. Would you have time to process them? Otherwise, could someone
> else maybe apply them? Listed in the order, in which they should be
> applied.

mmc: tmio_mmc: allow multi-element scatter-gather lists
mmc: tmio_mmc: fix PIO fallback on DMA descriptor allocation failure
[1/3] mmc: tmio: merge the private header into the driver
[2/3] mmc: tmio: implement a bounce buffer for unaligned DMA
[3/3] mfd: sdhi: require the tmio-mmc driver to bounce unaligned buffers
mmc: tmio_mmc: silence compiler warnings
[1/6] mmc: tmio: implement SDIO IRQ
[2/6] mfd: sh_mobile_sdhi: activate SDIO IRQ for tmio_mmc
[3/6] ARM: mach-shmobile: sh7372 Enable SDIO IRQs
[4/6] sh: sh7724 Enable SDIO IRQs
[5/6] sh: sh7722 Enable SDIO IRQs
[6/6] sh: sh7723 / ap325rxa enable SDIO IRQs
[1/2] tmio_mmc: handle missing HW interrupts
[2/2] tmio_mmc: fix CMD irq handling

[14 outstanding patches including 2 unlisted from Arnd]

Guennadi, thanks a lot for this list of outstanding patches. I've
tested most of them myself and I think they are all a welcome addition
to the SDHI hardware block on SH-Mobile / R-Mobile SoCs. I'm not sure
how they affect other platforms though.

Ian, would it be possible for you to give some feedback? I know it's
holiday season and all, but the first version of most patches were
posted about a month ago.

If we can't get any feedback then perhaps someone else can maintain
the tmio-mmc driver together with Ian? Or maybe it's easier to just
easier to create a SDHI specific fork of the tmio-mmc driver which can
be modified more easily.

Any ideas?

Thanks,

/ magnus

Re: outstanding TMIO MMC patches

[Paul Mundt]

On Wed, Jan 05, 2011 at 11:10:18AM +0900, Magnus Damm wrote:
> mmc: tmio_mmc: allow multi-element scatter-gather lists
> mmc: tmio_mmc: fix PIO fallback on DMA descriptor allocation failure
> [1/3] mmc: tmio: merge the private header into the driver
> [2/3] mmc: tmio: implement a bounce buffer for unaligned DMA
> [3/3] mfd: sdhi: require the tmio-mmc driver to bounce unaligned buffers
> mmc: tmio_mmc: silence compiler warnings
> [1/6] mmc: tmio: implement SDIO IRQ
> [2/6] mfd: sh_mobile_sdhi: activate SDIO IRQ for tmio_mmc
> [3/6] ARM: mach-shmobile: sh7372 Enable SDIO IRQs
> [4/6] sh: sh7724 Enable SDIO IRQs
> [5/6] sh: sh7722 Enable SDIO IRQs
> [6/6] sh: sh7723 / ap325rxa enable SDIO IRQs
> [1/2] tmio_mmc: handle missing HW interrupts
> [2/2] tmio_mmc: fix CMD irq handling
> 
> [14 outstanding patches including 2 unlisted from Arnd]
> 
> Guennadi, thanks a lot for this list of outstanding patches. I've
> tested most of them myself and I think they are all a welcome addition
> to the SDHI hardware block on SH-Mobile / R-Mobile SoCs. I'm not sure
> how they affect other platforms though.
> 
> Ian, would it be possible for you to give some feedback? I know it's
> holiday season and all, but the first version of most patches were
> posted about a month ago.
> 
> If we can't get any feedback then perhaps someone else can maintain
> the tmio-mmc driver together with Ian? Or maybe it's easier to just
> easier to create a SDHI specific fork of the tmio-mmc driver which can
> be modified more easily.
> 
The situation is actually much worse than this, the initial patches are
more than 2 months old, and have never been commented on once by the
alleged "maintainer" of the TMIO driver. This is not the first time
either, and indeed, every single time patches are posted that touch this
driver, months pass before anything at all gets done.

My expectation was that if the subsystem had a maintainer that claimed to
be active they would step up and do something when repeated efforts to
engage with an absentee driver maintainer fall short. If neither one of
these things are the case, then I really see no reason to bring changes
to this driver to the attention of either the author or the subsystem
author, and will just start to merge them directly.

Having this amount of work backlogged without so much as a single bit of
feedback or activity from anyone that pretends to be a maintainer is
simply nonsense. It's not acceptable to have progress stalled
indefinitely simply because 'real life got in the way' or any other
number of baseless excuses. If you can't commit to doing the job you
elected to as a maintainer, then set the driver orphaned and get out of
the way.

The MMC subsystem has been pretty much a disaster in terms of maintenance
for as long as I can remember, so this is certainly not a new situation,
but I had hoped that the situation had rather improved recently with at
least some people stepping up and being a bit more active. For now, -mm
is probably the only way for these to make any sort of forward progress,
but it's a bit counter-intuitive to have to sideline an allegedly
maintained subsystem in order for anything to happen at all.

Re: outstanding TMIO MMC patches

[Chris Ball]

Hi,

On Wed, Jan 05, 2011 at 01:53:47PM +0900, Paul Mundt wrote:
> The MMC subsystem has been pretty much a disaster in terms of maintenance
> for as long as I can remember, so this is certainly not a new situation,
> but I had hoped that the situation had rather improved recently with at
> least some people stepping up and being a bit more active. For now, -mm
> is probably the only way for these to make any sort of forward progress,
> but it's a bit counter-intuitive to have to sideline an allegedly
> maintained subsystem in order for anything to happen at all.

Wow, how hostile -- insult first, ask questions later?  I do review and
merge MMC patches; all it takes is a ping to let me know that the tmio
maintainer is absent and that you'd like me to start picking these up.
I'd seen them being taken into other trees, and no-one's asked me about
merging any of them into the MMC tree before, so I didn't realize there
was a problem.  We just need more communication.

So, let's come up with a workflow.  With Ian absent, it would be good to
have someone with TMIO hardware (I don't have any) who's willing to help
test and review/ACK patches.  I don't generally like to take arch code
in through the MMC tree, so it would also be good to break up some of
the patchsets into MMC-only if possible.

-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: outstanding TMIO MMC patches

[Paul Mundt]

On Wed, Jan 05, 2011 at 04:57:57PM +0000, Chris Ball wrote:
> Wow, how hostile -- insult first, ask questions later?  I do review and
> merge MMC patches; all it takes is a ping to let me know that the tmio
> maintainer is absent and that you'd like me to start picking these up.
> I'd seen them being taken into other trees, and no-one's asked me about
> merging any of them into the MMC tree before, so I didn't realize there
> was a problem.  We just need more communication.
> 
Again, this isn't the first time this has happened. Any perceived
hostility in this matter is not directed at you directly since you did
come in to things rather late and were possibly unaware of the situation.
It's more absentee maintainers I have a problem with. In any event, you
were Cc'ed on mails that pointed out the problem (at least in summary),
you've presumably seen the mails with the patches that went by with pings
by people looking for answers, and it still took a strongly worded email
to elicit any sort of response. Make of that what you will.

In any event, we seem to have shaken out the beginnings of a way forward
now, so this is progress!

> So, let's come up with a workflow.  With Ian absent, it would be good to
> have someone with TMIO hardware (I don't have any) who's willing to help
> test and review/ACK patches.  I don't generally like to take arch code
> in through the MMC tree, so it would also be good to break up some of
> the patchsets into MMC-only if possible.
> 
This is basically where the problem lies. Ian has some version of the
hardware that we don't, and he likewise doesn't have access to the
version that we do (of course there would be no problem in making the
hardware available to whoever decides to step up and look after TMIO in a
more constructive fashion, though). There are likewise issues with
regards to who has access to what specifications, and there are cases
where neither Ian nor any of the people from our side have any specs at
all. With this sort of a scenario it can be quite difficult to avoid
stepping on other peoples toes and making sure that things aren't being
inadvertently broken, and this is something I don't see any specific
resolution to, other than if you're not around to test and object in a
timely fashion, you lose. I don't know if other MMC drivers have the same
problem or not, but I can't imagine that this situation is terribly
unique when you have both corporations and hobbyists working on the same
driver from vastly different angles.

For the moment Guennadi and Arnd have been doing the work, with the
occasional patch from Magnus and others. All of this work however is done
on the same set of hardware and roughly by the same set of people with an
identical set of interests working for the same company, which makes
objective code review a bit problematic. Ian has provided useful feedback
in the past, which is why I've generally given him the benefit of the
doubt and let patches sit around for a month or two before pushing on
people. I note that the driver is 'maintained' for example instead of
'supported', so it's understandable that people do somethings get pulled
away by other things from time to time. If one persistently can't even do
the bare minimum however, then it should simply be orphaned.

As it is now however we are quickly building up an unwieldly patch stack
with more future work to be done, and I'm hesitant to have anyone begin
any future work when the existing dependencies are wildly out of sync
with upstream already. If we can get some sort of process in place that
makes this less of a problem, then of course I'm pretty open to anything.
The main thing I want to avoid is a feedback loop where things go in to
-mm purgatory, get bounced off of Ian once a month or so, and then the
process repeats itself.

Re: outstanding TMIO MMC patches

[Chris Ball]

On Thu, Jan 06, 2011 at 02:30:30AM +0900, Paul Mundt wrote:
> Again, this isn't the first time this has happened. Any perceived
> hostility in this matter is not directed at you directly since you did
> come in to things rather late and were possibly unaware of the situation.
> It's more absentee maintainers I have a problem with. In any event, you
> were Cc'ed on mails that pointed out the problem (at least in summary),
> you've presumably seen the mails with the patches that went by with pings
> by people looking for answers, and it still took a strongly worded email
> to elicit any sort of response. Make of that what you will.

A politely-worded email would have achieved just as good a response as the
insultingly-worded one.  You should reach for politeness first when dealing
with someone who might simply be misunderstanding your expectations of them.

Since I came in late, I've been reluctant to overrule driver maintainers
without someone asking me to do so explicitly (I'm happy to do it when
asked to).  I do sympathize with the frustration, though; let's move on.

> In any event, we seem to have shaken out the beginnings of a way forward
> now, so this is progress!
> 
> > So, let's come up with a workflow.  With Ian absent, it would be good to
> > have someone with TMIO hardware (I don't have any) who's willing to help
> > test and review/ACK patches.  I don't generally like to take arch code
> > in through the MMC tree, so it would also be good to break up some of
> > the patchsets into MMC-only if possible.
> > 
> This is basically where the problem lies. Ian has some version of the
> hardware that we don't, and he likewise doesn't have access to the
> version that we do (of course there would be no problem in making the
> hardware available to whoever decides to step up and look after TMIO in a
> more constructive fashion, though). There are likewise issues with
> regards to who has access to what specifications, and there are cases
> where neither Ian nor any of the people from our side have any specs at
> all. With this sort of a scenario it can be quite difficult to avoid
> stepping on other peoples toes and making sure that things aren't being
> inadvertently broken, and this is something I don't see any specific
> resolution to, other than if you're not around to test and object in a
> timely fashion, you lose. I don't know if other MMC drivers have the same
> problem or not, but I can't imagine that this situation is terribly
> unique when you have both corporations and hobbyists working on the same
> driver from vastly different angles.

I see.  So, if most patches are coming from your side, it seems that the
largest problem for the moment is that no-one except Ian can test your
patches against his hardware.  Do we think there's any chance of someone
(I guess ideally you but possibly me) getting hold of hardware with Ian's
MMC block in, for at least occasional testing before releases?

If not, is there any kind of split in the driver that we could use to try
to isolate changes more?

If not, I guess I agree that we just have to try and be clear about what
we're merging and the chance that we're breaking something in the process.

> For the moment Guennadi and Arnd have been doing the work, with the
> occasional patch from Magnus and others. All of this work however is done
> on the same set of hardware and roughly by the same set of people with an
> identical set of interests working for the same company, which makes
> objective code review a bit problematic. Ian has provided useful feedback
> in the past, which is why I've generally given him the benefit of the
> doubt and let patches sit around for a month or two before pushing on
> people. I note that the driver is 'maintained' for example instead of
> 'supported', so it's understandable that people do somethings get pulled
> away by other things from time to time. If one persistently can't even do
> the bare minimum however, then it should simply be orphaned.
> 
> As it is now however we are quickly building up an unwieldly patch stack
> with more future work to be done, and I'm hesitant to have anyone begin
> any future work when the existing dependencies are wildly out of sync
> with upstream already. If we can get some sort of process in place that
> makes this less of a problem, then of course I'm pretty open to anything.
> The main thing I want to avoid is a feedback loop where things go in to
> -mm purgatory, get bounced off of Ian once a month or so, and then the
> process repeats itself.

Yes, I expect we can start by merging many of the outstanding patches.
It looks like all except Arnd's six-part series can be merged via the
MMC tree, since the MFD changes have an ACK from Samuel already. 
I'll do that today.

Arnd, can I take just patches 1/2 from your six-part series, and have
you send the rest through the arch/ maintainers later?

-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: outstanding TMIO MMC patches

[Arnd Hannemann]

Hi Chris,

Am 05.01.2011 19:57, schrieb Chris Ball:
> On Thu, Jan 06, 2011 at 02:30:30AM +0900, Paul Mundt wrote:
>> Again, this isn't the first time this has happened. Any perceived
>> hostility in this matter is not directed at you directly since you did
>> come in to things rather late and were possibly unaware of the situation.
>> It's more absentee maintainers I have a problem with. In any event, you
>> were Cc'ed on mails that pointed out the problem (at least in summary),
>> you've presumably seen the mails with the patches that went by with pings
>> by people looking for answers, and it still took a strongly worded email
>> to elicit any sort of response. Make of that what you will.
> 
> A politely-worded email would have achieved just as good a response as the
> insultingly-worded one.  You should reach for politeness first when dealing
> with someone who might simply be misunderstanding your expectations of them.
> 
> Since I came in late, I've been reluctant to overrule driver maintainers
> without someone asking me to do so explicitly (I'm happy to do it when
> asked to).  I do sympathize with the frustration, though; let's move on.
> 
>> In any event, we seem to have shaken out the beginnings of a way forward
>> now, so this is progress!
>>
>>> So, let's come up with a workflow.  With Ian absent, it would be good to
>>> have someone with TMIO hardware (I don't have any) who's willing to help
>>> test and review/ACK patches.  I don't generally like to take arch code
>>> in through the MMC tree, so it would also be good to break up some of
>>> the patchsets into MMC-only if possible.
>>>
>> This is basically where the problem lies. Ian has some version of the
>> hardware that we don't, and he likewise doesn't have access to the
>> version that we do (of course there would be no problem in making the
>> hardware available to whoever decides to step up and look after TMIO in a
>> more constructive fashion, though). There are likewise issues with
>> regards to who has access to what specifications, and there are cases
>> where neither Ian nor any of the people from our side have any specs at
>> all. With this sort of a scenario it can be quite difficult to avoid
>> stepping on other peoples toes and making sure that things aren't being
>> inadvertently broken, and this is something I don't see any specific
>> resolution to, other than if you're not around to test and object in a
>> timely fashion, you lose. I don't know if other MMC drivers have the same
>> problem or not, but I can't imagine that this situation is terribly
>> unique when you have both corporations and hobbyists working on the same
>> driver from vastly different angles.
> 
> I see.  So, if most patches are coming from your side, it seems that the
> largest problem for the moment is that no-one except Ian can test your
> patches against his hardware.  Do we think there's any chance of someone
> (I guess ideally you but possibly me) getting hold of hardware with Ian's
> MMC block in, for at least occasional testing before releases?
> 
> If not, is there any kind of split in the driver that we could use to try
> to isolate changes more?
> 
> If not, I guess I agree that we just have to try and be clear about what
> we're merging and the chance that we're breaking something in the process.
> 
>> For the moment Guennadi and Arnd have been doing the work, with the
>> occasional patch from Magnus and others. All of this work however is done
>> on the same set of hardware and roughly by the same set of people with an
>> identical set of interests working for the same company, which makes
>> objective code review a bit problematic. Ian has provided useful feedback
>> in the past, which is why I've generally given him the benefit of the
>> doubt and let patches sit around for a month or two before pushing on
>> people. I note that the driver is 'maintained' for example instead of
>> 'supported', so it's understandable that people do somethings get pulled
>> away by other things from time to time. If one persistently can't even do
>> the bare minimum however, then it should simply be orphaned.
>>
>> As it is now however we are quickly building up an unwieldly patch stack
>> with more future work to be done, and I'm hesitant to have anyone begin
>> any future work when the existing dependencies are wildly out of sync
>> with upstream already. If we can get some sort of process in place that
>> makes this less of a problem, then of course I'm pretty open to anything.
>> The main thing I want to avoid is a feedback loop where things go in to
>> -mm purgatory, get bounced off of Ian once a month or so, and then the
>> process repeats itself.
> 
> Yes, I expect we can start by merging many of the outstanding patches.
> It looks like all except Arnd's six-part series can be merged via the
> MMC tree, since the MFD changes have an ACK from Samuel already. 
> I'll do that today.
> 
> Arnd, can I take just patches 1/2 from your six-part series, and have
> you send the rest through the arch/ maintainers later?

Sure, should be no problem.
Ah, just saw that you already pushed those two, thanks.

@Paul: 
Maybe it would be best that you ACK those arch patches (if you think
they are ok) and that they also go in via the mmc-next tree?
Otherwise we would need to wait until mmc-next for .38 is merged in your trees,
right?

Thanks,
Arnd

Re: outstanding TMIO MMC patches

[Chris Ball]

Hi,

Just to check we're agreed on the current status:

On Wed, Dec 29, 2010 at 02:35:51PM +0100, Arnd Hannemann wrote:
> > my patches:
> > 
> > mmc: tmio_mmc: allow multi-element scatter-gather lists
> > 	https://patchwork.kernel.org/patch/317142/
> > 	should go in via linux-mmc
> > 
> > mmc: tmio_mmc: fix PIO fallback on DMA descriptor allocation failure
> > 	https://patchwork.kernel.org/patch/317162/
> > 	should go in via linux-mmc
> > 
> > [1/3] mmc: tmio: merge the private header into the driver
> > 	https://patchwork.kernel.org/patch/349931/
> > 	should go in via linux-mmc
> > 
> > [2/3] mmc: tmio: implement a bounce buffer for unaligned DMA
> > 	https://patchwork.kernel.org/patch/426661/
> > 	should go in via linux-mmc
> > 
> > [3/3] mfd: sdhi: require the tmio-mmc driver to bounce unaligned buffers
> > 	https://patchwork.kernel.org/patch/349961/
> > 	acked by Samuel Ortiz, should go in via linux-mmc
> > 
> > patches from Arnd Hannemann:
> > 
> > mmc: tmio_mmc: silence compiler warnings
> > 	https://patchwork.kernel.org/patch/418931/
> > 	should go in via linux-mmc
> > 
> > [1/6] mmc: tmio: implement SDIO IRQ
> > 	https://patchwork.kernel.org/patch/437441/
> > 	should go in via linux-mmc
> > 
> > [2/6] mfd: sh_mobile_sdhi: activate SDIO IRQ for tmio_mmc
> > 	https://patchwork.kernel.org/patch/437451/
> > 	acked by Samual Ortiz, should go in via linux-mmc

I've merged all of the above patches.

> > [3/6] ARM: mach-shmobile: sh7372 Enable SDIO IRQs
> > 	https://patchwork.kernel.org/patch/437491/
> > 	Either via linux-mmc: Ack needed by Paul Mundt
> > 	or later separately via sh-2.6
> > 
> > [4/6] sh: sh7724 Enable SDIO IRQs
> > 	https://patchwork.kernel.org/patch/437471/
> > 	Either via linux-mmc: Ack needed by Paul Mundt
> > 	or later separately via sh-2.6
> > 
> > [5/6] sh: sh7722 Enable SDIO IRQs
> > 	https://patchwork.kernel.org/patch/437521/
> > 	Either via linux-mmc: Ack needed by Paul Mundt
> > 	or later separately via sh-2.6
> > 
> > [6/6] sh: sh7723 / ap325rxa enable SDIO IRQs
> > 	https://patchwork.kernel.org/patch/437511/
> > 	Either via linux-mmc: Ack needed by Paul Mundt
> > 	or later separately via sh-2.6

I haven't merged these because I'd prefer them to go via architecture
trees.

> There are also these two:
> 
> [1/2] tmio_mmc: handle missing HW interrupts
> 	https://patchwork.kernel.org/patch/201962/
> [2/2] tmio_mmc: fix CMD irq handling
> 	https://patchwork.kernel.org/patch/201982/

I haven't merged these because 1/2 breaks the build without TMIO_MMC_DMA=y.

-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: outstanding TMIO MMC patches

[Chris Ball]

On Wed, Jan 05, 2011 at 10:24:08PM +0000, Chris Ball wrote:
> > There are also these two:
> > 
> > [1/2] tmio_mmc: handle missing HW interrupts
> > 	https://patchwork.kernel.org/patch/201962/
> > [2/2] tmio_mmc: fix CMD irq handling
> > 	https://patchwork.kernel.org/patch/201982/
> 
> I haven't merged these because 1/2 breaks the build without TMIO_MMC_DMA=y.

These two are merged now, was my fault.

-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: outstanding TMIO MMC patches

[Chris Ball]

Hi Ian,

On Wed, Dec 29, 2010 at 12:32:13AM +0100, Guennadi Liakhovetski wrote:
> There are a number of outstanding tmio-mmc patches from Arnd Hannemann and 
> myself, many of them posted weeks ago. We really would like to have them 
> in 2.6.38. Would you have time to process them? Otherwise, could someone 
> else maybe apply them? Listed in the order, in which they should be 
> applied.

I've applied these to mmc-next, plus two more of Arnd's, since it looks 
like you don't have time for reviews at the moment.  Feel free to review
them before .38 releases; we can still make changes if necessary.  It'd
be great if you can retest on mmc-next with your HW, too.

- Chris.
-- 
Chris Ball   <cjb@laptop.org>   <http://printf.net/>
One Laptop Per Child

Re: outstanding TMIO MMC patches

[Paul Mundt]

On Wed, Jan 05, 2011 at 10:16:24PM +0100, Arnd Hannemann wrote:
> Am 05.01.2011 19:57, schrieb Chris Ball:
> > Arnd, can I take just patches 1/2 from your six-part series, and have
> > you send the rest through the arch/ maintainers later?
> 
> Sure, should be no problem.
> Ah, just saw that you already pushed those two, thanks.
> 
> @Paul: 
> Maybe it would be best that you ACK those arch patches (if you think
> they are ok) and that they also go in via the mmc-next tree?
> Otherwise we would need to wait until mmc-next for .38 is merged in your trees,
> right?
> 
If Chris prefers they go through the architecture side then that's not a
problem either. I'll be doing at least 2 merges during the merge window,
and this stuff is just adding in platform data, so it doesn't really
matter when it gets rolled in. Optionally if the MMC tree doesn't rebase
I can just set up a topic branch that branches off of that, roll these
patches on top of that, and you can just test that directly.

Re: outstanding TMIO MMC patches

[Paul Mundt]

On Wed, Jan 05, 2011 at 06:57:17PM +0000, Chris Ball wrote:
> On Thu, Jan 06, 2011 at 02:30:30AM +0900, Paul Mundt wrote:
> > This is basically where the problem lies. Ian has some version of the
> > hardware that we don't, and he likewise doesn't have access to the
> > version that we do (of course there would be no problem in making the
> > hardware available to whoever decides to step up and look after TMIO in a
> > more constructive fashion, though). There are likewise issues with
> > regards to who has access to what specifications, and there are cases
> > where neither Ian nor any of the people from our side have any specs at
> > all. With this sort of a scenario it can be quite difficult to avoid
> > stepping on other peoples toes and making sure that things aren't being
> > inadvertently broken, and this is something I don't see any specific
> > resolution to, other than if you're not around to test and object in a
> > timely fashion, you lose. I don't know if other MMC drivers have the same
> > problem or not, but I can't imagine that this situation is terribly
> > unique when you have both corporations and hobbyists working on the same
> > driver from vastly different angles.
> 
> I see.  So, if most patches are coming from your side, it seems that the
> largest problem for the moment is that no-one except Ian can test your
> patches against his hardware.  Do we think there's any chance of someone
> (I guess ideally you but possibly me) getting hold of hardware with Ian's
> MMC block in, for at least occasional testing before releases?
> 
> If not, is there any kind of split in the driver that we could use to try
> to isolate changes more?
> 
The biggest difference is that the stuff Ian is working with is a
full-blown MFD, while from our side we're simply dealing with an insular
MFD cell. At the moment we have a shim single-function MFD driver
(sh_mobile_shdi) that simply packages up the insular cell and binds it to
tmio-mmc so that we could keep using the same interface on the MMC side
without having to hack up the driver irreperably.

The behaviour however is not always the same, which you can already see
in things like 311f3ac76826bfd8ed6213ded91ec947df164def when DMA support
was added. For the most part it's been posible to keep things fairly
compartmentalized by layering on top of MFD, but there are plenty of
cases where we just have to make assumptions about how the other versions
of the block work. Given that we don't have an MFD in any of the blocks
we're using, it's not always readily apparent what the best way to split
things out is while keeping within the spirit of the MFD layering. How
best to handle runtime PM for example remains an outstanding issue.

As far as I can tell, all of the other MFD drivers using tmio-mmc are
already years old and mostly seem to have come out of the handhelds.org
work. Some of them bear recent copyrights but were ported from 2.4 code,
and so date from that era of hardware. I expect that for the most part
these have all been end of lifed from Toshiba's side already, so it's not
entirely obvious how easy they will be to procure. I'll take a look and
see what I can dig up though, and of course we're happy to send hardware
with our version of the block in it to whoever wishes to do independent
testing.

Re: outstanding TMIO MMC patches

[Magnus Damm]

Hi Chris,

On Thu, Jan 6, 2011 at 3:57 AM, Chris Ball <cjb@laptop.org> wrote:
> On Thu, Jan 06, 2011 at 02:30:30AM +0900, Paul Mundt wrote:
>> This is basically where the problem lies. Ian has some version of the
>> hardware that we don't, and he likewise doesn't have access to the
>> version that we do (of course there would be no problem in making the
>> hardware available to whoever decides to step up and look after TMIO in a
>> more constructive fashion, though). There are likewise issues with
>> regards to who has access to what specifications, and there are cases
>> where neither Ian nor any of the people from our side have any specs at
>> all. With this sort of a scenario it can be quite difficult to avoid
>> stepping on other peoples toes and making sure that things aren't being
>> inadvertently broken, and this is something I don't see any specific
>> resolution to, other than if you're not around to test and object in a
>> timely fashion, you lose. I don't know if other MMC drivers have the same
>> problem or not, but I can't imagine that this situation is terribly
>> unique when you have both corporations and hobbyists working on the same
>> driver from vastly different angles.
>
> I see.  So, if most patches are coming from your side, it seems that the
> largest problem for the moment is that no-one except Ian can test your
> patches against his hardware.  Do we think there's any chance of someone
> (I guess ideally you but possibly me) getting hold of hardware with Ian's
> MMC block in, for at least occasional testing before releases?
>
> If not, is there any kind of split in the driver that we could use to try
> to isolate changes more?

At this point we make use of capability flags prefixed with TMIO_MMC
to flag that the specific hardware block supports a certain feature.
So for instance the SDIO code for tmio-mmc is rather isolated and is
only enabled if TMIO_MMC_SDIO_IRQ is flagged - like it is by the SDHI
mfd wrapper.

Like Paul mentioned, upcoming Runtime PM changes will be very
intrusive, so the current abstraction may not be enough in the near
future. But let's deal with that then.

As for SDHI documentation, we have access to very little information.
The SDHI blocks are not even included in the regular per-SoC data
sheet. I managed to figure out that we can use the tmio-mmc driver by
comparing bit fields in an out-of-tree driver with existing mainline
drivers.

I suspect that the SDHI hardware block is somewhat related to the
MN57xx family, perhaps, MN5774. For not so much information in
japanese google for "2002_co2.pdf mn57xx". According to that
information there are a wide range of devices available but we're yet
to see any open driver coming from the vendor. At this point all we've
got is the tmio-mmc driver that has been reverse engineered by
hobbyists.

Many thanks for your help!

/ magnus