Subject: Re: [PATCH v26 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
and transfer-mode properties

Hi Ryan,

quoted

quoted

Not at all - the next paragraph was my attempt at a recap of those,
but Ryan, please correct me if I am wrong on any of those points.

Your understanding is correct; the byte and buffer mode is mostly the same.
And also mode should be decided before xfer, due to the
controller/target both use the same xfer mode, not decide by transfer time.
The original my submit is only buffer mode and dma mode, and use only
one Boolean property, aspeed,i2c-dma-enabled, but someone suggest add
byte mode select, so I start to add at v17. I can drop the byte mode, if this is

confused.

quoted

byte mode request:
https://lore.kernel.org/all/010e55e9-d58b-444c-ab57-ddf8c75f2390@gmail
.com/

I understand that there may be valid uses for byte mode, but that does not
mean the configuration belongs in the device tree.

We do not seem to have much data on what those valid uses are, but I am
assuming it is not an attribute of the controller peripheral hardware.

OK will remove it in yaml file, instead Boolean property, aspeed,i2c-dma-enabled

[As an example: I suspect MCTP cannot be fully spec-compliant without byte
mode, in order to support the NAK window on target-mode RX. In that case we
can enforce byte mode when the controller is selected for MCTP use, without
requiring a mode selection property in the DT]

quoted

quoted

Ryan: I think this gives us a much cleaner approach to the binding.

Thanks the feedback, do you mean, just one boolean property for mode
selection, Am I right?

The property would not select a mode, it just indicates whether DMA is
available.

A driver implementation can use that indication, along with any other
configuration data, in order to select a mode. The Linux driver implementation
may use other runtime facilities to control that selection, if you need, like sysfs
or configfs.

Do you mean sysfs select support mode selection(byte, buffer, dma)
Or just force byte mode? 

Cheers,


Jeremy