Re: [PATCH 2/6] mailbox/omap: add support for parsing dt devices

Hi!

quoted

quoted

quoted

quoted

quoted

quoted

The non-DT support has to be maintained for now to not break
OMAP3 legacy boot, and the legacy-style code will be cleaned
up once OMAP3 is also converted to DT-boot only.

quoted

@@ -587,24 +606,157 @@ static int omap_mbox_unregister(struct omap_mbox_device *mdev)
 	return 0;
 }
 
+static const struct omap_mbox_device_data omap2_data = {
+	.num_users	= 4,
+	.num_fifos	= 6,
+	.intr_type	= MBOX_INTR_CFG_TYPE1,
+};
+
+static const struct omap_mbox_device_data omap3_data = {
+	.num_users	= 2,
+	.num_fifos	= 2,
+	.intr_type	= MBOX_INTR_CFG_TYPE1,
+};
+
+static const struct omap_mbox_device_data am335x_data = {
+	.num_users	= 4,
+	.num_fifos	= 8,
+	.intr_type	= MBOX_INTR_CFG_TYPE2,
+};

quoted

Aha, ok, then the intr_type should be derived from
compatible-string. Or rather... you should have three
compatible-strings for the three possibilities? (And then subtype,
currently unused, in case there are more hw differences).

The compatible string can and should be separate for each revision
unless they are the same exacat hardware revision.

ACK.

quoted

quoted

two are HW IP design parameters, so in general putting them in DT isn't
completely a bad idea, but I will wait to see if there are any further
comments on this from Tony or DT maintainers before I make changes.

Ok, right... I'd vote for putting them into DT.

I would avoid adding custom DT properties where possible and let the
driver just initialize the right data based on the compatible flag.

If these are HW IP design parameters, we can expect to see many
different combinations. Yet we know ahead of time how to handle
different parameters HW people select.

Thus IMO we should do it in the device tree.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html