Good Day PhilYes, so they should be added. I don't think we should assume the bootloader sets things up.
Am Montag, 1. Mai 2017, 09:57:35 CEST schrieb Phil Reid:
Yes, but if the resets are not connected in the device tree, the linux driversSo 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
There's a few thing like that where the bootloader has been expected to
setup the resets etc.
are not going to use them?
I think I understand. What soft core gpio controller are you using?
I don't switch to GPIO mode. As the I2C logic is only pulling active low, i only doHowever 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?
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:
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.
Given a couple of days I can test this on some flack i2c hardware I haveSounds good. If you need some further input how i have configured the fpga
with a Cyclone-V SOC. I'm interested in the functionality as well.
drop me a line.
For i2c that are connected to the dedicated HPS pins it should be possibleAs far as i know the internal jtag chain is only used in the bootloader and there
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.
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?
I'm guessI am interested in this ptp solution too. Is there anything on the way to mainline?
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.