On 07/12/2020 01:07, André Przywara wrote:

On 06/12/2020 16:01, Icenowy Zheng wrote:

Hi,

....

quoted

quoted

quoted

quoted

quoted

+                 SUNXI_FUNCTION_IRQ_BANK(0x6, 4, 16)), /*

PI_EINT16 */

quoted

quoted

quoted

+};
+static const unsigned int h616_irq_bank_map[] = { 2, 5, 6, 7, 8 };

The BSP driver seems to have more than 5 IRQ Banks.

static const unsigned sun50iw9p1_irq_bank_base[] = {
SUNXI_PIO_BANK_BASE(PA_BASE, 0),
SUNXI_PIO_BANK_BASE(PC_BASE, 1),
SUNXI_PIO_BANK_BASE(PD_BASE, 2),
SUNXI_PIO_BANK_BASE(PE_BASE, 3),
SUNXI_PIO_BANK_BASE(PF_BASE, 4),
SUNXI_PIO_BANK_BASE(PG_BASE, 5),
SUNXI_PIO_BANK_BASE(PH_BASE, 6),
SUNXI_PIO_BANK_BASE(PI_BASE, 7),
};

So maybe it should be somethings like this:
static const unsigned int h616_irq_bank_map[] = { 0, 2, 3, 4, 5, 6,

7, 8 };

quoted

While that's true, I don't see a need for IRQ bank on port A - this

port is 

quoted

internal (not exposed on pins) and none of the functionality on that

port 

quoted

needs IRQ.

I agree here, since port A isn't even mentioned in the manual (neither

I think if we ignore it we have the risk of DT binding issues
when we need to add it afterwards.

You have a point, but which interrupt shall I assign in the .dtsi?

Ah, of course they mention it in their -pinctrl.dtsi...

And as Jernej mentioned, there is little sense in having those pins as
interrupt sources, since we cannot use them as GPIOs in a useful way. We
could bitbang I2C, but I don't see much sense in doing this.

And to be honest: that issue is a shortcoming of our binding. By moving
this simple array into the DT we could avoid this problem entirely.

quoted

quoted

is PortD or PortE),

I had a look at PortD and PortE in the BSP: they describe LCD, LVDS and
CSI, mostly, all interfaces which the chip does not support anymore.
Even if the peripherals are still in, there is no use for having those
signals internally. And there are surely no pads connected to them
(there are simply no balls left on the package, according to the datasheet).

So my theory is that those peripherals are just left in because it was
too much trouble to remove them (and it doesn't hurt having them in), or
there is another package variant which exposes those pins.

So I would lean to not expose those ports (PD, PE) and their interrupts
(for PA, PD, PE).

Opinions?

So with those numbers from their .dtsi I can offer to use the array as
Clément showed above, and adjust the indicies in the pin arrays above.
Then have the IRQ numbers as shown in the BSP in our .dtsi.
But I would not have SUNXI_FUNCTION_IRQ_BANK statements for those
unknown ports, in fact no mentions of PortD and PortE at all.

Does that sound acceptable?

Cheers,
Andre

quoted

I would refrain from listing it here prematurely.

quoted

Plus we actually don't know their interrupt numbers: the manual only
mentions GPIOE on top of the already listed interrupts.

The interrupts work by their index, so skipping ports is not an issue.
I
just tested the PIO interrupt on PortC, and it works.

Cheers,
Andre

quoted

quoted

quoted

+
+static const struct sunxi_pinctrl_desc h616_pinctrl_data = {
+       .pins = h616_pins,
+       .npins = ARRAY_SIZE(h616_pins),
+       .irq_banks = 5,

 .irq_banks = ARAY_SIZE(h616_irq_bank_map) is better no ?

quoted

+       .irq_bank_map = h616_irq_bank_map,
+       .irq_read_needs_mux = true,
+       .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
+};
+
+static int h616_pinctrl_probe(struct platform_device *pdev)
+{
+       return sunxi_pinctrl_init(pdev,
+                                 &h616_pinctrl_data);
+}
+
+static const struct of_device_id h616_pinctrl_match[] = {
+       { .compatible = "allwinner,sun50i-h616-pinctrl", },

This is a new compatible and should be documented.

Regards,
Clement

quoted

+       {}
+};
+
+static struct platform_driver h616_pinctrl_driver = {
+       .probe  = h616_pinctrl_probe,
+       .driver = {
+               .name           = "sun50i-h616-pinctrl",
+               .of_match_table = h616_pinctrl_match,
+       },
+};
+builtin_platform_driver(h616_pinctrl_driver);
--
2.17.5

--

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel