[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-fpga
Subject:    Re: Fpga manager help
From:       Alan Tull <atull () kernel ! org>
Date:       2018-02-21 19:25:52
Message-ID: CANk1AXSkryS-KxczSfen41VvoTVafZcuSLDUhcq-kuiqhYjknQ () mail ! gmail ! com
[Download RAW message or body]

On Wed, Feb 21, 2018 at 6:33 AM, Michal Simek <monstr@monstr.eu> wrote:
> Hi, +Grant and Pantelis,

Hi Shubhrajyoti,

I want to make sure I understand your situation here.  So I'll ask
some questions, please let me know if I'm misunderstanding.

>
> On 21.2.2018 06:36, Shubhrajyoti Datta wrote:
>> Hi Alan,
>> Thanks for the help.
>>
>>
>> On Tue, Feb 20, 2018 at 9:54 PM, Alan Tull <atull@kernel.org> wrote:
>>> On Mon, Feb 19, 2018 at 1:09 AM, Shubhrajyoti Datta
>>> <shubhrajyoti.datta@gmail.com> wrote:
>>>
>>> Hi Shubhrajyoti,
>>>
>>>> Hi ,
>>>>
>>>> Some of the FPGA has a  clock  rate that it needs to operate.

The FPGA device needs a clock, right?  This isn't dependent on what
FPGA image is loaded; this is the clock that makes the FPGA device
happy, right?

If that is the case, this is platform specific setup, which can be
done by adding an overlay or it could have been in the base device
tree, right?  The second overlay can do the FPGA programming.

>>>> Wanted some help in having suggestions as to  how should this be done.
>>>>
>>>>
>>>> I tried the bridge approach.
>>>> It worked however since having the possible rate have precompiled is difficult
>>>> because of the wide range of possible frequency.
>>>>
>>>> So i have a first overlay that updates the rate and second overlay
>>>> actually apply.
>>>
>>> IIUC, that sounds right to me.  The base overlay sets up bridges and
>>> fpga regions.  The overlay after that does the programming.  That's
>>> consistent with the fpga-region device tree binding documentation.
>>
>> My options were
>> 1) a first overlay that updates the rate and second overlay
>>  actually apply.

So that's what I'm saying above, IIUC

>> 2) overlay has a pseudo clock driver that sets the rate and acts
>> as a provider of clocks so that other drivers are EPROBE_DEFERED.
>>
>> Do you think I should prefer option 1)
> I would prefer option too.

Option two?

What does option 2 give us that option 1 doesn't?  Seems like more
work, unless there's something in this setup I don't know about, which
seems pretty likely right now.

> If you want to use option 1 then still
> devices in second overlay should reference clock setup in the first.

Now that makes it sound like we're talking about clocks for the
hardware that is in FPGA fabric?

>
> Thanks,
> Michal
>
>
> --
> Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
> w: www.monstr.eu p: +42-0-721842854
> Maintainer of Linux kernel - Xilinx Microblaze
> Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
> U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP SoCs
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]