l2c series
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 75 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 75 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [PATCH 00/75] l2c series
Quoted 48 lines · Russell King - ARM Linux
Quoted 47 lines · Michal Simek
Quoted 31 lines · Russell King - ARM Linux
Quoted 22 lines · Michal Simek
Quoted 21 lines · Russell King - ARM Linux
Quoted 19 lines · Michal Simek
Hi Russell,
Quoted 9 lines · Russell King - ARM Linux
This is another posting of the L2 cache controller series. I'm not planning for this for the upcoming merge window, but the one after, as people need to test it and still need to feed back to me on various issues. Hence, this is not a finalised series.
There are still various issues which I've raised, and have had no feedback on.
This series is being posted with Cc's on the individual patches.
I just want to also point you that we have sent EDAC support for pl310 which will be good to have it for L2.
[RFC PATCH] EDAC support for ARM PL310 cache controller [RFC PATCH] edac: add support for ARM PL310 L2 cache parity
http://lkml.org/lkml/2014/3/2/85
http://lkml.org/lkml/2014/3/2/87Quoted 7 lines
Quoted 3 lines
As seems to be the norm, lkml.org is broken... please find a different archive instead. :)
Here it is:
http://lkml.iu.edu/hypermail/linux/kernel/1403.0/00250.html
http://lkml.iu.edu/hypermail/linux/kernel/1403.0/00251.htmlQuoted 5 lines
A number of comments immediately spring to mind:
- the use of writel/readl rather than their ARM specific
_relaxedversions is not a good idea: using the standard macros will result in another write due to the barrier.Not a problem to use
_relaxedversion.My concern about using
_relaxedversion is that everybody is still saying useCOMPILE_TESTor just enable drivers for all archs. With using_relaxedIO helper function it is ending up in compilation problems for i386.
Last time with our i2c driver.
http://www.spinics.net/lists/arm-kernel/msg320255.html
Quoted 7 lines
Quoted 3 lines
It means shouldn't be that
_relaxedversion listed inasm-generic/io.hor just limit it to use this driver just for ARM like we have done for this edac driver.As I said, it's a requirement for L2C code, because otherwise you end up with every IO access to the L2C also invoking a second IO access to the device.
I understand your point and as I write above we will use relaxed version for reason you have written.
I just wanted to know your opinion regarding adding relaxed version to asm-generic/io.h that's it.
Quoted 8 lines
Quoted 8 lines
Quoted 7 lines
- a driver coupled to the arm,pl310-cache compatible for this which is distinctly separate from the main "driver" is probably a bad idea. what if we want our existing l2 stuff to couple into the driver model to expose some properties at a later date (eg, maybe to deal with stuff like the power management settings?) For example, it may be that we want to expose the prefetch offset so that people can easily play with the value to determine the correct tuning for their workload.
Quoted 6 lines
Quoted 2 lines
We choose that name for starting to discuss this how to do it better. We could use zynq-edac-l2 or zynq-edac-r3p2, etc version.
I'm not talking about the compatible name. I'm certainly not suggesting that you should describe the L2 as two separate devices in DT. I'm saying that this should appear as one _single_ driver for the entire device.
great.
Quoted 7 lines
Quoted 2 lines
Our kernel for historical reasons runs in secure mode that's why I don't know if this will work for us but easy to try.
Sorry, this kind of short sightedness is unacceptable. This is the "I'm only going to solve the problem immediately in front of my nose" syndrome which is currently causing me to end up rewriting lots of code in the kernel right now.
Not like that. I am just saying to give you full picture what I am able to easily test. It means kernel running in secure mode I can just download, rebuild and retest and give you results.
Because this is shared driver across platform I am just saying that for testing this in non secure mode will be better to do it on different platform because on zynq this could be problematic.
We have 3rd party secure monitor around but l2 was problematic there that's why choosing different platform is better choice.
Quoted 3 lines
What you're doing is similar to this:
https://twitter.com/denny/status/452867158964326400/photo/1
Nice picture. :-)
Quoted 2 lines
You're solving the problem you have without thinking about the consequences for others.
I don't think so. I wanted to clearly said our configuration for you to know what I can easily test it.
Quoted 4 lines
Of course other people are going to want to use this, and as the L2C controllers are generic, so any code which adds support for EDAC support should also be generic and not written with a single platform in mind.
Sure I agree with you. That was also the reason why generic string is used there and we are not pretending that this is something zynq specific.
Thanks,
Michal
Signature · 14 lines
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Microblaze cpu - http://www.monstr.eu/fdt/ Maintainer of Linux kernel - Xilinx Zynq ARM architecture Microblaze U-BOOT custodian and responsible for u-boot arm zynq platform -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 263 bytes Desc: OpenPGP digital signature URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140407/5ed9e725/attachment.sig>