Hello,
> -Original Message-
> From: Felipe Balbi [mailto:ba...@ti.com]
> Sent: Thursday, November 13, 2014 3:44 AM
> To: Felipe Balbi
> Cc: Robert Baldyga; David Cohen; gre...@linuxfoundation.org; linux-
> u...@vger.kernel.org; linux-kernel@vger.kernel.org;
> min...@mina86.com; andrze...@s
32-bit ARM kernels may have a 64-bit dma_addr_t but have no
implementation of the compiler helper for 64-bit unsigned division,
therefore the use of the modulo operator in pl330_prep_dma_memcpy causes
the link error "undefined reference to `__aeabi_uldivmod'"
As the burst value is always a power o
Hi,
Am 13.11.2014 um 12:51 schrieb Tomi Valkeinen :
> On 13/11/14 00:10, Marek Belisko wrote:
>> opa362 is amplifier for video and can be connected to the tvout pads
>> of the OMAP3. It has one gpio control for enable/disable of the output
>> (high impedance).
>>
>> Signed-off-by: H. Nikolaus Sc
On Fri 2014-11-07 09:04:52, Ivaylo Dimitrov wrote:
> On 7.11.2014 01:01, Pali Rohár wrote:
> >
> >For voice calls you need:
> >* kernel driver cmt-speech (or it has some new name)
> >* cmt-speech userspace library (communication with kernel)
> >* pulseaudio modules which are using that library
> >
On Thu, Nov 13, 2014 at 10:12:28AM +, Lee Jones wrote:
> On Tue, 11 Nov 2014, Richard Fitzgerald wrote:
>
> > Signed-off-by: Richard Fitzgerald
> > ---
> > drivers/mfd/Kconfig |6 +
> > drivers/mfd/Makefile |3 +
> > drivers/mfd/arizona-core.c | 91 ++
Dear Attorney,
This is to inquire if your law firm handles Purchase and Sale Agreements in
your area in the United States.
Regards,
Anthony Miyamoto
President & CEO
MIYAMOTO Industrial Co. Ltd.
6-4-10
NANKO-NAKA, SUMINOE-KU,
OSAKA, JAPAN 559-0033
--
To unsubscribe from this list: send the line "
Hi!
> > I actually had pm=0 on the command line, but I removed it now, and no
> > change: [...]
> >
> > Let me try with explicit =1. .. aha, that helps. Thanks!
>
> mh seems I actually missed to make 1 the default value. I will
> prepare a patch for that.
>
> I assume, that the example ofono co
Building with the attached random configuration file,
drivers/built-in.o: In function `set_type':
/home/jim/linux/drivers/media/v4l2-core/tuner-core.c:412: undefined
reference to `simple_tuner_attach'
/home/jim/linux/drivers/media/v4l2-core/tuner-core.c:376: undefined
reference to `xc5000_attach'
On Tue, Nov 11, 2014 at 02:20:57PM +0200, Octavian Purdila wrote:
> This fixes the following kbuild test robot warning:
>
> >> drivers/i2c/busses/i2c-dln2.c:70:1-4: WARNING: end returns can be
> >> simplified if negative or 0 value
>
> Reported-by: kbuild test robot
> Reported-by: Julia Lawall
2014-11-12 17:07 GMT+01:00 Howard Chen :
> This patch add s devicetree document for Mediatek UART.
>
> Signed-off-by: Howard Chen
> ---
> Documentation/devicetree/bindings/serial/mtk-uart.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindi
2014-11-12 17:07 GMT+01:00 Howard Chen :
> * A dtsi for boards based on Mediatek MT6592 SoCs
> * Compatible string in arch/arm/mach-mediatek/mediatek.c
>
> Signed-off-by: Howard Chen
> ---
> arch/arm/boot/dts/mt6592.dtsi | 97
> +++
> arch/arm/mach-mediate
On Thu, Nov 13, 2014 at 12:27:07PM +0100, Thierry Reding wrote:
> On Wed, Nov 12, 2014 at 09:07:20AM -0800, Olof Johansson wrote:
> > Hi Thierry,
> >
> >
> >
> > On Wed, Nov 12, 2014 at 4:20 AM, Thierry Reding
> > wrote:
> > > On Tue, Nov 11, 2014 at 12:49:30PM -0800, Olof Johansson wrote:
> >
On 11/10/2014 03:22 PM, Linus Torvalds wrote:
> Rik, the fact that you acked this just makes all your other ack's be
> suspect. Did you do it just because it was from Red Hat, or do you do
> it because you like seeing Acked-by's with your name?
I acked it because I could not come up with a better
2014-11-12 17:07 GMT+01:00 Howard Chen :
> The mt6592-evb is an evaluation board based on the MT6592 SoC.
>
> Signed-off-by: Howard Chen
> ---
> arch/arm/boot/dts/Makefile | 3 ++-
> arch/arm/boot/dts/mt6592-evb.dts | 25 +
> 2 files changed, 27 insertions(+), 1 del
On 11/13/2014 04:31 PM, Andre Przywara wrote:
>
>
> On 13/11/14 15:02, Nikolay Nikolaev wrote:
>> On Thu, Nov 13, 2014 at 4:23 PM, Eric Auger wrote:
>>> On 11/13/2014 03:16 PM, Eric Auger wrote:
On 11/13/2014 11:45 AM, Nikolay Nikolaev wrote:
> On Mon, Nov 10, 2014 at 6:27 PM, Christoff
(2014/11/13 6:47), Vojtech Pavlik wrote:
> On Thu, Nov 13, 2014 at 02:33:24AM +0900, Masami Hiramatsu wrote:
>> Right. Consistency model is still same as kpatch. Btw, I think
>> we can just use the difference of consistency for classifying
>> the patches, since we have these classes, only limited c
On Wed, Nov 12, 2014 at 10:08 PM, Andrew Morton
wrote:
> On Fri, 7 Nov 2014 17:01:01 + David Drysdale wrote:
>
>> This patch set adds execveat(2) for x86
>
> I grabbed these. If someone else was planning to do so, feel free to
> shout at me.
>
> I haven't been following the discussion close
On Thu, 13 Nov 2014, Borislav Petkov wrote:
> Revisit this patch how? I'm not sure I understand...
X86_64 starts with:
pteval_t __supported_pte_mask __read_mostly = ~0;
while i386 starts with:
pteval_t __supported_pte_mask __read_mostly = ~(_PAGE_NX | _PAGE_GLOBAL);
Now if the stupid BIOS disa
This series is 6th version of interrupt polarity support for MediaTek SoCs.
This is based on tip/irq/irqdomain[1] and my mediatek SoC basic support[2].
In this version, I added a minor fix to irqdomain as first patch. Patch 3,
4 are changed to use newly added helper functions. The other patches a
Add binding documentation for Mediatek SoC SYSIRQ.
Signed-off-by: Yingjoe Chen
---
.../bindings/arm/mediatek/mediatek,sysirq.txt | 26 ++
1 file changed, 26 insertions(+)
create mode 100644
Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt
diff --git
Add sysirq settings for mt6589/mt8135/mt8127
This also correct timer interrupt flag. The old setting works
because boot loader already set polarity for timer interrupt.
Without intpol support, the setting was not changed so gic
can get the irq correctly.
Signed-off-by: Yingjoe Chen
---
arch/arm/
Mediatek SoCs have interrupt polarity support in sysirq which
allows to invert polarity for given interrupt. Add this support
using hierarchy irq domain.
Signed-off-by: Yingjoe Chen
---
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-mtk-sysirq.c | 156 +
Add support to use gic as a parent for stacked irq domain.
Signed-off-by: Yingjoe Chen
---
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-gic.c | 80 ---
2 files changed, 55 insertions(+), 26 deletions(-)
diff --git a/drivers/irqchip/Kconfig b/
When using irq_domain_free_irqs_top() directly in irq_domain_ops, gcc
generate the following warnings:
../drivers/irqchip/irq-gic.c:879:2: warning: initialization from incompatible
pointer type [enabled by default]
../drivers/irqchip/irq-gic.c:879:2: warning: (near initialization for
'gic_irq_do
Add more helper function for stacked irq_chip to just call parent's
function.
Signed-off-by: Yingjoe Chen
---
include/linux/irq.h | 6 ++
kernel/irq/chip.c | 28
2 files changed, 34 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index d8
On Thu, Nov 13, 2014 at 12:13:32PM +0100, Martin Kepplinger wrote:
> Am 13. November 2014 11:53:29 MEZ, schrieb Miklos Szeredi :
> >On Thu, Nov 13, 2014 at 11:05 AM, Martin Kepplinger
> >wrote:
> >
> >> In this week's -next this should have changed. My SSD broke down so i
> >have to delay further
On Wed, Nov 12, 2014 at 02:15:02PM +0100, Maxime Ripard wrote:
> Hi,
>
> On Wed, Nov 12, 2014 at 04:55:29PM +0530, Vinod Koul wrote:
> > On Thu, Nov 06, 2014 at 03:33:49PM +0100, Maxime Ripard wrote:
> > > Hi Vinod,
> > >
> > > On Tue, Oct 28, 2014 at 10:25:15PM +0100, Maxime Ripard wrote:
> > >
[CC'ing Arnd and RobH]
On Tue, Nov 11, 2014 at 03:33:44PM +, Suravee Suthikulpanit wrote:
> On 11/11/14 18:24, Will Deacon wrote:
> >> @@ -313,6 +324,9 @@ static int gen_pci_probe(struct platform_device *pdev)
> >> > return err;
> >> > }
> >> >
> >> >+ pci->mchip = of
On 13/11/14 15:02, Nikolay Nikolaev wrote:
> On Thu, Nov 13, 2014 at 4:23 PM, Eric Auger wrote:
>> On 11/13/2014 03:16 PM, Eric Auger wrote:
>>> On 11/13/2014 11:45 AM, Nikolay Nikolaev wrote:
On Mon, Nov 10, 2014 at 6:27 PM, Christoffer Dall
wrote:
> On Mon, Nov 10, 2014 at 05:09
On 13/11/14 15:04, Chen Gang wrote:
> When kvm_register_device_ops() fails, also need call free_percpu_irq()
> just like others have down within kvm_vgic_hyp_init().
>
> Signed-off-by: Chen Gang
> ---
> virt/kvm/arm/vgic.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> d
On (11/14/14 00:22), Sergey Senozhatsky wrote:
> > Now zsmalloc can be registered as a zpool driver into zpool when
> > CONFIG_ZPOOL is enabled. During the init of zsmalloc, when error happens,
> > we need to do cleanup. But in current code, it will unregister a not yet
> > registered zsmalloc zpoo
On 11/13/2014 06:55 AM, Thomas Gleixner wrote:
> On Wed, 12 Nov 2014, Dave Hansen wrote:
>> +/*
>> + * Get the base of bounds tables pointed by specific bounds
>> + * directory entry.
>> + */
>> +static int get_bt_addr(struct mm_struct *mm,
>> +long __user *bd_entry, unsigned lo
On 11/12/14, 9:02 PM, gsant...@codeaurora.org wrote:
Hi All,
The Question is for the compressed offload session.
For a generic codec driver during the startup function it will set some of
the hw_constraints rule similarly like this.
snd_pcm_hw_constraint_list(substream->runtime, 0,
On Thu 2014-11-13 16:12:25, Geert Uytterhoeven wrote:
> Hi Pavel,
>
> On Thu, Nov 13, 2014 at 3:09 PM, Pavel Machek wrote:
> > Acked-by: Pavel Machek
>
> You've got a new email address? ;-)
Yes, I decided to typo-squat myself :-). Just kidding.
Acked-by: Pavel Machek
--
(english) http://www
On 11/11/2014 06:16 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.10.60 release.
> There are 123 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
Hi Johan,
On Thu, Nov 13, 2014 at 01:27:28PM +0100, Johan Havold wrote:
> On Wed, Nov 12, 2014 at 03:38:09PM +0200, Laurentiu Palcu wrote:
> > This adds support for Diolan DLN2 USB-SPI adapter.
> >
> > Information about the USB protocol interface can be found in the
> > Programmer's Reference Man
On 11/11/2014 06:14 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.14.24 release.
> There are 203 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses
On 11/11/2014 06:12 PM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.17.3 release.
> There are 319 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses s
At Thu, 13 Nov 2014 20:44:17 +0530,
Sudip Mukherjee wrote:
>
> these variable were initialized with some value, but never used.
> and so they are safe to be deleted.
>
> Signed-off-by: Sudip Mukherjee
> ---
>
> i have not given Jaroslav Kysela in the To list,
> as in my last mail, all mails bo
On Tue, Nov 11, 2014 at 11:52:27AM +, Liviu Dudau wrote:
> On Tue, Nov 11, 2014 at 11:24:24AM +, Will Deacon wrote:
> > Hi Suravee,
> >
> > On Mon, Nov 10, 2014 at 07:24:40PM +, suravee.suthikulpa...@amd.com
> > wrote:
> > > From: Suravee Suthikulpanit
> > >
> > > This patch impleme
On (11/13/14 21:37), Mahendran Ganesh wrote:
> Now zsmalloc can be registered as a zpool driver into zpool when
> CONFIG_ZPOOL is enabled. During the init of zsmalloc, when error happens,
> we need to do cleanup. But in current code, it will unregister a not yet
> registered zsmalloc zpool driver(*
At Thu, 13 Nov 2014 20:44:16 +0530,
Sudip Mukherjee wrote:
>
> the functions:
> snd_ice1712_akm4xxx_build_controls
> snd_ice1712_build_pro_mixer
> snd_ctl_add
> snd_ak4114_build
> prodigy192_ak4114_init
> snd_ak4113_build
> are all returning either 0 or a negeti
On Thu, Nov 13, 2014 at 03:14:08PM +, Kyle McMartin wrote:
> On Thu, Nov 13, 2014 at 03:06:25PM +, Catalin Marinas wrote:
> > On Wed, Nov 12, 2014 at 09:07:44PM +, Kyle McMartin wrote:
> > > ARM64 currently doesn't fix up faults on the single-byte (strb) case of
> > > __clear_user... wh
>From f25ff0f2645f9763552147d480f86973b7041e26 Mon Sep 17 00:00:00 2001
From: Vincent BENAYOUN
Date: Thu, 13 Nov 2014 13:47:26 +0100
Subject: [PATCH] inetdevice: fixed signed integer overflow
There could be a signed overflow in the following code.
The expression, (32-logmask) is comprised betwee
On 20/10/2014 14:35, Nicolas Ferre :
> On 20/10/2014 14:17, Boris Brezillon :
>> Hi Alessandro,
>>
>> On Tue, 23 Sep 2014 16:48:35 +0200
>> Boris BREZILLON wrote:
>>
>>> Hello,
>>>
>>> This patch series adds DT support to the atmel at91sam9 RTC driver.
>>>
>>> It also removes any machine specific
Hi,
On Friday, November 07, 2014 02:59:51 PM Eduardo Valentin wrote:
> Hi Bartlomiej,
>
> On Mon, Oct 20, 2014 at 02:41:07PM +0200, Bartlomiej Zolnierkiewicz wrote:
> >
> > Hi,
> >
> > Eduardo, could you please merge this patch?
> >
>
> I queued this in my -fixes branch. It should appear als
the functions:
snd_ice1712_akm4xxx_build_controls
snd_ice1712_build_pro_mixer
snd_ctl_add
snd_ak4114_build
prodigy192_ak4114_init
snd_ak4113_build
are all returning either 0 or a negetive error value.
so we can easily remove the check for a negative v
On 11/13/2014 03:56 PM, Lorenzo Pieralisi wrote:
On Wed, Nov 12, 2014 at 03:03:50PM +, Daniel Lezcano wrote:
The only place where the time is invalid is when the ACPI_CSTATE_FFH entry
method is not set. Otherwise for all the drivers, the time can be correctly
measured.
Instead of duplicatin
On Thu, Nov 13, 2014 at 03:06:25PM +, Catalin Marinas wrote:
> On Wed, Nov 12, 2014 at 09:07:44PM +, Kyle McMartin wrote:
> > ARM64 currently doesn't fix up faults on the single-byte (strb) case of
> > __clear_user... which means that we can cause a nasty kernel panic as an
> > ordinary use
Hi Nikolay,
On Thu, Nov 13, 2014 at 4:02 PM, Nikolay Nikolaev
wrote:
[...]
>>
>>
>> We're reconsidering ioeventfds patchseries and we tried to evaluate
>> what you suggested here.
>>
>>>
>>> this special-casing of the vgic is now really terrible. Is there
>>> any
I am not sure to understand your request, it's quite confusing,
you ask me to revert this commit and see if the bug is gone ? :
74665016086615bbaa3fa6f83af410a0a4e029ee scsi: convert host_busy to atomic_t
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=74665016086615bba
reg->triminfo_ctrl[] is used in only exynos_tmu_initialize() and
accessed only if TMU_SUPPORT_TRIM_RELOAD flag is set. This flag
is set only on Exynos3250, Exynos4412 and Exynos5250 (other SoC
types don't even have triminfo_ctrl[] entries assigned in their
struct exynos_tmu_registers instances) so
these variable were initialized with some value, but never used.
and so they are safe to be deleted.
Signed-off-by: Sudip Mukherjee
---
i have not given Jaroslav Kysela in the To list,
as in my last mail, all mails bounced with the error:
"cant create user output file"
sound/pci/ice1712/ice17
When kvm_register_device_ops() fails, also need call free_percpu_irq()
just like others have down within kvm_vgic_hyp_init().
Signed-off-by: Chen Gang
---
virt/kvm/arm/vgic.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/virt/kvm/arm/vgic.c b/virt/kvm/arm/vgic.c
Hi Pavel,
On Thu, Nov 13, 2014 at 3:09 PM, Pavel Machek wrote:
> Acked-by: Pavel Machek
You've got a new email address? ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with tech
Factor out code for initializing data->temp_error[1,2] values
from exynos_tmu_initialize() into sanitize_temp_error().
This is a preparation for introducing per-SoC type tmu_initialize
method.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap
Cc: Lukasz Majewsk
reg->therm_trip_en_shift is used only in exynos_tmu_initialize()
and not accessed on Exynos4210 (also reg->therm_trip_en_shift is
not even assigned in exynos4210_tmu_registers but it is assigned
to identical value for all other SoC types) so the register
abstraction is not needed and can be removed
On Wed, Nov 12, 2014 at 09:07:44PM +, Kyle McMartin wrote:
> ARM64 currently doesn't fix up faults on the single-byte (strb) case of
> __clear_user... which means that we can cause a nasty kernel panic as an
> ordinary user with any multiple PAGE_SIZE+1 read from /dev/zero.
> i.e.: dd if=/dev/z
Replace TMU_SUPPORT_ADDRESS_MULTIPLE flag check in exynos_map_dt_data()
by an explicit check for a SoC type (only Exynos5420 with TRIMINFO
quirk and Exynos5440 have TMU_SUPPORT_ADDRESS_MULTIPLE flag set in
their struct exynos_tmu_init_data instances).
Please note that this requires moving SoC type
Replace TMU_SUPPORT_EMUL_TIME flag check in get_emul_con_reg()
by an explicit check for a SoC type (all SoC types except
Exynos4210 and Exynos5440 have TMU_SUPPORT_EMUL_TIME flag set
in their struct exynos_tmu_init_data instances).
There should be no functional changes caused by this patch.
Cc: A
Remove unused TMU_SUPPORT_MULTI_INST flag, no longer
needed TMU_SUPPORTS() macro and features field from
struct exynos_tmu_platform_data.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap
Cc: Lukasz Majewski
Cc: Eduardo Valentin
Cc: Zhang Rui
Signed-off-by: B
Replace pdata->test_mux check in get_con_reg() by explicitly
checking for SoC type.
Also since the used pdata->test_mux value is always identical
use it directly and remove pdata->test_mux completely.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap
Cc: Lukasz
Maximum theoretical size saving (i.e. with only Exynos5410
SoC support enabled in kernel config so all SoC dependend
Exynos thermal driver code was dropped) is 4096 bytes so
there is no much sense in keeping these ifdefs (especially
given that they are useless once the driver gets updated to
use de
Replace TMU_SUPPORT_FALLING_TRIP flag check in
exynos[4210,5440]_tmu_control() by an explicit check
for a SoC type (all SoC types except Exynos4210 have
TMU_SUPPORT_FALLING_TRIP flag set in their struct
exynos_tmu_init_data instances).
There should be no functional changes caused by this patch.
C
__EXYNOS5420_TMU_DATA macro is now identical to __EXYNOS5260_TMU_DATA
one and can be removed.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap
Cc: Lukasz Majewski
Cc: Eduardo Valentin
Cc: Zhang Rui
Signed-off-by: Bartlomiej Zolnierkiewicz
Acked-by: Kyungmin
There is no longer need to share defines between exynos_tmu.c
and exynos_tmu_data.c (as they are now only used by the former
file) so move them accordingly. Then move externs for struct
exynos_tmu_init_data instances to exynos_tmu.h and remove no
longer needed exynos_tmu_data.h include.
There sho
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: 12 November 2014 23:06
> To: Andrew Bresticker
> Cc: James Hartley; Rob Herring; Pawel Moll; Mark Rutland; Ian Campbell;
> Kumar Gala; Grant Likely; Ezequiel Garcia; devicet...@vger.kernel.org; linux-
> ker...@vger.
Add ->tmu_clear_irqs method to struct exynos_tmu_data and use
it instead exynos_tmu_clear_irqs(). Then add ->tmu_clear_irqs
implementations for Exynos4210+ and Exynos5440. Finally
remove no longer needed reg->tmu_int[stat,clear] abstractions
and struct exynos_tmu_registers instances.
There shoul
Replace TMU_SUPPORT_EMULATION flag check in exynos_tmu_set_emulation()
by an explicit check for a SoC type (all SoC types except Exynos4210
have TMU_SUPPORT_EMULATION flag set in their struct exynos_tmu_init_data
instances).
There should be no functional changes caused by this patch.
Cc: Amit Dan
Add ->tmu_read method to struct exynos_tmu_data and use it
in exynos_tmu_control(). Then add ->tmu_read implementations
for Exynos4210, Exynos4412+ and Exynos5440. Finally remove
no longer needed reg->tmu_cur_temp abstractions.
There should be no functional changes caused by this patch.
Cc: Ami
Factor out code for preparing TMU_CONTROL register value from
exynos_tmu_control() into get_con_reg().
This is a preparation for introducing per-SoC type tmu_control
method.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap
Cc: Lukasz Majewski
Cc: Eduardo Vale
Add ->tmu_initialize method to struct exynos_tmu_data and
use it in exynos_tmu_initialize(). Then add ->tmu_initialize
implementations for Exynos4210, Exynos4412+ and Exynos5440.
Finally remove no longer needed reg->threshold_th[0,1],
reg->intclr_[fall,rise]_shift and reg->intclr_[rise,fall]_mask
Add ->tmu_control method to struct exynos_tmu_data and use it
in exynos_tmu_control(). Then add ->tmu_control implementations
for Exynos4210+ and Exynos5440. Finally remove no longer needed
reg->tmu_[ctrl,inten], reg->inten_rise[0,1,2,3]_shift and
reg->inten_fall0_shift abstractions.
There shoul
Add ->tmu_set_emulation method to struct exynos_tmu_data and
use it in exynos_tmu_set_emulation(). Then add ->tmu_set_emulation
implementations for Exynos4412+ and Exynos5440. Finally remove
no longer needed reg->emul_con abstraction.
There should be no functional changes caused by this patch.
Factor out code for preparing EMUL_CON register value from
exynos_tmu_set_emulation() into get_emul_con_reg().
This is a preparation for introducing per-SoC type
tmu_set_emulation method.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap
Cc: Lukasz Majewski
Cc
Replace TMU_SUPPORT_TRIM_RELOAD flag check in exynos_tmu_initialize()
by an explicit check for a SoC type (only Exynos3250, Exynos4412 and
Exynos5250 have TMU_SUPPORT_READY_STATUS flag set in their struct
exynos_tmu_init_data instances). Please note that this requires
adding separate SoC type for
Factor out code for preparing threshold register value from
exynos_tmu_initialize() into get_th_reg().
This is a preparation for introducing per-SoC type tmu_initialize
method.
There should be no functional changes caused by this patch.
Cc: Amit Daniel Kachhap
Cc: Lukasz Majewski
Cc: Eduardo V
Replace TMU_SUPPORT_READY_STATUS flag check in
exynos_tmu_initialize() by an explicit check for a SoC type
(all SoC types except Exynos5440 have TMU_SUPPORT_READY_STATUS
flag set in their struct exynos_tmu_init_data instances).
This is a preparation for introducing per-SoC type tmu_initialize
meth
Simplify HW_TRIP level setting in exynos_tmu_initialize() (don't
pretend that the current code is hardware and configuration
independent and just do SoC type check explicitly). Then remove
no longer needed reg->threshold_[th2,th3_l0_shift] abstractions
(only assigned for Exynos5440 in exynos5440_t
reg->tmu_pmin is set to non-zero value only for Exynos5440
so replace check for non-zero value of reg->tmu_pmin by
explicitly checking for Exynos5440 SoC type. Then remove no
longer needed reg->tmu_pmin register abstraction.
There should be no functional changes caused by this patch.
Cc: Amit Da
Replace pdata->threshold_falling check for non-zero value in
exynos_tmu_initialize() by an explicit check for a SoC type
(all SoC types except Exynos5440 have pdata->threshold_falling
assigned to non-zero value in their struct exynos_tmu_registers
instances).
This is a preparation for introducing
reg->emul_temp_shift is used only in exynos_tmu_set_emulation()
and accessed only if TMU_SUPPORT_EMULATION flag is set. This
flag is not set for Exynos4210 (reg->emul_temp_shift field is
not even assigned in exynos4210_tmu_registers and is assigned
to identical value for all other SoC types) so th
reg->emul_time_shift is used only in exynos_tmu_set_emulation()
and accessed only if TMU_SUPPORT_EMUL_TIME flag is set. This
flag is not set for Exynos4210 and Exynos5440 (reg->emul_time_shift
field is not even assigned in exynos[4210,5440]_tmu_registers
and is assigned to identical value for all
reg->tmu_irqstatus is set to non-zero value only for Exynos5440
so replace check for non-zero value of reg->tmu_irqstatus by
explicitly checking for Exynos5440 SoC type. Then remove no
longer needed reg->tmu_irqstatus register abstraction.
There should be no functional changes caused by this patc
On Thu, Nov 13, 2014 at 4:23 PM, Eric Auger wrote:
> On 11/13/2014 03:16 PM, Eric Auger wrote:
>> On 11/13/2014 11:45 AM, Nikolay Nikolaev wrote:
>>> On Mon, Nov 10, 2014 at 6:27 PM, Christoffer Dall
>>> wrote:
On Mon, Nov 10, 2014 at 05:09:07PM +0200, Nikolay Nikolaev wrote:
> Hello,
>>
reg->therm_trip_mode_shift and reg->therm_trip_mode_mask are
used only in exynos_tmu_control() and accessed only if
pdata->noise_cancel_mode is non-zero. pdata->noise_cancel
field is not defined on Exynos4210 (also therm_trip_mode_shift
and therm_trip_mode_mask entries are not even assigned in
exy
reg->test_mux_addr_shift is used only if pdata->test_mux is
non-zero. pdata->test_mux is defined only on Exynos3250 and
Exynos4412 (other SoC types don't even have pdata->test_mux
entry assigned in their struct exynos_tmu_registers instances)
so the abstraction is not needed and can be removed.
T
reg->threshold_temp is used only in exynos_tmu_initialize() and
is accessed only on Exynos4210 (other SoC types don't even have
threshold_temp entry assigned in their struct exynos_tmu_registers
instances) so the register abstraction is not needed and can be
removed.
There should be no functional
Hi,
This patch series replaces the hardware registers abstractions in
the Exynos thermal driver by the usage of per-SoC type operations.
Such solution provides simpler, easier to understand code and
allows removal of ~250 LOCs (~11% of the whole source code) from
the driver. Some other driver imp
reg->triminfo_data is used only in exynos_tmu_initialize() and
the code has already different paths for Exynos5440 and other
SoC types (on which TRIMINFO_DATA register offset is identical)
so the register abstraction is not needed and can be removed.
There should be no functional changes caused by
reg->tmu_status is used only in exynos_tmu_initialize() and it
is accessed only if TMU_SUPPORT_READY_STATUS flag is set. This
flag is not set for Exynos5440 and TMU_STATUS register offset
is identical for all other SoC types so the abstraction is not
needed and can be removed.
There should be no
Hi,
Sorry for sending this multiple times. There was some problem with my mail
configuration which I have fixed now.
Thanks
Kishon
On Thursday 13 November 2014 08:24 PM, Kishon Vijay Abraham I wrote:
> Added HS200 to improve EMMC throughput for dra72.
>
> With HS200
> ==
> Read thro
From: Balaji T K
MMC tuning procedure is required to support SD card
UHS1-SDR104 mode and EMMC HS200 mode.
The tuning function omap_execute_tuning() will only
be called by the MMC/SD core if the corresponding
speed modes are supported by the OMAP silicon which
is set in the mmc host "caps" field
Added HS200 to improve EMMC throughput for dra72.
With HS200
==
Read throughput
./dd if=/dev/mmcblk0 of=/dev/null bs=1M count=100 oflag=sync
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 1.46028 s, 71.8 MB/s
Write throughput
root@dra7xx-evm:/# ./dd if=/dev/zero o
On Wed, Nov 12, 2014 at 03:03:50PM +, Daniel Lezcano wrote:
> The only place where the time is invalid is when the ACPI_CSTATE_FFH entry
> method is not set. Otherwise for all the drivers, the time can be correctly
> measured.
>
> Instead of duplicating the CPUIDLE_FLAG_TIME_VALID flag in all
On (11/12/14 22:37), Mahendran Ganesh wrote:
> In struct zram_table_entry, the element *value* contains obj size and
> obj zram flags. Bit 0 to bit (ZRAM_FLAG_SHIFT - 1) represent obj size,
> and bit ZRAM_FLAG_SHIFT to the highest bit of unsigned long represent obj
> zram_flags. So the first zram f
On Wed, 12 Nov 2014, Dave Hansen wrote:
> +/*
> + * Get the base of bounds tables pointed by specific bounds
> + * directory entry.
> + */
> +static int get_bt_addr(struct mm_struct *mm,
> + long __user *bd_entry, unsigned long *bt_addr)
> +{
> + int ret;
> + int valid;
From: Viswanath Puttagunta
set SDR104, SDR50, DDR50 and HS200 capability flags to caps/caps2 by reading
MMCHS_CAPA2 register.
Signed-off-by: Viswanath Puttagunta
Signed-off-by: Sourav Poddar
Signed-off-by: Kishon Vijay Abraham I
Suggested-by: Misael Lopez Cruz
---
drivers/mmc/host/omap_hsmm
Hi Arnd,
Thanks for reviewing.
On Thu, 13 Nov 2014, Arnd Bergmann wrote:
> On Thursday 13 November 2014 11:00:16 Peter Griffin wrote:
> > + soc {
> > + usb2_picophy0: usbpicophy@0 {
> > + compatible = "st,stih407-usb2-phy";
> > + re
Set the maximum operating frequency of MMC2 to 192MHz.
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/boot/dts/dra72-evm.dts |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index abbaaa7..5cc1110 100644
--- a/arch/arm/b
601 - 700 of 978 matches
Mail list logo
