| Message ID | 200912032045.48728.bzolnier@gmail.com |
|---|---|
| State | Not Applicable |
| Delegated to: | David Miller |
| Headers | show |
On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote: > On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote: >> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote: >>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote: >>>> The merge window is upon us, which by strict rules means that anything >>>> not already in libata-dev.git#upstream needs to wait until 2.6.34. >>>> >>>> However, bug fixes and the like should definitely be in 2.6.33. >>>> ->init_host is definitely 2.6.34 material. Some of the other stuff >>>> could go either way. >> >>> If you would like to apply some of my patches to 2.6.33 you are more than >>> welcome to do it. I can even prepare separate git tree with specific changes >>> to make it easier for you once you tell me which changes you would like to >>> see in it. >> >> OK, great. >> >> Can you prepare a patchset containing only fixes? Comment-only changes >> are acceptable too. Trivial changes too, if they are extremely trivial :) >> >> Include nothing that adds features, removes or unifies drivers, etc. > > Since this is pretty high-level description and some changes fall into > many categories at once (i.e. addition of proper PCI Power Management > handling could be considered both as a fix and as a feature) I prepared > a rather conservative set of changes (which means that unfortunately > it misses many enhancements available in my tree): > >> Please do it in standard kernel submit form, which is either >> (a) repost the patches (yes, again) being submitted for 2.6.33, or >> (b) a standard git pull request, which includes shortlog, diffstat, and >> all-in-one diff. > > Thank you for the detailed explanation of the standard kernel submit > form (I wonder how would I know this otherwise :) but the thing is that > at the current moment I'm not submitting anything to the upstream. Ok, that explains my confusion, then. I had thought you intended to get this stuff upstream, and into users' hands. > That's it. While this may sound strange to some people it turns out > that in practice it is much less hassle for me personally to keep some > of trees outside of the (sometimes greatly overrated) upstream. > > If knowing the above you still would like to include the aforementioned > set of changes in your libata-dev tree they are at kernel.org now. I will go through this batch and cherry-pick. The build fix is already in my tree. Existing kernel practice (and previous comments) indicate that lists of known issues do not belong in Kconfig. Will take a look at the other stuff... Thanks, Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote: > On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote: > > On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote: > >> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote: > >>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote: > >>>> The merge window is upon us, which by strict rules means that anything > >>>> not already in libata-dev.git#upstream needs to wait until 2.6.34. > >>>> > >>>> However, bug fixes and the like should definitely be in 2.6.33. > >>>> ->init_host is definitely 2.6.34 material. Some of the other stuff > >>>> could go either way. > >> > >>> If you would like to apply some of my patches to 2.6.33 you are more than > >>> welcome to do it. I can even prepare separate git tree with specific changes > >>> to make it easier for you once you tell me which changes you would like to > >>> see in it. > >> > >> OK, great. > >> > >> Can you prepare a patchset containing only fixes? Comment-only changes > >> are acceptable too. Trivial changes too, if they are extremely trivial :) > >> > >> Include nothing that adds features, removes or unifies drivers, etc. > > > > Since this is pretty high-level description and some changes fall into > > many categories at once (i.e. addition of proper PCI Power Management > > handling could be considered both as a fix and as a feature) I prepared > > a rather conservative set of changes (which means that unfortunately > > it misses many enhancements available in my tree): > > > >> Please do it in standard kernel submit form, which is either > >> (a) repost the patches (yes, again) being submitted for 2.6.33, or > >> (b) a standard git pull request, which includes shortlog, diffstat, and > >> all-in-one diff. > > > > Thank you for the detailed explanation of the standard kernel submit > > form (I wonder how would I know this otherwise :) but the thing is that > > at the current moment I'm not submitting anything to the upstream. > > Ok, that explains my confusion, then. I had thought you intended to get > this stuff upstream, and into users' hands. Interesting argument but the vast majority of users use distribution kernels which are not upstream and I doubt that any self-respecting distribution would miss such amount of fixes. The rest can easily use my tree which follows upstream closely and can be obtained using a single line git command. > > That's it. While this may sound strange to some people it turns out > > that in practice it is much less hassle for me personally to keep some > > of trees outside of the (sometimes greatly overrated) upstream. > > > > If knowing the above you still would like to include the aforementioned > > set of changes in your libata-dev tree they are at kernel.org now. > > I will go through this batch and cherry-pick. The build fix is already > in my tree. Existing kernel practice (and previous comments) indicate > that lists of known issues do not belong in Kconfig. Will take a look > at the other stuff... Well, you were aware that they were not dropped so you could have easily told me that you specifically don't want this patches in the for-2.6.33 tree.. -- Bartlomiej Zolnierkiewicz -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote: > On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote: >> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote: >>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote: >>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote: >>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote: >>>>>> The merge window is upon us, which by strict rules means that anything >>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34. >>>>>> >>>>>> However, bug fixes and the like should definitely be in 2.6.33. >>>>>> ->init_host is definitely 2.6.34 material. Some of the other stuff >>>>>> could go either way. >>>> >>>>> If you would like to apply some of my patches to 2.6.33 you are more than >>>>> welcome to do it. I can even prepare separate git tree with specific changes >>>>> to make it easier for you once you tell me which changes you would like to >>>>> see in it. >>>> >>>> OK, great. >>>> >>>> Can you prepare a patchset containing only fixes? Comment-only changes >>>> are acceptable too. Trivial changes too, if they are extremely trivial :) >>>> >>>> Include nothing that adds features, removes or unifies drivers, etc. >>> >>> Since this is pretty high-level description and some changes fall into >>> many categories at once (i.e. addition of proper PCI Power Management >>> handling could be considered both as a fix and as a feature) I prepared >>> a rather conservative set of changes (which means that unfortunately >>> it misses many enhancements available in my tree): >>> >>>> Please do it in standard kernel submit form, which is either >>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or >>>> (b) a standard git pull request, which includes shortlog, diffstat, and >>>> all-in-one diff. >>> >>> Thank you for the detailed explanation of the standard kernel submit >>> form (I wonder how would I know this otherwise :) but the thing is that >>> at the current moment I'm not submitting anything to the upstream. >> >> Ok, that explains my confusion, then. I had thought you intended to get >> this stuff upstream, and into users' hands. > > Interesting argument but the vast majority of users use distribution kernels > which are not upstream and I doubt that any self-respecting distribution would > miss such amount of fixes. Interesting argument, but applied across 1000+ developers this is clearly an unscalable development model for distributions. Thus, patches go upstream, and are then distributed widely, to eliminate massive amounts of duplicated work across distributions. You are essentially implying that each distribution must - discover your tree - look through the mailing list to figure out why each of ~80 changes are not upstream - individually make a decision on each of ~80 changes - actively track your tree for updates, repeating this process over and over again Talk about a lot of unwanted work pushed upon OTHER people, all because you choose to avoid the standard upstream development process. >>> That's it. While this may sound strange to some people it turns out >>> that in practice it is much less hassle for me personally to keep some >>> of trees outside of the (sometimes greatly overrated) upstream. >>> >>> If knowing the above you still would like to include the aforementioned >>> set of changes in your libata-dev tree they are at kernel.org now. >> >> I will go through this batch and cherry-pick. The build fix is already >> in my tree. Existing kernel practice (and previous comments) indicate >> that lists of known issues do not belong in Kconfig. Will take a look >> at the other stuff... > > Well, you were aware that they were not dropped so you could have easily told > me that you specifically don't want this patches in the for-2.6.33 tree.. At the time you built atang-2.6.33, you were aware that those Kconfig changes were not wanted -at all-. You tell others "I think that there were enough hints in my mail already" then fail to apply this logic to yourself. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote: > On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote: > > On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote: > >> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote: > >>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote: > >>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote: > >>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote: > >>>>>> The merge window is upon us, which by strict rules means that anything > >>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34. > >>>>>> > >>>>>> However, bug fixes and the like should definitely be in 2.6.33. > >>>>>> ->init_host is definitely 2.6.34 material. Some of the other stuff > >>>>>> could go either way. > >>>> > >>>>> If you would like to apply some of my patches to 2.6.33 you are more than > >>>>> welcome to do it. I can even prepare separate git tree with specific changes > >>>>> to make it easier for you once you tell me which changes you would like to > >>>>> see in it. > >>>> > >>>> OK, great. > >>>> > >>>> Can you prepare a patchset containing only fixes? Comment-only changes > >>>> are acceptable too. Trivial changes too, if they are extremely trivial :) > >>>> > >>>> Include nothing that adds features, removes or unifies drivers, etc. > >>> > >>> Since this is pretty high-level description and some changes fall into > >>> many categories at once (i.e. addition of proper PCI Power Management > >>> handling could be considered both as a fix and as a feature) I prepared > >>> a rather conservative set of changes (which means that unfortunately > >>> it misses many enhancements available in my tree): > >>> > >>>> Please do it in standard kernel submit form, which is either > >>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or > >>>> (b) a standard git pull request, which includes shortlog, diffstat, and > >>>> all-in-one diff. > >>> > >>> Thank you for the detailed explanation of the standard kernel submit > >>> form (I wonder how would I know this otherwise :) but the thing is that > >>> at the current moment I'm not submitting anything to the upstream. > >> > >> Ok, that explains my confusion, then. I had thought you intended to get > >> this stuff upstream, and into users' hands. > > > > Interesting argument but the vast majority of users use distribution kernels > > which are not upstream and I doubt that any self-respecting distribution would > > miss such amount of fixes. > > Interesting argument, but applied across 1000+ developers this is > clearly an unscalable development model for distributions. Thus, Interesting that you have brought distributions' convenience before non-distribution developers' one. > patches go upstream, and are then distributed widely, to eliminate > massive amounts of duplicated work across distributions. > > You are essentially implying that each distribution must > > - discover your tree > - look through the mailing list to figure out why each of > ~80 changes are not upstream > - individually make a decision on each of ~80 changes > - actively track your tree for updates, repeating this process > over and over again Not really. I'm only saying that the upstream is so much hassle to deal with it that it is up to people wanting to see my changes upstream to do the work on integrating them upstream if they want to see them in upstream faster. Fair enough? > Talk about a lot of unwanted work pushed upon OTHER people, all because > you choose to avoid the standard upstream development process. I'm not forcing any work on anybody and I'm not avoiding the standard process. I just find other things to have higher priority than pushing these changes upstream right now. > >>> That's it. While this may sound strange to some people it turns out > >>> that in practice it is much less hassle for me personally to keep some > >>> of trees outside of the (sometimes greatly overrated) upstream. > >>> > >>> If knowing the above you still would like to include the aforementioned > >>> set of changes in your libata-dev tree they are at kernel.org now. > >> > >> I will go through this batch and cherry-pick. The build fix is already > >> in my tree. Existing kernel practice (and previous comments) indicate > >> that lists of known issues do not belong in Kconfig. Will take a look > >> at the other stuff... > > > > Well, you were aware that they were not dropped so you could have easily told > > me that you specifically don't want this patches in the for-2.6.33 tree.. > > At the time you built atang-2.6.33, you were aware that those Kconfig > changes were not wanted -at all-. Why should I remember/care/worry about such details? > You tell others "I think that there were enough hints in my mail > already" then fail to apply this logic to yourself. You forgot that it was you who have asked me to prepare this tree to enhance your tree. -- Bartlomiej Zolnierkiewicz -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Alan, Can you sanity check me on these? > Bartlomiej Zolnierkiewicz (28): > ide-pci-generic: build fix ACK but skipped -- already applied myself > ata_piix: fix MWDMA handling on PIIX3 applied > pata_efar: fix wrong PIO timings being programmed applied > pata_efar: fix wrong MWDMA timings being programmed applied > pata_efar: MWDMA0 is unsupported skipped, pending discussion (just sent email) > pata_cmd640: document known issues rejected, for reasons already explained > pata_cs5520: remove dead VDMA support applied > pata_cypress: document known issues rejected, for reasons already explained > pata_hpt3x2n: fix overclocked MWDMA0 timing skipped, pending discussion (just sent email) > pata_hpt3x3: Power Management fix applied, on a hope and a prayer (did not see this posted to mailing list?). It looks correct to me. > pata_it8213: fix UDMA handling applied > pata_it8213: fix wrong PIO timings being programmed applied > pata_it8213: fix PIO2 underclocking applied > pata_it8213: fix wrong MWDMA timings being programmed applied > pata_it8213: fix it8213_pre_reset() documentation applied > pata_it8213: MWDMA0 is unsupported skipped, pending discussion (just sent email) > pata_legacy: fix QDI6580DP support applied > pata_legacy: fix access to control register for QDI6580 applied > pata_legacy: add pointers to QDI65x0 documentation applied. I did not think the file path issue raised was important enough to warrant patch rejection. > pata_marvell: fix marvell_pre_reset() documentation applied > pata_ns87415: Power Management fix applied > pata_oldpiix: MWDMA0 is unsupported skipped -- Alan, Sergey, comments? > pata_pdc202xx_old: document known issues rejected, for reasons already explained > pata_radisys: fix UDMA handling applied > pata_rdc: MWDMA0 is unsupported skipped -- Alan, Sergey, comments? > pata_rz1000: Power Management fix applied > pata_sis: Power Management fix applied > pata_via: clear UDMA transfer mode bit for PIO and MWDMA applied -- even though Alan's comment was correct. It is standard kernel practice to place cosmetic changes into their own patches, because it is standard kernel practice to break up logically distinct changes. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/03/2009 04:01 PM, Bartlomiej Zolnierkiewicz wrote: > On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote: >> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote: >>> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote: >>>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote: >>>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote: >>>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote: >>>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote: >>>>>>>> The merge window is upon us, which by strict rules means that anything >>>>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34. >>>>>>>> >>>>>>>> However, bug fixes and the like should definitely be in 2.6.33. >>>>>>>> ->init_host is definitely 2.6.34 material. Some of the other stuff >>>>>>>> could go either way. >>>>>> >>>>>>> If you would like to apply some of my patches to 2.6.33 you are more than >>>>>>> welcome to do it. I can even prepare separate git tree with specific changes >>>>>>> to make it easier for you once you tell me which changes you would like to >>>>>>> see in it. >>>>>> >>>>>> OK, great. >>>>>> >>>>>> Can you prepare a patchset containing only fixes? Comment-only changes >>>>>> are acceptable too. Trivial changes too, if they are extremely trivial :) >>>>>> >>>>>> Include nothing that adds features, removes or unifies drivers, etc. >>>>> >>>>> Since this is pretty high-level description and some changes fall into >>>>> many categories at once (i.e. addition of proper PCI Power Management >>>>> handling could be considered both as a fix and as a feature) I prepared >>>>> a rather conservative set of changes (which means that unfortunately >>>>> it misses many enhancements available in my tree): >>>>> >>>>>> Please do it in standard kernel submit form, which is either >>>>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or >>>>>> (b) a standard git pull request, which includes shortlog, diffstat, and >>>>>> all-in-one diff. >>>>> >>>>> Thank you for the detailed explanation of the standard kernel submit >>>>> form (I wonder how would I know this otherwise :) but the thing is that >>>>> at the current moment I'm not submitting anything to the upstream. >>>> >>>> Ok, that explains my confusion, then. I had thought you intended to get >>>> this stuff upstream, and into users' hands. >>> >>> Interesting argument but the vast majority of users use distribution kernels >>> which are not upstream and I doubt that any self-respecting distribution would >>> miss such amount of fixes. >> >> Interesting argument, but applied across 1000+ developers this is >> clearly an unscalable development model for distributions. Thus, > > Interesting that you have brought distributions' convenience before > non-distribution developers' one. uhwhu? You brought up distributions. >> patches go upstream, and are then distributed widely, to eliminate >> massive amounts of duplicated work across distributions. >> >> You are essentially implying that each distribution must >> >> - discover your tree >> - look through the mailing list to figure out why each of >> ~80 changes are not upstream >> - individually make a decision on each of ~80 changes >> - actively track your tree for updates, repeating this process >> over and over again > > Not really. > > I'm only saying that the upstream is so much hassle to deal with it that > it is up to people wanting to see my changes upstream to do the work on > integrating them upstream if they want to see them in upstream faster. > > Fair enough? I respect your opinion, sure. And respect that your time is your own. And appreciate you spending that time to batch together some patches. But it is simple logic that a non-standard distribution method for your changes implies a self-imposed limited distribution, with possibly useful fixes and changes not getting into the hands of users that can use them. That's your choice -- but it surprised me, is all. Usually developers are more eager to get their changes into wide distribution, because that benefits the most Linux users. If you fail to send changes upstream, most people will assume that you do not consider your changes "ready" for users, "ready" for wide distribution and use. Because that is the common practice for nearly all other Linux kernel developers in all subsystems. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thursday 03 December 2009 10:16:15 pm Jeff Garzik wrote: > > pata_efar: MWDMA0 is unsupported > > skipped, pending discussion (just sent email) The discussion was there, you were not especially interested (http://lkml.org/lkml/2009/11/26/343). > > pata_hpt3x2n: fix overclocked MWDMA0 timing > > skipped, pending discussion (just sent email) ditto (http://lkml.org/lkml/2009/11/27/257). There were no complains so I'm pretty sure Sergei was fine with it. > > pata_hpt3x3: Power Management fix > > applied, on a hope and a prayer (did not see this posted to mailing > list?). It looks correct to me. I prefer sticking to technical facts. ;) Patch was posted to both mailing lists: http://lkml.org/lkml/2009/11/25/321 > > pata_via: clear UDMA transfer mode bit for PIO and MWDMA > > applied -- even though Alan's comment was correct. It is standard > kernel practice to place cosmetic changes into their own patches, > because it is standard kernel practice to break up logically distinct > changes. We are talking about: pata_via.c | 19 +++++++++++++------ 1 file changed, 13 insertions(+), 6 deletions(-) patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change is clearly documented in the patch description. Do people really wonder why I find upstream to be too much hassle to deal with? -- Bartlomiej Zolnierkiewicz -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/03/2009 04:42 PM, Bartlomiej Zolnierkiewicz wrote: > On Thursday 03 December 2009 10:16:15 pm Jeff Garzik wrote: > >>> pata_efar: MWDMA0 is unsupported >> >> skipped, pending discussion (just sent email) > > The discussion was there, you were not especially interested > (http://lkml.org/lkml/2009/11/26/343). I reviewed the discussion before adding an email to that thread. >>> pata_hpt3x2n: fix overclocked MWDMA0 timing >> >> skipped, pending discussion (just sent email) > > ditto (http://lkml.org/lkml/2009/11/27/257). I reviewed the discussion before adding an email to that thread. > There were no complains so I'm pretty sure Sergei was fine with it. It was unclear, hence I sent email for clarification. >>> pata_hpt3x3: Power Management fix >> >> applied, on a hope and a prayer (did not see this posted to mailing >> list?). It looks correct to me. > > I prefer sticking to technical facts. ;) > > Patch was posted to both mailing lists: http://lkml.org/lkml/2009/11/25/321 Whoops, I indeed missed this one. >>> pata_via: clear UDMA transfer mode bit for PIO and MWDMA >> >> applied -- even though Alan's comment was correct. It is standard >> kernel practice to place cosmetic changes into their own patches, >> because it is standard kernel practice to break up logically distinct >> changes. > > We are talking about: > > pata_via.c | 19 +++++++++++++------ > 1 file changed, 13 insertions(+), 6 deletions(-) > > patch here (http://lkml.org/lkml/2009/11/25/380) and cosmetic change > is clearly documented in the patch description. > > > Do people really wonder why I find upstream to be too much hassle to > deal with? The thousand other kernel developers seem to be able to split up their patches, separating out cosmetic changes from functional ones. It has clear engineering benefits, and has been standard practice for a decade or more. Why is it such an imposition for your patches to look like everyone else's? And by "everyone", I mean all other kernel developers, not just other ATA developers. You seem to consider standard kernel practice a hassle. Separating out cosmetic changes is not only a libata practice, it is the norm for the entire kernel. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello. Jeff Garzik wrote: >> pata_efar: MWDMA0 is unsupported > > skipped, pending discussion (just sent email) There's basically nothing to discuss -- the PIIX like chips don't support MWDMA0 (with an acceptable cycle length, if at all, anyway). The way the driver is written, MWDMA0 is simply programmed overclocked. > >> pata_hpt3x2n: fix overclocked MWDMA0 timing > > skipped, pending discussion (just sent email) Nothing to discuss either, this looks like a single digit typo to me... > >> pata_hpt3x3: Power Management fix > > applied, on a hope and a prayer (did not see this posted to mailing > list?). http://marc.info/?l=linux-ide&m=125916980522990 > >> pata_it8213: MWDMA0 is unsupported > > skipped, pending discussion (just sent email) Nothing to discuss... > pata_oldpiix: MWDMA0 is unsupported > > skipped -- Alan, Sergey, comments? Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> > >> pata_rdc: MWDMA0 is unsupported > > skipped -- Alan, Sergey, comments? Acked-by: Sergei Shtylyov <sshtylyov@ru.mvista.com> MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/03/2009 05:02 PM, Sergei Shtylyov wrote: > Hello. > > Jeff Garzik wrote: > >>> pata_efar: MWDMA0 is unsupported >> >> skipped, pending discussion (just sent email) > > There's basically nothing to discuss -- the PIIX like chips don't > support MWDMA0 (with an acceptable cycle length, if at all, anyway). The > way the driver is written, MWDMA0 is simply programmed overclocked. > >> >>> pata_hpt3x2n: fix overclocked MWDMA0 timing >> >> skipped, pending discussion (just sent email) > > > Nothing to discuss either, this looks like a single digit typo to me... > >> >>> pata_hpt3x3: Power Management fix >> >> applied, on a hope and a prayer (did not see this posted to mailing >> list?). > > http://marc.info/?l=linux-ide&m=125916980522990 Yeah, missed that. Bart provided a link, too. >>> pata_it8213: MWDMA0 is unsupported >> >> skipped, pending discussion (just sent email) > > Nothing to discuss... Perhaps discuss was the wrong word. After reviewing each thread, in each case, it remained unclear whether the original patch was correct or not, especially since the docs seemed to list MWDMA0 as supported on PIIX-like chips. Thanks for going over these, that should clear up my confusion. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 12/03/2009 04:16 PM, Jeff Garzik wrote: >> pata_efar: MWDMA0 is unsupported > > skipped, pending discussion (just sent email) applied, after merging into a single "PIIX no MWDMA0" patch >> pata_hpt3x2n: fix overclocked MWDMA0 timing > > skipped, pending discussion (just sent email) applied >> pata_it8213: MWDMA0 is unsupported > > skipped, pending discussion (just sent email) applied >> pata_oldpiix: MWDMA0 is unsupported > > skipped -- Alan, Sergey, comments? applied, after merging into a single "PIIX no MWDMA0" patch >> pata_rdc: MWDMA0 is unsupported > > skipped -- Alan, Sergey, comments? applied, after merging into a single "PIIX no MWDMA0" patch -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Likewise I'm happy with all of this stuff. My worry is the turn 32bit on for hardware without real testing/docs checking except where it was on by default bits. The rest is good stuff. The 32bit stuff for the unproven cards could do longer in -next as its only a performance boost for PIO. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> > pata_oldpiix: MWDMA0 is unsupported > > skipped -- Alan, Sergey, comments? Would need to look at the chip docs again. Certainly the ICH documents the lack of MWDMA. Dunno about the original PIIX. Rest looks sane, and that one probably is as the only way to to DMA0 appears to be with TIME0 clear. Unfortunately I can't lay my hands on a PIIX errata sheet right now. The PIIX4 programming tables don't list MWDMA0. The original PIIX datasheet clarifies one other point too For 32bit PIO it seems you must have bit 4 and 0 of IDETIM set for 32bit data port access. That is you cannot use 32bit PIO when TIME0/TIME1 are not set for that device. MPIIX fixes that restriction (no DMA but does have 32bit PIO for all modes) by inserting the needed mode 0 two clocks of CS deselect even if not visible on the ISA bus. The restriction is also not mentioned on PIIX4+ so presumably is specific to the original chip. -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 3 Dec 2009, Bartlomiej Zolnierkiewicz wrote: > On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote: >> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote: >>> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote: >>>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote: >>>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote: >>>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote: >>>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote: >>>>>>>> The merge window is upon us, which by strict rules means that anything >>>>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34. >>>>>>>> >>>>>>>> However, bug fixes and the like should definitely be in 2.6.33. >>>>>>>> ->init_host is definitely 2.6.34 material. Some of the other stuff >>>>>>>> could go either way. >>>>>> >>>>>>> If you would like to apply some of my patches to 2.6.33 you are more than >>>>>>> welcome to do it. I can even prepare separate git tree with specific changes >>>>>>> to make it easier for you once you tell me which changes you would like to >>>>>>> see in it. >>>>>> >>>>>> OK, great. >>>>>> >>>>>> Can you prepare a patchset containing only fixes? Comment-only changes >>>>>> are acceptable too. Trivial changes too, if they are extremely trivial :) >>>>>> >>>>>> Include nothing that adds features, removes or unifies drivers, etc. >>>>> >>>>> Since this is pretty high-level description and some changes fall into >>>>> many categories at once (i.e. addition of proper PCI Power Management >>>>> handling could be considered both as a fix and as a feature) I prepared >>>>> a rather conservative set of changes (which means that unfortunately >>>>> it misses many enhancements available in my tree): >>>>> >>>>>> Please do it in standard kernel submit form, which is either >>>>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or >>>>>> (b) a standard git pull request, which includes shortlog, diffstat, and >>>>>> all-in-one diff. >>>>> >>>>> Thank you for the detailed explanation of the standard kernel submit >>>>> form (I wonder how would I know this otherwise :) but the thing is that >>>>> at the current moment I'm not submitting anything to the upstream. >>>> >>>> Ok, that explains my confusion, then. I had thought you intended to get >>>> this stuff upstream, and into users' hands. >>> >>> Interesting argument but the vast majority of users use distribution kernels >>> which are not upstream and I doubt that any self-respecting distribution would >>> miss such amount of fixes. >> >> Interesting argument, but applied across 1000+ developers this is >> clearly an unscalable development model for distributions. Thus, > > Interesting that you have brought distributions' convenience before > non-distribution developers' one. and you are leaving those of us who use kernel.org out in the cold (forcing all non-distribution users to go through all the work that Jeff described) I'm not sure who you see as benifiting from this approach. David Lang -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Saturday 12 December 2009 03:02:43 am david@lang.hm wrote: > On Thu, 3 Dec 2009, Bartlomiej Zolnierkiewicz wrote: > > > On Thursday 03 December 2009 09:39:39 pm Jeff Garzik wrote: > >> On 12/03/2009 03:26 PM, Bartlomiej Zolnierkiewicz wrote: > >>> On Thursday 03 December 2009 09:11:19 pm Jeff Garzik wrote: > >>>> On 12/03/2009 02:45 PM, Bartlomiej Zolnierkiewicz wrote: > >>>>> On Thursday 03 December 2009 06:53:59 pm Jeff Garzik wrote: > >>>>>> On 12/03/2009 07:39 AM, Bartlomiej Zolnierkiewicz wrote: > >>>>>>> On Thursday 03 December 2009 09:07:41 am Jeff Garzik wrote: > >>>>>>>> The merge window is upon us, which by strict rules means that anything > >>>>>>>> not already in libata-dev.git#upstream needs to wait until 2.6.34. > >>>>>>>> > >>>>>>>> However, bug fixes and the like should definitely be in 2.6.33. > >>>>>>>> ->init_host is definitely 2.6.34 material. Some of the other stuff > >>>>>>>> could go either way. > >>>>>> > >>>>>>> If you would like to apply some of my patches to 2.6.33 you are more than > >>>>>>> welcome to do it. I can even prepare separate git tree with specific changes > >>>>>>> to make it easier for you once you tell me which changes you would like to > >>>>>>> see in it. > >>>>>> > >>>>>> OK, great. > >>>>>> > >>>>>> Can you prepare a patchset containing only fixes? Comment-only changes > >>>>>> are acceptable too. Trivial changes too, if they are extremely trivial :) > >>>>>> > >>>>>> Include nothing that adds features, removes or unifies drivers, etc. > >>>>> > >>>>> Since this is pretty high-level description and some changes fall into > >>>>> many categories at once (i.e. addition of proper PCI Power Management > >>>>> handling could be considered both as a fix and as a feature) I prepared > >>>>> a rather conservative set of changes (which means that unfortunately > >>>>> it misses many enhancements available in my tree): > >>>>> > >>>>>> Please do it in standard kernel submit form, which is either > >>>>>> (a) repost the patches (yes, again) being submitted for 2.6.33, or > >>>>>> (b) a standard git pull request, which includes shortlog, diffstat, and > >>>>>> all-in-one diff. > >>>>> > >>>>> Thank you for the detailed explanation of the standard kernel submit > >>>>> form (I wonder how would I know this otherwise :) but the thing is that > >>>>> at the current moment I'm not submitting anything to the upstream. > >>>> > >>>> Ok, that explains my confusion, then. I had thought you intended to get > >>>> this stuff upstream, and into users' hands. > >>> > >>> Interesting argument but the vast majority of users use distribution kernels > >>> which are not upstream and I doubt that any self-respecting distribution would > >>> miss such amount of fixes. > >> > >> Interesting argument, but applied across 1000+ developers this is > >> clearly an unscalable development model for distributions. Thus, > > > > Interesting that you have brought distributions' convenience before > > non-distribution developers' one. > > and you are leaving those of us who use kernel.org out in the cold > (forcing all non-distribution users to go through all the work that Jeff > described) [ ..and you believed it? ;) ] > I'm not sure who you see as benifiting from this approach. I'm not the maintainer of the affected code (according to MAINTAINERS at least PATA code is unmaintained and to add more confusion it has been in such state forever despite numerous claims of said code being the 'official' one ) so I think that you are barking at the wrong tree here.. Moreover the claim of forcing people to do the work was completely ridiculous (BTW all the changes happen in my own time) since I did/do a lot to make review/merge easier for people: - My tree is based on top of libata tree and stays up-to-date with it. - All changes have been posted to linux-ide and linux-kernel, and they had review concerns addressed already (there was only one real issue, Alan has noticed that scc_pata change is unnecessary). - I'm OK with providing additional branches with only selected changes to ease the merging process. -- Bartlomiej Zolnierkiewicz -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig index 676f08b..25cb4e7 100644 --- a/drivers/ata/Kconfig +++ b/drivers/ata/Kconfig @@ -287,8 +287,11 @@ config PATA_CMD640_PCI depends on PCI && EXPERIMENTAL help This option enables support for the CMD640 PCI IDE - interface chip. Only the primary channel is currently - supported. + interface chip. + + Known issues: + - only the primary channel is currently supported + - only the PCI chip interface is currently supported If unsure, say N. @@ -344,6 +347,9 @@ config PATA_CYPRESS This option enables support for the Cypress/Contaq CY82C693 chipset found in some Alpha systems + Known issues: + - only the primary channel is currently supported + If unsure, say N. config PATA_EFAR @@ -588,6 +594,10 @@ config PATA_PDC_OLD This option enables support for the Promise 20246, 20262, 20263, 20265 and 20267 adapters. + Known issues: + - UDMA transfers fail mysteriously on some chipsets + - ATAPI DMA is unsupported currently + If unsure, say N. config PATA_QDI diff --git a/drivers/ata/ata_piix.c b/drivers/ata/ata_piix.c index 9ac4e37..0c6155f 100644 --- a/drivers/ata/ata_piix.c +++ b/drivers/ata/ata_piix.c @@ -869,10 +869,10 @@ static void do_pata_set_dmamode(struct ata_port *ap, struct ata_device *adev, in (timings[pio][1] << 8); } - if (ap->udma_mask) { + if (ap->udma_mask) udma_enable &= ~(1 << devid); - pci_write_config_word(dev, master_port, master_data); - } + + pci_write_config_word(dev, master_port, master_data); } /* Don't scribble on 0x48 if the controller does not support UDMA */ if (ap->udma_mask) diff --git a/drivers/ata/pata_cs5520.c b/drivers/ata/pata_cs5520.c index 0df83cf..95ebdac 100644 --- a/drivers/ata/pata_cs5520.c +++ b/drivers/ata/pata_cs5520.c @@ -90,48 +90,12 @@ static void cs5520_set_timings(struct ata_port *ap, struct ata_device *adev, int } /** - * cs5520_enable_dma - turn on DMA bits - * - * Turn on the DMA bits for this disk. Needed because the BIOS probably - * has not done the work for us. Belongs in the core SATA code. - */ - -static void cs5520_enable_dma(struct ata_port *ap, struct ata_device *adev) -{ - /* Set the DMA enable/disable flag */ - u8 reg = ioread8(ap->ioaddr.bmdma_addr + 0x02); - reg |= 1<<(adev->devno + 5); - iowrite8(reg, ap->ioaddr.bmdma_addr + 0x02); -} - -/** - * cs5520_set_dmamode - program DMA timings - * @ap: ATA port - * @adev: ATA device - * - * Program the DMA mode timings for the controller according to the pio - * clocking table. Note that this device sets the DMA timings to PIO - * mode values. This may seem bizarre but the 5520 architecture talks - * PIO mode to the disk and DMA mode to the controller so the underlying - * transfers are PIO timed. - */ - -static void cs5520_set_dmamode(struct ata_port *ap, struct ata_device *adev) -{ - static const int dma_xlate[3] = { XFER_PIO_0, XFER_PIO_3, XFER_PIO_4 }; - cs5520_set_timings(ap, adev, dma_xlate[adev->dma_mode]); - cs5520_enable_dma(ap, adev); -} - -/** * cs5520_set_piomode - program PIO timings * @ap: ATA port * @adev: ATA device * * Program the PIO mode timings for the controller according to the pio - * clocking table. We know pio_mode will equal dma_mode because of the - * CS5520 architecture. At least once we turned DMA on and wrote a - * mode setter. + * clocking table. */ static void cs5520_set_piomode(struct ata_port *ap, struct ata_device *adev) @@ -149,7 +113,6 @@ static struct ata_port_operations cs5520_port_ops = { .qc_prep = ata_sff_dumb_qc_prep, .cable_detect = ata_cable_40wire, .set_piomode = cs5520_set_piomode, - .set_dmamode = cs5520_set_dmamode, }; static int __devinit cs5520_init_one(struct pci_dev *pdev, const struct pci_device_id *id) diff --git a/drivers/ata/pata_efar.c b/drivers/ata/pata_efar.c index 2a6412f..b2e71e6 100644 --- a/drivers/ata/pata_efar.c +++ b/drivers/ata/pata_efar.c @@ -2,6 +2,7 @@ * pata_efar.c - EFAR PIIX clone controller driver * * (C) 2005 Red Hat + * (C) 2009 Bartlomiej Zolnierkiewicz * * Some parts based on ata_piix.c by Jeff Garzik and others. * @@ -118,12 +119,12 @@ static void efar_set_piomode (struct ata_port *ap, struct ata_device *adev) int shift = 4 * ap->port_no; u8 slave_data; - idetm_data &= 0xCC0F; + idetm_data &= 0xFF0F; idetm_data |= (control << 4); /* Slave timing in separate register */ pci_read_config_byte(dev, 0x44, &slave_data); - slave_data &= 0x0F << shift; + slave_data &= ap->port_no ? 0x0F : 0xF0; slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << shift; pci_write_config_byte(dev, 0x44, slave_data); } @@ -200,7 +201,7 @@ static void efar_set_dmamode (struct ata_port *ap, struct ata_device *adev) master_data &= 0xFF4F; /* Mask out IORDY|TIME1|DMAONLY */ master_data |= control << 4; pci_read_config_byte(dev, 0x44, &slave_data); - slave_data &= (0x0F + 0xE1 * ap->port_no); + slave_data &= ap->port_no ? 0x0F : 0xF0; /* Load the matching timing */ slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0); pci_write_config_byte(dev, 0x44, slave_data); @@ -251,7 +252,7 @@ static int efar_init_one (struct pci_dev *pdev, const struct pci_device_id *ent) static const struct ata_port_info info = { .flags = ATA_FLAG_SLAVE_POSS, .pio_mask = ATA_PIO4, - .mwdma_mask = ATA_MWDMA2, + .mwdma_mask = ATA_MWDMA12_ONLY, .udma_mask = ATA_UDMA4, .port_ops = &efar_ops, }; diff --git a/drivers/ata/pata_hpt3x2n.c b/drivers/ata/pata_hpt3x2n.c index d30da80..9a09a1b 100644 --- a/drivers/ata/pata_hpt3x2n.c +++ b/drivers/ata/pata_hpt3x2n.c @@ -80,14 +80,13 @@ static struct hpt_clock hpt3x2n_clocks[] = { { XFER_MW_DMA_2, 0x2c829c62 }, { XFER_MW_DMA_1, 0x2c829c66 }, - { XFER_MW_DMA_0, 0x2c829d2c }, + { XFER_MW_DMA_0, 0x2c829d2e }, { XFER_PIO_4, 0x0c829c62 }, { XFER_PIO_3, 0x0c829c84 }, { XFER_PIO_2, 0x0c829ca6 }, { XFER_PIO_1, 0x0d029d26 }, { XFER_PIO_0, 0x0d029d5e }, - { 0, 0x0d029d5e } }; /** diff --git a/drivers/ata/pata_hpt3x3.c b/drivers/ata/pata_hpt3x3.c index 7e31025..c86c716 100644 --- a/drivers/ata/pata_hpt3x3.c +++ b/drivers/ata/pata_hpt3x3.c @@ -255,8 +255,17 @@ static int hpt3x3_init_one(struct pci_dev *pdev, const struct pci_device_id *id) #ifdef CONFIG_PM static int hpt3x3_reinit_one(struct pci_dev *dev) { + struct ata_host *host = dev_get_drvdata(&dev->dev); + int rc; + + rc = ata_pci_device_do_resume(dev); + if (rc) + return rc; + hpt3x3_init_chipset(dev); - return ata_pci_device_resume(dev); + + ata_host_resume(host); + return 0; } #endif diff --git a/drivers/ata/pata_it8213.c b/drivers/ata/pata_it8213.c index f156da8..8f3325a 100644 --- a/drivers/ata/pata_it8213.c +++ b/drivers/ata/pata_it8213.c @@ -22,7 +22,7 @@ #define DRV_VERSION "0.0.3" /** - * it8213_pre_reset - check for 40/80 pin + * it8213_pre_reset - probe begin * @link: link * @deadline: deadline jiffies for the operation * @@ -92,18 +92,17 @@ static void it8213_set_piomode (struct ata_port *ap, struct ata_device *adev) { 2, 1 }, { 2, 3 }, }; - if (pio > 2) - control |= 1; /* TIME1 enable */ + if (pio > 1) + control |= 1; /* TIME */ if (ata_pio_need_iordy(adev)) /* PIO 3/4 require IORDY */ - control |= 2; /* IORDY enable */ + control |= 2; /* IE */ /* Bit 2 is set for ATAPI on the IT8213 - reverse of ICH/PIIX */ if (adev->class != ATA_DEV_ATA) - control |= 4; + control |= 4; /* PPE */ pci_read_config_word(dev, idetm_port, &idetm_data); - /* Enable PPE, IE and TIME as appropriate */ - + /* Set PPE, IE, and TIME as appropriate */ if (adev->devno == 0) { idetm_data &= 0xCCF0; idetm_data |= control; @@ -112,17 +111,17 @@ static void it8213_set_piomode (struct ata_port *ap, struct ata_device *adev) } else { u8 slave_data; - idetm_data &= 0xCC0F; + idetm_data &= 0xFF0F; idetm_data |= (control << 4); /* Slave timing in separate register */ pci_read_config_byte(dev, 0x44, &slave_data); slave_data &= 0xF0; - slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << 4; + slave_data |= (timings[pio][0] << 2) | timings[pio][1]; pci_write_config_byte(dev, 0x44, slave_data); } - idetm_data |= 0x4000; /* Ensure SITRE is enabled */ + idetm_data |= 0x4000; /* Ensure SITRE is set */ pci_write_config_word(dev, idetm_port, idetm_data); } @@ -173,10 +172,10 @@ static void it8213_set_dmamode (struct ata_port *ap, struct ata_device *adev) udma_enable |= (1 << devid); - /* Load the UDMA mode number */ + /* Load the UDMA cycle time */ pci_read_config_word(dev, 0x4A, &udma_timing); udma_timing &= ~(3 << (4 * devid)); - udma_timing |= (udma & 3) << (4 * devid); + udma_timing |= u_speed << (4 * devid); pci_write_config_word(dev, 0x4A, udma_timing); /* Load the clock selection */ @@ -211,7 +210,7 @@ static void it8213_set_dmamode (struct ata_port *ap, struct ata_device *adev) master_data &= 0xFF4F; /* Mask out IORDY|TIME1|DMAONLY */ master_data |= control << 4; pci_read_config_byte(dev, 0x44, &slave_data); - slave_data &= (0x0F + 0xE1 * ap->port_no); + slave_data &= 0xF0; /* Load the matching timing */ slave_data |= ((timings[pio][0] << 2) | timings[pio][1]) << (ap->port_no ? 4 : 0); pci_write_config_byte(dev, 0x44, slave_data); @@ -263,7 +262,7 @@ static int it8213_init_one (struct pci_dev *pdev, const struct pci_device_id *en static const struct ata_port_info info = { .flags = ATA_FLAG_SLAVE_POSS, .pio_mask = ATA_PIO4, - .mwdma_mask = ATA_MWDMA2, + .mwdma_mask = ATA_MWDMA12_ONLY, .udma_mask = ATA_UDMA4, /* FIXME: want UDMA 100? */ .port_ops = &it8213_ops, }; diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c index 6932e56..9df1ff7 100644 --- a/drivers/ata/pata_legacy.c +++ b/drivers/ata/pata_legacy.c @@ -25,6 +25,13 @@ * http://www.ryston.cz/petr/vlb/pdc20230b.html * http://www.ryston.cz/petr/vlb/pdc20230c.html * http://www.ryston.cz/petr/vlb/pdc20630.html + * QDI65x0: + * http://www.ryston.cz/petr/vlb/qd6500.html + * http://www.ryston.cz/petr/vlb/qd6580.html + * + * QDI65x0 probe code based on drivers/ide/legacy/qd65xx.c + * Rewritten from the work of Colten Edwards <pje120@cs.usask.ca> by + * Samuel Thibault <samuel.thibault@ens-lyon.org> * * Unsupported but docs exist: * Appian/Adaptec AIC25VL01/Cirrus Logic PD7220 @@ -35,7 +42,7 @@ * the MPIIX where the tuning is PCI side but the IDE is "ISA side". * * Specific support is included for the ht6560a/ht6560b/opti82c611a/ - * opti82c465mv/promise 20230c/20630/winbond83759A + * opti82c465mv/promise 20230c/20630/qdi65x0/winbond83759A * * Use the autospeed and pio_mask options with: * Appian ADI/2 aka CLPD7220 or AIC25VL01. @@ -672,7 +679,7 @@ static void qdi6580dp_set_piomode(struct ata_port *ap, struct ata_device *adev) outb(timing, ld_qdi->timing + 2 * ap->port_no); /* Clear the FIFO */ if (adev->class != ATA_DEV_ATA) - outb(0x5F, ld_qdi->timing + 3); + outb(0x5F, (ld_qdi->timing & 0xFFF0) + 3); } /** @@ -707,7 +714,7 @@ static void qdi6580_set_piomode(struct ata_port *ap, struct ata_device *adev) outb(timing, ld_qdi->timing + 2 * adev->devno); /* Clear the FIFO */ if (adev->class != ATA_DEV_ATA) - outb(0x5F, ld_qdi->timing + 3); + outb(0x5F, (ld_qdi->timing & 0xFFF0) + 3); } /** @@ -787,6 +794,7 @@ static struct ata_port_operations qdi6580_port_ops = { static struct ata_port_operations qdi6580dp_port_ops = { .inherits = &legacy_base_port_ops, .set_piomode = qdi6580dp_set_piomode, + .qc_issue = qdi_qc_issue, .sff_data_xfer = vlb32_data_xfer, }; diff --git a/drivers/ata/pata_marvell.c b/drivers/ata/pata_marvell.c index 2096fb7..950da39 100644 --- a/drivers/ata/pata_marvell.c +++ b/drivers/ata/pata_marvell.c @@ -58,7 +58,7 @@ static int marvell_pata_active(struct pci_dev *pdev) } /** - * marvell_pre_reset - check for 40/80 pin + * marvell_pre_reset - probe begin * @link: link * @deadline: deadline jiffies for the operation * diff --git a/drivers/ata/pata_ns87415.c b/drivers/ata/pata_ns87415.c index 773b159..061aa1c 100644 --- a/drivers/ata/pata_ns87415.c +++ b/drivers/ata/pata_ns87415.c @@ -325,6 +325,13 @@ static struct scsi_host_template ns87415_sht = { ATA_BMDMA_SHT(DRV_NAME), }; +static void ns87415_fixup(struct pci_dev *pdev) +{ + /* Select 512 byte sectors */ + pci_write_config_byte(pdev, 0x55, 0xEE); + /* Select PIO0 8bit clocking */ + pci_write_config_byte(pdev, 0x54, 0xB7); +} /** * ns87415_init_one - Register 87415 ATA PCI device with kernel services @@ -371,10 +378,8 @@ static int ns87415_init_one (struct pci_dev *pdev, const struct pci_device_id *e if (rc) return rc; - /* Select 512 byte sectors */ - pci_write_config_byte(pdev, 0x55, 0xEE); - /* Select PIO0 8bit clocking */ - pci_write_config_byte(pdev, 0x54, 0xB7); + ns87415_fixup(pdev); + return ata_pci_sff_init_one(pdev, ppi, &ns87415_sht, NULL); } @@ -384,6 +389,23 @@ static const struct pci_device_id ns87415_pci_tbl[] = { { } /* terminate list */ }; +#ifdef CONFIG_PM +static int ns87415_reinit_one(struct pci_dev *pdev) +{ + struct ata_host *host = dev_get_drvdata(&pdev->dev); + int rc; + + rc = ata_pci_device_do_resume(pdev); + if (rc) + return rc; + + ns87415_fixup(pdev); + + ata_host_resume(host); + return 0; +} +#endif + static struct pci_driver ns87415_pci_driver = { .name = DRV_NAME, .id_table = ns87415_pci_tbl, @@ -391,7 +413,7 @@ static struct pci_driver ns87415_pci_driver = { .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = ata_pci_device_resume, + .resume = ns87415_reinit_one, #endif }; diff --git a/drivers/ata/pata_oldpiix.c b/drivers/ata/pata_oldpiix.c index 84ac503..9a8687d 100644 --- a/drivers/ata/pata_oldpiix.c +++ b/drivers/ata/pata_oldpiix.c @@ -239,7 +239,7 @@ static int oldpiix_init_one (struct pci_dev *pdev, const struct pci_device_id *e static const struct ata_port_info info = { .flags = ATA_FLAG_SLAVE_POSS, .pio_mask = ATA_PIO4, - .mwdma_mask = ATA_MWDMA2, + .mwdma_mask = ATA_MWDMA12_ONLY, .port_ops = &oldpiix_pata_ops, }; const struct ata_port_info *ppi[] = { &info, NULL }; diff --git a/drivers/ata/pata_radisys.c b/drivers/ata/pata_radisys.c index 4401b33..4fd25e7 100644 --- a/drivers/ata/pata_radisys.c +++ b/drivers/ata/pata_radisys.c @@ -139,9 +139,9 @@ static void radisys_set_dmamode (struct ata_port *ap, struct ata_device *adev) pci_read_config_byte(dev, 0x4A, &udma_mode); if (adev->xfer_mode == XFER_UDMA_2) - udma_mode &= ~ (1 << adev->devno); + udma_mode &= ~(2 << (adev->devno * 4)); else /* UDMA 4 */ - udma_mode |= (1 << adev->devno); + udma_mode |= (2 << (adev->devno * 4)); pci_write_config_byte(dev, 0x4A, udma_mode); diff --git a/drivers/ata/pata_rdc.c b/drivers/ata/pata_rdc.c index c843a1e..237a24d 100644 --- a/drivers/ata/pata_rdc.c +++ b/drivers/ata/pata_rdc.c @@ -284,7 +284,7 @@ static struct ata_port_info rdc_port_info = { .flags = ATA_FLAG_SLAVE_POSS, .pio_mask = ATA_PIO4, - .mwdma_mask = ATA_MWDMA2, + .mwdma_mask = ATA_MWDMA12_ONLY, .udma_mask = ATA_UDMA5, .port_ops = &rdc_pata_ops, }; diff --git a/drivers/ata/pata_rz1000.c b/drivers/ata/pata_rz1000.c index a5e4dfe..2932998 100644 --- a/drivers/ata/pata_rz1000.c +++ b/drivers/ata/pata_rz1000.c @@ -105,11 +105,20 @@ static int rz1000_init_one (struct pci_dev *pdev, const struct pci_device_id *en #ifdef CONFIG_PM static int rz1000_reinit_one(struct pci_dev *pdev) { + struct ata_host *host = dev_get_drvdata(&pdev->dev); + int rc; + + rc = ata_pci_device_do_resume(pdev); + if (rc) + return rc; + /* If this fails on resume (which is a "cant happen" case), we must stop as any progress risks data loss */ if (rz1000_fifo_disable(pdev)) panic("rz1000 fifo"); - return ata_pci_device_resume(pdev); + + ata_host_resume(host); + return 0; } #endif diff --git a/drivers/ata/pata_sis.c b/drivers/ata/pata_sis.c index d70ecec..8af0dc8 100644 --- a/drivers/ata/pata_sis.c +++ b/drivers/ata/pata_sis.c @@ -2,7 +2,7 @@ * pata_sis.c - SiS ATA driver * * (C) 2005 Red Hat - * (C) 2007 Bartlomiej Zolnierkiewicz + * (C) 2007,2009 Bartlomiej Zolnierkiewicz * * Based upon linux/drivers/ide/pci/sis5513.c * Copyright (C) 1999-2000 Andre Hedrick <andre@linux-ide.org> @@ -876,6 +876,23 @@ static int sis_init_one (struct pci_dev *pdev, const struct pci_device_id *ent) return ata_pci_sff_init_one(pdev, ppi, &sis_sht, chipset); } +#ifdef CONFIG_PM +static int sis_reinit_one(struct pci_dev *pdev) +{ + struct ata_host *host = dev_get_drvdata(&pdev->dev); + int rc; + + rc = ata_pci_device_do_resume(pdev); + if (rc) + return rc; + + sis_fixup(pdev, host->private_data); + + ata_host_resume(host); + return 0; +} +#endif + static const struct pci_device_id sis_pci_tbl[] = { { PCI_VDEVICE(SI, 0x5513), }, /* SiS 5513 */ { PCI_VDEVICE(SI, 0x5518), }, /* SiS 5518 */ @@ -891,7 +908,7 @@ static struct pci_driver sis_pci_driver = { .remove = ata_pci_remove_one, #ifdef CONFIG_PM .suspend = ata_pci_device_suspend, - .resume = ata_pci_device_resume, + .resume = sis_reinit_one, #endif }; diff --git a/drivers/ata/pata_via.c b/drivers/ata/pata_via.c index 78eac27..0d97890 100644 --- a/drivers/ata/pata_via.c +++ b/drivers/ata/pata_via.c @@ -303,14 +303,21 @@ static void via_do_set_mode(struct ata_port *ap, struct ata_device *adev, int mo } /* Set UDMA unless device is not UDMA capable */ - if (udma_type && t.udma) { - u8 cable80_status; + if (udma_type) { + u8 udma_etc; - /* Get 80-wire cable detection bit */ - pci_read_config_byte(pdev, 0x50 + offset, &cable80_status); - cable80_status &= 0x10; + pci_read_config_byte(pdev, 0x50 + offset, &udma_etc); - pci_write_config_byte(pdev, 0x50 + offset, ut | cable80_status); + /* clear transfer mode bit */ + udma_etc &= ~0x20; + + if (t.udma) { + /* preserve 80-wire cable detection bit */ + udma_etc &= 0x10; + udma_etc |= ut; + } + + pci_write_config_byte(pdev, 0x50 + offset, udma_etc); } } diff --git a/drivers/ide/ide-pci-generic.c b/drivers/ide/ide-pci-generic.c index 3f0bc42..a743e68 100644 --- a/drivers/ide/ide-pci-generic.c +++ b/drivers/ide/ide-pci-generic.c @@ -165,7 +165,7 @@ static const struct pci_device_id generic_pci_tbl[] = { { PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_1), 4 }, { PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_2), 4 }, { PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_3), 4 }, - { PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_5) 4 }, + { PCI_VDEVICE(TOSHIBA, PCI_DEVICE_ID_TOSHIBA_PICCOLO_5), 4 }, { PCI_VDEVICE(NETCELL, PCI_DEVICE_ID_REVOLUTION), 6 }, /* * Must come last. If you add entries adjust