On Wed, Mar 04, 2015 at 05:46:25PM -0800, Stephen Boyd wrote:
> On 03/04/15 16:30, Mark Brown wrote:
> > On Wed, Mar 04, 2015 at 11:35:43AM -0800, Stephen Boyd wrote:
> > Dependency resolution isn't anything new, I'm not sure why you think
> > this is related to of_parse_cb()? Open coding does
On Wed, Mar 04, 2015 at 05:46:25PM -0800, Stephen Boyd wrote:
On 03/04/15 16:30, Mark Brown wrote:
On Wed, Mar 04, 2015 at 11:35:43AM -0800, Stephen Boyd wrote:
Dependency resolution isn't anything new, I'm not sure why you think
this is related to of_parse_cb()? Open coding does exactly
On 03/04/15 16:30, Mark Brown wrote:
> On Wed, Mar 04, 2015 at 11:35:43AM -0800, Stephen Boyd wrote:
>
>> There's another problem with this of_parse_cb design. The regulator
>> framework requires supplies to be registered before consumers of the
>> supplies are registered. So when we register L23
On Wed, Mar 04, 2015 at 03:51:46PM -0800, Bjorn Andersson wrote:
> I took a stab at implementing EPROBE_DEFER within qcom_rpm-regulator,
> but as it's a mixture of internal and external dependencies (e.g.
> <_s4> vs <_mpp 7>) this became quite messy. I started
> looking at using the dt
On Wed, Mar 04, 2015 at 11:35:43AM -0800, Stephen Boyd wrote:
> There's another problem with this of_parse_cb design. The regulator
> framework requires supplies to be registered before consumers of the
> supplies are registered. So when we register L23 we need to make sure
> it's supply is
On Wed 04 Mar 11:35 PST 2015, Stephen Boyd wrote:
> On 03/02/15 20:25, Bjorn Andersson wrote:
> > + match = of_match_device(rpm_of_match, >dev);
> > + for (reg = match->data; reg->name; reg++) {
> > + vreg = devm_kmalloc(>dev, sizeof(*vreg), GFP_KERNEL);
> > + if (!vreg) {
On 03/02/15 20:25, Bjorn Andersson wrote:
> + match = of_match_device(rpm_of_match, >dev);
> + for (reg = match->data; reg->name; reg++) {
> + vreg = devm_kmalloc(>dev, sizeof(*vreg), GFP_KERNEL);
> + if (!vreg) {
> + dev_err(>dev, "failed to
On 03/02/15 20:25, Bjorn Andersson wrote:
+ match = of_match_device(rpm_of_match, pdev-dev);
+ for (reg = match-data; reg-name; reg++) {
+ vreg = devm_kmalloc(pdev-dev, sizeof(*vreg), GFP_KERNEL);
+ if (!vreg) {
+ dev_err(pdev-dev, failed to
On 03/04/15 16:30, Mark Brown wrote:
On Wed, Mar 04, 2015 at 11:35:43AM -0800, Stephen Boyd wrote:
There's another problem with this of_parse_cb design. The regulator
framework requires supplies to be registered before consumers of the
supplies are registered. So when we register L23 we need
On Wed 04 Mar 11:35 PST 2015, Stephen Boyd wrote:
On 03/02/15 20:25, Bjorn Andersson wrote:
+ match = of_match_device(rpm_of_match, pdev-dev);
+ for (reg = match-data; reg-name; reg++) {
+ vreg = devm_kmalloc(pdev-dev, sizeof(*vreg), GFP_KERNEL);
+ if (!vreg) {
On Wed, Mar 04, 2015 at 03:51:46PM -0800, Bjorn Andersson wrote:
I took a stab at implementing EPROBE_DEFER within qcom_rpm-regulator,
but as it's a mixture of internal and external dependencies (e.g.
pm8921_s4 vs pm8921_mpp 7) this became quite messy. I started
looking at using the dt
On Wed, Mar 04, 2015 at 11:35:43AM -0800, Stephen Boyd wrote:
There's another problem with this of_parse_cb design. The regulator
framework requires supplies to be registered before consumers of the
supplies are registered. So when we register L23 we need to make sure
it's supply is already
On Tue, Mar 03, 2015 at 04:01:43PM -0800, Stephen Boyd wrote:
> On 03/03/15 15:52, Mark Brown wrote:
> > ...but of course we'd never try any operations on it anyway as there
> > would be no consumers.
> Yes sounds fine. The only concern is that we're probably wasting memory
> with things that
On 03/03/15 15:52, Mark Brown wrote:
> On Tue, Mar 03, 2015 at 02:32:35PM -0800, Bjorn Andersson wrote:
>> On Tue 03 Mar 14:09 PST 2015, Stephen Boyd wrote:
>>> How does this work for the case where we may not want to add all the
>>> regulators that a PMIC supports. I'm mostly thinking about the
On Tue, Mar 03, 2015 at 02:32:35PM -0800, Bjorn Andersson wrote:
> On Tue 03 Mar 14:09 PST 2015, Stephen Boyd wrote:
> > How does this work for the case where we may not want to add all the
> > regulators that a PMIC supports. I'm mostly thinking about the case
> > where we want to use the
On Tue 03 Mar 14:09 PST 2015, Stephen Boyd wrote:
> On 03/02/15 20:25, Bjorn Andersson wrote:
> > - config.of_node = pdev->dev.of_node;
> > +static int rpm_reg_probe(struct platform_device *pdev)
> > +{
> > + const struct rpm_regulator_data *reg;
> > + const struct of_device_id *match;
> >
On 03/02/15 20:25, Bjorn Andersson wrote:
> - config.of_node = pdev->dev.of_node;
> +static int rpm_reg_probe(struct platform_device *pdev)
> +{
> + const struct rpm_regulator_data *reg;
> + const struct of_device_id *match;
> + struct regulator_config config = { };
> + struct
Modeling the individual RPM resources as platform devices consumes at
least 12-15kb of RAM, just to hold the platform_device structs. Rework
this to instead have one device per pmic exposed by the RPM.
With this representation we can more accurately define the input pins on
the pmic and have the
On 03/02/15 20:25, Bjorn Andersson wrote:
- config.of_node = pdev-dev.of_node;
+static int rpm_reg_probe(struct platform_device *pdev)
+{
+ const struct rpm_regulator_data *reg;
+ const struct of_device_id *match;
+ struct regulator_config config = { };
+ struct
On 03/03/15 15:52, Mark Brown wrote:
On Tue, Mar 03, 2015 at 02:32:35PM -0800, Bjorn Andersson wrote:
On Tue 03 Mar 14:09 PST 2015, Stephen Boyd wrote:
How does this work for the case where we may not want to add all the
regulators that a PMIC supports. I'm mostly thinking about the case
On Tue, Mar 03, 2015 at 02:32:35PM -0800, Bjorn Andersson wrote:
On Tue 03 Mar 14:09 PST 2015, Stephen Boyd wrote:
How does this work for the case where we may not want to add all the
regulators that a PMIC supports. I'm mostly thinking about the case
where we want to use the
On Tue 03 Mar 14:09 PST 2015, Stephen Boyd wrote:
On 03/02/15 20:25, Bjorn Andersson wrote:
- config.of_node = pdev-dev.of_node;
+static int rpm_reg_probe(struct platform_device *pdev)
+{
+ const struct rpm_regulator_data *reg;
+ const struct of_device_id *match;
+ struct
On Tue, Mar 03, 2015 at 04:01:43PM -0800, Stephen Boyd wrote:
On 03/03/15 15:52, Mark Brown wrote:
...but of course we'd never try any operations on it anyway as there
would be no consumers.
Yes sounds fine. The only concern is that we're probably wasting memory
with things that won't
Modeling the individual RPM resources as platform devices consumes at
least 12-15kb of RAM, just to hold the platform_device structs. Rework
this to instead have one device per pmic exposed by the RPM.
With this representation we can more accurately define the input pins on
the pmic and have the
24 matches
Mail list logo
