Re: gpio: dwapb: Synopsys Designware GPIO

[Steffen Trumtrar <s.trumtrar-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>]

On Thu, Oct 31, 2013 at 06:21:46PM +0100, Sebastian Hesselbarth wrote:
> On 10/31/2013 05:17 PM, Steffen Trumtrar wrote:
> >On Thu, Oct 31, 2013 at 04:07:23PM +0000, Jamie Iles wrote:
> >>On Thu, Oct 31, 2013 at 04:58:03PM +0100, Steffen Trumtrar wrote:
> >>>I wonder if we want to really keep the binding as it is proposed by
> >>>Jamie. Do we really win anything by having to specify the banks in the
> >>>DT? In my version I get the number of ports, width etc. from the config registers
> >>>of the device. I think everything that the device knows itself and can be read
> >>>out at runtime shouldn't be specified in the DT.
> >>>And it seems that the binding was never merged, so I guess we can change it.
> >>
> >>The reason for having it split into banks is that for hardware that has
> >>a mixture of bank sizes (odd hardware admittedly, but that includes
> >>hardware that I was writing the driver for), we had a setup like 16 pins
> >>on bank A, 16 on B, 1 on C and 16 on D where each bank could have a
> >>maximum of 32, so converting from a data sheet to GPIO number is not
> >>obvious.  Grant Likely suggested representing the banks as different
> >>devices, so that's how I created the binding.
> >
> >I have no problem with the binding, if it is worth it. Do you mean you had
> >hardware where the gpio lines where not connected? Or maybe you had an older
> >version of the IP core?
> >In the Socfpga case there is gpio_config_reg2, which specifies the width
> >for every of the 4 ports. So I thought I use those values to describe my
> >hardware. The Socfpga however only uses the first bank of its three GPIO cores,
> >so I wouldn't be able to test if the code works for more than just that.
> 
> Having talked with Heiko at ELCE, both upcoming mach-berlin and
> mach-rockchip will be using dw-apb-gpio as GPIO driver. Unfortunately,
> while berlin has the CONFIG[12] registers, rockchip has not. So there
> must be bindings to at least overwrite the obvious settings derived
> from that registers.
> 

Well, okay :-( It looks like the original binding is a must than.

> Also, IIRC Heiko prefers to use platform_data driven registration as it
> is tightly coupled with rk's pinmux. So there should really be support
> for that and DT parsing on top that fills platform_data.
> 

If it's up to me, that may be added later when needed. But I guess I'm
out and will leave that to Alan/Dinh as they already have a more
appropriate series.

> Can you please resend the whole set on list so we can review it again
> with more machs involved?
> 

Dito.

Thanks,
Steffen

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
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