On Fri, Apr 27, 2018 at 4:23 AM, Sujeev Dias <sdias@xxxxxxxxxxxxxx> wrote:
> QCOM PCIe based modems uses MHI as the communication protocol.
> MHI control driver is the bus master for such modems. As the bus
> master driver, it oversees power management operations
> such as suspend, resume, powering on and off the device.
>
> +- compatible
> + Usage: required
> + Value type: <string>
> + Definition: "qcom,mhi"
> +
> +- qcom,pci-dev-id
> + Usage: optional
> + Value type: <u32>
> + Definition: PCIe device id of external modem to bind. If not set, any
> + device is compatible with this node.
> +
> +- qcom,pci-domain
> + Usage: required
> + Value type: <u32>
> + Definition: PCIe root complex external modem connected to
> +
> +- qcom,pci-bus
> + Usage: required
> + Value type: <u32>
> + Definition: PCIe bus external modem connected to
> +
> +- qcom,pci-slot
> + Usage: required
> + Value type: <u32>
> + Definition: PCIe slot as assigned by pci framework to external modem
These don't seem to make any sense: You seem to have access to
a regular pci_device already, so why do you need to duplicate the
information about it in DT?
> +- qcom,smmu-cfg
> + Usage: required
> + Value type: <u32>
> + Definition: Required SMMU configuration bitmask for PCIe bus.
> + BIT mask:
> + BIT(0) : Attach address mapping to endpoint device
> + BIT(1) : Set attribute S1_BYPASS
> + BIT(2) : Set attribute FAST
> + BIT(3) : Set attribute ATOMIC
> + BIT(4) : Set attribute FORCE_COHERENT
> +
> +- qcom,addr-win
> + Usage: required if SMMU S1 translation is enabled
> + Value type: Array of <u64>
> + Definition: Pair of values describing iova start and stop address
Why do you need these? Can't that be handled by the PCI
layer?
> +- qcom,msm-bus,name
> + Usage: required
> + Value type: <string>
> + Definition: string representing the bus scale client name to register
This probably belongs into a separate binding for the bus
scale driver, right?
> +static struct pci_driver mhi_pcie_driver;
Please try to reorder the symbols to avoid forward declarations.
> +static int mhi_platform_probe(struct platform_device *pdev)
> +{
> + struct mhi_controller *mhi_cntrl;
> + struct mhi_dev *mhi_dev;
> + struct device_node *of_node = pdev->dev.of_node;
> + u64 addr_win[2];
> + int ret;
> +
> + if (!of_node)
> + return -ENODEV;
> +
> + mhi_cntrl = mhi_alloc_controller(sizeof(*mhi_dev));
> + if (!mhi_cntrl)
> + return -ENOMEM;
> +
> + mhi_dev = mhi_controller_get_devdata(mhi_cntrl);
> +
> + /* get pci bus topology for this node */
> + ret = of_property_read_u32(of_node, "qcom,pci-dev-id",
> + &mhi_cntrl->dev_id);
> + if (ret)
> + mhi_cntrl->dev_id = PCI_ANY_ID;
> +
> + ret = of_property_read_u32(of_node, "qcom,pci-domain",
> + &mhi_cntrl->domain);
> + if (ret)
> + goto error_probe;
> +
> + ret = of_property_read_u32(of_node, "qcom,pci-bus", &mhi_cntrl->bus);
> + if (ret)
> + goto error_probe;
> +
> + ret = of_property_read_u32(of_node, "qcom,pci-slot", &mhi_cntrl->slot);
> + if (ret)
> + goto error_probe;
Please explain what you are trying to do here, why do you register
two device drivers? It looks like they both refer to the same
hardware, so why isn't it sufficient to have the pci_driver?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
