<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>i.MX Processorsのトピックlinux kernel: what imx6-specific code is called with gpio_set_value()?</title>
    <link>https://community.nxp.com/t5/i-MX-Processors/linux-kernel-what-imx6-specific-code-is-called-with-gpio-set/m-p/743152#M115624</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I am debugging an issue on an imx6dl based system running a relatively old kernel/uboot.&amp;nbsp; I have a device tied to ecspi5 that works as expected, but I just noticed that the first access to this device corrupts a few -other- bits in a GPIO data register.&amp;nbsp; In the process of debugging this, I see that spi_imx_chipselect() (in {KERNEL}/devices/spi/spi-imx.c) calls gpio_set_value() and it appears that it is this call that mucks up a few other bits in GPIO1_DR.&lt;/P&gt;&lt;P&gt;I'm not really sure if my problem is in my device tree or possibly just an issue with my kernel.&lt;/P&gt;&lt;P&gt;So, right now I'm just trying to figure out what device-specific code is actually called below gpio_set_value() that actually sets the chipselect bit used with SPI.&amp;nbsp; I'm hoping to find a problem there (but not sure)...&lt;/P&gt;&lt;P&gt;Any thoughts?&lt;/P&gt;&lt;P&gt;Ed&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;PS... If there are any good documents on device tree and IMX6 specifics, I could use a pointer to that as well.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 18 Apr 2018 14:45:59 GMT</pubDate>
    <dc:creator>EdSutter</dc:creator>
    <dc:date>2018-04-18T14:45:59Z</dc:date>
    <item>
      <title>linux kernel: what imx6-specific code is called with gpio_set_value()?</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/linux-kernel-what-imx6-specific-code-is-called-with-gpio-set/m-p/743152#M115624</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;I am debugging an issue on an imx6dl based system running a relatively old kernel/uboot.&amp;nbsp; I have a device tied to ecspi5 that works as expected, but I just noticed that the first access to this device corrupts a few -other- bits in a GPIO data register.&amp;nbsp; In the process of debugging this, I see that spi_imx_chipselect() (in {KERNEL}/devices/spi/spi-imx.c) calls gpio_set_value() and it appears that it is this call that mucks up a few other bits in GPIO1_DR.&lt;/P&gt;&lt;P&gt;I'm not really sure if my problem is in my device tree or possibly just an issue with my kernel.&lt;/P&gt;&lt;P&gt;So, right now I'm just trying to figure out what device-specific code is actually called below gpio_set_value() that actually sets the chipselect bit used with SPI.&amp;nbsp; I'm hoping to find a problem there (but not sure)...&lt;/P&gt;&lt;P&gt;Any thoughts?&lt;/P&gt;&lt;P&gt;Ed&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;PS... If there are any good documents on device tree and IMX6 specifics, I could use a pointer to that as well.&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 18 Apr 2018 14:45:59 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/linux-kernel-what-imx6-specific-code-is-called-with-gpio-set/m-p/743152#M115624</guid>
      <dc:creator>EdSutter</dc:creator>
      <dc:date>2018-04-18T14:45:59Z</dc:date>
    </item>
    <item>
      <title>Re: linux kernel: what imx6-specific code is called with gpio_set_value()?</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/linux-kernel-what-imx6-specific-code-is-called-with-gpio-set/m-p/743153#M115625</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;P&gt;The issue that I was seeing was that my SPI chipselect was corrupting the GPIO_DR register that the bit was part of.&lt;/P&gt;&lt;P&gt;The problem was that I had written a GPIO device&amp;nbsp;driver that just uses ioremap() and the physical addresses of the GPIO control registers.&amp;nbsp; Apparently this isn't really the way to do it; because what I found was that linux was booting up and apparently reading the GPIO_DR at startup, then my driver would modify a few of the bits, then later the SPI driver used its shadow copy of the GPIO_DR instead of actually reading the GPIO_DR prior to writing to it.&lt;/P&gt;&lt;P&gt;As a result, the settings that I had put in place with my driver were lost.&lt;/P&gt;&lt;P&gt;Then I tried just using /sys/class/gpio to do my GPIO setup and then the SPI access didn't do any damage because apparently /sys/class/gpio uses the same gpio hooks as SPI, so the shadow copy of GPIO_DR was properly updated.&lt;/P&gt;&lt;P&gt;&lt;/P&gt;&lt;P&gt;My guess is that linux does an initial read of GPIO_DR and from then on, since it is an output register, it assumes that it knows the content of GPIO_DR based on its shadow copy.&amp;nbsp; This saves a read before the write, but seems kinda dangerous none-the-less.&amp;nbsp; Can anyone confirm that this is a valid conclusion?&lt;/P&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 18 Apr 2018 20:16:34 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/linux-kernel-what-imx6-specific-code-is-called-with-gpio-set/m-p/743153#M115625</guid>
      <dc:creator>EdSutter</dc:creator>
      <dc:date>2018-04-18T20:16:34Z</dc:date>
    </item>
  </channel>
</rss>

