Re: MMCv4 support (8-bit support missing)
Hi Pierre/Philip, I've looked through the MMC 4.2 spec and I see nothing in it that even hints that 8-bit support might be optional. So as it stands, the bus testing is still out. Okay. Its possible that my understanding was wrong in the sense that I thought bus testing procedure is mandatory to support 8-bit cards. If 8-bit is mandatory for MMC4 cards, then the changes required in the MMC core to support 8-bit might be simple. Based on host controller cap this can be handled. Philip asked me about the access to the 8-bit controller. We might not be able to provide you direct access to the hardware platform as it requires involvement of business managers and so on. But can I be of help by testing your code on our platform and leting you know the results? Regards, Madhu On 4/24/07, Pierre Ossman <[EMAIL PROTECTED]> wrote: Madhusudhan c wrote: > > Suppose a host controller is capable of suporting 8-bit and it tells > the core that it can support 8-bit. Now the card that is plugged in > might or might not support 8-bit based on the type of the card. There > is no field in the ext_csd which will tell you what bus width the card > can support. > I've looked through the MMC 4.2 spec and I see nothing in it that even hints that 8-bit support might be optional. So as it stands, the bus testing is still out. Rgds Pierre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MMCv4 support (8-bit support missing)
Hi Pierre/Philip, I've looked through the MMC 4.2 spec and I see nothing in it that even hints that 8-bit support might be optional. So as it stands, the bus testing is still out. Okay. Its possible that my understanding was wrong in the sense that I thought bus testing procedure is mandatory to support 8-bit cards. If 8-bit is mandatory for MMC4 cards, then the changes required in the MMC core to support 8-bit might be simple. Based on host controller cap this can be handled. Philip asked me about the access to the 8-bit controller. We might not be able to provide you direct access to the hardware platform as it requires involvement of business managers and so on. But can I be of help by testing your code on our platform and leting you know the results? Regards, Madhu On 4/24/07, Pierre Ossman [EMAIL PROTECTED] wrote: Madhusudhan c wrote: Suppose a host controller is capable of suporting 8-bit and it tells the core that it can support 8-bit. Now the card that is plugged in might or might not support 8-bit based on the type of the card. There is no field in the ext_csd which will tell you what bus width the card can support. I've looked through the MMC 4.2 spec and I see nothing in it that even hints that 8-bit support might be optional. So as it stands, the bus testing is still out. Rgds Pierre - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MMCv4 support (8-bit support missing)
Hi Perre, Until 8-bit SD shows up, at which point things go to hell again. You need to present a valid case for why we need this bus testing stuff. The spec never requires it, and neither does any cards. So this is just crud that we know causes problems and doesn't give us anything back. Okay. Let me try to explain a scenario where it is required. Suppose a host controller is capable of suporting 8-bit and it tells the core that it can support 8-bit. Now the card that is plugged in might or might not support 8-bit based on the type of the card. There is no field in the ext_csd which will tell you what bus width the card can support. So you need first try to setup 8-bit and send a patteren on the data lines and read it back. If you get back the expected data then you are good to go in 8-bit. Else, shift to 4-bit and try again with the data patteren to see if four bit works. This is how the patch is implemented. Also the spec says that you need to perform bus test procedure before sending the switch command to set the bus width. By doing this you can figure out whether the card supports 8-bit or not. And this is the only way to support 8-bit cards, which are widely available in the market today. Also if the host controler says it can only support 4-bit then no need of bus testing procedure.Ignoring the bus test procedure does not affect you to functionally support 4-bit but there is no way you can support 8-bit cards without it correctly. Regards, Madhu On 4/19/07, Pierre Ossman <[EMAIL PROTECTED]> wrote: Madhusudhan c wrote: > > The bus test procedure from this patch can be adopted to the MMCv4 > support in the MMC core with small changes to do bus testing procedure > only if the host sets the capability to support 8-bit. That way we > dont break the legacy code. What do you think? > Until 8-bit SD shows up, at which point things go to hell again. You need to present a valid case for why we need this bus testing stuff. The spec never requires it, and neither does any cards. So this is just crud that we know causes problems and doesn't give us anything back. Rgds Pierre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MMCv4 support (8-bit support missing)
Hi Perre, I don't think I've seen that patch. And now we have the work by Philip and myself which adds support for both MMC 4.0 and 4.2. The only missing piece is 8-bit data and I'm not that interested in adding it until we have a driver that can use it. Here is a link to that patch. http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3489/1 The bus test procedure from this patch can be adopted to the MMCv4 support in the MMC core with small changes to do bus testing procedure only if the host sets the capability to support 8-bit. That way we dont break the legacy code. What do you think? On 4/18/07, Pierre Ossman <[EMAIL PROTECTED]> wrote: Madhusudhan c wrote: > > Kyung-ju Hyun from samsung had submitted a patch for MMCPlus support > long back, which had the bus testing procedure implemented and it > works fine. I am able to write and read the data pattern back > successfuly with his patch. I am not sure why his patch was not > integrated into the main line kernel. > I don't think I've seen that patch. And now we have the work by Philip and myself which adds support for both MMC 4.0 and 4.2. The only missing piece is 8-bit data and I'm not that interested in adding it until we have a driver that can use it. > Why should we be bothered about how controllers respond at the MMC > core level. We need to just implement what specification says and > leave the controller handling part to the controller driver. Am I > correct? Kindof. The controller drivers should indeed just handle the controller and leave the protocol stuff to the mmc core. The problem is that this bus testing stuff breaks the previous standards. Sending invalid CRC was not previously a supported operation, so many controllers just toss the data when that happens. And since the bus testing is specified as a test, not a required part of the wide bus song and dance, we've decided to leave it out. Rgds Pierre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MMCv4 support (8-bit support missing)
Hi Perre, I don't think I've seen that patch. And now we have the work by Philip and myself which adds support for both MMC 4.0 and 4.2. The only missing piece is 8-bit data and I'm not that interested in adding it until we have a driver that can use it. Here is a link to that patch. http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=3489/1 The bus test procedure from this patch can be adopted to the MMCv4 support in the MMC core with small changes to do bus testing procedure only if the host sets the capability to support 8-bit. That way we dont break the legacy code. What do you think? On 4/18/07, Pierre Ossman [EMAIL PROTECTED] wrote: Madhusudhan c wrote: Kyung-ju Hyun from samsung had submitted a patch for MMCPlus support long back, which had the bus testing procedure implemented and it works fine. I am able to write and read the data pattern back successfuly with his patch. I am not sure why his patch was not integrated into the main line kernel. I don't think I've seen that patch. And now we have the work by Philip and myself which adds support for both MMC 4.0 and 4.2. The only missing piece is 8-bit data and I'm not that interested in adding it until we have a driver that can use it. Why should we be bothered about how controllers respond at the MMC core level. We need to just implement what specification says and leave the controller handling part to the controller driver. Am I correct? Kindof. The controller drivers should indeed just handle the controller and leave the protocol stuff to the mmc core. The problem is that this bus testing stuff breaks the previous standards. Sending invalid CRC was not previously a supported operation, so many controllers just toss the data when that happens. And since the bus testing is specified as a test, not a required part of the wide bus song and dance, we've decided to leave it out. Rgds Pierre - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MMCv4 support (8-bit support missing)
Hi Perre/Philip, Feel free to add me as cc in the future if you want me to notice your mail ;) Sure. In fact I looked around to find your email id and did not find it. In future I will include you in cc. We haven't determined it as necessary, and as Philip commented, most (if not all) controllers cannot properly support the test. The MMCA spec 4.1 has the below two lines of explaination in the Bus testing procedure section. 1. "The data pattern sent by the host may optionally include a CRC16 checksum, which is ignored by the card." 2. "The reverse data pattern sent by the card may optionally include a CRC16 checksum, which is ignored by the host." I faced a simillar problem as philip mentioned on our hardware. I used to see failures on CMD19. I used to get a "Data timeout" interrupt. After speaking to our hardware folks, we got it working. The hardware folks suggested me to do a soft reset of the data lines upon receiving the DTO for CMD19.Our controller has a bit in the MMC registers to soft reset the data lines. It solved the problem. So I expect their may be simillar stuff on other controllers as well. Kyung-ju Hyun from samsung had submitted a patch for MMCPlus support long back, which had the bus testing procedure implemented and it works fine. I am able to write and read the data pattern back successfuly with his patch. I am not sure why his patch was not integrated into the main line kernel. Why should we be bothered about how controllers respond at the MMC core level. We need to just implement what specification says and leave the controller handling part to the controller driver. Am I correct? Regards, Madhusudhan On 4/18/07, Pierre Ossman <[EMAIL PROTECTED]> wrote: Madhusudhan c wrote: > Hi Pierre/philip, > Hi Madhusudhan, Feel free to add me as cc in the future if you want me to notice your mail ;) > This is regarding the MMCv4 support that came in as part of the MMC > core of 2.6.20 linux kernel version. > > The high speed MMC cards can support 4-bit/8-bit transfers. The 8-bit > support seems to be missing from the MMCv4 support implemented by > Philip Langdale . As soon as hardware with specs is available we'll start hacking. :) > To support 8-bit transfers the core needs to implement "bus testing > procedure". This requires support for CMD19 and CMD14. > > Why is the support for bus testing procedure msiing from the MMCv4 support? > We haven't determined it as necessary, and as Philip commented, most (if not all) controllers cannot properly support the test. Rgds Pierre - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MMCv4 support (8-bit support missing)
Hi Perre/Philip, Feel free to add me as cc in the future if you want me to notice your mail ;) Sure. In fact I looked around to find your email id and did not find it. In future I will include you in cc. We haven't determined it as necessary, and as Philip commented, most (if not all) controllers cannot properly support the test. The MMCA spec 4.1 has the below two lines of explaination in the Bus testing procedure section. 1. The data pattern sent by the host may optionally include a CRC16 checksum, which is ignored by the card. 2. The reverse data pattern sent by the card may optionally include a CRC16 checksum, which is ignored by the host. I faced a simillar problem as philip mentioned on our hardware. I used to see failures on CMD19. I used to get a Data timeout interrupt. After speaking to our hardware folks, we got it working. The hardware folks suggested me to do a soft reset of the data lines upon receiving the DTO for CMD19.Our controller has a bit in the MMC registers to soft reset the data lines. It solved the problem. So I expect their may be simillar stuff on other controllers as well. Kyung-ju Hyun from samsung had submitted a patch for MMCPlus support long back, which had the bus testing procedure implemented and it works fine. I am able to write and read the data pattern back successfuly with his patch. I am not sure why his patch was not integrated into the main line kernel. Why should we be bothered about how controllers respond at the MMC core level. We need to just implement what specification says and leave the controller handling part to the controller driver. Am I correct? Regards, Madhusudhan On 4/18/07, Pierre Ossman [EMAIL PROTECTED] wrote: Madhusudhan c wrote: Hi Pierre/philip, Hi Madhusudhan, Feel free to add me as cc in the future if you want me to notice your mail ;) This is regarding the MMCv4 support that came in as part of the MMC core of 2.6.20 linux kernel version. The high speed MMC cards can support 4-bit/8-bit transfers. The 8-bit support seems to be missing from the MMCv4 support implemented by Philip Langdale . As soon as hardware with specs is available we'll start hacking. :) To support 8-bit transfers the core needs to implement bus testing procedure. This requires support for CMD19 and CMD14. Why is the support for bus testing procedure msiing from the MMCv4 support? We haven't determined it as necessary, and as Philip commented, most (if not all) controllers cannot properly support the test. Rgds Pierre - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
MMCv4 support (8-bit support missing)
Hi Pierre/philip, This is regarding the MMCv4 support that came in as part of the MMC core of 2.6.20 linux kernel version. The high speed MMC cards can support 4-bit/8-bit transfers. The 8-bit support seems to be missing from the MMCv4 support implemented by Philip Langdale . To support 8-bit transfers the core needs to implement "bus testing procedure". This requires support for CMD19 and CMD14. Why is the support for bus testing procedure msiing from the MMCv4 support? Regards, Madhu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
MMCv4 support (8-bit support missing)
Hi Pierre/philip, This is regarding the MMCv4 support that came in as part of the MMC core of 2.6.20 linux kernel version. The high speed MMC cards can support 4-bit/8-bit transfers. The 8-bit support seems to be missing from the MMCv4 support implemented by Philip Langdale . To support 8-bit transfers the core needs to implement bus testing procedure. This requires support for CMD19 and CMD14. Why is the support for bus testing procedure msiing from the MMCv4 support? Regards, Madhu - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/