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. 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. 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. Tomi
signature.asc
Description: This is a digitally signed message part
