On Mon, Jul 22, 2019 at 3:42 AM Andrew Jeffery <andrew@xxxxxxxx> wrote: > If the clock driver owns the control register, it also needs to know how > many GPIOs we want to emit on the bus. This seems like an awkward > configuration parameter for a clock driver. > > To avoid the weird parameter we could protect the control register > with a lock shared between the clock driver and the SGPIO driver. This > way the SGPIO driver could have the ngpios parameter, and request > the clock after its written the ngpios value to the control register. A > regmap would be useful here to avoid the resource clash and it also > provides the required lock. Nah. Too complicated. What about using the clock API locally (in the singleton driver, much as it is today) though, to give the right abstraction? See drivers/gpu/drm/pl111/pl111_display.c pl111_init_clock_divider() for an example of a local clock. > However, you're also going down the path of splitting the driver such > that there's one instance per bank. With this approach we need to > solve two problems: Accounting for the total number of GPIOs, I don't see that as a big problem since each driver instance will handle 8 GPIOs and don't need to know how many the other instances have and whether they exist or not. > and > only enabling the bus after the last bank has had its driver probed. That is a bigger problem and a good reason to stick with some complex driver like this. > The accounting might be handled by accumulating the number of > GPIOs in each bank in the control register itself, e.g. the driver > implementation does something like: > > spin_lock(...) > ctrl = ioread32(...) > ngpios = FIELD_GET(ASPEED_SGPIO_CTRL_NGPIOS, ctrl); > ngpios += 8; > ctrl &= ~ASPEED_SGPIO_CTRL_NGPIOS; > ctrl |= FIELD_PREP(ASPEED_SGPIO_CTRL_NGPIOS, ngpios); > iowrite32(ctrl, ...); > spin_unlock(...); But why. The gpio_chip only knows the ngpios for its own instance. It has no business knowing about how many gpios are on the other chips or not. If this is split across several instances this should not be accounted that is the point. > This works on cold boot of the device when the ngpios field is set to > zero due to reset, however will fail on subsequent warm reboots if > the GPIO IP block is protected from reset by the SoC's watchdog > configuration: the field will not be zeroed in this case, and the > value of the field is represented by `NR_BOOTS * NR_GPIOS`, > which is incorrect. To do this correctly I guess we would need some > other global state held in the driver implementation (zeroed when > the kernel is loaded), and write the incremented value to the control > register on each probe() invocation. This is answered about I guess. > However, that aside, we can't simply enable the bus in the clock > enable callback if enable is called per-bank, as it is called once on > the first request with further requests simply refcounted as you > mentioned. This is exactly the behaviour we can't tolerate with the > bus: it must only be enabled after the last GPIO bank is registered, > when we know the total number of GPIOs to emit. So the bus needs to know the total number of GPIOs or everything breaks, and that is the blocker for this divide-and-conquer approach. Why does the bus need to know the total number of GPIOs? (Maybe the answer is elsewhere in the thread...) I guess I will accept it if it is really this complex in the hardware. Yours, Linus Walleij
