On 17/09/2020 22:23, Dario Binacchi wrote:
Hi Grygorii,
Il 17/09/2020 08:57 Grygorii Strashko <grygorii.stras...@ti.com> ha scritto:
Hi Dario,
On 06/09/2020 15:08, Dario Binacchi wrote:
The series was born from the need to manage the PWM backlight of the
display connected to my beaglebone board. To hit the target, I had to
develop drivers for PWM management which in turn relied on drivers for
managing timers and clocks, all developed according to the driver model.
My intention was to use the SoC-specific API only at strictly necessary
points in the code. My previous patches for migrating the AM335x display
driver to the driver model had required the implementation of additional
functions outside the concerns of the driver, (settings for dividing the
pixel clock rate, configuring the display DPLL rate, ....) not being
able to use the API of the related clock drivers. This series shouldn't
have repeated the same kind of mistake. Furthermore, I also wanted to fix
that kind of forced choice. Almost everything should have been accessible
via the driver model API. In the series there are also some patches that
could be submitted separately, but which I have however inserted to avoid
applying future patches to incorporate them.
With this last consideration, I hope I have convincingly justified the
large number of patches in the series.
The patch enabling address translation into a CPU physical address from
device-tree even in case of crossing levels with #size-cells = <0>, is
crucial for the series. The previous implementation was unable to
perform the address translation required by the am33xx device tree.
I tried to apply in a conservative way as few changes as possible and
to verify the execution of all the tests already developed, as well as
the new ones I added for the new feature.
Thank you for you patches.
In my opinion it's better if you split this series as it is
- too big
- modifies different subsystems
- contains as fixes as new features
I agree with you.
I've been thinking about it for some time too.
Hope in the weekend. Anyway, next patches upload
will split this series.
I'd recommend to separate
- fixes first, like
clk: remove a redundant header
arch: sandbox: fix typo in clk.h
fdt: translate address if #size-cells = <0>
omap: timer: fix the rate setting
dm: core: add a function to decode display timings
..
- clk patches
- pwm/backlight patches
- video: omap: panel patches
And I'd recommend not to port device tree bindings in u-boot as it's just
duplication of
kernel binding which u-boot shell follow.
Just providing links to Kernel binding in commit messages should be enough.
I have already added device-tree bindings in patches that have been accepted.
No one has ever
pointed out what you recommend to me. Also, the doc/device-tree-bindings
directory seems very
crowded. I have read that device-tree bindings are often evolving and I think
that not copying
them in uboot does not favor their consultation. Also I wonder if it is enough
to report in the
commit message the kernel file path or to refer to a particular file version by
specifying the
commit sha1. Can you help me figure out what to do?
It depends, if you porting code to u-boot it's most probably that kernel bindings
evolved already (>1 commit).
In such case link on file may be preferable, i think.
if it's new driver which just has been accepted to the Kernel with bindings -
it could be sha1.
Note. Common practice for u-boot is to accept new drivers only after their
binding accepted in Linux Kernel.
--
Best regards,
grygorii
