From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756463AbcHYPu2 (ORCPT ); Thu, 25 Aug 2016 11:50:28 -0400 Received: from www381.your-server.de ([78.46.137.84]:44897 "EHLO www381.your-server.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751664AbcHYPu0 (ORCPT ); Thu, 25 Aug 2016 11:50:26 -0400 Subject: Re: [PATCH 1/2] sdhci-of-arasan: Add quirk and device tree parameter to fake CD bit To: =?UTF-8?Q?S=c3=b6ren_Brinkmann?= References: <1472080984-17373-1-git-send-email-zach.brown@ni.com> <20160825151047.GO16583@xsjsorenbubuntu> <20160825152944.GP16583@xsjsorenbubuntu> Cc: Zach Brown , mark.rutland@arm.com, devicetree@vger.kernel.org, ulf.hansson@linaro.org, linux-mmc@vger.kernel.org, adrian.hunter@intel.com, linux-kernel@vger.kernel.org, robh+dt@kernel.org, michal.simek@xilinx.com, linux-arm-kernel@lists.infradead.org From: Lars-Peter Clausen X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 25 Aug 2016 17:50:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160825152944.GP16583@xsjsorenbubuntu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Authenticated-Sender: lars@metafoo.de Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/25/2016 05:29 PM, Sören Brinkmann wrote: > On Thu, 2016-08-25 at 17:23:47 +0200, Lars-Peter Clausen wrote: >> On 08/25/2016 05:10 PM, Sören Brinkmann wrote: >>> On Wed, 2016-08-24 at 18:23:03 -0500, Zach Brown wrote: >>>> The sdhci controller on xilinx zynq devices will not function unless >>>> the cd bit is provided. http://www.xilinx.com/support/answers/61064.html >>>> In cases where it is impossible to provide the cd bit in hardware, >>>> setting the controller to test mode and then setting inserted to true >>>> will get the controller to function with out the cd bit. >>>> >>>> The device property "fake-cd" will let the arasan driver know it needs >>>> to fake the cd bit for the controller inorder for the controller to >>>> function with a SD card that does not provide the CD bit. >>> >>> I thought the CD is, if not pinned out, tied off to some valid logic >>> level. Isn't it enough to specify cd-inverted if needed to make it work >>> in those cases? >> >> It is always brought out to some pin, that is the problem on the Zynq. This >> means you'd have to set at least one pin aside as dummy CD or WP pin. Which >> is not always possible when you are tight on available pins. > > I have to admit that I haven't looked at Vivado for quite a while. Is it > possible to select EMIO for those pins? If those are not routed anything > they should be tied to some logic level, I believe. > If they are always forced to be on a physical pin, do you let that pin > just float? Otherwise, the logic level should also be defined, give and > take a logic inversion. Yes, it is possible to source them from EMIO. We had the same issue with WP on one of our boards and the routing to EMIO approach was one of the solutions I considered. But I could not find documentation on whether and how the pins are tied when the FPGA is not configured or what happens during reconfiguration, is there a chance of glitches. So I went with the software solution of specifying disable-wp for the slot instead. But even if using EMIO works I think correctly describing the hardware, which is that there is no external WP or CD pin connected, is the better approach rather than playing around with invert flags, which has a different semantical meaning. Software can than work with that information and take the approach it is best to handle the situation. And this approach might change if we find better ways to handle it, whereas the hardware description stays static. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lars-Peter Clausen Subject: Re: [PATCH 1/2] sdhci-of-arasan: Add quirk and device tree parameter to fake CD bit Date: Thu, 25 Aug 2016 17:50:16 +0200 Message-ID: References: <1472080984-17373-1-git-send-email-zach.brown@ni.com> <20160825151047.GO16583@xsjsorenbubuntu> <20160825152944.GP16583@xsjsorenbubuntu> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Return-path: In-Reply-To: <20160825152944.GP16583@xsjsorenbubuntu> Sender: devicetree-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: =?UTF-8?Q?S=c3=b6ren_Brinkmann?= Cc: Zach Brown , mark.rutland-5wv7dgnIgG8@public.gmane.org, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, adrian.hunter-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org, michal.simek-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org List-Id: devicetree@vger.kernel.org On 08/25/2016 05:29 PM, Sören Brinkmann wrote: > On Thu, 2016-08-25 at 17:23:47 +0200, Lars-Peter Clausen wrote: >> On 08/25/2016 05:10 PM, Sören Brinkmann wrote: >>> On Wed, 2016-08-24 at 18:23:03 -0500, Zach Brown wrote: >>>> The sdhci controller on xilinx zynq devices will not function unless >>>> the cd bit is provided. http://www.xilinx.com/support/answers/61064.html >>>> In cases where it is impossible to provide the cd bit in hardware, >>>> setting the controller to test mode and then setting inserted to true >>>> will get the controller to function with out the cd bit. >>>> >>>> The device property "fake-cd" will let the arasan driver know it needs >>>> to fake the cd bit for the controller inorder for the controller to >>>> function with a SD card that does not provide the CD bit. >>> >>> I thought the CD is, if not pinned out, tied off to some valid logic >>> level. Isn't it enough to specify cd-inverted if needed to make it work >>> in those cases? >> >> It is always brought out to some pin, that is the problem on the Zynq. This >> means you'd have to set at least one pin aside as dummy CD or WP pin. Which >> is not always possible when you are tight on available pins. > > I have to admit that I haven't looked at Vivado for quite a while. Is it > possible to select EMIO for those pins? If those are not routed anything > they should be tied to some logic level, I believe. > If they are always forced to be on a physical pin, do you let that pin > just float? Otherwise, the logic level should also be defined, give and > take a logic inversion. Yes, it is possible to source them from EMIO. We had the same issue with WP on one of our boards and the routing to EMIO approach was one of the solutions I considered. But I could not find documentation on whether and how the pins are tied when the FPGA is not configured or what happens during reconfiguration, is there a chance of glitches. So I went with the software solution of specifying disable-wp for the slot instead. But even if using EMIO works I think correctly describing the hardware, which is that there is no external WP or CD pin connected, is the better approach rather than playing around with invert flags, which has a different semantical meaning. Software can than work with that information and take the approach it is best to handle the situation. And this approach might change if we find better ways to handle it, whereas the hardware description stays static. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: lars@metafoo.de (Lars-Peter Clausen) Date: Thu, 25 Aug 2016 17:50:16 +0200 Subject: [PATCH 1/2] sdhci-of-arasan: Add quirk and device tree parameter to fake CD bit In-Reply-To: <20160825152944.GP16583@xsjsorenbubuntu> References: <1472080984-17373-1-git-send-email-zach.brown@ni.com> <20160825151047.GO16583@xsjsorenbubuntu> <20160825152944.GP16583@xsjsorenbubuntu> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 08/25/2016 05:29 PM, S?ren Brinkmann wrote: > On Thu, 2016-08-25 at 17:23:47 +0200, Lars-Peter Clausen wrote: >> On 08/25/2016 05:10 PM, S?ren Brinkmann wrote: >>> On Wed, 2016-08-24 at 18:23:03 -0500, Zach Brown wrote: >>>> The sdhci controller on xilinx zynq devices will not function unless >>>> the cd bit is provided. http://www.xilinx.com/support/answers/61064.html >>>> In cases where it is impossible to provide the cd bit in hardware, >>>> setting the controller to test mode and then setting inserted to true >>>> will get the controller to function with out the cd bit. >>>> >>>> The device property "fake-cd" will let the arasan driver know it needs >>>> to fake the cd bit for the controller inorder for the controller to >>>> function with a SD card that does not provide the CD bit. >>> >>> I thought the CD is, if not pinned out, tied off to some valid logic >>> level. Isn't it enough to specify cd-inverted if needed to make it work >>> in those cases? >> >> It is always brought out to some pin, that is the problem on the Zynq. This >> means you'd have to set at least one pin aside as dummy CD or WP pin. Which >> is not always possible when you are tight on available pins. > > I have to admit that I haven't looked at Vivado for quite a while. Is it > possible to select EMIO for those pins? If those are not routed anything > they should be tied to some logic level, I believe. > If they are always forced to be on a physical pin, do you let that pin > just float? Otherwise, the logic level should also be defined, give and > take a logic inversion. Yes, it is possible to source them from EMIO. We had the same issue with WP on one of our boards and the routing to EMIO approach was one of the solutions I considered. But I could not find documentation on whether and how the pins are tied when the FPGA is not configured or what happens during reconfiguration, is there a chance of glitches. So I went with the software solution of specifying disable-wp for the slot instead. But even if using EMIO works I think correctly describing the hardware, which is that there is no external WP or CD pin connected, is the better approach rather than playing around with invert flags, which has a different semantical meaning. Software can than work with that information and take the approach it is best to handle the situation. And this approach might change if we find better ways to handle it, whereas the hardware description stays static.