lkml.org 
[lkml]   [2018]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH v1 2/4] mhi_bus: controller: MHI support for QCOM modems
From
Date


On 04/27/2018 04:32 AM, Arnd Bergmann wrote:
> On Fri, Apr 27, 2018 at 4:23 AM, Sujeev Dias <sdias@codeaurora.org> 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?
>
I will remove the platform device, original hardware design we had a
complicated power on
sequence that require platform device to come up first and follow a
strict power on sequence to power on modem
before pci device can enumerate. I stored the BDF in DT to correlate
the platform device with pci device. platform device
is no longer needed so I can remove it.
>> +- 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?
I will move this to end point DT. PCIe end point driver does the iommu
configuration
>> +- 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?
Yes, this is for qcom bus scale driver which I don't think is upstreamed
yet. Will confirm.
>> +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?
As I explained earlier, it's now. Original hardware design we had
chicken egg situation where
some driver has to come up and power on device before pcie enumeration
can take place.

>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Thanks again
Sujeev

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

\
 
 \ /
  Last update: 2018-04-28 17:40    [W:0.102 / U:40.388 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site