> On 22.07.2015, at 03:55, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
>
> However, I'd like to see a "semantic" driver for the shared register
> region rather than a "syscon". IIUC, "syscon" simply provides a stylized
> way for one driver to touch some shared registers directly without any
> semantics. I'd strongly prefer to see a real driver inside Linux rather
> than something that just lets drivers fiddle with the shared registers
> willy nilly. Still, this aspect is an internal implementation detail
> inside the kernel that we can change without external impact later if we
> need.
>
> More concerning: The bcm283x HW doesn't implement a "syscon" module, but
> some semantic IP block. The DT should contain a real compatible value
> that describes what the HW block really is, not just "syscon". We could
> bind the syscon driver to this compatible value if we have to for
So, do I understand you correctly that if we would call the node
bcm2835aux_enable as syscon with only the enable bit field register in it
and add a enable_reg (pointing to the above) and enable_reg_mask=2 or 4
to the spi1/2 nodes then it would be acceptable?
Would look like this:
spi2@7e2150c0 {
+ compatible = "brcm,bcm2835-aux-spi";
+ reg = <0x7e2150c0 0x40>;
+ interrupts = <1 29>;
+ clocks = <&clk_spi>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ cs-gpios = <&gpio 43>, <&gpio 44>, <&gpio 45>;
+ enable_reg = <&bcm2835aux_enable>;
+ enable_reg_mask = 4;
+};
+
+/* the necessary syscon config referenced above */
+bcm2835aux_enable: bcm2835aux_enable@0x7e215004 {
+ compatible = "syscon";
+ reg = <0x7e215004 0x04>;
+};
The uart aux driver would use:
+ enable_reg = <&bcm2835aux_enable>;
+ enable_reg_mask = 1;
Or maybe you would prefer a different naming?
The only use-case would be using:
regmap_update_bits(enable_reg, 0, enable_reg_mask, enable_reg_mask); /*enable */
regmap_update_bits(enable_reg, 0, enable_reg_mask, 0); /* disable */
--
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
