GSoC PRU: AM35xx Clock driver

[Nils Hölscher]

On Wed, 24 Jul 2019 at 15:14, Vijay Kumar Banerjee <vijaykumar9597 at gmail.com>
wrote:

>
>
>
> On Wed, Jul 24, 2019 at 6:36 PM Nils Hölscher <nilhoel1 at gmail.com> wrote:
>
>> Hi again,
>>
>> Hi Nils
>
>> I just decompiled my device tree and checked.
>> The probe code of the prcm driver is as follows:
>> "
>> static int
>> am335x_prcm_probe(device_t dev)
>> {
>>     printk("am335x_prcm_probe\n");
>>
>>     if (!ofw_bus_status_okay(dev)){
>>         printk("ofw_bus_status_not_okay\n");
>>         return (ENXIO);
>>     }
>>
>> Do you get the "ofw_bus_status_not_okay" print ?
>
Yes. But I also see the other print. except the success one.

>     if (ofw_bus_is_compatible(dev, "ti,am3-prcm")) {
>>         device_set_desc(dev, "AM335x Power and Clock Management");
>>         printk("PROBE SUCESSFULL\n");
>>         return(BUS_PROBE_DEFAULT);
>>     }
>>     printk("ofw_bus incompatible\n");
>>     return (ENXIO);
>> }
>> "
>> So it seems the prcm part in the device tree has to be compatible to
>> "ti,am3-prcm".
>> The thing is the decompiled device tree states just that:
>> "
>> prcm at 0 {
>>                         compatible = "ti,am3-prcm\0simple-bus";
>>
> In my device tree, it runs successfully and the decompiled compatible
> looks like  :
> ```
>             prcm at 200000 {
>                 compatible = "ti,am3-prcm";
>                 reg = < 0x200000 0x4000 >;
>                 linux,phandle = < 0x4a >;
>                 phandle = < 0x4a >;
> ```
>
OK, this is awkward, cause we both should have used the same sources.

>                         reg = <0x00 0x2000>;
>>                         #address-cells = <0x01>;
>>                         #size-cells = <0x01>;
>>                         ranges = <0x00 0x00 0x2000>;
>>                         phandle = <0x5a>;
>> [...]
>> "
>> Any ideas would help, cause I am currently not able to understand this
>> behaviour.
>> Also without this driver even the dev_usb_bbb driver shouldn't work.
>> However it attaches because it doesn't check for the clocks error code.
>>
> I remember testing this a few days ago for my fb drivers and it was
> attaching alright,
> if I remember correctly. If changing the dtb doesn't work for you, I won't
> mind checking
> again, this will give me a hint for the display issue as well.
>
I will keep you updated on this.
Would you be so kind and send me your compiled device tree?
>
>
>>
> Best,
>> Nils
>>
>>
>>
>> On Wed, 24 Jul 2019 at 14:43, Nils Hölscher <nilhoel1 at gmail.com> wrote:
>>
>>> Hi,
>>>
>>> I just found out that the prcm driver fails to probe on the simplebus
>>> and therefore cannot apply itself.
>>> Seems like I am back to checking dtb.
>>>
>>> Best,
>>> Nils
>>>
>>> On Tue, 23 Jul 2019 at 14:26, Nils Hölscher <nilhoel1 at gmail.com> wrote:
>>>
>>>> Hi,
>>>>
>>>> After debugging with printk, didn't get the module loading working as
>>>> suggested by Sebastian.
>>>> I just found out that my PRU driver can't be attached, cause the AM35xx
>>>> clock driver isn't loaded.
>>>> The driver can be found her:
>>>>
>>>> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c
>>>>
>>>> Can anyone tell me how to load this driver and obisouly before I
>>>> initialize my BSD modules?
>>>>
>>>> FYI: The code line that fails is this one, cause the driver hasn't been
>>>> initialized.
>>>>
>>>> https://github.com/RTEMS/rtems-libbsd/blob/610349693dd31d8b0efd33776516b7187cc5cda2/freebsd/sys/arm/ti/am335x/am335x_prcm.c#L854
>>>>
>>>> Thanks,
>>>> Nils
>>>>
>>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190724/edea5aad/attachment-0002.html>