> On 30.06.2015, at 19:42, Mark Brown <broonie@xxxxxxxxxx> wrote:
>
> This looks relevant:
>
>>>> On 22.06.2015, at 16:55, Jakub Kiciński <moorray3@xxxxx> wrote:
>>>> As mentioned by Noralf UART1 is quite commonly used on Compute Modules.
>>>> Proper driver - perhaps modelled as a bus - seems like a prerequisite
>>>> for this work. You are also not using IRQ mux in DT binding example
>>>> which is very misleading.
Well, we are using shared interrupts, which is typical for other drivers on
the rpi as well - i2c and usb are examples for multiple handlers on
a single irq line on the rpi - excerpt from /proc/interrupts:
CPU0
33: 3547607286 ARMCTRL-level 41 Edge 20980000.usb, dwc2_hsotg:usb1
77: 0 ARMCTRL-level 85 Edge 20205000.i2c, 20804000.i2c
The compute module is not supported upstream and nobody
created any patches for a device tree for a cm...
On top there is no direct support for uart1 in the upstream kernel.
Support only exists in the foundation kernel where the implementation
enables the uart1 in the board-config directly, so that uart1
can also get used as the console during boot.
This means (as far as I understand) that there can be no
race-condition, as spi would get configured later during boot
and the access to the enable register is then properly
protected against concurrent access when enabling both
auxiliar spi devices (and spi2 is only usable on the compute
Module - see above for upstream support of the cm)
Finally asking for a recommendation with regards to using a bus
to arbitrate access to the enable register there was no feedback
how this could be get implemented...
This last piece is actually one of the last reasons why I have not
posted a patch for spi1 and spi2 to the default device-trees for
the rpi models yet.
(That and the fact that assigning pins in multiple pinctrl groups
- i2s and spi1 - gives warnings or errors in dmesg, because i2s is
also requiring Gpio 18, 19, 20 and 21 on the model-b-plus
device tree - so it can only be either/or not both...)
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
