The UART clock is initialised to be as close to the requested
frequency as possible without exceeding it. Now that there is a
clock manager that returns the actual frequencies, an expected
48MHz clock is reported as 47999625. If the requested baudrate
== requested clock/16, there is no headroom and the slight
reduction in actual clock rate results in failure.
If increasing a clock by less than 0.1% changes it from ..999..
to ..000.., round it up.
This is reworked version of a downstream fix:
https://github.com/raspberrypi/linux/commit/ab3f1b39537f6d3825b8873006fbe2fc5ff057b7
Cc: Phil Elwell <[email protected]>
Signed-off-by: Ivan T. Ivanov <[email protected]>
---
Changes since v1
Make bcm2835_clock_round() static to fix following warning
when compiling for riscv:
drivers/clk/bcm/clk-bcm2835.c:997:15: warning: no previous prototype for 'bcm2835_clock_round' [-Wmissing-prototypes]
Reported-by: kernel test robot <[email protected]>
drivers/clk/bcm/clk-bcm2835.c | 30 ++++++++++++++++++++++++++++--
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
index 3ad20e75fd23..c29b643d1bf5 100644
--- a/drivers/clk/bcm/clk-bcm2835.c
+++ b/drivers/clk/bcm/clk-bcm2835.c
@@ -502,6 +502,8 @@ struct bcm2835_clock_data {
bool low_jitter;
u32 tcnt_mux;
+
+ bool round_up;
};
struct bcm2835_gate_data {
@@ -992,12 +994,30 @@ static long bcm2835_clock_rate_from_divisor(struct bcm2835_clock *clock,
return temp;
}
+static unsigned long bcm2835_clock_round(unsigned long clk)
+{
+ unsigned long scaler;
+
+ /*
+ * If increasing a clock by less than 0.1% changes it
+ * from ..999.. to ..000.., round up.
+ */
+ scaler = 1;
+ while (scaler * 100000 < clk)
+ scaler *= 10;
+ if ((clk + scaler - 1) / scaler % 1000 == 0)
+ clk = (clk / scaler + 1) * scaler;
+
+ return clk;
+}
+
static unsigned long bcm2835_clock_get_rate(struct clk_hw *hw,
unsigned long parent_rate)
{
struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
struct bcm2835_cprman *cprman = clock->cprman;
const struct bcm2835_clock_data *data = clock->data;
+ unsigned long rate;
u32 div;
if (data->int_bits == 0 && data->frac_bits == 0)
@@ -1005,7 +1025,12 @@ static unsigned long bcm2835_clock_get_rate(struct clk_hw *hw,
div = cprman_read(cprman, data->div_reg);
- return bcm2835_clock_rate_from_divisor(clock, parent_rate, div);
+ rate = bcm2835_clock_rate_from_divisor(clock, parent_rate, div);
+
+ if (data->round_up)
+ rate = bcm2835_clock_round(rate);
+
+ return rate;
}
static void bcm2835_clock_wait_busy(struct bcm2835_clock *clock)
@@ -2142,7 +2167,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
.div_reg = CM_UARTDIV,
.int_bits = 10,
.frac_bits = 12,
- .tcnt_mux = 28),
+ .tcnt_mux = 28,
+ .round_up = true),
/* TV encoder clock. Only operating frequency is 108Mhz. */
[BCM2835_CLOCK_VEC] = REGISTER_PER_CLK(
--
2.26.2
Hi Stefan,
Please, could you take a look into following patch?
Thanks!
Ivan
On 04-04 15:51, Ivan T. Ivanov wrote:
> Subject: [PATCH v2] clk: bcm2835: Round UART input clock up
> Message-Id: <[email protected]>
>
> The UART clock is initialised to be as close to the requested
> frequency as possible without exceeding it. Now that there is a
> clock manager that returns the actual frequencies, an expected
> 48MHz clock is reported as 47999625. If the requested baudrate
> == requested clock/16, there is no headroom and the slight
> reduction in actual clock rate results in failure.
>
> If increasing a clock by less than 0.1% changes it from ..999..
> to ..000.., round it up.
>
> This is reworked version of a downstream fix:
> https://github.com/raspberrypi/linux/commit/ab3f1b39537f6d3825b8873006fbe2fc5ff057b7
>
> Cc: Phil Elwell <[email protected]>
> Signed-off-by: Ivan T. Ivanov <[email protected]>
> ---
> Changes since v1
> Make bcm2835_clock_round() static to fix following warning
> when compiling for riscv:
> drivers/clk/bcm/clk-bcm2835.c:997:15: warning: no previous prototype for 'bcm2835_clock_round' [-Wmissing-prototypes]
> Reported-by: kernel test robot <[email protected]>
>
> drivers/clk/bcm/clk-bcm2835.c | 30 ++++++++++++++++++++++++++++--
> 1 file changed, 28 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
> index 3ad20e75fd23..c29b643d1bf5 100644
> --- a/drivers/clk/bcm/clk-bcm2835.c
> +++ b/drivers/clk/bcm/clk-bcm2835.c
> @@ -502,6 +502,8 @@ struct bcm2835_clock_data {
> bool low_jitter;
>
> u32 tcnt_mux;
> +
> + bool round_up;
> };
>
> struct bcm2835_gate_data {
> @@ -992,12 +994,30 @@ static long bcm2835_clock_rate_from_divisor(struct bcm2835_clock *clock,
> return temp;
> }
>
> +static unsigned long bcm2835_clock_round(unsigned long clk)
> +{
> + unsigned long scaler;
> +
> + /*
> + * If increasing a clock by less than 0.1% changes it
> + * from ..999.. to ..000.., round up.
> + */
> + scaler = 1;
> + while (scaler * 100000 < clk)
> + scaler *= 10;
> + if ((clk + scaler - 1) / scaler % 1000 == 0)
> + clk = (clk / scaler + 1) * scaler;
> +
> + return clk;
> +}
> +
> static unsigned long bcm2835_clock_get_rate(struct clk_hw *hw,
> unsigned long parent_rate)
> {
> struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
> struct bcm2835_cprman *cprman = clock->cprman;
> const struct bcm2835_clock_data *data = clock->data;
> + unsigned long rate;
> u32 div;
>
> if (data->int_bits == 0 && data->frac_bits == 0)
> @@ -1005,7 +1025,12 @@ static unsigned long bcm2835_clock_get_rate(struct clk_hw *hw,
>
> div = cprman_read(cprman, data->div_reg);
>
> - return bcm2835_clock_rate_from_divisor(clock, parent_rate, div);
> + rate = bcm2835_clock_rate_from_divisor(clock, parent_rate, div);
> +
> + if (data->round_up)
> + rate = bcm2835_clock_round(rate);
> +
> + return rate;
> }
>
> static void bcm2835_clock_wait_busy(struct bcm2835_clock *clock)
> @@ -2142,7 +2167,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
> .div_reg = CM_UARTDIV,
> .int_bits = 10,
> .frac_bits = 12,
> - .tcnt_mux = 28),
> + .tcnt_mux = 28,
> + .round_up = true),
>
> /* TV encoder clock. Only operating frequency is 108Mhz. */
> [BCM2835_CLOCK_VEC] = REGISTER_PER_CLK(
> --
> 2.26.2
Hi Ivan,
Am 14.04.22 um 12:56 schrieb Ivan T. Ivanov:
> Hi Stefan,
>
> Please, could you take a look into following patch?
yes, but i cannot give a technical review. But from my gut feeling this
doesn't look really elegant to me.
>
> Thanks!
> Ivan
>
> On 04-04 15:51, Ivan T. Ivanov wrote:
>> Subject: [PATCH v2] clk: bcm2835: Round UART input clock up
>> Message-Id: <[email protected]>
>>
>> The UART clock is initialised to be as close to the requested
>> frequency as possible without exceeding it. Now that there is a
>> clock manager that returns the actual frequencies, an expected
>> 48MHz clock is reported as 47999625. If the requested baudrate
>> == requested clock/16, there is no headroom and the slight
>> reduction in actual clock rate results in failure.
>>
>> If increasing a clock by less than 0.1% changes it from ..999..
>> to ..000.., round it up.
Based on this commit message this looks like a fix / workaround for an
issue. It would be very helpful to know:
What issue should be fixed?
Why is it fixed here and not in the UART driver for instance?
In case it fixes a regression, a Fixes tag should be necessary.
In best case this is explained in the commit message.
Best regards
>>
>> This is reworked version of a downstream fix:
>> https://github.com/raspberrypi/linux/commit/ab3f1b39537f6d3825b8873006fbe2fc5ff057b7
>>
>> Cc: Phil Elwell <[email protected]>
>> Signed-off-by: Ivan T. Ivanov <[email protected]>
>> ---
>> Changes since v1
>> Make bcm2835_clock_round() static to fix following warning
>> when compiling for riscv:
>> drivers/clk/bcm/clk-bcm2835.c:997:15: warning: no previous prototype for 'bcm2835_clock_round' [-Wmissing-prototypes]
>> Reported-by: kernel test robot <[email protected]>
>>
>> drivers/clk/bcm/clk-bcm2835.c | 30 ++++++++++++++++++++++++++++--
>> 1 file changed, 28 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/bcm/clk-bcm2835.c b/drivers/clk/bcm/clk-bcm2835.c
>> index 3ad20e75fd23..c29b643d1bf5 100644
>> --- a/drivers/clk/bcm/clk-bcm2835.c
>> +++ b/drivers/clk/bcm/clk-bcm2835.c
>> @@ -502,6 +502,8 @@ struct bcm2835_clock_data {
>> bool low_jitter;
>>
>> u32 tcnt_mux;
>> +
>> + bool round_up;
>> };
>>
>> struct bcm2835_gate_data {
>> @@ -992,12 +994,30 @@ static long bcm2835_clock_rate_from_divisor(struct bcm2835_clock *clock,
>> return temp;
>> }
>>
>> +static unsigned long bcm2835_clock_round(unsigned long clk)
>> +{
>> + unsigned long scaler;
>> +
>> + /*
>> + * If increasing a clock by less than 0.1% changes it
>> + * from ..999.. to ..000.., round up.
>> + */
>> + scaler = 1;
>> + while (scaler * 100000 < clk)
>> + scaler *= 10;
>> + if ((clk + scaler - 1) / scaler % 1000 == 0)
>> + clk = (clk / scaler + 1) * scaler;
>> +
>> + return clk;
>> +}
>> +
>> static unsigned long bcm2835_clock_get_rate(struct clk_hw *hw,
>> unsigned long parent_rate)
>> {
>> struct bcm2835_clock *clock = bcm2835_clock_from_hw(hw);
>> struct bcm2835_cprman *cprman = clock->cprman;
>> const struct bcm2835_clock_data *data = clock->data;
>> + unsigned long rate;
>> u32 div;
>>
>> if (data->int_bits == 0 && data->frac_bits == 0)
>> @@ -1005,7 +1025,12 @@ static unsigned long bcm2835_clock_get_rate(struct clk_hw *hw,
>>
>> div = cprman_read(cprman, data->div_reg);
>>
>> - return bcm2835_clock_rate_from_divisor(clock, parent_rate, div);
>> + rate = bcm2835_clock_rate_from_divisor(clock, parent_rate, div);
>> +
>> + if (data->round_up)
>> + rate = bcm2835_clock_round(rate);
>> +
>> + return rate;
>> }
>>
>> static void bcm2835_clock_wait_busy(struct bcm2835_clock *clock)
>> @@ -2142,7 +2167,8 @@ static const struct bcm2835_clk_desc clk_desc_array[] = {
>> .div_reg = CM_UARTDIV,
>> .int_bits = 10,
>> .frac_bits = 12,
>> - .tcnt_mux = 28),
>> + .tcnt_mux = 28,
>> + .round_up = true),
>>
>> /* TV encoder clock. Only operating frequency is 108Mhz. */
>> [BCM2835_CLOCK_VEC] = REGISTER_PER_CLK(
>> --
>> 2.26.2
Hi Ivan,
Am 18.04.22 um 13:05 schrieb Ivan T. Ivanov:
> Hi Stefan,
>
> On 04-15 10:52, Stefan Wahren wrote:
>> Hi Ivan,
>>
>> Am 14.04.22 um 12:56 schrieb Ivan T. Ivanov:
>>> Hi Stefan,
>>>
>>> Please, could you take a look into following patch?
>> yes, but i cannot give a technical review. But from my gut feeling this
>> doesn't look really elegant to me.
>>> Thanks!
>>> Ivan
>>>
>>> On 04-04 15:51, Ivan T. Ivanov wrote:
>>>> Subject: [PATCH v2] clk: bcm2835: Round UART input clock up
>>>> Message-Id: <[email protected]>
>>>>
>>>> The UART clock is initialised to be as close to the requested
>>>> frequency as possible without exceeding it. Now that there is a
>>>> clock manager that returns the actual frequencies, an expected
>>>> 48MHz clock is reported as 47999625. If the requested baudrate
>>>> == requested clock/16, there is no headroom and the slight
>>>> reduction in actual clock rate results in failure.
>>>>
>>>> If increasing a clock by less than 0.1% changes it from ..999..
>>>> to ..000.., round it up.
>> Based on this commit message this looks like a fix / workaround for an
>> issue. It would be very helpful to know:
>>
>> What issue should be fixed?
>>
>> Why is it fixed here and not in the UART driver for instance?
> The UART driver is amba-pl011. Original fix, see below Github link,
> was inside pl011 module, but somehow it didn't look as the right
> place either. Beside that this rounding function is not exactly
> perfect for all possible clock values. So I deiced to move the hack
> to the platform which actually need it.
thanks for your explanation. These are import information which belongs
in the commit log, because the motivation and the affected UART is very
important.
>
>> In case it fixes a regression, a Fixes tag should be necessary.
> I found the issue because it was reported that RPi3[1] and RPi Zero 2W
> boards have issues with the Bluetooth. So it turns out that when
> switching from initial to operation speed host and device no longer
> can talk each other because host uses incorrect baud rate.
Now i remember this issue, for the mainline kernel we decide to
workaround the issue by lowering the BT baudrate to 2000000 baud. I
didn't investigate the issue further, but your approach is a better
solution.
Do you use the mainline DTS or the vendor DTS to see this issue?
Best regards
> I open to better solution of the issue.
>
> Thanks,
> Ivan
>
>> In best case this is explained in the commit message.
>>
>> Best regards
>>
>>>> This is reworked version of a downstream fix:
>>>> https://github.com/raspberrypi/linux/commit/ab3f1b39537f6d3825b8873006fbe2fc5ff057b7
>>>>
> [1] https://bugzilla.suse.com/show_bug.cgi?id=1188238
>
Hi Stefan,
On 04-15 10:52, Stefan Wahren wrote:
>
> Hi Ivan,
>
> Am 14.04.22 um 12:56 schrieb Ivan T. Ivanov:
> > Hi Stefan,
> >
> > Please, could you take a look into following patch?
> yes, but i cannot give a technical review. But from my gut feeling this
> doesn't look really elegant to me.
> >
> > Thanks!
> > Ivan
> >
> > On 04-04 15:51, Ivan T. Ivanov wrote:
> > > Subject: [PATCH v2] clk: bcm2835: Round UART input clock up
> > > Message-Id: <[email protected]>
> > >
> > > The UART clock is initialised to be as close to the requested
> > > frequency as possible without exceeding it. Now that there is a
> > > clock manager that returns the actual frequencies, an expected
> > > 48MHz clock is reported as 47999625. If the requested baudrate
> > > == requested clock/16, there is no headroom and the slight
> > > reduction in actual clock rate results in failure.
> > >
> > > If increasing a clock by less than 0.1% changes it from ..999..
> > > to ..000.., round it up.
>
> Based on this commit message this looks like a fix / workaround for an
> issue. It would be very helpful to know:
>
> What issue should be fixed?
>
> Why is it fixed here and not in the UART driver for instance?
The UART driver is amba-pl011. Original fix, see below Github link,
was inside pl011 module, but somehow it didn't look as the right
place either. Beside that this rounding function is not exactly
perfect for all possible clock values. So I deiced to move the hack
to the platform which actually need it.
>
> In case it fixes a regression, a Fixes tag should be necessary.
I found the issue because it was reported that RPi3[1] and RPi Zero 2W
boards have issues with the Bluetooth. So it turns out that when
switching from initial to operation speed host and device no longer
can talk each other because host uses incorrect baud rate.
I open to better solution of the issue.
Thanks,
Ivan
>
> In best case this is explained in the commit message.
>
> Best regards
>
> > >
> > > This is reworked version of a downstream fix:
> > > https://github.com/raspberrypi/linux/commit/ab3f1b39537f6d3825b8873006fbe2fc5ff057b7
> > >
[1] https://bugzilla.suse.com/show_bug.cgi?id=1188238
Am 18.04.22 um 13:38 schrieb Ivan T. Ivanov:
> On 04-18 13:22, Stefan Wahren wrote:
>> Hi Ivan,
>>
>> Am 18.04.22 um 13:05 schrieb Ivan T. Ivanov:
>>> Hi Stefan,
>>>
>>> On 04-15 10:52, Stefan Wahren wrote:
>>>> Hi Ivan,
>>>>
>>>> Am 14.04.22 um 12:56 schrieb Ivan T. Ivanov:
>>>>> Hi Stefan,
>>>>>
>>>>> Please, could you take a look into following patch?
>>>> yes, but i cannot give a technical review. But from my gut feeling this
>>>> doesn't look really elegant to me.
>>>>> Thanks!
>>>>> Ivan
>>>>>
>>>>> On 04-04 15:51, Ivan T. Ivanov wrote:
>>>>>> Subject: [PATCH v2] clk: bcm2835: Round UART input clock up
>>>>>> Message-Id: <[email protected]>
>>>>>>
>>>>>> The UART clock is initialised to be as close to the requested
>>>>>> frequency as possible without exceeding it. Now that there is a
>>>>>> clock manager that returns the actual frequencies, an expected
>>>>>> 48MHz clock is reported as 47999625. If the requested baudrate
>>>>>> == requested clock/16, there is no headroom and the slight
>>>>>> reduction in actual clock rate results in failure.
>>>>>>
>>>>>> If increasing a clock by less than 0.1% changes it from ..999..
>>>>>> to ..000.., round it up.
>>>> Based on this commit message this looks like a fix / workaround for an
>>>> issue. It would be very helpful to know:
>>>>
>>>> What issue should be fixed?
>>>>
>>>> Why is it fixed here and not in the UART driver for instance?
>>> The UART driver is amba-pl011. Original fix, see below Github link,
>>> was inside pl011 module, but somehow it didn't look as the right
>>> place either. Beside that this rounding function is not exactly
>>> perfect for all possible clock values. So I deiced to move the hack
>>> to the platform which actually need it.
>> thanks for your explanation. These are import information which belongs in
>> the commit log, because the motivation and the affected UART is very
>> important.
>>>> In case it fixes a regression, a Fixes tag should be necessary.
>>> I found the issue because it was reported that RPi3[1] and RPi Zero 2W
>>> boards have issues with the Bluetooth. So it turns out that when
>>> switching from initial to operation speed host and device no longer
>>> can talk each other because host uses incorrect baud rate.
>> Now i remember this issue, for the mainline kernel we decide to workaround
>> the issue by lowering the BT baudrate to 2000000 baud.
> I have workaranded this the same, at first, but then decided to look at
> vendor tree and voilà!
>
>> I didn't investigate
>> the issue further, but your approach is a better solution.
>>
>> Do you use the mainline DTS or the vendor DTS to see this issue?
>>
> For (open)SUSE we use downstream DTS.
This is popular and bad at the same time. We as the mainline kernel
developer cannot guarantee that this works as expected. A lot of issues
are caused by mixing vendor DTS with mainline kernel, so in general (not
for this specific issue) you are on your own with this approach.
I know this is a little bit off topic but except from overlay support,
can you provide a list of most missing features of the mainline kernel /
DTS?
> Do you think that if I put better description in commit message fix will
> be more acceptable.
At least it would increase the chance to be accepted. This rounding
behavior looks open coded, maybe there is already a function to achieve
this.
> Or if someone could suggest anything else I am open
> to discussion.
>
> Regards,
> Ivan
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 04-18 13:22, Stefan Wahren wrote:
>
> Hi Ivan,
>
> Am 18.04.22 um 13:05 schrieb Ivan T. Ivanov:
> > Hi Stefan,
> >
> > On 04-15 10:52, Stefan Wahren wrote:
> > > Hi Ivan,
> > >
> > > Am 14.04.22 um 12:56 schrieb Ivan T. Ivanov:
> > > > Hi Stefan,
> > > >
> > > > Please, could you take a look into following patch?
> > > yes, but i cannot give a technical review. But from my gut feeling this
> > > doesn't look really elegant to me.
> > > > Thanks!
> > > > Ivan
> > > >
> > > > On 04-04 15:51, Ivan T. Ivanov wrote:
> > > > > Subject: [PATCH v2] clk: bcm2835: Round UART input clock up
> > > > > Message-Id: <[email protected]>
> > > > >
> > > > > The UART clock is initialised to be as close to the requested
> > > > > frequency as possible without exceeding it. Now that there is a
> > > > > clock manager that returns the actual frequencies, an expected
> > > > > 48MHz clock is reported as 47999625. If the requested baudrate
> > > > > == requested clock/16, there is no headroom and the slight
> > > > > reduction in actual clock rate results in failure.
> > > > >
> > > > > If increasing a clock by less than 0.1% changes it from ..999..
> > > > > to ..000.., round it up.
> > > Based on this commit message this looks like a fix / workaround for an
> > > issue. It would be very helpful to know:
> > >
> > > What issue should be fixed?
> > >
> > > Why is it fixed here and not in the UART driver for instance?
> > The UART driver is amba-pl011. Original fix, see below Github link,
> > was inside pl011 module, but somehow it didn't look as the right
> > place either. Beside that this rounding function is not exactly
> > perfect for all possible clock values. So I deiced to move the hack
> > to the platform which actually need it.
> thanks for your explanation. These are import information which belongs in
> the commit log, because the motivation and the affected UART is very
> important.
> >
> > > In case it fixes a regression, a Fixes tag should be necessary.
> > I found the issue because it was reported that RPi3[1] and RPi Zero 2W
> > boards have issues with the Bluetooth. So it turns out that when
> > switching from initial to operation speed host and device no longer
> > can talk each other because host uses incorrect baud rate.
>
> Now i remember this issue, for the mainline kernel we decide to workaround
> the issue by lowering the BT baudrate to 2000000 baud.
I have workaranded this the same, at first, but then decided to look at
vendor tree and voilà!
> I didn't investigate
> the issue further, but your approach is a better solution.
>
> Do you use the mainline DTS or the vendor DTS to see this issue?
>
For (open)SUSE we use downstream DTS.
Do you think that if I put better description in commit message fix will
be more acceptable. Or if someone could suggest anything else I am open
to discussion.
Regards,
Ivan
Hi Ivan,
Am 19.04.22 um 17:05 schrieb Ivan T. Ivanov:
> On 04-18 18:01, Stefan Wahren wrote:
>>>> Do you use the mainline DTS or the vendor DTS to see this issue?
>>>>
>>> For (open)SUSE we use downstream DTS.
>> This is popular and bad at the same time. We as the mainline kernel
>> developer cannot guarantee that this works as expected. A lot of issues are
>> caused by mixing vendor DTS with mainline kernel, so in general (not for
>> this specific issue) you are on your own with this approach.
>>
> Yep, I am aware of that. I am still trying to recover after recent
> gpio-ranges fiasco, also still working on fixing non-exported firmware
> clocks, which break HDMI output on some of the devices.
I guess, these firmware clock issues are only reproducible with vendor DTS?
>
>> I know this is a little bit off topic but except from overlay support, can
>> you provide a list of most missing features of the mainline kernel / DTS?
> Well, 260+ overlays for free is not insignificant benefit. Beside few
> breakages from time to time using downstream device tree works fine.
I think the better approach is to add the missing steps for overlay
support in mainline.
Best regards
>
> Regards,
> Ivan
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On 04-18 18:01, Stefan Wahren wrote:
> > >
> > > Do you use the mainline DTS or the vendor DTS to see this issue?
> > >
> > For (open)SUSE we use downstream DTS.
>
> This is popular and bad at the same time. We as the mainline kernel
> developer cannot guarantee that this works as expected. A lot of issues are
> caused by mixing vendor DTS with mainline kernel, so in general (not for
> this specific issue) you are on your own with this approach.
>
Yep, I am aware of that. I am still trying to recover after recent
gpio-ranges fiasco, also still working on fixing non-exported firmware
clocks, which break HDMI output on some of the devices.
> I know this is a little bit off topic but except from overlay support, can
> you provide a list of most missing features of the mainline kernel / DTS?
Well, 260+ overlays for free is not insignificant benefit. Beside few
breakages from time to time using downstream device tree works fine.
Regards,
Ivan