# Re: \[PATCH 24/25\] OMAPDSS: DSI: improve DSI module id handling

- From: Archit Taneja \<hidden\>
- Date: 2012-05-04 10:17:24 
- List: linux-fbdev
- Page: https://ratatoskr.run/linux-fbdev/2012/05/13463111
- Thread: https://ratatoskr.run/linux-omap/2012/05/13463081/t.md

```text
On Friday 04 May 2012 03:23 PM, Tomi Valkeinen wrote:
> On Fri, 2012-05-04 at 14:39 +0530, Archit Taneja wrote:
>> On Thursday 03 May 2012 07:28 PM, Tomi Valkeinen wrote:
>>> We currently use the id of the dsi platform device (dsidev->id) as the
>>> DSI hardware module ID. This works because we assign the ID manually in
>>> arch/arm/mach-omap2/display.c at boot time.
>>>
>>> However, with device tree the platform device IDs are automatically
>>> assigned to an arbitrary number, and we can't use it.
>>
>> If this number is arbitrary we would need to change the "dsi_pdev_map"
>> approach of mapping a dsi module and it's corresponding platform device.
>> Currently dsi_pdev_map is:
>>
>> static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
>>
>> So we either need to increase the array size to take larger arbitrary
>> numbers, or do something else.
>>
>> We would also need to fix the usage of dsi_get_dsidev_from_id(), as
>> right now we manually pass 0 and 1 to it only, for example:
>>
>> static void dsi1_dump_irqs(struct seq_file *s)
>> {
>>           struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
>>
>>           dsi_dump_dsidev_irqs(dsidev, s);
>> }
>>
>> The immediate solution that comes to mind is to maintain 2 id's, one
>> which is sequential, and the other which the DT has created, and keep an
>> array to map these. But this seems messy!
>
> This is only a problem with device tree, and I solved it so that I pass
> a DSI module ID in the device tree data. So, with old pdata way I
> initialize dsi->module_id from the pdev->id, but with DT I initialize
> dsi->module_id from the DT data.

Oh ok, so the code which decides how dsi->module_id is initialised(from 
DT or pdata) is not in this series right? And it would come later? Right 
now it's just set to dsidev->id in probe.

>
> So basically we remove the use of pdev->id in this patch, and add
> dsi->module_id field, which needs to be initialized to 0 or 1, depending
> on the corresponding HW module. We just happen to use the pdev->id to
> initialize it when using the old pdata method, as we know it tells the
> right id. But we could initialize it from any other source.

Right, I get it now.

>
> This allows us to keep the 0 and 1 DSI IDs, and I think we need those
> anyway. Some parts of the code could work fine with arbitrary ID, as
> long as a pdev can be linked to/from this ID. However, there are things
> where we must have the ID, like configuring the clock source settings in
> dss_core, where we set a certain bit for DSI module 0, and certain bit
> for module 1.
>
> Perhaps even those could be handled without explicit ID of 0 or 1, but
> that doesn't sound trivial and I didn't want to start tackling that in
> this series.
>
> I wish there was a way to get the module ID from the HW registers
> somehow. Then we wouldn't need to pass the ID via SW, which doesn't feel
> very correct. At least with DT it's a bit wrong, in my opinion, but best
> I could come up with.

We could derive it via a parameter like number of lanes or something 
similar through DSI_GNQ, but that doesn't seem very nice, and may not be 
usable on future OMAPs.

Archit

>
>   Tomi
>

```