On 12/03/2019 11:16, Per Jessen wrote:
> Matthias Brugger wrote:
>
>>
>>
>> On 12/03/2019 09:04, Guillaume Gardet wrote:
>>> Hi Per,
>>>
>>>> -----Original Message-----
>>>> From: Per Jessen <[email protected]>
>>>> Sent: 12 March 2019 08:58
>>>> To: [email protected]
>>>> Subject: Re: [opensuse-arm] vcio, STRICT_DEVMEM
>>>>
>>>> Per Jessen wrote:
>>>>
>>>>> Matthias Brugger wrote:
>>>>>
>>>>>> On 10/03/2019 19:35, Per Jessen wrote:
>>>>>>> Well, at least I have a vcio module that builds now, we'll see it
>>>>>>> if it also works.
>>>>>>>
>>>>>>
>>>>>> It seems that there is another thread on this mailing list, but I
>>>>>> wasn't able to find it. What do you want to achieve?
>>>>>
>>>>> Hi Matthias,
>>>>>
>>>>> nothing too complex I hope, I just want to control a series of
>>>>> WS2812 LEDs, using the code/utilities from
>>>>>
>>>>> https://github.com/jgarff/rpi_ws281x
>>>>
>>
>> I had a look on that code and it looks like a hack to me.
>
> I can't really comment - of the couple of projects I looked at (related
> to ws2812), this looked the most complete/useful.
>
>>>> I built the vcio module, seems to work fine. Then I built the
>>>> kernel without STRICT_DEVMEM and I can now control a string of
>>>> WS2812 LEDs.
>>>
>>> Thanks for your feedback!
>>> The vcio module can probably be upstreamed, or at least packaged in
>>> OBS, I guess.
>>>
>>
>> I don't think this is the right approach for upstream. If we want to
>> control these leds, then we should write a kernel driver which uses
>> the mbox and not implement detection etc in user-space.
>> If you want to use a LED matrix, then I think this is a good candidate
>> for a tinydrm driver in the kernel.
>
> again, I can't really comment on what is right or good - so just my
> observations:
>
> getting the vcio module to work was no big deal, just required a bit of
> research - I think even a relative newbie would manage to get it to
> work.
>
Well what I wanted to say is: openSUSE uses the mainline kernel. If you want
your LED matrix to work out-of-the-box with openSUSE then you (or someone) will
need to find a solution that works with upstream.
The solution that raspbian gives us does not full fill this criteria. IMHO:
- We don't want to discover the HW from user-space reading the device-tree
compatible etc.
- We don't want to access the mailbox driver from user-space to control a PWM,
we want to do that in the kernel and use the sysfs
- We don't want to implement a frame buffer in userspace that get's passed
through the mailbox driver to the kernel. Instead we want to use tinydrm that
exposes a frame buffer to us. And, if needed, have a userspace library (for C,
golang, you name it) that interacts with that device.
Just in case someone with a LED matrix wants to get this working upstream :)
Regards,
Matthias
> About STRICT_DEVMEM - had I been able to disable with a kernel argument,
> that would have been really nice. In 2008, Bernhard Walle @ suse also
> proposed a sysctl "dev.mem.restricted", but I guess that didn't go
> through.
>
>
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
