On Tue, Aug 20, 2013 at 10:35:51AM +0800, Shawn Guo wrote:
> On Mon, Aug 19, 2013 at 07:39:12PM +0200, Sascha Hauer wrote:
> > On Mon, Aug 19, 2013 at 10:41:38PM +0800, Shawn Guo wrote:
> > > Copy devicetree mailing list.
> > >
> > > > @@ -352,8 +521,15 @@ static struct platform_device_id sdma_devtypes[] = {
> > > > MODULE_DEVICE_TABLE(platform, sdma_devtypes);
> > > >
> > > > static const struct of_device_id sdma_dt_ids[] = {
> > > > - { .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, },
> > > > + { .compatible = "fsl,imx6q-sdma", .data = &sdma_imx6q, },
> > > > + { .compatible = "fsl,imx53-sdma", .data = &sdma_imx53, },
> > > > + { .compatible = "fsl,imx51-sdma", .data = &sdma_imx51, },
> > > > + { .compatible = "fsl,imx35-to2-sdma", .data = &sdma_imx35_to2, },
> > > > + { .compatible = "fsl,imx35-to1-sdma", .data = &sdma_imx35_to1, },
> > > > { .compatible = "fsl,imx35-sdma", .data = &sdma_imx35, },
>
> <snip>
>
> > > Also, I do not know how we will play these tapeout specific compatible
> > > in device tree. As you know, we currently do not have tapeout but only
> > > chip specific DTS, since we expect kernel will figure out the
> > > tapeout/revision and handle the differences accordingly.
> >
> > In fact the kernel does figure out the tapeout version, but I don't have
> > access to it in the driver.
>
> Yeah. But since we're using SoC for IP versioning and the version could
> vary even for same SoC between different revisions, I think we will see
> such need of accessing SoC revision from device driver more and more.
> Thus, we will need a generic approach for that sooner or later, I guess.
>
> One approach I can think of is that we define a property "revision"
> under node "soc", and ask platform code to fill this property by calling
> of_update_property(). Then drivers can simply get it via device tree
> /soc/revision.
If the IP differs between SoC revisions then I would argue these should
have different compatible entries. Otherwise we end up coding SoC
specifics in the driver, something we just recently got rid of.
Of course it's not very convenient to let the bootloader adjust the dtb
for different SoC revisions. This leaves the kernel architecture code to
do it.
>
> >
> > Currently we have a problem anyway. We have the firmware names in the
> > dts, but the firmware is tapeout specific for i.MX31/35.
> >
> > So I think our options are:
> >
> > - remove the tapeout specifics from the devicetrees, this would mean to
> > also remove the firmware names.
> > - keep the tapeout specifics in the devicetree, then we could even add
> > some more like I did ;)
>
> If I understand this option correctly, we will need something like
> imx35-to1.dtsi and imx35-to2.dtsi, and board level dts authors need to
> include the correct one per the chip revision on their boards. What
> about some board that solder both revisions, and socket board that can
> change chips? I do not think it's going to work.
I would not go the way to have two different dtsi files in the kernel.
If we want to go this way we either have to let the bootloader or the
kernel architecture code fix it up between SoC revisions.
I'll postpone this problem for now by removing the ROM script support
for i.MX31/35.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
