Hi,
Considering i have arch/arm/configs/abc_defconfig, I can run "make
abc_defconfig" repeatedly, and always get output
# configuration written to .config
or
# No change to .config
But if I now change arch/arm/configs/abc_defconfig, even just the
modification date, then "make abc_defconfig" no
Hi,
Since 37c8a5fafa3bb7dcdd51774be353be6cb2912b86 [kbuild: consolidate
Devicetree dtb build rules], the target bindeb-pkg no longer installs
DTBs in the .deb package.
Thanks,
Nuno
On Mon, Jan 15, 2018 at 9:30 PM, Andy Shevchenko
wrote:
> It seems the change broke Bluetooth on some Intel platforms. I'm not
> sure yet, but
> see here:
>
> https://github.com/Dunedan/mbp-2016-linux/issues/29#issuecomment-357583782
>
Hi Andy,
I guess you mean de9e33b [1] and not this patch (wh
Dear Ed,
Thanks.
Tested-by: Nuno Goncalves
I just would like to report a aditional issue I find, which I am not
sure if it is intend behaviour or not. If I set bauds 1152000,
150, 200, 250, 300, I always get a actually set baud
of 150, because it appears to be the closest ba
6:48 PM, Ed Blake wrote:
> On 11/01/18 17:28, Nuno Gonçalves wrote:
>> I have to disagree :)
>>
>> if (rate < i * min_rate) is true to i=a, then
>>
>> (rate >= i * min_rate && rate <= i * max_rate) will always be false
>> for any
I have to disagree :)
if (rate < i * min_rate) is true to i=a, then
(rate >= i * min_rate && rate <= i * max_rate) will always be false
for any i=b, where b>a.
If this condition is true, it means the old condition would be always
false for the remaining of the iteration.
My patch "only" avoids
Dear Ed and Greg,
There is a small bug on de9e33bdfa22e607a88494ff21e9196d00bf4550, at
least on 32bit devices.
Line 274 if (rate >= i * min_rate && rate <= i * max_rate)
This will overflow when min_rate/max_rate is large and can not be
achieved in the hardware.
Eg.
stty -F /dev/ttyS2 raw 35000
; abs64()".
>
> Thus on 32-bit platforms, this resulted in the clocksteering to
> take a quite dampended random walk trying to converge on the
> proper frequency, which caused the adjustments to be made much
> slower then intended (most easily observed when large
> adjustments a
Yes please.
Tested-by: Nuno Goncalves
Thanks,
Nuno
On Wed, Sep 9, 2015 at 1:52 AM, John Stultz wrote:
> On Sat, Sep 5, 2015 at 6:41 AM, Nuno Gonçalves wrote:
>> Considering your last message I just tried to use abs64 instead. Fixes
>> the problem for me.
>
> Yea, I&#
Sep 5, 2015 at 2:00 AM, John Stultz wrote:
> On Fri, Sep 4, 2015 at 5:57 PM, John Stultz wrote:
>> On Thu, Sep 3, 2015 at 4:26 AM, Miroslav Lichvar wrote:
>>> On Wed, Sep 02, 2015 at 04:16:00PM -0700, John Stultz wrote:
>>>> On Tue, Sep 1, 2015 at 6:14 PM, Nuno Go
.367 -2694ms53ms
To have it perform normally try for example 3.16.3:
sudo apt-get install linux-image-3.16.3-bone6
Thanks,
Nuno
On Thu, Sep 3, 2015 at 12:16 AM, John Stultz wrote:
> On Tue, Sep 1, 2015 at 6:14 PM, Nuno Gonçalves wrote:
>> On Wed, Sep 2, 2015 at 2:03 AM, John Stult
On Wed, Sep 2, 2015 at 2:03 AM, John Stultz wrote:
> On Tue, Sep 1, 2015 at 5:36 PM, Nuno Gonçalves wrote:
>> On Tue, Sep 1, 2015 at 9:25 PM, Thomas Gleixner wrote:
>>> On Tue, 1 Sep 2015, Nuno Gonçalves wrote:
>>>
>>>> There is a regression on the cl
On Tue, Sep 1, 2015 at 9:25 PM, Thomas Gleixner wrote:
> On Tue, 1 Sep 2015, Nuno Gonçalves wrote:
>
>> There is a regression on the clock system since v3.16-rc5-111-g4396e05
>> [1],
>
>> [1]
>> http://git.kernel.org/cgit/linux/kernel/
There is a regression on the clock system since v3.16-rc5-111-g4396e05
[1], where the clock doesn't apply frequency offsets above about
1000ppm [2].
This was found at a Beaglebone (armv7l, TI AM335x).
Thanks,
Nuno Goncalves
[1]
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/comm
14 matches
Mail list logo
