Re: [PATCH 2/2] arm64: take onlined cpus into account when setting irq affinity in migrate_one_irq
On Wed, Aug 27, 2014 at 7:40 PM, Sudeep Holla wrote:
>
>
> On 27/08/14 10:30, byungchul.p...@lge.com wrote:
>>
>> From: Byungchul Park
>>
>> This patch ensures that the cpu being offlined is not present in the
>> affinity mask.
>>
>
> I agree that this patch fixes the issue reported in [1] without
> disabling forced set affinity mask. However Thomas responded yesterday
> asking to disable it [2] on the original thread for ARM. I have
> responded on the thread and waiting for feedback from rmk and tglx. I
> would prefer to wait and align with ARM code if possible.
It is also good to call irq_set_affinity() with "force = false" to
solve the problem,
because it can give a chance to check if the passed affinity includes
only onlined cpus or not.
However, it totally relies on the implementation of irq_set_affinity(),
and it cannnot ensure that the function performs what we expect.
I think a code basically needs to be written to do exactly what it intends.
It is not bad to apply calling irq_set_affinity() with "force = false"
to the code if necessary.
But this patches also have to be applied, independently,
in order to make the code do exactly what it intends.
Thank you.
>
>> Signed-off-by: Byungchul Park
>> ---
>> arch/arm64/kernel/irq.c |9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
>> index 473e5db..0c7b79e 100644
>> --- a/arch/arm64/kernel/irq.c
>> +++ b/arch/arm64/kernel/irq.c
>> @@ -87,6 +87,7 @@ static bool migrate_one_irq(struct irq_desc *desc)
>> {
>> struct irq_data *d = irq_desc_get_irq_data(desc);
>> const struct cpumask *affinity = d->affinity;
>> + struct cpumask tmp_affinity;
>> struct irq_chip *c;
>> bool ret = false;
>>
>> @@ -100,6 +101,14 @@ static bool migrate_one_irq(struct irq_desc *desc)
>> if (cpumask_any_and(affinity, cpu_online_mask) >= nr_cpu_ids) {
>> affinity = cpu_online_mask;
>> ret = true;
>> + } else {
>> + /*
>> +* when using forced irq_set_affinity we must ensure that
>> the cpu
>> +* being offlined is not present in the affinity mask, it
>> may be
>> +* selected as the target CPU otherwise
>> +*/
>> + cpumask_and(&tmp_affinity, affinity, cpu_online_mask);
>
>
> In case we decide to retain forced set affinity, you can probably squash
> this cpumask_and with the above cpumask_any_and.
>
>> + affinity = &tmp_affinity;
>> }
>>
>> c = irq_data_get_irq_chip(d);
>>
>
> Regards,
> Sudeep
>
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266785.html
> [2]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/281548.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
LG electronics CTO division
senior engineer
max.byungchul.park
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] pinctrl: qcom: Release pin ranges when gpiochip_irqchip_add fails
On Thursday 28 August 2014 02:54 AM, Bjorn Andersson wrote:
> On Wed, Aug 27, 2014 at 3:57 AM, Pramod Gurav
> wrote:
>> This patches adds a call to gpiochip_remove_pin_ranges when
>> gpiochip_irqchip_add fails to release memory allocated for pin_ranges.
>>
>> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
>> b/drivers/pinctrl/qcom/pinctrl-msm.c
>> @@ -845,6 +845,7 @@ static int msm_gpio_init(struct msm_pinctrl *pctrl)
>>IRQ_TYPE_NONE);
>> if (ret) {
>> dev_err(pctrl->dev, "Failed to add irqchip to gpiochip\n");
>> + gpiochip_remove_pin_ranges(chip);
>> return -ENOSYS;
>> }
>
> Good catch, I guess this was lost in the introduction of gpiochip_irqchip...
>
>
> Rather than just releasing the pin_ranges of the gpio_chip you should
> probably add a gpiochip_remove() both here and in the case of
> gpiochip_add_pin_range() failing.
Thanks for review. But if I see implementation of gpiochip_remove() it does:
gpiochip_irqchip_remove(chip);
gpiochip_remove_pin_ranges(chip);
of_gpiochip_remove(chip);
In above failure case only gpiochip_add() and gpiochip_add_pin_range()
have been successful hence I thought that would cause any problem to add
gpiochip_remove(). If that is not a problem I think we can call
gpiochip_remove() in fail case of gpiochip_add_pin_range() as well.
Do I make sense?
>
> Regards,
> Bjorn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linux 3.12.27
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm announcing the release of the 3.12.27 kernel.
All users of the 3.12 kernel series must upgrade.
The updated 3.12.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.12.y
and can be browsed at the normal kernel.org git web browser:
http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
-
Akeem G Abodunrin (1):
igb: Fixed Wake On LAN support
Ales Novak (1):
drivers/rtc/interface.c: fix infinite loop in initializing the alarm
Alexandre Bounine (1):
rapidio/tsi721_dma: fix failure to obtain transaction descriptor
Andrey Ryabinin (1):
net: sendmsg: fix NULL pointer dereference
Andrey Utkin (1):
arch/sparc/math-emu/math_32.c: drop stray break operator
Andy Lutomirski (1):
x86_64/entry/xen: Do not invoke espfix64 on Xen
Anssi Hannula (1):
dm cache: fix race affecting dirty block count
Benjamin Tisssoires (1):
HID: logitech-dj: Fix USB 3.0 issue
Boris Ostrovsky (1):
x86/espfix/xen: Fix allocation of pages for paravirt page tables
Carolyn Wyborny (1):
igb: Fix master/slave mode for all m88 i354 PHY's
Cedric Le Goater (1):
offb: Little endian fixes
Christoph Paasch (2):
tcp: Fix integer-overflows in TCP veno
tcp: Fix integer-overflow in TCP vegas
Christopher Alexander Tobias Schulze (2):
bbc-i2c: Fix BBC I2C envctrl on SunBlade 2000
sunsab: Fix detection of BREAK on sunsab serial console
Dan Carpenter (2):
igbvf: integer wrapping bug setting the mtu
RDMA/cxgb3: Fix information leak in send_abort()
Daniel Borkmann (1):
net: sctp: inherit auth_capable on INIT collisions
David Ertman (1):
e1000e: Fix a compile flag mis-match for suspend/resume
David Gibson (1):
netxen: Correct off-by-one errors in bounds checks
David Rientjes (1):
mm, thp: do not allow thp faults to avoid cpuset restrictions
David S. Miller (9):
sparc64: Fix argument sign extension for compat_sys_futex().
sparc64: Handle 32-bit tasks properly in
compute_effective_address().
sparc64: Fix top-level fault handling bugs.
sparc64: Give more detailed information in {pgd,pmd}_ERROR() and
kill pte_ERROR().
sparc64: Don't bark so loudly about 32-bit tasks generating
64-bit fault addresses.
sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus.
sparc64: Add membar to Niagara2 memcpy code.
sparc64: Do not insert non-valid PTEs into the TSB hash table.
sparc64: Guard against flushing openfirmware mappings.
Dmitry Kravkov (1):
bnx2x: fix crash during TSO tunneling
Don Skidmore (1):
ixgbevf: cleanup redundant mailbox read failure check
Eliad Peller (2):
cfg80211: fix mic_failure tracing
mac80211: reset probe_send_count also in HW_CONNECTION_MONITOR case
Emil Tantilov (2):
ixgbe: fix rx-usecs range checks for BQL
ixgbe: fix inconsistent clearing of the multicast table
Eric Dumazet (3):
inetpeer: get rid of ip_id_count
ip: make IP identifiers less predictable
sctp: fix possible seqlock seadlock in sctp_packet_transmit()
Eric W. Biederman (3):
mnt: Only change user settable mount flags in remount
mnt: Move the test for MNT_LOCK_READONLY from change_mount_flags
into do_remount
mnt: Correct permission checks in do_remount
Felix Fietkau (1):
ath9k: fix aggregation session lockup
Fujinaka, Todd (2):
igb: Add ethtool offline tests for i354
igb: Don't let ethtool try to write to iNVM in i210/i211
Greg Thelen (1):
dm bufio: fully initialize shrinker
H. Peter Anvin (6):
Revert "x86-64, modify_ldt: Make support for 16-bit segments a
runtime option"
x86-64, espfix: Don't leak bits 31:16 of %esp returning to
16-bit stack
x86, espfix: Move espfix definitions into a separate header file
x86, espfix: Fix broken header guard
x86, espfix: Make espfix64 a Kconfig option, fix UML
x86, espfix: Make it possible to disable 16-bit support
Hong Zhiguo (1):
e1000: fix wrong queue idx calculation
Ilan Peer (1):
iwlwifi: mvm: Add a missed beacons threshold
Jacob Keller (1):
ixgbe: fix qv_lock_napi call in ixgbe_napi_disable_all
James Bottomley (1):
scsi: handle flush errors properly
Jan Beulich (1):
drivers/rtc/rtc-efi.c: check for invalid data coming back from UEFI
Jan Kara (2):
timer: Fix lock inversion between hrtimer_bases.lock and
scheduler locks
ext4: Fix block zeroing when punching holes in indirect block files
Jiri Kosina (1):
Input: i8042 - add Acer Aspire 5710 to nomux blacklist
Jiri Slaby (1):
Linux 3.12.27
Johannes Berg (1):
Revert "mac80211: move "bufferable MMPDU" check to fix AP mode scan"
John Stultz (1):
printk: rename printk_sched to printk_deferred
Keith Pa
Re: [PATCH v2] DRBG: fix maximum value checks on 32 bit systems
Am Mittwoch, 27. August 2014, 21:35:28 schrieb Herbert Xu: Hi Herbert, > On Tue, Aug 26, 2014 at 11:36:54AM +0200, Stephan Mueller wrote: > > The max_addtllen and max_req are defined in drbg_cores[] in crypto/drbg.c > > for each DRBG type. As size_t on a 32 bit system is 32 bit the bit shifts > > would not work either. > > > > Thus, I am wondering whether the just applied patch would need to go to > > Linus > > tree too? I would think that the following patch would be in order: > Have you actually tested this on a 32-bit box? If so and it > actually works then I'd be happy to push it. I tested the current cryptodev-2.6: - on x86_64 and on i386 - in FIPS mode and without FIPS mode on both arches - executing the CAVS testing in FIPS mode and non-FIPS mode on both arches - executing stress tests (obtain random values at a size randomly selected between 1 through 1 million bytes) in both modes on both arches - adding some debug printks to check for the drbg_max_addtl() on both arches - adding some debug printks to check for the drbg_max_requests() on both arches I found a bug that was introduced with bc034ef5573ef4d81daa666c02a3df1ad28e24a7 when booting in FIPS mode, i.e. it is not in Linus' tree. The patch will be on your desk shortly. Thus, the fix in b9347aff91ce4789619168539f08202d8d6a1177 works. However, this patch is based on 05c81ccd9087d238c10b234eadb55632742e5518. So, if we want to fix Linus' tree with minimal impact, either these two patches are pushed to Linus or I have to port b9347aff91ce4789619168539f08202d8d6a1177 to the current Linus tree. > > Cheers, -- Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 00/21] Support ext4 on NV-DIMMs
On Wed, Aug 27, 2014 at 02:30:55PM -0700, Andrew Morton wrote: > On Wed, 27 Aug 2014 16:22:20 -0500 (CDT) Christoph Lameter > wrote: > > > > Some explanation of why one would use ext4 instead of, say, > > > suitably-modified ramfs/tmpfs/rd/etc? > > > > The NVDIMM contents survive reboot and therefore ramfs and friends wont > > work with it. > > See "suitably modified". Presumably this type of memory would need to > come from a particular page allocator zone. ramfs would be unweildy > due to its use to dentry/inode caches, but rd/etc should be feasible. That's where we started about two years ago with that horrible pramfs trainwreck. To start with: brd is a block device, not a filesystem. We still need the filesystem on top of a persistent ram disk to make it useful to applications. We can do this with ext4/XFS right now, and that is the fundamental basis on which DAX is built. For sake of the discussion, however, let's walk through what is required to make an "existing" ramfs persistent. Persistence means we can't just wipe it and start again if it gets corrupted, and rebooting is not a fix for problems. Hence we need to be able to identify it, check it, repair it, ensure metadata operations are persistent across machine crashes, etc, so there is all sorts of management tools required by a persistent ramfs. But most important of all: the persistent storage format needs to be forwards and backwards compatible across kernel versions. Hence we can't encode any structure the kernel uses internally into the persistent storage because they aren't stable structures. That means we need to marshall objects between the persistence domain and the volatile domain in an orderly fashion. We can avoid using the dentry/inode *caches* by freeing those volatile objects the moment reference counts dop to zero rather than putting them on LRUs. However, we can't store them in persistent storage and we can't avoid using them to interface with the VFS, so it makes little sense to burn CPU continually marshalling such structures in and out of volatile memory if we have free RAM to do so. So even with a "persistent ramfs" caching the working set of volatile VFS objects makes sense from a peformance point of view. Then you've got crash recovery management: NVDIMMs are not synchronous: they can still lose data while it is being written on power loss. And we can't update persistent memory piecemeal as the VFS code modifies metadata - there needs to be synchronisation points, otherwise we will always have inconsistent metadata state in persistent memory. Persistent memory also can't do atomic writes across multiple, disjoint CPU cachelines or NVDIMMs, and this is what is needed for synchroniation points for multi-object metadata modification operations to be consistent after a crash. There is some work in the nvme working groups to define this, but so far there hasn't been any useful outcome, and then we willhave to wait for CPUs to implement those interfaces. Hence the metadata that indexes the persistent RAM needs to use COW techniques, use a log structure or use WAL (journalling). Hence that "persistent ramfs" is now looking much more like a database or traditional filesystem. Further, it's going to need to scale to very large amounts of storage. We're talking about machines with *tens of TB* of NVDIMM capacity in the immediate future and so free space manangement and concurrency of allocation and freeing of used space is going to be fundamental to the performance of the persistent NVRAM filesystem. So, you end up with block/allocation groups to subdivide the space. Looking a lot like ext4 or XFS at this point. And now you have to scale to indexing tens of millions of everything. At least tens of millions - hundreds of millions to billions is more likely, because storing tens of terabytes of small files is going to require indexing billions of files. And because there is no performance penalty for doing this, people will use the filesystem as a great big database. So now you have to have a scalable posix compatible directory structures, scalable freespace indexation, dynamic, scalable inode allocation, freeing, etc. Oh, and it also needs to be highly concurrent to handle machines with hundreds of CPU cores. Funnily enough, we already have a couple of persistent storage implementations that solve these problems to varying degrees. ext4 is one of them, if you ignore the scalability and concurrency requirements. XFS is the other. And both will run unmodified on a persistant ram block device, which we *already have*. And so back to DAX. What users actually want from their high speed persistant RAM storage is direct, cpu addressable access to that persistent storage. They don't want to have to care about how to find an object in the persistent storage - that's what filesystems are for - they just want to be able to read and write to it directly. That's what DAX does - it provides existing filesystems a method
DRBG: remove test for uninitialized DRBG handle
The drbg_healthcheck() contains a test to call the DRBG with an uninitialized DRBG cipher handle. As this is an inappropriate use of the kernel crypto API to try to generate random numbers before initialization, checks verifying for an initialized DRBG during the generate function have been removed in previous patches. Now, the drbg_healthcheck test trying to generate random numbers with an uninstantiated DRBG must also be removed. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/crypto/drbg.c b/crypto/drbg.c index 39ed918..54cfd48 100644 --- a/crypto/drbg.c +++ b/crypto/drbg.c @@ -1872,9 +1872,6 @@ static inline int __init drbg_healthcheck_sanity(void) /* overflow max addtllen with personalization string */ ret = drbg_instantiate(drbg, &addtl, coreref, pr); BUG_ON(0 == ret); - /* test uninstantated DRBG */ - len = drbg_generate(drbg, buf, (max_request_bytes + 1), NULL); - BUG_ON(0 < len); /* all tests passed */ rc = 0; -- 1.9.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] watchdog: add driver for Ricoh RN5T618 watchdog
On Wed, 27 Aug 2014, Guenter Roeck wrote:
> On Wed, Aug 27, 2014 at 12:13:56AM +0200, Beniamino Galvani wrote:
> > This adds a driver for the watchdog timer available in Ricoh RN5T618
> > PMIC. The device supports a programmable expiration time of 1, 8, 32
> > or 128 seconds.
> >
> > Signed-off-by: Beniamino Galvani
> > ---
> > drivers/watchdog/Kconfig | 11 +++
> > drivers/watchdog/Makefile |1 +
> > drivers/watchdog/rn5t618_wdt.c | 196
> >
> > include/linux/mfd/rn5t618.h|4 +
> > 4 files changed, 212 insertions(+)
> > create mode 100644 drivers/watchdog/rn5t618_wdt.c
[...]
> > +++ b/drivers/watchdog/rn5t618_wdt.c
> > @@ -0,0 +1,196 @@
[...]
> > +static int rn5t618_wdt_set_timeout(struct watchdog_device *wdt_dev,
> > + unsigned int timeout)
> > +{
> > + struct rn5t618_wdt *wdt = watchdog_get_drvdata(wdt_dev);
> > + int ret, i;
> > +
> > + for (i = 0; i < ARRAY_SIZE(rn5t618_wdt_map); i++) {
> > + if (rn5t618_wdt_map[i].time + 1 >= timeout)
> > + break;
> > + }
> > +
> > + if (i == ARRAY_SIZE(rn5t618_wdt_map))
> > + ret = -EINVAL;
>
> Can you simplify this a bit ? If you use
>
> if (i == ARRAY_SIZE(rn5t618_wdt_map))
> return -EINVAL;
This changes the semantics.
> > + else
>
> You can drop this else statement.
>
> > + ret = regmap_update_bits(wdt->rn5t618->regmap, RN5T618_WATCHDOG,
> > +RN5T618_WATCHDOG_WDOGTIM_M,
> > +rn5t618_wdt_map[i].reg_val);
> > + if (!ret)
> > + wdt_dev->timeout = rn5t618_wdt_map[i].time;
... Isn't this important?
> > + return ret;
> > +}
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] lpc_ich: Add Device IDs for Intel 9 Series PCH
On Wed, 27 Aug 2014, James Ralston wrote:
> This patch adds the LPC Device IDs for the Intel 9 Series PCH.
>
> Signed-off-by: James Ralston
> ---
> drivers/mfd/lpc_ich.c | 11 +++
> 1 file changed, 11 insertions(+)
Applied, thanks.
> diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
> index 7d8482f..cb41f4f 100644
> --- a/drivers/mfd/lpc_ich.c
> +++ b/drivers/mfd/lpc_ich.c
> @@ -54,6 +54,7 @@
> * document number TBD : Avoton SoC
> * document number TBD : Coleto Creek
> * document number TBD : Wildcat Point-LP
> + * document number TBD : 9 Series
> */
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> @@ -216,6 +217,7 @@ enum lpc_chipsets {
> LPC_BAYTRAIL, /* Bay Trail SoC */
> LPC_COLETO, /* Coleto Creek */
> LPC_WPT_LP, /* Wildcat Point-LP */
> + LPC_9S, /* 9 Series */
> };
>
> static struct lpc_ich_info lpc_chipset_info[] = {
> @@ -519,6 +521,10 @@ static struct lpc_ich_info lpc_chipset_info[] = {
> .name = "Wildcat Point_LP",
> .iTCO_version = 2,
> },
> + [LPC_9S] = {
> + .name = "9 Series",
> + .iTCO_version = 2,
> + },
> };
>
> /*
> @@ -745,6 +751,11 @@ static const struct pci_device_id lpc_ich_ids[] = {
> { PCI_VDEVICE(INTEL, 0x9cc6), LPC_WPT_LP},
> { PCI_VDEVICE(INTEL, 0x9cc7), LPC_WPT_LP},
> { PCI_VDEVICE(INTEL, 0x9cc9), LPC_WPT_LP},
> + { PCI_VDEVICE(INTEL, 0x8cc1), LPC_9S},
> + { PCI_VDEVICE(INTEL, 0x8cc2), LPC_9S},
> + { PCI_VDEVICE(INTEL, 0x8cc3), LPC_9S},
> + { PCI_VDEVICE(INTEL, 0x8cc4), LPC_9S},
> + { PCI_VDEVICE(INTEL, 0x8cc6), LPC_9S},
> { 0, }, /* End of list */
> };
> MODULE_DEVICE_TABLE(pci, lpc_ich_ids);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 4/4] drivers/hwmon/menf21bmc_hwmon: introduce MEN14F021P00 BMC HWMON driver
On Wed, Aug 27, 2014 at 11:38:43AM -0700, Guenter Roeck wrote: > On Wed, Aug 27, 2014 at 07:53:06PM +0200, Andreas Werner wrote: > > Added driver to support the 14F021P00 BMC Hardware Monitoring. > > The BMC is a Board Management Controller including monitoring of the > > board voltages. > > > > Signed-off-by: Andreas Werner > > Looks good, though I do have one comment ... > > > + > > + hwmon_dev = devm_hwmon_device_register_with_groups(&pdev->dev, > > + "menf21bmc", drv_data, > > + menf21bmc_hwmon_groups); > > + if (IS_ERR(hwmon_dev)) > > + return PTR_ERR(hwmon_dev); > > + > > + dev_info(&pdev->dev, "MEN 14F021P00 BMC hwmon device enabled"); > > + > You removed the dev_info from the mfd driver but left it in the client > drivers. If you'd drop it here as well, you could use > 'return PTR_ERR_OR_ZERO(hwmon_dev);'. Just a suggestion, not mandatory. > > Either case, It is a nice info for every slave driver which are the drivers for accessing the features in the BMC. The mfd is just the driver who will instantiate the slaves. For the mfd the most important info is if there was an error. Anyway good idea with PTR_ERR_OR_ZERO. Thanks for the nice review and the comments. Regards Andy > > Reviewed-by: Guenter Roeck > > I assume this will go in through the mfd tree. > > Thanks, > Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/7] dmaengine: edma: fix two faults which happen with the 8250_dma user
On Thu, Aug 21, 2014 at 03:09:12PM +0200, Sebastian Andrzej Siewior wrote: > On 08/19/2014 05:12 PM, Vinod Koul wrote: > >> > >> desc = dmaengine_prep_slave_single(rxchan, …); > >> rx_cookie = dmaengine_submit(desc); > >> dma_async_issue_pending(rxchan); > >> > >> ssleep(2); > >> /* Now assume that the transfer did not start */ > >> st = dmaengine_tx_status(rxchan, rx_cookie, NULL); > >> /* st is now DMA_IN_PROGRESS as expected */ > >> > >> dmaengine_terminate_all(rxchan); > >> st = dmaengine_tx_status(rxchan, rx_cookie, NULL); > > and here is the culprit. You have terminated the channel. This means that > > dmaengine driver is free to clean up all the allocated descriptors on the > > channels and do whatever it decides to do with them. > > descriptors, yes. and by that logic when you query the driver would have freed up! > > You have already terminated the channel so what is the point in querying the > > status of the cookie, which you shouldn't use anyway after invoking > > terminate_all() as its result is not correct. > > The point is to check (later, after terminate_all()) if there is an > outstanding DMA transfer or not _and_ how much data was really > transfered. Looking at edma it does not really support the latter if > the transfer is already completed. On the plus side the HW does not > support partly transfers :) well that can be achieved properly and differently! Why don't we pause the channel, get the residue, status and then terminate. > But where is it written that the life time of the cookie is limited? > Looking at the "cooking check" code there is no such thing. It is > simply compare of completed vs passed number but okay, this is an > implementation detail. > From [0] it says under "4. Submit the transaction": > > | This returns a cookie can be used to check the progress of DMA engine > | activity via other DMA engine calls not covered in this document. > > no life time limit mentioned here. Which brings to the question: Why is > it okay to use the cookie after the transaction "terminated" normally > but not if it has been canceled? Due to the special nature of terminate. The point here is that you don't terminate a transaction but channel operation > And from [0] the API explanation "4. … dma_async_is_tx_complete()": > > |Note: > |Not all DMA engine drivers can return reliable information for > |a running DMA channel. It is recommended that DMA engine users > |pause or stop (via dmaengine_terminate_all) the channel before > |using this API. > > So the documentation says to use the cookie with > dma_async_is_tx_complete() and before doing so it is recommended that > the transfer should be paused or stopped. _Exactly_ what is done here. > > >> /* st is still DMA_IN_PROGRESS but _I_ expect DMA_COMPLETE because > >> * it has been terminated / canceled > >> */ > >> > >> Both dma driver clean up all / terminate all descriptors as required but > >> _none_ of them completes the cookie. As a result dma_cookie_status() > >> still thinks that the transfer is in progress. > > > > Btw how does it matter in the driver here if the transaction completed or > > not after terminate_all() was invoked. What is the purpose of querying > > status. > > In the RX interrupt (of the 8250 unit), the code checks if the transfer > has been already started or not via querying the status. So if it > returns DMA_COMPLETE then a new transfer will be started. If it returns > DMA_IN_PROGRESS then the code returns doing nothing because the DMA > engine should start moving data anytime now so the RX interrupt goes > away. > > That means: If the transfer is canceled then it won't be started again. > > Btw: the current (probably only) dma driver that is used by 8250-dma is > dw/core.c. That one does cookie complete on terminate: > dwc_control(DMA_TERMINATE_ALL) -> dwc_descriptor_complete() -> > dma_cookie_complete(). Yes but would above flow work for you :) -- ~Vinod > > That is why it works for them… > > [0] Documentation/dmaengine.txt > > > > > Thanks > > > > Sebastian -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] brd: Add getgeo to block ops
On 08/27/2014 08:53 PM, Matthew Wilcox wrote: > On Wed, Aug 27, 2014 at 06:28:25PM +0300, Boaz Harrosh wrote: >> We set all hd_geometry members to 1, because this way fdisk >> math will not try its crazy geometry math and get stuff totally wrong. >> >> I was trying to get some values that will make fdisk Want to align >> first sector on 4K (like 8, 16, 20, ... sectors) but nothing worked, >> I searched the net the math is not your regular simple multiplication >> at all. >> >> If you managed to get these please tell me. I would love to solve >> this. >> >> But for now we use 4k physical sectors for fixing fdisk alignment >> issues, and setting these here to something that will not make >> fdisk serve us with crazy numbers. > > Are you saying that fdisk ignores the 4k physical sectors (that you set up > in patch 5/5) in favour of the geometry exposed here? That doesn't make > sense to me, since it would misalign 4k-physical ATA drives if it did. > No with patch 5/5 the 4k stuff is good. What I'm saying is that with (64, 32, x) fdisk offers a very high first sector and with all 1(s) it will allow a low value like 4k For example with (64, 32, x) + the 4k patch in 5/5 with a 4M brd disk it will offer 40 (20K) as first possible sector. With this patch applied it will offer 8 (4K) as first sector, which is what I want > I don't see anywhere else in the kernel reporting (1,1,1). The most common > form to fake a geometry uses (64, 32, x), including SCSI. > But is it wrong? why? I guess that until now no one cared about wasted space at the beginning but with brd I do. Your words this is all "fake" then why at all. With all 1(s) the CHS convoluted math just disappears and gets out of the way. This is clearly the case of copy/paste so long in the history of the code that no one knows why it was done originally, and it has become religion that if you dare touch it ghost will come out of closets. But I looked at the code's math and I found that this is better. And why not let it be a flag to UM that this is RAM based? If legacy code likes it just fine, why do we think otherwise? Thanks Boaz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/5] MFD: RK808: Add new mfd driver for RK808
On Wed, 27 Aug 2014, Dmitry Torokhov wrote:
> On Wednesday, August 27, 2014 02:39:36 PM Lee Jones wrote:
> > On Tue, 26 Aug 2014, Chris Zhong wrote:
> > > +
> > > +static struct of_device_id rk808_of_match[] = {
> > > + { .compatible = "rockchip,rk808" },
> > > +};
> > > +MODULE_DEVICE_TABLE(of, rk808_of_match);
> > > +
> > > +static const struct i2c_device_id rk808_ids[] = {
> > > + { "rk808" },
> > > +};
> > > +
> > > +MODULE_DEVICE_TABLE(i2c, rk808_ids);
> >
> > My OCD senses are tingling. Either have a blank line above the calls
> > to MODULE_DEVICE_TABLE() or don't.
>
> Wait, don't we also need sentinel entries in both these tables?
Good spot, yes please.
{ },
Will do fine.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 06/12] sched: add per rq cpu_capacity_orig
On 27 August 2014 15:32, Kamalesh Babulal wrote: > * Vincent Guittot [2014-08-26 13:06:49]: > >> This new field cpu_capacity_orig reflects the available capacity of a CPUs >> unlike the cpu_capacity which reflects the current capacity that can be >> altered >> by frequency and rt tasks. >> >> Signed-off-by: Vincent Guittot > > Reviewed-by: Kamalesh Babulal Thanks > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/4] drivers/mfd/menf21bmc: introduce MEN 14F021P00 BMC MFD Core driver
On Wed, 27 Aug 2014, Andreas Werner wrote: > The MEN 14F021P00 Board Management Controller provides an > I2C interface to the host to access the feature implemented in the BMC. > The BMC is a PIC Microntroller assembled on CPCI Card from MEN Mikroelektronik > and on a few Box/Display Computer. > > Added MFD Core driver, supporting the I2C communication to the device. > > The MFD driver currently supports the following features: > - Watchdog > - LEDs > - Hwmon (voltage monitoring) > > Signed-off-by: Andreas Werner > --- > drivers/mfd/Kconfig | 15 ++ > drivers/mfd/Makefile| 1 + > drivers/mfd/menf21bmc.c | 132 > > 3 files changed, 148 insertions(+) > create mode 100644 drivers/mfd/menf21bmc.c I'd like to take this set through the MFD tree, but for now: Acked-by: Lee Jones -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 16/17] arcmsr: support new adapter ARC12x4 series
On Wed, 2014-08-27 at 16:00 +0200, Tomas Henzl wrote:
> On 08/19/2014 09:25 AM, Ching Huang wrote:
> > From: Ching Huang
> >
> > Add code for supporting Areca new Raid adapter ARC12x4 series.
> >
> > Signed-off-by: Ching Huang
> > ---
>
> Hi Ching,
> please look at the comments below -
>
> > }
> > @@ -1039,7 +1147,60 @@ static void arcmsr_done4abort_postqueue(
> > error = (flag_ccb & ARCMSR_CCBREPLY_FLAG_ERROR_MODE1) ?
> > true : false;
> > arcmsr_drain_donequeue(acb, pCCB, error);
> > }
> > - }
> > + }
> > + break;
> > + case ACB_ADAPTER_TYPE_D: {
> > + struct MessageUnit_D *pmu = acb->pmuD;
> > + uint32_t ccb_cdb_phy, outbound_write_pointer;
> > + uint32_t doneq_index, index_stripped, addressLow, residual;
> > + bool error;
> > + struct CommandControlBlock *pCCB;
>
> I have noticed this^ in this driver already before. Sometimes it makes sense
> when a variable is declared in a 'case' block but often it is just
> a waste of space. In this function this is the third 'bool error' declared.
> Is there a reason for this style (this function is not the worst case) ?
Yea, there is many variable are duplicate declaration, I will clean it up.
>
> > + outbound_write_pointer = pmu->done_qbuffer[0].addressLow + 1;
> > + doneq_index = pmu->doneq_index;
> > + residual = atomic_read(&acb->ccboutstandingcount);
> > + for (i = 0; i < residual; i++) {
> > + while ((doneq_index & 0xFFF) !=
> > + (outbound_write_pointer & 0xFFF)) {
> > + if (doneq_index & 0x4000) {
> > + index_stripped = doneq_index & 0xFFF;
> > + index_stripped += 1;
> > + index_stripped %=
> > + ARCMSR_MAX_ARC1214_DONEQUEUE;
> > + pmu->doneq_index = index_stripped ?
> > + (index_stripped | 0x4000) :
> > + (index_stripped + 1);
> > + } else {
> > + index_stripped = doneq_index;
> > + index_stripped += 1;
> > + index_stripped %=
> > + ARCMSR_MAX_ARC1214_DONEQUEUE;
> > + pmu->doneq_index = index_stripped ?
> > + index_stripped :
> > + ((index_stripped | 0x4000) + 1);
> > + }
> > + doneq_index = pmu->doneq_index;
> > + addressLow = pmu->done_qbuffer[doneq_index &
> > + 0xFFF].addressLow;
> > + ccb_cdb_phy = (addressLow & 0xFFF0);
> > + pARCMSR_CDB = (struct ARCMSR_CDB *)
> > + (acb->vir2phy_offset + ccb_cdb_phy);
> > + pCCB = container_of(pARCMSR_CDB,
> > + struct CommandControlBlock, arcmsr_cdb);
> > + error = (addressLow &
> > + ARCMSR_CCBREPLY_FLAG_ERROR_MODE1) ?
> > + true : false;
> > + arcmsr_drain_donequeue(acb, pCCB, error);
> > + writel(doneq_index,
> > pmu->outboundlist_read_pointer);
> > + }
> > + mdelay(10);
> > + outbound_write_pointer =
> > + pmu->done_qbuffer[0].addressLow + 1;
> > + doneq_index = pmu->doneq_index;
> > + }
> > + pmu->postq_index = 0;
> > + pmu->doneq_index = 0x40FF;
> > + }
> > + break;
> > }
> > }
> ...
>
> >
> >
> > @@ -1256,6 +1424,38 @@ static void arcmsr_post_ccb(struct Adapt
> > writel(ccb_post_stamp, &phbcmu->inbound_queueport_low);
> > }
> > }
> > + break;
> > + case ACB_ADAPTER_TYPE_D: {
> > + struct MessageUnit_D *pmu = acb->pmuD;
> > + u16 index_stripped;
> > + u16 postq_index;
u16 postq_index, toggle;
> > + unsigned long flags;
> > + struct InBound_SRB *pinbound_srb;
> > +
> > + spin_lock_irqsave(&acb->postq_lock, flags);
> > + postq_index = pmu->postq_index;
> > + pinbound_srb = (struct InBound_SRB
> > *)&(pmu->post_qbuffer[postq_index & 0xFF]);
> > + pinbound_srb->addressHigh = dma_addr_hi32(cdb_phyaddr);
> > + pinbound_srb->addressLow = dma_addr_lo32(cdb_phyaddr);
> > + pinbound_srb->length = ccb->
[PATCH] MAINTAINERS: Add irqchip DT bindings doc path to IRQCHIP DRIVERS section
Signed-off-by: Geert Uytterhoeven --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index 704be0f07f86..f76af4d18ee5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4989,6 +4989,7 @@ L:linux-kernel@vger.kernel.org S: Maintained T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core T: git git://git.infradead.org/users/jcooper/linux.git irqchip/core +F: Documentation/devicetree/bindings/interrupt-controller/ F: drivers/irqchip/ IRQ DOMAINS (IRQ NUMBER MAPPING LIBRARY) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: use IORESOURCE_REG resource type for non-translatable addresses in DT
On 08/27/2014 09:24 PM, Bjorn Andersson wrote: > On Tue, Jul 29, 2014 at 11:06 PM, Stephen Boyd wrote: >> On 07/29, Rob Herring wrote: > [..] >>> >>> You might as well do of_property_read_u32 in the below example. >>> >> >> Fair enough. The example is probably too simple. Things are >> sometimes slightly more complicated and a simple >> of_property_read_u32() isn't going to work in the case of >> multiple reg values or when reg-names is in play. >> > > But do we have such cases in the Qualcomm PMICs? yes, we have few - rtc, iadc and partially regulators. > > The only case I've hit so far is for gpios and mpps, where it feels > like reg should be base, size and not simply base reg of first gpio - > but that's a different thing. > > Also, so far it seems like most drivers just code the base address in > the driver, as we have very specific compatibles. > > > How about we stop trying so hard to make this "perfect" and just merge > something close to Josh's original proposal and ignore this problem? > Currently all we're doing is delaying any possibility of getting > drivers for the individual blocks merged. > If we have the dt bindings require the reg to be there, we can discuss > and change this all we want later! I totally agree with you, the latest PMIC version of the patches sent two weeks ago follow this assumption but I didn't receive any ack/reviewed-by from anyone and we miss the merge window. :( -- regards, Stan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: randconfig build error with next-20140826, in Documentation/video4linux
On Wed, Aug 27, 2014 at 10:33:46AM -0700, Jim Davis wrote: > On Wed, Aug 27, 2014 at 3:58 AM, Sudip Mukherjee > wrote: > > > Hi, > > I tried to build next-20140826 with your given config file . But for me > > everything was fine. > > Well, you should be able to reproduce it. Do these steps work for you? > > jim@krebstar:~/linux2$ git checkout next-20140826 > HEAD is now at 1c9e4561f3b2... Add linux-next specific files for 20140826 > jim@krebstar:~/linux2$ git clean -fdx > jim@krebstar:~/linux2$ cp ~/randconfig-1409069188.txt .config > jim@krebstar:~/linux2$ make oldconfig > HOSTCC scripts/basic/fixdep > HOSTCC scripts/kconfig/conf.o > SHIPPED scripts/kconfig/zconf.tab.c > SHIPPED scripts/kconfig/zconf.lex.c > SHIPPED scripts/kconfig/zconf.hash.c > HOSTCC scripts/kconfig/zconf.tab.o > HOSTLD scripts/kconfig/conf > scripts/kconfig/conf --oldconfig Kconfig > # > # configuration written to .config > # > jim@krebstar:~/linux2$ make -j4 >buildlog.txt 2>&1 > jim@krebstar:~/linux2$ grep ERROR buildlog.txt > ERROR: "vb2_ops_wait_finish" > [Documentation/video4linux/v4l2-pci-skeleton.ko] undefined! > > (followed by many more similar lines). yes , it worked. thanks . i was missing the oldconfig . thanks sudip -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply
Some Exynos SoCs have a separate regulator controlling a
Boost 5V supply which goes as input for VBUS regulator.
So adding a control for the same in driver, to enable
vbus supply on the port.
Signed-off-by: Vivek Gautam
---
drivers/phy/phy-exynos5-usbdrd.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index 685c108..a6d0cb7 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -176,6 +176,7 @@ struct exynos5_usbdrd_phy {
u32 extrefclk;
struct clk *ref_clk;
struct regulator *vbus;
+ struct regulator *vbus_boost;
};
static inline
@@ -457,11 +458,19 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
clk_prepare_enable(phy_drd->ref_clk);
/* Enable VBUS supply */
+ if (phy_drd->vbus_boost) {
+ ret = regulator_enable(phy_drd->vbus_boost);
+ if (ret) {
+ dev_err(phy_drd->dev,
+ "Failed to enable VBUS boost supply\n");
+ goto fail_vbus;
+ }
+ }
if (phy_drd->vbus) {
ret = regulator_enable(phy_drd->vbus);
if (ret) {
dev_err(phy_drd->dev, "Failed to enable VBUS supply\n");
- goto fail_vbus;
+ goto fail_vbus_boost;
}
}
@@ -470,6 +479,9 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
return 0;
+fail_vbus_boost:
+ if (phy_drd->vbus_boost)
+ regulator_disable(phy_drd->vbus_boost);
fail_vbus:
clk_disable_unprepare(phy_drd->ref_clk);
if (!IS_ERR(phy_drd->pipeclk))
@@ -493,6 +505,8 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
/* Disable VBUS supply */
if (phy_drd->vbus)
regulator_disable(phy_drd->vbus);
+ if (phy_drd->vbus_boost)
+ regulator_disable(phy_drd->vbus_boost);
clk_disable_unprepare(phy_drd->ref_clk);
if (!IS_ERR(phy_drd->pipeclk))
@@ -645,7 +659,7 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
break;
}
- /* Get Vbus regulator */
+ /* Get Vbus regulators */
phy_drd->vbus = devm_regulator_get(dev, "vbus");
if (IS_ERR(phy_drd->vbus)) {
ret = PTR_ERR(phy_drd->vbus);
@@ -655,6 +669,15 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
dev_warn(dev, "Failed to get VBUS supply regulator\n");
phy_drd->vbus = NULL;
}
+ phy_drd->vbus_boost = devm_regulator_get(dev, "vbus-boost");
+ if (IS_ERR(phy_drd->vbus_boost)) {
+ ret = PTR_ERR(phy_drd->vbus_boost);
+ if (ret == -EPROBE_DEFER)
+ return ret;
+
+ dev_warn(dev, "Failed to get VBUS boost supply regulator\n");
+ phy_drd->vbus_boost = NULL;
+ }
dev_vdbg(dev, "Creating usbdrd_phy phy\n");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7
This USB 3.0 PHY controller is also present on Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 for this driver. Signed-off-by: Vivek Gautam --- drivers/phy/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig index 0dd7427..c3bc380 100644 --- a/drivers/phy/Kconfig +++ b/drivers/phy/Kconfig @@ -186,7 +186,7 @@ config PHY_EXYNOS5250_USB2 config PHY_EXYNOS5_USBDRD tristate "Exynos5 SoC series USB DRD PHY driver" - depends on ARCH_EXYNOS5 && OF + depends on (ARCH_EXYNOS5 || ARCH_EXYNOS7) && OF depends on HAS_IOMEM depends on USB_DWC3_EXYNOS select GENERIC_PHY -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] usb: dwc3/phy-exynos5-usbdrd: Extend support to Exynos7
Adding required support for clocks and additional VBUS regulators to enable USB 3.0 support on Exynos7 SoC. This series depends for ACRH_EXYNOS7 support on following series: [PATCH 00/14] Support 64bit Cortex A57 based Exynos7 SoC https://www.mail-archive.com/devicetree@vger.kernel.org/msg39392.html The series is based on usb-next branch. Vivek Gautam (5): usb: dwc3: exynos: Add support for SCLK present on Exynos7 phy: exynos5-usbdrd: Add pipe-clk and utmi-clk support phy: exynos5-usbdrd: Add facility for VBUS-BOOST-5V supply usb: dwc3: Adding Kconfig dependency for Exynos7 phy: exynos5-usbdrd: Adding Kconfig dependency for Exynos7 .../devicetree/bindings/phy/samsung-phy.txt|4 ++ drivers/phy/Kconfig|2 +- drivers/phy/phy-exynos5-usbdrd.c | 51 +++- drivers/usb/dwc3/Kconfig |2 +- drivers/usb/dwc3/dwc3-exynos.c | 16 ++ 5 files changed, 71 insertions(+), 4 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] usb: dwc3: exynos: Add support for SCLK present on Exynos7
Exynos7 also has a separate special gate clock going to the IP
apart from the usual AHB clock. So add support for the same.
Signed-off-by: Vivek Gautam
---
drivers/usb/dwc3/dwc3-exynos.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/usb/dwc3/dwc3-exynos.c b/drivers/usb/dwc3/dwc3-exynos.c
index f9fb8ad..bab6395 100644
--- a/drivers/usb/dwc3/dwc3-exynos.c
+++ b/drivers/usb/dwc3/dwc3-exynos.c
@@ -35,6 +35,7 @@ struct dwc3_exynos {
struct device *dev;
struct clk *clk;
+ struct clk *sclk;
struct regulator*vdd33;
struct regulator*vdd10;
};
@@ -141,10 +142,17 @@ static int dwc3_exynos_probe(struct platform_device *pdev)
return -EINVAL;
}
+ /* Exynos7 has a special gate clock going to this IP */
+ exynos->sclk = devm_clk_get(dev, "usbdrd30_sclk");
+ if (IS_ERR(exynos->sclk))
+ dev_warn(dev, "couldn't get sclk\n");
+
exynos->dev = dev;
exynos->clk = clk;
clk_prepare_enable(exynos->clk);
+ if (!IS_ERR(exynos->sclk))
+ clk_prepare_enable(exynos->sclk);
exynos->vdd33 = devm_regulator_get(dev, "vdd33");
if (IS_ERR(exynos->vdd33)) {
@@ -187,6 +195,8 @@ err4:
err3:
regulator_disable(exynos->vdd33);
err2:
+ if (!IS_ERR(exynos->sclk))
+ clk_disable_unprepare(exynos->sclk);
clk_disable_unprepare(clk);
return ret;
}
@@ -199,6 +209,8 @@ static int dwc3_exynos_remove(struct platform_device *pdev)
platform_device_unregister(exynos->usb2_phy);
platform_device_unregister(exynos->usb3_phy);
+ if (!IS_ERR(exynos->sclk))
+ clk_disable_unprepare(exynos->sclk);
clk_disable_unprepare(exynos->clk);
regulator_disable(exynos->vdd33);
@@ -220,6 +232,8 @@ static int dwc3_exynos_suspend(struct device *dev)
{
struct dwc3_exynos *exynos = dev_get_drvdata(dev);
+ if (!IS_ERR(exynos->sclk))
+ clk_disable(exynos->sclk);
clk_disable(exynos->clk);
regulator_disable(exynos->vdd33);
@@ -245,6 +259,8 @@ static int dwc3_exynos_resume(struct device *dev)
}
clk_enable(exynos->clk);
+ if (!IS_ERR(exynos->sclk))
+ clk_enable(exynos->sclk);
/* runtime set active to reflect active state. */
pm_runtime_disable(dev);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] phy: exynos5-usbdrd: Add pipe-clk and utmi-clk support
Exynos7 SoC has now separate gate control for 125MHz pipe3 phy
clock, as well as 60MHz utmi phy clock.
So get the same and control in the phy-exynos5-usbdrd driver.
Signed-off-by: Vivek Gautam
---
.../devicetree/bindings/phy/samsung-phy.txt|4
drivers/phy/phy-exynos5-usbdrd.c | 24
2 files changed, 28 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index 7a6feea..b64d616 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -135,6 +135,10 @@ Required properties:
PHY operations, associated by phy name. It is used to
determine bit values for clock settings register.
For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+ - optional clocks: Next gen Exynos SoCs have following additional
+ gate clocks available:
+ - phy_pipe: for PIPE3 phy
+ - phy_utmi: for UTMI+ phy
- samsung,pmu-syscon: phandle for PMU system controller interface, used to
control pmu registers for power isolation.
- #phy-cells : from the generic PHY bindings, must be 1;
diff --git a/drivers/phy/phy-exynos5-usbdrd.c b/drivers/phy/phy-exynos5-usbdrd.c
index b05302b..685c108 100644
--- a/drivers/phy/phy-exynos5-usbdrd.c
+++ b/drivers/phy/phy-exynos5-usbdrd.c
@@ -148,6 +148,8 @@ struct exynos5_usbdrd_phy_drvdata {
* @dev: pointer to device instance of this platform device
* @reg_phy: usb phy controller register memory base
* @clk: phy clock for register access
+ * @pipeclk: clock for pipe3 phy
+ * @utmiclk: clock for utmi+ phy
* @drv_data: pointer to SoC level driver data structure
* @phys[]: array for 'EXYNOS5_DRDPHYS_NUM' number of PHY
* instances each with its 'phy' and 'phy_cfg'.
@@ -161,6 +163,8 @@ struct exynos5_usbdrd_phy {
struct device *dev;
void __iomem *reg_phy;
struct clk *clk;
+ struct clk *pipeclk;
+ struct clk *utmiclk;
const struct exynos5_usbdrd_phy_drvdata *drv_data;
struct phy_usb_instance {
struct phy *phy;
@@ -446,6 +450,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
dev_dbg(phy_drd->dev, "Request to power_on usbdrd_phy phy\n");
+ if (!IS_ERR(phy_drd->utmiclk))
+ clk_prepare_enable(phy_drd->utmiclk);
+ if (!IS_ERR(phy_drd->pipeclk))
+ clk_prepare_enable(phy_drd->pipeclk);
clk_prepare_enable(phy_drd->ref_clk);
/* Enable VBUS supply */
@@ -464,6 +472,10 @@ static int exynos5_usbdrd_phy_power_on(struct phy *phy)
fail_vbus:
clk_disable_unprepare(phy_drd->ref_clk);
+ if (!IS_ERR(phy_drd->pipeclk))
+ clk_disable_unprepare(phy_drd->pipeclk);
+ if (!IS_ERR(phy_drd->utmiclk))
+ clk_disable_unprepare(phy_drd->utmiclk);
return ret;
}
@@ -483,6 +495,10 @@ static int exynos5_usbdrd_phy_power_off(struct phy *phy)
regulator_disable(phy_drd->vbus);
clk_disable_unprepare(phy_drd->ref_clk);
+ if (!IS_ERR(phy_drd->pipeclk))
+ clk_disable_unprepare(phy_drd->pipeclk);
+ if (!IS_ERR(phy_drd->utmiclk))
+ clk_disable_unprepare(phy_drd->utmiclk);
return 0;
}
@@ -581,6 +597,14 @@ static int exynos5_usbdrd_phy_probe(struct platform_device
*pdev)
return PTR_ERR(phy_drd->clk);
}
+ phy_drd->pipeclk = devm_clk_get(dev, "phy_pipe");
+ if (IS_ERR(phy_drd->pipeclk))
+ dev_warn(dev, "Failed to get pipe3 phy operational clock\n");
+
+ phy_drd->utmiclk = devm_clk_get(dev, "phy_utmi");
+ if (IS_ERR(phy_drd->utmiclk))
+ dev_warn(dev, "Failed to get utmi phy operational clock\n");
+
phy_drd->ref_clk = devm_clk_get(dev, "ref");
if (IS_ERR(phy_drd->ref_clk)) {
dev_err(dev, "Failed to get reference clock of usbdrd phy\n");
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] usb: dwc3: Adding Kconfig dependency for Exynos7
The Exynos-DWC3 USB 3.0 DRD controller is also present on Exynos7 platform, so adding the dependency on ARCH_EXYNOS7 for this driver. Signed-off-by: Vivek Gautam --- drivers/usb/dwc3/Kconfig |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig index 785510a..e235894 100644 --- a/drivers/usb/dwc3/Kconfig +++ b/drivers/usb/dwc3/Kconfig @@ -55,7 +55,7 @@ config USB_DWC3_OMAP config USB_DWC3_EXYNOS tristate "Samsung Exynos Platform" - depends on ARCH_EXYNOS || COMPILE_TEST + depends on (ARCH_EXYNOS || ARCH_EXYNOS7) || COMPILE_TEST default USB_DWC3 help Recent Exynos5 SoCs ship with one DesignWare Core USB3 IP inside, -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ARM: dts: Add shmobile platform device tree bindings documentation
Add Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings Documentation, listing supported SoCs and boards. This allows to use checkpatch to validate DTSes referring to Renesas shmobile SoCs, and boards containing those SoCs. Signed-off-by: Geert Uytterhoeven --- v2: - Drop RFC - Move sh7372/sh73a0 up, before r8a73a4 - Add r8a7793/Gose - Drop bogus EMEV2 before KZM9D board name - Drop armadillo-reference, as it's on its way out --- Documentation/devicetree/bindings/arm/shmobile.txt | 71 ++ 1 file changed, 71 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/shmobile.txt diff --git a/Documentation/devicetree/bindings/arm/shmobile.txt b/Documentation/devicetree/bindings/arm/shmobile.txt new file mode 100644 index ..5d1c5c0085dc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/shmobile.txt @@ -0,0 +1,71 @@ +Renesas SH-Mobile, R-Mobile, and R-Car Platform Device Tree Bindings + + +SoCs: + + - Emma Mobile EV2 +compatible = "renesas,emev2" + - RZ/A1H (R7S72100) +compatible = "renesas,r7s72100" + - SH-Mobile AP4 (R8A73720/SH7372) +compatible = "renesas,sh7372" + - SH-Mobile AG5 (R8A73A00/SH73A0) +compatible = "renesas,sh73a0" + - R-Mobile APE6 (R8A73A40) +compatible = "renesas,r8a73a4" + - R-Mobile A1 (R8A77400) +compatible = "renesas,r8a7740" + - R-Car M1A (R8A77781) +compatible = "renesas,r8a7778" + - R-Car H1 (R8A77790) +compatible = "renesas,r8a7779" + - R-Car H2 (R8A77900) +compatible = "renesas,r8a7790" + - R-Car M2-W (R8A77910) +compatible = "renesas,r8a7791" + - R-Car V2H (R8A77920) +compatible = "renesas,r8a7792" + - R-Car M2-N (R8A77930) +compatible = "renesas,r8a7793" + - R-Car E2 (R8A77940) +compatible = "renesas,r8a7794" + + +Boards: + + - Alt +compatible = "renesas,alt", "renesas,r8a7794" + - APE6-EVM +compatible = "renesas,ape6evm", "renesas,r8a73a4" + - APE6-EVM - Reference Device Tree Implementation +compatible = "renesas,ape6evm-reference", "renesas,r8a73a4" + - Atmark Techno Armadillo-800 EVA +compatible = "renesas,armadillo800eva" + - BOCK-W +compatible = "renesas,bockw", "renesas,r8a7778" + - BOCK-W - Reference Device Tree Implementation +compatible = "renesas,bockw-reference", "renesas,r8a7778" + - Genmai (RTK772100BC0BR) +compatible = "renesas,genmai", "renesas,r7s72100" + - Gose +compatible = "renesas,gose", "renesas,r8a7793" + - Henninger +compatible = "renesas,henninger", "renesas,r8a7791" + - Koelsch (RTP0RC7791SEB00010S) +compatible = "renesas,koelsch", "renesas,r8a7791" + - KZM9D +compatible = "renesas,kzm9d", "renesas,emev2" + - KZM-A9-GT +compatible = "renesas,kzm9g", "renesas,sh73a0" + - KZM-A9-GT - Reference Device Tree Implementation +compatible = "renesas,kzm9g-reference", "renesas,sh73a0" + - Lager (RTP0RC7790SEB00010S) +compatible = "renesas,lager", "renesas,r8a7790" + - Mackerel (R0P7372LC0016RL, AP4 EVM 2nd) +compatible = "renesas,mackerel" + - Marzen +compatible = "renesas,marzen", "renesas,r8a7779" + +Note: Reference Device Tree Implementations are temporary implementations + to ease the migration from platform devices to Device Tree, and are + intended to be removed in the future. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 00/21] Support ext4 on NV-DIMMs
On 08/27/2014 06:45 AM, Matthew Wilcox wrote: > One of the primary uses for NV-DIMMs is to expose them as a block device > and use a filesystem to store files on the NV-DIMM. While that works, > it currently wastes memory and CPU time buffering the files in the page > cache. We have support in ext2 for bypassing the page cache, but it > has some races which are unfixable in the current design. This series > of patches rewrite the underlying support, and add support for direct > access to ext4. > > Note that patch 6/21 has been included in > https://git.kernel.org/cgit/linux/kernel/git/viro/vfs.git/log/?h=for-next-candidate > Matthew hi Could you please push this to the regular or a new public tree? (Old versions are at: https://github.com/01org/prd) Thanks Boaz > This iteration of the patchset rebases to 3.17-rc2, changes the page fault > locking, fixes a couple of bugs and makes a few other minor changes. > > - Move the calculation of the maximum size available at the requested >location from the ->direct_access implementations to bdev_direct_access() > - Fix a comment typo (Ross Zwisler) > - Check that the requested length is positive in bdev_direct_access(). If >it is not, assume that it's an errno, and just return it. > - Fix some whitespace issues flagged by checkpatch > - Added the Acked-by responses from Kirill that I forget in the last round > - Added myself to MAINTAINERS for DAX > - Fixed compilation with !CONFIG_DAX (Vishal Verma) > - Revert the locking in the page fault handler back to an earlier version. >If we hit the race that we were trying to protect against, we will leave >blocks allocated past the end of the file. They will be removed on file >removal, the next truncate, or fsck. > > > Matthew Wilcox (20): > axonram: Fix bug in direct_access > Change direct_access calling convention > Fix XIP fault vs truncate race > Allow page fault handlers to perform the COW > Introduce IS_DAX(inode) > Add copy_to_iter(), copy_from_iter() and iov_iter_zero() > Replace XIP read and write with DAX I/O > Replace ext2_clear_xip_target with dax_clear_blocks > Replace the XIP page fault handler with the DAX page fault handler > Replace xip_truncate_page with dax_truncate_page > Replace XIP documentation with DAX documentation > Remove get_xip_mem > ext2: Remove ext2_xip_verify_sb() > ext2: Remove ext2_use_xip > ext2: Remove xip.c and xip.h > Remove CONFIG_EXT2_FS_XIP and rename CONFIG_FS_XIP to CONFIG_FS_DAX > ext2: Remove ext2_aops_xip > Get rid of most mentions of XIP in ext2 > xip: Add xip_zero_page_range > brd: Rename XIP to DAX > > Ross Zwisler (1): > ext4: Add DAX functionality > > Documentation/filesystems/Locking | 3 - > Documentation/filesystems/dax.txt | 91 +++ > Documentation/filesystems/ext4.txt | 2 + > Documentation/filesystems/xip.txt | 68 - > MAINTAINERS| 6 + > arch/powerpc/sysdev/axonram.c | 19 +- > drivers/block/Kconfig | 13 +- > drivers/block/brd.c| 26 +- > drivers/s390/block/dcssblk.c | 21 +- > fs/Kconfig | 21 +- > fs/Makefile| 1 + > fs/block_dev.c | 40 +++ > fs/dax.c | 497 > + > fs/exofs/inode.c | 1 - > fs/ext2/Kconfig| 11 - > fs/ext2/Makefile | 1 - > fs/ext2/ext2.h | 10 +- > fs/ext2/file.c | 45 +++- > fs/ext2/inode.c| 38 +-- > fs/ext2/namei.c| 13 +- > fs/ext2/super.c| 53 ++-- > fs/ext2/xip.c | 91 --- > fs/ext2/xip.h | 26 -- > fs/ext4/ext4.h | 6 + > fs/ext4/file.c | 49 +++- > fs/ext4/indirect.c | 18 +- > fs/ext4/inode.c| 51 ++-- > fs/ext4/namei.c| 10 +- > fs/ext4/super.c| 39 ++- > fs/open.c | 5 +- > include/linux/blkdev.h | 6 +- > include/linux/fs.h | 49 +++- > include/linux/mm.h | 1 + > include/linux/uio.h| 3 + > mm/Makefile| 1 - > mm/fadvise.c | 6 +- > mm/filemap.c | 6 +- > mm/filemap_xip.c | 483 --- > mm/iov_iter.c | 237 -- > mm/madvise.c | 2 +- > mm/memory.c| 33 ++- > 41 files changed, 1229 insertions(+), 873 deletions(-) > create mode 100644 Documentation/filesystems/dax.txt > delete mode 100644 Documentation/filesystems/xip.txt > create mode 100644 fs/dax.c > delete mode 100644 fs/ext2/xip.c > delete mod
Dear Webmail User,
Dear Webmail User, This is to inform you that you have exceeded your quota limit of 325MB in our database e-mail and you need to increase your quota limit of email because in less than 48hours your e-mail will be disabled. Increase the share of e-mail limit and continue to use your webmail account. To increase your quota limit of email to 2.2GB, click or copy the below link into your broswer now and fill your detail Click Link: http://www.jotform.me/form/42389052998470 Thank You. Copyright © 2014 Taiwan Webmail Help Desk Administrator All rights reserved. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/1]: Update platform-drivers-x86 maintainer and tree
Hi All, Per my discussion with Matthew, I have agreed to take on maintenance of platform-drivers-x86. I have setup a new tree: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git It currently has the one revert patch I know is pending for this branch in the for-linus branch and I've tagged it for-linus-3.17-rc2. However, as I'll be traveling for the next few days without much access to email, I thought it best not to send my first pull request and run.. Instead, I'm including the MAINTAINER update here, for Matthew mostly, and a preview of what I have queued for Linus for early next week. Thanks, Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: Update platform-drivers-x86 maintainer and tree
From: Darren Hart Update the general entry for drivers/platform/x86 with myself as maintainer and point to my tree. Leave Matthew Garrett as maintainer of the two drivers called out specifically elsewhere in MAINTAINERS. Signed-off-by: Darren Hart Cc: Matthew Garrett --- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 1ff06de..b700f5f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -10057,9 +10057,9 @@ F: Documentation/x86/ F: arch/x86/ X86 PLATFORM DRIVERS -M: Matthew Garrett +M: Darren Hart L: platform-driver-...@vger.kernel.org -T: git git://cavan.codon.org.uk/platform-drivers-x86.git +T: git git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git S: Maintained F: drivers/platform/x86/ -- 2.1.0.rc1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3.17 REGRESSION FIX] Revert "ideapad-laptop: Disable touchpad interface on Yoga models"
On Mon, Aug 25, 2014 at 12:00:13PM +0200, Hans de Goede wrote: > I've received a bug report from a user that the touchpad control part > of the ideapad-laptop ACPI interface does work for him on his > "Lenovo Yoga 2 13", and that this patch causes a regression for him. > > Since it did not work for me when I had a "Lenovo Yoga 2 11" in my own > hands (loaned from a friend). It seems that this is a bit of hit and miss. > > Since the result of having a false positive here is worse, then the minor > annoyance of a false touchpad disabled messages being shown after suspend / > resume on models (or is it firmware versions?) where the interface does not > work, simply revert the patch. > > This reverts commit f79a901331a823ae370584b15cd39dd110b95a0a. > > Reported-by: GOESSEL Guillaume > Signed-off-by: Hans de Goede Queued: git://git.infradead.org/users/dvhart/linux-platform-drivers-x86.git for-linus I'll send the pull request next week after some weekend travel. Thanks, -- Darren Hart Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 3/4] zram: zram memory size limitation
On Wed, Aug 27, 2014 at 04:28:19PM +0900, Minchan Kim wrote:
> On Wed, Aug 27, 2014 at 02:04:38PM +0900, Joonsoo Kim wrote:
> > On Wed, Aug 27, 2014 at 11:51:32AM +0900, Minchan Kim wrote:
> > > Hey Joonsoo,
> > >
> > > On Wed, Aug 27, 2014 at 10:26:11AM +0900, Joonsoo Kim wrote:
> > > > Hello, Minchan and David.
> > > >
> > > > On Tue, Aug 26, 2014 at 08:22:29AM -0400, David Horner wrote:
> > > > > On Tue, Aug 26, 2014 at 3:55 AM, Minchan Kim
> > > > > wrote:
> > > > > > Hey Joonsoo,
> > > > > >
> > > > > > On Tue, Aug 26, 2014 at 04:37:30PM +0900, Joonsoo Kim wrote:
> > > > > >> On Mon, Aug 25, 2014 at 09:05:55AM +0900, Minchan Kim wrote:
> > > > > >> > @@ -513,6 +540,14 @@ static int zram_bvec_write(struct zram
> > > > > >> > *zram, struct bio_vec *bvec, u32 index,
> > > > > >> > ret = -ENOMEM;
> > > > > >> > goto out;
> > > > > >> > }
> > > > > >> > +
> > > > > >> > + if (zram->limit_pages &&
> > > > > >> > + zs_get_total_pages(meta->mem_pool) >
> > > > > >> > zram->limit_pages) {
> > > > > >> > + zs_free(meta->mem_pool, handle);
> > > > > >> > + ret = -ENOMEM;
> > > > > >> > + goto out;
> > > > > >> > + }
> > > > > >> > +
> > > > > >> > cmem = zs_map_object(meta->mem_pool, handle, ZS_MM_WO);
> > > > > >>
> > > > > >> Hello,
> > > > > >>
> > > > > >> I don't follow up previous discussion, so I could be wrong.
> > > > > >> Why this enforcement should be here?
> > > > > >>
> > > > > >> I think that this has two problems.
> > > > > >> 1) alloc/free happens unnecessarilly if we have used memory over
> > > > > >> the
> > > > > >> limitation.
> > > > > >
> > > > > > True but firstly, I implemented the logic in zsmalloc, not zram but
> > > > > > as I described in cover-letter, it's not a requirement of zsmalloc
> > > > > > but zram so it should be in there. If every user want it in future,
> > > > > > then we could move the function into zsmalloc. That's what we
> > > > > > concluded in previous discussion.
> > > >
> > > > Hmm...
> > > > Problem is that we can't avoid these unnecessary overhead in this
> > > > implementation. If we can implement this feature in zram efficiently,
> > > > it's okay. But, I think that current form isn't.
> > >
> > >
> > > If we can add it in zsmalloc, it would be more clean and efficient
> > > for zram but as I said, at the moment, I didn't want to put zram's
> > > requirement into zsmalloc because to me, it's weird to enforce max
> > > limit to allocator. It's client's role, I think.
> >
> > AFAIK, many kinds of pools such as thread-pool or memory-pool have
> > their own limit. It's not weird for me.
>
> Actually I don't know what is pool allocator but things you mentioned
> is basically used to gaurantee *new* thread/memory, not limit although
> it would implement limit.
>
> Another question, why do you think zsmalloc is pool allocator?
> IOW, What logic makes you think it's pool allocator?
In fact, it is not pool allocator for now. But, it looks like pool
allocator because it is used only for one zram device. If there are
many zram devices, there are many zs_pool and their memory cannot be
shared. It is totally isolated each other. We can easily make it
actual pool allocator or impose memory usage limit on it with this
property. This make me think that zsmalloc is better place to limit
memory usage.
Anyway, I don't have strong objection to current implementation. You
can fix it later when it turn out to be real problem.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Tony Lindgren | 2014-08-27 13:23:14 [-0700]: >> which means I just enable DMA mode in UART and disable it. No DMA >> operations were performed. >> With this change I see a lost character now and then which means the >> UART-IP goes into off and loses its context. Good. However I don't see >> core off anymore. This looks like a bug beyond my responsibilities :) > >OK, that sounds like a bug still lurking around somewhere. The core >domain won't hit idle if there are any hardware pieces blocking. Yes. >> I added code to cancel & and start DMA transfers in runtime suspend >> callbacks. > >Do you mean just the OMAP_UART_SCR_DMAMODE_CTL related code, or >also the dmaengine calls? dmaengine calls are unused because up.dma is not assigned. It is basically like you wouldn't have the dma properties in the devicetree. And while in that non-DMA mode I just set and unset the DMAMODE_CTL + DMAMODE_1 bits in the SCR register. Nothing else. Based on some testing I just did, DMAMODE_CTL does not make the difference. DMAMODE_CTL + DMAMODE_1 does. >> However core-off with DMA won't work. I think we could document this in >> the binding document. What do you think? > >There should not be such a limitation though. Maybe dump out the values >of cm_idlest_per and cm_idlest1_core for working and failing off idle >cases and see what the difference is? I can't follow here. This is the working case: usbhost_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:109,RET:22,INA:71,ON:203,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:137,RET:126,INA:0,ON:264,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:383,RET:861,INA:0,ON:1245,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:311,RET:889,INA:44,ON:1245,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:311,RET:889,INA:44,ON:1245,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm->usbhost_pwrdm (0) sgx_clkdm->sgx_pwrdm (0) per_clkdm->per_pwrdm (15) cam_clkdm->cam_pwrdm (0) dss_clkdm->dss_pwrdm (1) d2d_clkdm->core_pwrdm (0) iva2_clkdm->iva2_pwrdm (0) mpu_clkdm->mpu_pwrdm (0) core_l4_clkdm->core_pwrdm (20) core_l3_clkdm->core_pwrdm (1) neon_clkdm->neon_pwrdm (0) non-working: usbhost_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:253,RET:159,INA:0,ON:413,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:135,RET:242,INA:35,ON:413,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:135,RET:242,INA:35,ON:413,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm->usbhost_pwrdm (0) sgx_clkdm->sgx_pwrdm (0) per_clkdm->per_pwrdm (15) cam_clkdm->cam_pwrdm (0) dss_clkdm->dss_pwrdm (1) d2d_clkdm->core_pwrdm (0) iva2_clkdm->iva2_pwrdm (0) mpu_clkdm->mpu_pwrdm (0) core_l4_clkdm->core_pwrdm (21) core_l3_clkdm->core_pwrdm (1) neon_clkdm->neon_pwrdm (0) so per_pwrdm and core_pwrdm remain on and I guess the former is where the UART sits. >It could be the either the dma or the uart hardware blocking. I guess >it could be also an issue with runtime pm use somewhere. So I just toggle the two DMA bits in SCR and the UART seems to block since the DMA hw is not involved. Reading SCR back says that those bits are not set. To use DMA you don't have to enable it in SCR register you can also use the FCR register. The manual says that you can only write this DMA enable bit in the FCR register if the baud clock is not running. And guess what: same thing: I only *toggle* the DMA enable bit here (it remains 0 later) and the core won't hit idle. Same effect if I toggle this bit while the baud clock is running (the manual says that this bit can only be written if the baud clock is not running). Seems like the UART is following its own specification and it remains blocking once the DMA was enabled. It would be nice if someone from the UART-IP team could ACK this. Bah. Does it make sense to use runtime-PM if we can't hit core-off? I'm thinking to add a printk once dma is enabled says that runtime-pm is switched off. >Tony Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] regulator: max77802: set opmode to normal if off is read from hw
On Thu, Aug 28, 2014 at 12:44:18AM +0200, Javier Martinez Canillas wrote: > On Wed, Aug 27, 2014 at 11:03 PM, Tomasz Figa wrote: > This is the case for Chromebooks as well but the solution implemented > in the downstream Chrome OS 3.8 kernel is what Tomasz suggested *sigh* This is not what you were describing, though most of what you then go on to say doesn't correspond to the issue Tomasz was describing. > Yes, AFAIK the bootloader (none of them because Chromebooks use two > chained U-boots) change the regulators default opmode so once is set > to OFF on .disable, that value is preserved on warm reboot. This made > sense with the Chrome OS kernel since the kernel always set the opmode > defined in the "regulator-op-mode" DT property and did not relied on > the bootloader to set the most efficient default opmode. I'm sorry but this is just really unclear. Does the bootloader change the mode or does it not change the mode? You start off saying that the bootloader does change the mode, then go on to say that it doesn't and that the system relies on Linux changing the mode (which is consistent with what you were originally saying and what you say for much of the rest of this mail but not with what Tomasz was talking about). > Also, other drivers have customs operating mode DT properties, please > take a look at > Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt: Per driver things can potentially be fine, trying to define generic properties is much harder. signature.asc Description: Digital signature
Re: [PATCH V3] ACPI / OSL: Make acpi_os_map_cleanup() use call_rcu() to avoid deadlocks
On 2014年08月28日 07:37, Rafael J. Wysocki wrote:
> On Wednesday, August 27, 2014 03:11:29 PM Lan Tianyu wrote:
>> Deadlock is possible when CPU hotplug and evaluating ACPI method happen
>> at the same time.
>>
>> During CPU hotplug, acpi_cpu_soft_notify() is called under the CPU hotplug
>> lock. Then, acpi_cpu_soft_notify() calls acpi_bus_get_device() to obtain
>> the struct acpi_device attached to the given ACPI handle. The ACPICA's
>> namespace lock will be acquired by acpi_bus_get_device() in the process.
>> Thus it is possible to hold the ACPICA's namespace lock under the CPU
>> hotplug lock.
>>
>> Evaluating an ACPI method may involve accessing an operation region in
>> system memory and the associated address space will be unmapped under
>> the ACPICA's namespace lock after completing the access. Currently, osl.c
>> uses RCU to protect memory ranges used by AML. When unmapping them it
>> calls synchronize_rcu() in acpi_os_map_cleanup(), but that blocks
>> CPU hotplug by acquiring the CPU hotplug lock. Thus it is possible to
>> hold the CPU hotplug lock under the ACPICA's namespace lock.
>>
>> This leads to deadlocks like the following one if AML accessing operation
>> regions in memory is executed in parallel with CPU hotplug.
>
> [cut]
>
>> To avoid such deadlocks, modify acpi_os_map_cleanup() to use call_rcu()
>> to schedule acpi_os_async_umap() asynchronously to umap memory regions
>> that aren't used any more. The umap operation can't be done in the
>> call_rcu()'s callback directly because the callback will be called in the
>> soft irq context and acpi_unmap() holds mutex lock inside.
>>
>> Signed-off-by: Lan Tianyu
>> [rjw: Subject and changelog.]
>> Cc: All applicable
>> Signed-off-by: Rafael J. Wysocki
>>
>> Signed-off-by: Lan Tianyu
>> ---
>> drivers/acpi/osl.c | 24 +++-
>> 1 file changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
>> index 3abe9b2..9baef71 100644
>> --- a/drivers/acpi/osl.c
>> +++ b/drivers/acpi/osl.c
>> @@ -40,6 +40,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -94,6 +95,7 @@ struct acpi_ioremap {
>> acpi_physical_address phys;
>> acpi_size size;
>> unsigned long refcount;
>> +struct rcu_head rcu;
>> };
>>
>> static LIST_HEAD(acpi_ioremaps);
>> @@ -423,13 +425,25 @@ static void acpi_os_drop_map_ref(struct acpi_ioremap
>> *map)
>> list_del_rcu(&map->list);
>> }
>>
>> +static void acpi_os_async_umap(void *data, async_cookie_t cookie)
>> +{
>> +struct acpi_ioremap *map = data;
>> +
>> +acpi_unmap(map->phys, map->virt);
>> +kfree(map);
>> +}
>> +
>> +static void acpi_os_map_reclaim(struct rcu_head *rcu)
>> +{
>> +struct acpi_ioremap *map = container_of(rcu, struct acpi_ioremap, rcu);
>> +
>> +async_schedule(acpi_os_async_umap, map);
>> +}
>> +
>> static void acpi_os_map_cleanup(struct acpi_ioremap *map)
>> {
>> -if (!map->refcount) {
>> -synchronize_rcu();
>> -acpi_unmap(map->phys, map->virt);
>> -kfree(map);
>> -}
>> +if (!map->refcount)
>> +call_rcu(&map->rcu, acpi_os_map_reclaim);
>> }
>>
>> void __ref acpi_os_unmap_iomem(void __iomem *virt, acpi_size size)
>>
>
> This goes a bit too far. First, if you need to start an async thread,
> you can simply do synchronize_rcu() from there.
Yes, that will be simple.
> Second, though, perhaps
> we can address the whole deadlock in a different way.
>
> For example, if we do something like the patch below (which I haven't
> tested, but it should work if I'm not missing something horribly), we
> won't be taking the ACPI namespace lock under the CPU hotplug lock
> in acpi_cpu_soft_notify() any more.
I considered this before. But the notify callback still will evaluate
ACPI method and may hold ACPICA's namespace lock. E.G "_CST".
Calltrace:
acpi_cpu_soft_notify()
acpi_processor_hotplug()
acpi_processor_get_power_info()
acpi_processor_get_power_info_cst()
>
> Rafael
>
> ---
> drivers/acpi/processor_driver.c |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> Index: linux-pm/drivers/acpi/processor_driver.c
> ===
> --- linux-pm.orig/drivers/acpi/processor_driver.c
> +++ linux-pm/drivers/acpi/processor_driver.c
> @@ -129,7 +129,11 @@ static int acpi_cpu_soft_notify(struct n
> if (action == CPU_STARTING || action == CPU_DYING)
> return NOTIFY_DONE;
>
> - if (!pr || acpi_bus_get_device(pr->handle, &device))
> + if (!pr || !pr->dev)
> + return NOTIFY_DONE;
> +
> + device = ACPI_COMPANION(pr->dev);
> + if (!device)
> return NOTIFY_DONE;
>
> if (action == CPU_ONLINE) {
>
--
Best regards
Tianyu Lan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
[PATCH 2/3] iio: accel: BMC150: fix issues when CONFIG_PM_RUNTIME is not set
When CONFIG_PM_RUNTIME is not set, the following issues are seen:
* warning message at compilation time:
warning: 'bmc150_accel_get_startup_times' defined but not used
[-Wunused-function]
* bmc150_accel_set_power_state() will always fail and reading the
accelerometer data is impossible;
This commit fixes these.
Signed-off-by: Laurentiu Palcu
---
drivers/iio/accel/bmc150-accel.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/iio/accel/bmc150-accel.c b/drivers/iio/accel/bmc150-accel.c
index ccb6cf8..0e6566a 100644
--- a/drivers/iio/accel/bmc150-accel.c
+++ b/drivers/iio/accel/bmc150-accel.c
@@ -499,6 +499,7 @@ static int bmc150_accel_get_bw(struct bmc150_accel_data
*data, int *val,
return -EINVAL;
}
+#ifdef CONFIG_PM_RUNTIME
static int bmc150_accel_get_startup_times(struct bmc150_accel_data *data)
{
int i;
@@ -529,6 +530,12 @@ static int bmc150_accel_set_power_state(struct
bmc150_accel_data *data, bool on)
return 0;
}
+#else
+static int bmc150_accel_set_power_state(struct bmc150_accel_data *data, bool
on)
+{
+ return 0;
+}
+#endif
static int bmc150_accel_set_scale(struct bmc150_accel_data *data, int val)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] iio: accel: BMC150: add support for more Bosch chips
Hi, The following patchset fixes a couple of minor issues with the BMC150 accelerometer driver and, also, adds support for more Bosch accelerometer chips that are basically identical to BMC150 or have only the resolution different. So, it makes sense to reuse this existing driver. All the accelerometer chips were tested using the eval boards provided by Bosch. laurentiu Laurentiu Palcu (3): iio: accel: BMC150: fix scale value for 16G iio: accel: BMC150: fix issues when CONFIG_PM_RUNTIME is not set iio: accel: BMC150: add support for other Bosch chips drivers/iio/accel/bmc150-accel.c | 238 ++- 1 file changed, 184 insertions(+), 54 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 4/5] rtc: max77686: Remove unneded info log
On pon, 2014-08-18 at 10:34 +0200, Javier Martinez Canillas wrote:
> If devm_rtc_device_register() fails a dev_err() is already
> reported so there is no need to do an additional dev_info().
>
> Signed-off-by: Javier Martinez Canillas
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
> ---
> drivers/rtc/rtc-max77686.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
> index 55396bb..b177ba1 100644
> --- a/drivers/rtc/rtc-max77686.c
> +++ b/drivers/rtc/rtc-max77686.c
> @@ -457,8 +457,6 @@ static int max77686_rtc_probe(struct platform_device
> *pdev)
> &max77686_rtc_ops, THIS_MODULE);
>
> if (IS_ERR(info->rtc_dev)) {
> - dev_info(&pdev->dev, "%s: fail\n", __func__);
> -
> ret = PTR_ERR(info->rtc_dev);
> dev_err(&pdev->dev, "Failed to register RTC device: %d\n", ret);
> if (ret == 0)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] iio: accel: BMC150: add support for other Bosch chips
The following chips are either similar or have only the resolution
different. Hence, change this driver to support these chips too:
BMI055 - combo chip (accelerometer part is identical to BMC150's)
BMA255 - identical to BMC150's accelerometer
BMA222 - 8 bit resolution
BMA250 - 10 bit resolution
BMA280 - 14 bit resolution
Additionally:
* add bmc150_accel_match_acpi_device() function to check that the device
has been enumerated through ACPI;
* rename bmc150_accel_acpi_gpio_probe() to bmc150_accel_gpio_probe()
since the ACPI matching has been moved to the new function. Also, this
will allow for the GPIO matching to be done against a device tree too, not
only
ACPI tree;
Signed-off-by: Laurentiu Palcu
---
drivers/iio/accel/bmc150-accel.c | 231 ++-
1 file changed, 177 insertions(+), 54 deletions(-)
diff --git a/drivers/iio/accel/bmc150-accel.c b/drivers/iio/accel/bmc150-accel.c
index 0e6566a..07e10fc 100644
--- a/drivers/iio/accel/bmc150-accel.c
+++ b/drivers/iio/accel/bmc150-accel.c
@@ -1,5 +1,12 @@
/*
- * BMC150 3-axis accelerometer driver
+ * 3-axis accelerometer driver supporting following Bosch-Sensortec chips:
+ * - BMC150
+ * - BMI055
+ * - BMA255
+ * - BMA250
+ * - BMA222
+ * - BMA280
+ *
* Copyright (c) 2014, Intel Corporation.
*
* This program is free software; you can redistribute it and/or modify it
@@ -35,6 +42,11 @@
#define BMC150_ACCEL_REG_CHIP_ID 0x00
#define BMC150_ACCEL_CHIP_ID_VAL 0xFA
+#define BMA255_ACCEL_CHIP_ID_VAL 0xFA
+#define BMI055_ACCEL_CHIP_ID_VAL 0xFA
+#define BMA222_ACCEL_CHIP_ID_VAL 0xF8
+#define BMA250_ACCEL_CHIP_ID_VAL 0xF9
+#define BMA280_ACCEL_CHIP_ID_VAL 0xFB
#define BMC150_ACCEL_REG_INT_STATUS_2 0x0B
#define BMC150_ACCEL_ANY_MOTION_MASK 0x07
@@ -126,6 +138,18 @@ enum bmc150_power_modes {
BMC150_ACCEL_SLEEP_MODE_SUSPEND = 0x04,
};
+struct bmc150_scale_info {
+ int scale;
+ int range;
+};
+
+struct bmc150_accel_chip_info {
+ u8 chip_id;
+ const struct iio_chan_spec *channels;
+ int num_channels;
+ const struct bmc150_scale_info scale_table[4];
+};
+
struct bmc150_accel_data {
struct i2c_client *client;
struct iio_trigger *dready_trig;
@@ -140,6 +164,7 @@ struct bmc150_accel_data {
bool dready_trigger_on;
bool motion_trigger_on;
int64_t timestamp;
+ const struct bmc150_accel_chip_info *chip_info;
};
static const struct {
@@ -168,14 +193,6 @@ static const struct {
{0x0F, 1} };
static const struct {
- int scale;
- int range;
-} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
-{19122, BMC150_ACCEL_DEF_RANGE_4G},
-{38344, BMC150_ACCEL_DEF_RANGE_8G},
-{76590, BMC150_ACCEL_DEF_RANGE_16G} };
-
-static const struct {
int sleep_dur;
int reg_value;
} bmc150_accel_sleep_value_table[] = { {0, 0},
@@ -267,7 +284,7 @@ static int bmc150_accel_chip_init(struct bmc150_accel_data
*data)
}
dev_dbg(&data->client->dev, "Chip Id %x\n", ret);
- if (ret != BMC150_ACCEL_CHIP_ID_VAL) {
+ if (ret != data->chip_info->chip_id) {
dev_err(&data->client->dev, "Invalid chip %x\n", ret);
return -ENODEV;
}
@@ -541,19 +558,19 @@ static int bmc150_accel_set_scale(struct
bmc150_accel_data *data, int val)
{
int ret, i;
- for (i = 0; i < ARRAY_SIZE(bmc150_accel_scale_table); ++i) {
- if (bmc150_accel_scale_table[i].scale == val) {
+ for (i = 0; i < ARRAY_SIZE(data->chip_info->scale_table); ++i) {
+ if (data->chip_info->scale_table[i].scale == val) {
ret = i2c_smbus_write_byte_data(
data->client,
BMC150_ACCEL_REG_PMU_RANGE,
- bmc150_accel_scale_table[i].range);
+ data->chip_info->scale_table[i].range);
if (ret < 0) {
dev_err(&data->client->dev,
"Error writing pmu_range\n");
return ret;
}
- data->range = bmc150_accel_scale_table[i].range;
+ data->range = data->chip_info->scale_table[i].range;
return 0;
}
}
@@ -580,10 +597,12 @@ static int bmc150_accel_get_temp(struct bmc150_accel_data
*data, int *val)
return IIO_VAL_INT;
}
-static int bmc150_accel_get_axis(struct bmc150_accel_data *data, int axis,
+static int bmc150_accel_get_axis(struct bmc150_accel_data *data,
+struc
[PATCH 1/3] iio: accel: BMC150: fix scale value for 16G
According to documentation ([1] - page 27), the range for 16G is
7.81mg/LSB. Converted to SI, this is:
7.81 * 10^-3 * 9.80665 m/s^2 / LSB = 0.0765899365 m/s^2 / LSB
[1]
http://ae-bst.resource.bosch.com/media/products/dokumente/bmc150/BST-BMC150-DS000-04.pdf
Signed-off-by: Laurentiu Palcu
---
drivers/iio/accel/bmc150-accel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/accel/bmc150-accel.c b/drivers/iio/accel/bmc150-accel.c
index 23ae334..ccb6cf8 100644
--- a/drivers/iio/accel/bmc150-accel.c
+++ b/drivers/iio/accel/bmc150-accel.c
@@ -173,7 +173,7 @@ static const struct {
} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
{19122, BMC150_ACCEL_DEF_RANGE_4G},
{38344, BMC150_ACCEL_DEF_RANGE_8G},
-{77057, BMC150_ACCEL_DEF_RANGE_16G} };
+{76590, BMC150_ACCEL_DEF_RANGE_16G} };
static const struct {
int sleep_dur;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL]: few dma-buf updates for 3.17-rc3
Hi Linus, The major changes for 3.17 already went via Greg-KH's tree this time as well; this is a small pull request for dma-buf - all documentation related. Could you please pull? The following changes since commit f1bd473f95e02bc382d4dae94d7f82e2a455e05d: Merge branch 'sec-v3.17-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/sergeh/linux-security (2014-08-27 17:32:37 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/sumits/dma-buf.git tags/for-3.17-rc3 for you to fetch changes up to 1f58d9465c568eb47cab939bbc4f30ae51863295: dma-buf/fence: Fix one more kerneldoc warning (2014-08-28 11:59:38 +0530) Small dma-buf pull request for 3.17-rc3 Gioh Kim (1): Documentation/dma-buf-sharing.txt: update API descriptions Thierry Reding (2): dma-buf/fence: Fix a kerneldoc warning dma-buf/fence: Fix one more kerneldoc warning Documentation/dma-buf-sharing.txt | 14 -- drivers/dma-buf/fence.c | 2 +- include/linux/seqno-fence.h | 1 + 3 files changed, 10 insertions(+), 7 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 1/4] ftracetest: Initial commit for ftracetest
(2014/08/28 0:54), Luis Henriques wrote:
> Hi,
>
> Not really a complete review, but just 2 comments on this script:
>
> On Tue, Aug 26, 2014 at 11:15:18AM +, Masami Hiramatsu wrote:
> ...
>> +prlog() { # messages
>> + echo $@ | tee -a $LOG_FILE
>> +}
>> +catlog() { #file
>> + cat $1 | tee -a $LOG_FILE
>> +}
>> +
>> +# Testcase management
>> +PASSED_CASES=
>> +FAILED_CASES=
>> +CASENO=0
>> +testcase() { # testfile
>> + CASENO=$((CASENO+1))
>> + prlog -n "[$CASENO]"`grep "^#[ \t]*description:" $1 | cut -f2 -d:`
>> +}
>> +failed() {
>> + prlog -e "\t[FAIL]"
>> + FAILED_CASES="$FAILED_CASES $CASENO"
>> +}
>> +passed() {
>> + prlog -e "\t[PASS]"
>> + PASSED_CASES="$PASSED_CASES $CASENO"
>> +}
>
> What I see here is a '-e' being echo'ed and not really a '-e' switch
> being used to 'echo'. (Also, I'm not sure if this is a standard
> switch...).
>
> This applies to all the other 'prlog -e'.
Oh, really? what shell did you use?
My target shell is the busybox and I've tested it on fedora20.
e.g. busybox echo command seems accept -e.
$ busybox echo -e '\tfoo'
foo
Of course maybe I'd better not use \t, but ""...
>> +
>> +
>> +# Run one test case
>> +run_test() { # testfile
>> + local testname=`basename $1`
>> + local testlog=`mktemp --tmpdir=$LOG_DIR ${testname}-XX.log`
>> + testcase $1
>> + echo "execute: "$1 > $testlog
>> + (cd $TRACING_DIR; set -x ; source $t) >> $testlog 2>&1
>> + ret=$?
>
> I believe the usage of 'source' is a bashism, and '.' should be used
> instead. In my environment, 'source' results in ret=127. Replacing
> it by '.' fixes it.
Ah, right. I missed that, I'll fix that :)
Thank you,
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/4] thermal: rockchip: add driver for thermal
On Thursday 28 August 2014 08:59:19 Caesar Wang wrote: > Thermal is TS-ADC Controller module supports user-defined mode and automatic > mode. > > User-defined mode refers,TSADC all the control signals entirely by software > writing to register for direct control. > > Automaic mode refers to the module automatically poll TSADC output,and the > results > Were checked. > > If you find that the temperature High in a period of time, an interrupt is > generated > to the processor down-measures taken;if the temperature over a period of time > High, > the resulting TSHUT gave CRU module,let it reset the entire chip, or via GPIO > give PMIC. > > Signed-off-by: zhaoyifeng > Signed-off-by: Caesar Wang Hi Caesar, After looking at the driver (last time I only received the patch for the binding), I have a more general comment: This looks like a general-purpose ADC device, not an IP block that is specific to thermal management. The binding looks ok for that purpose but should probably be moved into Documentation/devicetree/bindings/iio/adc/ as a minor change. On the driver side, I believe the correct way to deal with this setup is to split your driver into a generic drivers/iio/adc/rockchips-tsadc.c file, and a smaller thermal driver that uses the iio in-kernel interfaces, ideally one that is independent of the underlying hardware and can work on any ADC implementation. I've put the IIO maintainer on Cc in this mail, maybe Jonathan or someone else on the linux-iio mailing list has some extra insight. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [f2fs-dev] [PATCH] f2fs: reposition unlock_new_inode to prevent accessing invalid inode
Hi Changman, > -Original Message- > From: Changman Lee [mailto:cm224@samsung.com] > Sent: Thursday, August 28, 2014 9:48 AM > To: Chao Yu > Cc: Jaegeuk Kim; linux-kernel@vger.kernel.org; > linux-f2fs-de...@lists.sourceforge.net > Subject: Re: [f2fs-dev] [PATCH] f2fs: reposition unlock_new_inode to prevent > accessing invalid > inode > > Hi Chao, > > I agree it's correct unlock_new_inode should be located after make_bad_inode. > > About this scenario, > I think we should check some condition if this could be occured; I think this condition is the almost impossible but which can happen theoretically. > A inode allocated newly could be victim by gc thread. > Then, f2fs_iget called by Thread A have to fail because we handled it as > bad_inode in Thread B. However, f2fs_iget could still get inode. > How about check it using is_bad_inode() in f2fs_iget. Yes, agreed. How about return -EIO when this inode we iget_locked is bad? Thanks, Yu > > Thanks, > > On Tue, Aug 26, 2014 at 06:35:29PM +0800, Chao Yu wrote: > > As the race condition on the inode cache, following scenario can appear: > > [Thread a] [Thread b] > > ->f2fs_mkdir > > ->f2fs_add_link > > ->__f2fs_add_link > > ->init_inode_metadata failed here > > ->gc_thread_func > > ->f2fs_gc > > ->do_garbage_collect > > ->gc_data_segment > > ->f2fs_iget > > ->iget_locked > > ->wait_on_inode > > ->unlock_new_inode > > ->move_data_page > > ->make_bad_inode > > ->iput > > > > When we fail in create/symlink/mkdir/mknod/tmpfile, the new allocated inode > > should be set as bad to avoid being accessed by other thread. But in above > > scenario, it allows f2fs to access the invalid inode before this inode was > > set > > as bad. > > This patch fix the potential problem, and this issue was found by code > > review. > > > > Signed-off-by: Chao Yu > > --- > > fs/f2fs/namei.c | 10 +- > > 1 file changed, 5 insertions(+), 5 deletions(-) > > > > diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c > > index 6b53ce9..845f1be 100644 > > --- a/fs/f2fs/namei.c > > +++ b/fs/f2fs/namei.c > > @@ -134,8 +134,8 @@ static int f2fs_create(struct inode *dir, struct dentry > > *dentry, umode_t > mode, > > return 0; > > out: > > clear_nlink(inode); > > - unlock_new_inode(inode); > > make_bad_inode(inode); > > + unlock_new_inode(inode); > > iput(inode); > > alloc_nid_failed(sbi, ino); > > return err; > > @@ -267,8 +267,8 @@ static int f2fs_symlink(struct inode *dir, struct > > dentry *dentry, > > return err; > > out: > > clear_nlink(inode); > > - unlock_new_inode(inode); > > make_bad_inode(inode); > > + unlock_new_inode(inode); > > iput(inode); > > alloc_nid_failed(sbi, inode->i_ino); > > return err; > > @@ -308,8 +308,8 @@ static int f2fs_mkdir(struct inode *dir, struct dentry > > *dentry, umode_t > mode) > > out_fail: > > clear_inode_flag(F2FS_I(inode), FI_INC_LINK); > > clear_nlink(inode); > > - unlock_new_inode(inode); > > make_bad_inode(inode); > > + unlock_new_inode(inode); > > iput(inode); > > alloc_nid_failed(sbi, inode->i_ino); > > return err; > > @@ -354,8 +354,8 @@ static int f2fs_mknod(struct inode *dir, struct dentry > > *dentry, > > return 0; > > out: > > clear_nlink(inode); > > - unlock_new_inode(inode); > > make_bad_inode(inode); > > + unlock_new_inode(inode); > > iput(inode); > > alloc_nid_failed(sbi, inode->i_ino); > > return err; > > @@ -688,8 +688,8 @@ release_out: > > out: > > f2fs_unlock_op(sbi); > > clear_nlink(inode); > > - unlock_new_inode(inode); > > make_bad_inode(inode); > > + unlock_new_inode(inode); > > iput(inode); > > alloc_nid_failed(sbi, inode->i_ino); > > return err; > > -- > > 2.0.0.421.g786a89d > > > > > > > > -- > > Slashdot TV. > > Video for Nerds. Stuff that matters. > > http://tv.slashdot.org/ > > ___ > > Linux-f2fs-devel mailing list > > linux-f2fs-de...@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sh: get_user_pages_fast() must flush cache the way
Hi Andrew, could you please apply? -=-=-=-=-=-=-=-=-=# Don't remove this line #=-=-=-=-=-=-=-=-=- This patch avoids fuse hangs on sh4 by flushing the cache on get_user_pages_fast(). This is not necessary a good thing to do, but get_user_pages() does this, so get_user_pages_fast() should too. Please note the patch for mips arch that addresses the similar problem: https://kernel.googlesource.com/pub/scm/linux/kernel/git/ralf/linux/+/linux-3.4.50%5E!/#F0 They basically simply disable get_user_pages_fast() at all, using a fall-back to get_user_pages(). But my fix is different, it adds an explicit cache flushes. Signed-off-by: Stas Sergeev --- arch/sh/mm/gup.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/sh/mm/gup.c b/arch/sh/mm/gup.c index bf8daf9..37458f3 100644 --- a/arch/sh/mm/gup.c +++ b/arch/sh/mm/gup.c @@ -105,6 +105,8 @@ static noinline int gup_pte_range(pmd_t pmd, unsigned long addr, VM_BUG_ON(!pfn_valid(pte_pfn(pte))); page = pte_page(pte); get_page(page); +__flush_anon_page(page, addr); +flush_dcache_page(page); pages[*nr] = page; (*nr)++; -- 1.7.11.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2 V4] irqchip: gic: Add supports for ARM GICv2m MSI(-X)
On 08/15/2014 09:03 AM, Marc Zyngier wrote:
+
+static struct irq_chip gicv2m_chip;
+
+#ifdef CONFIG_OF
Is there any reason why this should be guarded by CONFIG_OF? Surely the
v2m capability should only be enabled if OF is.
[Suravee]
We are also planning to support ACPI in the future also, which will be
using a different init function. Also, there is the same #ifdef in the
irq-gic.c for the gic_of_init(). So, I am just trying to be consistent
here.
+
+ memcpy(&gicv2m_chip, gic->irq_chip, sizeof(struct irq_chip));
+ gicv2m_chip.name = "GICv2m",
+ gicv2m_chip.irq_mask = gicv2m_mask_irq;
+ gicv2m_chip.irq_unmask = gicv2m_unmask_irq;
+ gic->irq_chip = &gicv2m_chip;
I liked it until this last line. You're overriding the irq_chip for the
whole GIC. I was expecting you'd only use it for the MSI range
(basically return a range to the caller, together with your brand new
irq_chip).
[Suravee]
I'm not sure if I understand you point here. Actually, I don't see the
whole point of the need to have a whole different irq_chip for v2m
stuff. All I need is just a way to overwrite the irq_chip.irq_mask()
and irq_chip.irq_unmask() with the v2m version which should check for
MSI before calling mask/unmask_msi_irq(). I should be able to just do:
gic->irq_chip.irq_mask = gicv2m_mask_irq;
gic->irq_chip.irq_unmask = gicv2m_unmask_irq;
@@ -768,19 +768,21 @@ void __init gic_init_physaddr(struct device_node *node)
static int gic_irq_domain_map(struct irq_domain *d, unsigned int irq,
irq_hw_number_t hw)
{
+ struct gic_chip_data *gic = d->host_data;
+
if (hw < 32) {
irq_set_percpu_devid(irq);
- irq_set_chip_and_handler(irq, &gic_chip,
+ irq_set_chip_and_handler(irq, gic->irq_chip,
handle_percpu_devid_irq);
set_irq_flags(irq, IRQF_VALID | IRQF_NOAUTOEN);
} else {
- irq_set_chip_and_handler(irq, &gic_chip,
+ irq_set_chip_and_handler(irq, gic->irq_chip,
handle_fasteoi_irq);
And here you should discriminate on whether this is MSI or not, based on
the range you got from above.
[Suravee]
From above, since we only use one irq_chip (i.e. the gic_chip), there
is no need to differentiate here, and I don't need to make these two
line changes.
@@ -1009,6 +1012,16 @@ gic_of_init(struct device_node *node, struct device_node
*parent)
if (of_property_read_u32(node, "cpu-offset", &percpu_offset))
percpu_offset = 0;
+ gic_data[gic_cnt].irq_chip = &gic_chip;
+
+ /* Currently, we only support one v2m subnode. */
+ child = of_get_child_by_name(node, "v2m");
If you only support one v2m node, then you should also enforce it for
potential secondaty GICs (just probing it for gic_cnt == 0 should be
enough).
[Suravee]
Actually, if we have multiple (N) GICs, we should be able to also
support multiple (N) V2Ms with the followings entries.
gic0 {
.
v2m {
}
}
gic1 {
.
v2m {
}
}
What I am not trying to support at this point is the following:
gic0 {
v2m {
}
v2m {
}
}
diff --git a/drivers/irqchip/irq-gic.h b/drivers/irqchip/irq-gic.h
new file mode 100644
index 000..2ec6bc3
--- /dev/null
+++ b/drivers/irqchip/irq-gic.h
@@ -0,0 +1,48 @@
+#ifndef _IRQ_GIC_H_
+#define _IRQ_GIC_H_
+
+#include
+
+union gic_base {
+ void __iomem *common_base;
+ void __percpu * __iomem *percpu_base;
+};
+
+#ifdef CONFIG_ARM_GIC_V2M
+struct v2m_data {
+ spinlock_t msi_cnt_lock;
+ struct msi_chip msi_chip;
+ struct resource res; /* GICv2m resource */
+ void __iomem *base; /* GICv2m virt address */
+ unsigned int spi_start; /* The SPI number that MSIs start */
+ unsigned int nr_spis; /* The number of SPIs for MSIs */
+ unsigned long *bm;/* MSI vector bitmap */
+};
+#endif
So if you put the #ifdef/#endif *inside* the v2m_data structure...
[Suravee] Are you suggesting an empty struct v2m_data{}; Hm.. I guess I
can do that.
Thanks,
Suravee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] regulator: fix kernel-doc warnings in header files
On Wed, Aug 27, 2014 at 02:31:24PM -0700, Randy Dunlap wrote: > From: Randy Dunlap > > Fix kernel-doc warnings in regulator header files: Applied, thanks. signature.asc Description: Digital signature
Re: [PATCH 1/2 V4] irqchip: gic: Add supports for ARM GICv2m MSI(-X)
On 08/14/2014 12:55 PM, Mark Rutland wrote:
On Wed, Aug 13, 2014 at 04:00:40PM +0100, suravee.suthikulpa...@amd.com wrote:
From: Suravee Suthikulpanit
ARM GICv2m specification extends GICv2 to support MSI(-X) with
a new set of register frame. This patch introduces support for
the non-secure GICv2m register frame. Currently, GICV2m is available
in certain version of GIC-400.
The patch introduces a new property in ARM gic binding, the v2m subnode.
It is optional.
Signed-off-by: Suravee Suthikulpanit
Cc: Mark Rutland
Cc: Marc Zyngier
Cc: Jason Cooper
Cc: Catalin Marinas
Cc: Will Deacon
---
Documentation/devicetree/bindings/arm/gic.txt | 32
drivers/irqchip/Kconfig | 7 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-gic-v2m.c | 215 ++
drivers/irqchip/irq-gic.c | 75 +
drivers/irqchip/irq-gic.h | 48 ++
6 files changed, 348 insertions(+), 30 deletions(-)
create mode 100644 drivers/irqchip/irq-gic-v2m.c
create mode 100644 drivers/irqchip/irq-gic.h
diff --git a/Documentation/devicetree/bindings/arm/gic.txt
b/Documentation/devicetree/bindings/arm/gic.txt
index 5573c08..8a64179 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -95,3 +95,35 @@ Example:
<0x2c006000 0x2000>;
interrupts = <1 9 0xf04>;
};
+
+
+* GICv2m extension for MSI/MSI-x support (Optional)
+
+Certain revision of GIC-400 supports MSI/MSI-x via V2M register frame.
+This is enabled by specifying v2m sub-node.
+
+Required properties:
+
+- msi-controller : Identifies the node as an MSI controller.
+
+- reg : GICv2m MSI interface register base and size
+
+Example:
+
+ interrupt-controller@e1101000 {
+ compatible = "arm,gic-400";
+ #interrupt-cells = <3>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+ interrupt-controller;
+ interrupts = <1 8 0xf04>;
+ ranges = <0 0 0 0xe110 0 0x10>;
+ reg = <0x0 0xe111 0 0x01000>,
+ <0x0 0xe112f000 0 0x02000>,
+ <0x0 0xe114 0 0x1>,
+ <0x0 0xe116 0 0x1>;
+ v2m {
+ msi-controller;
+ reg = <0x0 0x8 0 0x1000>;
+ };
+ };
[...]
@@ -1009,6 +1012,16 @@ gic_of_init(struct device_node *node, struct device_node
*parent)
if (of_property_read_u32(node, "cpu-offset", &percpu_offset))
percpu_offset = 0;
+ gic_data[gic_cnt].irq_chip = &gic_chip;
+
+ /* Currently, we only support one v2m subnode. */
+ child = of_get_child_by_name(node, "v2m");
+ if (child) {
+ ret = gicv2m_of_init(child, &gic_data[gic_cnt]);
+ if (ret)
+ return ret;
+ }
I can't see how you'd sanely expand this to multiple children, which was
the main point of having a separate node for the M block.
Give the M block a compatible string and look for children with that
string.
Thanks,
Mark.
Good point. I can try that.
Thank,
Suravee
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 0/5] rtc: s3c: Refactoring s3c-rtc driver and support Exynos3250 RTC
This patchset clean up codes to improve readability as following and support the RTC of Exynos3250 SoC. - Remove global variables and then use new s3c_rtc structure - Remove warn message with checking checkpatch script - Use variant structure according to SoC type instead of legacy enum variable(s3c_cpu_type) Changes from v2: - Drop the checking statement of 'info->base' because it is un-needed Changes from v1: - Fix NULL pointer panic of s3c_rtc_settime() - Check info->base value to protect NULL pointer panic Chanwoo Choi (5): rtc: s3c: Define s3c_rtc structure to remove global variables. rtc: s3c: Remove warning message when checking coding style with checkpatch script rtc: s3c: Add s3c_rtc_data structure to use variant data instead of s3c_cpu_type rtc: s3c: Add support for RTC of Exynos3250 SoC ARM: dts: Fix wrong compatible string of Exynos3250 RTC dt node Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 3 + arch/arm/boot/dts/exynos3250.dtsi | 2 +- drivers/rtc/rtc-s3c.c | 851 ++ 3 files changed, 535 insertions(+), 321 deletions(-) -- 1.8.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] pwm: Fix uninitialized warnings in pwm_get()
With some versions of gcc (e.g. 4.1.2):
drivers/pwm/core.c: In function ‘pwm_get’:
drivers/pwm/core.c:610: warning: ‘polarity’ may be used uninitialized in this
function
drivers/pwm/core.c:609: warning: ‘period’ may be used uninitialized in this
function
While these are false positives, we can get rid of them by refactoring
the code to store a pointer to the best match, as suggested before by
Thierry Reding. This does require moving the mutex_unlock() down.
Fixes: d717ea73e36dd565 ("pwm: Fix period and polarity in pwm_get() for
non-perfect matches")
Signed-off-by: Geert Uytterhoeven
---
drivers/pwm/core.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 8c748b17f416..966497d10c6e 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -602,12 +602,9 @@ struct pwm_device *pwm_get(struct device *dev, const char
*con_id)
struct pwm_device *pwm = ERR_PTR(-EPROBE_DEFER);
const char *dev_id = dev ? dev_name(dev) : NULL;
struct pwm_chip *chip = NULL;
- unsigned int index = 0;
unsigned int best = 0;
- struct pwm_lookup *p;
+ struct pwm_lookup *p, *chosen = NULL;
unsigned int match;
- unsigned int period;
- enum pwm_polarity polarity;
/* look up via DT first */
if (IS_ENABLED(CONFIG_OF) && dev && dev->of_node)
@@ -653,10 +650,7 @@ struct pwm_device *pwm_get(struct device *dev, const char
*con_id)
}
if (match > best) {
- chip = pwmchip_find_by_name(p->provider);
- index = p->index;
- period = p->period;
- polarity = p->polarity;
+ chosen = p;
if (match != 3)
best = match;
@@ -665,17 +659,22 @@ struct pwm_device *pwm_get(struct device *dev, const char
*con_id)
}
}
- mutex_unlock(&pwm_lookup_lock);
+ if (!chosen)
+ goto out;
- if (chip)
- pwm = pwm_request_from_chip(chip, index, con_id ?: dev_id);
- if (IS_ERR(pwm))
- return pwm;
+ chip = pwmchip_find_by_name(chosen->provider);
+ if (!chip)
+ goto out;
- pwm_set_period(pwm, period);
- pwm_set_polarity(pwm, polarity);
+ pwm = pwm_request_from_chip(chip, chosen->index, con_id ?: dev_id);
+ if (IS_ERR(pwm))
+ goto out;
+ pwm_set_period(pwm, chosen->period);
+ pwm_set_polarity(pwm, chosen->polarity);
+out:
+ mutex_unlock(&pwm_lookup_lock);
return pwm;
}
EXPORT_SYMBOL_GPL(pwm_get);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 3/5] rtc: s3c: Add s3c_rtc_data structure to use variant data instead of s3c_cpu_type
This patch add s3c_rtc_data structure to variant data according to SoC type.
The s3c_rtc_data structure includes some functions to control RTC operation
and specific data dependent on SoC type.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Cc: Alessandro Zummo
Cc: Kukjin Kim
Cc: Andrew Morton
---
drivers/rtc/rtc-s3c.c | 461 +++---
1 file changed, 289 insertions(+), 172 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 4e95cca..0d90892 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -32,17 +32,6 @@
#include
#include "rtc-s3c.h"
-enum s3c_cpu_type {
- TYPE_S3C2410,
- TYPE_S3C2416,
- TYPE_S3C2443,
- TYPE_S3C64XX,
-};
-
-struct s3c_rtc_drv_data {
- int cpu_type;
-};
-
struct s3c_rtc {
struct device *dev;
struct rtc_device *rtc;
@@ -51,7 +40,7 @@ struct s3c_rtc {
struct clk *rtc_clk;
bool enabled;
- enum s3c_cpu_type cpu_type;
+ struct s3c_rtc_data *data;
int irq_alarm;
int irq_tick;
@@ -63,6 +52,19 @@ struct s3c_rtc {
bool wake_en;
};
+struct s3c_rtc_data {
+ int max_user_freq;
+
+ void (*irq_handler) (struct s3c_rtc *info, int mask);
+ void (*set_freq) (struct s3c_rtc *info, int freq);
+ void (*enable_tick) (struct s3c_rtc *info, struct seq_file *seq);
+ void (*select_tick_clk) (struct s3c_rtc *info);
+ void (*save_tick_cnt) (struct s3c_rtc *info);
+ void (*restore_tick_cnt) (struct s3c_rtc *info);
+ void (*enable) (struct s3c_rtc *info);
+ void (*disable) (struct s3c_rtc *info);
+};
+
static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info, bool enable)
{
unsigned long irq_flags;
@@ -83,34 +85,22 @@ static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info,
bool enable)
}
/* IRQ Handlers */
-static irqreturn_t s3c_rtc_alarmirq(int irq, void *id)
+static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
{
struct s3c_rtc *info = (struct s3c_rtc *)id;
- clk_enable(info->rtc_clk);
- rtc_update_irq(info->rtc, 1, RTC_AF | RTC_IRQF);
-
- if (info->cpu_type == TYPE_S3C64XX)
- writeb(S3C2410_INTP_ALM, info->base + S3C2410_INTP);
-
- clk_disable(info->rtc_clk);
-
- s3c_rtc_alarm_clk_enable(info, false);
+ if (info->data->irq_handler)
+ info->data->irq_handler(info, S3C2410_INTP_TIC);
return IRQ_HANDLED;
}
-static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
+static irqreturn_t s3c_rtc_alarmirq(int irq, void *id)
{
struct s3c_rtc *info = (struct s3c_rtc *)id;
- clk_enable(info->rtc_clk);
- rtc_update_irq(info->rtc, 1, RTC_PF | RTC_IRQF);
-
- if (info->cpu_type == TYPE_S3C64XX)
- writeb(S3C2410_INTP_TIC, info->base + S3C2410_INTP);
-
- clk_disable(info->rtc_clk);
+ if (info->data->irq_handler)
+ info->data->irq_handler(info, S3C2410_INTP_ALM);
return IRQ_HANDLED;
}
@@ -137,36 +127,18 @@ static int s3c_rtc_setaie(struct device *dev, unsigned
int enabled)
return 0;
}
+/* Set RTC frequency */
static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
{
- unsigned int tmp = 0;
- int val;
-
if (!is_power_of_2(freq))
return -EINVAL;
clk_enable(info->rtc_clk);
spin_lock_irq(&info->pie_lock);
- if (info->cpu_type != TYPE_S3C64XX) {
- tmp = readb(info->base + S3C2410_TICNT);
- tmp &= S3C2410_TICNT_ENABLE;
- }
-
- val = (info->rtc->max_user_freq / freq) - 1;
-
- if (info->cpu_type == TYPE_S3C2416 || info->cpu_type == TYPE_S3C2443) {
- tmp |= S3C2443_TICNT_PART(val);
- writel(S3C2443_TICNT1_PART(val), info->base + S3C2443_TICNT1);
+ if (info->data->set_freq)
+ info->data->set_freq(info, freq);
- if (info->cpu_type == TYPE_S3C2416)
- writel(S3C2416_TICNT2_PART(val),
- info->base + S3C2416_TICNT2);
- } else {
- tmp |= val;
- }
-
- writel(tmp, info->base + S3C2410_TICNT);
spin_unlock_irq(&info->pie_lock);
clk_disable(info->rtc_clk);
@@ -174,7 +146,6 @@ static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
}
/* Time read/write */
-
static int s3c_rtc_gettime(struct device *dev, struct rtc_time *rtc_tm)
{
struct s3c_rtc *info = dev_get_drvdata(dev);
@@ -355,19 +326,14 @@ static int s3c_rtc_setalarm(struct device *dev, struct
rtc_wkalrm *alrm)
static int s3c_rtc_proc(struct device *dev, struct seq_file *seq)
{
struct s3c_rtc *info = dev_get_drvdata(dev);
- unsigned int ticnt;
clk_enable(info->rtc_clk);
- if (info->cpu_type == TYPE_S3C64XX) {
- ticnt = readw(info->base + S3C2410_RTCCON);
- ticnt &= S3C64XX_RTCCON_TICEN;
- } e
Re: [PATCH 1/7] dmaengine: edma: fix two faults which happen with the 8250_dma user
On 08/28/2014 09:06 AM, Vinod Koul wrote: > On Thu, Aug 21, 2014 at 03:09:12PM +0200, Sebastian Andrzej Siewior wrote: >> On 08/19/2014 05:12 PM, Vinod Koul wrote: desc = dmaengine_prep_slave_single(rxchan, …); rx_cookie = dmaengine_submit(desc); dma_async_issue_pending(rxchan); ssleep(2); /* Now assume that the transfer did not start */ st = dmaengine_tx_status(rxchan, rx_cookie, NULL); /* st is now DMA_IN_PROGRESS as expected */ dmaengine_terminate_all(rxchan); st = dmaengine_tx_status(rxchan, rx_cookie, NULL); >>> and here is the culprit. You have terminated the channel. This means that >>> dmaengine driver is free to clean up all the allocated descriptors on the >>> channels and do whatever it decides to do with them. >> >> descriptors, yes. > and by that logic when you query the driver would have freed up! I don't understand. What "would have freed up"? >>> You have already terminated the channel so what is the point in querying the >>> status of the cookie, which you shouldn't use anyway after invoking >>> terminate_all() as its result is not correct. >> >> The point is to check (later, after terminate_all()) if there is an >> outstanding DMA transfer or not _and_ how much data was really >> transfered. Looking at edma it does not really support the latter if >> the transfer is already completed. On the plus side the HW does not >> support partly transfers :) > well that can be achieved properly and differently! I am all yours. > Why don't we pause the channel, get the residue, status and then > terminate. This is done that way. For the protocol: pause is not supported by driver (edma and omap-dma) unless the channel is used in "continuous" mode. But this does not matter here. The root problems remains: You get DMA_IN_PROGRESS returned as long as the cookie has not been completed _even_ after the invocation of terminate_all(). So that part that knows it terminates the thing for the first time does everything correct. The other part that only enqueues a transfer if there is not another one pending does never do anything. >> But where is it written that the life time of the cookie is limited? >> Looking at the "cooking check" code there is no such thing. It is >> simply compare of completed vs passed number but okay, this is an >> implementation detail. >> From [0] it says under "4. Submit the transaction": >> >> | This returns a cookie can be used to check the progress of DMA engine >> | activity via other DMA engine calls not covered in this document. >> >> no life time limit mentioned here. Which brings to the question: Why is >> it okay to use the cookie after the transaction "terminated" normally >> but not if it has been canceled? > Due to the special nature of terminate. The point here is that you don't > terminate a transaction but channel operation So the channel is terminated and the transaction is still in progress. Is this what you are telling me? And why should a transaction remain in progress after the channel has been terminated? I mean once you terminate a bridge crossing point there are no cars going over that bridge. It is closed. Their trip has been terminated as well. The question that remains is which of those cars passed the bridge before it was terminated. I understand that you want first to pause that channel looking at the bytes and then terminate. Totally understand. Otherwise the number of bytes transfered (reside) can no longer be queried because the driver cleaned up. Fine. But it should be reported that this transaction is no longer in movement. It won't happen. Never. And this is what bugs me. >> And from [0] the API explanation "4. … dma_async_is_tx_complete()": > > >> >> |Note: >> |Not all DMA engine drivers can return reliable information for >> |a running DMA channel. It is recommended that DMA engine users >> |pause or stop (via dmaengine_terminate_all) the channel before >> |using this API. >> >> So the documentation says to use the cookie with >> dma_async_is_tx_complete() and before doing so it is recommended that >> the transfer should be paused or stopped. _Exactly_ what is done here. >> /* st is still DMA_IN_PROGRESS but _I_ expect DMA_COMPLETE because * it has been terminated / canceled */ Both dma driver clean up all / terminate all descriptors as required but _none_ of them completes the cookie. As a result dma_cookie_status() still thinks that the transfer is in progress. >>> >>> Btw how does it matter in the driver here if the transaction completed or >>> not after terminate_all() was invoked. What is the purpose of querying >>> status. >> >> In the RX interrupt (of the 8250 unit), the code checks if the transfer >> has been already started or not via querying the status. So if it >> returns DMA_COMPLETE then a new transfer will be started. If it returns >> DMA_IN_PROGRESS then the co
[PATCHv3 1/5] rtc: s3c: Define s3c_rtc structure to remove global variables.
This patch define s3c_rtc structure including necessary variables for S3C RTC
device instead of global variables. This patch improves the readability by
removing global variables.
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Cc: Alessandro Zummo
Cc: Andrew Morton
Cc: Kukjin Kim
---
drivers/rtc/rtc-s3c.c | 431 +-
1 file changed, 216 insertions(+), 215 deletions(-)
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 4958a36..2f71b13 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -43,125 +43,132 @@ struct s3c_rtc_drv_data {
int cpu_type;
};
-/* I have yet to find an S3C implementation with more than one
- * of these rtc blocks in */
+struct s3c_rtc {
+ struct device *dev;
+ struct rtc_device *rtc;
+
+ void __iomem *base;
+ struct clk *rtc_clk;
+ bool enabled;
+
+ enum s3c_cpu_type cpu_type;
-static struct clk *rtc_clk;
-static void __iomem *s3c_rtc_base;
-static int s3c_rtc_alarmno;
-static int s3c_rtc_tickno;
-static enum s3c_cpu_type s3c_rtc_cpu_type;
+ int irq_alarm;
+ int irq_tick;
-static DEFINE_SPINLOCK(s3c_rtc_pie_lock);
+ spinlock_t pie_lock;
+ spinlock_t alarm_clk_lock;
-static void s3c_rtc_alarm_clk_enable(bool enable)
+ int ticnt_save, ticnt_en_save;
+ bool wake_en;
+};
+
+static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info, bool enable)
{
- static DEFINE_SPINLOCK(s3c_rtc_alarm_clk_lock);
- static bool alarm_clk_enabled;
unsigned long irq_flags;
- spin_lock_irqsave(&s3c_rtc_alarm_clk_lock, irq_flags);
+ spin_lock_irqsave(&info->alarm_clk_lock, irq_flags);
if (enable) {
- if (!alarm_clk_enabled) {
- clk_enable(rtc_clk);
- alarm_clk_enabled = true;
+ if (!info->enabled) {
+ clk_enable(info->rtc_clk);
+ info->enabled = true;
}
} else {
- if (alarm_clk_enabled) {
- clk_disable(rtc_clk);
- alarm_clk_enabled = false;
+ if (info->enabled) {
+ clk_disable(info->rtc_clk);
+ info->enabled = false;
}
}
- spin_unlock_irqrestore(&s3c_rtc_alarm_clk_lock, irq_flags);
+ spin_unlock_irqrestore(&info->alarm_clk_lock, irq_flags);
}
/* IRQ Handlers */
-
static irqreturn_t s3c_rtc_alarmirq(int irq, void *id)
{
- struct rtc_device *rdev = id;
+ struct s3c_rtc *info = (struct s3c_rtc *)id;
- clk_enable(rtc_clk);
- rtc_update_irq(rdev, 1, RTC_AF | RTC_IRQF);
+ clk_enable(info->rtc_clk);
+ rtc_update_irq(info->rtc, 1, RTC_AF | RTC_IRQF);
- if (s3c_rtc_cpu_type == TYPE_S3C64XX)
- writeb(S3C2410_INTP_ALM, s3c_rtc_base + S3C2410_INTP);
+ if (info->cpu_type == TYPE_S3C64XX)
+ writeb(S3C2410_INTP_ALM, info->base + S3C2410_INTP);
- clk_disable(rtc_clk);
+ clk_disable(info->rtc_clk);
- s3c_rtc_alarm_clk_enable(false);
+ s3c_rtc_alarm_clk_enable(info, false);
return IRQ_HANDLED;
}
static irqreturn_t s3c_rtc_tickirq(int irq, void *id)
{
- struct rtc_device *rdev = id;
+ struct s3c_rtc *info = (struct s3c_rtc *)id;
- clk_enable(rtc_clk);
- rtc_update_irq(rdev, 1, RTC_PF | RTC_IRQF);
+ clk_enable(info->rtc_clk);
+ rtc_update_irq(info->rtc, 1, RTC_PF | RTC_IRQF);
- if (s3c_rtc_cpu_type == TYPE_S3C64XX)
- writeb(S3C2410_INTP_TIC, s3c_rtc_base + S3C2410_INTP);
+ if (info->cpu_type == TYPE_S3C64XX)
+ writeb(S3C2410_INTP_TIC, info->base + S3C2410_INTP);
+
+ clk_disable(info->rtc_clk);
- clk_disable(rtc_clk);
return IRQ_HANDLED;
}
/* Update control registers */
static int s3c_rtc_setaie(struct device *dev, unsigned int enabled)
{
+ struct s3c_rtc *info = dev_get_drvdata(dev);
unsigned int tmp;
- dev_dbg(dev, "%s: aie=%d\n", __func__, enabled);
+ dev_dbg(info->dev, "%s: aie=%d\n", __func__, enabled);
- clk_enable(rtc_clk);
- tmp = readb(s3c_rtc_base + S3C2410_RTCALM) & ~S3C2410_RTCALM_ALMEN;
+ clk_enable(info->rtc_clk);
+ tmp = readb(info->base + S3C2410_RTCALM) & ~S3C2410_RTCALM_ALMEN;
if (enabled)
tmp |= S3C2410_RTCALM_ALMEN;
- writeb(tmp, s3c_rtc_base + S3C2410_RTCALM);
- clk_disable(rtc_clk);
+ writeb(tmp, info->base + S3C2410_RTCALM);
+ clk_disable(info->rtc_clk);
- s3c_rtc_alarm_clk_enable(enabled);
+ s3c_rtc_alarm_clk_enable(info, enabled);
return 0;
}
-static int s3c_rtc_setfreq(struct device *dev, int freq)
+static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
{
- struct platform_device *pdev = to_platform_device(dev);
- struct rtc_de
[PATCHv3 4/5] rtc: s3c: Add support for RTC of Exynos3250 SoC
This patch add support for RTC of Exynos3250 SoC. The Exynos3250 needs source
clock(32.768KHz) for RTC block. If source clock of RTC is registerd on clock
list of common clk framework, Exynos RTC drvier have to control this clock.
Clock list for s3c-rtc device:
- rtc : CLK_RTC of CLK_GATE_IP_PERIR is gate clock for RTC.
- rtc_src : XrtcXTI is 32.768.kHz source clock for RTC.
(XRTCXTI: Specifies a clock from 32.768 kHz crystal pad with XRTCXTI and
XRTCXTO pins. RTC uses this clock as the source of a real-time clock.)
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Cc: Alessandro Zummo
Cc: Kukjin Kim
Cc: Andrew Morton
---
Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 1 +
drivers/rtc/rtc-s3c.c | 93 ++-
2 files changed, 93 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
index 06db446..ab757b84 100644
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
@@ -6,6 +6,7 @@ Required properties:
* "samsung,s3c2416-rtc" - for controllers compatible with s3c2416 rtc.
* "samsung,s3c2443-rtc" - for controllers compatible with s3c2443 rtc.
* "samsung,s3c6410-rtc" - for controllers compatible with s3c6410 rtc.
+* "samsung,exynos3250-rtc" - for controllers compatible with exynos3250
rtc.
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: Two interrupt numbers to the cpu should be specified. First
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 0d90892..a6b1252 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -38,6 +38,7 @@ struct s3c_rtc {
void __iomem *base;
struct clk *rtc_clk;
+ struct clk *rtc_src_clk;
bool enabled;
struct s3c_rtc_data *data;
@@ -54,6 +55,7 @@ struct s3c_rtc {
struct s3c_rtc_data {
int max_user_freq;
+ bool needs_src_clk;
void (*irq_handler) (struct s3c_rtc *info, int mask);
void (*set_freq) (struct s3c_rtc *info, int freq);
@@ -73,10 +75,14 @@ static void s3c_rtc_alarm_clk_enable(struct s3c_rtc *info,
bool enable)
if (enable) {
if (!info->enabled) {
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
info->enabled = true;
}
} else {
if (info->enabled) {
+ if (info->data->needs_src_clk)
+ clk_disable(info->rtc_src_clk);
clk_disable(info->rtc_clk);
info->enabled = false;
}
@@ -114,12 +120,16 @@ static int s3c_rtc_setaie(struct device *dev, unsigned
int enabled)
dev_dbg(info->dev, "%s: aie=%d\n", __func__, enabled);
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
tmp = readb(info->base + S3C2410_RTCALM) & ~S3C2410_RTCALM_ALMEN;
if (enabled)
tmp |= S3C2410_RTCALM_ALMEN;
writeb(tmp, info->base + S3C2410_RTCALM);
+ if (info->data->needs_src_clk)
+ clk_disable(info->rtc_src_clk);
clk_disable(info->rtc_clk);
s3c_rtc_alarm_clk_enable(info, enabled);
@@ -134,12 +144,16 @@ static int s3c_rtc_setfreq(struct s3c_rtc *info, int freq)
return -EINVAL;
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
spin_lock_irq(&info->pie_lock);
if (info->data->set_freq)
info->data->set_freq(info, freq);
spin_unlock_irq(&info->pie_lock);
+ if (info->data->needs_src_clk)
+ clk_disable(info->rtc_src_clk);
clk_disable(info->rtc_clk);
return 0;
@@ -152,6 +166,9 @@ static int s3c_rtc_gettime(struct device *dev, struct
rtc_time *rtc_tm)
unsigned int have_retried = 0;
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
+
retry_get_time:
rtc_tm->tm_min = readb(info->base + S3C2410_RTCMIN);
rtc_tm->tm_hour = readb(info->base + S3C2410_RTCHOUR);
@@ -185,6 +202,8 @@ static int s3c_rtc_gettime(struct device *dev, struct
rtc_time *rtc_tm)
rtc_tm->tm_mon -= 1;
+ if (info->data->needs_src_clk)
+ clk_disable(info->rtc_src_clk);
clk_disable(info->rtc_clk);
return rtc_valid_tm(rtc_tm);
@@ -207,6 +226,8 @@ static int s3c_rtc_settime(struct device *dev, struct
rtc_time *tm)
}
clk_enable(info->rtc_clk);
+ if (info->data->needs_src_clk)
+ clk_enable(info->rtc_src_clk);
writeb(bin2bcd(tm->tm_sec), info->base +
[PATCHv3 5/5] ARM: dts: Fix wrong compatible string of Exynos3250 RTC dt node
This patch fix wrong compatible string of Exynos3250 RTC (Real-Time Clock) dt
node. The RTC of Exynos3250 must need additional source clock (XrtcXTI).
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Cc: Alessandro Zummo
Cc: Kukjin Kim
Cc: Andrew Morton
---
arch/arm/boot/dts/exynos3250.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/exynos3250.dtsi
b/arch/arm/boot/dts/exynos3250.dtsi
index 1d52de6..429a6c6 100644
--- a/arch/arm/boot/dts/exynos3250.dtsi
+++ b/arch/arm/boot/dts/exynos3250.dtsi
@@ -164,7 +164,7 @@
};
rtc: rtc@1007 {
- compatible = "samsung,s3c6410-rtc";
+ compatible = "samsung,exynos3250-rtc";
reg = <0x1007 0x100>;
interrupts = <0 73 0>, <0 74 0>;
status = "disabled";
--
1.8.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 2/5] rtc: s3c: Remove warning message when checking coding style with checkpatch script
This patch remove warning message when checking codeing style with checkpatch
script and reduce un-necessary i2c read operation on s3c_rtc_enable.
WARNING: line over 80 characters
#406: FILE: drivers/rtc/rtc-s3c.c:406:
+ if ((readw(info->base + S3C2410_RTCCON) &
S3C2410_RTCCON_RTCEN) == 0) {
WARNING: line over 80 characters
#414: FILE: drivers/rtc/rtc-s3c.c:414:
+ if ((readw(info->base + S3C2410_RTCCON) &
S3C2410_RTCCON_CNTSEL)) {
WARNING: line over 80 characters
#422: FILE: drivers/rtc/rtc-s3c.c:422:
+ if ((readw(info->base + S3C2410_RTCCON) &
S3C2410_RTCCON_CLKRST)) {
WARNING: Missing a blank line after declarations
#451: FILE: drivers/rtc/rtc-s3c.c:451:
+ struct s3c_rtc_drv_data *data;
+ if (pdev->dev.of_node) {
WARNING: Missing a blank line after declarations
#453: FILE: drivers/rtc/rtc-s3c.c:453:
+ const struct of_device_id *match;
+ match = of_match_node(s3c_rtc_dt_match,
pdev->dev.of_node);
WARNING: DT compatible string "samsung,s3c2416-rtc" appears
un-documented -- check ./Documentation/devicetree/bindings/
#650: FILE: drivers/rtc/rtc-s3c.c:650:
+ .compatible = "samsung,s3c2416-rtc",
WARNING: DT compatible string "samsung,s3c2443-rtc" appears
un-documented -- check ./Documentation/devicetree/bindings/
#653: FILE: drivers/rtc/rtc-s3c.c:653:
+ .compatible = "samsung,s3c2443-rtc",
Signed-off-by: Chanwoo Choi
Acked-by: Kyungmin Park
Cc: Alessandro Zummo
Cc: Kukjin Kim
Cc: Andrew Morton
---
Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 2 ++
drivers/rtc/rtc-s3c.c | 26 ---
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
index 7ac7259..06db446 100644
--- a/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/s3c-rtc.txt
@@ -3,6 +3,8 @@
Required properties:
- compatible: should be one of the following.
* "samsung,s3c2410-rtc" - for controllers compatible with s3c2410 rtc.
+* "samsung,s3c2416-rtc" - for controllers compatible with s3c2416 rtc.
+* "samsung,s3c2443-rtc" - for controllers compatible with s3c2443 rtc.
* "samsung,s3c6410-rtc" - for controllers compatible with s3c6410 rtc.
- reg: physical base address of the controller and length of memory mapped
region.
diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
index 2f71b13..4e95cca 100644
--- a/drivers/rtc/rtc-s3c.c
+++ b/drivers/rtc/rtc-s3c.c
@@ -382,25 +382,25 @@ static const struct rtc_class_ops s3c_rtcops = {
static void s3c_rtc_enable(struct s3c_rtc *info, int en)
{
- unsigned int tmp;
+ unsigned int con, tmp;
clk_enable(info->rtc_clk);
+
+ con = readw(info->base + S3C2410_RTCCON);
if (!en) {
- tmp = readw(info->base + S3C2410_RTCCON);
if (info->cpu_type == TYPE_S3C64XX)
- tmp &= ~S3C64XX_RTCCON_TICEN;
- tmp &= ~S3C2410_RTCCON_RTCEN;
- writew(tmp, info->base + S3C2410_RTCCON);
+ con &= ~S3C64XX_RTCCON_TICEN;
+ con &= ~S3C2410_RTCCON_RTCEN;
+ writew(con, info->base + S3C2410_RTCCON);
if (info->cpu_type != TYPE_S3C64XX) {
- tmp = readb(info->base + S3C2410_TICNT);
- tmp &= ~S3C2410_TICNT_ENABLE;
- writeb(tmp, info->base + S3C2410_TICNT);
+ con = readb(info->base + S3C2410_TICNT);
+ con &= ~S3C2410_TICNT_ENABLE;
+ writeb(con, info->base + S3C2410_TICNT);
}
} else {
/* re-enable the device, and check it is ok */
-
- if ((readw(info->base + S3C2410_RTCCON) & S3C2410_RTCCON_RTCEN)
== 0) {
+ if ((con & S3C2410_RTCCON_RTCEN) == 0) {
dev_info(info->dev, "rtc disabled, re-enabling\n");
tmp = readw(info->base + S3C2410_RTCCON);
@@ -408,7 +408,7 @@ static void s3c_rtc_enable(struct s3c_rtc *info, int en)
info->base + S3C2410_RTCCON);
}
- if ((readw(info->base + S3C2410_RTCCON) &
S3C2410_RTCCON_CNTSEL)) {
+ if (con & S3C2410_RTCCON_CNTSEL) {
dev_info(info->dev, "removing RTCCON_CNTSEL\n");
tmp = readw(info->base + S3C2410_RTCCON);
@@ -416,7 +416,7 @@ static void s3c_rtc_enable(struct s3c_rtc *info, int en)
info->base + S3C2410_RTCCON);
}
- if ((readw(info->base + S3C2410_RTCCON) &
S3C24
[PATCH v2 00/17] drm/exynos/ipp: image post processing fixes and improvements, part four
This set of patches contains various improvement and fixes for exynos_drm ipp framework. The patchset is based on exynos-drm-next branch. IPP framework was tested for regressions on exynos4210-trats target. In the 2nd version of the series I have included changes proposed by Joonyoung Shim. I have decided to resend whole series because the changes caused merge conflicts and two separate patches have been added to the series. Changes are described in comit messages. Regards Andrzej Andrzej Hajda (17): drm/exynos/ipp: remove fake pm callbacks drm/exynos/ipp: cancel works before command node clean drm/exynos/ipp: move file reference from memory to command node drm/exynos/ipp: remove only related commands on file close drm/exynos/ipp: remove unused field in command node drm/exynos/ipp: free partially allocated resources on error drm/exynos/ipp: move nodes cleaning to separate function drm/exynos/ipp: clean memory nodes on command node cleaning drm/exynos/ipp: replace work_struct casting with better constructs drm/exynos/ipp: stop hardware before freeing memory drm/exynos/ipp: remove events during command cleaning drm/exynos/fimc: avoid clearing overflow bits drm/exynos/fimc: do not enable fimc twice drm/exynos/fimc: simplify buffer queuing drm/exynos/fimc: fix source buffer registers drm/exynos/ipp: remove file argument from node related functions drm/exynos/ipp: add file checks for ioctls drivers/gpu/drm/exynos/exynos_drm_fimc.c| 90 ++- drivers/gpu/drm/exynos/exynos_drm_gsc.c | 3 +- drivers/gpu/drm/exynos/exynos_drm_ipp.c | 397 drivers/gpu/drm/exynos/exynos_drm_ipp.h | 4 +- drivers/gpu/drm/exynos/exynos_drm_rotator.c | 3 +- 5 files changed, 195 insertions(+), 302 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 11/17] drm/exynos/ipp: remove events during command cleaning
Events were removed only during stop command, as a result
there were memory leaks if program prematurely exited.
This patch fixes it.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 155
1 file changed, 78 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 341db52..05f0f4e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -600,6 +600,81 @@ static void ipp_clean_mem_nodes(struct drm_device *drm_dev,
mutex_unlock(&c_node->mem_lock);
}
+static void ipp_free_event(struct drm_pending_event *event)
+{
+ kfree(event);
+}
+
+static int ipp_get_event(struct drm_device *drm_dev,
+ struct drm_file *file,
+ struct drm_exynos_ipp_cmd_node *c_node,
+ struct drm_exynos_ipp_queue_buf *qbuf)
+{
+ struct drm_exynos_ipp_send_event *e;
+ unsigned long flags;
+
+ DRM_DEBUG_KMS("ops_id[%d]buf_id[%d]\n", qbuf->ops_id, qbuf->buf_id);
+
+ e = kzalloc(sizeof(*e), GFP_KERNEL);
+ if (!e) {
+ spin_lock_irqsave(&drm_dev->event_lock, flags);
+ file->event_space += sizeof(e->event);
+ spin_unlock_irqrestore(&drm_dev->event_lock, flags);
+ return -ENOMEM;
+ }
+
+ /* make event */
+ e->event.base.type = DRM_EXYNOS_IPP_EVENT;
+ e->event.base.length = sizeof(e->event);
+ e->event.user_data = qbuf->user_data;
+ e->event.prop_id = qbuf->prop_id;
+ e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id;
+ e->base.event = &e->event.base;
+ e->base.file_priv = file;
+ e->base.destroy = ipp_free_event;
+ mutex_lock(&c_node->event_lock);
+ list_add_tail(&e->base.link, &c_node->event_list);
+ mutex_unlock(&c_node->event_lock);
+
+ return 0;
+}
+
+static void ipp_put_event(struct drm_exynos_ipp_cmd_node *c_node,
+ struct drm_exynos_ipp_queue_buf *qbuf)
+{
+ struct drm_exynos_ipp_send_event *e, *te;
+ int count = 0;
+
+ mutex_lock(&c_node->event_lock);
+ list_for_each_entry_safe(e, te, &c_node->event_list, base.link) {
+ DRM_DEBUG_KMS("count[%d]e[0x%x]\n", count++, (int)e);
+
+ /*
+* qbuf == NULL condition means all event deletion.
+* stop operations want to delete all event list.
+* another case delete only same buf id.
+*/
+ if (!qbuf) {
+ /* delete list */
+ list_del(&e->base.link);
+ kfree(e);
+ }
+
+ /* compare buffer id */
+ if (qbuf && (qbuf->buf_id ==
+ e->event.buf_id[EXYNOS_DRM_OPS_DST])) {
+ /* delete list */
+ list_del(&e->base.link);
+ kfree(e);
+ goto out_unlock;
+ }
+ }
+
+out_unlock:
+ mutex_unlock(&c_node->event_lock);
+ return;
+}
+
static void ipp_clean_cmd_node(struct ipp_context *ctx,
struct drm_exynos_ipp_cmd_node *c_node)
{
@@ -610,6 +685,9 @@ static void ipp_clean_cmd_node(struct ipp_context *ctx,
cancel_work_sync(&c_node->stop_work->work);
cancel_work_sync(&c_node->event_work->work);
+ /* put event */
+ ipp_put_event(c_node, NULL);
+
for_each_ipp_ops(i)
ipp_clean_mem_nodes(ctx->subdrv.drm_dev, c_node, i);
@@ -706,81 +784,6 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv
*ippdrv,
return ret;
}
-static void ipp_free_event(struct drm_pending_event *event)
-{
- kfree(event);
-}
-
-static int ipp_get_event(struct drm_device *drm_dev,
- struct drm_file *file,
- struct drm_exynos_ipp_cmd_node *c_node,
- struct drm_exynos_ipp_queue_buf *qbuf)
-{
- struct drm_exynos_ipp_send_event *e;
- unsigned long flags;
-
- DRM_DEBUG_KMS("ops_id[%d]buf_id[%d]\n", qbuf->ops_id, qbuf->buf_id);
-
- e = kzalloc(sizeof(*e), GFP_KERNEL);
- if (!e) {
- spin_lock_irqsave(&drm_dev->event_lock, flags);
- file->event_space += sizeof(e->event);
- spin_unlock_irqrestore(&drm_dev->event_lock, flags);
- return -ENOMEM;
- }
-
- /* make event */
- e->event.base.type = DRM_EXYNOS_IPP_EVENT;
- e->event.base.length = sizeof(e->event);
- e->event.user_data = qbuf->user_data;
- e->event.prop_id = qbuf->prop_id;
- e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id;
- e->base.event = &e->event.base;
- e->base.file_priv = file;
- e->base.destroy = ipp_free_event;
- mutex_lock(&c_node->event_lock);
- list_add_tail(&e->base.link, &c_node->
[PATCH v2 04/17] drm/exynos/ipp: remove only related commands on file close
On file close driver should remove only command nodes created
via this file.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index bbe9968..81f780e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1681,14 +1681,11 @@ static int ipp_subdrv_open(struct drm_device *drm_dev,
struct device *dev,
static void ipp_subdrv_close(struct drm_device *drm_dev, struct device *dev,
struct drm_file *file)
{
- struct drm_exynos_file_private *file_priv = file->driver_priv;
struct exynos_drm_ippdrv *ippdrv = NULL;
struct ipp_context *ctx = get_ipp_context(dev);
struct drm_exynos_ipp_cmd_node *c_node, *tc_node;
int count = 0;
- DRM_DEBUG_KMS("for priv[0x%x]\n", (int)file_priv->ipp_dev);
-
list_for_each_entry(ippdrv, &exynos_drm_ippdrv_list, drv_list) {
mutex_lock(&ippdrv->cmd_lock);
list_for_each_entry_safe(c_node, tc_node,
@@ -1696,7 +1693,7 @@ static void ipp_subdrv_close(struct drm_device *drm_dev,
struct device *dev,
DRM_DEBUG_KMS("count[%d]ippdrv[0x%x]\n",
count++, (int)ippdrv);
- if (c_node->dev == file_priv->ipp_dev) {
+ if (c_node->filp == file) {
/*
* userland goto unnormal state. process killed.
* and close the file.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 15/17] drm/exynos/fimc: fix source buffer registers
FIMC in default mode of operation uses only one input buffer,
but the driver used also second buffer, as a result only the
first frame was processed correctly. The patch fixes it.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 59ba8bb..e2c43b4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -722,24 +722,24 @@ static int fimc_src_set_addr(struct device *dev,
case IPP_BUF_ENQUEUE:
config = &property->config[EXYNOS_DRM_OPS_SRC];
fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_Y],
- EXYNOS_CIIYSA(buf_id));
+ EXYNOS_CIIYSA0);
if (config->fmt == DRM_FORMAT_YVU420) {
fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CR],
- EXYNOS_CIICBSA(buf_id));
+ EXYNOS_CIICBSA0);
fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CB],
- EXYNOS_CIICRSA(buf_id));
+ EXYNOS_CIICRSA0);
} else {
fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CB],
- EXYNOS_CIICBSA(buf_id));
+ EXYNOS_CIICBSA0);
fimc_write(ctx, buf_info->base[EXYNOS_DRM_PLANAR_CR],
- EXYNOS_CIICRSA(buf_id));
+ EXYNOS_CIICRSA0);
}
break;
case IPP_BUF_DEQUEUE:
- fimc_write(ctx, 0x0, EXYNOS_CIIYSA(buf_id));
- fimc_write(ctx, 0x0, EXYNOS_CIICBSA(buf_id));
- fimc_write(ctx, 0x0, EXYNOS_CIICRSA(buf_id));
+ fimc_write(ctx, 0x0, EXYNOS_CIIYSA0);
+ fimc_write(ctx, 0x0, EXYNOS_CIICBSA0);
+ fimc_write(ctx, 0x0, EXYNOS_CIICRSA0);
break;
default:
/* bypass */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 16/17] drm/exynos/ipp: remove file argument from node related functions
Since file pointer is preserved in c_node passing it
as argument in node functions is redundant.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 05f0f4e..fc8bb67 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -529,7 +529,6 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
static struct drm_exynos_ipp_mem_node
*ipp_get_mem_node(struct drm_device *drm_dev,
- struct drm_file *file,
struct drm_exynos_ipp_cmd_node *c_node,
struct drm_exynos_ipp_queue_buf *qbuf)
{
@@ -560,7 +559,7 @@ static struct drm_exynos_ipp_mem_node
dma_addr_t *addr;
addr = exynos_drm_gem_get_dma_addr(drm_dev,
- qbuf->handle[i], file);
+ qbuf->handle[i], c_node->filp);
if (IS_ERR(addr)) {
DRM_ERROR("failed to get addr.\n");
ipp_put_mem_node(drm_dev, c_node, m_node);
@@ -606,7 +605,6 @@ static void ipp_free_event(struct drm_pending_event *event)
}
static int ipp_get_event(struct drm_device *drm_dev,
- struct drm_file *file,
struct drm_exynos_ipp_cmd_node *c_node,
struct drm_exynos_ipp_queue_buf *qbuf)
{
@@ -618,7 +616,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
e = kzalloc(sizeof(*e), GFP_KERNEL);
if (!e) {
spin_lock_irqsave(&drm_dev->event_lock, flags);
- file->event_space += sizeof(e->event);
+ c_node->filp->event_space += sizeof(e->event);
spin_unlock_irqrestore(&drm_dev->event_lock, flags);
return -ENOMEM;
}
@@ -630,7 +628,7 @@ static int ipp_get_event(struct drm_device *drm_dev,
e->event.prop_id = qbuf->prop_id;
e->event.buf_id[EXYNOS_DRM_OPS_DST] = qbuf->buf_id;
e->base.event = &e->event.base;
- e->base.file_priv = file;
+ e->base.file_priv = c_node->filp;
e->base.destroy = ipp_free_event;
mutex_lock(&c_node->event_lock);
list_add_tail(&e->base.link, &c_node->event_list);
@@ -899,7 +897,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
void *data,
/* find command node */
c_node = ipp_find_obj(&ctx->prop_idr, &ctx->prop_lock,
qbuf->prop_id);
- if (!c_node) {
+ if (!c_node || c_node->filp != file) {
DRM_ERROR("failed to get command node.\n");
return -ENODEV;
}
@@ -908,7 +906,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
void *data,
switch (qbuf->buf_type) {
case IPP_BUF_ENQUEUE:
/* get memory node */
- m_node = ipp_get_mem_node(drm_dev, file, c_node, qbuf);
+ m_node = ipp_get_mem_node(drm_dev, c_node, qbuf);
if (IS_ERR(m_node)) {
DRM_ERROR("failed to get m_node.\n");
return PTR_ERR(m_node);
@@ -921,7 +919,7 @@ int exynos_drm_ipp_queue_buf(struct drm_device *drm_dev,
void *data,
*/
if (qbuf->ops_id == EXYNOS_DRM_OPS_DST) {
/* get event for destination buffer */
- ret = ipp_get_event(drm_dev, file, c_node, qbuf);
+ ret = ipp_get_event(drm_dev, c_node, qbuf);
if (ret) {
DRM_ERROR("failed to get event.\n");
goto err_clean_node;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 10/17] drm/exynos/ipp: stop hardware before freeing memory
Memory shouldn't be freed when hardware is still running.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index fff3509..341db52 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1282,12 +1282,15 @@ static int ipp_stop_property(struct drm_device *drm_dev,
struct drm_exynos_ipp_cmd_node *c_node)
{
struct drm_exynos_ipp_property *property = &c_node->property;
- int ret = 0, i;
+ int i;
DRM_DEBUG_KMS("prop_id[%d]\n", property->prop_id);
/* put event */
ipp_put_event(c_node, NULL);
+ /* stop operations */
+ if (ippdrv->stop)
+ ippdrv->stop(ippdrv->dev, property->cmd);
/* check command */
switch (property->cmd) {
@@ -1303,16 +1306,10 @@ static int ipp_stop_property(struct drm_device *drm_dev,
break;
default:
DRM_ERROR("invalid operations.\n");
- ret = -EINVAL;
- goto err_clear;
+ return -EINVAL;
}
-err_clear:
- /* stop operations */
- if (ippdrv->stop)
- ippdrv->stop(ippdrv->dev, property->cmd);
-
- return ret;
+ return 0;
}
void ipp_sched_cmd(struct work_struct *work)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 03/17] drm/exynos/ipp: move file reference from memory to command node
Command node should contain file reference to distinguish commands
created by different processes.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 ++---
drivers/gpu/drm/exynos/exynos_drm_ipp.h | 2 ++
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 9770966..bbe9968 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -75,7 +75,6 @@ struct drm_exynos_ipp_mem_node {
u32 prop_id;
u32 buf_id;
struct drm_exynos_ipp_buf_info buf_info;
- struct drm_file *filp;
};
/*
@@ -448,6 +447,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev,
void *data,
c_node->dev = dev;
c_node->property = *property;
c_node->state = IPP_STATE_IDLE;
+ c_node->filp = file;
c_node->start_work = ipp_create_cmd_work();
if (IS_ERR(c_node->start_work)) {
@@ -645,7 +645,6 @@ static struct drm_exynos_ipp_mem_node
}
}
- m_node->filp = file;
mutex_lock(&c_node->mem_lock);
list_add_tail(&m_node->list, &c_node->mem_list[qbuf->ops_id]);
mutex_unlock(&c_node->mem_lock);
@@ -677,7 +676,7 @@ static int ipp_put_mem_node(struct drm_device *drm_dev,
unsigned long handle = m_node->buf_info.handles[i];
if (handle)
exynos_drm_gem_put_dma_addr(drm_dev, handle,
- m_node->filp);
+ c_node->filp);
}
/* delete list in queue */
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index 6f48d62..0311035 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
@@ -62,6 +62,7 @@ struct drm_exynos_ipp_cmd_work {
* @stop_work: stop command work structure.
* @event_work: event work structure.
* @state: state of command node.
+ * @filp: associated file pointer.
*/
struct drm_exynos_ipp_cmd_node {
struct device *dev;
@@ -78,6 +79,7 @@ struct drm_exynos_ipp_cmd_node {
struct drm_exynos_ipp_cmd_work *stop_work;
struct drm_exynos_ipp_event_work *event_work;
enum drm_exynos_ipp_state state;
+ struct drm_file *filp;
};
/*
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 17/17] drm/exynos/ipp: add file checks for ioctls
Process should not have access to ipp nodes created by another
process. The patch adds necessary checks.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index fc8bb67..d233cfc 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -318,7 +318,8 @@ static void ipp_print_property(struct
drm_exynos_ipp_property *property,
sz->hsize, sz->vsize, config->flip, config->degree);
}
-static int ipp_find_and_set_property(struct drm_exynos_ipp_property *property)
+static int ipp_find_and_set_property(struct drm_exynos_ipp_property *property,
+ struct drm_file *file)
{
struct exynos_drm_ippdrv *ippdrv;
struct drm_exynos_ipp_cmd_node *c_node;
@@ -339,8 +340,12 @@ static int ipp_find_and_set_property(struct
drm_exynos_ipp_property *property)
*/
mutex_lock(&ippdrv->cmd_lock);
list_for_each_entry(c_node, &ippdrv->cmd_list, list) {
- if ((c_node->property.prop_id == prop_id) &&
- (c_node->state == IPP_STATE_STOP)) {
+ if (c_node->property.prop_id == prop_id) {
+ if (c_node->filp != file)
+ break;
+ if (c_node->state != IPP_STATE_STOP)
+ break;
+
mutex_unlock(&ippdrv->cmd_lock);
DRM_DEBUG_KMS("found cmd[%d]ippdrv[0x%x]\n",
property->cmd, (int)ippdrv);
@@ -418,7 +423,7 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev,
void *data,
*/
if (property->prop_id) {
DRM_DEBUG_KMS("prop_id[%d]\n", property->prop_id);
- return ipp_find_and_set_property(property);
+ return ipp_find_and_set_property(property, file);
}
/* find ipp driver using ipp id */
@@ -1032,7 +1037,7 @@ int exynos_drm_ipp_cmd_ctrl(struct drm_device *drm_dev,
void *data,
c_node = ipp_find_obj(&ctx->prop_idr, &ctx->prop_lock,
cmd_ctrl->prop_id);
- if (!c_node) {
+ if (!c_node || c_node->filp != file) {
DRM_ERROR("invalid command node list.\n");
return -ENODEV;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 12/17] drm/exynos/fimc: avoid clearing overflow bits
Overflow bits shall be cleared by H/W. Signed-off-by: Andrzej Hajda Reviewed-by: Joonyoung Shim --- drivers/gpu/drm/exynos/exynos_drm_fimc.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c b/drivers/gpu/drm/exynos/exynos_drm_fimc.c index 34367ff..6dc9c41 100644 --- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c +++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c @@ -341,9 +341,6 @@ static bool fimc_check_ovf(struct fimc_context *ctx) fimc_set_bits(ctx, EXYNOS_CIWDOFST, EXYNOS_CIWDOFST_CLROVFIY | EXYNOS_CIWDOFST_CLROVFICB | EXYNOS_CIWDOFST_CLROVFICR); - fimc_clear_bits(ctx, EXYNOS_CIWDOFST, - EXYNOS_CIWDOFST_CLROVFIY | EXYNOS_CIWDOFST_CLROVFICB | - EXYNOS_CIWDOFST_CLROVFICR); dev_err(ippdrv->dev, "occurred overflow at %d, status 0x%x.\n", ctx->id, status); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 02/17] drm/exynos/ipp: cancel works before command node clean
All pending works should be canceled prior to its removal.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index da917ca..9770966 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -502,6 +502,11 @@ err_clear:
static void ipp_clean_cmd_node(struct ipp_context *ctx,
struct drm_exynos_ipp_cmd_node *c_node)
{
+ /* cancel works */
+ cancel_work_sync(&c_node->start_work->work);
+ cancel_work_sync(&c_node->stop_work->work);
+ cancel_work_sync(&c_node->event_work->work);
+
/* delete list */
list_del(&c_node->list);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 01/17] drm/exynos/ipp: remove fake pm callbacks
PM callbacks in ipp core do nothing, so the patch removes it.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 51 -
1 file changed, 51 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index c411399..da917ca 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -1808,63 +1808,12 @@ static int ipp_remove(struct platform_device *pdev)
return 0;
}
-static int ipp_power_ctrl(struct ipp_context *ctx, bool enable)
-{
- DRM_DEBUG_KMS("enable[%d]\n", enable);
-
- return 0;
-}
-
-#ifdef CONFIG_PM_SLEEP
-static int ipp_suspend(struct device *dev)
-{
- struct ipp_context *ctx = get_ipp_context(dev);
-
- if (pm_runtime_suspended(dev))
- return 0;
-
- return ipp_power_ctrl(ctx, false);
-}
-
-static int ipp_resume(struct device *dev)
-{
- struct ipp_context *ctx = get_ipp_context(dev);
-
- if (!pm_runtime_suspended(dev))
- return ipp_power_ctrl(ctx, true);
-
- return 0;
-}
-#endif
-
-#ifdef CONFIG_PM_RUNTIME
-static int ipp_runtime_suspend(struct device *dev)
-{
- struct ipp_context *ctx = get_ipp_context(dev);
-
- return ipp_power_ctrl(ctx, false);
-}
-
-static int ipp_runtime_resume(struct device *dev)
-{
- struct ipp_context *ctx = get_ipp_context(dev);
-
- return ipp_power_ctrl(ctx, true);
-}
-#endif
-
-static const struct dev_pm_ops ipp_pm_ops = {
- SET_SYSTEM_SLEEP_PM_OPS(ipp_suspend, ipp_resume)
- SET_RUNTIME_PM_OPS(ipp_runtime_suspend, ipp_runtime_resume, NULL)
-};
-
struct platform_driver ipp_driver = {
.probe = ipp_probe,
.remove = ipp_remove,
.driver = {
.name = "exynos-drm-ipp",
.owner = THIS_MODULE,
- .pm = &ipp_pm_ops,
},
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 09/17] drm/exynos/ipp: replace work_struct casting with better constructs
Type casting should be avoided if possible. In case of
work_struct it can be simply replaced by reference to member field.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c| 2 +-
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 3 +--
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 6 +++---
drivers/gpu/drm/exynos/exynos_drm_rotator.c | 3 +--
4 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 177e7bc..34367ff 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1309,7 +1309,7 @@ static irqreturn_t fimc_irq_handler(int irq, void *dev_id)
event_work->ippdrv = ippdrv;
event_work->buf_id[EXYNOS_DRM_OPS_DST] = buf_id;
- queue_work(ippdrv->event_workq, (struct work_struct *)event_work);
+ queue_work(ippdrv->event_workq, &event_work->work);
return IRQ_HANDLED;
}
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 9e3ff16..c6a013f 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1326,8 +1326,7 @@ static irqreturn_t gsc_irq_handler(int irq, void *dev_id)
buf_id[EXYNOS_DRM_OPS_SRC];
event_work->buf_id[EXYNOS_DRM_OPS_DST] =
buf_id[EXYNOS_DRM_OPS_DST];
- queue_work(ippdrv->event_workq,
- (struct work_struct *)event_work);
+ queue_work(ippdrv->event_workq, &event_work->work);
}
return IRQ_HANDLED;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 857817c..fff3509 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -790,7 +790,7 @@ static void ipp_handle_cmd_work(struct device *dev,
cmd_work->ippdrv = ippdrv;
cmd_work->c_node = c_node;
- queue_work(ctx->cmd_workq, (struct work_struct *)cmd_work);
+ queue_work(ctx->cmd_workq, &cmd_work->work);
}
static int ipp_queue_buf_with_run(struct device *dev,
@@ -1318,7 +1318,7 @@ err_clear:
void ipp_sched_cmd(struct work_struct *work)
{
struct drm_exynos_ipp_cmd_work *cmd_work =
- (struct drm_exynos_ipp_cmd_work *)work;
+ container_of(work, struct drm_exynos_ipp_cmd_work, work);
struct exynos_drm_ippdrv *ippdrv;
struct drm_exynos_ipp_cmd_node *c_node;
struct drm_exynos_ipp_property *property;
@@ -1531,7 +1531,7 @@ err_event_unlock:
void ipp_sched_event(struct work_struct *work)
{
struct drm_exynos_ipp_event_work *event_work =
- (struct drm_exynos_ipp_event_work *)work;
+ container_of(work, struct drm_exynos_ipp_event_work, work);
struct exynos_drm_ippdrv *ippdrv;
struct drm_exynos_ipp_cmd_node *c_node;
int ret;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
index 55af6b4..b6a37d4 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_rotator.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_rotator.c
@@ -156,8 +156,7 @@ static irqreturn_t rotator_irq_handler(int irq, void *arg)
event_work->ippdrv = ippdrv;
event_work->buf_id[EXYNOS_DRM_OPS_DST] =
rot->cur_buf_id[EXYNOS_DRM_OPS_DST];
- queue_work(ippdrv->event_workq,
- (struct work_struct *)event_work);
+ queue_work(ippdrv->event_workq, &event_work->work);
} else {
DRM_ERROR("the SFR is set illegally\n");
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 07/17] drm/exynos/ipp: move nodes cleaning to separate function
The patch introduces ipp_clean_mem_nodes function which replaces
redundant code. Additionally memory node function definitions
are moved up to increase its visibility.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 229 +++-
1 file changed, 106 insertions(+), 123 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index ab7b74c..05f103e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -498,6 +498,108 @@ err_clear:
return ret;
}
+static int ipp_put_mem_node(struct drm_device *drm_dev,
+ struct drm_exynos_ipp_cmd_node *c_node,
+ struct drm_exynos_ipp_mem_node *m_node)
+{
+ int i;
+
+ DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
+
+ if (!m_node) {
+ DRM_ERROR("invalid dequeue node.\n");
+ return -EFAULT;
+ }
+
+ DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
+
+ /* put gem buffer */
+ for_each_ipp_planar(i) {
+ unsigned long handle = m_node->buf_info.handles[i];
+ if (handle)
+ exynos_drm_gem_put_dma_addr(drm_dev, handle,
+ c_node->filp);
+ }
+
+ list_del(&m_node->list);
+ kfree(m_node);
+
+ return 0;
+}
+
+static struct drm_exynos_ipp_mem_node
+ *ipp_get_mem_node(struct drm_device *drm_dev,
+ struct drm_file *file,
+ struct drm_exynos_ipp_cmd_node *c_node,
+ struct drm_exynos_ipp_queue_buf *qbuf)
+{
+ struct drm_exynos_ipp_mem_node *m_node;
+ struct drm_exynos_ipp_buf_info *buf_info;
+ int i;
+
+ m_node = kzalloc(sizeof(*m_node), GFP_KERNEL);
+ if (!m_node)
+ return ERR_PTR(-ENOMEM);
+
+ buf_info = &m_node->buf_info;
+
+ /* operations, buffer id */
+ m_node->ops_id = qbuf->ops_id;
+ m_node->prop_id = qbuf->prop_id;
+ m_node->buf_id = qbuf->buf_id;
+ INIT_LIST_HEAD(&m_node->list);
+
+ DRM_DEBUG_KMS("m_node[0x%x]ops_id[%d]\n", (int)m_node, qbuf->ops_id);
+ DRM_DEBUG_KMS("prop_id[%d]buf_id[%d]\n", qbuf->prop_id, m_node->buf_id);
+
+ for_each_ipp_planar(i) {
+ DRM_DEBUG_KMS("i[%d]handle[0x%x]\n", i, qbuf->handle[i]);
+
+ /* get dma address by handle */
+ if (qbuf->handle[i]) {
+ dma_addr_t *addr;
+
+ addr = exynos_drm_gem_get_dma_addr(drm_dev,
+ qbuf->handle[i], file);
+ if (IS_ERR(addr)) {
+ DRM_ERROR("failed to get addr.\n");
+ ipp_put_mem_node(drm_dev, c_node, m_node);
+ return ERR_PTR(-EFAULT);
+ }
+
+ buf_info->handles[i] = qbuf->handle[i];
+ buf_info->base[i] = *addr;
+ DRM_DEBUG_KMS("i[%d]base[0x%x]hd[0x%lx]\n", i,
+ buf_info->base[i], buf_info->handles[i]);
+ }
+ }
+
+ mutex_lock(&c_node->mem_lock);
+ list_add_tail(&m_node->list, &c_node->mem_list[qbuf->ops_id]);
+ mutex_unlock(&c_node->mem_lock);
+
+ return m_node;
+}
+
+static void ipp_clean_mem_nodes(struct drm_device *drm_dev,
+ struct drm_exynos_ipp_cmd_node *c_node, int ops)
+{
+ struct drm_exynos_ipp_mem_node *m_node, *tm_node;
+ struct list_head *head = &c_node->mem_list[ops];
+
+ mutex_lock(&c_node->mem_lock);
+
+ list_for_each_entry_safe(m_node, tm_node, head, list) {
+ int ret;
+
+ ret = ipp_put_mem_node(drm_dev, c_node, m_node);
+ if (ret)
+ DRM_ERROR("failed to put m_node.\n");
+ }
+
+ mutex_unlock(&c_node->mem_lock);
+}
+
static void ipp_clean_cmd_node(struct ipp_context *ctx,
struct drm_exynos_ipp_cmd_node *c_node)
{
@@ -599,89 +701,6 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv
*ippdrv,
return ret;
}
-static int ipp_put_mem_node(struct drm_device *drm_dev,
- struct drm_exynos_ipp_cmd_node *c_node,
- struct drm_exynos_ipp_mem_node *m_node)
-{
- int i;
-
- DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
-
- if (!m_node) {
- DRM_ERROR("invalid dequeue node.\n");
- return -EFAULT;
- }
-
- DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
-
- /* put gem buffer */
- for_each_ipp_planar(i) {
- unsigned long handle = m_node->buf_info.handles[i];
- if (handle)
- exynos_drm_gem_put_dma_addr(drm_dev, handle,
-
[PATCH v2 06/17] drm/exynos/ipp: free partially allocated resources on error
In case of allocation errors some already allocated buffers
were not freed. The patch fixes it.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 67 -
1 file changed, 32 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 060a198..ab7b74c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -599,6 +599,35 @@ static int ipp_set_mem_node(struct exynos_drm_ippdrv
*ippdrv,
return ret;
}
+static int ipp_put_mem_node(struct drm_device *drm_dev,
+ struct drm_exynos_ipp_cmd_node *c_node,
+ struct drm_exynos_ipp_mem_node *m_node)
+{
+ int i;
+
+ DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
+
+ if (!m_node) {
+ DRM_ERROR("invalid dequeue node.\n");
+ return -EFAULT;
+ }
+
+ DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
+
+ /* put gem buffer */
+ for_each_ipp_planar(i) {
+ unsigned long handle = m_node->buf_info.handles[i];
+ if (handle)
+ exynos_drm_gem_put_dma_addr(drm_dev, handle,
+ c_node->filp);
+ }
+
+ list_del(&m_node->list);
+ kfree(m_node);
+
+ return 0;
+}
+
static struct drm_exynos_ipp_mem_node
*ipp_get_mem_node(struct drm_device *drm_dev,
struct drm_file *file,
@@ -619,6 +648,7 @@ static struct drm_exynos_ipp_mem_node
m_node->ops_id = qbuf->ops_id;
m_node->prop_id = qbuf->prop_id;
m_node->buf_id = qbuf->buf_id;
+ INIT_LIST_HEAD(&m_node->list);
DRM_DEBUG_KMS("m_node[0x%x]ops_id[%d]\n", (int)m_node, qbuf->ops_id);
DRM_DEBUG_KMS("prop_id[%d]buf_id[%d]\n", qbuf->prop_id, m_node->buf_id);
@@ -634,7 +664,8 @@ static struct drm_exynos_ipp_mem_node
qbuf->handle[i], file);
if (IS_ERR(addr)) {
DRM_ERROR("failed to get addr.\n");
- goto err_clear;
+ ipp_put_mem_node(drm_dev, c_node, m_node);
+ return ERR_PTR(-EFAULT);
}
buf_info->handles[i] = qbuf->handle[i];
@@ -649,40 +680,6 @@ static struct drm_exynos_ipp_mem_node
mutex_unlock(&c_node->mem_lock);
return m_node;
-
-err_clear:
- kfree(m_node);
- return ERR_PTR(-EFAULT);
-}
-
-static int ipp_put_mem_node(struct drm_device *drm_dev,
- struct drm_exynos_ipp_cmd_node *c_node,
- struct drm_exynos_ipp_mem_node *m_node)
-{
- int i;
-
- DRM_DEBUG_KMS("node[0x%x]\n", (int)m_node);
-
- if (!m_node) {
- DRM_ERROR("invalid dequeue node.\n");
- return -EFAULT;
- }
-
- DRM_DEBUG_KMS("ops_id[%d]\n", m_node->ops_id);
-
- /* put gem buffer */
- for_each_ipp_planar(i) {
- unsigned long handle = m_node->buf_info.handles[i];
- if (handle)
- exynos_drm_gem_put_dma_addr(drm_dev, handle,
- c_node->filp);
- }
-
- /* delete list in queue */
- list_del(&m_node->list);
- kfree(m_node);
-
- return 0;
}
static void ipp_free_event(struct drm_pending_event *event)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 13/17] drm/exynos/fimc: do not enable fimc twice
The patch removes redundant H/W activation.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 6dc9c41..62ba033 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1598,12 +1598,9 @@ static int fimc_ippdrv_start(struct device *dev, enum
drm_exynos_ipp_cmd cmd)
fimc_clear_bits(ctx, EXYNOS_CIOCTRL, EXYNOS_CIOCTRL_WEAVE_MASK);
- if (cmd == IPP_CMD_M2M) {
+ if (cmd == IPP_CMD_M2M)
fimc_set_bits(ctx, EXYNOS_MSCTRL, EXYNOS_MSCTRL_ENVID);
- fimc_set_bits(ctx, EXYNOS_MSCTRL, EXYNOS_MSCTRL_ENVID);
- }
-
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 08/17] drm/exynos/ipp: clean memory nodes on command node cleaning
The nodes should be removed before removing command node.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 05f103e..857817c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -603,11 +603,16 @@ static void ipp_clean_mem_nodes(struct drm_device
*drm_dev,
static void ipp_clean_cmd_node(struct ipp_context *ctx,
struct drm_exynos_ipp_cmd_node *c_node)
{
+ int i;
+
/* cancel works */
cancel_work_sync(&c_node->start_work->work);
cancel_work_sync(&c_node->stop_work->work);
cancel_work_sync(&c_node->event_work->work);
+ for_each_ipp_ops(i)
+ ipp_clean_mem_nodes(ctx->subdrv.drm_dev, c_node, i);
+
/* delete list */
list_del(&c_node->list);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 14/17] drm/exynos/fimc: simplify buffer queuing
The patch removes redundant checks, redundant HW reads
and simplifies code.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
v2:
- fixed bit cleaning operation
---
drivers/gpu/drm/exynos/exynos_drm_fimc.c | 64
1 file changed, 15 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
index 62ba033..59ba8bb 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fimc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fimc.c
@@ -1126,67 +1126,34 @@ static int fimc_dst_set_size(struct device *dev, int
swap,
return 0;
}
-static int fimc_dst_get_buf_count(struct fimc_context *ctx)
-{
- u32 cfg, buf_num;
-
- cfg = fimc_read(ctx, EXYNOS_CIFCNTSEQ);
-
- buf_num = hweight32(cfg);
-
- DRM_DEBUG_KMS("buf_num[%d]\n", buf_num);
-
- return buf_num;
-}
-
-static int fimc_dst_set_buf_seq(struct fimc_context *ctx, u32 buf_id,
+static void fimc_dst_set_buf_seq(struct fimc_context *ctx, u32 buf_id,
enum drm_exynos_ipp_buf_type buf_type)
{
- struct exynos_drm_ippdrv *ippdrv = &ctx->ippdrv;
- bool enable;
- u32 cfg;
- u32 mask = 0x0001 << buf_id;
- int ret = 0;
unsigned long flags;
+ u32 buf_num;
+ u32 cfg;
DRM_DEBUG_KMS("buf_id[%d]buf_type[%d]\n", buf_id, buf_type);
spin_lock_irqsave(&ctx->lock, flags);
- /* mask register set */
cfg = fimc_read(ctx, EXYNOS_CIFCNTSEQ);
- switch (buf_type) {
- case IPP_BUF_ENQUEUE:
- enable = true;
- break;
- case IPP_BUF_DEQUEUE:
- enable = false;
- break;
- default:
- dev_err(ippdrv->dev, "invalid buf ctrl parameter.\n");
- ret = -EINVAL;
- goto err_unlock;
- }
+ if (buf_type == IPP_BUF_ENQUEUE)
+ cfg |= (1 << buf_id);
+ else
+ cfg &= ~(1 << buf_id);
- /* sequence id */
- cfg &= ~mask;
- cfg |= (enable << buf_id);
fimc_write(ctx, cfg, EXYNOS_CIFCNTSEQ);
- /* interrupt enable */
- if (buf_type == IPP_BUF_ENQUEUE &&
- fimc_dst_get_buf_count(ctx) >= FIMC_BUF_START)
- fimc_mask_irq(ctx, true);
+ buf_num = hweight32(cfg);
- /* interrupt disable */
- if (buf_type == IPP_BUF_DEQUEUE &&
- fimc_dst_get_buf_count(ctx) <= FIMC_BUF_STOP)
+ if (buf_type == IPP_BUF_ENQUEUE && buf_num >= FIMC_BUF_START)
+ fimc_mask_irq(ctx, true);
+ else if (buf_type == IPP_BUF_DEQUEUE && buf_num <= FIMC_BUF_STOP)
fimc_mask_irq(ctx, false);
-err_unlock:
spin_unlock_irqrestore(&ctx->lock, flags);
- return ret;
}
static int fimc_dst_set_addr(struct device *dev,
@@ -1244,7 +1211,9 @@ static int fimc_dst_set_addr(struct device *dev,
break;
}
- return fimc_dst_set_buf_seq(ctx, buf_id, buf_type);
+ fimc_dst_set_buf_seq(ctx, buf_id, buf_type);
+
+ return 0;
}
static struct exynos_drm_ipp_ops fimc_dst_ops = {
@@ -1299,10 +1268,7 @@ static irqreturn_t fimc_irq_handler(int irq, void
*dev_id)
DRM_DEBUG_KMS("buf_id[%d]\n", buf_id);
- if (fimc_dst_set_buf_seq(ctx, buf_id, IPP_BUF_DEQUEUE) < 0) {
- DRM_ERROR("failed to dequeue.\n");
- return IRQ_HANDLED;
- }
+ fimc_dst_set_buf_seq(ctx, buf_id, IPP_BUF_DEQUEUE);
event_work->ippdrv = ippdrv;
event_work->buf_id[EXYNOS_DRM_OPS_DST] = buf_id;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 05/17] drm/exynos/ipp: remove unused field in command node
Since command node have file pointer dev field became useless.
Signed-off-by: Andrzej Hajda
Reviewed-by: Joonyoung Shim
---
drivers/gpu/drm/exynos/exynos_drm_ipp.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_ipp.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
index 81f780e..060a198 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
@@ -444,7 +444,6 @@ int exynos_drm_ipp_set_property(struct drm_device *drm_dev,
void *data,
property->prop_id, property->cmd, (int)ippdrv);
/* stored property information and ippdrv in private data */
- c_node->dev = dev;
c_node->property = *property;
c_node->state = IPP_STATE_IDLE;
c_node->filp = file;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
index 0311035..2a61547 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_ipp.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.h
@@ -48,7 +48,6 @@ struct drm_exynos_ipp_cmd_work {
/*
* A structure of command node.
*
- * @dev: IPP device.
* @list: list head to command queue information.
* @event_list: list head of event.
* @mem_list: list head to source,destination memory queue information.
@@ -65,7 +64,6 @@ struct drm_exynos_ipp_cmd_work {
* @filp: associated file pointer.
*/
struct drm_exynos_ipp_cmd_node {
- struct device *dev;
struct list_headlist;
struct list_headevent_list;
struct list_headmem_list[EXYNOS_DRM_OPS_MAX];
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH] ARM: dts: make arch-timer always on in rk3288 soc
Hi Kever,
On Thu, Aug 28, 2014 at 02:40:17AM +0100, Kever Yang wrote:
> We need use the hrtimer, which need the arch-timer to be 'always-on'
I asked a question on the last posting [1]. Can you please confirm
either way?
Thanks,
Mark.
[1] lists.infradead.org/pipermail/linux-arm-kernel/2014-August/282327.html
> Signed-off-by: Kever Yang
> ---
>
> arch/arm/boot/dts/rk3288.dtsi | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
> index 5950b0a..698e6ea 100644
> --- a/arch/arm/boot/dts/rk3288.dtsi
> +++ b/arch/arm/boot/dts/rk3288.dtsi
> @@ -76,6 +76,7 @@
> IRQ_TYPE_LEVEL_HIGH)>,
> IRQ_TYPE_LEVEL_HIGH)>;
> clock-frequency = <2400>;
> + always-on;
> };
>
> i2c1: i2c@ff14 {
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2 V4] irqchip: gic: Add supports for ARM GICv2m MSI(-X)
On 08/13/2014 09:56 PM, Jingoo Han wrote: On Thursday, August 14, 2014 12:01 AM, Suravee Suthikulpanit wrote: From: Suravee Suthikulpanit ARM GICv2m specification extends GICv2 to support MSI(-X) with a new set of register frame. This patch introduces support for the non-secure GICv2m register frame. Currently, GICV2m is available in certain version of GIC-400. The patch introduces a new property in ARM gic binding, the v2m subnode. It is optional. Hi Suravee Suthikulpanit, I added some minor comments. Thanks for the cleaning up comments. Suravee -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 3/5] rtc: max77686: Fail to probe if no RTC regmap irqchip is set
On pon, 2014-08-18 at 10:34 +0200, Javier Martinez Canillas wrote:
> The max77686 mfd driver adds a regmap IRQ chip which creates an
> IRQ domain that is used to map the virtual RTC alarm1 interrupt.
>
> The RTC driver assumes that this will always be true since the
> PMIC IRQ is a required property according to the max77686 DT
> binding doc. If an "interrupts" property is not defined for a
> max77686 PMIC, then the mfd probe function will fail and the
> RTC platform driver will never be probed. But even when it is
> not possible to probe the rtc-max77686 driver without a regmap
> IRQ chip, it's better to explicitly check if the IRQ chip data
> is not NULL and gracefully fail instead of getting an OOPS.
The OOPS was possible only with Bartlomiej's patch because he changed
the MFD driver probe function to skip IRQ setup on lack of interrupts.
In current state the OOPS should not happen so mentioning OOPS in commit
message may be misleading. Maybe just don't put the OOPS here?
Anyway the patch looks good and a check for non-null
regmap_irq_chip_data is still a valid precaution so:
Reviewed-by: Krzysztof Kozlowski
Best regards,
Krzysztof
>
> Reported-by: Krzysztof Kozlowski
> Signed-off-by: Javier Martinez Canillas
> ---
>
> Fixes the issue reported by Krzystof in: https://lkml.org/lkml/2014/8/8/121
> ---
> drivers/rtc/rtc-max77686.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
> index 7bb5433..55396bb 100644
> --- a/drivers/rtc/rtc-max77686.c
> +++ b/drivers/rtc/rtc-max77686.c
> @@ -466,6 +466,12 @@ static int max77686_rtc_probe(struct platform_device
> *pdev)
> goto err_rtc;
> }
>
> + if (!max77686->rtc_irq_data) {
> + ret = -EINVAL;
> + dev_err(&pdev->dev, "%s: no RTC regmap IRQ chip\n", __func__);
> + goto err_rtc;
> + }
> +
> info->virq = regmap_irq_get_virq(max77686->rtc_irq_data,
>MAX77686_RTCIRQ_RTCA1);
> if (!info->virq) {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] iio: accel: BMC150: add support for other Bosch chips
Sorry for top-posting but it looks like I have to improve my copy-pasting
techniques. :) The sensitivity value computed in the first patch, 76590, turned
into 75590 in the last... :/
Please, go ahead and review the patch and I'll fix this in a subsequent
revision.
thanks,
laurentiu
On Thu, Aug 28, 2014 at 11:35:06AM +0300, Laurentiu Palcu wrote:
> The following chips are either similar or have only the resolution
> different. Hence, change this driver to support these chips too:
>
> BMI055 - combo chip (accelerometer part is identical to BMC150's)
> BMA255 - identical to BMC150's accelerometer
> BMA222 - 8 bit resolution
> BMA250 - 10 bit resolution
> BMA280 - 14 bit resolution
>
> Additionally:
> * add bmc150_accel_match_acpi_device() function to check that the device
>has been enumerated through ACPI;
> * rename bmc150_accel_acpi_gpio_probe() to bmc150_accel_gpio_probe()
>since the ACPI matching has been moved to the new function. Also, this
>will allow for the GPIO matching to be done against a device tree too, not
> only
>ACPI tree;
>
> Signed-off-by: Laurentiu Palcu
> ---
> drivers/iio/accel/bmc150-accel.c | 231
> ++-
> 1 file changed, 177 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/iio/accel/bmc150-accel.c
> b/drivers/iio/accel/bmc150-accel.c
> index 0e6566a..07e10fc 100644
> --- a/drivers/iio/accel/bmc150-accel.c
> +++ b/drivers/iio/accel/bmc150-accel.c
> @@ -1,5 +1,12 @@
> /*
> - * BMC150 3-axis accelerometer driver
> + * 3-axis accelerometer driver supporting following Bosch-Sensortec chips:
> + * - BMC150
> + * - BMI055
> + * - BMA255
> + * - BMA250
> + * - BMA222
> + * - BMA280
> + *
> * Copyright (c) 2014, Intel Corporation.
> *
> * This program is free software; you can redistribute it and/or modify it
> @@ -35,6 +42,11 @@
>
> #define BMC150_ACCEL_REG_CHIP_ID 0x00
> #define BMC150_ACCEL_CHIP_ID_VAL 0xFA
> +#define BMA255_ACCEL_CHIP_ID_VAL 0xFA
> +#define BMI055_ACCEL_CHIP_ID_VAL 0xFA
> +#define BMA222_ACCEL_CHIP_ID_VAL 0xF8
> +#define BMA250_ACCEL_CHIP_ID_VAL 0xF9
> +#define BMA280_ACCEL_CHIP_ID_VAL 0xFB
>
> #define BMC150_ACCEL_REG_INT_STATUS_20x0B
> #define BMC150_ACCEL_ANY_MOTION_MASK 0x07
> @@ -126,6 +138,18 @@ enum bmc150_power_modes {
> BMC150_ACCEL_SLEEP_MODE_SUSPEND = 0x04,
> };
>
> +struct bmc150_scale_info {
> + int scale;
> + int range;
> +};
> +
> +struct bmc150_accel_chip_info {
> + u8 chip_id;
> + const struct iio_chan_spec *channels;
> + int num_channels;
> + const struct bmc150_scale_info scale_table[4];
> +};
> +
> struct bmc150_accel_data {
> struct i2c_client *client;
> struct iio_trigger *dready_trig;
> @@ -140,6 +164,7 @@ struct bmc150_accel_data {
> bool dready_trigger_on;
> bool motion_trigger_on;
> int64_t timestamp;
> + const struct bmc150_accel_chip_info *chip_info;
> };
>
> static const struct {
> @@ -168,14 +193,6 @@ static const struct {
>{0x0F, 1} };
>
> static const struct {
> - int scale;
> - int range;
> -} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
> - {19122, BMC150_ACCEL_DEF_RANGE_4G},
> - {38344, BMC150_ACCEL_DEF_RANGE_8G},
> - {76590, BMC150_ACCEL_DEF_RANGE_16G} };
> -
> -static const struct {
> int sleep_dur;
> int reg_value;
> } bmc150_accel_sleep_value_table[] = { {0, 0},
> @@ -267,7 +284,7 @@ static int bmc150_accel_chip_init(struct
> bmc150_accel_data *data)
> }
>
> dev_dbg(&data->client->dev, "Chip Id %x\n", ret);
> - if (ret != BMC150_ACCEL_CHIP_ID_VAL) {
> + if (ret != data->chip_info->chip_id) {
> dev_err(&data->client->dev, "Invalid chip %x\n", ret);
> return -ENODEV;
> }
> @@ -541,19 +558,19 @@ static int bmc150_accel_set_scale(struct
> bmc150_accel_data *data, int val)
> {
> int ret, i;
>
> - for (i = 0; i < ARRAY_SIZE(bmc150_accel_scale_table); ++i) {
> - if (bmc150_accel_scale_table[i].scale == val) {
> + for (i = 0; i < ARRAY_SIZE(data->chip_info->scale_table); ++i) {
> + if (data->chip_info->scale_table[i].scale == val) {
> ret = i2c_smbus_write_byte_data(
> data->client,
> BMC150_ACCEL_REG_PMU_RANGE,
> - bmc150_accel_scale_table[i].range);
> + data->chip_info->scale_table[i].range);
> if (ret < 0) {
> dev_err(&data->client->dev,
> "Error writing pmu_range\n");
> return ret;
> }
>
> -
Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)
On Thu, Aug 28, 2014 at 07:50:36AM +0100, Alexander Holler wrote: > Am 27.08.2014 18:37, schrieb Stephen Warren: > > Of course, there are probably cases where we could/should add some more > > phandles/... and likewise cases where we shouldn't. That's why detailed > > research is needed. > > Just because I'm curious, I wonder how this research does or shoud look > like. > > Defered probes did come to light with 3.4, that was more than 2 years > ago. Ok, most people (like me) just noticed it during the last months > when they switched to DT and have run into a problem (the deferred probe > mechanism is an error-message killer), but some must have seen it > already 2 years ago. > > And I wonder how the ACPI world solves that problem. My guess would be > hardcoded stuff in the firmware-blob (BIOS), just like it happened with > board files, but I've never seen BIOS code and my knowledge about ACPI > is almost zero. ;) ACPI doesn't even attempt to solve such problems at the OS level. SoCs aimed at ACPI should have simple hardware configuration (from a Linux perspective) initialised by firmware (e.g. clocks) and devices living on a standard bus like PCIe. If a SoC requires specific low-level code to initialise the hardware in a specific order (other than architected peripherals like GIC, timers; e.g. MFD devices), we should deem it unsuitable for ACPI. ACPI should only be used by vendors who know exactly why they need and how to implement it properly and not just because the marketing department told them to (it would also be nice if the Linux kernel community was informed about such reasons). -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/5 v3] irq / PM: Make wakeup interrupts work with suspend-to-idle
On Thu, 28 Aug 2014, Rafael J. Wysocki wrote:
> On Wednesday, August 27, 2014 10:32:23 PM Thomas Gleixner wrote:
> > void suspend_device_irqs(void)
> > {
> > for_each_irq_desc(irq, desc) {
> > /* Disable the interrupt unconditionally */
> > disable_irq(irq);
>
> We still need to skip the IRQF_NO_SUSPEND stuff (eg. timers), so I guess
> everything left disabled here needs to be IRQS_SUSPENDED, so we know which
> ones to re-enable in resume_device_irqs().
Right. I skipped that one for simplicity. I wanted to look into the
whole maze today again with brain awake. I think it's simple to
integrate the no suspend magic here and have a separate handler for
it.
> >
> > /* Is the irq a wakeup source? */
> > if (!irqd_is_wakeup_set(&desc->irq_data))
> > continue;
> >
> > /* Replace the handler */
> > raw_spin_lock_irqsave(&desc->lock, flags);
> > desc->saved_handler = desc->handler;
> > desc->handler = handle_wakeup_irq;
>
> Hmm. There's no handler field in struct irq_desc (/me is puzzled).
>
> Did you mean handle_irq (I think you did)?
Yup.
> There is quite some ugliness related to resume_irqs(), the want_early thing
> and IRQF_EARLY_RESUME / IRQF_FORCE_RESUME. I guess that needs to be
> preserved?
Probably. Did not look into the madness of that yet.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested
[cc-ing Will for the VDSO bits]
Hi Sonny,
On 27/08/14 22:03, Sonny Rao wrote:
> This is a bug fix for using physical arch timers when
> the arch_timer_use_virtual boolean is false. It restores the
> arch_counter_get_cntpct() function after removal in
>
> 0d651e4e "clocksource: arch_timer: use virtual counters"
This isn't a bug, but rather a feature. It allows the kernel to
consistently use the virtual counter everywhere (including userspace),
no matter if it behaves as a host or a guest, without worrying about the
accessibility of the physical counter (hint: you have no way of knowing
if it is accessible or not).
> and completes the implementation of memory mapped access for physical
> timers, so if a system is trying to use physical timers, it will
> function properly.
>
> Signed-off-by: Sonny Rao
> ---
> arch/arm/include/asm/arch_timer.h| 9 +
> arch/arm64/include/asm/arch_timer.h | 10 ++
> drivers/clocksource/arm_arch_timer.c | 30 ++
> 3 files changed, 45 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch_timer.h
> b/arch/arm/include/asm/arch_timer.h
> index 0704e0c..e72aa4d 100644
> --- a/arch/arm/include/asm/arch_timer.h
> +++ b/arch/arm/include/asm/arch_timer.h
> @@ -78,6 +78,15 @@ static inline u32 arch_timer_get_cntfrq(void)
> return val;
> }
>
> +static inline u64 arch_counter_get_cntpct(void)
> +{
> + u64 cval;
> +
> + isb();
> + asm volatile("mrrc p15, 0, %Q0, %R0, c14" : "=r" (cval));
> + return cval;
> +}
> +
> static inline u64 arch_counter_get_cntvct(void)
> {
> u64 cval;
> diff --git a/arch/arm64/include/asm/arch_timer.h
> b/arch/arm64/include/asm/arch_timer.h
> index 9400596..58657c4 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -135,6 +135,16 @@ static inline void arch_timer_evtstrm_enable(int divider)
> #endif
> }
>
> +static inline u64 arch_counter_get_cntpct(void)
> +{
> + u64 cval;
> +
> + isb();
> + asm volatile("mrs %0, cntpct_el0" : "=r" (cval));
> +
> + return cval;
> +}
> +
> static inline u64 arch_counter_get_cntvct(void)
> {
> u64 cval;
> diff --git a/drivers/clocksource/arm_arch_timer.c
> b/drivers/clocksource/arm_arch_timer.c
> index 5163ec1..ad723cb 100644
> --- a/drivers/clocksource/arm_arch_timer.c
> +++ b/drivers/clocksource/arm_arch_timer.c
> @@ -30,6 +30,8 @@
> #define CNTTIDR 0x08
> #define CNTTIDR_VIRT(n) (BIT(1) << ((n) * 4))
>
> +#define CNTPCT_LO0x00
> +#define CNTPCT_HI0x04
> #define CNTVCT_LO0x08
> #define CNTVCT_HI0x0c
> #define CNTFRQ 0x10
> @@ -386,6 +388,19 @@ static u64 arch_counter_get_cntvct_mem(void)
> return ((u64) vct_hi << 32) | vct_lo;
> }
>
> +static u64 arch_counter_get_cntpct_mem(void)
> +{
> + u32 pct_lo, pct_hi, tmp_hi;
> +
> + do {
> + pct_hi = readl_relaxed(arch_counter_base + CNTPCT_HI);
> + pct_lo = readl_relaxed(arch_counter_base + CNTPCT_LO);
> + tmp_hi = readl_relaxed(arch_counter_base + CNTPCT_HI);
> + } while (pct_hi != tmp_hi);
> +
> + return ((u64) pct_hi << 32) | pct_lo;
> +}
> +
> /*
> * Default to cp15 based access because arm64 uses this function for
> * sched_clock() before DT is probed and the cp15 method is guaranteed
> @@ -429,10 +444,17 @@ static void __init arch_counter_register(unsigned type)
> u64 start_count;
>
> /* Register the CP15 based counter if we have one */
> - if (type & ARCH_CP15_TIMER)
> - arch_timer_read_counter = arch_counter_get_cntvct;
> - else
> - arch_timer_read_counter = arch_counter_get_cntvct_mem;
> + if (type & ARCH_CP15_TIMER) {
> + if (arch_timer_use_virtual)
> + arch_timer_read_counter = arch_counter_get_cntvct;
> + else
> + arch_timer_read_counter = arch_counter_get_cntpct;
> + } else {
> + if (arch_timer_use_virtual)
> + arch_timer_read_counter = arch_counter_get_cntvct_mem;
> + else
> + arch_timer_read_counter = arch_counter_get_cntpct_mem;
> + }
>
> start_count = arch_timer_read_counter();
> clocksource_register_hz(&clocksource_counter, arch_timer_rate);
>
What will be the effect on arm64 where the VDSO uses the virtual counter
to implement gettimeofday?
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] iio: accel: BMC150: add support for other Bosch chips
> The following chips are either similar or have only the resolution
> different. Hence, change this driver to support these chips too:
> BMI055 - combo chip (accelerometer part is identical to BMC150's)
> BMA255 - identical to BMC150's accelerometer
> BMA222 - 8 bit resolution
> BMA250 - 10 bit resolution
> BMA280 - 14 bit resolution
I recently proposed to add BMA250 support to the BMA180 IIO driver;
according to the datasheet, the chip ID value for the BMA180 and (!)
BMA250 is 0x03, while your patch claims that it is 0xf9
see
http://ae-bst.resource.bosch.com/media/products/dokumente/bma250/bst-bma250-ds002-05.pdf,
page 37 (and it really is on my chip :)
the question is whether to add further Bosch accelerometer chips to the
BMA180 driver or the BMC150 driver and what explains the different chip IDs
need to check if these are really so similar and what driver provides /
exposes more features
p.
> Additionally:
> * add bmc150_accel_match_acpi_device() function to check that the device
>has been enumerated through ACPI;
> * rename bmc150_accel_acpi_gpio_probe() to bmc150_accel_gpio_probe()
>since the ACPI matching has been moved to the new function. Also, this
>will allow for the GPIO matching to be done against a device tree too, not
> only
>ACPI tree;
>
> Signed-off-by: Laurentiu Palcu
> ---
> drivers/iio/accel/bmc150-accel.c | 231
> ++-
> 1 file changed, 177 insertions(+), 54 deletions(-)
>
> diff --git a/drivers/iio/accel/bmc150-accel.c
> b/drivers/iio/accel/bmc150-accel.c
> index 0e6566a..07e10fc 100644
> --- a/drivers/iio/accel/bmc150-accel.c
> +++ b/drivers/iio/accel/bmc150-accel.c
> @@ -1,5 +1,12 @@
> /*
> - * BMC150 3-axis accelerometer driver
> + * 3-axis accelerometer driver supporting following Bosch-Sensortec chips:
> + * - BMC150
> + * - BMI055
> + * - BMA255
> + * - BMA250
> + * - BMA222
> + * - BMA280
> + *
> * Copyright (c) 2014, Intel Corporation.
> *
> * This program is free software; you can redistribute it and/or modify it
> @@ -35,6 +42,11 @@
>
> #define BMC150_ACCEL_REG_CHIP_ID 0x00
> #define BMC150_ACCEL_CHIP_ID_VAL 0xFA
> +#define BMA255_ACCEL_CHIP_ID_VAL 0xFA
> +#define BMI055_ACCEL_CHIP_ID_VAL 0xFA
> +#define BMA222_ACCEL_CHIP_ID_VAL 0xF8
> +#define BMA250_ACCEL_CHIP_ID_VAL 0xF9
> +#define BMA280_ACCEL_CHIP_ID_VAL 0xFB
>
> #define BMC150_ACCEL_REG_INT_STATUS_20x0B
> #define BMC150_ACCEL_ANY_MOTION_MASK 0x07
> @@ -126,6 +138,18 @@ enum bmc150_power_modes {
> BMC150_ACCEL_SLEEP_MODE_SUSPEND = 0x04,
> };
>
> +struct bmc150_scale_info {
> + int scale;
> + int range;
> +};
> +
> +struct bmc150_accel_chip_info {
> + u8 chip_id;
> + const struct iio_chan_spec *channels;
> + int num_channels;
> + const struct bmc150_scale_info scale_table[4];
> +};
> +
> struct bmc150_accel_data {
> struct i2c_client *client;
> struct iio_trigger *dready_trig;
> @@ -140,6 +164,7 @@ struct bmc150_accel_data {
> bool dready_trigger_on;
> bool motion_trigger_on;
> int64_t timestamp;
> + const struct bmc150_accel_chip_info *chip_info;
> };
>
> static const struct {
> @@ -168,14 +193,6 @@ static const struct {
>{0x0F, 1} };
>
> static const struct {
> - int scale;
> - int range;
> -} bmc150_accel_scale_table[] = { {9610, BMC150_ACCEL_DEF_RANGE_2G},
> - {19122, BMC150_ACCEL_DEF_RANGE_4G},
> - {38344, BMC150_ACCEL_DEF_RANGE_8G},
> - {76590, BMC150_ACCEL_DEF_RANGE_16G} };
> -
> -static const struct {
> int sleep_dur;
> int reg_value;
> } bmc150_accel_sleep_value_table[] = { {0, 0},
> @@ -267,7 +284,7 @@ static int bmc150_accel_chip_init(struct
> bmc150_accel_data *data)
> }
>
> dev_dbg(&data->client->dev, "Chip Id %x\n", ret);
> - if (ret != BMC150_ACCEL_CHIP_ID_VAL) {
> + if (ret != data->chip_info->chip_id) {
> dev_err(&data->client->dev, "Invalid chip %x\n", ret);
> return -ENODEV;
> }
> @@ -541,19 +558,19 @@ static int bmc150_accel_set_scale(struct
> bmc150_accel_data *data, int val)
> {
> int ret, i;
>
> - for (i = 0; i < ARRAY_SIZE(bmc150_accel_scale_table); ++i) {
> - if (bmc150_accel_scale_table[i].scale == val) {
> + for (i = 0; i < ARRAY_SIZE(data->chip_info->scale_table); ++i) {
> + if (data->chip_info->scale_table[i].scale == val) {
> ret = i2c_smbus_write_byte_data(
> data->client,
> BMC150_ACCEL_REG_PMU_RANGE,
> - bmc150_accel_scale_table[i].range);
> + data->chip_info->scale_table[i].range);
> if
Re: [PATCH] clocksource: arch_timer: Fix code to use physical timers when requested
On Thu, Aug 28, 2014 at 04:33:31AM +0100, Doug Anderson wrote: > Hi, > > On Wed, Aug 27, 2014 at 7:58 PM, Olof Johansson wrote: > > On Wed, Aug 27, 2014 at 5:56 PM, Stephen Boyd wrote: > >> On 08/27/14 15:33, Olof Johansson wrote: > >>> On Wed, Aug 27, 2014 at 3:26 PM, Stephen Boyd > >>> wrote: > >>> > Is there any reason why the virtual counter can't be read? Maybe we're > the hyp and we need to make sure we don't use the virtual timer so that > the guest can use it, but that doesn't have any effect on the usage of > the virtual counter for the clocksource. > >>> There are several cases where virtual is unusable -- in particular it > >>> might not have been configured properly (i.e. the phys/virt offset is > >>> at a bad value). > >>> > >> > >> Any specifics? It would be nice to say so in the commit text so that > >> others using such devices know they need this patch. I'm guessing the > >> firmware can't be fixed? > > Even if we could change things to use a virtual timer in some cases, > Sonny's patch still fixes a bug. The code as written right now makes > pretenses about supporting the physical timer, but it doesn't work. > That should be fixed. The code does support the physical timer. It does not support the physical counter (and makes no pretenses that it does). I had hoped we wouldn't encounter cases where CNTVOFF was hopelessly ill-configured on a platform, but evidently we have. So we need some workaround for that. > > Yeah, there are a few. The big.LITTLE on the Chromebook 2 models have > > this issue, due to the A7 cluster having an incorrect offset > > programmed. However, arch timers aren't supported on that SoC in the > > first place, so it's not a problem in reality. > > > > The other known platform is rk3288. It has products out in the wild > > where firmware updates are unlikely. > > One other reason is that (I'm told) that the virtual offset is lost in > certain power down conditions (powering down a core, going into S3, > etc). When we power back up the offset is effectively reset to a > random value. That means we need something to reprogram the virtual > timer offset whenever we power things back up. > > If we've got a hypervisor then the hypervisor will definitely be > involved in powering things back up and it can reset the virtual > offset. ...but forcing systems to implement a hypervisor (or somehow > adding an interface for the kernel to call back into firmware) is a > huge effort and it means more hard-to-update code sitting in firmware. Not if you boot Linux at hyp, as we've recommended for this precise reason. That doesn't fix other things like CNTFRQ if the secure initialisation doesn't poke that, however. Thanks, Mark. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Revert "arm64: use cpu_online_mask when using forced irq_set_affinity"
On Wed, Aug 27, 2014 at 10:30:06AM +0100, byungchul.p...@lge.com wrote: > From: Byungchul Park > > This reverts commit 601c942176d8ad8334118bddb747e3720bed24f8. > > This patch is designed to ensure that the cpu being offlined is not > present in the affinity mask. But it is a bad idea to overwrite the > affinity variable with cpu_online_mask, even in case that the current > affinity already includes onlined cpus. > > So revert this patch to replace it with another one doing exactly > what it intends. Sudeep: what's the right way forward for this? There seems to be general agreement that the existing code is broken, but a bunch of different `fixes'. Can we just take a straight port of what tglx proposed for ARM? (changing force to false) Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 2/3] kprobes: copy ainsn after alloc aggr kprobe
(2014/08/27 22:02), Wang Nan wrote:
> Copy old kprobe to newly alloced optimized_kprobe before
> arch_prepare_optimized_kprobe(). Original kprove can brings more
> information to optimizer.
>
> Signed-off-by: Wang Nan
> Cc: Russell King
> Cc: "David A. Long"
> Cc: Jon Medhurst
> Cc: Taras Kondratiuk
> Cc: Ben Dooks
> Cc: Ananth N Mavinakayanahalli
> Cc: Anil S Keshavamurthy
> Cc: "David S. Miller"
> Cc: Masami Hiramatsu
> Cc: Will Deacon
> ---
> kernel/kprobes.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index 3995f54..33cf568 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -730,7 +730,12 @@ static struct kprobe *alloc_aggr_kprobe(struct kprobe *p)
> return NULL;
>
> INIT_LIST_HEAD(&op->list);
> - op->kp.addr = p->addr;
Do not remove this, since copy_kprobe() doesn't copy kp.addr.
static inline void copy_kprobe(struct kprobe *ap, struct kprobe *p)
{
memcpy(&p->opcode, &ap->opcode, sizeof(kprobe_opcode_t));
memcpy(&p->ainsn, &ap->ainsn, sizeof(struct arch_specific_insn));
}
Thank you,
> +
> + /*
> + * copy gives arch_prepare_optimized_kprobe
> + * more information
> + */
> + copy_kprobe(p, &op->kp);
> arch_prepare_optimized_kprobe(op);
>
> return &op->kp;
>
--
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Revert "arm64: use cpu_online_mask when using forced irq_set_affinity"
On 28/08/14 10:38, Will Deacon wrote: On Wed, Aug 27, 2014 at 10:30:06AM +0100, byungchul.p...@lge.com wrote: From: Byungchul Park This reverts commit 601c942176d8ad8334118bddb747e3720bed24f8. This patch is designed to ensure that the cpu being offlined is not present in the affinity mask. But it is a bad idea to overwrite the affinity variable with cpu_online_mask, even in case that the current affinity already includes onlined cpus. So revert this patch to replace it with another one doing exactly what it intends. Sudeep: what's the right way forward for this? There seems to be general agreement that the existing code is broken, but a bunch of different `fixes'. Can we just take a straight port of what tglx proposed for ARM? (changing force to false) Yes I agree but for that we need agreement from rmk and hence I asked to wait till we hear from rmk. Main issue raised by rmk is if some other interrupt controller implementation decide not to migrate away when force is false(theoretically possible). Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Revert "arm64: use cpu_online_mask when using forced irq_set_affinity"
On Thu, Aug 28, 2014 at 10:49:54AM +0100, Sudeep Holla wrote: > > > On 28/08/14 10:38, Will Deacon wrote: > > On Wed, Aug 27, 2014 at 10:30:06AM +0100, byungchul.p...@lge.com wrote: > >> From: Byungchul Park > >> > >> This reverts commit 601c942176d8ad8334118bddb747e3720bed24f8. > >> > >> This patch is designed to ensure that the cpu being offlined is not > >> present in the affinity mask. But it is a bad idea to overwrite the > >> affinity variable with cpu_online_mask, even in case that the current > >> affinity already includes onlined cpus. > >> > >> So revert this patch to replace it with another one doing exactly > >> what it intends. > > > > Sudeep: what's the right way forward for this? There seems to be general > > agreement that the existing code is broken, but a bunch of different > > `fixes'. Can we just take a straight port of what tglx proposed for ARM? > > (changing force to false) > > > > Yes I agree but for that we need agreement from rmk and hence I asked to > wait till we hear from rmk. Main issue raised by rmk is if some other > interrupt controller implementation decide not to migrate away when > force is false(theoretically possible). Okey doke. Whatever solution we take should be the same for arm and arm64, so I'll leave it with you. Will -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 1/3] ARM: probes: check stack operation when decoding
(2014/08/27 22:02), Wang Nan wrote:
> This patch improves arm instruction decoder, allows it check whether an
> instruction is a stack store operation. This information is important
> for kprobe optimization.
>
> For normal str instruction, this patch add a series of _SP_STACK
> register indicator in the decoder to test the base and offset register
> in ldr , [, ] against sp.
>
> For stm instruction, it check sp register in instruction specific
> decoder.
OK, reviewed. but since I'm not so sure about arm32 ISA,
I need help from ARM32 maintainer to ack this.
Reviewed-by: Masami Hiramatsu
Thank you,
>
> Signed-off-by: Wang Nan
> Cc: Russell King
> Cc: "David A. Long"
> Cc: Jon Medhurst
> Cc: Taras Kondratiuk
> Cc: Ben Dooks
> Cc: Ananth N Mavinakayanahalli
> Cc: Anil S Keshavamurthy
> Cc: "David S. Miller"
> Cc: Masami Hiramatsu
> Cc: Will Deacon
>
> ---
> arch/arm/include/asm/probes.h| 1 +
> arch/arm/kernel/kprobes-common.c | 4
> arch/arm/kernel/probes-arm.c | 4 ++--
> arch/arm/kernel/probes-thumb.c | 6 +++---
> arch/arm/kernel/probes.c | 20 ++--
> arch/arm/kernel/probes.h | 6 ++
> 6 files changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/include/asm/probes.h b/arch/arm/include/asm/probes.h
> index 806cfe6..3f6912c 100644
> --- a/arch/arm/include/asm/probes.h
> +++ b/arch/arm/include/asm/probes.h
> @@ -38,6 +38,7 @@ struct arch_probes_insn {
> probes_check_cc *insn_check_cc;
> probes_insn_singlestep_t*insn_singlestep;
> probes_insn_fn_t*insn_fn;
> + boolis_stack_operation;
> };
>
> #endif
> diff --git a/arch/arm/kernel/kprobes-common.c
> b/arch/arm/kernel/kprobes-common.c
> index 0bf5d64..4e8b918 100644
> --- a/arch/arm/kernel/kprobes-common.c
> +++ b/arch/arm/kernel/kprobes-common.c
> @@ -133,6 +133,10 @@ kprobe_decode_ldmstm(probes_opcode_t insn, struct
> arch_probes_insn *asi,
> int is_ldm = insn & 0x10;
> int rn = (insn >> 16) & 0xf;
>
> + /* whether this is a push instruction? */
> + if ((rn == 0xd) && (!is_ldm))
> + asi->is_stack_operation = true;
> +
> if (rn <= 12 && (reglist & 0xe000) == 0) {
> /* Instruction only uses registers in the range R0..R12 */
> handler = emulate_generic_r0_12_noflags;
> diff --git a/arch/arm/kernel/probes-arm.c b/arch/arm/kernel/probes-arm.c
> index 8eaef81..5c187ba 100644
> --- a/arch/arm/kernel/probes-arm.c
> +++ b/arch/arm/kernel/probes-arm.c
> @@ -577,7 +577,7 @@ static const union decode_item arm__01xx_table[] = {
> /* STR (immediate) 010x x0x0 */
> /* STRB (immediate) 010x x1x0 */
> DECODE_EMULATEX (0x0e10, 0x0400, PROBES_STORE,
> - REGS(NOPCWB, ANY, 0, 0, 0)),
> + REGS(NOPCWB_SP_STACK, ANY, 0,
> 0, 0)),
>
> /* LDR (immediate) 010x x0x1 */
> /* LDRB (immediate) 010x x1x1 */
> @@ -587,7 +587,7 @@ static const union decode_item arm__01xx_table[] = {
> /* STR (register) 011x x0x0 */
> /* STRB (register) 011x x1x0 */
> DECODE_EMULATEX (0x0e10, 0x0600, PROBES_STORE,
> - REGS(NOPCWB, ANY, 0, 0, NOPC)),
> + REGS(NOPCWB_SP_STACK, ANY, 0,
> 0, NOPC_SP_STACK)),
>
> /* LDR (register) 011x x0x1 */
> /* LDRB (register) 011x x1x1 */
> diff --git a/arch/arm/kernel/probes-thumb.c b/arch/arm/kernel/probes-thumb.c
> index 4131351..d0d30d8 100644
> --- a/arch/arm/kernel/probes-thumb.c
> +++ b/arch/arm/kernel/probes-thumb.c
> @@ -54,7 +54,7 @@ static const union decode_item t32_table_1110_100x_x1xx[] =
> {
> /* STRD (immediate) 1110 1001 x1x0 */
> /* LDRD (immediate) 1110 1001 x1x1 */
> DECODE_EMULATEX (0xff40, 0xe940, PROBES_T32_LDRDSTRD,
> - REGS(NOPCWB, NOSPPC, NOSPPC,
> 0, 0)),
> + REGS(NOPCWB_SP_STACK, NOSPPC,
> NOSPPC, 0, 0)),
>
> /* TBB 1110 1000 1101 */
> /* TBH 1110 1000 1101 0001 */
> @@ -345,12 +345,12 @@ static const union decode_item t32_table__100x[] = {
> /* STR (immediate) 1000 1100 */
> /* LDR (immediate) 1000 1101 */
> DECODE_EMULATEX (0xffe0, 0xf8c0, PROBES_T32_LDRSTR,
> -
Re: [PATCH v2] usb: hub: Prevent hub autosuspend if usbcore.autosuspend is -1
On 08/28/2014 12:02 AM, Greg KH wrote: > On Wed, Aug 27, 2014 at 12:23:39PM -0700, Greg KH wrote: >> On Wed, Aug 27, 2014 at 03:11:10PM +0300, Roger Quadros wrote: >>> If user specifies that USB autosuspend must be disabled by module >>> parameter "usbcore.autosuspend=-1" then we must prevent >>> autosuspend of USB hub devices as well. >>> >>> commit 596d789a211d introduced in v3.8 changed the original behaivour >>> and stopped respecting the usbcore.autosuspend parameter for hubs. >>> >>> Fixes: 596d789a211d "USB: set hub's default autosuspend delay as 0" >>> >>> Cc: [3.8+] >>> Signed-off-by: Roger Quadros >>> --- >>> drivers/usb/core/hub.c | 8 +++- >>> 1 file changed, 7 insertions(+), 1 deletion(-) >>> >>> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c >>> index 8a4dcbc..59b599d 100644 >>> --- a/drivers/usb/core/hub.c >>> +++ b/drivers/usb/core/hub.c >>> @@ -1728,8 +1728,14 @@ static int hub_probe(struct usb_interface *intf, >>> const struct usb_device_id *id) >>> * - Change autosuspend delay of hub can avoid unnecessary auto >>> * suspend timer for hub, also may decrease power consumption >>> * of USB bus. >>> +* >>> +* - If user has indicated to prevent autosuspend by passing >>> +* usbcore.autosuspend = -1 then keep autosuspend disabled. >>> */ >>> - pm_runtime_set_autosuspend_delay(&hdev->dev, 0); >>> +#ifdef CONFIG_PM_RUNTIME >>> + if (hdev->dev.power.autosuspend_delay >= 0) >>> + pm_runtime_set_autosuspend_delay(&hdev->dev, 0); >>> +#endif >>> >>> /* >>> * Hubs have proper suspend/resume support, except for root hubs >> >> Sorry, but can I have a patch that just adds the #ifdef as I already >> have your original one in my tree. > > This should be all that is needed, right? > > - > > > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c > index 003cb6b1a6bf..46f5161c7891 100644 > --- a/drivers/usb/core/hub.c > +++ b/drivers/usb/core/hub.c > @@ -1732,8 +1732,10 @@ static int hub_probe(struct usb_interface *intf, const > struct usb_device_id *id) >* - If user has indicated to prevent autosuspend by passing >* usbcore.autosuspend = -1 then keep autosuspend disabled. >*/ > +#ifdef CONFIG_PM_RUNTIME > if (hdev->dev.power.autosuspend_delay >= 0) > pm_runtime_set_autosuspend_delay(&hdev->dev, 0); > +#endif > > /* >* Hubs have proper suspend/resume support, except for root hubs > Yes. Thanks Greg. cheers, -roger -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Revert "arm64: use cpu_online_mask when using forced irq_set_affinity"
On 28/08/14 10:50, Will Deacon wrote: On Thu, Aug 28, 2014 at 10:49:54AM +0100, Sudeep Holla wrote: On 28/08/14 10:38, Will Deacon wrote: On Wed, Aug 27, 2014 at 10:30:06AM +0100, byungchul.p...@lge.com wrote: From: Byungchul Park This reverts commit 601c942176d8ad8334118bddb747e3720bed24f8. This patch is designed to ensure that the cpu being offlined is not present in the affinity mask. But it is a bad idea to overwrite the affinity variable with cpu_online_mask, even in case that the current affinity already includes onlined cpus. So revert this patch to replace it with another one doing exactly what it intends. Sudeep: what's the right way forward for this? There seems to be general agreement that the existing code is broken, but a bunch of different `fixes'. Can we just take a straight port of what tglx proposed for ARM? (changing force to false) Yes I agree but for that we need agreement from rmk and hence I asked to wait till we hear from rmk. Main issue raised by rmk is if some other interrupt controller implementation decide not to migrate away when force is false(theoretically possible). Okey doke. Whatever solution we take should be the same for arm and arm64, so I'll leave it with you. tglx just confirmed that interrupt controller implementation using force flag must use online_cpumask. So converting to false should be fine. So once rmk agrees for ARM, we can apply this revert and change to false for ARM64 also. Regards, Sudeep -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC v1 1/2] USB: OTG: Hold wakeupsource when VBUS present
From: Todd Poynor
USB: OTG: Hold wakeupsource when VBUS present
Purpose of this is to prevent the system to enter into
suspend state from USB peripheral traffic by hodling a
wakeupsource when USB(otg) is connected and enumerated
in peripheral mode(say adb).
Disabled by default, can enable with:
echo Y > /sys/module/otg_wakeupsource/parameters/enabled
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Cc: Arve Hj�nnev�g
Cc: Benoit Goby
Signed-off-by: Todd Poynor
[kiran: Added context to commit message.
Included build fix from Benoit Goby and Arve Hj�nnev�g.
Removed lock->held field in driver as this mechanism is
provided in wakeupsource driver.
wakelock(wl) terminology replaced with wakeup_source(ws).
changed to disabled by default from "enable by default".
sys entry(module param) field modified to otg_wakeupsource.
included Todd's refactoring logic.
Introduced get_phy_hook to handle otgws_xceiv per-PHY.
otgws_nb moved to otg_wakeupsource_init function.
__pm_stay_awake and __pm_relax called directly from the main.
code instead of calling them via otgws_grab,otgws_drop.
modified Kconfig help text]
Signed-off-by: Kiran Raparthy
---
drivers/usb/phy/Kconfig| 8 +++
drivers/usb/phy/Makefile | 1 +
drivers/usb/phy/otg-wakeupsource.c | 144 +
3 files changed, 153 insertions(+)
create mode 100644 drivers/usb/phy/otg-wakeupsource.c
diff --git a/drivers/usb/phy/Kconfig b/drivers/usb/phy/Kconfig
index e253fa0..d9ddd85 100644
--- a/drivers/usb/phy/Kconfig
+++ b/drivers/usb/phy/Kconfig
@@ -6,6 +6,14 @@ menu "USB Physical Layer drivers"
config USB_PHY
def_bool n
+config USB_OTG_WAKEUPSOURCE
+ bool "Hold wakeupsource when USB is enumerated in peripheral mode"
+ depends on PM_SLEEP
+ select USB_PHY
+ help
+ Prevent the system going into automatic suspend while
+ it is attached as a USB peripheral by holding a wakeupsource.
+
#
# USB Transceiver Drivers
#
diff --git a/drivers/usb/phy/Makefile b/drivers/usb/phy/Makefile
index 24a9133..ca2fbaf 100644
--- a/drivers/usb/phy/Makefile
+++ b/drivers/usb/phy/Makefile
@@ -3,6 +3,7 @@
#
obj-$(CONFIG_USB_PHY) += phy.o
obj-$(CONFIG_OF) += of.o
+obj-$(CONFIG_USB_OTG_WAKEUPSOURCE) += otg-wakeupsource.o
# transceiver drivers, keep the list sorted
diff --git a/drivers/usb/phy/otg-wakeupsource.c
b/drivers/usb/phy/otg-wakeupsource.c
new file mode 100644
index 000..7c838d1
--- /dev/null
+++ b/drivers/usb/phy/otg-wakeupsource.c
@@ -0,0 +1,144 @@
+/*
+ * otg-wakeupsource.c
+ *
+ * Copyright (C) 2011 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+bool enabled = false;
+
+static DEFINE_SPINLOCK(otgws_spinlock);
+static struct usb_phy *get_phy_hook(void);
+
+/* Only one lock, but since these 2 fields are associated with each other... */
+
+struct otgws_lock {
+ char name[40];
+ struct wakeup_source wsource;
+};
+
+/* VBUS present lock */
+
+static struct otgws_lock vbus_lock;
+
+static void otgws_handle_event(unsigned long event)
+{
+ unsigned long irqflags;
+
+ spin_lock_irqsave(&otgws_spinlock, irqflags);
+
+ if (!enabled) {
+ __pm_relax(&vbus_lock.wsource);
+ spin_unlock_irqrestore(&otgws_spinlock, irqflags);
+ return;
+ }
+
+ switch (event) {
+ case USB_EVENT_VBUS:
+ case USB_EVENT_ENUMERATED:
+ __pm_stay_awake(&vbus_lock.wsource);
+ break;
+
+ case USB_EVENT_NONE:
+ case USB_EVENT_ID:
+ case USB_EVENT_CHARGER:
+ __pm_relax(&vbus_lock.wsource);
+ break;
+
+ default:
+ break;
+ }
+
+ spin_unlock_irqrestore(&otgws_spinlock, irqflags);
+}
+static struct usb_phy *get_phy_hook(void)
+{
+ struct usb_phy *phy;
+
+ phy = usb_get_phy(USB_PHY_TYPE_USB2);
+
+ if (IS_ERR(phy)) {
+ pr_err("%s: No OTG transceiver found\n", __func__);
+ return NULL;
+ }
+
+ return phy;
+}
+static int otgws_otg_notifications(struct notifier_block *nb,
+ unsigned long event, void *unused)
+{
+ otgws_handle_event(event);
+ return NOTIFY_O
[RFC v1 2/2] usb: otg: Temporarily hold wakeupsource on charger and disconnect events
From: Todd Poynor
usb: otg: Temporarily hold wakeupsource on charger and disconnect events
Allow other parts of the system to react to the charger connect/disconnect
event without allowing the system to suspend before the other parts can process
the event. This wakeup_source times out after 2 seconds; if nobody else holds a
wakeup_source by that time then the device can sleep.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Signed-off-by: Todd Poynor
[kiran: Added context to commit message]
Signed-off-by: Kiran Raparthy
---
drivers/usb/phy/otg-wakeupsource.c | 10 +++---
include/linux/usb/otg.h| 2 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/otg-wakeupsource.c
b/drivers/usb/phy/otg-wakeupsource.c
index 7c838d1..9f3c5c1 100644
--- a/drivers/usb/phy/otg-wakeupsource.c
+++ b/drivers/usb/phy/otg-wakeupsource.c
@@ -34,8 +34,11 @@ struct otgws_lock {
struct wakeup_source wsource;
};
-/* VBUS present lock */
-
+/*
+ * VBUS present lock. Also used as a timed lock on charger
+ * connect/disconnect and USB host disconnect, to allow the system
+ * to react to the change in power.
+ */
static struct otgws_lock vbus_lock;
static void otgws_handle_event(unsigned long event)
@@ -59,7 +62,8 @@ static void otgws_handle_event(unsigned long event)
case USB_EVENT_NONE:
case USB_EVENT_ID:
case USB_EVENT_CHARGER:
- __pm_relax(&vbus_lock.wsource);
+ __pm_wakeup_event(&vbus_lock.wsource,
+ msecs_to_jiffies(TEMPORARY_HOLD_TIME));
break;
default:
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 154332b..4243747 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -11,6 +11,8 @@
#include
+#define TEMPORARY_HOLD_TIME2000
+
struct usb_otg {
u8 default_a;
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] regulator: max77802: set opmode to normal if off is read from hw
Hello Mark, > On 28/08/2014, at 10:28, Mark Brown wrote: >> Yes, AFAIK the bootloader (none of them because Chromebooks use two >> chained U-boots) change the regulators default opmode so once is set >> to OFF on .disable, that value is preserved on warm reboot. This made >> sense with the Chrome OS kernel since the kernel always set the opmode >> defined in the "regulator-op-mode" DT property and did not relied on >> the bootloader to set the most efficient default opmode. > > I'm sorry but this is just really unclear. Does the bootloader change > the mode or does it not change the mode? I meant that the boot loader *does not* change the mode and is Linux who change it, sorry for the confusion. Best regards, Javier-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC v1 2/2] usb: otg: Temporarily hold wakeupsource on charger and disconnect events
From: Todd Poynor
usb: otg: Temporarily hold wakeupsource on charger and disconnect events
Allow other parts of the system to react to the charger connect/disconnect
event without allowing the system to suspend before the other parts can process
the event. This wakeup_source times out after 2 seconds; if nobody else holds a
wakeup_source by that time then the device can sleep.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Signed-off-by: Todd Poynor
[kiran: Added context to commit message]
Signed-off-by: Kiran Raparthy
---
drivers/usb/phy/otg-wakeupsource.c | 10 +++---
include/linux/usb/otg.h| 2 ++
2 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/otg-wakeupsource.c
b/drivers/usb/phy/otg-wakeupsource.c
index 7c838d1..9f3c5c1 100644
--- a/drivers/usb/phy/otg-wakeupsource.c
+++ b/drivers/usb/phy/otg-wakeupsource.c
@@ -34,8 +34,11 @@ struct otgws_lock {
struct wakeup_source wsource;
};
-/* VBUS present lock */
-
+/*
+ * VBUS present lock. Also used as a timed lock on charger
+ * connect/disconnect and USB host disconnect, to allow the system
+ * to react to the change in power.
+ */
static struct otgws_lock vbus_lock;
static void otgws_handle_event(unsigned long event)
@@ -59,7 +62,8 @@ static void otgws_handle_event(unsigned long event)
case USB_EVENT_NONE:
case USB_EVENT_ID:
case USB_EVENT_CHARGER:
- __pm_relax(&vbus_lock.wsource);
+ __pm_wakeup_event(&vbus_lock.wsource,
+ msecs_to_jiffies(TEMPORARY_HOLD_TIME));
break;
default:
diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 154332b..4243747 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -11,6 +11,8 @@
#include
+#define TEMPORARY_HOLD_TIME2000
+
struct usb_otg {
u8 default_a;
--
1.8.2.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 4/4] Documentation/scheduler/sched-deadline.txt: add tests suite appendix
Add an appendix briefly describing tools that can be used to test SCHED_DEADLINE
(and the scheduler in general). Links to where source code of the tools is
hosted
are also provided.
Signed-off-by: Juri Lelli
Cc: Randy Dunlap
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Henrik Austad
Cc: Dario Faggioli
Cc: Juri Lelli
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Documentation/scheduler/sched-deadline.txt | 52 ++
1 file changed, 52 insertions(+)
diff --git a/Documentation/scheduler/sched-deadline.txt
b/Documentation/scheduler/sched-deadline.txt
index 641395e..2f5b174 100644
--- a/Documentation/scheduler/sched-deadline.txt
+++ b/Documentation/scheduler/sched-deadline.txt
@@ -15,6 +15,7 @@ CONTENTS
5. Tasks CPU affinity
5.1 SCHED_DEADLINE and cpusets HOWTO
6. Future plans
+ A. Test suite
0. WARNING
@@ -341,3 +342,54 @@ CONTENTS
throttling patches [https://lkml.org/lkml/2010/2/23/239] but we still are in
the preliminary phases of the merge and we really seek feedback that would
help us decide on the direction it should take.
+
+Appendix A. Test suite
+==
+
+ The SCHED_DEADLINE policy can be easily tested using two applications that
+ are part of a wider Linux Scheduler validation suite. The suite is
+ available as a GitHub repository: https://github.com/scheduler-tools.
+
+ The first testing application is called rt-app and can be used to
+ start multiple threads with specific parameters. rt-app supports
+ SCHED_{OTHER,FIFO,RR,DEADLINE} scheduling policies and their related
+ parameters (e.g., niceness, priority, runtime/deadline/period). rt-app
+ is a valuable tool, as it can be used to synthetically recreate certain
+ workloads (maybe mimicking real use-cases) and evaluate how the scheduler
+ behaves under such workloads. In this way, results are easily reproducible.
+ rt-app is available at: https://github.com/scheduler-tools/rt-app.
+
+ Thread parameters can be specified from the command line, with something like
+ this:
+
+ # rt-app -t 10:1:d -t 15:2:f:10 -D5
+
+ The above creates two threads. The first one, scheduled by SCHED_DEADLINE,
+ executes for 10ms every 100ms and the second one, scheduled at RT priority 10
+ with SCHED_FIFO, executes for 20ms every 150ms. The configuration runs
+ for 5 seconds.
+
+ More interestingly, configurations can be described with a json file that
+ can be passed as input to rt-app with something like this:
+
+ # rt-app my_config.json
+
+ The parameters that can be specified with the second method are a superset
+ of the command line options. Please refer to rt-app documentation for more
+ details.
+
+ The second testing application is a modification of schedtool, called
+ schedtool-dl, which can be used to setup SCHED_DEADLINE parameters for a
+ certain pid/application. schedtool-dl is available at:
+ https://github.com/scheduler-tools/schedtool-dl.git.
+
+ The usage is straightforward:
+
+ # schedtool -E -t 1000:1 -e ./my_cpuhog_app
+
+ With this, my_cpuhog_app is put to run inside a SCHED_DEADLINE reservation
+ of 10ms every 100ms (note that parameters are expressed in microseconds).
+ You can also use schedtool to create a reservation for an already running
+ application, given that you know its pid:
+
+ # schedtool -E -t 1000:1 my_app_pid
--
2.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/4] SCHED_DEADLINE documentation fixes and improvements
Hello everyone, This is version 3 of a small patchset that fixes and improves SCHED_DEADLINE documentation. Patch 1/4 fixes and clarifies terminology; patch 2/4 aligns Section 4 to the current interface; patch 3/4 improves and clarifies what admission control means on UP an SMP systems; patch 4/4 introduces an appendix about testing. Changes since v1: - fixed typos spotted by Randy and Peter (thanks!) Changes since v2: - fixed typos and rewrote paragraphs as suggested by Ingo (thanks!) Best Regards, - Juri Juri Lelli (2): Documentation/scheduler/sched-deadline.txt: Rewrite section 4 intro Documentation/scheduler/sched-deadline.txt: add tests suite appendix Luca Abeni (2): Documentation/scheduler/sched-deadline.txt: fix terminology and improve clarity Documentation/scheduler/sched-deadline.txt: improve and clarify AC bits Documentation/scheduler/sched-deadline.txt | 204 ++--- 1 file changed, 159 insertions(+), 45 deletions(-) -- 2.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/4] Documentation/scheduler/sched-deadline.txt: improve and clarify AC bits
From: Luca Abeni
Admission control is of key importance for SCHED_DEADLINE, since it guarantees
system schedulability (or tells us something about the degree of guarantees
we can provide to the user).
This patch improves and clarifies bits and pieces regarding AC, both for UP
and SMP systems.
Signed-off-by: Luca Abeni
Signed-off-by: Juri Lelli
Cc: Randy Dunlap
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Henrik Austad
Cc: Dario Faggioli
Cc: Juri Lelli
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
Documentation/scheduler/sched-deadline.txt | 89 +-
1 file changed, 75 insertions(+), 14 deletions(-)
diff --git a/Documentation/scheduler/sched-deadline.txt
b/Documentation/scheduler/sched-deadline.txt
index 0aff2d5..641395e 100644
--- a/Documentation/scheduler/sched-deadline.txt
+++ b/Documentation/scheduler/sched-deadline.txt
@@ -38,16 +38,17 @@ CONTENTS
==
SCHED_DEADLINE uses three parameters, named "runtime", "period", and
- "deadline" to schedule tasks. A SCHED_DEADLINE task is guaranteed to receive
+ "deadline", to schedule tasks. A SCHED_DEADLINE task should receive
"runtime" microseconds of execution time every "period" microseconds, and
these "runtime" microseconds are available within "deadline" microseconds
from the beginning of the period. In order to implement this behaviour,
every time the task wakes up, the scheduler computes a "scheduling deadline"
consistent with the guarantee (using the CBS[2,3] algorithm). Tasks are then
scheduled using EDF[1] on these scheduling deadlines (the task with the
- closest scheduling deadline is selected for execution). Notice that this
- guaranteed is respected if a proper "admission control" strategy (see Section
- "4. Bandwidth management") is used.
+ closest scheduling deadline is selected for execution). Notice that the
+ task actually receives "runtime" time units within "deadline" if a proper
+ "admission control" strategy (see Section "4. Bandwidth management") is used
+ (clearly, if the system is overloaded this guarantee cannot be respected).
Summing up, the CBS[2,3] algorithms assigns scheduling deadlines to tasks so
that each task runs for at most its runtime every period, avoiding any
@@ -134,6 +135,50 @@ CONTENTS
A real-time task can be periodic with period P if r_{j+1} = r_j + P, or
sporadic with minimum inter-arrival time P is r_{j+1} >= r_j + P. Finally,
d_j = r_j + D, where D is the task's relative deadline.
+ The utilisation of a real-time task is defined as the ratio between its
+ WCET and its period (or minimum inter-arrival time), and represents
+ the fraction of CPU time needed to execute the task.
+
+ If the total utilisation sum_i(WCET_i/P_i) is larger than M (with M equal
+ to the number of CPUs), then the scheduler is unable to respect all the
+ deadlines.
+ Note that total utilisation is defined as the sum of the utilisations
+ WCET_i/P_i over all the real-time tasks in the system. When considering
+ multiple real-time tasks, the parameters of the i-th task are indicated
+ with the "_i" suffix.
+ Moreover, if the total utilisation is larger than M, then we risk starving
+ non- real-time tasks by real-time tasks.
+ If, instead, the total utilisation is smaller than M, then non real-time
+ tasks will not be starved and the system might be able to respect all the
+ deadlines.
+ As a matter of fact, in this case it is possible to provide an upper bound
+ for tardiness (defined as the maximum between 0 and the difference
+ between the finishing time of a job and its absolute deadline).
+ More precisely, it can be proven that using a global EDF scheduler the
+ maximum tardiness of each task is smaller or equal than
+ ((M − 1) · WCET_max − WCET_min)/(M − (M − 2) · U_max) + WCET_max
+ where WCET_max = max_i{WCET_i} is the maximum WCET, WCET_min=min_i{WCET_i}
+ is the minimum WCET, and U_max = max_i{WCET_i/P_i} is the maximum utilisation.
+
+ If M=1 (uniprocessor system), or in case of partitioned scheduling (each
+ real-time task is statically assigned to one and only one CPU), it is
+ possible to formally check if all the deadlines are respected.
+ If D_i = P_i for all tasks, then EDF is able to respect all the deadlines
+ of all the tasks executing on a CPU if and only if the total utilisation
+ of the tasks running on such a CPU is smaller or equal than 1.
+ If D_i != P_i for some task, then it is possible to define the density of
+ a task as C_i/min{D_i,T_i}, and EDF is able to respect all the deadlines
+ of all the tasks running on a CPU if the sum sum_i C_i/min{D_i,T_i} of the
+ densities of the tasks running on such a CPU is smaller or equal than 1
+ (notice that this condition is only sufficient, and not necessary).
+
+ On multiprocessor systems with global EDF scheduling (non partitioned
+ systems), a sufficient test for schedulability can not be based on the
+ utilisations (it can be shown that task sets with utilisations slight
[PATCH v3 1/4] Documentation/scheduler/sched-deadline.txt: fix terminology and improve clarity
From: Luca Abeni Several small changes regarding SCHED_DEADLINE documentation that fix terminology and improve clarity and readability: - "current runtime" becomes "remaining runtime" - readablity of an equation is improved by introducing more spacing - clarify when admission control will certainly fail - new URL for CBS technical report - substitue "smallest" with "closest" Signed-off-by: Luca Abeni Signed-off-by: Juri Lelli Cc: Randy Dunlap Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Henrik Austad Cc: Dario Faggioli Cc: Juri Lelli Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Documentation/scheduler/sched-deadline.txt | 32 -- 1 file changed, 17 insertions(+), 15 deletions(-) diff --git a/Documentation/scheduler/sched-deadline.txt b/Documentation/scheduler/sched-deadline.txt index 18adc92..dce6d63 100644 --- a/Documentation/scheduler/sched-deadline.txt +++ b/Documentation/scheduler/sched-deadline.txt @@ -45,14 +45,14 @@ CONTENTS every time the task wakes up, the scheduler computes a "scheduling deadline" consistent with the guarantee (using the CBS[2,3] algorithm). Tasks are then scheduled using EDF[1] on these scheduling deadlines (the task with the - smallest scheduling deadline is selected for execution). Notice that this + closest scheduling deadline is selected for execution). Notice that this guaranteed is respected if a proper "admission control" strategy (see Section "4. Bandwidth management") is used. Summing up, the CBS[2,3] algorithms assigns scheduling deadlines to tasks so that each task runs for at most its runtime every period, avoiding any interference between different tasks (bandwidth isolation), while the EDF[1] - algorithm selects the task with the smallest scheduling deadline as the one + algorithm selects the task with the closest scheduling deadline as the one to be executed first. Thanks to this feature, also tasks that do not strictly comply with the "traditional" real-time task model (see Section 3) can effectively use the new policy. @@ -64,45 +64,45 @@ CONTENTS "deadline", and "period" parameters; - The state of the task is described by a "scheduling deadline", and -a "current runtime". These two parameters are initially set to 0; +a "remaining runtime". These two parameters are initially set to 0; - When a SCHED_DEADLINE task wakes up (becomes ready for execution), the scheduler checks if -current runtimeruntime - -- > - scheduling deadline - current time period + remaining runtime runtime +-->- +scheduling deadline - current time period then, if the scheduling deadline is smaller than the current time, or this condition is verified, the scheduling deadline and the -current budget are re-initialised as +remaining runtime are re-initialised as scheduling deadline = current time + deadline - current runtime = runtime + remaining runtime = runtime -otherwise, the scheduling deadline and the current runtime are +otherwise, the scheduling deadline and the remaining runtime are left unchanged; - When a SCHED_DEADLINE task executes for an amount of time t, its -current runtime is decreased as +remaining runtime is decreased as - current runtime = current runtime - t + remaining runtime = remaining runtime - t (technically, the runtime is decreased at every tick, or when the task is descheduled / preempted); - - When the current runtime becomes less or equal than 0, the task is + - When the remaining runtime becomes less or equal than 0, the task is said to be "throttled" (also known as "depleted" in real-time literature) and cannot be scheduled until its scheduling deadline. The "replenishment time" for this task (see next item) is set to be equal to the current value of the scheduling deadline; - When the current time is equal to the replenishment time of a -throttled task, the scheduling deadline and the current runtime are +throttled task, the scheduling deadline and the remaining runtime are updated as scheduling deadline = scheduling deadline + period - current runtime = current runtime + runtime + remaining runtime = remaining runtime + runtime 3. Scheduling Real-Time Tasks @@ -147,6 +147,8 @@ CONTENTS and the absolute deadlines (d_j) coincide, so a proper admission control allows to respect the jobs' absolute deadlines for this task (this is what is called "hard schedulability property" and is an extension of Lemma 1 of [2]). + Notice that if runtime > deadline the admission control will surely reject + this task, as it is not possible to respect its temporal
[PATCH v3 2/4] Documentation/scheduler/sched-deadline.txt: Rewrite section 4 intro
Section 4 intro was still describing the old interface. Rewrite it. Signed-off-by: Juri Lelli Signed-off-by: Luca Abeni Cc: Randy Dunlap Cc: Peter Zijlstra Cc: Ingo Molnar Cc: Henrik Austad Cc: Dario Faggioli Cc: Juri Lelli Cc: linux-...@vger.kernel.org Cc: linux-kernel@vger.kernel.org --- Documentation/scheduler/sched-deadline.txt | 51 +++--- 1 file changed, 25 insertions(+), 26 deletions(-) diff --git a/Documentation/scheduler/sched-deadline.txt b/Documentation/scheduler/sched-deadline.txt index dce6d63..0aff2d5 100644 --- a/Documentation/scheduler/sched-deadline.txt +++ b/Documentation/scheduler/sched-deadline.txt @@ -165,39 +165,38 @@ CONTENTS In order for the -deadline scheduling to be effective and useful, it is important to have some method to keep the allocation of the available CPU - bandwidth to the tasks under control. - This is usually called "admission control" and if it is not performed at all, - no guarantee can be given on the actual scheduling of the -deadline tasks. - - Since when RT-throttling has been introduced each task group has a bandwidth - associated, calculated as a certain amount of runtime over a period. - Moreover, to make it possible to manipulate such bandwidth, readable/writable - controls have been added to both procfs (for system wide settings) and cgroupfs - (for per-group settings). - Therefore, the same interface is being used for controlling the bandwidth - distrubution to -deadline tasks. - - However, more discussion is needed in order to figure out how we want to manage - SCHED_DEADLINE bandwidth at the task group level. Therefore, SCHED_DEADLINE - uses (for now) a less sophisticated, but actually very sensible, mechanism to - ensure that a certain utilization cap is not overcome per each root_domain. - - Another main difference between deadline bandwidth management and RT-throttling + bandwidth to the tasks under control. This is usually called "admission + control" and if it is not performed at all, no guarantee can be given on + the actual scheduling of the -deadline tasks. + + The interface used to control the fraction of CPU bandwidth that can be + allocated to -deadline tasks is similar to the one already used for -rt + tasks with real-time group scheduling (a.k.a. RT-throttling - see + Documentation/scheduler/sched-rt-group.txt), and is based on readable/ + writable control files located in procfs (for system wide settings). + Notice that per-group settings (controlled through cgroupfs) are still not + defined for -deadline tasks, because more discussion is needed in order to + figure out how we want to manage SCHED_DEADLINE bandwidth at the task group + level. + + A main difference between deadline bandwidth management and RT-throttling is that -deadline tasks have bandwidth on their own (while -rt ones don't!), - and thus we don't need an higher level throttling mechanism to enforce the - desired bandwidth. + and thus we don't need a higher level throttling mechanism to enforce the + desired bandwidth. Therefore, using this simple interface we can put a cap + on total utilization of -deadline tasks (i.e., \Sum (runtime_i / period_i) < + some_desired_value). 4.1 System wide settings The system wide settings are configured under the /proc virtual file system. - For now the -rt knobs are used for dl admission control and the -deadline - runtime is accounted against the -rt runtime. We realise that this isn't - entirely desirable; however, it is better to have a small interface for now, - and be able to change it easily later. The ideal situation (see 5.) is to run - -rt tasks from a -deadline server; in which case the -rt bandwidth is a direct - subset of dl_bw. + For now the -rt knobs are used for -deadline admission control and the + -deadline runtime is accounted against the -rt runtime. We realise that this + isn't entirely desirable; however, it is better to have a small interface for + now, and be able to change it easily later. The ideal situation (see 5.) is to + run -rt tasks from a -deadline server; in which case the -rt bandwidth is a + direct subset of dl_bw. This means that, for a root_domain comprising M CPUs, -deadline tasks can be created while the sum of their bandwidths stays below: -- 2.0.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] regulator: max77802: set opmode to normal if off is read from hw
On Thu, Aug 28, 2014 at 11:59:16AM +0200, Javier Martinez Canillas wrote: > > On 28/08/2014, at 10:28, Mark Brown wrote: > >> Yes, AFAIK the bootloader (none of them because Chromebooks use two > >> chained U-boots) change the regulators default opmode so once is set > >> to OFF on .disable, that value is preserved on warm reboot. This made > >> sense with the Chrome OS kernel since the kernel always set the opmode > >> defined in the "regulator-op-mode" DT property and did not relied on > >> the bootloader to set the most efficient default opmode. > > I'm sorry but this is just really unclear. Does the bootloader change > > the mode or does it not change the mode? > I meant that the boot loader *does not* change the mode and is Linux > who change it, sorry for the confusion. Ah, OK. Like I say that's a separate concern to the one Tomasz was raising - he is worried about the case where we change the mode in the bootloader but only on cold boot. signature.asc Description: Digital signature
RE: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms CLK_OF_DECLARE support
>-Original Message-
>From: Wood Scott-B07421
>Sent: Thursday, August 28, 2014 7:34 AM
>To: Lu Jingchang-B35083
>Cc: mturque...@linaro.org; linuxppc-...@lists.ozlabs.org; linux-
>ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
>Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based platforms
>CLK_OF_DECLARE support
>
>On Tue, 2014-08-26 at 21:19 -0500, Lu Jingchang-B35083 wrote:
>> >-Original Message-
>> >From: Wood Scott-B07421
>> >Sent: Wednesday, August 27, 2014 6:51 AM
>> >To: Lu Jingchang-B35083
>> >Cc: mturque...@linaro.org; linuxppc-...@lists.ozlabs.org; linux-
>> >ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
>> >Subject: Re: [RESEND] clk: ppc-corenet: Add Freescale ARM-based
>> >platforms CLK_OF_DECLARE support
>> >
>> >On Fri, 2014-08-22 at 17:34 +0800, Jingchang Lu wrote:
>> >> +CLK_OF_DECLARE(ppc_core_pll_v1, "fsl,qoriq-core-pll-1.0",
>> >core_pll_init);
>> >> +CLK_OF_DECLARE(ppc_core_pll_v2, "fsl,qoriq-core-pll-2.0",
>> >core_pll_init);
>> >> +CLK_OF_DECLARE(ppc_core_mux_v1, "fsl,qoriq-core-mux-1.0",
>> >core_mux_init);
>> >> +CLK_OF_DECLARE(ppc_core_mux_v2, "fsl,qoriq-core-mux-2.0",
>> >core_mux_init);
>> >
>> >What does this do that the existing platform driver and match table
>> >don't? Why is it needed for ARM when PPC didn't need it?
>> >
>> >-Scott
>> >
>> Common clk init on ARM platform is initialized earlier via
>> of_clk_init() instead of driver probe method, the of_clk_init will
>> walk a __clk_of_table to init each clk provider in the table, the
>> CLK_OF_DECLARE() macro puts a supported clk in the __clk_of_table for it
>initializing on starup, and the clk system has added some common clk such
>as "fixed-clk"
>> to this table already.
>> So here I add our specific clk init declaration to consist this
>> framework, and the driver probe function will not be needed on ARM.
>
>OK... Is there any reason why the new method won't work on PPC?
>
PPC has little dependence on the clock tree but frequency, it will work well
if adopted I think.
Best Regards,
Jingchang
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
