* [PATCH v3 7/7] EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC
From: Borislav Petkov @ 2018-01-11 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2b8d9facf0ee4110af4815d024693652@svr-chch-ex1.atlnz.lc>
On Wed, Jan 10, 2018 at 11:05:48PM +0000, Chris Packham wrote:
> Would you suggest dropping "armada_xp" altogether or just shortening to
> "axp"? What about dropping "edac" as well?
Whatever you prefer. And yes, my personal preference is short symbols so
I'd drop "edac" too.
I mean, we know it is "edac" - the whole driver is edac :-) and those
functions are static so their name being unique makes only partial sense
in stack traces and if the compiler hasn't inlined them...
Thx.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH v3 7/7] EDAC: Add driver for the Marvell Armada XP SDRAM and L2 cache ECC
From: Borislav Petkov @ 2018-01-11 19:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <121880e53de2408f9699bb04b9caf2b9@svr-chch-ex1.atlnz.lc>
On Wed, Jan 10, 2018 at 09:54:29PM +0000, Chris Packham wrote:
> Do you have any preference for which option to take? I'm leaning towards
> MACH_MVEBU_V7.
With my layman attempts at looking at ARM Kconfig organization, this
makes sense to me too.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: Adam Ford @ 2018-01-11 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f20267f2-be4c-e031-1c5f-76490164c60d@lechnology.com>
On Thu, Jan 11, 2018 at 12:29 PM, David Lechner <david@lechnology.com> wrote:
> On 01/11/2018 12:09 PM, Adam Ford wrote:
>>
>> On Thu, Jan 11, 2018 at 11:22 AM, David Lechner <david@lechnology.com>
>> wrote:
>>>
>>> On 01/11/2018 06:45 AM, Adam Ford wrote:
>>>>
>>>>
>>>> On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david@lechnology.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I am available tomorrow to build and test patches against the
>>>>>> da850-evm. I just need to know which version(s) to test.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Great. As per the cover letter:
>>>>>
>>>>> You can find a working branch with everything included in the
>>>>> "common-clk-v5"
>>>>> branch of https://github.com/dlech/ev3dev-kernel.git.
>>>>
>>>>
>>>>
>>>> I wasn't sure if things had changed after some of the dialog about the
>>>> bindings and device tree.
>>>
>>>
>>>
>>> Not yet. ;-)
>>>
>>>>
>>>> Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
>>>>
>>>> Starting kernel ...
>>>>
>>>> Uncompressing Linux... done, booting the kernel.
>>>> Booting Linux on physical CPU 0x0
>>>> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
>>>> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
>>>> CST 2018
>>>> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
>>>> CPU: VIVT data cache, VIVT instruction cache
>>>> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
>>>
>>>
>>>
>>> OK, using device tree...
>>
>>
>> Sorry, I thought I was supposed to. I retested using the board file,
>> but it also resulted in a hang.
>
>
> This was just intended as a note to self. But we do need to test both.
> Let's stick with the device tree boot first.
>
>>
>>>
>>>
>> [snip]
>>>
>>>
>>>
>>> If you are getting to this point, you probably don't need DEBUG_LL.
>>> It looks like "earlyprint" is not being passed to the command line
>>> anyway, so CONFIG_EARLY_PRINTK is not actually doing anything.
>>>
>>>> brd: module loaded
>>>> libphy: Fixed MDIO Bus: probed
>>>> davinci_mdio 1e24000.mdio: failed to get device clock
>>>> davinci_mdio: probe of 1e24000.mdio failed with error -2
>>>
>>>
>>>
>>> It looks like this needs a clock-names property in the device tree.
>>> Please make this change and try again:
>>>
>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>> index 08a9817..fd3e316 100644
>>> --- a/arch/arm/boot/dts/da850.dtsi
>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>> @@ -713,6 +713,7 @@
>>> #size-cells = <0>;
>>> reg = <0x224000 0x1000>;
>>> clocks = <&psc1 5>;
>>> + clock-names = "fck";
>>> status = "disabled";
>>> };
>>> eth0: ethernet at 220000 {
>>>
>>>
>> [snip]
>>
>> I added your copy-names entry to my device tree and we get a login prompt.
>> :-)
>
>
> OK, great! It sounds like device tree is working after this change. I guess
> we can move on to non-device-tree.
>
>
>>
>>> I'm not sure why there is an error here. I'm using I2C0 on my board,
>>> so I am fairly confident that it is not a problem introduced by this
>>> series.
>>>
>>>> console [netcon0] enabled
>>>> netconsole: network logging started
>>>> davinci_emac 1e20000.ethernet: incompatible machine/device type for
>>>> reading mac address
>>>> hctosys: unable to open rtc device (rtc0)
>>>>
>>>
>>> What is normally the next line after this in a working boot?
>>>
>>> Also please try passing "clk_ignore_unused" to the kernel command line.
>>
>>
>> Here is the log. There seems to be some garbled characters that don't
>> seem to appear. I'm going to double check those against the stock
>> kernel.
>>
>>
[snip]
>
>
> If removing the "clk_ignore_unused" option causes the board to not boot,
> then we still have problems that need to be fixed, so please also test
> without this option.
Without this option, it still does not boot. Without device tree it
hangs after:
[snip]
NET: Registered protocol family 17
Loading compiled-in X.509 certificates
console [netcon0] enabled
netconsole: network logging started
davinci_emac davinci_emac.1: using random MAC addr: 5e:38:1a:1f:4f:77
mmc0: host does not support reading read-only switch, assuming write-enable
hctosys: unable to open rtc device (rtc0)
mmc0: new high speed SDHC card at address b368
With device tree it hangs after:
[snip]
mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: new high speed SDHC card at address b368
mmcblk0: mmc0:b368 00000 3.75 GiB
mmcblk0: p1 p2
pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
pca953x 0-0020: failed reading register
pca953x: probe of 0-0020 failed with error -121
console [netcon0] enabled
netconsole: network logging started
davinci_emac 1e20000.ethernet: incompatible machine/device type for
reading mac address
hctosys: unable to open rtc device (rtc0)
>
>> vbat: disabling
>> EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts:
>> (null)
>> VFS: Mounted root (ext4 filesystem) on device 179:2.
>> devtmpfs: mounted
>> Freeing unused kernel memory: 232K
>> This architecture does not have kernel memory protection.
>> EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered
>> Starting logging: OK
>> Initializing random number generator... done.
>> Starting network: OK
>>
>> Welcome to Buildroot
>> buildroot login:
>>
>>
>>>
>>
>> However, I get a reboot failure:
>>
>> umount: devtmpfs busy - remounted read-only
>> EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
>> The system is going down NOW!
>> Sent SIGTERM to all processes
>> Sent SIGKILL to all processes
>> Requesting system reboot
>>
>> reboot: Restarting system
>> Reboot failed -- System halted
>>
>> I'll run more tests on a stock kernel to look at the reboot failure
>> and the uart noise.
>>
>> adam
>>
>
> The reboot failure probably has to do with the watchdog patches that
> are dependencies of this series.
>
>
> Also, see the cover letter about how to avoid garbled output. Either
> disable low level debugging or disable switching the parent of the
> async3 clock.
Disabling the low-level debugging eliminated the garbage.
If/when you have more to me to test, feel free to e-mail me. I am
available today and tomorrow to test.
>
^ permalink raw reply
* [PATCH 06/19] drm/blend: Add a generic alpha property
From: Laurent Pinchart @ 2018-01-11 18:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKMK7uE3L9Px_2e_76pvW4k1FxN6_VSFcn21enVb7+s7b1c-dg@mail.gmail.com>
Hi Daniel,
On Thursday, 11 January 2018 18:36:10 EET Daniel Vetter wrote:
> On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard wrote:
> > On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
> >> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
> >>> On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
> >>>> On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> >>>>> Some drivers duplicate the logic to create a property to store a
> >>>>> per-plane alpha.
> >>>>>
> >>>>> Let's create a helper in order to move that to the core.
> >>>>>
> >>>>> Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> >>>>> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> >>>>> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >>>>
> >>>> Do we have userspace for this?
> >>>
> >>> Wayland seems to be on its way to implement this, with ChromeOS using
> >>> it:
> >>> https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741
> >>> .html
> >>>
> >>> and more specifically:
> >>> https://chromium.googlesource.com/chromium/src/+/master/third_party/way
> >>> land-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1
> >>> .xml#118
> >>
> >> Yay, would be good to include these links in the patch description.
> >> Really happy we're having a real standard now used by multiple people.
> >
> > I will.
> >
> >> > > Is encoding a fixed 0-255 range really the best idea?
> >> >
> >> > I don't really know, is there hardware or formats where there is more
> >> > than 255? Or did you mean less than that?
> >>
> >> 30bit I'd assume wants more alpha. In the past we've done some
> >> fixed-point stuff (e.g. for LUT), using the 0.0-1.0 float range. Using
> >> that for the blend equation docs is also what I recommend (and that we
> >> map from 0-255 to 0.0-1.0 logically). Ofc the hw might not do any of that
> >> ... I think 0.16 fixed point, stored in a u16 is probably best. That's
> >> what we're doing for gamma tables already, and that way drivers can
> >> simply throw away the lower bits.
> >
> > But that would also break the two users of that property that won't be
> > able to move to the generic property (with the same name) without
> > breaking userspace. The point of that patch was to allow some code
> > consolidation, and that would mean failing to do so here :/
>
> Let me try to clarify:
> - We'll keep the exact existing property semantics with the 0-255
> range for the userspace visible property.
>
> - But internally, in the decode value that we store into
> drm_plane_state, we'll do the slightly more future proof thing with a
> few more bits.
>
> That gives us the option of exposing those bits in the future without
> having to change all the drivers again (which we have to do for this
> series here already anyway, since the decoded value moves into
> drm_plane_state from driver subclasses).
>
> Definitely not asking to break userspace here :-)
As the property range is available to userspace, we could allow drivers to
expose a driver-dependent number of bits for the alpha value without breaking
anything. We can even require new drivers to expose 16 bits regardless of the
number of bits that the hardware can handle, or we could keep that driver-
specific.
Please note, however, that U0.16 can only represent [0.0, 0.999984741...]
while we need [0.0, 1.0]. As all the hardware I know map the full range of
values ([0, 255] for 8-bit for instance) to [0.0, 1.0] I wouldn't pretend that
the 16-bit value exposed to userspace is U0.16.
> >>>> I know other drivers have skimped on the rules here a bit ... But at
> >>>> least internally (i.e. within the drm_plane_state) we probably should
> >>>> restrict ourselves to u8. And this needs real docs (i.e. the full blend
> >>>> equation drivers are supposed to implement).
> >>>
> >>> You mean straight vs premultiplied? Maybe we should implement this as
> >>> an additional property in read only depending on how the hardware
> >>> behaves?
> >>
> >> No need for an additional property right now, but definitely document
> >> whether you mean straight or pre-multiplied. Just writing down the blend
> >> equation is probably best.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: David Lechner @ 2018-01-11 18:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xL=h_g6HK2ey82r_w5qRbXg9+68Og+84YUYuePsjYd-Vg@mail.gmail.com>
On 01/11/2018 12:09 PM, Adam Ford wrote:
> On Thu, Jan 11, 2018 at 11:22 AM, David Lechner <david@lechnology.com> wrote:
>> On 01/11/2018 06:45 AM, Adam Ford wrote:
>>>
>>> On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david@lechnology.com>
>>> wrote:
>>>>
>>>> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>>>>
>>>>>
>>>>>
>>>>> I am available tomorrow to build and test patches against the
>>>>> da850-evm. I just need to know which version(s) to test.
>>>>
>>>>
>>>>
>>>> Great. As per the cover letter:
>>>>
>>>> You can find a working branch with everything included in the
>>>> "common-clk-v5"
>>>> branch of https://github.com/dlech/ev3dev-kernel.git.
>>>
>>>
>>> I wasn't sure if things had changed after some of the dialog about the
>>> bindings and device tree.
>>
>>
>> Not yet. ;-)
>>
>>>
>>> Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
>>>
>>> Starting kernel ...
>>>
>>> Uncompressing Linux... done, booting the kernel.
>>> Booting Linux on physical CPU 0x0
>>> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
>>> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
>>> CST 2018
>>> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
>>> CPU: VIVT data cache, VIVT instruction cache
>>> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
>>
>>
>> OK, using device tree...
>
> Sorry, I thought I was supposed to. I retested using the board file,
> but it also resulted in a hang.
This was just intended as a note to self. But we do need to test both.
Let's stick with the device tree boot first.
>
>>
>>
> [snip]
>>
>>
>> If you are getting to this point, you probably don't need DEBUG_LL.
>> It looks like "earlyprint" is not being passed to the command line
>> anyway, so CONFIG_EARLY_PRINTK is not actually doing anything.
>>
>>> brd: module loaded
>>> libphy: Fixed MDIO Bus: probed
>>> davinci_mdio 1e24000.mdio: failed to get device clock
>>> davinci_mdio: probe of 1e24000.mdio failed with error -2
>>
>>
>> It looks like this needs a clock-names property in the device tree.
>> Please make this change and try again:
>>
>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>> index 08a9817..fd3e316 100644
>> --- a/arch/arm/boot/dts/da850.dtsi
>> +++ b/arch/arm/boot/dts/da850.dtsi
>> @@ -713,6 +713,7 @@
>> #size-cells = <0>;
>> reg = <0x224000 0x1000>;
>> clocks = <&psc1 5>;
>> + clock-names = "fck";
>> status = "disabled";
>> };
>> eth0: ethernet at 220000 {
>>
>>
> [snip]
>
> I added your copy-names entry to my device tree and we get a login prompt. :-)
OK, great! It sounds like device tree is working after this change. I guess
we can move on to non-device-tree.
>
>> I'm not sure why there is an error here. I'm using I2C0 on my board,
>> so I am fairly confident that it is not a problem introduced by this
>> series.
>>
>>> console [netcon0] enabled
>>> netconsole: network logging started
>>> davinci_emac 1e20000.ethernet: incompatible machine/device type for
>>> reading mac address
>>> hctosys: unable to open rtc device (rtc0)
>>>
>>
>> What is normally the next line after this in a working boot?
>>
>> Also please try passing "clk_ignore_unused" to the kernel command line.
>
> Here is the log. There seems to be some garbled characters that don't
> seem to appear. I'm going to double check those against the stock
> kernel.
>
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
> CST 2018
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
> CPU: VIVT data cache, VIVT instruction cache
> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
> debug: ignoring loglevel setting.
> bootconsole [earlycon0] enabled
> Memory policy: Data cache writethrough
> cma: Reserved 16 MiB at 0xc2c00000
> DaVinci da850/omap-l138 variant 0x0
> On node 0 totalpages: 16384
> DMA zone: 128 pages used for memmap
> DMA zone: 0 pages reserved
> DMA zone: 16384 pages, LIFO batch:3
> random: fast init done
> pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
> pcpu-alloc: [0] 0
> Built 1 zonelists, mobility grouping on. Total pages: 16256
> Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw
> rootfstype=ext4 rootwait ignore_loglevel earlyprintk clk_ignore_unused
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 42164K/65536K available (4548K kernel code, 280K rwdata, 1044K
> rodata, 232K init, 143K bss, 6988K reserved, 16384K cma-reserved)
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
> lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
> modules : 0xbf000000 - 0xc0000000 ( 16 MB)
> .text : 0x(ptrval) - 0x(ptrval) (4550 kB)
> .init : 0x(ptrval) - 0x(ptrval) ( 232 kB)
> .data : 0x(ptrval) -&?p`? rval) Qm^?`} b ? $\???? ?! ?
> "V ? ???@ B- d?????}bf ?f? i?console [ttyS2] enabled
> console [ttyS2] enabled??F 0x(ptrval) ( 144 kB)
> bootconsole [earlycon0] disabledObjects=0, CP&?p^?-?Mdes=1
> bootconsole [earlycon0] disabledb ?f? i?a ?F $\????
> brd: module loaded??} ??B
> libphy: Fixed MDIO Bus: probed &?p^?-?I
> davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 2200000
> a- R? /^???? ???v at a??.???? ^\?`&?`l??f ?????M??? ?E ??????)?)! ?}?y
> ya bK????? ???
> davinci_mdio 1e24000.mdio: detected phy mask
> fffffffe ??I ")=M??-?)!iD????mi-??I ?k??
> ???)? r??.????i2? ?v? ?k$^????-?-!mD??q} ] ?K???? 6m?R?`? q)?M ???^??
> ??
> libphy: 1e24000.mdio:
> probed&?????a I?j?`?a?I???} 2/?p? bv VK,?q? 6M?- ? ??? ?I ??f??a?I???}
> 2 A-!?a-? ?K????!aMq- ")=I??-?-!mD??} 2 A-!?a-? ?K -? &-=M??-?-!mD?
> davinci_mdio 1e24000.mdio: phy[0]: device 1e24000.mdio:00, driver SMSC
> LAN8710/LAN8720??? I?Sm??aM?-! &??P-4RhR?
> ??-? ?K?^t@?
> i2c /dev entries driver
> davinci_mmc 1c40000.mmc: Using DMA, 4-bit mode
> NET: Registered protocol family 10
> Segment Routing with IPv6
> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> NET: Registered protocol family 17
> Loading compiled-in X.509 certificates
> mmc0: host does not support reading read-only switch, assuming write-enable
> mmc0: new high speed SDHC card at address b368
> mmcblk0: mmc0:b368 00000 3.75 GiB
> mmcblk0: p1 p2
> pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
> pca953x 0-0020: failed reading register
> pca953x: probe of 0-0020 failed with error -121
> console [netcon0] enabled
> netconsole: network logging started
> davinci_emac 1e20000.ethernet: incompatible machine/device type for
> reading mac address
> hctosys: unable to open rtc device (rtc0)
> clk: Not disabling unused clocks
If removing the "clk_ignore_unused" option causes the board to not boot,
then we still have problems that need to be fixed, so please also test
without this option.
> vbat: disabling
> EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
> VFS: Mounted root (ext4 filesystem) on device 179:2.
> devtmpfs: mounted
> Freeing unused kernel memory: 232K
> This architecture does not have kernel memory protection.
> EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered
> Starting logging: OK
> Initializing random number generator... done.
> Starting network: OK
>
> Welcome to Buildroot
> buildroot login:
>
>
>>
>
> However, I get a reboot failure:
>
> umount: devtmpfs busy - remounted read-only
> EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
> The system is going down NOW!
> Sent SIGTERM to all processes
> Sent SIGKILL to all processes
> Requesting system reboot
>
> reboot: Restarting system
> Reboot failed -- System halted
>
> I'll run more tests on a stock kernel to look at the reboot failure
> and the uart noise.
>
> adam
>
The reboot failure probably has to do with the watchdog patches that
are dependencies of this series.
Also, see the cover letter about how to avoid garbled output. Either
disable low level debugging or disable switching the parent of the
async3 clock.
^ permalink raw reply
* [PATCH] phy: work around 'phys' references to usb-phy devices
From: Eric Anholt @ 2018-01-11 18:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a0NSGCR8=MzHAPqyhWMsUWAxJjtstYo8gszKcXUCaupgg@mail.gmail.com>
Arnd Bergmann <arnd@arndb.de> writes:
> On Thu, Jan 11, 2018 at 2:30 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>> On Thursday 11 January 2018 02:27 AM, Arnd Bergmann wrote:
>>> On Mon, Jan 8, 2018 at 7:32 PM, Kishon Vijay Abraham I <kishon@ti.com> wrote:
>>>> On Monday 08 January 2018 06:31 PM, Arnd Bergmann wrote:
>>>>> Stefan Wahren reports a problem with a warning fix that was merged
>>>>> ---
>>>>> This obviously needs to be tested, I wrote this up as a reply to
>>>>> Stefan's bug report. I'm fairly sure that I covered all usb-phy
>>>>> driver strings here. My goal is to have a fix merged into 4.15
>>>>> rather than reverting all the DT fixes.
>>>>
>>>> Shouldn't the fix be in phy consumer drivers to not return error if it's able
>>>> to find the phy either using usb-phy or generic phy?
>>>
>>> Stefan has posted a patch to that effect now, but I fear that might be
>>> a little fragile, in particular this short before the release with the
>>> regression
>>> in place.
>>>
>>> The main problem is that we'd have to change the generic
>>> usb_add_hcd() function in addition to dwc2 and dwc3 to ignore
>>> -EPROBE_DEFER from phy_get() whenever usb_get_phy_dev()
>>> has already succeeded.
>>>
>>> If there is any HCD that relies on usb_add_hcd() to get both the
>>> usb_phy and the phy structures, and it may need to defer probing
>>> when the latter one isn't ready yet, that fix would break another
>>> driver.
>>
>> hmm.. IMO the better thing right now would be to revert the dt patch which adds
>> #phy-cells.
>> We have to see if there are better fixes in order to add #phy-cells warning fix
>> in stable tree.
>
> Let's see which patches that would be, I think this is the full list of
> nodes that got an extra #phy-cells:
>
> c22fe696157d ARM: dts: Fix dm814x missing phy-cells property
> f0e11ff8ff65 ARM: dts: am33xx: Add missing #phy-cells to ti,am335x-usb-phy
> c5bbf358b790 arm: dts: nspire: Add missing #phy-cells to usb-nop-xceiv
> 44e5dced2ef6 arm: dts: marvell: Add missing #phy-cells to usb-nop-xceiv
> 014d6da6cb25 ARM: dts: bcm283x: Fix DTC warnings about missing phy-cells
> f568f6f554b8 ARM: dts: omap: Add missing #phy-cells to usb-nop-xceiv
>
> plus a couple in linux-next:
>
> d745d5f277bf ARM: dts: imx51-zii-rdu1: Add missing #phy-cells to usb-nop-xceiv
> 915fbe59cbf2 ARM: dts: imx: Add missing #phy-cells to usb-nop-xceiv
>
> It's a lot of patches to revert, and I guess it would get us back to hundreds
> of warnings in an allmodconfig build, so I'd first try to come up with
> ways to prove that at least some of them can stay.
>
> Almost all the warnings are about "usb-nop-xceiv" phys, the only exceptions
> I could find are the OMAP ones (the first two patches), which use
> "ti,am335x-usb-phy" and are referenced from a "ti,musb-am33xx". That
> particular driver is not affected by the bug, so we can leave that in.
>
> To deal with all the "usb-nop-xceiv" references including the one that
> Stefan reported, we could use a much simpler version of my earlier
> patch, do you think this is any better?
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c
> index b4964b067aec..f056d8fb3921 100644
> --- a/drivers/phy/phy-core.c
> +++ b/drivers/phy/phy-core.c
> @@ -410,6 +410,10 @@ static struct phy *_of_phy_get(struct device_node
> *np, int index)
> if (ret)
> return ERR_PTR(-ENODEV);
>
> + /* This phy type handled by the usb-phy subsystem for now */
> + if (of_device_is_compatible("usb-nop-xceiv"))
> + return ERR_PTR(-ENODEV);
> +
> mutex_lock(&phy_provider_mutex);
> phy_provider = of_phy_provider_lookup(args.np);
> if (IS_ERR(phy_provider) || !try_module_get(phy_provider->owner)) {
This seems like a nice workaround!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180111/0cadfd65/attachment-0001.sig>
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: Adam Ford @ 2018-01-11 18:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <40501635-6f5b-20c9-f8bc-d17e26b58426@lechnology.com>
On Thu, Jan 11, 2018 at 11:22 AM, David Lechner <david@lechnology.com> wrote:
> On 01/11/2018 06:45 AM, Adam Ford wrote:
>>
>> On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david@lechnology.com>
>> wrote:
>>>
>>> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>>>
>>>>
>>>>
>>>> I am available tomorrow to build and test patches against the
>>>> da850-evm. I just need to know which version(s) to test.
>>>
>>>
>>>
>>> Great. As per the cover letter:
>>>
>>> You can find a working branch with everything included in the
>>> "common-clk-v5"
>>> branch of https://github.com/dlech/ev3dev-kernel.git.
>>
>>
>> I wasn't sure if things had changed after some of the dialog about the
>> bindings and device tree.
>
>
> Not yet. ;-)
>
>>
>> Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
>>
>> Starting kernel ...
>>
>> Uncompressing Linux... done, booting the kernel.
>> Booting Linux on physical CPU 0x0
>> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
>> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
>> CST 2018
>> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
>> CPU: VIVT data cache, VIVT instruction cache
>> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
>
>
> OK, using device tree...
Sorry, I thought I was supposed to. I retested using the board file,
but it also resulted in a hang.
>
>
[snip]
>
>
> If you are getting to this point, you probably don't need DEBUG_LL.
> It looks like "earlyprint" is not being passed to the command line
> anyway, so CONFIG_EARLY_PRINTK is not actually doing anything.
>
>> brd: module loaded
>> libphy: Fixed MDIO Bus: probed
>> davinci_mdio 1e24000.mdio: failed to get device clock
>> davinci_mdio: probe of 1e24000.mdio failed with error -2
>
>
> It looks like this needs a clock-names property in the device tree.
> Please make this change and try again:
>
> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
> index 08a9817..fd3e316 100644
> --- a/arch/arm/boot/dts/da850.dtsi
> +++ b/arch/arm/boot/dts/da850.dtsi
> @@ -713,6 +713,7 @@
> #size-cells = <0>;
> reg = <0x224000 0x1000>;
> clocks = <&psc1 5>;
> + clock-names = "fck";
> status = "disabled";
> };
> eth0: ethernet at 220000 {
>
>
[snip]
I added your copy-names entry to my device tree and we get a login prompt. :-)
> I'm not sure why there is an error here. I'm using I2C0 on my board,
> so I am fairly confident that it is not a problem introduced by this
> series.
>
>> console [netcon0] enabled
>> netconsole: network logging started
>> davinci_emac 1e20000.ethernet: incompatible machine/device type for
>> reading mac address
>> hctosys: unable to open rtc device (rtc0)
>>
>
> What is normally the next line after this in a working boot?
>
> Also please try passing "clk_ignore_unused" to the kernel command line.
Here is the log. There seems to be some garbled characters that don't
seem to appear. I'm going to double check those against the stock
kernel.
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
(Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
CST 2018
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
CPU: VIVT data cache, VIVT instruction cache
OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
debug: ignoring loglevel setting.
bootconsole [earlycon0] enabled
Memory policy: Data cache writethrough
cma: Reserved 16 MiB at 0xc2c00000
DaVinci da850/omap-l138 variant 0x0
On node 0 totalpages: 16384
DMA zone: 128 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 16384 pages, LIFO batch:3
random: fast init done
pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
pcpu-alloc: [0] 0
Built 1 zonelists, mobility grouping on. Total pages: 16256
Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw
rootfstype=ext4 rootwait ignore_loglevel earlyprintk clk_ignore_unused
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 42164K/65536K available (4548K kernel code, 280K rwdata, 1044K
rodata, 232K init, 143K bss, 6988K reserved, 16384K cma-reserved)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0x(ptrval) - 0x(ptrval) (4550 kB)
.init : 0x(ptrval) - 0x(ptrval) ( 232 kB)
.data : 0x(ptrval) -&?p`? rval) Qm^?`} b ? $\???? ?! ?
"V ? ???@ B- d?????}bf ?f? i?console [ttyS2] enabled
console [ttyS2] enabled??F 0x(ptrval) ( 144 kB)
bootconsole [earlycon0] disabledObjects=0, CP&?p^?-?Mdes=1
bootconsole [earlycon0] disabledb ?f? i?a ?F $\????
brd: module loaded??} ??B
libphy: Fixed MDIO Bus: probed &?p^?-?I
davinci_mdio 1e24000.mdio: davinci mdio revision 1.5, bus freq 2200000
a- R? /^???? ???v at a??.???? ^\?`&?`l??f ?????M??? ?E ??????)?)! ?}?y
ya bK????? ???
davinci_mdio 1e24000.mdio: detected phy mask
fffffffe ??I ")=M??-?)!iD????mi-??I ?k??
???)? r??.????i2? ?v? ?k$^????-?-!mD??q} ] ?K???? 6m?R?`? q)?M ???^??
??
libphy: 1e24000.mdio:
probed&?????a I?j?`?a?I???} 2/?p? bv VK,?q? 6M?- ? ??? ?I ??f??a?I???}
2 A-!?a-? ?K????!aMq- ")=I??-?-!mD??} 2 A-!?a-? ?K -? &-=M??-?-!mD?
davinci_mdio 1e24000.mdio: phy[0]: device 1e24000.mdio:00, driver SMSC
LAN8710/LAN8720??? I?Sm??aM?-! &??P-4RhR?
??-? ?K?^t@?
i2c /dev entries driver
davinci_mmc 1c40000.mmc: Using DMA, 4-bit mode
NET: Registered protocol family 10
Segment Routing with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
Loading compiled-in X.509 certificates
mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: new high speed SDHC card at address b368
mmcblk0: mmc0:b368 00000 3.75 GiB
mmcblk0: p1 p2
pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
pca953x 0-0020: failed reading register
pca953x: probe of 0-0020 failed with error -121
console [netcon0] enabled
netconsole: network logging started
davinci_emac 1e20000.ethernet: incompatible machine/device type for
reading mac address
hctosys: unable to open rtc device (rtc0)
clk: Not disabling unused clocks
vbat: disabling
EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
VFS: Mounted root (ext4 filesystem) on device 179:2.
devtmpfs: mounted
Freeing unused kernel memory: 232K
This architecture does not have kernel memory protection.
EXT4-fs (mmcblk0p2): re-mounted. Opts: data=ordered
Starting logging: OK
Initializing random number generator... done.
Starting network: OK
Welcome to Buildroot
buildroot login:
>
However, I get a reboot failure:
umount: devtmpfs busy - remounted read-only
EXT4-fs (mmcblk0p2): re-mounted. Opts: (null)
The system is going down NOW!
Sent SIGTERM to all processes
Sent SIGKILL to all processes
Requesting system reboot
reboot: Restarting system
Reboot failed -- System halted
I'll run more tests on a stock kernel to look at the reboot failure
and the uart noise.
adam
^ permalink raw reply
* [patch v15 3/4] Documentation: jtag: Add bindings for Aspeed SoC 24xx and 25xx families JTAG master driver
From: Joel Stanley @ 2018-01-11 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514202808-29747-4-git-send-email-oleksandrs@mellanox.com>
On Mon, Dec 25, 2017 at 3:53 AM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
> It has been tested on Mellanox system with BMC equipped with
> Aspeed 2520 SoC for programming CPLD devices.
>
> Signed-off-by: Oleksandr Shamray <oleksandrs@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> Acked-by: Rob Herring <robh@kernel.org>
> ---
> v14->v15
> v13->v14
> v12->v13
> v11->v12
> v10->v11
> v9->v10
> v8->v9
> v7->v8
> Comments pointed by pointed by Joel Stanley <joel.stan@gmail.com>
> - Change compatible string to ast2400 and ast2000
>
> V6->v7
> Comments pointed by Tobias Klauser <tklauser@distanz.ch>
> - Fix spell "Doccumentation" -> "Documentation"
>
> v5->v6
> Comments pointed by Tobias Klauser <tklauser@distanz.ch>
> - Small nit: s/documentation/Documentation/
>
> v4->v5
>
> V3->v4
> Comments pointed by Rob Herring <robh@kernel.org>
> - delete unnecessary "status" and "reg-shift" descriptions in
> bndings file
>
> v2->v3
> Comments pointed by Rob Herring <robh@kernel.org>
> - split Aspeed jtag driver and binding to sepatrate patches
> - delete unnecessary "status" and "reg-shift" descriptions in
> bndings file
> ---
> .../devicetree/bindings/jtag/aspeed-jtag.txt | 18 ++++++++++++++++++
> 1 files changed, 18 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
>
> diff --git a/Documentation/devicetree/bindings/jtag/aspeed-jtag.txt b/Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
> new file mode 100644
> index 0000000..8cfc610
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/jtag/aspeed-jtag.txt
> @@ -0,0 +1,18 @@
> +Aspeed JTAG driver for ast2400 and ast2500 SoC
> +
> +Required properties:
> +- compatible: Should be one of
> + - "aspeed,ast2400-jtag"
> + - "aspeed,ast2500-jtag"
> +- reg contains the offset and length of the JTAG memory
> + region
> +- clocks root clock of bus, should reference the APB clock
> +- interrupts should contain JTAG controller interrupt
> +
> +Example:
> +jtag: jtag at 1e6e4000 {
> + compatible = "aspeed,ast2500-jtag";
> + reg = <0x1e6e4000 0x1c>;
> + clocks = <&clk_apb>;
We've now got a proper clock driver upstream. Can you update the
example to match the newly added bindings?
clocks = <&syscon ASPEED_CLK_APB>;
Cheers,
Joel
^ permalink raw reply
* [patch v15 2/4] drivers: jtag: Add Aspeed SoC 24xx and 25xx families JTAG master driver
From: Joel Stanley @ 2018-01-11 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514202808-29747-3-git-send-email-oleksandrs@mellanox.com>
On Mon, Dec 25, 2017 at 3:53 AM, Oleksandr Shamray
<oleksandrs@mellanox.com> wrote:
> Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller.
>
> Driver implements the following jtag ops:
> - freq_get;
> - freq_set;
> - status_get;
> - idle;
> - xfer;
>
> It has been tested on Mellanox system with BMC equipped with
> Aspeed 2520 SoC for programming CPLD devices.
>
> Signed-off-by: Oleksandr Shamray <oleksandrs@mellanox.com>
> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Philippe Ombredanne <pombredanne@nexb.com>
Acked-by: Joel Stanley <joel@jms.id.au>
Cheers,
Joel
^ permalink raw reply
* [PATCH v3 0/7] Marvell NAND controller rework with ->exec_op()
From: Robert Jarzmik @ 2018-01-11 17:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111122751.4bd74366@bbrezillon>
Boris Brezillon <boris.brezillon@free-electrons.com> writes:
Hi Boris and Miquel,
> So, here is the plan: since the driver has been tested on various mvebu
> platforms and is known to work fine on these platforms, I'd like to
> queue the driver and the patch modifying mvebu defconfigs (patches 1 to
> 4) for 4.16.
That's all right.
> I'll leave other patches for 4.17, which means I'd like remaining bugs
> to be fixed during the 4.16 release cycle so that we can eventually get
> rid of the old driver. That's really important to me that we don't keep
> both drivers around for too long, because my previous experience showed
> that, when you have 2 drivers for the same HW, people don't switch to
> the new one until they're forced to do it.
>
> Robert, are you fine with this approach? What about the tests you were
> doing? Did you make any progress? Did you find other issues?
So far, with the latest branch from Miquel of tip commit 12b9e62c851c ("ARM64:
dts: marvell: use reworked NAND controller driver on Armada 8K"), the bad blocks
issue is still there, ie :
- the old pxa3xx driver doesn't see any bad block and mounts the ext2/ubifs
correctly
- barebox doesn't see any bad block
- marvell_nand sees all (or most all) blocks as bad with "flash_bbt=0" in
platform data, which is very surprising
I'm really surprised that in your tests on the cm_x300, in a platform_data setup
(ie. not device-tree setup), you're not seeing these errors ...
As if I'm fine with this approach, I agree with step 1 (patches 1-4). As for
step 2, I'll agree if the current situation is solved and my boards recognize
correctly my ext2 over ubifs on the NAND.
Cheers.
--
Robert
[1] The dmesg extract (here with flash_bbt = 0)
Loading ARM Linux zImage '/mnt/tftp/zImage_jenkins'
commandline: ram=64M console=ttyS0,115200 ip=dhcp root=/dev/nfs nfsroot=/home/none/nfsroot/zylonite,v3,tcp earlycon mtdparts=pxa3xx_nand-0:128k at 0(TIMH)ro,128k at 128k(OBMI)ro,768k at 256k(barebox),256k at 1024k(barebox-env),12M at 1280k(kernel),38016k at 13568k(root)
arch_number: 1233
Uncompressing Linux... done, booting the kernel.
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 4.15.0-rc1-00044-g11cc68b (jenkins at belgarath) (gcc version 4.8.3 20140320 (prerelease) (Sourcery CodeBench Lite 2014.05-29)) #879 PREEMPT Thu Jan 11 09:16:09 CET 2018
[ 0.000000] CPU: XScale-V3 based processor [69056891] revision 1 (ARMv5TE), cr=0000397f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: PXA3xx Platform Development Kit (aka Zylonite)
[ 0.000000] Ignoring tag cmdline (using the default kernel command line)
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] RO Mode clock: 0.00MHz
[ 0.000000] Run Mode clock: 0.00MHz
[ 0.000000] Turbo Mode clock: 0.00MHz
[ 0.000000] System bus clock: 0.00MHz
[ 0.000000] On node 0 totalpages: 16384
[ 0.000000] Normal zone: 128 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 16384 pages, LIFO batch:3
[ 0.000000] random: fast init done
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 16256
[ 0.000000] Kernel command line: root=/dev/ram0 ip=192.168.1.232:192.168.1.5::255.255.255.0::eth0:on console=ttyS0,115200 mem=64M mtdparts=pxa3xx_nand-0:128k at 0(TIMH)ro,128k at 128k(OBMI)ro,768k at 256k(barebox),256k at 1024k(barebox-env),12M at 1280k(kernel),38016k at 13568k(root) ubi.mtd=5 earlycon=pxa,io,0xf6200000,115200n8 debug no_console_suspend
[ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Memory: 56856K/65536K available (4225K kernel code, 202K rwdata, 972K rodata, 2396K init, 102K bss, 8680K reserved, 0K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[ 0.000000] .text : 0xc0008000 - 0xc04289e8 (4227 kB)
[ 0.000000] .init : 0xc053f000 - 0xc0796000 (2396 kB)
[ 0.000000] .data : 0xc0796000 - 0xc07c8bec ( 203 kB)
[ 0.000000] .bss : 0xc07c8bec - 0xc07e25fc ( 103 kB)
[ 0.000000] Preemptible hierarchical RCU implementation.
[ 0.000000] Tasks RCU enabled.
[ 0.000000] NR_IRQS: 16, nr_irqs: 336, preallocated irqs: 336
[ 0.000000] RJK: parent_rate=13000000, xl=8, xn=1
[ 0.000068] sched_clock: 32 bits at 3250kHz, resolution 307ns, wraps every 660764198758ns
[ 0.000267] clocksource: oscr0: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 588080137591 ns
[ 0.002139] Console: colour dummy device 80x30
[ 0.002298] Calibrating delay loop... 103.83 BogoMIPS (lpj=519168)
[ 0.081019] pid_max: default: 32768 minimum: 301
[ 0.081858] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.081958] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.085170] CPU: Testing write buffer coherency: ok
[ 0.088980] Setting up static identity map for 0x80008200 - 0x80008260
[ 0.089936] Hierarchical SRCU implementation.
[ 0.102958] devtmpfs: initialized
[ 0.113835] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.113974] futex hash table entries: 256 (order: -1, 3072 bytes)
[ 0.116311] NET: Registered protocol family 16
[ 0.119126] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.385492] Advanced Linux Sound Architecture Driver Initialized.
[ 0.398200] clocksource: Switched to clocksource oscr0
[ 0.551166] NET: Registered protocol family 2
[ 0.556911] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.557135] TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.557316] TCP: Hash tables configured (established 1024 bind 1024)
[ 0.557858] UDP hash table entries: 256 (order: 0, 4096 bytes)
[ 0.558038] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
[ 0.559740] NET: Registered protocol family 1
[ 0.561795] RPC: Registered named UNIX socket transport module.
[ 0.561891] RPC: Registered udp transport module.
[ 0.561946] RPC: Registered tcp transport module.
[ 0.562003] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 2.497308] Initialise system trusted keyrings
[ 2.499900] workingset: timestamp_bits=30 max_order=14 bucket_order=0
[ 2.503798] NFS: Registering the id_resolver key type
[ 2.504004] Key type id_resolver registered
[ 2.504066] Key type id_legacy registered
[ 2.510210] Key type asymmetric registered
[ 2.510311] Asymmetric key parser 'x509' registered
[ 2.510469] io scheduler noop registered
[ 2.510534] io scheduler deadline registered
[ 2.510928] io scheduler cfq registered (default)
[ 2.510999] io scheduler mq-deadline registered
[ 2.511060] io scheduler kyber registered
[ 2.571677] pxa-dma pxa-dma.0: initialized 32 channels on 100 requestors
[ 2.575099] pxa2xx-uart.0: ttyS0 at MMIO 0x40100000 (irq = 38, base_baud = 928571) is a UART1
[ 3.050644] console [ttyS0] enabled
[ 3.056987] pxa2xx-uart.1: ttyS1 at MMIO 0x40200000 (irq = 37, base_baud = 928571) is a UART2
[ 3.069918] pxa2xx-uart.2: ttyS2 at MMIO 0x40700000 (irq = 36, base_baud = 928571) is a UART3
[ 3.085482] nand: executing subop:
[ 3.091647] nand: ->CMD [0xff]
[ 3.095546] nand: ->WAITRDY [max 250 ms]
[ 3.100705] marvell-nfc pxa3xx-nand:
[ 3.100705] NDCR: 0x90079fff
[ 3.100705] NDCB0: 0x00a000ff
[ 3.100705] NDCB1: 0x00000000
[ 3.100705] NDCB2: 0x00000000
[ 3.100705] NDCB3: 0x00000000
[ 3.119968] nand: executing subop:
[ 3.123439] nand: ->CMD [0x90]
[ 3.127315] nand: ->ADDR [1 cyc: 00]
[ 3.131983] nand: ->DATA_IN [2 B, force 8-bit]
[ 3.136985] marvell-nfc pxa3xx-nand:
[ 3.136985] NDCR: 0x90079fff
[ 3.136985] NDCB0: 0x00610090
[ 3.136985] NDCB1: 0x00000000
[ 3.136985] NDCB2: 0x00000000
[ 3.136985] NDCB3: 0x00000000
[ 3.155819] nand: executing subop:
[ 3.159462] nand: ->CMD [0x90]
[ 3.163343] nand: ->ADDR [1 cyc: 00]
[ 3.167635] nand: ->DATA_IN [8 B, force 8-bit]
[ 3.172747] marvell-nfc pxa3xx-nand:
[ 3.172747] NDCR: 0x90079fff
[ 3.172747] NDCB0: 0x00610090
[ 3.172747] NDCB1: 0x00000000
[ 3.172747] NDCB2: 0x00000000
[ 3.172747] NDCB3: 0x00000000
[ 3.191422] nand: executing subop:
[ 3.194876] nand: ->CMD [0x90]
[ 3.198897] nand: ->ADDR [1 cyc: 20]
[ 3.203210] nand: ->DATA_IN [4 B, force 8-bit]
[ 3.208314] marvell-nfc pxa3xx-nand:
[ 3.208314] NDCR: 0x90079fff
[ 3.208314] NDCB0: 0x00610090
[ 3.208314] NDCB1: 0x00000020
[ 3.208314] NDCB2: 0x00000000
[ 3.208314] NDCB3: 0x00000000
[ 3.226920] nand: executing subop:
[ 3.230511] nand: ->CMD [0x90]
[ 3.234394] nand: ->ADDR [1 cyc: 40]
[ 3.238830] nand: ->DATA_IN [5 B, force 8-bit]
[ 3.243808] marvell-nfc pxa3xx-nand:
[ 3.243808] NDCR: 0x90079fff
[ 3.243808] NDCB0: 0x00610090
[ 3.243808] NDCB1: 0x00000040
[ 3.243808] NDCB2: 0x00000000
[ 3.243808] NDCB3: 0x00000000
[ 3.262444] nand: device found, Manufacturer ID: 0x20, Chip ID: 0xba
[ 3.268947] nand: ST Micro NAND 256MiB 1,8V 16-bit
[ 3.273791] nand: 256 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[ 3.281519] marvell-nfc pxa3xx-nand: No minimum ECC strength, using 1b/512B
[ 3.288669] Scanning device for bad blocks
[ 3.292845] nand: nand_do_read_oob: from = 0x00000000, len = 64
[ 3.299007] marvell-nfc pxa3xx-nand:
[ 3.299007] NDCR: 0x9d079fff
[ 3.299007] NDCB0: 0x000d3000
[ 3.299007] NDCB1: 0x00000000
[ 3.299007] NDCB2: 0x00000000
[ 3.299007] NDCB3: 0x00000000
[ 3.318075] Bad eraseblock 0 at 0x000000000000
[ 3.322773] nand: nand_do_read_oob: from = 0x00020000, len = 64
[ 3.328941] marvell-nfc pxa3xx-nand:
[ 3.328941] NDCR: 0x9d079fff
[ 3.328941] NDCB0: 0x000d3000
[ 3.328941] NDCB1: 0x00400000
[ 3.328941] NDCB2: 0x00000000
[ 3.328941] NDCB3: 0x00000000
[ 3.347848] nand: nand_do_read_oob: from = 0x00040000, len = 64
[ 3.354049] marvell-nfc pxa3xx-nand:
[ 3.354049] NDCR: 0x9d079fff
[ 3.354049] NDCB0: 0x000d3000
[ 3.354049] NDCB1: 0x00800000
[ 3.354049] NDCB2: 0x00000000
[ 3.354049] NDCB3: 0x00000000
[ 3.372925] Bad eraseblock 2 at 0x000000040000
[ 3.377451] nand: nand_do_read_oob: from = 0x00060000, len = 64
[ 3.383633] marvell-nfc pxa3xx-nand:
[ 3.383633] NDCR: 0x9d079fff
[ 3.383633] NDCB0: 0x000d3000
[ 3.383633] NDCB1: 0x00c00000
[ 3.383633] NDCB2: 0x00000000
[ 3.383633] NDCB3: 0x00000000
[ 3.402509] Bad eraseblock 3 at 0x000000060000
... and so on ...
[ 60.154031] marvell-nfc pxa3xx-nand:
[ 60.154031] NDCR: 0x9d079fff
[ 60.154031] NDCB0: 0x000d3000
[ 60.154031] NDCB1: 0x58410000
[ 60.154031] NDCB2: 0x00000000
[ 60.154031] NDCB3: 0x00000000
[ 60.173335] ubi0: scanning is finished
[ 60.177297] ubi0 error: ubi_read_volume_table: the layout volume was not found
[ 60.184878] ubi0 error: ubi_attach_mtd_dev: failed to attach mtd5, error -22
[ 60.192397] UBI error: cannot attach mtd5
[ 60.197652] pxa-rtc pxa-rtc: setting system clock to 2000-01-01 00:01:25 UTC (946684885)
[ 60.282788] smc91x smc91x.0 eth0: link down
[ 62.152546] smc91x smc91x.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[ 62.198419] IP-Config: Complete:
[ 62.201766] device=eth0, hwaddr=00:0e:0c:a7:26:f7, ipaddr=192.168.1.232, mask=255.255.255.0, gw=255.255.255.255
[ 62.212438] host=192.168.1.232, domain=, nis-domain=(none)
[ 62.218511] bootserver=192.168.1.5, rootserver=192.168.1.5, rootpath=
[ 62.226759] ALSA device list:
[ 62.230209] #0: Zylonite
[ 62.255735] Freeing unused kernel memory: 2396K
[ 62.260675] This architecture does not have kernel memory protection.
Starting logging: OK
^ permalink raw reply
* [PATCH] IIO: ADC: stm32-dfsdm: avoid unused-variable warning
From: Arnaud Pouliquen @ 2018-01-11 17:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <866335ff-d9a8-99c0-0946-82b3f207f266@arm.com>
On 01/11/2018 03:27 PM, Robin Murphy wrote:
> On 11/01/18 10:34, Arnd Bergmann wrote:
>> Building with CONFIG_OF disabled produces a compiler warning:
>>
>> drivers/iio/adc/stm32-dfsdm-core.c: In function 'stm32_dfsdm_probe':
>> drivers/iio/adc/stm32-dfsdm-core.c:245:22: error: unused variable
>> 'pnode' [-Werror=unused-variable]
>>
>> This removes the variable and open-codes it in the only place
>> it gets used to avoid that warning.
>>
>> Fixes: bed73904e76f ("IIO: ADC: add stm32 DFSDM core support")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>> ---
>> ? drivers/iio/adc/stm32-dfsdm-core.c | 3 +--
>> ? 1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/drivers/iio/adc/stm32-dfsdm-core.c
>> b/drivers/iio/adc/stm32-dfsdm-core.c
>> index 72427414db7f..6cd655f8239b 100644
>> --- a/drivers/iio/adc/stm32-dfsdm-core.c
>> +++ b/drivers/iio/adc/stm32-dfsdm-core.c
>> @@ -242,7 +242,6 @@ MODULE_DEVICE_TABLE(of, stm32_dfsdm_of_match);
>> ? static int stm32_dfsdm_probe(struct platform_device *pdev)
>> ? {
>> ????? struct dfsdm_priv *priv;
>> -??? struct device_node *pnode = pdev->dev.of_node;
>> ????? const struct of_device_id *of_id;
>> ????? const struct stm32_dfsdm_dev_data *dev_data;
>> ????? struct stm32_dfsdm *dfsdm;
>> @@ -254,7 +253,7 @@ static int stm32_dfsdm_probe(struct
>> platform_device *pdev)
>> ? ????? priv->pdev = pdev;
>> ? -??? of_id = of_match_node(stm32_dfsdm_of_match, pnode);
>> +??? of_id = of_match_node(stm32_dfsdm_of_match, pdev->dev.of_node);
>> ????? if (!of_id->data) {
>> ????????? dev_err(&pdev->dev, "Data associated to device is missing\n");
>> ????????? return -EINVAL;
>
> FWIW, it looks like this whole lot could be cleaned up by using
> of_device_get_match_data().
>
Right, and test of the return now seems to me an overprotection as data
structure is defined in the driver...
Same optimization could be applied to stm32_dfsdm_adc_probe function.
Here is the patch I tested:
---
drivers/iio/adc/stm32-dfsdm-adc.c | 9 +--------
drivers/iio/adc/stm32-dfsdm-core.c | 9 +--------
2 files changed, 2 insertions(+), 16 deletions(-)
diff --git a/drivers/iio/adc/stm32-dfsdm-adc.c
b/drivers/iio/adc/stm32-dfsdm-adc.c
index b03ca3f..01836c9 100644
--- a/drivers/iio/adc/stm32-dfsdm-adc.c
+++ b/drivers/iio/adc/stm32-dfsdm-adc.c
@@ -1087,18 +1087,11 @@ static int stm32_dfsdm_adc_probe(struct
platform_device *pdev)
struct device_node *np = dev->of_node;
const struct stm32_dfsdm_dev_data *dev_data;
struct iio_dev *iio;
- const struct of_device_id *of_id;
char *name;
int ret, irq, val;
- of_id = of_match_node(stm32_dfsdm_adc_match, np);
- if (!of_id->data) {
- dev_err(&pdev->dev, "Data associated to device is missing\n");
- return -EINVAL;
- }
-
- dev_data = (const struct stm32_dfsdm_dev_data *)of_id->data;
+ dev_data = of_device_get_match_data(dev);
iio = devm_iio_device_alloc(dev, sizeof(*adc));
if (IS_ERR(iio)) {
dev_err(dev, "%s: Failed to allocate IIO\n", __func__);
diff --git a/drivers/iio/adc/stm32-dfsdm-core.c
b/drivers/iio/adc/stm32-dfsdm-core.c
index 7242741..6290332 100644
--- a/drivers/iio/adc/stm32-dfsdm-core.c
+++ b/drivers/iio/adc/stm32-dfsdm-core.c
@@ -242,8 +242,6 @@ MODULE_DEVICE_TABLE(of, stm32_dfsdm_of_match);
static int stm32_dfsdm_probe(struct platform_device *pdev)
{
struct dfsdm_priv *priv;
- struct device_node *pnode = pdev->dev.of_node;
- const struct of_device_id *of_id;
const struct stm32_dfsdm_dev_data *dev_data;
struct stm32_dfsdm *dfsdm;
int ret;
@@ -254,13 +252,8 @@ static int stm32_dfsdm_probe(struct platform_device
*pdev)
priv->pdev = pdev;
- of_id = of_match_node(stm32_dfsdm_of_match, pnode);
- if (!of_id->data) {
- dev_err(&pdev->dev, "Data associated to device is missing\n");
- return -EINVAL;
- }
+ dev_data = of_device_get_match_data(&pdev->dev);
- dev_data = (const struct stm32_dfsdm_dev_data *)of_id->data;
dfsdm = &priv->dfsdm;
dfsdm->fl_list = devm_kcalloc(&pdev->dev, dev_data->num_filters,
sizeof(*dfsdm->fl_list), GFP_KERNEL);
--
Arnd,
fell free to propose it (with my acked-by) or tell me if you
prefer that i send it.
Thanks,
Arnaud
^ permalink raw reply related
* [PATCH 2/2] kasan: clean up KASAN_SHADOW_SCALE_SHIFT usage
From: Will Deacon @ 2018-01-11 17:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff221eca3db7a1f208c30c625b7d209fba33abb9.1515684162.git.andreyknvl@google.com>
On Thu, Jan 11, 2018 at 04:29:09PM +0100, Andrey Konovalov wrote:
> Right now the fact that KASAN uses a single shadow byte for 8 bytes of
> memory is scattered all over the code.
>
> This change defines KASAN_SHADOW_SCALE_SHIFT early in asm include files
> and makes use of this constant where necessary.
>
> Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
> ---
> arch/arm64/include/asm/kasan.h | 3 ++-
> arch/arm64/include/asm/memory.h | 3 ++-
> arch/arm64/mm/kasan_init.c | 3 ++-
> arch/x86/include/asm/kasan.h | 8 ++++++--
> include/linux/kasan.h | 2 --
> 5 files changed, 12 insertions(+), 7 deletions(-)
For the arm64 parts:
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
* [PATCH 00/10] perf tools: Add support for CoreSight trace decoding
From: Kim Phillips @ 2018-01-11 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANLsYkzBi3M48VtUYJcSREshXBxiaN5m5RsCcdi=4C1Z7jmMoA@mail.gmail.com>
On Thu, 11 Jan 2018 08:45:21 -0700
Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> On 11 January 2018 at 05:23, Mark Brown <broonie@kernel.org> wrote:
> > On Wed, Jan 10, 2018 at 06:08:21PM -0600, Kim Phillips wrote:
> >> Mathieu Poirier <mathieu.poirier@linaro.org> wrote:
> >
> >> > Instructions on how to build and install the openCSD library are provided
> >> > in the HOWTO.md of the project repository.
> >
> >> Usually when a perf builder sees something they need "on," they - or,
> >> at least I - start querying the host's package manager for something
> >> that provides it (e.g., apt search/install libopencsd), but since no
> >> distro provides libopencsd, this is bad because it misleads the user.
> >
> > It's on the radar to push this at distros fairly soon.
Adding packages to distros takes years, this patchset is being
submitted for inclusion *now*. So until then, it would greatly
facilitate users if the relevant libopencsd source files were
self-contained within perf from the get go.
> > Part of the
> > discussion was wanting to get things to the point where the tools using
> > the library were far enough along that we could be reasonably sure that
Curious, what other tools are there?
> > there weren't any problems that were going to require ABI breaks to fix
> > before pushing the library at distros since ABI churn isn't nice for
> > packagers to deal with.
Why make perf the guinea pig? Whatever, this doesn't preclude
adding the code into the tree; it can be removed years from now when
libopencsd becomes ubiquitous among distros.
> > There's also a bit of a chicken and egg problem
> > in that it's a lot easier to get distros to package libraries that have
> > users available (some are not really bothered about this of course but
> > it still helps).
>
> Moreover including in the kernel tree every library that can
> potentially be used by the perf tools simply doesn't scale.
This is a trace decoder library we're talking about: there are no
others in perf's system features autodetection list. And why wouldn't
adding such libraries scale?
> The perf
> tools project has come up with a very cleaver way to deal with
> external dependencies and I don't see why the OpenCSD library should
> be different.
Again, the opencsd library is a decoder library: this patchseries adds
it as a package dependency (when it isn't even a package in any
distro), and it's different in that it's the first decoder library to
be submitted as an external dependency (i.e., not fully built-in, like
Intel's, or even the Arm SPE's pending submission).
> >> Keeping the library external will also inevitably introduce more
> >> source level synchronization problems because the perf sources being
> >> built may not be compatible with their version of the library, whether
> >> due to new features like new trace hardware support, or API changes.
> >
> > Perf users installing from source rather than from a package (who do
> > tend to the more technical side even for kernel developers) already have
> > to cope with potentially installing at least dwarf, gtk2, libaudit,
> > libbfd, libelf, libnuma, libperl, libpython, libslang, libcrypto,
> > libunwind, libdw-dwarf-unwind, zlib, lzma, bpf and OpenJDK depending on
> > which features they want. I'm not sure that adding one more library is
> > going to be the end of the world here, especially once the packaging
> > starts to filter through distros. Until that happens at least people
> > are no worse off for not having the feature.
>
> I completely agree. Just like any other package, people that want the
> very latest code need to install from source.
A fully-integrated solution would work better for people, e.g., how are
people supposed to know what 'latest' is when there are separate,
unsynchronized git repos?
> >> As Mark Brown (cc'd) mentioned on the Coresight mailing list, this may
> >> be able to be done the same way the dtc is incorporated into the
> >> kernel, where only its relevant sources are included and updated as
> >> needed: see linux/scripts/dtc/update-dtc-source.sh.
> >
> > Bear in mind that we need dtc for essentially all kernel development on
> > ARM and when it was introduced it was a new requirement for existing
> > systems, it's a bit of a different case here where it's an optional
> > feature in an optional tool.
That argument applies to Intel-PT, yet its decoder is self-contained
within perf: all non-x86 perf binaries are capable of decoding PT.
We'd want that for Arm Coresight where perf gets statically built to
run on much more constrained systems like Android.
Or are you referring to the higher level linux/scripts/ location of the
dtc? That's not my point: the libopencsd sources can live under
somewhere like linux/tools/.
Kim
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: David Lechner @ 2018-01-11 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xKORFriQ2Gjx85OsCUzHO-mavCQXLOzh5D3n4kEG=i-Yg@mail.gmail.com>
On 01/11/2018 06:45 AM, Adam Ford wrote:
> On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david@lechnology.com> wrote:
>> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>>
>>>
>>> I am available tomorrow to build and test patches against the
>>> da850-evm. I just need to know which version(s) to test.
>>
>>
>> Great. As per the cover letter:
>>
>> You can find a working branch with everything included in the
>> "common-clk-v5"
>> branch of https://github.com/dlech/ev3dev-kernel.git.
>
> I wasn't sure if things had changed after some of the dialog about the
> bindings and device tree.
Not yet. ;-)
>
> Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
> CST 2018
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
> CPU: VIVT data cache, VIVT instruction cache
> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
OK, using device tree...
> Memory policy: Data cache writethrough
> cma: Reserved 16 MiB at 0xc2c00000
> DaVinci da850/omap-l138 variant 0x0
> random: fast init done
> Built 1 zonelists, mobility grouping on. Total pages: 16256
> Kernel command line: console=ttyS2,115200n8 root=PARTUUID= rw
> rootfstype=ext4 rootwait
> Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
> Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
> Memory: 42164K/65536K available (4548K kernel code, 280K rwdata, 1044K
> rodata, 232K init, 143K bss, 6988K reserved, 16384K cma-reserved)
> Virtual kernel memory layout:
> vector : 0xffff0000 - 0xffff1000 ( 4 kB)
> fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
> vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
> lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
> modules : 0xbf000000 - 0xc0000000 ( 16 MB)
> .text : 0x(ptrval) - 0x(ptrval) (4550 kB)
> .init : 0x(ptrval) - 0x(ptrval) ( 232 kB)
> .data : 0x(ptrval) - 0x(ptrval) ( 281 kB)
> .bss : 0x(ptrval) - 0x(ptrval) ( 144 kB)
> SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
> Preemptible hierarchical RCU implementation.
> Tasks RCU enabled.
> NR_IRQS: 245
> clocksource: timer0_1: mask: 0xffffffff max_cycles: 0xffffffff,
> max_idle_ns: 79635851949 ns
> sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every
> 89478484971ns
> Console: colour dummy device 80x30
> Calibrating delay loop... 148.88 BogoMIPS (lpj=744448)
> pid_max: default: 32768 minimum: 301
> Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
> Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
> CPU: Testing write buffer coherency: ok
> Setting up static identity map for 0xc0008400 - 0xc0008458
> Hierarchical SRCU implementation.
> devtmpfs: initialized
> clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
> max_idle_ns: 19112604462750000 ns
> futex hash table entries: 256 (order: -1, 3072 bytes)
> pinctrl core: initialized pinctrl subsystem
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> cpuidle: using governor menu
> mux: initialized RTC_ALARM
> mux: Setting register RTC_ALARM
> mux: PINMUX0 (0x00000000) = 0x44080000 -> 0x24080000
> edma 1c00000.edma: memcpy is disabled
> edma 1c00000.edma: TI EDMA DMA engine driver
> edma 1e30000.edma: memcpy is disabled
> edma 1e30000.edma: TI EDMA DMA engine driver
> i2c_davinci 1c22000.i2c: could not find pctldev for node
> /soc at 1c00000/pinmux at 14120/pinmux_i2c0_pins, deferring probe
> clocksource: Switched to clocksource timer0_1
> NET: Registered protocol family 2
> TCP established hash table entries: 1024 (order: 0, 4096 bytes)
> TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
> TCP: Hash tables configured (established 1024 bind 1024)
> UDP hash table entries: 256 (order: 0, 4096 bytes)
> UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
> NET: Registered protocol family 1
> RPC: Registered named UNIX socket transport module.
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> RPC: Registered tcp NFSv4.1 backchannel transport module.
> Initialise system trusted keyrings
> workingset: timestamp_bits=30 max_order=14 bucket_order=0
> Key type asymmetric registered
> Asymmetric key parser 'x509' registered
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
> io scheduler noop registered (default)
> io scheduler mq-deadline registered
> io scheduler kyber registered
> pinctrl-single 1c14120.pinmux: 160 pins at pa fdfe34a6 size 80
> Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
> 1c42000.serial: ttyS0 at MMIO 0x1c42000 (irq = 25, base_baud =
> 9375000) is a TI DA8xx/66AK2x
> 1d0c000.serial: ttyS1 at MMIO 0x1d0c000 (irq = 53, base_baud =
> 8250000) is a TI DA8xx/66AK2x
> 1d0d000.serial: ttyS2 at MMIO 0x1d0d000 (irq = 61, base_baud =
> 8250000) is a TI DA8xx/66AK2x
> console [ttyS2] enabled
If you are getting to this point, you probably don't need DEBUG_LL.
It looks like "earlyprint" is not being passed to the command line
anyway, so CONFIG_EARLY_PRINTK is not actually doing anything.
> brd: module loaded
> libphy: Fixed MDIO Bus: probed
> davinci_mdio 1e24000.mdio: failed to get device clock
> davinci_mdio: probe of 1e24000.mdio failed with error -2
It looks like this needs a clock-names property in the device tree.
Please make this change and try again:
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 08a9817..fd3e316 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -713,6 +713,7 @@
#size-cells = <0>;
reg = <0x224000 0x1000>;
clocks = <&psc1 5>;
+ clock-names = "fck";
status = "disabled";
};
eth0: ethernet at 220000 {
> i2c /dev entries driver
> davinci_mmc 1c40000.mmc: Using DMA, 4-bit mode
> NET: Registered protocol family 10
> Segment Routing with IPv6
> sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
> NET: Registered protocol family 17
> Loading compiled-in X.509 certificates
> mmc0: host does not support reading read-only switch, assuming
> write-enable
> mmc0: new high speed SDHC card at address b368
> mmcblk0: mmc0:b368 00000 3.75 GiB
> mmcblk0: p1 p2
> pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
> pca953x 0-0020: failed reading register
> pca953x: probe of 0-0020 failed with error -121
I'm not sure why there is an error here. I'm using I2C0 on my board,
so I am fairly confident that it is not a problem introduced by this
series.
> console [netcon0] enabled
> netconsole: network logging started
> davinci_emac 1e20000.ethernet: incompatible machine/device type for
> reading mac address
> hctosys: unable to open rtc device (rtc0)
>
What is normally the next line after this in a working boot?
Also please try passing "clk_ignore_unused" to the kernel command line.
^ permalink raw reply related
* [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property
From: Timur Tabi @ 2018-01-11 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACxGe6vA652LCosMc+AsQ2Gb_mgiApx+Gxu9judXnO_p3AFcsw@mail.gmail.com>
On 01/11/2018 10:33 AM, Grant Likely wrote:
> What level of access control is implemented here? Is there access
> control for each GPIO individually, or is it done by banks of GPIOs?
> Just asking to make sure I understand the problem domain.
On our ACPI system, it's specific GPIOs. Each GPIO is in its own 64k
page, which is what allows us to block specific ones.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH net-next v4 0/4] net: mvpp2: 1000BaseX and 2500BaseX support
From: Thomas Petazzoni @ 2018-01-11 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111.113203.1899608306187914852.davem@davemloft.net>
Hello,
On Thu, 11 Jan 2018 11:32:03 -0500 (EST), David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 11 Jan 2018 11:23:37 -0500 (EST)
>
> > From: Antoine Tenart <antoine.tenart@free-electrons.com>
> > Date: Wed, 10 Jan 2018 16:58:04 +0100
> >
> >> This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
> >> driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
> >> common PHY driver (cp110-comphy).
> >
> > Series applied, thank you.
>
> Actually, this introduced build warnings, I'm reverting. Please fix this
> and repost.
>
> Thank you.
>
> drivers/net/ethernet/marvell/mvpp2.c: In function ?mvpp2_port_mii_gmac_configure_mode?:
> drivers/net/ethernet/marvell/mvpp2.c:4687:26: warning: suggest parentheses around comparison in operand of ?|? [-Wparentheses]
> if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX |
> ~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This is actually a very good warning: it should be a || and not |.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 06/19] drm/blend: Add a generic alpha property
From: Daniel Vetter @ 2018-01-11 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111155857.bbfp4772fx56s5k3@flea.lan>
On Thu, Jan 11, 2018 at 4:58 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
>> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
>> > On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
>> > > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
>> > > > Some drivers duplicate the logic to create a property to store a per-plane
>> > > > alpha.
>> > > >
>> > > > Let's create a helper in order to move that to the core.
>> > > >
>> > > > Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
>> > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
>> > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>> > >
>> > > Do we have userspace for this?
>> >
>> > Wayland seems to be on its way to implement this, with ChromeOS using
>> > it:
>> > https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
>> >
>> > and more specifically:
>> > https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118
>>
>> Yay, would be good to include these links in the patch description. Really
>> happy we're having a real standard now used by multiple people.
>
> I will.
>
>> > > Is encoding a fixed 0-255 range really the best idea?
>> >
>> > I don't really know, is there hardware or formats where there is more
>> > than 255? Or did you mean less than that?
>>
>> 30bit I'd assume wants more alpha. In the past we've done some fixed-point
>> stuff (e.g. for LUT), using the 0.0-1.0 float range. Using that for the
>> blend equation docs is also what I recommend (and that we map from 0-255
>> to 0.0-1.0 logically). Ofc the hw might not do any of that ... I think
>> 0.16 fixed point, stored in a u16 is probably best. That's what we're
>> doing for gamma tables already, and that way drivers can simply throw away
>> the lower bits.
>
> But that would also break the two users of that property that won't be
> able to move to the generic property (with the same name) without
> breaking userspace. The point of that patch was to allow some code
> consolidation, and that would mean failing to do so here :/
Let me try to clarify:
- We'll keep the exact existing property semantics with the 0-255
range for the userspace visible property.
- But internally, in the decode value that we store into
drm_plane_state, we'll do the slightly more future proof thing with a
few more bits.
That gives us the option of exposing those bits in the future without
having to change all the drivers again (which we have to do for this
series here already anyway, since the decoded value moves into
drm_plane_state from driver subclasses).
Definitely not asking to break userspace here :-)
Cheers, Daniel
>> > > I know other drivers have skimped on the rules here a bit ... But at least
>> > > internally (i.e. within the drm_plane_state) we probably should restrict
>> > > ourselves to u8. And this needs real docs (i.e. the full blend equation
>> > > drivers are supposed to implement).
>> >
>> > You mean straight vs premultiplied? Maybe we should implement this as
>> > an additional property in read only depending on how the hardware
>> > behaves?
>>
>> No need for an additional property right now, but definitely document
>> whether you mean straight or pre-multiplied. Just writing down the blend
>> equation is probably best.
>
> Ack.
>
> Thanks!
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
>
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 2/3] dt-bindings: pinctrl: Add a ngpios-ranges property
From: Grant Likely @ 2018-01-11 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdaN6vmV4L4U76DvD5BN+j1RYCQakTysA+GGPdT8Chc-iw@mail.gmail.com>
On Wed, Jan 10, 2018 at 1:37 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
> On Wed, Jan 10, 2018 at 2:58 AM, Stephen Boyd <sboyd@codeaurora.org> wrote:
>
>> Some qcom platforms make some GPIOs or pins unavailable for use
>> by non-secure operating systems, and thus reading or writing the
>> registers for those pins will cause access control issues.
>> Introduce a DT property to describe the set of GPIOs that are
>> available for use so that higher level OSes are able to know what
>> pins to avoid reading/writing.
What level of access control is implemented here? Is there access
control for each GPIO individually, or is it done by banks of GPIOs?
Just asking to make sure I understand the problem domain.
>>
>> Cc: <devicetree@vger.kernel.org>
>> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
>
> I like the idea, let's check what we think about the details regarding
> naming and semantics, I need feedback from some DT people
> in particular.
>
> Paging in Grant on this as he might have some input.
>
>> I stuck this inside msm8996, but maybe it can go somewhere more generic?
>
> Yeah just put it in Documentation/devicetree/bindings/gpio/gpio.txt
> Everyone and its dog doing GPIO reservations "from another world"
> will need to use this.
>
>> +- ngpios-ranges:
>> + Usage: optional
>> + Value type: <prop-encoded-array>
>> + Definition: Tuples of GPIO ranges (base, size) indicating
>> + GPIOs available for use.
>> +
>> Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
>> a general description of GPIO and interrupt bindings.
>
> I like the tuples syntax. That's fine. It's like gpio-ranges we have
> already to map between pin controllers and GPIO.
>
> I don't think we can reuse gpio-ranges because that is
> exclusively for pin control ATM, it would be fine if the ranges
> were for a specific device, like pin control does, like:
>
> gpio-ranges = <&secure_world_thing 0 20 10>;
>
> But you definately would need a node to tie it to, so that the
> driver for that node can specify that it's gonna take the
> GPIOs.
>
> But I think the semantics should be the inverse. That you
> point out "holes" with the lines we *can't* use.
>
> We already support a generic property "ngpios" that says how
> many of the GPIOs (counted from zero) that can be used,
> so if those should be able to use this as a generic property it
> is better with the inverse semantics and say that the
> "reserved-gpio-ranges", "secureworld-gpio-ranges"
> (or whatever we decide to call it) takes precedence over
> ngpios so we don't end up in ambigous places.
Heh, I just went down the same thought process on the naming before I
read the above. Yes I agree. The property name should have something
like "reserved" in it. I vote for "gpio-reserved-ranges" because it
puts the binding owner (gpio) at the front of the name, it indicates
that the list is unavailable GPIOs, and that the format is a set of
ranges.
The fiddly bit is it assumes the GPIOs are described by a single
number. It works fine as long as the GPIO controllers can use a single
cell to describe a gpio number (instead of having #gpio-cells = 3 with
the first cell being bank, the second being number in bank, and the
third being flags).
>
> Then, will it be possible to put the parsing, handling and
> disablement of these ranges into drivers/gpio/gpiolib-of.c
> where we handle the ranges today, or do we need to
> do it in the individual drivers?
I certainly would prefer parsing this in common code, and not in
individual drivers, but again it becomes hard for any driver using
multiple cells to describe the local GPIO number. I think the guidance
here needs to be that the property is relevant when the internal GPIO
number representation fits within a uint32, which realistically should
never be a problem.
g.
^ permalink raw reply
* [PATCH net-next v4 0/4] net: mvpp2: 1000BaseX and 2500BaseX support
From: David Miller @ 2018-01-11 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111.112337.98385023847631863.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 11 Jan 2018 11:23:37 -0500 (EST)
> From: Antoine Tenart <antoine.tenart@free-electrons.com>
> Date: Wed, 10 Jan 2018 16:58:04 +0100
>
>> This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
>> driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
>> common PHY driver (cp110-comphy).
>
> Series applied, thank you.
Actually, this introduced build warnings, I'm reverting. Please fix this
and repost.
Thank you.
drivers/net/ethernet/marvell/mvpp2.c: In function ?mvpp2_port_mii_gmac_configure_mode?:
drivers/net/ethernet/marvell/mvpp2.c:4687:26: warning: suggest parentheses around comparison in operand of ?|? [-Wparentheses]
if (port->phy_interface == PHY_INTERFACE_MODE_1000BASEX |
~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
^ permalink raw reply
* [PATCH v2] MAINTAINERS: mtd/nand: update Microchip nand entry
From: Nicolas Ferre @ 2018-01-11 16:26 UTC (permalink / raw)
To: linux-arm-kernel
Update Wenyou Yang email address.
Take advantage of this update to move this entry to the MICROCHIP / ATMEL
location and add the DT binding documentation link.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Acked-by: Wenyou Yang <wenyou.yang@microchip.com>
---
v2: - patch agains 09ec417b0ea8 ("mtd: nand: samsung: Disable subpage
writes on E-die NAND") of
http://git.infradead.org/linux-mtd.git/shortlog/refs/heads/nand/next
- Ack by Wenyou added
Hi,
v1 patch was part of a series because it was conflicting with the previous one
named:
"[PATCH 1/2] MAINTAINERS: linux-media: update Microchip ISI and ISC entries"
Boris asked me to rebase it so that they are independent.
So, if this first one goes upstream through another tree, conflicts will have
to be resolved at one point.
Best regards,
Nicolas
MAINTAINERS | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index aa71ab52fd76..37ee5ae4bae2 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2382,13 +2382,6 @@ F: Documentation/devicetree/bindings/input/atmel,maxtouch.txt
F: drivers/input/touchscreen/atmel_mxt_ts.c
F: include/linux/platform_data/atmel_mxt_ts.h
-ATMEL NAND DRIVER
-M: Wenyou Yang <wenyou.yang@atmel.com>
-M: Josh Wu <rainyfeeling@outlook.com>
-L: linux-mtd at lists.infradead.org
-S: Supported
-F: drivers/mtd/nand/atmel/*
-
ATMEL SAMA5D2 ADC DRIVER
M: Ludovic Desroches <ludovic.desroches@microchip.com>
L: linux-iio at vger.kernel.org
@@ -9045,6 +9038,14 @@ F: drivers/media/platform/atmel/atmel-isc.c
F: drivers/media/platform/atmel/atmel-isc-regs.h
F: devicetree/bindings/media/atmel-isc.txt
+MICROCHIP / ATMEL NAND DRIVER
+M: Wenyou Yang <wenyou.yang@microchip.com>
+M: Josh Wu <rainyfeeling@outlook.com>
+L: linux-mtd at lists.infradead.org
+S: Supported
+F: drivers/mtd/nand/atmel/*
+F: Documentation/devicetree/bindings/mtd/atmel-nand.txt
+
MICROCHIP KSZ SERIES ETHERNET SWITCH DRIVER
M: Woojung Huh <Woojung.Huh@microchip.com>
M: Microchip Linux Driver Support <UNGLinuxDriver@microchip.com>
--
2.9.0
^ permalink raw reply related
* [PATCH net-next v4 0/4] net: mvpp2: 1000BaseX and 2500BaseX support
From: David Miller @ 2018-01-11 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180110155808.3484-1-antoine.tenart@free-electrons.com>
From: Antoine Tenart <antoine.tenart@free-electrons.com>
Date: Wed, 10 Jan 2018 16:58:04 +0100
> This series adds 1000BaseX and 2500BaseX support to the Marvell PPv2
> driver. In order to use it, the 2.5 SGMII mode is added in the Marvell
> common PHY driver (cp110-comphy).
Series applied, thank you.
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: Adam Ford @ 2018-01-11 16:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14320e05-c6f7-fa2d-35cd-c01414c59f2f@ti.com>
On Thu, Jan 11, 2018 at 9:47 AM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Thursday 11 January 2018 06:15 PM, Adam Ford wrote:
>> On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david@lechnology.com> wrote:
>>> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>>>
>>>>
>>>> I am available tomorrow to build and test patches against the
>>>> da850-evm. I just need to know which version(s) to test.
>>>
>>>
>>> Great. As per the cover letter:
>>>
>>> You can find a working branch with everything included in the
>>> "common-clk-v5"
>>> branch of https://github.com/dlech/ev3dev-kernel.git.
>>
>> I wasn't sure if things had changed after some of the dialog about the
>> bindings and device tree.
>>
>> Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
>>
>> Starting kernel ...
>>
>> Uncompressing Linux... done, booting the kernel.
>> Booting Linux on physical CPU 0x0
>> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
>> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
>> CST 2018
>> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
>> CPU: VIVT data cache, VIVT instruction cache
>> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
>> Memory policy: Data cache writethrough
>> cma: Reserved 16 MiB at 0xc2c00000
>> DaVinci da850/omap-l138 variant 0x0
>> random: fast init done
>> Built 1 zonelists, mobility grouping on. Total pages: 16256
>> Kernel command line: console=ttyS2,115200n8 root=PARTUUID= rw
>
> Pretty sure an actual UUID is missing here.
>
When I setup root to be on the /dev/mmcblk0, I get the same result.
The kernel still hangs. It doesn't hang using the mainline kernel
without this patch series
Starting kernel ...
Uncompressing Linux... done, booting the kernel.
Booting Linux on physical CPU 0x0
Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
(Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
CST 2018
CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
CPU: VIVT data cache, VIVT instruction cache
OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
Memory policy: Data cache writethrough
cma: Reserved 16 MiB at 0xc2c00000
DaVinci da850/omap-l138 variant 0x0
random: fast init done
Built 1 zonelists, mobility grouping on. Total pages: 16256
Kernel command line: console=ttyS2,115200n8 root=/dev/mmcblk0p2 rw
rootfstype=ext4 rootwait
Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
Memory: 42164K/65536K available (4548K kernel code, 280K rwdata, 1044K
rodata, 232K init, 143K bss, 6988K reserved, 16384K cma-reserved)
Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
vmalloc : 0xc4800000 - 0xff800000 ( 944 MB)
lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
modules : 0xbf000000 - 0xc0000000 ( 16 MB)
.text : 0x(ptrval) - 0x(ptrval) (4550 kB)
.init : 0x(ptrval) - 0x(ptrval) ( 232 kB)
.data : 0x(ptrval) - 0x(ptrval) ( 281 kB)
.bss : 0x(ptrval) - 0x(ptrval) ( 144 kB)
SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
Preemptible hierarchical RCU implementation.
Tasks RCU enabled.
NR_IRQS: 245
clocksource: timer0_1: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 79635851949 ns
sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 89478484971ns
Console: colour dummy device 80x30
Calibrating delay loop... 148.88 BogoMIPS (lpj=744448)
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
CPU: Testing write buffer coherency: ok
Setting up static identity map for 0xc0008400 - 0xc0008458
Hierarchical SRCU implementation.
devtmpfs: initialized
clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 19112604462750000 ns
futex hash table entries: 256 (order: -1, 3072 bytes)
pinctrl core: initialized pinctrl subsystem
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
cpuidle: using governor menu
mux: initialized RTC_ALARM
mux: Setting register RTC_ALARM
mux: PINMUX0 (0x00000000) = 0x44080000 -> 0x24080000
edma 1c00000.edma: memcpy is disabled
edma 1c00000.edma: TI EDMA DMA engine driver
edma 1e30000.edma: memcpy is disabled
edma 1e30000.edma: TI EDMA DMA engine driver
i2c_davinci 1c22000.i2c: could not find pctldev for node
/soc at 1c00000/pinmux at 14120/pinmux_i2c0_pins, deferring probe
clocksource: Switched to clocksource timer0_1
NET: Registered protocol family 2
TCP established hash table entries: 1024 (order: 0, 4096 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
UDP hash table entries: 256 (order: 0, 4096 bytes)
UDP-Lite hash table entries: 256 (order: 0, 4096 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Initialise system trusted keyrings
workingset: timestamp_bits=30 max_order=14 bucket_order=0
Key type asymmetric registered
Asymmetric key parser 'x509' registered
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 251)
io scheduler noop registered (default)
io scheduler mq-deadline registered
io scheduler kyber registered
pinctrl-single 1c14120.pinmux: 160 pins at pa fdfe34a6 size 80
Serial: 8250/16550 driver, 3 ports, IRQ sharing disabled
1c42000.serial: ttyS0 at MMIO 0x1c42000 (irq = 25, base_baud =
9375000) is a TI DA8xx/66AK2x
1d0c000.serial: ttyS1 at MMIO 0x1d0c000 (irq = 53, base_baud =
8250000) is a TI DA8xx/66AK2x
1d0d000.serial: ttyS2 at MMIO 0x1d0d000 (irq = 61, base_baud =
8250000) is a TI DA8xx/66AK2x
console [ttyS2] enabled
brd: module loaded
libphy: Fixed MDIO Bus: probed
davinci_mdio 1e24000.mdio: failed to get device clock
davinci_mdio: probe of 1e24000.mdio failed with error -2
i2c /dev entries driver
davinci_mmc 1c40000.mmc: Using DMA, 4-bit mode
NET: Registered protocol family 10
Segment Routing with IPv6
sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
NET: Registered protocol family 17
Loading compiled-in X.509 certificates
mmc0: host does not support reading read-only switch, assuming write-enable
mmc0: new high speed SDHC card at address b368
mmcblk0: mmc0:b368 00000 3.75 GiB
mmcblk0: p1 p2
pca953x 0-0020: 0-0020 supply vcc not found, using dummy regulator
pca953x 0-0020: failed reading register
pca953x: probe of 0-0020 failed with error -121
console [netcon0] enabled
netconsole: network logging started
davinci_emac 1e20000.ethernet: incompatible machine/device type for
reading mac address
hctosys: unable to open rtc device (rtc0)
> Thanks,
> Sekhar
^ permalink raw reply
* [PATCH 06/19] drm/blend: Add a generic alpha property
From: Maxime Ripard @ 2018-01-11 15:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180109142834.GZ26573@phenom.ffwll.local>
On Tue, Jan 09, 2018 at 03:28:34PM +0100, Daniel Vetter wrote:
> On Tue, Jan 09, 2018 at 02:53:22PM +0100, Maxime Ripard wrote:
> > On Tue, Jan 09, 2018 at 01:32:41PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 09, 2018 at 11:56:25AM +0100, Maxime Ripard wrote:
> > > > Some drivers duplicate the logic to create a property to store a per-plane
> > > > alpha.
> > > >
> > > > Let's create a helper in order to move that to the core.
> > > >
> > > > Cc: Boris Brezillon <boris.brezillon@free-electrons.com>
> > > > Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > >
> > > Do we have userspace for this?
> >
> > Wayland seems to be on its way to implement this, with ChromeOS using
> > it:
> > https://lists.freedesktop.org/archives/wayland-devel/2017-August/034741.html
> >
> > and more specifically:
> > https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland-protocols/unstable/alpha-compositing/alpha-compositing-unstable-v1.xml#118
>
> Yay, would be good to include these links in the patch description. Really
> happy we're having a real standard now used by multiple people.
I will.
> > > Is encoding a fixed 0-255 range really the best idea?
> >
> > I don't really know, is there hardware or formats where there is more
> > than 255? Or did you mean less than that?
>
> 30bit I'd assume wants more alpha. In the past we've done some fixed-point
> stuff (e.g. for LUT), using the 0.0-1.0 float range. Using that for the
> blend equation docs is also what I recommend (and that we map from 0-255
> to 0.0-1.0 logically). Ofc the hw might not do any of that ... I think
> 0.16 fixed point, stored in a u16 is probably best. That's what we're
> doing for gamma tables already, and that way drivers can simply throw away
> the lower bits.
But that would also break the two users of that property that won't be
able to move to the generic property (with the same name) without
breaking userspace. The point of that patch was to allow some code
consolidation, and that would mean failing to do so here :/
> > > I know other drivers have skimped on the rules here a bit ... But at least
> > > internally (i.e. within the drm_plane_state) we probably should restrict
> > > ourselves to u8. And this needs real docs (i.e. the full blend equation
> > > drivers are supposed to implement).
> >
> > You mean straight vs premultiplied? Maybe we should implement this as
> > an additional property in read only depending on how the hardware
> > behaves?
>
> No need for an additional property right now, but definitely document
> whether you mean straight or pre-multiplied. Just writing down the blend
> equation is probably best.
Ack.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180111/3260f17f/attachment-0001.sig>
^ permalink raw reply
* [PATCH v5 01/44] dt-bindings: clock: Add new bindings for TI Davinci PLL clocks
From: Sekhar Nori @ 2018-01-11 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAHCN7xKORFriQ2Gjx85OsCUzHO-mavCQXLOzh5D3n4kEG=i-Yg@mail.gmail.com>
On Thursday 11 January 2018 06:15 PM, Adam Ford wrote:
> On Wed, Jan 10, 2018 at 8:50 PM, David Lechner <david@lechnology.com> wrote:
>> On 01/10/2018 04:24 PM, Adam Ford wrote:
>>>
>>>
>>> I am available tomorrow to build and test patches against the
>>> da850-evm. I just need to know which version(s) to test.
>>
>>
>> Great. As per the cover letter:
>>
>> You can find a working branch with everything included in the
>> "common-clk-v5"
>> branch of https://github.com/dlech/ev3dev-kernel.git.
>
> I wasn't sure if things had changed after some of the dialog about the
> bindings and device tree.
>
> Here is my log with DEBUG_LL and CONFIG_EARLY_PRINTK set :
>
> Starting kernel ...
>
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0x0
> Linux version 4.15.0-rc4-g8564e0f (aford at ubuntu16) (gcc version 7.2.0
> (Buildroot 2017.11.1-00021-g7b43660)) #2 PREEMPT Thu Jan 11 06:35:29
> CST 2018
> CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
> CPU: VIVT data cache, VIVT instruction cache
> OF: fdt: Machine model: DA850/AM1808/OMAP-L138 EVM
> Memory policy: Data cache writethrough
> cma: Reserved 16 MiB at 0xc2c00000
> DaVinci da850/omap-l138 variant 0x0
> random: fast init done
> Built 1 zonelists, mobility grouping on. Total pages: 16256
> Kernel command line: console=ttyS2,115200n8 root=PARTUUID= rw
Pretty sure an actual UUID is missing here.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 2/9] iommu/rockchip: Fix error handling in attach
From: Robin Murphy @ 2018-01-11 15:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20180111082229.24011-3-jeffy.chen@rock-chips.com>
On 11/01/18 08:22, Jeffy Chen wrote:
> From: Tomasz Figa <tfiga@chromium.org>
>
> Currently if the driver encounters an error while attaching device, it
> will leave the IOMMU in an inconsistent state. Even though it shouldn't
> really happen in reality, let's just add proper error path to keep
> things consistent.
>
> Signed-off-by: Tomasz Figa <tfiga@chromium.org>
> Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
> ---
>
> drivers/iommu/rockchip-iommu.c | 26 +++++++++++++++++---------
> 1 file changed, 17 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/rockchip-iommu.c b/drivers/iommu/rockchip-iommu.c
> index 9d991c2d8767..ee805e1dfba7 100644
> --- a/drivers/iommu/rockchip-iommu.c
> +++ b/drivers/iommu/rockchip-iommu.c
> @@ -826,17 +826,10 @@ static int rk_iommu_attach_device(struct iommu_domain *domain,
>
> ret = rk_iommu_force_reset(iommu);
> if (ret)
> - return ret;
> + goto err_disable_stall;
>
> iommu->domain = domain;
>
> - for (i = 0; i < iommu->num_irq; i++) {
> - ret = devm_request_irq(iommu->dev, iommu->irq[i], rk_iommu_irq,
> - IRQF_SHARED, dev_name(dev), iommu);
> - if (ret)
> - return ret;
> - }
> -
> for (i = 0; i < iommu->num_mmu; i++) {
> rk_iommu_write(iommu->bases[i], RK_MMU_DTE_ADDR,
> rk_domain->dt_dma);
> @@ -844,9 +837,16 @@ static int rk_iommu_attach_device(struct iommu_domain *domain,
> rk_iommu_write(iommu->bases[i], RK_MMU_INT_MASK, RK_MMU_IRQ_MASK);
> }
>
> + for (i = 0; i < iommu->num_irq; i++) {
> + ret = devm_request_irq(iommu->dev, iommu->irq[i], rk_iommu_irq,
> + IRQF_SHARED, dev_name(dev), iommu);
Why aren't we simply requesting the IRQ once in rk_iommu_probe()? Given
that the hardware doesn't handle multiple translation contexts, there
doesn't seem to be much point in being this dynamic about it.
Robin.
> + if (ret)
> + goto err_free_irq;
> + }
> +
> ret = rk_iommu_enable_paging(iommu);
> if (ret)
> - return ret;
> + goto err_free_irq;
>
> spin_lock_irqsave(&rk_domain->iommus_lock, flags);
> list_add_tail(&iommu->node, &rk_domain->iommus);
> @@ -857,6 +857,14 @@ static int rk_iommu_attach_device(struct iommu_domain *domain,
> rk_iommu_disable_stall(iommu);
>
> return 0;
> +
> +err_free_irq:
> + while (i--)
> + devm_free_irq(iommu->dev, iommu->irq[i], iommu);
> +err_disable_stall:
> + rk_iommu_disable_stall(iommu);
> +
> + return ret;
> }
>
> static void rk_iommu_detach_device(struct iommu_domain *domain,
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox