Messages in this thread |  | | Subject | Re: RFC: i2c designware gpio recovery | From | Phil Reid <> | Date | Wed, 3 May 2017 09:30:50 +0800 |
| |
G'day Tim,
On 1/05/2017 21:31, Tim Sander wrote: > Good Day Phil > > Am Montag, 1. Mai 2017, 09:57:35 CEST schrieb Phil Reid: >>> So i took a look into the device tree file socfpga.dtsi and found that the >>> reset lines where not defined (although available in the corresponding >>> reset manager). Is there a reason for this? Other components are >>> connected. >> >> There's a few thing like that where the bootloader has been expected to >> setup the resets etc. > Yes, but if the resets are not connected in the device tree, the linux drivers > are not going to use them? Yes, so they should be added. I don't think we should assume the bootloader sets things up. But that doesn't seem to have been the assumption with the Alter SOC's.
> >>> However with the patch below my previously sent patch works! >>> >>> If there is interest in would cleanup the patch and send it in for >>> mainlining. I think the most unacceptable part would be this line: >>> + ret = gpio_request_one(bri->scl_gpio, //GPIOF_OPEN_DRAIN | >>> My gpio drivers refuse to work as output as they have no open drain mode. >>> So i wonder how to get this solved in a clean manner. >> >> I thought the gpio system would emulate open drain by switching the pin >> between an input and output driven low in this case. How are you >> configuring the GPIO's in the FPGA? > I don't switch to GPIO mode. As the I2C logic is only pulling active low, i only do > a wired and with the gpio (implemented in the fpga) port output on the output > enable line for the SCL output. SDA is only an additional input for the second in > fpga gpio port. > > A picture should make it a clearer: > > gpio scl--\ > i2c scl --&---i2c mode output pin (configured as fpga loan) > > In my case the original i2c pins where occupied by some other logic conflicting > so the i2c pins had to be shifted to some other pins using fpga logic. So it was > just a matter of adding a two port gpio port. I think I understand. What soft core gpio controller are you using?
> >> Given a couple of days I can test this on some flack i2c hardware I have >> with a Cyclone-V SOC. I'm interested in the functionality as well. > Sounds good. If you need some further input how i have configured the fpga > drop me a line. > >> For i2c that are connected to the dedicated HPS pins it should be possible >> to reconfigure the pin mux controller (see system manager) in the HPS to >> avoid the need to go thru the fpga to get direct control. The docs say this >> is "unsupport" but I've done some test and it does seem to work. > As far as i know the internal jtag chain is only used in the bootloader and there > is no linux driver? But it shouldn't be a too big problem to port it to linux. > > What i am unsure about is the fact that the internal jtag chain which controls the > pinmuxing might wreak havoc on other pin states if you reconfigure it?
Have a look at the Cyclone V handbook "pin mux control Group REgister Descriptions" From what I can see the chain is used to configure IO standards and drive strength. But not the actual muxes > >> I'm guess >> the no support is in a similar vain to the emac ptp FPGA interface couldn't >> be used when the HPS pin where used. But that got changed when the user's >> proved otherwise. There's just no pin ctrl driver yet to manage it. > I am interested in this ptp solution too. Is there anything on the way to mainline? >
This was working the last time I tried it. I submitted a couple of minor patches for it a while ago. My hardware has a DSA switch attached to the ethernet port and so far I haven't figured out how to enable ptp when using the virtual lan ports on the DSA. But it worked fine when directly connected to a phy.
-- Regards Phil Reid
|  |