[PATCH] arc: remove num-slots from arc platforms

Jaehoon Chung jh80.chung at samsung.com
Wed Jul 5 21:17:48 PDT 2017

On 07/05/2017 07:14 PM, Alexey Brodkin wrote:
> Hi Jaehoon,
> On Wed, 2017-07-05 at 18:58 +0900, Jaehoon Chung wrote:
>> Hi Alexey,
>> On 07/05/2017 06:23 PM, Alexey Brodkin wrote:
>>> Hi Jaehoon,
>>> On Wed, 2017-07-05 at 18:13 +0900, Jaehoon Chung wrote:
>>>> Hi Alexey,
>>>> On 07/05/2017 06:05 PM, Alexey Brodkin wrote:
>>>>> Hi Shawn,
>>>>> On Wed, 2017-07-05 at 15:10 +0800, Shawn Lin wrote:
>>>>>> dwmmc driver deprecated num-slots and plan to get rid
>>>>>> of it finally. Just move a step to cleanup it from DT.
>>>>> Hm, that's interesting.
>>>>> In our upcoming devboard (HSDK, see
>>>>> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_pipermail_linux-2Dsnps-2Darc_2017-2DJuly_002667.html&d=DwICaQ&c=DPL6_X
>>>>> _6Jk
>>>>> XFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=b7bMsqUn3obLZnR09LeBC0q6AouAgBH_cIlb0VcM43U&s=yMZ4dGcco3uL5H1m51kiI8d2sF6MCA_IdFw
>>>>> T326
>>>>> IOGk&e= )
>>>>> we do use 2 slots of DW MobileStorage controller (even though it's not yet
>>>>> mentioned in its .dts).
>>>> I didn't see about multiple slot for dwmmc controller.
>>> I was about to add a second SD-card slot to hsdk.dts
>>> once we have a peripheral attached to it working.
>> Sorry, Have we discuss about this?
> I think it was never discussed unfortunately.
>>>>> So the question is if multi-slot support gets removed from dwmmc driver or
>>>>> it's just a .dts option gets obsoleted. In latter case I'm wondering how to
>>>>> enable a second slot in dwmmc driver (will it just auto-probe it etc)?
>>>> In dwmmc controller, already removed the multiple slot concept.
>>> Too bad for us as the second slot is attached to SDIO peripheral we really need.
>>> What was a reason to get rid of multi-slot support on DW MMC?
>> After merged dwmmc in mainline, we were keeping the slot concept.
>> During 6 years, we didn't see the use-case about multi-slots..
>> In all dts files, num-slots were used to "1" like "by-default".
>> It was meaningless value.
>> when we kept the multiple slot concept, it's complex to handle the driver.
>> e,g) if upstream some patch, it has to check "cur_slot" and "slot" ..because dwmmc controller was doing context switch for slot.
>> 	Sometime slot was not assigned..occurred the panic or NULL pointer dereference error.
>> If there is no advantage for maintaining it, then i felt that the removing multiple slot is better than keeping.
>> Then we can focus on one slot..and maintenance is more easier...
>> And as i know, MMC subsystem doesn't consider the multiple slot.
>> That's why i have removed it.
> Ok that's a good reason to do it.
> I was really surprised to see people prefer to add a few more
> instances of DW MMC controolers in their systems (I did see about 5 of them
> on some boards) instead of using extra slots of the same one controller.
> I guess that's because all slots reuse the same data lines and so performance
> degradation is inevitable.

Right, that's why doesn't use the multiple slot.
Company hopes to make the product that costumer is satisfied.
Performance is one of important things...
For saving about the cost that using more IP ...use the multiple slots via one IP?
It doesn't make sense..but i don't know why your board is using the multiple slot..
Maybe there are some reasons..?

> Anyways we still don't have that SDIO peripheral working as expected
> and for now only 1 slot is fine. Though it might become a nightmare for me
> if the need for the second slot really arises. But let's see how it goes.
> BTW do you know if that multi-slot functionality was ever tested at all?

I know...i didn't never test the multi-slot..did you check the slot->sdio_id?
Rockchip is using the slot 8 as sdio peripheral.
As you already know, dwmmc needs to shift the bit according to slot.

Best Regards,
Jaehoon Chung

> Now I have a feeling that our SDIO peripheral attached to the second slot of DW MMC
> is not working because:
>  a) Linux driver support for multi-slot is not functional
>  b) Hardware itself is not working as expected as nobody ever tried that functionality.
> -Alexey

More information about the linux-snps-arc mailing list