Hi Wolfram,
On 11/11/2010 8:48 AM, Wolfram Sang wrote:
>>> Removing the dev.parent-branch will break some PCI-based solutions.
>> Hmm, I suspected this :-(. Unfortunately I need to not pass the parent
>> for the problem described in the patch.
>> How to proceed? Do I have to re-introduce the sdhc
> > Removing the dev.parent-branch will break some PCI-based solutions.
> Hmm, I suspected this :-(. Unfortunately I need to not pass the parent
> for the problem described in the patch.
> How to proceed? Do I have to re-introduce the sdhci-stm driver?
The current mainline code does not work for y
Hi Wolfram
On 11/10/2010 4:43 PM, Wolfram Sang wrote:
> Hi,
>
> thanks for the work in general, just...
>
>> -if (pdev->dev.parent)
>> -host = sdhci_alloc_host(pdev->dev.parent, 0);
>> -else
>> -host = sdhci_alloc_host(&pdev->dev, 0);
>> -
>> +host = sdhci_alloc
Hi,
thanks for the work in general, just...
> - if (pdev->dev.parent)
> - host = sdhci_alloc_host(pdev->dev.parent, 0);
> - else
> - host = sdhci_alloc_host(&pdev->dev, 0);
> -
> + host = sdhci_alloc_host(&pdev->dev, 0);
> if (IS_ERR(host)) {
>
ST targets use the sdhci-pltfm driver but there are some
problems when re-insert the driver on our platforms.
Within sdhci-pltfm d.d. the pdata->init invokes own
platform function to claim some resource (based on devres):
see the example code below:
static int mmc_pad_resources(struct sdhci_host *
