On 2022/3/23 21:11, Rob Herring wrote:
On Wed, Mar 23, 2022 at 12:12:43PM +0800, Sui Jingfeng wrote:
On 2022/3/23 04:49, Rob Herring wrote:
+/*
+ * mainly for dc in ls7a1000 which have builtin gpio emulated i2c
+ *
+ * @index : output channel index, 0 for DVO0, 1 for DVO1
+ */
+struct lsdc_i2c *lsdc_create_i2c_chan(struct device *dev, void *base, unsigned int index)
+{
+ char compat[32] = {0};
+ unsigned int udelay = 5;
+ unsigned int timeout = 2200;
+ int nr = -1;
+ struct i2c_adapter *adapter;
+ struct lsdc_i2c *li2c;
+ struct device_node *i2c_np;
+ int ret;
+
+ li2c = devm_kzalloc(dev, sizeof(*li2c), GFP_KERNEL);
+ if (!li2c)
+ return ERR_PTR(-ENOMEM);
+
+ li2c->index = index;
+ li2c->dev = dev;
+
+ if (index == 0) {
+ li2c->sda = 0x01;
+ li2c->scl = 0x02;
+ } else if (index == 1) {
+ li2c->sda = 0x04;
+ li2c->scl = 0x08;
Just require this to be in DT rather than having some default.
By design, I am try very hard to let the code NOT fully DT dependent. DT is nice , easy to learn and use.
But kernel side developer plan to follow UEFI + ACPI Specification on LS3A5000 + LS7A1000 platform. See [1]
There will no DT support then, provide a convention support make the driver more flexible. I want the
driver works with minimal requirement. The driver just works on simple boards by put the following dc device
node in arch/mips/dts/loongson/loongson64g_4core_ls7a.dts,
Pick DT or ACPI for the platform, not both. We don't need to have both
in the kernel to support.
Rob
Hi Rob,
We can only choose DT currently, we love DT, but it is kernel side developer's choice.
We just avoid deep coupling which tend to lost flexibility.
All I can and should do is make the drivers works, writing code beautiful does not
means it can works like a charm.
From what i am understanding, DT is not a strict specification, but in return flexible.
Force every driver comply with what already have is tend to prohibit innovation.
It just too late to do so.
