On Fri, 2014-11-07 at 17:33 +0200, Ivan T. Ivanov wrote:
> On Thu, 2014-11-06 at 08:55 -0800, Bjorn Andersson wrote:
> > On Wed, Nov 5, 2014 at 11:54 PM, Ivan T. Ivanov <iivanov@xxxxxxxxxx> wrote:
> > > On Wed, 2014-11-05 at 17:36 -0800, Bjorn Andersson wrote:
> > > > On Wed, Nov 5, 2014 at 10:31 AM, Ivan T. Ivanov <iivanov@xxxxxxxxxx> wrote:
> > [..]
> > > > > Some of the child device drivers have to know PMIC chip revision.
> > > > >
> > > >
> > > > So your plan is to have a strstr(parent->compatible, "-v2") there?
> > >
> > > Actually also PMIC subtype (pm8841, pm8226...) is also required, so
> > > the plan is to have something like this:
> > >
> > > {
> > > static const struct of_device_id pmic_match_table[] = {
> > > { .compatible = "qcom,pm8941-v1.0" },
> > > { .compatible = "qcom,pm8841-v0.0" },
> > > { }
> > >
> > > };
> > >
> > > const struct of_device_id *match;
> > >
> > > match = of_match_device(pmic_match_table, pdev->dev.parent);
> > > if (match) {
> > > dev_info(&pdev->dev, "%s chip detected\n", match->compatible);
> > > }
> > > }
> > >
> >
> > To me this is a hack, you should not alter the devicetree to make it
> > "better express the hardware". Either you know these things from boot
> > and they go in device tree, or you can probe them and they should not
> > go in device tree.
> >
> > If you really need these values you should expose them through some api.
>
> I would like to avoid compile time dependency between these drivers.
> There are several precedents of using of_update_property() for enhancing
> compatible property already.
>
> > > > Could you be a little bit more elaborate on what you're trying to do
> > > > and which child devices that might be?
> > >
> > > For example ADC drivers are required temperature compensation based
> > > on PMIC variant and chip manufacturer.
> > >
> >
> > I see, is that compensation of any practical value? Or is the
> > compensation of academic proportions?
>
> It depends of what you mean by academic :-). Attached file have test
> application which dump difference between non compensated and compensated
> values for different temperature, manufacture and input value.
>
> Output format of the program is:
> Column 1: manufacturer GF=0, SMIC=1, TSMC=2
> Column 2: chip revision
> Column 3: die temperature in mili deg Celsius
> Column 4: input for compensation in micro Volts
> Column 5: compensated result in micro Volts
> Column 6: difference in micro Volts
Forgot to add. PMIC subtype and version are used also in charger and BMS
drivers to workaround hardware issues.
Ivan
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
