Initial Linux-wireless contribution

[Eugene Krasnikov]

>> With mmio I'm not sure. I was thinking that we would provide 'struct
>> resource *wcnss_memory' instead so that we can do ioremap() in the probe
>> and iounmap() in the remove. I think it's easier to manage allocations
>> that way.
>
> Let me double check that. platform_device_add_resources must be use probably.

Kalle, what is the idea behind calling ioremap/iounmap from wcn36xx
but not from wcn36xx_msm module?

>From platform perspective tx,rx irq and memory are all resources. So
or we let wcn36xx handle all resources or we let wcn36xx_msm handle
resources. Under 'handle' i mean call of platform_get_resource_byname.

I think that it is better to let  wcn36xx_msm to handle resources so
that wcn36xx will deal with he final data.

2013/8/6 Eugene Krasnikov <k.eugene.e at gmail.com>:
> Made a quick definition for SMD channel hocks:
> https://github.com/KrasnikovEugene/wcn36xx/commit/4b77d93dda946f7f02364797eb3ed6841022d6d8
>
> 2013/8/6 Eugene Krasnikov <k.eugene.e at gmail.com>:
>>> Why do we need dev there? That's not clear to me.
>>
>> for one single call : SET_IEEE80211_DEV(wcn->hw, wcn->pdata->dev);
>>
>>> With mmio I'm not sure. I was thinking that we would provide 'struct
>>> resource *wcnss_memory' instead so that we can do ioremap() in the probe
>>> and iounmap() in the remove. I think it's easier to manage allocations
>>> that way.
>>
>> Let me double check that. platform_device_add_resources must be use probably.
>>
>>> Also the fact that the file is in arch/arm/mach-msm/include/mach/ might
>>> make things difficult. We should be able to compile wcn36xx also on x86
>>> but I'm not sure how that's possible now.
>>
>> It makes more sense to me to abstract from SMD as well.
>>
>> 2013/8/6 Kalle Valo <kvalo at qca.qualcomm.com>:
>>> Eugene Krasnikov <k.eugene.e at gmail.com> writes:
>>>
>>>> With this commit I made a draft version of platform abstraction layer
>>>> https://github.com/KrasnikovEugene/wcn36xx/commit/becf7a7a7d67c2913b61091a14eee404bde516bc
>>>>
>>>> Interface is defined with struct wcn36xx_platform_data here
>>>> https://github.com/KrasnikovEugene/wcn36xx/blob/pal/wcn36xx.h#L103
>>>>
>>>> Probe will be called from outside the driver. I'll publish that part later on.
>>>>
>>>> Could you please have a look and express your opinion about the
>>>> concept?
>>>
>>> So the struct is:
>>>
>>> struct wcn36xx_platform_data {
>>>         struct device           *dev;
>>>         /* IRQs */
>>>         int                     tx_irq;
>>>         int                     rx_irq;
>>>         void __iomem            *mmio;
>>> };
>>>
>>> Why do we need dev there? That's not clear to me.
>>>
>>> tx_irq and rx_irq look ok.
>>>
>>> With mmio I'm not sure. I was thinking that we would provide 'struct
>>> resource *wcnss_memory' instead so that we can do ioremap() in the probe
>>> and iounmap() in the remove. I think it's easier to manage allocations
>>> that way.
>>>
>>>> Should we put SMD channel handling in there as well? Any thoughts are
>>>> welcome.
>>>
>>> I forgot SMD altogether and of course there's a problem :(
>>>
>>> I don't see smd_named_open_on_edge() at all in upstream tree. But I do
>>> see smd_open() and smd_close() in
>>> arch/arm/mach-msm/include/mach/msm_smd.h. This might be tricky to solve.
>>>
>>> Also the fact that the file is in arch/arm/mach-msm/include/mach/ might
>>> make things difficult. We should be able to compile wcn36xx also on x86
>>> but I'm not sure how that's possible now.
>>>
>>> --
>>> Kalle Valo
>>
>>
>>
>> --
>> Best regards,
>> Eugene
>
>
>
> --
> Best regards,
> Eugene



-- 
Best regards,
Eugene