<kyak>
ysionneau: well, that's good, but it's in AUR, so not really supported. You will have to worry about creating rc-files (or whatever is used in OpenRC) by yourself
<kyak>
being the arch linux user for several years now i'm convinced that i want to stay as close to arch upstream as possible
<kyak>
otherwise strange things can happen :)
<ysionneau>
sure it seems you are right: the officially supported stuff is systemd
FrankBlues has quit [Remote host closed the connection]
<mth>
apelete: I'm not sure 0 patches is achievable, but we should certainly try to get it as low as possible
<mth>
larsc: something we'd need to get 4740 and 4770 closer is pinctrl for 4740
<larsc>
yes
<mth>
to merge with 4780, devicetree support would be required
wej has quit [Ping timeout: 250 seconds]
<larsc>
I did add devicetree support to most drivers a while ago, never pushed it though
<mth>
we have a pinctrl driver for 4770; I'm not sure it's entirely as it should be as I'm having trouble understanding part of the pinctrl design
<mth>
but it is working at least, so it could be used as a starting point perhaps
<larsc>
I think the driver will probably be the same for most jz47xx chips
<larsc>
just the pinctrl tables will be different
<mth>
should those tables be in the driver, in the platform code or in devicetree?
<mth>
ImgTec put them in devicetree, but me and pcercuei were wondering if that is the right place
<mth>
since it's SoC specific, not board specific
<mth>
on the other hand, it might save memory if only the dt tables for the active SoC has to be loaded
<larsc>
its ok to have SoC specific stuff in the dt
<apelete>
mth: great, let's talk with pcercuei tomorrow to see how he feels about it
<apelete>
if everyone is ok we'll choose which patches to start with
<mth>
one thing I recently changed is that for PWM pins, we used to bind them to the PWM driver, but when binding them to the PWM-using driver (pwm-backlight, pwm-haptic) the power management came for free
<mth>
but I wouldn't know whether that is the right way to do it
<mth>
and what surprised me is that a pin can have a gpio owner separate from a mux owner
<mth>
while that works fine for reading, it would cause problems if you'd change direction to output
<larsc>
I never really understood pinctrl either
wej has joined #qi-hardware
jivs has joined #qi-hardware
<DocScrutinizer05>
I never understood DT concept. It's kinda flawed. In my book a hw design is simply too complex and individual to get formally described in anything less bloated than the drivers code itself. Even the drivers only describe how to handle certain aspects of it
<whitequark>
I suppose the idea is to pick low-hanging fruit. 80% of easily configurable stuff
<DocScrutinizer05>
DT would only work when it was the parameter set of a complete physical emulation of the hardware
<whitequark>
and handle the rest with hardcoded quirks and such
<DocScrutinizer05>
possibly
<whitequark>
there's some merit to that idea imo.
porchao has joined #qi-hardware
porchaso0 has quit [Ping timeout: 268 seconds]
<DocScrutinizer05>
sure
<DocScrutinizer05>
intention is good, I however doubt it ever will rach a convenient "maturity"
<DocScrutinizer05>
reach*
<DocScrutinizer05>
and for embedded I favor the approach of a tailored-to-fit kernel instead of a general-purpose on-size-fits-all one
<DocScrutinizer05>
one*
<whitequark>
DT solves the need of running the same kernel on differing hw
<whitequark>
which is even more relevant with ARM laptops and similar hardware
<DocScrutinizer05>
err, is DT a build-time thing or a run time thing?
<whitequark>
as I understand you can select different trees based on board ID
<whitequark>
so you only need one kernel per microarch, rather than one kernel per board
<DocScrutinizer05>
exactly
<DocScrutinizer05>
drivers adapt during boot time, according to DT
<DocScrutinizer05>
aiui
<whitequark>
it would suck to ship debian with eight thousand different kernels for every ARM laptop out there :p
<whitequark>
yes
<whitequark>
DT doesn't solve some abstract goal of removing the need to write C or something, it's mainly this
<DocScrutinizer05>
>>and for embedded I favor the approach of a tailored-to-fit kernel instead of a general-purpose on-size-fits-all one<<
<whitequark>
well, see above.
<whitequark>
it doesn't scale
<DocScrutinizer05>
it does, when you build a OS / distro for your hw
<larsc>
DT gets rid of boilerplate code, that's all it does...
<larsc>
previoulsy you'd have one C file which has doeszen of lines of device_register(...)
<larsc>
this is now in the DT
<DocScrutinizer05>
DT might work for laptops and desktop PCs and servers, all based on 8086 ISA, with a peretty limited number of peripherals that all are connected via well defined busses like PCI etc
<whitequark>
on x86 you don't need DT at all
<whitequark>
since it's by and large plug and play
<DocScrutinizer05>
my take on all that is that you need drivers tailored to fit your particular hardware platform, not a single chip in that platform. But then that's just my take on it
<larsc>
nobody wants to write the same driver 10 times
<DocScrutinizer05>
yes, I know
<DocScrutinizer05>
nobody wants to create a new hw platform 10 times either
<DocScrutinizer05>
but in the end that's exactly what EE does
<whitequark>
a hw platform is released once however source has to be maintained essentially forever
<whitequark>
so you need a different approach to manage complexity here
<DocScrutinizer05>
yes, I know
<DocScrutinizer05>
and there's hardly a universal approach
<DocScrutinizer05>
it's not exactly like if a new embedded device was identical to the last one, just with 5 instead of 4 PCI slots and a quadcore instead of a dualcore
<whitequark>
you mean they don't do this with 3/4 of android phones? :]
<DocScrutinizer05>
or maybe let's put it this way: the changes you face in new hw platforms are kinda 'analog', not a discrete number of alternative options
<whitequark>
no one says the changes should be *only* to DT. you modify drivers as well, but the combo allows you to keep modifications to the minimum
<DocScrutinizer05>
so a) you need patches to the drivers anyway. And b) your drivers supporting other alternative hw platforms as well is mere cruft
<whitequark>
it's not a magic universal configuration interface, just a handy abstraction for common tasks
<DocScrutinizer05>
exactly
<DocScrutinizer05>
I simply don't see how you get handled by DT and universal drivers stuff like e.g. a mux in the camera interface that allows to connect 2 cam modules alternatively to the single SoC cam bus
<DocScrutinizer05>
sure you could write a driver that allows stuff like a mux in cam bus, but do you want to upstream that?
<DocScrutinizer05>
or take the fingerprint sensor that same time can act like a "trackball". Do you integrate fingerprint functions into all mouse drivers?
<DocScrutinizer05>
or mouse function into the generic fingerprint reader driver?
<DocScrutinizer05>
and how makes that sense on all other devices that don't offer using fingerprint reader as trackball/pointer
<whitequark>
the answer is "same as without DT", really
<DocScrutinizer05>
I'm sure resp I even know there are solutions for the above two cases which do not automatically introduce layering conflicts and stuff. But maybe I made my point regarding universal drivers and highly proprietary resp unique embedded platforms
jivs has quit [Ping timeout: 240 seconds]
jivs has joined #qi-hardware
jivs has quit [Quit: Leaving]
woakas has quit [Ping timeout: 250 seconds]
woakas has joined #qi-hardware
kristianpaul has quit [Ping timeout: 240 seconds]
kristianpaul has joined #qi-hardware
kristianpaul has joined #qi-hardware
arhuaco has joined #qi-hardware
DocScrutinizer51 has quit [Ping timeout: 260 seconds]