* [U-Boot] New UCLASS_PINCTRL driver - probe is not called for all nodes
@ 2016-11-15 13:56 Konstantin Porotchkin
2016-11-18 1:14 ` Simon Glass
0 siblings, 1 reply; 4+ messages in thread
From: Konstantin Porotchkin @ 2016-11-15 13:56 UTC (permalink / raw
To: u-boot
Hi, All,
I am currently porting the Marvell (mvebu) pin control driver for Armada-8K
family to the current u-boot sources.
The Armada 8K SoC is a hybrid chip that contains several interconnected
dies in a single package.
Each such device (AP, CP0, CP1) has an independent pin controller with
different memory mapping.
The DTS for such configuration looks like the following:
/ {
ap806 {
config-space {
pinctl: pinctl at 6F4000 {
...
};
};
};
cp110-master {
config-space {
cpm_pinctl: pinctl at 44000 {
...
};
};
};
cp110-slave {
config-space {
cps_pinctl: pinctl at 44000 {
...
};
};
};
};
I expect that my driver "probe" method will be called 3 times - one for
every controller.
However, according to my test, only the first controller is probed
(pinctl at 6F4000).
Two others are listed in the DM tree, but are not active (not probed).
I can do a trick and sequentially call uclass_get_device() function for
the UCLASS_PINCTRL type, causing all 3 controller to be probed and
activated.
However I think this is not the way it should work.
Is my assumption wrong and such hybrid devices should use the above trick
for bringing up all controllers in the package?
Thank you beforehand for your help
Konstantin
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] New UCLASS_PINCTRL driver - probe is not called for all nodes
2016-11-15 13:56 [U-Boot] New UCLASS_PINCTRL driver - probe is not called for all nodes Konstantin Porotchkin
@ 2016-11-18 1:14 ` Simon Glass
2016-11-20 11:33 ` Konstantin Porotchkin
0 siblings, 1 reply; 4+ messages in thread
From: Simon Glass @ 2016-11-18 1:14 UTC (permalink / raw
To: u-boot
Hi Konstantin,
On 15 November 2016 at 06:56, Konstantin Porotchkin <kostap@gmail.com> wrote:
> Hi, All,
>
> I am currently porting the Marvell (mvebu) pin control driver for Armada-8K
> family to the current u-boot sources.
> The Armada 8K SoC is a hybrid chip that contains several interconnected
> dies in a single package.
> Each such device (AP, CP0, CP1) has an independent pin controller with
> different memory mapping.
> The DTS for such configuration looks like the following:
> / {
> ap806 {
> config-space {
> pinctl: pinctl at 6F4000 {
> ...
> };
> };
> };
> cp110-master {
> config-space {
> cpm_pinctl: pinctl at 44000 {
> ...
> };
> };
> };
> cp110-slave {
> config-space {
> cps_pinctl: pinctl at 44000 {
> ...
> };
> };
> };
> };
>
> I expect that my driver "probe" method will be called 3 times - one for
> every controller.
> However, according to my test, only the first controller is probed
> (pinctl at 6F4000).
> Two others are listed in the DM tree, but are not active (not probed).
>
> I can do a trick and sequentially call uclass_get_device() function for
> the UCLASS_PINCTRL type, causing all 3 controller to be probed and
> activated.
> However I think this is not the way it should work.
> Is my assumption wrong and such hybrid devices should use the above trick
> for bringing up all controllers in the package?
They should be activated automatically by devices that use them. This
is the pinctrl-0 property in the device. Can you take a look at why
that is not working?
Specifically, see pinctrl_select_state() in device_probe().
Regards,
Simon
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] New UCLASS_PINCTRL driver - probe is not called for all nodes
2016-11-18 1:14 ` Simon Glass
@ 2016-11-20 11:33 ` Konstantin Porotchkin
2016-11-24 2:21 ` Simon Glass
0 siblings, 1 reply; 4+ messages in thread
From: Konstantin Porotchkin @ 2016-11-20 11:33 UTC (permalink / raw
To: u-boot
Hi, Simon,
Thank you for your reply.
In order to activate pin control function using "pinctrl-0" property, the
device driver itself has to be aware of the pin control existence, right?
So if I put such property under SPI controller, the SPI controller driver
has to handle call to the pin control driver methods, right?
However my current target is to trigger setup for all existent pin
controllers regardless of the connected device entries.
Unfortunately not all drivers are aware of the pin controller properties.
For instance current SPI and I2C drivers does not trigger the pin
controller "probe" method regardless of the "pinctrl-0" property presence
in FDT.
Regards
Konstantin
On Fri, Nov 18, 2016 at 3:14 AM, Simon Glass <sjg@chromium.org> wrote:
> Hi Konstantin,
>
> On 15 November 2016 at 06:56, Konstantin Porotchkin <kostap@gmail.com>
> wrote:
> > Hi, All,
> >
> > I am currently porting the Marvell (mvebu) pin control driver for
> Armada-8K
> > family to the current u-boot sources.
> > The Armada 8K SoC is a hybrid chip that contains several interconnected
> > dies in a single package.
> > Each such device (AP, CP0, CP1) has an independent pin controller with
> > different memory mapping.
> > The DTS for such configuration looks like the following:
> > / {
> > ap806 {
> > config-space {
> > pinctl: pinctl at 6F4000 {
> > ...
> > };
> > };
> > };
> > cp110-master {
> > config-space {
> > cpm_pinctl: pinctl at 44000 {
> > ...
> > };
> > };
> > };
> > cp110-slave {
> > config-space {
> > cps_pinctl: pinctl at 44000 {
> > ...
> > };
> > };
> > };
> > };
> >
> > I expect that my driver "probe" method will be called 3 times - one for
> > every controller.
> > However, according to my test, only the first controller is probed
> > (pinctl at 6F4000).
> > Two others are listed in the DM tree, but are not active (not probed).
> >
> > I can do a trick and sequentially call uclass_get_device() function for
> > the UCLASS_PINCTRL type, causing all 3 controller to be probed and
> > activated.
> > However I think this is not the way it should work.
> > Is my assumption wrong and such hybrid devices should use the above trick
> > for bringing up all controllers in the package?
>
> They should be activated automatically by devices that use them. This
> is the pinctrl-0 property in the device. Can you take a look at why
> that is not working?
>
> Specifically, see pinctrl_select_state() in device_probe().
>
> Regards,
> Simon
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* [U-Boot] New UCLASS_PINCTRL driver - probe is not called for all nodes
2016-11-20 11:33 ` Konstantin Porotchkin
@ 2016-11-24 2:21 ` Simon Glass
0 siblings, 0 replies; 4+ messages in thread
From: Simon Glass @ 2016-11-24 2:21 UTC (permalink / raw
To: u-boot
Hi Konstantin,
On 20 November 2016 at 04:33, Konstantin Porotchkin <kostap@gmail.com> wrote:
> Hi, Simon,
>
> Thank you for your reply.
> In order to activate pin control function using "pinctrl-0" property, the
> device driver itself has to be aware of the pin control existence, right?
> So if I put such property under SPI controller, the SPI controller driver
> has to handle call to the pin control driver methods, right?
No, this happens automatically in device_probe().
>
> However my current target is to trigger setup for all existent pin
> controllers regardless of the connected device entries.
> Unfortunately not all drivers are aware of the pin controller properties.
> For instance current SPI and I2C drivers does not trigger the pin controller
> "probe" method regardless of the "pinctrl-0" property presence in FDT.
Provided they have the correct properties in the DT, this should work
without effort.
>
> Regards
> Konstantin
>
> On Fri, Nov 18, 2016 at 3:14 AM, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi Konstantin,
>>
>> On 15 November 2016 at 06:56, Konstantin Porotchkin <kostap@gmail.com>
>> wrote:
>> > Hi, All,
>> >
>> > I am currently porting the Marvell (mvebu) pin control driver for
>> > Armada-8K
>> > family to the current u-boot sources.
>> > The Armada 8K SoC is a hybrid chip that contains several interconnected
>> > dies in a single package.
>> > Each such device (AP, CP0, CP1) has an independent pin controller with
>> > different memory mapping.
>> > The DTS for such configuration looks like the following:
>> > / {
>> > ap806 {
>> > config-space {
>> > pinctl: pinctl at 6F4000 {
>> > ...
>> > };
>> > };
>> > };
>> > cp110-master {
>> > config-space {
>> > cpm_pinctl: pinctl at 44000 {
>> > ...
>> > };
>> > };
>> > };
>> > cp110-slave {
>> > config-space {
>> > cps_pinctl: pinctl at 44000 {
>> > ...
>> > };
>> > };
>> > };
>> > };
>> >
>> > I expect that my driver "probe" method will be called 3 times - one for
>> > every controller.
>> > However, according to my test, only the first controller is probed
>> > (pinctl at 6F4000).
>> > Two others are listed in the DM tree, but are not active (not probed).
>> >
>> > I can do a trick and sequentially call uclass_get_device() function for
>> > the UCLASS_PINCTRL type, causing all 3 controller to be probed and
>> > activated.
>> > However I think this is not the way it should work.
>> > Is my assumption wrong and such hybrid devices should use the above
>> > trick
>> > for bringing up all controllers in the package?
>>
>> They should be activated automatically by devices that use them. This
>> is the pinctrl-0 property in the device. Can you take a look at why
>> that is not working?
>>
>> Specifically, see pinctrl_select_state() in device_probe().
Regards,
Simon
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-11-24 2:21 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-11-15 13:56 [U-Boot] New UCLASS_PINCTRL driver - probe is not called for all nodes Konstantin Porotchkin
2016-11-18 1:14 ` Simon Glass
2016-11-20 11:33 ` Konstantin Porotchkin
2016-11-24 2:21 ` Simon Glass
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.