Hi Chris,
thanks for testing the series
On 27/01/2017 22:09, Chris Brandt wrote:
Hi Jacopo,
On Friday, January 27, 2017, Jacopo Mondi wrote:
Hello,
sorry if I'm sending 2 patches on top of an RFC series with comments
still pending, but these patches enabled me to properly test pin
configuration sequence in order to access the internal EEPROM through
RIIC2 interface on pins 1_4 and 1_5.
The outcome is a bugfix to RZ/A1 pincontroller driver which [2/2] applies
on.
When sending v2 of the whole series I'll probably squash these, but if
someone is testing the RFC series I wanted to make sure he does not waste
his time with a broken driver.
Thanks
j
Jacopo Mondi (2):
arm: dts: genmai: Configure RIIC2 pins
pinctrl: rz-pfc: Fix RZ/A1 pin function configuration
arch/arm/boot/dts/r7s72100-genmai.dts | 8 ++++- drivers/pinctrl/rz-
pfc/pinctrl-rza1.c | 55 +++++++++++++++++++++++------------
2 files changed, 43 insertions(+), 20 deletions(-)
Preliminary testing shows that I2C pin muxing works. Nice job!
Testing:
- RZ/A1H RSK board
- u-boot modified to make sure pins are put back to GPIO-IN
- RIIC ch3 is connected to a I2C port expander that has 3 LEDs attached
- using a heartbeat kernel thread that blinks the LEDs
Of course, more testing is needed to make sure there is no "smoke and mirrors"
going on like there was with the MSTP clock driver ;)
Note that the I2C pin need to be configured at "bi-directional" but there is
no way to specify that from DT, so that has to be added as a parameter.
That's something I would like to discuss quite soon.
One general thing I would like is having the so-called "additional
parameters" part of the SoC driver module, as my gut feeling is that
different PFC hw requires different configuration options.
In example, the RZ/A1 SoC requires the input/output direction of the pin
to be specified even when the alternate function is supposed to drive it
(in order to enable/disable input buffer). The same applies to
bi-directional port control as you pointed out in your example
(bi-directional enables input buffer, but that's a consequence of how hw
works there).
I'm almost sure the same won't be required by all existing and
forth-coming Renesas SoCs with a pin-based PFC hardware, but maybe other
parameters I cannot think of right now will have to be specified instead.
If we want to keep the configuration flags SoC-specific, the most easy
way to pass them down from core module to SoC module would be
compressing the alternate function number and other configurations in a
single u32.
In that case the dts will look like:
renesasa,rz-pins = <BANK PORT (ALTERNATE_FUNC_# | IO_MODE | DIRECTION)>;
We could even add a parameter to separate ALTERNATE_FUNCTION from the
additional configurations, but I don't see any advantage in doing this
at the moment.
Can people with a broader knowledge of Renesas' SoC series ack/nack my
assumptions here?
Thanks
j
--
To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
