> On Fri, 2015-03-20 at 11:55 +0700, Arseny Solokha wrote:
>>
>> And by the way, while revisiting the series I've noticed that though the
>> patch
>> 4/4 basically reverts [1], it leaves
>>
>> #define MPIC_GREG_GLOBAL_CONF_10x00030
>>
>> in arch/powerpc/include/asm/mpic.h untouche
Drop unused static procedure which doesn't have callers within its
translation unit. It had been already removed independently in QEMU[1]
from the OpenPIC implementation borrowed by the kernel.
[1] https://lists.gnu.org/archive/html/qemu-devel/2014-06/msg01812.html
v4: Fixed the comment regarding
Describe the HFPLLs present on MSM8960 and APQ8064 devices.
Signed-off-by: Stephen Boyd
---
drivers/clk/qcom/gcc-msm8960.c | 172 +++
include/dt-bindings/clock/qcom,gcc-msm8960.h | 2 +
2 files changed, 174 insertions(+)
diff --git a/drivers/clk/qcom/gcc-
Krait CPUs have a handful of L2 cache controller registers that
live behind a cp15 based indirection register. First you program
the indirection register (l2cpselr) to point the L2 'window'
register (l2cpdr) at what you want to read/write. Then you
read/write the 'window' register to do what you w
The Krait CPU clocks are made up of a primary mux and secondary
mux for each CPU and the L2, controlled via cp15 accessors. For
Kraits within KPSSv1 each secondary mux accepts a different aux
source, but on KPSSv2 each secondary mux accepts the same aux
source.
Cc:
Signed-off-by: Stephen Boyd
--
We want to reuse the logic in clk-mux.c for other clock drivers
that don't use readl as register accessors. Fortunately, there
really isn't much to the mux code besides the table indirection
and quirk flags if you assume any bit shifting and masking has
been done already. Pull that logic out into r
Add the necessary DT nodes and data so we can probe the cpufreq
driver on MSM devices with Krait CPUs.
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/qcom-apq8064.dtsi | 230 ++
arch/arm/boot/dts/qcom-msm8960.dtsi | 49 ++
arch/arm/boot/dts/qcom-msm8974.dtsi | 311
Sometimes clocks can't accept their parent source turning off
while the source is reprogrammed to a different rate. Most
notably CPU clocks require a way to switch away from the current
PLL they're running on, reprogram that PLL to a new rate, and
then switch back to the PLL with the new rate once
HFPLLs are the main frequency source for Krait CPU clocks. Add
support for changing the rate of these PLLs.
Signed-off-by: Stephen Boyd
---
I'd really like to get rid of __clk_hfpll_init_once() if possible...
drivers/clk/qcom/Makefile| 1 +
drivers/clk/qcom/clk-hfpll.c | 253
On some devices (MSM8974 for example), the HFPLLs are
instantiated within the Krait processor subsystem as separate
register regions. Add a driver for these PLLs so that we can
provide HFPLL clocks for use by the system.
Cc:
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/clock/qcom,hfp
If a clock is on and we call clk_set_rate() on it we may get into
a situation where the clock temporarily increases in rate
dramatically while we walk the tree and call .set_rate() ops. For
example, consider a case where a PLL feeds into a divider.
Initially the divider is set to divide by 1 and th
The Krait clocks are made up of a series of muxes and a divider
that choose between a fixed rate clock and dedicated HFPLLs for
each CPU. Instead of using mmio accesses to remux parents, the
Krait implementation exposes the remux control via cp15
registers. Support these clocks.
Signed-off-by: Ste
Register a cpufreq-generic device whenever we detect that a
"qcom,krait" compatible CPU is present in DT.
Cc:
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/arm/msm/qcom,pvs.txt | 38
drivers/cpufreq/Kconfig.arm| 9 +
drivers/cpufreq/Makefile
The ACC and GCC regions present in KPSSv1 contain registers to
control clocks and power to each Krait CPU and L2. For CPUfreq
purposes probe these devices and expose a mux clock that chooses
between PXO and PLL8.
Cc:
Signed-off-by: Stephen Boyd
---
.../devicetree/bindings/arm/msm/qcom,kpss-acc.
Describe the HFPLLs present on IPQ806X devices.
Signed-off-by: Stephen Boyd
---
drivers/clk/qcom/gcc-ipq806x.c | 83 ++
1 file changed, 83 insertions(+)
diff --git a/drivers/clk/qcom/gcc-ipq806x.c b/drivers/clk/qcom/gcc-ipq806x.c
index cbdc31dea7f4..5a03e
These patches provide cpufreq scaling on devices with Krait CPUs.
In Krait CPU designs there's one PLL and two muxes per CPU, allowing
us to switch CPU frequencies independently.
secondary
+-++
| QSB |---+|\
On Fri, Mar 20, 2015 at 09:35:26PM -0500, Aravind Gopalakrishnan wrote:
> Other function pointers in the mce code like unexpected_machine_check
> and default_threshold_interrupt are assigned to the respective
> function pointers when they are defined.
The "WTF?!" would still fire and we don't want
From: Xudong Chen
Add devicetree bindings for Mediatek Soc I2C driver.
Signed-off-by: Xudong Chen
Signed-off-by: Eddie Huang
---
.../devicetree/bindings/i2c/i2c-mt6577.txt | 41 ++
1 file changed, 41 insertions(+)
create mode 100644 Documentation/devicetree/bindin
From: Xudong Chen
The mediatek SoCs have I2C controller that handle I2C transfer.
This patch include common I2C bus driver.
This driver is compatible with I2C controller on mt65xx/mt81xx.
Signed-off-by: Xudong Chen
Signed-off-by: Liguo Zhang
Signed-off-by: Eddie Huang
---
drivers/i2c/busses/
Add mediatek MT8173 I2C controller driver. Compare to I2C controller
of earlier mediatek SoC, MT8173 fix write-then-read limitation, and
also increase message size to 64kb.
Signed-off-by: Xudong Chen
Signed-off-by: Liguo Zhang
Signed-off-by: Eddie Huang
---
drivers/i2c/busses/i2c-mt65xx.c | 10
This series is for Mediatek SoCs I2C controller common bus driver.
Earlier MTK SoC ((for example, MT6589, MT8135)) I2C HW has some limitationes.
New generation SoC like MT8173 fix these limitations.
1. Only support one i2c_msg number. One exception is WRRD (write then read)
mode. WRRD can have tw
On 2015/3/21 1:24, Luck, Tony wrote:
>> RAS user space tools like rasdaemon which base on trace event, could
>> receive mce error event, but no memory recovery result event. So, I
>> want to add this event to make this scenario complete.
>
> Excellent answer. Are you going to write that patch for
Hi Eddie,
On Tue, Mar 17, 2015 at 10:45 PM, Eddie Huang wrote:
> +static int mtk_rtc_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + struct mt6397_chip *mt6397_chip = dev_get_drvdata(pdev->dev.parent);
> + struct mt6397_rtc *rtc;
> + int ret = 0;
>
Hi Gigi,
> Add minimal device tree support to the btwilink driver that is used
> for binding bluetooth with the ti-st shared transport driver.
>
> Signed-off-by: Eyal Reizer
> Signed-off-by: bvijay
> Signed-off-by: Gigi Joseph
> ---
> Changes in v2:
> * Reformat device_id table to match
Dear Sir/Madam,
Please can you kindly provide us the FOB price of your products and delivery
time, i will kindly request your lowest competitive price and want a good
dealing partner, our company will buy more once first business is successful.
I will kindly advise you send your full quotation
Add minimal device tree support to the btwilink driver that is used
for binding bluetooth with the ti-st shared transport driver.
Signed-off-by: Eyal Reizer
Signed-off-by: bvijay
Signed-off-by: Gigi Joseph
---
Changes in v2:
* Reformat device_id table to match other drivers
* Ad
Hello Dear,
Hello my dear i know you will be very surprised to received this message
from me,how are you doing today,i hope you are fine.Anyway let me introduce
myself to you I am Engineer Scott Niall, am 47yrs old single,from Iceland
but i currently based in United kingdom (ENGLAND)I got your
Hi Gerd,
On Fri, Mar 20, 2015 at 01:39:29PM +0100, Gerd Hoffmann wrote:
> virtio-input is basically evdev-events-over-virtio, so this driver isn't
> much more than reading configuration from config space and forwarding
> incoming events to the linux input layer.
>
> Signed-off-by: Gerd Hoffmann
Hi Al,
Ping and sorry to bother you.
Could you please have a look at my question? Thank you!
Regards,
Boqun Feng
On Wed, Mar 18, 2015 at 01:27:24PM +0800, Boqun Feng wrote:
> On Fri, Mar 13, 2015 at 09:45:59AM -0400, Paul Moore wrote:
> > On Monday, March 09, 2015 04:24:32 PM Boqun Feng wrote:
>
From: Byoungyoung Lee
When filp->private_data is NULL, put_nfs_open_dir_context()
deferences its pointer (fi->list, fi->cred), similar to what
other file systems handle '.release' api (9p, cifs, btrfs,
ext4, ocfs2).
Signed-off-by: Byoungyoung Lee
Signed-off-by: Taesoo Kim
---
fs/nfs/dir.c |
Hi Linus,
Here are current target-pending fixes for v4.0-rc5 code that have made
their way into the queue over the last weeks.
Please go ahead and pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git master
The fixes this round include:
- Fix long-standing iser-t
On Fri, 20 Mar 2015 16:30:01 -0700
Alexei Starovoitov wrote:
> Hi Ingo,
>
> I think it's good to go.
> Patch 1 is already in net-next. Patch 3 depends on it.
> I'm assuming it's not going to be a problem during merge window.
> Patch 3 will have a minor conflict in uapi/linux/bpf.h in linux-next,
+CC Parth Dixit, Stefano Stabellini.
On 2015年03月21日 02:54, Will Deacon wrote:
On Thu, Mar 19, 2015 at 04:09:33AM +, Hanjun Guo wrote:
On 2015/3/19 3:05, Will Deacon wrote:
If you can get that in place, I'm not opposed to putting this into
linux-next ahead of the firmware summit in San Jose
On 3/20/15 5:31 PM, Luck, Tony wrote:
+ default:
+ WARN_ONCE(1, "WTF!?");
+ break;
You meant to type:
mce_severity = mce_severity_default;
just there, right?
Other function pointers in the mce code like unexpected_machine_check
and default_t
From: Murali Karicheri
Date: Fri, 20 Mar 2015 16:11:20 -0400
> NetCP 1.5 is used in newer K2 SoCs from Texas Instruments
> such as K2E, K2L etc. This patch series add support for Ethss
> driver for this version of NetCP. While at it, fix couple of
> bugs in the original driver.
>
> One of the ea
With CONFIG_DEBUG_INFO_REDUCED, we do get quite a lot of debug info
(around 22.7 MB for a defconfig+DEBUG_INFO_REDUCED). However, the
"basenames must match" rule used by -femit-struct-debug-baseonly
option means that we miss some core data structures, such as struct
{device, file, inode, mm_struct,
From: Mathieu Olivari
Date: Fri, 20 Mar 2015 18:31:03 -0700
> Change bd76a116707bd2381da36cf7c3183df11293f1d6 made all DSA drivers
> depend on NET_DSA rather than selecting them. However, as the only way
> to select this option was to actually select a driver, it made DSA
> impossible to enable a
On 03/20/2015 06:31 PM, Mathieu Olivari wrote:
Change bd76a116707bd2381da36cf7c3183df11293f1d6 made all DSA drivers
depend on NET_DSA rather than selecting them. However, as the only way
to select this option was to actually select a driver, it made DSA
impossible to enable at all.
This patch ad
Change bd76a116707bd2381da36cf7c3183df11293f1d6 made all DSA drivers
depend on NET_DSA rather than selecting them. However, as the only way
to select this option was to actually select a driver, it made DSA
impossible to enable at all.
This patch adds an explicit entry which the user will have to
On Fri, Mar 20, 2015 at 01:08:25PM +0200, Roger Quadros wrote:
> On 20/03/15 11:46, Roger Quadros wrote:
> > On 20/03/15 09:18, Peter Chen wrote:
> >> On Thu, Mar 19, 2015 at 04:50:31PM +0200, Roger Quadros wrote:
> >>> On 19/03/15 16:09, Li Jun wrote:
> On Thu, Mar 19, 2015 at 12:14:39PM +020
On Friday 20 March 2015, Richard Cochran wrote:
> Instead of changing to ktime_t, just use timespec64 instead. That
> way, each change will be a couple of lines per file.
This was the first idea, but it seems a bit silly when all the drivers
use a 64-bit nanosecond value just like ktime_t. While
On 21.03.2015 02:01, Lino Sanfilippo wrote:
>> Should that be (marks_mask & FS_ISDIR & marks_ignored_mask)?
>>
>
> No, the current logic should be correct, since we want events for
> directories if we have FS_ISDIR set in the marks mask but not in its
> ignored_mask.
>
Actually this should be:
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> When a system has PAT support enabled you don't need to be
> using MTRRs. Andy had added arch_phys_wc_add() long ago to
> help with this but not all drivers were converted over. We
> have to take care to onl
On Fri, Mar 20, 2015 at 07:53:06AM +0800, Axel Lin wrote:
> The mutex lock is not used at all, remove it.
> The *vmmc_regulator is not necessary, use a local variable in
> stw481x_vmmc_regulator_probe() instead.
>
Applied, thanks.
signature.asc
Description: Digital signature
This patchset attempts to standardize the naming of dt-bindings
documents based on the Broadcom vendor prefix of brcm.
Although there are no guidelines currently present for how to name
the dt-bindings document the "vendor,binding.txt" style is in use by
some of the other vendors.
Acked-by: Lee J
From: "Luis R. Rodriguez"
The crusade to replace mtrr_add() with architecture agnostic
arch_phys_wc_add() is complete, this will ensure write-combining
implementations (PAT on x86) is taken advantage instead of using
MTRR. With the crusade done now, hide direct MTRR access for
drivers.
Cc: Sures
From: "Luis R. Rodriguez"
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage o
On 20.03.2015 22:09, Andrew Morton wrote:
> On Fri, 20 Mar 2015 21:56:08 +0100 Fabian Frederick wrote:
>
>> ltp/fanotify02 was locked since commit 66ba93c0d7fe
>> ("fanotify: don't set FAN_ONDIR implicitly on a marks ignored mask")
>
> What does "ltp/fanotify02 was locked" mean? That this parti
From: "Luis R. Rodriguez"
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage o
Hi,
On 20.03.2015 21:56, Fabian Frederick wrote:
> ltp/fanotify02 was locked since commit 66ba93c0d7fe
> ("fanotify: don't set FAN_ONDIR implicitly on a marks ignored mask")
>
> Signed-off-by: Fabian Frederick
> ---
> fs/notify/fanotify/fanotify.c | 4 ++--
> 1 file changed, 2 insertions(+), 2
From: "Luis R. Rodriguez"
The driver doesn't use mtrr_add() or arch_phys_wc_add() but
since we know the framebuffer is isolated already on an
ioremap() we can take advantage of write combining for
performance where possible.
In this case there are a few motivations for this:
a) Take advantage o
Documents the touchscreen device tree binding for Broadcom iProc family
of SoCs.
Reviewed-by: Scott Branden
Tested-by: Scott Branden
Signed-off-by: Jonathan Richardson
---
.../input/touchscreen/brcm,iproc-touchscreen.txt | 76
1 file changed, 76 insertions(+)
create m
Add initial version of the Broadcom touchscreen driver.
Reviewed-by: Ray Jui
Reviewed-by: Scott Branden
Tested-by: Scott Branden
Signed-off-by: Jonathan Richardson
---
drivers/input/touchscreen/Kconfig | 11 +
drivers/input/touchscreen/Makefile|1 +
drivers/input/touchsc
This patchset contains initial support for the touchscreen on the Broadcom
iProc family of SoCs. This driver has been validated with Cygnus and is expected
to work on other iProc family of SoCs that use the same touchscreen controller.
Changes from v4:
- Debug code cleanup.
- pdev wasn't initializ
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
On Fri, Mar 20, 2015 at 5:18 PM, David Ahern wrote:
> On 3/20/15 4:49 PM, David Ahern wrote:
>>
>> I did ask around and apparently this bug is hit only with the new M7
>> processors. DaveM: that's why you are not hitting this.
Quite frankly, this smells even more like an architecture bug. It
coul
On Tue, 2015-01-20 at 10:57 +0100, Christophe Leroy wrote:
> By default, TASK_SIZE is set to 0x8000 for PPC_8xx, which is most likely
> sufficient for most cases. However, kernel configuration allows to set
> TASK_SIZE
> to another value, so the 8xx shall handle it.
>
> Signed-off-by: Christo
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
The same area used for MTRR is used for the ioremap() area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that al
On 3/20/15 6:34 PM, David Rientjes wrote:
On Fri, 20 Mar 2015, David Ahern wrote:
Here's another data point: If I disable NUMA I don't see the problem.
Performance drops, but no NULL pointer splats which would have been panics.
The 128 cpu ldom with NUMA enabled shows the problem every single
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
On Fri, 20 Mar 2015, David Ahern wrote:
> Here's another data point: If I disable NUMA I don't see the problem.
> Performance drops, but no NULL pointer splats which would have been panics.
>
> The 128 cpu ldom with NUMA enabled shows the problem every single time I do a
> kernel compile (-j 128)
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
Hi Linus,
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm+acpi-4.0-rc5
to receive power management and ACPI fixes for v4.0-rc5 with top-most
commit 9c86286a60b28bd25cb1c70eb2aba34f182d1063
Merge branches 'pm-cpuidle', 'powercap', 'irq-pm' and 'acpi-res
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR and ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also en
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap().
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
This driver uses the same ioremap()'d area for the MTRR.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also
From: "Luis R. Rodriguez"
Although this driver gives the framebuffer layer a different
size for the framebuffer it uses the entire aperture PCI BAR
size for the MTRR. Since the framebuffer is included in that
range and MTRR was used on the entire PCI BAR WC will have
been preferred on that range
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
On 3/20/15 4:49 PM, David Ahern wrote:
On 3/20/15 3:17 PM, Linus Torvalds wrote:
In other words, if I read that sparc asm right (and it is very likely
that I do *not*), then "objp" is NULL, and that's why you crash.
That does appear to be why. I put a WARN_ON before
clear_obj_pfmemalloc() if o
From: "Luis R. Rodriguez"
This driver never removed the MTRRs. Fix that.
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: Dave Airlie
Cc: Antonino Daplas
Cc: Jean-Christophe Plagniol-Villard
Cc: To
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that also ensure the ioremap'd area is requested
as write-combining
From: "Luis R. Rodriguez"
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that al
From: "Luis R. Rodriguez"
The same area used for ioremap() is used for the MTRR area.
Convert the driver from using the x86 specific MTRR code to
the architecture agnostic arch_phys_wc_add(). arch_phys_wc_add()
will avoid MTRR if write-combining is available, in order to
take advantage of that al
From: "Luis R. Rodriguez"
This driver already uses ioremap_wc() on the same range
so when write-combining is available that will be used
instead.
Cc: Andy Lutomirski
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Hyong
From: "Luis R. Rodriguez"
There is only one user but since we're going to bury
MTRR next out of access to drivers expose this last
piece of API to drivers in a general fashion only
needing io.h for access to helpers.
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Linus Torvalds
From: "Luis R. Rodriguez"
This driver uses the same area for MTRR as for the ioremap_wc(), if
anything it just uses a smaller size in case MTRR reservation fails.
ioremap_wc() API is already used to take advantage of architecture
write-combining when available.
Convert the driver from using the
On Fri, Dec 05, 2014 at 12:20:25PM +0100, LEROY Christophe wrote:
> When size is equal to 1, the test is always true so lets eliminate both 0 and
> 1
> at first.
>
> include/asm-generic/termios-base.h: In function
> 'user_termio_to_kernel_termios':
> include/asm-generic/termios-base.h:35:2: warn
From: "Luis R. Rodriguez"
The MTRR added was never being deleted.
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: Dave Airlie
Cc: Antonino Daplas
Cc: Jean-Christophe Plagniol-Villard
Cc: Tomi Valk
From: "Luis R. Rodriguez"
No other video driver uses MTRR types except for MTRR_TYPE_WRCOMB,
the other MTRR types were implemented and supported here but with
no real good reason. The ioremap() APIs are architecture agnostic and
at least on x86 PAT is a new design that extends MTRRs and
can repla
From: "Luis R. Rodriguez"
If and when this gets enabled the driver should address
using ioremap_wc() on the same area, that could require
a bit of work as it would mean a split with two ioremap'd
areas. Annotate this.
Cc: Andy Lutomirski
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Moln
From: "Luis R. Rodriguez"
Sadly this driver requires a bit of work in order
to use ioremap_wc() on the range currently used
for MTRR write-combining. We'd need to ensure two
ioremap() calls are done. Annotate this.
Cc: Andy Lutomirski
Cc: Andy Walls
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> The atyfb driver uses an MTRR work around since some
> cards use the same PCI BAR for the framebuffer and MMIO.
> In such cards the last page is used for MMIO, the rest for
> the framebuffer, so on those car
On Fri, Dec 05, 2014 at 12:20:20PM +0100, LEROY Christophe wrote:
> include/linux/mm.h: In function 'is_vmalloc_addr':
> include/linux/mm.h:367:14: warning: comparison between signed and unsigned
> integer expressions [-Wsign-compare]
> return addr >= VMALLOC_START && addr < VMALLOC_END;
>
From: "Luis R. Rodriguez"
This driver sadly does not have the MMIO registers and WC
desired areas (PIO buffers in this case) properly split up
and addressing a split is considerable work, as such this
such requires using the __arch_phys_wc_add() call to
ensure write combining is enforced using MT
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> This lets drivers take advanate of PAT when available. This
> should help with the transition of converting video drivers over
> to ioremap_wc() to help with the goal of eventually using
> _PAGE_CACHE_UC ove
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> We have devm_ioremap_nocache() but no devm_ioremap_wc()
> so add that. This will be used later.
>
> Cc: Suresh Siddha
> Cc: Venkatesh Pallipadi
> Cc: Ingo Molnar
> Cc: Thomas Gleixner
> Cc: Juergen Gross
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: Dave Airlie
Cc: Antonino Daplas
Cc: Jean-Christophe Plagni
On Fri, Mar 20, 2015 at 4:17 PM, Luis R. Rodriguez
wrote:
> From: "Luis R. Rodriguez"
>
> Ideally on systems using PAT we can expect a swift
> transition away from MTRR. There can be a few exceptions
> to this, one is where device drivers are known to exist
> on PATs with errata, another situatio
From: "Luis R. Rodriguez"
This driver already makes use of ioremap_wc() on PIO buffers,
so convert it to use arch_phys_wc_add().
Cc: Rickard Strandqvist
Cc: Dennis Dalessandro
Cc: Mike Marciniszyn
Cc: Roland Dreier
Cc: Andy Lutomirski
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Mol
From: "Luis R. Rodriguez"
There is no good reason not to, we eventually delete it as well.
Cc: Suresh Siddha
Cc: Venkatesh Pallipadi
Cc: Ingo Molnar
Cc: Thomas Gleixner
Cc: Juergen Gross
Cc: Daniel Vetter
Cc: Andy Lutomirski
Cc: Dave Airlie
Cc: Antonino Daplas
Cc: Jean-Christophe Plagni
Hello Grygorii,
On Fri, Mar 20, 2015 at 9:39 PM, grygorii.stras...@linaro.org
wrote:
> On 03/20/2015 08:56 PM, Javier Martinez Canillas wrote:
>> Hello Grygorii,
>>
>> On Thu, Mar 19, 2015 at 6:25 PM, wrote:
>>> From: Grygorii Strashko
>>>
>>> Now OMAP GPIO driver prepared for omap_irq_to_gpio
1 - 100 of 737 matches
Mail list logo
