Re: [PATCH v2 2/3] ARM: dts: socfpga: fpga bridges bindings docs

[Pantelis Antoniou]

Hi Steffen,

> On Oct 27, 2014, at 17:23 , Steffen Trumtrar <s.trumtrar@xxxxxxxxxxxxxx> wrote:
> 
> Hi!
> 
> On Mon, Oct 27, 2014 at 01:54:20PM +0200, Pantelis Antoniou wrote:
>> Hi Stefen,
>> 
>>> On Oct 25, 2014, at 17:42 , Steffen Trumtrar <s.trumtrar@xxxxxxxxxxxxxx> wrote:
>>> 
>>> Hi Pantelis!
>>> 
>>> On Fri, Oct 24, 2014 at 12:20:53PM +0300, Pantelis Antoniou wrote:
>>>> Hi Stefan, Allan,
>>>> 
>>>> Sorry, havenât had a chance to review all this yet; will do so in the weekend.
>>>> Just wanted to pop in and comment on a few things.
>>>> 
>>>>> On Oct 24, 2014, at 10:00 AM, Steffen Trumtrar <s.trumtrar@xxxxxxxxxxxxxx> wrote:
>>>>> 
>>>>> Hi!
>>>>> 
>>>>> On Thu, Oct 23, 2014 at 06:51:06PM -0500, atull@xxxxxxxxxxxxxxxxxxxxx wrote:
>>>>>> From: Alan Tull <atull@xxxxxxxxxxxxxxxxxxxxx>
>>>>> 
>>>>> (...)
>>>>> 
>>>>>> diff --git a/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..bc24a2e
>>>>>> --- /dev/null
>>>>>> +++ b/Documentation/devicetree/bindings/fpga/altera-hps2fpga-bridge.txt
>>>>>> @@ -0,0 +1,53 @@
>>>>>> +Altera FPGA/HPS Bridge Driver
>>>>>> +
>>>>>> +This driver manages a bridge between a FPGA and a host processor system (HPS).
>>>>>> +User space can enable or disable the bridge by writing a "1" or a "0",
>>>>>> +respectively, to its enable file under bridge's entry in
>>>>>> +/sys/class/fpga-bridge.  Typically, one disables the bridges before
>>>>>> +reprogramming the FPGA.  Once the FPGA is reprogrammed, the bridges are
>>>>>> +reenabled.
>>>>>> +
>>>>> 
>>>>> NAK.
>>>>> 
>>>>> This is all linux specific and doesn't belong here.
>>>>> 
>>>> 
>>>> We know. The DT spec hasnât been updated for a while, and this is going to be
>>>> part of what we want to do with the restarting of the ePAPR spec process.
>>>> 
>>> 
>>> As we don't have a new spec yet, I go with the current state of the art.
>>> And I don't see how "file under ... /sys/class/fpga-bridge" fits the
>>> current spec.
>>> 
>>>> So absolutes like âDT is a hardware description only" might be too strong statements, that
>>>> do not work in practice anymore.
>>>> 
>>>> Thereâs no such thing as pure hardware devices lately - there is always a configuration
>>>> component; some of it OS specific, some of it not.
>>>> 
>>> 
>>> If it really is necessary, I'm not against it, don't get me wrong.
>>> But in the grand scheme I wouldn't say that this fits my experience.
>>> There are some devices that need configuration and often when it is
>>> done in the DT, it is just a shortcut or not thought through.
>>> And can be also introspected dynamically. With some discussion on the
>>> list these bindings often change.
>>> 
>> 
>> Already answered and given a possible way this might work; admittedly this
>> specific example is not a good fit for what I was trying to say, but whatever.
>> Letâs get the ball rolling.
>> 
> 
> I would be okay with chosen-node. Not for this driver; but in general.
> 

Letâs figure out how to do it thenâ

>>> Regarding OS specifics: already there, e.g. console setup in the chosen node.
>>> And other things I saw are ethernet aliases just for u-boot. Not a problem
>>> of the spec, just a problem of u-boot and unneccessary "configuration".
>>> Just to fix a bad bootloader. barebox can handle this without any
>>> such stuff. Maybe we should integrate the DT "overlays" barebox uses into
>>> the in-kernel DTs as well...but does it really help/interest someone who
>>> decides to use u-boot where barebox stores its environment? I guess not.
>>> 
>> 
>> Although Iâm not against having DT overlays in the bootloader, I only see them
>> as a method that helps a platform developer express things easier. I am completely
>> against having the kernel tied to any particular bootloader.
>> 
>> Weâve all been through the hell where a kernel only boots if the bootloader has 
>> setup the platform âcorrectlyâ. This âcorrectlyâ has a very loose definition and
>> 99/100 times is extremely badly documented or not at all.
>> 
>> IMHO the bootloader should (as part of the normal boot sequence) only setup the
>> absolutely bare minimum and then pass control to the kernel as soon as possible.
>> 
>> The full featured bootloader environment should only be presented when the user
>> requests so.
>> 
> 
> Totally agree. The kernel shouldn't be tied to any bootloader if at all possible
> (the SoCFPGA is an especially bad example here again, as the pinmuxing can only
> happen in the bootloader).

Iâm not familiar with SoCFPGA. Why pinmuxing is only possible in the bootloader?
Canât the bootloader configure the minimum pinmux config and then have Linux setup
the rest?

If weâre feeling particularly nasty, we might just require bootloaders to clean the
hardware state before passing control to Linux (besides memory controller setup) and
see whatâs broken.

> But should the DT include stuff than, that is only interesting for linux?
> 

Like it or not itâs Linux thatâs in the forefront of many hardware designs.

There are configuration settings in DT that are part of the way hardware is presented to
Linux and user-space, and have been for quite some time. Weâve been pretending they donât
exist, but they are thereâ

We have a chance to try to get it right, so why not do so?

>>>> We have to be engaged in the process and figure out how to update the spec for what is
>>>> now the state of the art in the industry.
>>>> 
>>> 
>>> Again, not against that if it is necessary. For example your overlay stuff might
>>> be a good update to the spec. Would be better if it is official instead of a "hack".
>>> I want that for SoCFPGA.
>>> 
>>> But having looked at one or two vendor kernels+DTs, the state of the art in the
>>> industry is: using DT wrong. (And doing HW wrong, which makes some updates to the
>>> ePAPR necessary ;-))
>>> 
>> 
>> Vendor H/W, vendor DT and a crack pipe. Or as I call it Monday.
>> 
> 
> ;-)
> 
> Regards,
> Steffen
> 

Regards

â Pantelis

> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/