* [PATCH v3 0/6] efuse driver for Tegra
From: Peter De Schrijver @ 2014-01-30 9:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAP=VYLpJT1T2RGuK73TXhSYn-K+ZrLx9FuhQe+hVXYGnfoOBcQ@mail.gmail.com>
On Wed, Jan 29, 2014 at 04:00:27PM +0100, Paul Gortmaker wrote:
> On Tue, Jan 28, 2014 at 6:36 PM, Peter De Schrijver
> <pdeschrijver@nvidia.com> wrote:
> > This driver allows userspace to read the raw efuse data. Its userspace
> > interface is modelled after the sunxi_sid driver which provides similar
> > functionality for some Allwinner SoCs. It has been tested on
> > Tegra20 (ventana), Tegra30 (beaverboard) and Tegra114 (dalmore).
> >
> > Changes since v1:
> >
> > * Add documentation for sysfs interface
> > * Cleanup messages
> >
> > Changes since v2:
> >
> > * Incorporate early fuse code
> > * Remove module support
> > * Make driver always build when Tegra platform is selected
>
> Given the above, you should be able to remove #include <linux/module.h>
> and MODULE_DEVICE_TABLE, etc.
Indeed. Thanks for noticing!
Cheers,
Peter.
^ permalink raw reply
* [PATCH v2 0/6] setting the table for integration of cpuidle with the scheduler
From: Peter Zijlstra @ 2014-01-30 9:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391017513-12995-1-git-send-email-nicolas.pitre@linaro.org>
On Wed, Jan 29, 2014 at 12:45:07PM -0500, Nicolas Pitre wrote:
> As everyone should know by now, we want to integrate the cpuidle
> governor with the scheduler for a more efficient idling of CPUs.
> In order to help the transition, this small patch series moves the
> existing interaction with cpuidle from architecture code to generic
> core code. The ARM, PPC, SH and X86 architectures are concerned.
> No functional change should have occurred yet.
>
> @peterz: Are you willing to pick up those patches?
Yeah.. no objections. Should I pick these up or will you be sending
another round?
^ permalink raw reply
* [PATCH v2 5/6] X86: remove redundant cpuidle_idle_call()
From: Peter Zijlstra @ 2014-01-30 9:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401291434120.1652@knanqh.ubzr>
On Wed, Jan 29, 2014 at 03:14:40PM -0500, Nicolas Pitre wrote:
> Looking into some cpuidle drivers for x86 I found at least one that
> doesn't respect this convention. Damn.
Which one? We should probably fix it :-)
^ permalink raw reply
* [U-Boot] recommended action for bootloaders regarding modifying device-tree nodes
From: Michal Suchanek @ 2014-01-30 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU366GiY4k_rnh1Jf0kra+PU99w4tDdM2sNioUAJCiZqOA@mail.gmail.com>
Hello,
On 30 January 2014 10:11, Tim Harvey <tharvey@gateworks.com> wrote:
> Greetings,
>
>
> Is it more appropriate for the bootloader to 'remove' nodes for
> devices that are not physically present or should I be setting their
> status property to 'disabled' instead? I'm not clear if either option
> really has any pros or cons.
>
I am not a DT or u-boot developer but I observe these things:
1) DT include for a SoC has all supported devices. Some which require
external parts (eg. physical connectors, extra PHY, ...) are listed as
disabled and particular board DT enables them.
2) there is code for setting mac address on ethernet nodes with a
specific alias so you could perhaps reuse this code to set disabled
option on particular nodes.
Thanks
Michal
^ permalink raw reply
* recommended action for bootloaders regarding modifying device-tree nodes
From: Tim Harvey @ 2014-01-30 9:11 UTC (permalink / raw)
To: linux-arm-kernel
Greetings,
I develop the boot-loader and kernel for a family of boards that have
an on-board EEPROM which contains information as to what options are
physically loaded on the board such as memory size/config, and
peripheral IC's. We allow customers to create special builds of our
standard products with sub-loaded components and while each
combination of options ends up with a unique model number, it seems
silly to create a different static device-trees for each possible
option (not to mention we don't create the unique model number until
an order is placed).
My approach has been to define a per-baseboard device-tree in Linux
for a 'fully loaded' board, then remove nodes which the EEPROM claims
are not present in the bootloader before it passes the DTB to the
kernel. I do this by defining aliases in the device-tree for the
peripherals that are 'optional' so that the bootloader itself does not
need to know the details about how the device is connected.
Is it more appropriate for the bootloader to 'remove' nodes for
devices that are not physically present or should I be setting their
status property to 'disabled' instead? I'm not clear if either option
really has any pros or cons.
Thanks for any suggestions or comments,
Tim
Tim Harvey - Principal Software Engineer
Gateworks Corporation
3026 S. Higuera St. San Luis Obispo CA 93401
805-781-2000
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH v2 08/14] mtd: nand: add sunxi NAND flash controller support
From: Boris BREZILLON @ 2014-01-30 8:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129191005.GG1427@obsidianresearch.com>
On 29/01/2014 20:10, Jason Gunthorpe wrote:
> On Wed, Jan 29, 2014 at 03:46:20PM -0300, Ezequiel Garcia wrote:
>
>> After CE# has been pulled high and then transitioned low again, the host
>> should issue a Set Features to select the appropriate asynchronous timing mode.
>> """
> Oh, I had forgot you should do a set feature too
>
> Boris, I think the core core should handle this dance and the driver
> should just implement a call back to change the timing mode on the
> interface..
>
> If I ever get a moment I can work on support for timing setting in the
> mvebu driver, I have boards here with ONFI NAND..
Okay, I'll wait :).
Thanks.
>
> Regards,
> Jason
>
^ permalink raw reply
* [PATCH v2] ARM: iop32x: fix power off handling for the EM7210 board
From: Linus Walleij @ 2014-01-30 8:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87lhxyfkax.fsf@lebrac.rtp-net.org>
On Thu, Jan 30, 2014 at 12:19 AM, Arnaud Patard
<arnaud.patard@rtp-net.org> wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:
>> void em7210_power_off(void)
>> {
>> - *IOP3XX_GPOE &= 0xfe;
>> - *IOP3XX_GPOD |= 0x01;
>> + int ret;
>> +
>> + ret = gpio_direction_output(EM7210_HARDWARE_POWER, 1);
>
> btw, any reason for not using gpio_direction_output() in
> em7210_request_gpios() and gpio_set_value() here ? (just wondering)
Mainly because the old code did not drive a default value on
the pin (which would be zero then) but relies on the power-on
default.
So by not doing this I'm not poking any hardware that wasn't poked
earlier.
> I can't test it on my ss4000e but at least this patch looks fine.
Would be nice!
Yours,
Linus Walleij
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
From: boris brezillon dev @ 2014-01-30 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391035079.14902.3.camel@localhost>
Hello Henrik,
Sorry for the noise, I sent the mail to Rob's old address.
On 29/01/2014 23:37, Henrik Nordstr?m wrote:
> ons 2014-01-29 klockan 11:11 -0600 skrev Rob Herring:
>
>> Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B
>> pin is an option? If so, don't you need some fixed time delay
>> properties like max erase time?
>>
>> rb-gpios could be added to the generic nand binding as well.
> The Allwinner NAND controller have dedicated RB pins when NAND is
> enabled, only MUXed with other functions when NAND is not enabled.
>
> Leaving RB unconnected is not a valid hardware configuration. The
> controller internal timing engine depends on being able to sense RB to
> sequence NAND commands properly.
This is not true (at least in this driver). It was in yuq's driver because
he was using the NFC_WAIT_FLAG ,and in this case the controller wait
for the native R/B pin to be high before considering the CMD is complete.
This driver choose the appropriate way to test the R/B state of the
NAND chip according to what was specified in the DT:
- allwinner,rb: native R/B id. These pins will be used by the NAND
controller to test the R/B state. Only 0 and 1 are valid because the
NAND controller only support 2 R/B pins.
- rb-gpios: gpio used for R/B tests. This is a simple GPIO and will
use the GPIO subsystem to test the R/B pin state.
- none: the NAND base code will wait some time before and send
STATUS cmd to the NAND to check its status.
BTW, the controller supports 8 CS (8 NAND chips), but only have 2 native
R/B pins, this means you'll have to use the GPIO or standard GET_STATUS
method if you connect 3 or more NAND chips.
And for the record, I still think the rb-gpios property (or whatever
common name you choose: nand-rb-gpios ?) should be part of
the generic NAND binding, because other controllers (at least the
atmel one :)) use GPIOs to test R/B state.
Best Regards,
Boris
>
> Regards
> Henrik
>
^ permalink raw reply
* [PATCH 11/11] arm: dma-mapping: Add support to extend DMA IOMMU mappings
From: Andreas Herrmann @ 2014-01-30 8:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA0D43.1010802@samsung.com>
On Thu, Jan 30, 2014 at 03:28:51AM -0500, Marek Szyprowski wrote:
> Hello,
>
> On 2014-01-29 15:40, Andreas Herrmann wrote:
> > Hi Will, Marek,
> >
> > On Wed, Jan 29, 2014 at 06:05:37AM -0500, Will Deacon wrote:
> > > Hi Marek,
> > >
> > > On Wed, Jan 29, 2014 at 10:57:01AM +0000, Marek Szyprowski wrote:
> > > > On 2014-01-16 13:44, Andreas Herrmann wrote:
> > > > > Instead of using just one bitmap to keep track of IO virtual addresses
> > > > > (handed out for IOMMU use) introduce a list of iova_ranges (each
> > > > > having its own bitmap). This allows us to extend existing mappings
> > > > > when running out of iova space for a mapping.
> > > > >
> > > > > If there is not enough space in the mapping to service an IO virtual
> > > > > address allocation request, __alloc_iova() tries to extend the mapping
> > > > > -- by allocating another bitmap -- and makes another allocation
> > > > > attempt using the freshly allocated bitmap.
> > > > >
> > > > > This allows arm iommu drivers to start with a decent initial size when
> > > > > an dma_iommu_mapping is created and still to avoid running out of IO
> > > > > virtual addresses for the mapping.
> > > > >
> > > > > Tests were done on Calxeda ECX-2000 with smmu for sata and xgmac.
> > > > > I've used SZ_512K both for initial mapping size and grow_size.
> > > >
> > > > Thanks for implementing this feature! I remember it was discussed from
> > > > early beginning of arm dma iommu support, but I never had enough time
> > > > to actually implement it. I briefly checked the code and it look fine,
> > > > however I really wonder if we need separate grow_size parameter?
> > > > Personally I would simplify it to simply grow the bitmap by initial
> > > > size until it reaches the maximal size.
> > >
> > > That sounds sensible, but I also think it would be worth taking into account
> > > the page sizes supported by the IOMMU as well, since aligning to those makes
> > > sense from a TLB utilisation perspective.
> >
> > Meanwhile I also think that the grow_size parameter is overkill. Only
> > the initial mapping size and the maximum size really matter. Then we
> > could try to extend the mapping by initial mapping size and if this
> > fails (we might not have enough pages to serve such an allocation) we
> > could/should even fall back to allocate a single page (which should
> > give us at least a 16MB range).
> >
> > > > The whole concept of the simplified bitmap (where 1 bit != 1 page) for
> > > > iova allocation is a specific feature of this code and it has nothing
> > > > to the hardware. After thinking a bit more on the existing
> > > > implementation I've already observed that it is sometimes hard to
> > > > understand the parameters for arm_iommu_create_mapping() function,
> > > > especially the 'order' argument is ofter misunderstood. With your
> > > > patch we got two additional parameters. Maybe it will be much better
> > > > to use only 2 arguments: max_mapping_size and allocation_accuracy.
> > > > The initial bitmap size can be then calculated to fit it into single
> > > > memory page (that's quite important to avoid allocations larger that
> > > > a single memory page). 'allocation_accuracy' will serve the same way
> > > > as 'order' parameter now (but expressed in bytes rather than being
> > > > the multiplier for the number of pages). This way the
> > > > arm_iommu_create_mapping() function should be much easier to
> > > > understand, while keeping the implementation details hidden from the
> > > > caller.
> > >
> > > Hmm, I wouldn't guess the SI unit of accuracy to be bytes ;)
> >
> > Have to think about the alignment argument and the last paragraph for
> > a while.
> >
> > All I can say now is that starting with a bitmap size that fits into a
> > single memory page doesn't sound right to me. The initial allocation
> > is "easy" (not GFP_ATOMIC) and thus I think we should start with a
> > larger bitmap. Say you have a device for which at runtime 512MB
> > mapping range are required and you use a 4k page for the bitmaps (each
> > tracking 16MB IOVA range) you'll have 32 bitmaps to maintain. Whereas
> > when you start with 128MB initial bitmap size and (successfully)
> > enhance the mapping by 128MB you just have to maintain 4 bitmaps.
>
> Huh? In the 'worst' case scenario (1 bit represents 1 page) a bitmap
> which occupies a single memory page holds 4096 bytes (PAGE SIZE) * 8
> (bits/byte) = 32768 bits, what gives us 32768 * 4KiB (PAGE SIZE) = 128MiB
> of address space, so for 512MiB mapping you just need at most 4 pages for
> bitmap.
Arrgh, yes of course it's 128 and not 16 MB. (That's the reason why I
had chosen 128MB as the initial and grow size.) Not sure why I came up
with the 16MB thing yesterday. Sorry.
Of course that means that the number of bitmaps to maintain is
manageable (at least for most devices).
> Maybe the whole concept of simplified bitmap was already an over
> engineering from the beginning? I've added it to increase total supported
> mapping size (in my case I worked with devices which allocates quite
> large buffers), but now I see that it is not really needed if we have
> dynamically extended bitmaps.
>
> BTW, I thought a bit more one your implementation and I think that it will
> be better to replace lists with simple arrays of bitmaps. We know the
> maximum number of sub-bitmaps from beginning and such approach will
> simplify iova freeing (no need for searching the address in a list).
Yep, that sounds reasonable.
> > But of course coming up with the right choice for the initial bitmap
> > size that fits all master devices is a hard thing to do ...
>
> Right, but the dynamically extended bitmaps will adapt to particular use
> cases, so the initial values doesn't really matter that much.
Yes, (now that's again clear on my end that we cover 128MB ranges with
a bitmap of one page ;-) I don't see an issue here anymore.
Andreas
^ permalink raw reply
* [linux-sunxi] Re: [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
From: boris brezillon dev @ 2014-01-30 8:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391035079.14902.3.camel@localhost>
Hello Henrik,
On 29/01/2014 23:37, Henrik Nordstr?m wrote:
> ons 2014-01-29 klockan 11:11 -0600 skrev Rob Herring:
>
>> Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B
>> pin is an option? If so, don't you need some fixed time delay
>> properties like max erase time?
>>
>> rb-gpios could be added to the generic nand binding as well.
> The Allwinner NAND controller have dedicated RB pins when NAND is
> enabled, only MUXed with other functions when NAND is not enabled.
>
> Leaving RB unconnected is not a valid hardware configuration. The
> controller internal timing engine depends on being able to sense RB to
> sequence NAND commands properly.
This is not true (at least in this driver). It was in yuq's driver because
he was using the NFC_WAIT_FLAG ,and in this case the controller wait
for the native R/B pin to be high before considering the CMD is complete.
This driver choose the appropriate way to test the R/B state of the
NAND chip according to what was specified in the DT:
- allwinner,rb: native R/B id. These pins will be used by the NAND
controller to test the R/B state. Only 0 and 1 are valid because the
NAND controller only support 2 R/B pins.
- rb-gpios: gpio used for R/B tests. This is a simple GPIO and will
use the GPIO subsystem to test the R/B pin state.
- none: the NAND base code will wait some time before and send
STATUS cmd to the NAND to check its status.
BTW, the controller supports 8 CS (8 NAND chips), but only have 2 native
R/B pins, this means you'll have to use the GPIO or standard GET_STATUS
method if you connect 3 or more NAND chips.
And for the record, I still think the rb-gpios property (or whatever
common name you choose: nand-rb-gpios ?) should be part of
the generic NAND binding, because other controllers (at least the
atmel one :)) use GPIOs to test R/B state.
Best Regards,
Boris
>
> Regards
> Henrik
>
^ permalink raw reply
* [PATCH 11/11] arm: dma-mapping: Add support to extend DMA IOMMU mappings
From: Marek Szyprowski @ 2014-01-30 8:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140129144017.GA13543@alberich>
Hello,
On 2014-01-29 15:40, Andreas Herrmann wrote:
> Hi Will, Marek,
>
> On Wed, Jan 29, 2014 at 06:05:37AM -0500, Will Deacon wrote:
> > Hi Marek,
> >
> > On Wed, Jan 29, 2014 at 10:57:01AM +0000, Marek Szyprowski wrote:
> > > On 2014-01-16 13:44, Andreas Herrmann wrote:
> > > > Instead of using just one bitmap to keep track of IO virtual addresses
> > > > (handed out for IOMMU use) introduce a list of iova_ranges (each
> > > > having its own bitmap). This allows us to extend existing mappings
> > > > when running out of iova space for a mapping.
> > > >
> > > > If there is not enough space in the mapping to service an IO virtual
> > > > address allocation request, __alloc_iova() tries to extend the mapping
> > > > -- by allocating another bitmap -- and makes another allocation
> > > > attempt using the freshly allocated bitmap.
> > > >
> > > > This allows arm iommu drivers to start with a decent initial size when
> > > > an dma_iommu_mapping is created and still to avoid running out of IO
> > > > virtual addresses for the mapping.
> > > >
> > > > Tests were done on Calxeda ECX-2000 with smmu for sata and xgmac.
> > > > I've used SZ_512K both for initial mapping size and grow_size.
> > >
> > > Thanks for implementing this feature! I remember it was discussed from
> > > early beginning of arm dma iommu support, but I never had enough time
> > > to actually implement it. I briefly checked the code and it look fine,
> > > however I really wonder if we need separate grow_size parameter?
> > > Personally I would simplify it to simply grow the bitmap by initial
> > > size until it reaches the maximal size.
> >
> > That sounds sensible, but I also think it would be worth taking into account
> > the page sizes supported by the IOMMU as well, since aligning to those makes
> > sense from a TLB utilisation perspective.
>
> Meanwhile I also think that the grow_size parameter is overkill. Only
> the initial mapping size and the maximum size really matter. Then we
> could try to extend the mapping by initial mapping size and if this
> fails (we might not have enough pages to serve such an allocation) we
> could/should even fall back to allocate a single page (which should
> give us at least a 16MB range).
>
> > > The whole concept of the simplified bitmap (where 1 bit != 1 page) for
> > > iova allocation is a specific feature of this code and it has nothing
> > > to the hardware. After thinking a bit more on the existing
> > > implementation I've already observed that it is sometimes hard to
> > > understand the parameters for arm_iommu_create_mapping() function,
> > > especially the 'order' argument is ofter misunderstood. With your
> > > patch we got two additional parameters. Maybe it will be much better
> > > to use only 2 arguments: max_mapping_size and allocation_accuracy.
> > > The initial bitmap size can be then calculated to fit it into single
> > > memory page (that's quite important to avoid allocations larger that
> > > a single memory page). 'allocation_accuracy' will serve the same way
> > > as 'order' parameter now (but expressed in bytes rather than being
> > > the multiplier for the number of pages). This way the
> > > arm_iommu_create_mapping() function should be much easier to
> > > understand, while keeping the implementation details hidden from the
> > > caller.
> >
> > Hmm, I wouldn't guess the SI unit of accuracy to be bytes ;)
>
> Have to think about the alignment argument and the last paragraph for
> a while.
>
> All I can say now is that starting with a bitmap size that fits into a
> single memory page doesn't sound right to me. The initial allocation
> is "easy" (not GFP_ATOMIC) and thus I think we should start with a
> larger bitmap. Say you have a device for which at runtime 512MB
> mapping range are required and you use a 4k page for the bitmaps (each
> tracking 16MB IOVA range) you'll have 32 bitmaps to maintain. Whereas
> when you start with 128MB initial bitmap size and (successfully)
> enhance the mapping by 128MB you just have to maintain 4 bitmaps.
Huh? In the 'worst' case scenario (1 bit represents 1 page) a bitmap
which occupies a single memory page holds 4096 bytes (PAGE SIZE) * 8
(bits/byte) = 32768 bits, what gives us 32768 * 4KiB (PAGE SIZE) = 128MiB
of address space, so for 512MiB mapping you just need at most 4 pages for
bitmap.
Maybe the whole concept of simplified bitmap was already an over
engineering from the beginning? I've added it to increase total supported
mapping size (in my case I worked with devices which allocates quite
large buffers), but now I see that it is not really needed if we have
dynamically extended bitmaps.
BTW, I thought a bit more one your implementation and I think that it will
be better to replace lists with simple arrays of bitmaps. We know the
maximum number of sub-bitmaps from beginning and such approach will
simplify iova freeing (no need for searching the address in a list).
> But of course coming up with the right choice for the initial bitmap
> size that fits all master devices is a hard thing to do ...
Right, but the dynamically extended bitmaps will adapt to particular use
cases, so the initial values doesn't really matter that much.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* imx-drm: screen flickering
From: Sascha Hauer @ 2014-01-30 7:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401291553.15040.marex@denx.de>
On Wed, Jan 29, 2014 at 03:53:14PM +0100, Marek Vasut wrote:
> On Wednesday, January 29, 2014 at 12:15:57 PM, Sascha Hauer wrote:
> > Hi Christian,
> >
> > On Tue, Jan 28, 2014 at 09:11:32AM +0100, Christian Gmeiner wrote:
> > > Hi all.
> > >
> > > From time to time it happens that my LVDS display is flickering (look
> > > at scroll bar in the video).
> > > https://drive.google.com/file/d/0B_fznDimUHVubWtvVFlMTkdBbUU/edit?usp=sha
> > > ring
> > >
> > > I really want to find the root cause of it, but I do not know where to
> > > start. I can trigger this
> > > sometimes after xscreensever "blanks" the screen and the screensafer
> > > gets disabled
> > > via user input.
> > >
> > > Any hints?
> >
> > Sorry, no idea. Philipp and me watched the video, but we both haven't
> > seen something like this before.
>
> Isn't it the clock polarity being inverted thing again [1]?
Could be, at least the result should look similar. I just wonder why it
only happens after a few times doing something. I would expect the clock
is always inverted then.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH v2 2/2] drivers/media: s5p-mfc: Add Horizontal and Vertical MV Search Range
From: Hans Verkuil @ 2014-01-30 7:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391060563-27015-3-git-send-email-amit.grover@samsung.com>
On 01/30/2014 06:42 AM, Amit Grover wrote:
> This patch adds Controls to set Horizontal and Vertical search range
> for Motion Estimation block for Samsung MFC video Encoders.
>
> Signed-off-by: Swami Nathan <swaminath.p@samsung.com>
> Signed-off-by: Amit Grover <amit.grover@samsung.com>
> ---
> drivers/media/platform/s5p-mfc/regs-mfc-v6.h | 1 +
> drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
> drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 24 +++++++++++++++++++++++
> drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 8 ++------
> 4 files changed, 29 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
> index 2398cdf..8d0b686 100644
> --- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
> +++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
> @@ -229,6 +229,7 @@
> #define S5P_FIMV_E_PADDING_CTRL_V6 0xf7a4
> #define S5P_FIMV_E_MV_HOR_RANGE_V6 0xf7ac
> #define S5P_FIMV_E_MV_VER_RANGE_V6 0xf7b0
> +#define S5P_FIMV_E_MV_RANGE_V6_MASK 0x3fff
>
> #define S5P_FIMV_E_VBV_BUFFER_SIZE_V6 0xf84c
> #define S5P_FIMV_E_VBV_INIT_DELAY_V6 0xf850
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> index 6920b54..b90ee34 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
> @@ -430,6 +430,8 @@ struct s5p_mfc_vp8_enc_params {
> struct s5p_mfc_enc_params {
> u16 width;
> u16 height;
> + u32 mv_h_range;
> + u32 mv_v_range;
>
> u16 gop_size;
> enum v4l2_mpeg_video_multi_slice_mode slice_mode;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> index 4ff3b6c..704f30c1 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
> @@ -208,6 +208,24 @@ static struct mfc_control controls[] = {
> .default_value = 0,
> },
> {
> + .id = V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "Horizontal MV Search Range",
Don't set the name here if the control is also defined in v4l2-ctrls.
That way the string from v4l2-ctrls is the leading definition.
Regards,
Hans
> + .minimum = 16,
> + .maximum = 128,
> + .step = 16,
> + .default_value = 32,
> + },
> + {
> + .id = V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE,
> + .type = V4L2_CTRL_TYPE_INTEGER,
> + .name = "Vertical MV Search Range",
> + .minimum = 16,
> + .maximum = 128,
> + .step = 16,
> + .default_value = 32,
> + },
> + {
> .id = V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE,
> .type = V4L2_CTRL_TYPE_INTEGER,
> .minimum = 0,
> @@ -1377,6 +1395,12 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
> case V4L2_CID_MPEG_VIDEO_VBV_SIZE:
> p->vbv_size = ctrl->val;
> break;
> + case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
> + p->mv_h_range = ctrl->val;
> + break;
> + case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
> + p->mv_v_range = ctrl->val;
> + break;
> case V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE:
> p->codec.h264.cpb_size = ctrl->val;
> break;
> diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> index 461358c..3c10188 100644
> --- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
> @@ -727,14 +727,10 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx *ctx)
> WRITEL(reg, S5P_FIMV_E_RC_CONFIG_V6);
>
> /* setting for MV range [16, 256] */
> - reg = 0;
> - reg &= ~(0x3FFF);
> - reg = 256;
> + reg = (p->mv_h_range & S5P_FIMV_E_MV_RANGE_V6_MASK);
> WRITEL(reg, S5P_FIMV_E_MV_HOR_RANGE_V6);
>
> - reg = 0;
> - reg &= ~(0x3FFF);
> - reg = 256;
> + reg = (p->mv_v_range & S5P_FIMV_E_MV_RANGE_V6_MASK);
> WRITEL(reg, S5P_FIMV_E_MV_VER_RANGE_V6);
>
> WRITEL(0x0, S5P_FIMV_E_FRAME_INSERTION_V6);
>
^ permalink raw reply
* [PATCH v2 1/2] drivers/media: v4l2: Add settings for Horizontal and Vertical MV Search Range
From: Hans Verkuil @ 2014-01-30 7:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391060563-27015-2-git-send-email-amit.grover@samsung.com>
On 01/30/2014 06:42 AM, Amit Grover wrote:
> Adding V4L2 controls for horizontal and vertical search range in pixels
> for motion estimation module in video encoder.
>
> Signed-off-by: Swami Nathan <swaminath.p@samsung.com>
> Signed-off-by: Amit Grover <amit.grover@samsung.com>
> ---
> Documentation/DocBook/media/v4l/controls.xml | 20 ++++++++++++++++++++
> drivers/media/v4l2-core/v4l2-ctrls.c | 14 ++++++++++++++
> include/uapi/linux/v4l2-controls.h | 2 ++
> 3 files changed, 36 insertions(+)
>
> diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml
> index 7a3b49b..be04d18 100644
> --- a/Documentation/DocBook/media/v4l/controls.xml
> +++ b/Documentation/DocBook/media/v4l/controls.xml
> @@ -2258,6 +2258,26 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry>
> VBV buffer control.</entry>
> </row>
>
> + <row><entry></entry></row>
> + <row id=""v4l2-mpeg-video-hor-search-range">
> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE</constant> </entry>
> + <entry>integer</entry>
> + </row>
> + <row><entry spanname="descr">Horizontal search range defines maximum horizontal search area in pixels
> +to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
> +horizontal search range for motion estimation module in video encoder.</entry>
> + </row>
> +
> + <row><entry></entry></row>
> + <row id="v4l2-mpeg-video-vert-search-range">
> + <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE</constant> </entry>
> + <entry>integer</entry>
These two controls sound very mfc specific as opposed to being part of the standard.
If so, then they should be named V4L2_CID_MPEG_MFC51_*. Also, for which codecs are
these controls applicable?
> + </row>
> + <row><entry spanname="descr">Vertical search range defines maximum vertical search area in pixels
> +to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
> +vertical search range for motion estimation module in video encoder.</entry>
> + </row>
> +
> <row><entry></entry></row>
> <row>
> <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry>
> diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
> index fb46790..e775388 100644
> --- a/drivers/media/v4l2-core/v4l2-ctrls.c
> +++ b/drivers/media/v4l2-core/v4l2-ctrls.c
> @@ -735,6 +735,8 @@ const char *v4l2_ctrl_get_name(u32 id)
> case V4L2_CID_MPEG_VIDEO_DEC_PTS: return "Video Decoder PTS";
> case V4L2_CID_MPEG_VIDEO_DEC_FRAME: return "Video Decoder Frame Count";
> case V4L2_CID_MPEG_VIDEO_VBV_DELAY: return "Initial Delay for VBV Control";
> + case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE: return "Horizontal MV Search Range";
> + case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: return "Vertical MV Search Range";
> case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return "Repeat Sequence Header";
>
> /* VPX controls */
> @@ -905,6 +907,18 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
> *min = 0;
> *max = *step = 1;
> break;
> + case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
> + *type = V4L2_CTRL_TYPE_INTEGER;
> + *min = 16;
> + *max = 128;
> + *step = 16;
Weird range, why not use range 1-8?
> + break;
> + case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
> + *type = V4L2_CTRL_TYPE_INTEGER;
> + *min = 16;
> + *max = 128;
> + *step = 16;
> + break;
> case V4L2_CID_PAN_RESET:
> case V4L2_CID_TILT_RESET:
> case V4L2_CID_FLASH_STROBE:
> diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
> index 1666aab..80e1def 100644
> --- a/include/uapi/linux/v4l2-controls.h
> +++ b/include/uapi/linux/v4l2-controls.h
> @@ -372,6 +372,8 @@ enum v4l2_mpeg_video_multi_slice_mode {
> #define V4L2_CID_MPEG_VIDEO_DEC_FRAME (V4L2_CID_MPEG_BASE+224)
> #define V4L2_CID_MPEG_VIDEO_VBV_DELAY (V4L2_CID_MPEG_BASE+225)
> #define V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER (V4L2_CID_MPEG_BASE+226)
> +#define V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE (V4L2_CID_MPEG_BASE+227)
> +#define V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE (V4L2_CID_MPEG_BASE+228)
>
> #define V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP (V4L2_CID_MPEG_BASE+300)
> #define V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP (V4L2_CID_MPEG_BASE+301)
>
Regards,
Hans
^ permalink raw reply
* [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding
From: Andy Gross @ 2014-01-30 6:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4697306.PPWWh8UGTE@wuerfel>
On Tue, Jan 28, 2014 at 10:16:53AM +0100, Arnd Bergmann wrote:
> On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote:
> > > +
> > > +Clients must use the format described in the dma.txt file, using a three cell
> > > +specifier for each channel.
> > > +
> > > +The three cells in order are:
> > > + 1. A phandle pointing to the DMA controller
> > > + 2. The channel number
> > > + 3. Direction of the fixed unidirectional channel
> > > + 0 - Memory to Device
> > > + 1 - Device to Memory
> > > + 2 - Device to Device
> > > +
> >
> > Why does the direction needs to be specified in specifier? I see two
> > options, either the direction per is fixed in hardware. In that case the DMA
> > controller node should describe which channel is which direction. Or the
> > direction is not fixed in hardware and can be changed at runtime in which
> > case it should be set on a per descriptor basis.
>
> Normally the direction is implied by dmaengine_slave_config().
> Note that neither the dma slave API nor the generic DT binding
> can actually support device-to-device transfers, since this
> normally implies using two dma-request lines rather than one.
>
> There might be a case where the direction is required in order
> to allocate a channel, because the engine has specialized channels
> per direction, and might connect any of them to any dma request
> line. This does not seem to be the case for "bam", because
> the DMA specifier already contains a specific channel number, not
> a request line or slave ID number.
After some deliberation, I think the best solution is removing the direction
from the DT for now. It doesn't add anything except some verification
of direction.
As for the device to device:
As I mentioned before, each bam dma node is attached to a specific peripheral
(with one exception, but lets skip over that). The peripherals allow for more
than one execution environment to access the peripheral and attached bam. 2 bam
channels can be connected to form a unidirectional pipe from one execution
environment to another. Once the pipe is configured, the actually transfer
resembles a cyclical dma transfer and continues until you explicitly stop it.
That functionality will come later.
--
sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
^ permalink raw reply
* [PATCH V2] arm64: add DSB after icache flush in __flush_icache_all()
From: Vinayak Kale @ 2014-01-30 6:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140128161402.GI2885@mudshark.cambridge.arm.com>
Hi Will,
On Tue, Jan 28, 2014 at 9:44 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Tue, Jan 28, 2014 at 07:06:53AM +0000, Vinayak Kale wrote:
>> Add DSB after icache flush. It's needed to complete the cache maintenance
>> operation. The function __flush_icache_all() is used only for user space
>> mappings and an ISB is not required because of an exception return before
>> executing user instructions. An exception return would behave like an ISB.
>>
>> This patch also uses 'memory' clobber for flush operation instruction to
>> prevent instruction re-ordering by compiler.
>>
>> Signed-off-by: Vinayak Kale <vkale@apm.com>
>> ---
>>
>> V2: - Add more desciption in the commit message as suggested by Catalin & Will
>> - Use 'memory' clobber for flush instruction as suggested by Will
>
> Please can you check and fix other occurrences of this bug too, as I asked
> in v1? For example, a 2 second grep shows problems with data-cache
> maintenance in kvm. I can also see the same problem for system register
> writes followed up with isb.
Can you please elaborate whether you are referring to lack of memory
clobber or missing barriers?
>
> I also don't buy you not being able to test AArch32 kernels. Does KVM not
> work for you?
Let me see what I can do to address this.
>
> Will
>
>>
>> arch/arm64/include/asm/cacheflush.h | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/cacheflush.h b/arch/arm64/include/asm/cacheflush.h
>> index fea9ee3..bd30f42 100644
>> --- a/arch/arm64/include/asm/cacheflush.h
>> +++ b/arch/arm64/include/asm/cacheflush.h
>> @@ -115,7 +115,8 @@ extern void flush_dcache_page(struct page *);
>>
>> static inline void __flush_icache_all(void)
>> {
>> - asm("ic ialluis");
>> + asm volatile("ic ialluis" : : : "memory");
>> + dsb();
>> }
>>
>> #define flush_dcache_mmap_lock(mapping) \
>> --
>> 1.8.2.1
>>
>>
^ permalink raw reply
* [PATCH v2 0/2] drivers/media: Add controls for Horizontal and Vertical MV Search Range
From: Sachin Kamat @ 2014-01-30 6:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391060563-27015-1-git-send-email-amit.grover@samsung.com>
Hi Amit,
On 30 January 2014 11:12, Amit Grover <amit.grover@samsung.com> wrote:
> Based on 'master' branch of Linux-next.
Kamil's tree [1] would be more current most of the times for this driver.
[1] git://linuxtv.org/kdebski/media.git
> This is v2 version for the patch:
> s5p-mfc: Add Horizontal and Vertical search range for Video Macro Blocks
> (https://lkml.org/lkml/2013/12/30/83)
>
> Changes from v1:
> 1) Splitted the patch into v4l2 and mfc driver patches.
> 2) Incorporated review comments of v1
>
> Amit Grover (2):
> drivers/media: v4l2: Add settings for Horizontal and Vertical MV
> Search Range
> drivers/media: s5p-mfc: Add Horizontal and Vertical MV Search Range
nit: media changes use the following title format:
[media] v4l2: Add settings for Horizontal and Vertical MV Search Range
[media] s5p-mfc: Add Horizontal and Vertical MV Search Range
--
With warm regards,
Sachin
^ permalink raw reply
* [PATCH] serial: sirf: move to use generic dma dt-binding to get dma channels
From: Barry Song @ 2014-01-30 5:57 UTC (permalink / raw)
To: linux-arm-kernel
From: Qipan Li <Qipan.Li@csr.com>
instead of using sirf specific dma channel property like "sirf,uart-dma-rx-channel"
and "sirf,uart-dma-tx-channel", here we move to use generic dma dt-binding to get
the channel like:
- sirf,uart-dma-rx-channel = <21>;
- sirf,uart-dma-tx-channel = <2>;
+ dmas = <&dmac1 5>, <&dmac0 2>;
+ dma-names = "rx", "tx";
and we move dma_request_channel() to dma_request_slave_channel(), we don't need to
call sirfsoc dma filter function sirfsoc_dma_filter_id() again.
Signed-off-by: Qipan Li <Qipan.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
arch/arm/boot/dts/atlas6.dtsi | 17 ++--
arch/arm/boot/dts/prima2.dtsi | 20 ++--
drivers/tty/serial/sirfsoc_uart.c | 195 ++++++++++++-------------------------
drivers/tty/serial/sirfsoc_uart.h | 5 -
4 files changed, 81 insertions(+), 156 deletions(-)
diff --git a/arch/arm/boot/dts/atlas6.dtsi b/arch/arm/boot/dts/atlas6.dtsi
index f8674bc..0c81dc9 100644
--- a/arch/arm/boot/dts/atlas6.dtsi
+++ b/arch/arm/boot/dts/atlas6.dtsi
@@ -217,8 +217,8 @@
interrupts = <17>;
fifosize = <128>;
clocks = <&clks 13>;
- sirf,uart-dma-rx-channel = <21>;
- sirf,uart-dma-tx-channel = <2>;
+ dmas = <&dmac1 5>, <&dmac0 2>;
+ dma-names = "rx", "tx";
};
uart1: uart at b0060000 {
@@ -228,6 +228,7 @@
interrupts = <18>;
fifosize = <32>;
clocks = <&clks 14>;
+ dma-names = "no-rx", "no-tx";
};
uart2: uart at b0070000 {
@@ -237,8 +238,8 @@
interrupts = <19>;
fifosize = <128>;
clocks = <&clks 15>;
- sirf,uart-dma-rx-channel = <6>;
- sirf,uart-dma-tx-channel = <7>;
+ dmas = <&dmac0 6>, <&dmac0 7>;
+ dma-names = "rx", "tx";
};
usp0: usp at b0080000 {
@@ -248,8 +249,8 @@
interrupts = <20>;
fifosize = <128>;
clocks = <&clks 28>;
- sirf,usp-dma-rx-channel = <17>;
- sirf,usp-dma-tx-channel = <18>;
+ dmas = <&dmac1 1>, <&dmac1 2>;
+ dma-names = "rx", "tx";
};
usp1: usp at b0090000 {
@@ -259,8 +260,8 @@
interrupts = <21>;
fifosize = <128>;
clocks = <&clks 29>;
- sirf,usp-dma-rx-channel = <14>;
- sirf,usp-dma-tx-channel = <15>;
+ dmas = <&dmac0 14>, <&dmac0 15>;
+ dma-names = "rx", "tx";
};
dmac0: dma-controller at b00b0000 {
diff --git a/arch/arm/boot/dts/prima2.dtsi b/arch/arm/boot/dts/prima2.dtsi
index 0e21993..8582ae4 100644
--- a/arch/arm/boot/dts/prima2.dtsi
+++ b/arch/arm/boot/dts/prima2.dtsi
@@ -223,8 +223,8 @@
interrupts = <17>;
fifosize = <128>;
clocks = <&clks 13>;
- sirf,uart-dma-rx-channel = <21>;
- sirf,uart-dma-tx-channel = <2>;
+ dmas = <&dmac1 5>, <&dmac0 2>;
+ dma-names = "rx", "tx";
};
uart1: uart at b0060000 {
@@ -243,8 +243,8 @@
interrupts = <19>;
fifosize = <128>;
clocks = <&clks 15>;
- sirf,uart-dma-rx-channel = <6>;
- sirf,uart-dma-tx-channel = <7>;
+ dmas = <&dmac0 6>, <&dmac0 7>;
+ dma-names = "rx", "tx";
};
usp0: usp at b0080000 {
@@ -254,8 +254,8 @@
interrupts = <20>;
fifosize = <128>;
clocks = <&clks 28>;
- sirf,usp-dma-rx-channel = <17>;
- sirf,usp-dma-tx-channel = <18>;
+ dmas = <&dmac1 1>, <&dmac1 2>;
+ dma-names = "rx", "tx";
};
usp1: usp at b0090000 {
@@ -265,8 +265,8 @@
interrupts = <21>;
fifosize = <128>;
clocks = <&clks 29>;
- sirf,usp-dma-rx-channel = <14>;
- sirf,usp-dma-tx-channel = <15>;
+ dmas = <&dmac0 14>, <&dmac0 15>;
+ dma-names = "rx", "tx";
};
usp2: usp at b00a0000 {
@@ -276,8 +276,8 @@
interrupts = <22>;
fifosize = <128>;
clocks = <&clks 30>;
- sirf,usp-dma-rx-channel = <10>;
- sirf,usp-dma-tx-channel = <11>;
+ dmas = <&dmac0 10>, <&dmac0 11>;
+ dma-names = "rx", "tx";
};
dmac0: dma-controller at b00b0000 {
diff --git a/drivers/tty/serial/sirfsoc_uart.c b/drivers/tty/serial/sirfsoc_uart.c
index b7bfe24..68b0fd4 100644
--- a/drivers/tty/serial/sirfsoc_uart.c
+++ b/drivers/tty/serial/sirfsoc_uart.c
@@ -24,7 +24,6 @@
#include <linux/dmaengine.h>
#include <linux/dma-direction.h>
#include <linux/dma-mapping.h>
-#include <linux/sirfsoc_dma.h>
#include <asm/irq.h>
#include <asm/mach/irq.h>
@@ -173,7 +172,7 @@ static void sirfsoc_uart_stop_tx(struct uart_port *port)
struct sirfsoc_register *ureg = &sirfport->uart_reg->uart_reg;
struct sirfsoc_int_en *uint_en = &sirfport->uart_reg->uart_int_en;
- if (IS_DMA_CHAN_VALID(sirfport->tx_dma_no)) {
+ if (sirfport->tx_dma_chan) {
if (sirfport->tx_dma_state == TX_DMA_RUNNING) {
dmaengine_pause(sirfport->tx_dma_chan);
sirfport->tx_dma_state = TX_DMA_PAUSE;
@@ -288,7 +287,7 @@ static void sirfsoc_uart_start_tx(struct uart_port *port)
struct sirfsoc_uart_port *sirfport = to_sirfport(port);
struct sirfsoc_register *ureg = &sirfport->uart_reg->uart_reg;
struct sirfsoc_int_en *uint_en = &sirfport->uart_reg->uart_int_en;
- if (IS_DMA_CHAN_VALID(sirfport->tx_dma_no))
+ if (sirfport->tx_dma_chan)
sirfsoc_uart_tx_with_dma(sirfport);
else {
sirfsoc_uart_pio_tx_chars(sirfport, 1);
@@ -310,7 +309,7 @@ static void sirfsoc_uart_stop_rx(struct uart_port *port)
struct sirfsoc_int_en *uint_en = &sirfport->uart_reg->uart_int_en;
wr_regl(port, ureg->sirfsoc_rx_fifo_op, 0);
- if (IS_DMA_CHAN_VALID(sirfport->rx_dma_no)) {
+ if (sirfport->rx_dma_chan) {
if (!sirfport->is_marco)
wr_regl(port, ureg->sirfsoc_int_en_reg,
rd_regl(port, ureg->sirfsoc_int_en_reg) &
@@ -675,7 +674,7 @@ recv_char:
uart_handle_cts_change(port, cts_status);
wake_up_interruptible(&state->port.delta_msr_wait);
}
- if (IS_DMA_CHAN_VALID(sirfport->rx_dma_no)) {
+ if (sirfport->rx_dma_chan) {
if (intr_status & uint_st->sirfsoc_rx_timeout)
sirfsoc_uart_handle_rx_tmo(sirfport);
if (intr_status & uint_st->sirfsoc_rx_done)
@@ -686,7 +685,7 @@ recv_char:
SIRFSOC_UART_IO_RX_MAX_CNT);
}
if (intr_status & uint_st->sirfsoc_txfifo_empty) {
- if (IS_DMA_CHAN_VALID(sirfport->tx_dma_no))
+ if (sirfport->tx_dma_chan)
sirfsoc_uart_tx_with_dma(sirfport);
else {
if (uart_circ_empty(xmit) || uart_tx_stopped(port)) {
@@ -778,7 +777,7 @@ static void sirfsoc_uart_start_rx(struct uart_port *port)
wr_regl(port, ureg->sirfsoc_rx_fifo_op, SIRFUART_FIFO_RESET);
wr_regl(port, ureg->sirfsoc_rx_fifo_op, 0);
wr_regl(port, ureg->sirfsoc_rx_fifo_op, SIRFUART_FIFO_START);
- if (IS_DMA_CHAN_VALID(sirfport->rx_dma_no))
+ if (sirfport->rx_dma_chan)
sirfsoc_uart_start_next_rx_dma(port);
else {
if (!sirfport->is_marco)
@@ -1014,11 +1013,11 @@ static void sirfsoc_uart_set_termios(struct uart_port *port,
(sample_div_reg & SIRFSOC_USP_ASYNC_DIV2_MASK) <<
SIRFSOC_USP_ASYNC_DIV2_OFFSET);
}
- if (IS_DMA_CHAN_VALID(sirfport->tx_dma_no))
+ if (sirfport->tx_dma_chan)
wr_regl(port, ureg->sirfsoc_tx_dma_io_ctrl, SIRFUART_DMA_MODE);
else
wr_regl(port, ureg->sirfsoc_tx_dma_io_ctrl, SIRFUART_IO_MODE);
- if (IS_DMA_CHAN_VALID(sirfport->rx_dma_no))
+ if (sirfport->rx_dma_chan)
wr_regl(port, ureg->sirfsoc_rx_dma_io_ctrl, SIRFUART_DMA_MODE);
else
wr_regl(port, ureg->sirfsoc_rx_dma_io_ctrl, SIRFUART_IO_MODE);
@@ -1049,93 +1048,6 @@ static void sirfsoc_uart_pm(struct uart_port *port, unsigned int state,
clk_disable_unprepare(sirfport->clk);
}
-static unsigned int sirfsoc_uart_init_tx_dma(struct uart_port *port)
-{
- struct sirfsoc_uart_port *sirfport = to_sirfport(port);
- dma_cap_mask_t dma_mask;
- struct dma_slave_config tx_slv_cfg = {
- .dst_maxburst = 2,
- };
-
- dma_cap_zero(dma_mask);
- dma_cap_set(DMA_SLAVE, dma_mask);
- sirfport->tx_dma_chan = dma_request_channel(dma_mask,
- (dma_filter_fn)sirfsoc_dma_filter_id,
- (void *)sirfport->tx_dma_no);
- if (!sirfport->tx_dma_chan) {
- dev_err(port->dev, "Uart Request Dma Channel Fail %d\n",
- sirfport->tx_dma_no);
- return -EPROBE_DEFER;
- }
- dmaengine_slave_config(sirfport->tx_dma_chan, &tx_slv_cfg);
-
- return 0;
-}
-
-static unsigned int sirfsoc_uart_init_rx_dma(struct uart_port *port)
-{
- struct sirfsoc_uart_port *sirfport = to_sirfport(port);
- dma_cap_mask_t dma_mask;
- int ret;
- int i, j;
- struct dma_slave_config slv_cfg = {
- .src_maxburst = 2,
- };
-
- dma_cap_zero(dma_mask);
- dma_cap_set(DMA_SLAVE, dma_mask);
- sirfport->rx_dma_chan = dma_request_channel(dma_mask,
- (dma_filter_fn)sirfsoc_dma_filter_id,
- (void *)sirfport->rx_dma_no);
- if (!sirfport->rx_dma_chan) {
- dev_err(port->dev, "Uart Request Dma Channel Fail %d\n",
- sirfport->rx_dma_no);
- ret = -EPROBE_DEFER;
- goto request_err;
- }
- for (i = 0; i < SIRFSOC_RX_LOOP_BUF_CNT; i++) {
- sirfport->rx_dma_items[i].xmit.buf =
- dma_alloc_coherent(port->dev, SIRFSOC_RX_DMA_BUF_SIZE,
- &sirfport->rx_dma_items[i].dma_addr, GFP_KERNEL);
- if (!sirfport->rx_dma_items[i].xmit.buf) {
- dev_err(port->dev, "Uart alloc bufa failed\n");
- ret = -ENOMEM;
- goto alloc_coherent_err;
- }
- sirfport->rx_dma_items[i].xmit.head =
- sirfport->rx_dma_items[i].xmit.tail = 0;
- }
- dmaengine_slave_config(sirfport->rx_dma_chan, &slv_cfg);
-
- return 0;
-alloc_coherent_err:
- for (j = 0; j < i; j++)
- dma_free_coherent(port->dev, SIRFSOC_RX_DMA_BUF_SIZE,
- sirfport->rx_dma_items[j].xmit.buf,
- sirfport->rx_dma_items[j].dma_addr);
- dma_release_channel(sirfport->rx_dma_chan);
-request_err:
- return ret;
-}
-
-static void sirfsoc_uart_uninit_tx_dma(struct sirfsoc_uart_port *sirfport)
-{
- dmaengine_terminate_all(sirfport->tx_dma_chan);
- dma_release_channel(sirfport->tx_dma_chan);
-}
-
-static void sirfsoc_uart_uninit_rx_dma(struct sirfsoc_uart_port *sirfport)
-{
- int i;
- struct uart_port *port = &sirfport->port;
- dmaengine_terminate_all(sirfport->rx_dma_chan);
- dma_release_channel(sirfport->rx_dma_chan);
- for (i = 0; i < SIRFSOC_RX_LOOP_BUF_CNT; i++)
- dma_free_coherent(port->dev, SIRFSOC_RX_DMA_BUF_SIZE,
- sirfport->rx_dma_items[i].xmit.buf,
- sirfport->rx_dma_items[i].dma_addr);
-}
-
static int sirfsoc_uart_startup(struct uart_port *port)
{
struct sirfsoc_uart_port *sirfport = to_sirfport(port);
@@ -1174,18 +1086,12 @@ static int sirfsoc_uart_startup(struct uart_port *port)
wr_regl(port, ureg->sirfsoc_rx_fifo_op, 0);
wr_regl(port, ureg->sirfsoc_tx_fifo_ctrl, SIRFUART_FIFO_THD(port));
wr_regl(port, ureg->sirfsoc_rx_fifo_ctrl, SIRFUART_FIFO_THD(port));
-
- if (IS_DMA_CHAN_VALID(sirfport->rx_dma_no)) {
- ret = sirfsoc_uart_init_rx_dma(port);
- if (ret)
- goto init_rx_err;
+ if (sirfport->rx_dma_chan)
wr_regl(port, ureg->sirfsoc_rx_fifo_level_chk,
- SIRFUART_RX_FIFO_CHK_SC(port->line, 0x4) |
- SIRFUART_RX_FIFO_CHK_LC(port->line, 0xe) |
- SIRFUART_RX_FIFO_CHK_HC(port->line, 0x1b));
- }
- if (IS_DMA_CHAN_VALID(sirfport->tx_dma_no)) {
- sirfsoc_uart_init_tx_dma(port);
+ SIRFUART_RX_FIFO_CHK_SC(port->line, 0x4) |
+ SIRFUART_RX_FIFO_CHK_LC(port->line, 0xe) |
+ SIRFUART_RX_FIFO_CHK_HC(port->line, 0x1b));
+ if (sirfport->tx_dma_chan) {
sirfport->tx_dma_state = TX_DMA_IDLE;
wr_regl(port, ureg->sirfsoc_tx_fifo_level_chk,
SIRFUART_TX_FIFO_CHK_SC(port->line, 0x1b) |
@@ -1232,12 +1138,8 @@ static void sirfsoc_uart_shutdown(struct uart_port *port)
gpio_set_value(sirfport->rts_gpio, 1);
free_irq(gpio_to_irq(sirfport->cts_gpio), sirfport);
}
- if (IS_DMA_CHAN_VALID(sirfport->rx_dma_no))
- sirfsoc_uart_uninit_rx_dma(sirfport);
- if (IS_DMA_CHAN_VALID(sirfport->tx_dma_no)) {
- sirfsoc_uart_uninit_tx_dma(sirfport);
+ if (sirfport->tx_dma_chan)
sirfport->tx_dma_state = TX_DMA_IDLE;
- }
}
static const char *sirfsoc_uart_type(struct uart_port *port)
@@ -1313,8 +1215,8 @@ sirfsoc_uart_console_setup(struct console *co, char *options)
port->cons = co;
/* default console tx/rx transfer using io mode */
- sirfport->rx_dma_no = UNVALID_DMA_CHAN;
- sirfport->tx_dma_no = UNVALID_DMA_CHAN;
+ sirfport->rx_dma_chan = NULL;
+ sirfport->tx_dma_chan = NULL;
return uart_set_options(port, co, baud, parity, bits, flow);
}
@@ -1382,6 +1284,13 @@ static int sirfsoc_uart_probe(struct platform_device *pdev)
struct uart_port *port;
struct resource *res;
int ret;
+ int i, j;
+ struct dma_slave_config slv_cfg = {
+ .src_maxburst = 2,
+ };
+ struct dma_slave_config tx_slv_cfg = {
+ .dst_maxburst = 2,
+ };
const struct of_device_id *match;
match = of_match_node(sirfsoc_uart_ids, pdev->dev.of_node);
@@ -1402,27 +1311,10 @@ static int sirfsoc_uart_probe(struct platform_device *pdev)
sirfport->hw_flow_ctrl = of_property_read_bool(pdev->dev.of_node,
"sirf,uart-has-rtscts");
- if (of_device_is_compatible(pdev->dev.of_node, "sirf,prima2-uart")) {
+ if (of_device_is_compatible(pdev->dev.of_node, "sirf,prima2-uart"))
sirfport->uart_reg->uart_type = SIRF_REAL_UART;
- if (of_property_read_u32(pdev->dev.of_node,
- "sirf,uart-dma-rx-channel",
- &sirfport->rx_dma_no))
- sirfport->rx_dma_no = UNVALID_DMA_CHAN;
- if (of_property_read_u32(pdev->dev.of_node,
- "sirf,uart-dma-tx-channel",
- &sirfport->tx_dma_no))
- sirfport->tx_dma_no = UNVALID_DMA_CHAN;
- }
if (of_device_is_compatible(pdev->dev.of_node, "sirf,prima2-usp-uart")) {
sirfport->uart_reg->uart_type = SIRF_USP_UART;
- if (of_property_read_u32(pdev->dev.of_node,
- "sirf,usp-dma-rx-channel",
- &sirfport->rx_dma_no))
- sirfport->rx_dma_no = UNVALID_DMA_CHAN;
- if (of_property_read_u32(pdev->dev.of_node,
- "sirf,usp-dma-tx-channel",
- &sirfport->tx_dma_no))
- sirfport->tx_dma_no = UNVALID_DMA_CHAN;
if (!sirfport->hw_flow_ctrl)
goto usp_no_flow_control;
if (of_find_property(pdev->dev.of_node, "cts-gpios", NULL))
@@ -1515,8 +1407,32 @@ usp_no_flow_control:
goto port_err;
}
- return 0;
+ sirfport->rx_dma_chan = dma_request_slave_channel(port->dev, "rx");
+ for (i = 0; sirfport->rx_dma_chan && i < SIRFSOC_RX_LOOP_BUF_CNT; i++) {
+ sirfport->rx_dma_items[i].xmit.buf =
+ dma_alloc_coherent(port->dev, SIRFSOC_RX_DMA_BUF_SIZE,
+ &sirfport->rx_dma_items[i].dma_addr, GFP_KERNEL);
+ if (!sirfport->rx_dma_items[i].xmit.buf) {
+ dev_err(port->dev, "Uart alloc bufa failed\n");
+ ret = -ENOMEM;
+ goto alloc_coherent_err;
+ }
+ sirfport->rx_dma_items[i].xmit.head =
+ sirfport->rx_dma_items[i].xmit.tail = 0;
+ }
+ if (sirfport->rx_dma_chan)
+ dmaengine_slave_config(sirfport->rx_dma_chan, &slv_cfg);
+ sirfport->tx_dma_chan = dma_request_slave_channel(port->dev, "tx");
+ if (sirfport->tx_dma_chan)
+ dmaengine_slave_config(sirfport->tx_dma_chan, &tx_slv_cfg);
+ return 0;
+alloc_coherent_err:
+ for (j = 0; j < i; j++)
+ dma_free_coherent(port->dev, SIRFSOC_RX_DMA_BUF_SIZE,
+ sirfport->rx_dma_items[j].xmit.buf,
+ sirfport->rx_dma_items[j].dma_addr);
+ dma_release_channel(sirfport->rx_dma_chan);
port_err:
clk_put(sirfport->clk);
err:
@@ -1529,6 +1445,19 @@ static int sirfsoc_uart_remove(struct platform_device *pdev)
struct uart_port *port = &sirfport->port;
clk_put(sirfport->clk);
uart_remove_one_port(&sirfsoc_uart_drv, port);
+ if (sirfport->rx_dma_chan) {
+ int i;
+ dmaengine_terminate_all(sirfport->rx_dma_chan);
+ dma_release_channel(sirfport->rx_dma_chan);
+ for (i = 0; i < SIRFSOC_RX_LOOP_BUF_CNT; i++)
+ dma_free_coherent(port->dev, SIRFSOC_RX_DMA_BUF_SIZE,
+ sirfport->rx_dma_items[i].xmit.buf,
+ sirfport->rx_dma_items[i].dma_addr);
+ }
+ if (sirfport->tx_dma_chan) {
+ dmaengine_terminate_all(sirfport->tx_dma_chan);
+ dma_release_channel(sirfport->tx_dma_chan);
+ }
return 0;
}
diff --git a/drivers/tty/serial/sirfsoc_uart.h b/drivers/tty/serial/sirfsoc_uart.h
index b7d679c..8a6edda 100644
--- a/drivers/tty/serial/sirfsoc_uart.h
+++ b/drivers/tty/serial/sirfsoc_uart.h
@@ -392,9 +392,6 @@ struct sirfsoc_uart_register sirfsoc_uart = {
/* Indicate how many buffers used */
#define SIRFSOC_RX_LOOP_BUF_CNT 2
-/* Indicate if DMA channel valid */
-#define IS_DMA_CHAN_VALID(x) ((x) != -1)
-#define UNVALID_DMA_CHAN -1
/* For Fast Baud Rate Calculation */
struct sirfsoc_baudrate_to_regv {
unsigned int baud_rate;
@@ -423,8 +420,6 @@ struct sirfsoc_uart_port {
/* for SiRFmarco, there are SET/CLR for UART_INT_EN */
bool is_marco;
struct sirfsoc_uart_register *uart_reg;
- int rx_dma_no;
- int tx_dma_no;
struct dma_chan *rx_dma_chan;
struct dma_chan *tx_dma_chan;
dma_addr_t tx_dma_addr;
--
1.7.5.4
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: sirf: add pin group for USP0 with only RX or TX frame sync for atlas6
From: Barry Song @ 2014-01-30 5:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Rongjun Ying <rongjun.ying@csr.com>
add pin groups for USP0 only holding one of TX and RX frame sync. this patch
matches with the change in drivers/pinctrl/sirf.
commit 73f68c01f46 did this for prima2, but missed prima2. this patch fixes
the problem.
Signed-off-by: Rongjun Ying <rongjun.ying@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
arch/arm/boot/dts/atlas6.dtsi | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/atlas6.dtsi b/arch/arm/boot/dts/atlas6.dtsi
index 0c81dc9..8e60ae1 100644
--- a/arch/arm/boot/dts/atlas6.dtsi
+++ b/arch/arm/boot/dts/atlas6.dtsi
@@ -551,6 +551,18 @@
sirf,function = "usp0_uart_nostreamctrl";
};
};
+ usp0_only_utfs_pins_a: usp0 at 2 {
+ usp0 {
+ sirf,pins = "usp0_only_utfs_grp";
+ sirf,function = "usp0_only_utfs";
+ };
+ };
+ usp0_only_urfs_pins_a: usp0 at 3 {
+ usp0 {
+ sirf,pins = "usp0_only_urfs_grp";
+ sirf,function = "usp0_only_urfs";
+ };
+ };
usp1_pins_a: usp1 at 0 {
usp1 {
sirf,pins = "usp1grp";
--
1.7.5.4
^ permalink raw reply related
* [PATCH 1/2] pinctrl: sirf: add pin group for USP0 with only RX or TX frame sync for atlas6
From: Barry Song @ 2014-01-30 5:54 UTC (permalink / raw)
To: linux-arm-kernel
From: Rongjun Ying <rongjun.ying@csr.com>
USP0 has multiple functions, and has RX and TX frame sync signals, for some scenarios
like audio PCM, we don't need both of them. so here we add two possibilities for USP0
only holding one of TX and RX frame sync.
commit 8385af02bad only added this group for prima2, and missed atlas6. her this patch
fixes it.
Signed-off-by: Rongjun Ying <rongjun.ying@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
drivers/pinctrl/sirf/pinctrl-atlas6.c | 43 +++++++++++++++++++++++++++++++++
1 files changed, 43 insertions(+), 0 deletions(-)
diff --git a/drivers/pinctrl/sirf/pinctrl-atlas6.c b/drivers/pinctrl/sirf/pinctrl-atlas6.c
index 2b9f320..09211fb 100644
--- a/drivers/pinctrl/sirf/pinctrl-atlas6.c
+++ b/drivers/pinctrl/sirf/pinctrl-atlas6.c
@@ -529,6 +529,40 @@ static const struct sirfsoc_padmux usp0_padmux = {
static const unsigned usp0_pins[] = { 51, 52, 53, 54, 55 };
+static const struct sirfsoc_muxmask usp0_only_utfs_muxmask[] = {
+ {
+ .group = 1,
+ .mask = BIT(19) | BIT(20) | BIT(21) | BIT(22),
+ },
+};
+
+static const struct sirfsoc_padmux usp0_only_utfs_padmux = {
+ .muxmask_counts = ARRAY_SIZE(usp0_only_utfs_muxmask),
+ .muxmask = usp0_only_utfs_muxmask,
+ .ctrlreg = SIRFSOC_RSC_PIN_MUX,
+ .funcmask = BIT(1) | BIT(2) | BIT(6),
+ .funcval = 0,
+};
+
+static const unsigned usp0_only_utfs_pins[] = { 51, 52, 53, 54 };
+
+static const struct sirfsoc_muxmask usp0_only_urfs_muxmask[] = {
+ {
+ .group = 1,
+ .mask = BIT(19) | BIT(20) | BIT(21) | BIT(23),
+ },
+};
+
+static const struct sirfsoc_padmux usp0_only_urfs_padmux = {
+ .muxmask_counts = ARRAY_SIZE(usp0_only_urfs_muxmask),
+ .muxmask = usp0_only_urfs_muxmask,
+ .ctrlreg = SIRFSOC_RSC_PIN_MUX,
+ .funcmask = BIT(1) | BIT(2) | BIT(9),
+ .funcval = 0,
+};
+
+static const unsigned usp0_only_urfs_pins[] = { 51, 52, 53, 55 };
+
static const struct sirfsoc_muxmask usp0_uart_nostreamctrl_muxmask[] = {
{
.group = 1,
@@ -905,6 +939,8 @@ static const struct sirfsoc_pin_group sirfsoc_pin_groups[] = {
SIRFSOC_PIN_GROUP("usp0grp", usp0_pins),
SIRFSOC_PIN_GROUP("usp0_uart_nostreamctrl_grp",
usp0_uart_nostreamctrl_pins),
+ SIRFSOC_PIN_GROUP("usp0_only_utfs_grp", usp0_only_utfs_pins),
+ SIRFSOC_PIN_GROUP("usp0_only_urfs_grp", usp0_only_urfs_pins),
SIRFSOC_PIN_GROUP("usp1grp", usp1_pins),
SIRFSOC_PIN_GROUP("usp1_uart_nostreamctrl_grp",
usp1_uart_nostreamctrl_pins),
@@ -953,6 +989,9 @@ static const char * const uart2_nostreamctrlgrp[] = { "uart2_nostreamctrlgrp" };
static const char * const usp0_uart_nostreamctrl_grp[] = {
"usp0_uart_nostreamctrl_grp" };
static const char * const usp0grp[] = { "usp0grp" };
+static const char * const usp0_only_utfs_grp[] = { "usp0_only_utfs_grp" };
+static const char * const usp0_only_urfs_grp[] = { "usp0_only_urfs_grp" };
+
static const char * const usp1grp[] = { "usp1grp" };
static const char * const usp1_uart_nostreamctrl_grp[] = {
"usp1_uart_nostreamctrl_grp" };
@@ -1003,6 +1042,10 @@ static const struct sirfsoc_pmx_func sirfsoc_pmx_functions[] = {
SIRFSOC_PMX_FUNCTION("usp0_uart_nostreamctrl",
usp0_uart_nostreamctrl_grp,
usp0_uart_nostreamctrl_padmux),
+ SIRFSOC_PMX_FUNCTION("usp0_only_utfs", usp0_only_utfs_grp,
+ usp0_only_utfs_padmux),
+ SIRFSOC_PMX_FUNCTION("usp0_only_urfs", usp0_only_urfs_grp,
+ usp0_only_urfs_padmux),
SIRFSOC_PMX_FUNCTION("usp1", usp1grp, usp1_padmux),
SIRFSOC_PMX_FUNCTION("usp1_uart_nostreamctrl",
usp1_uart_nostreamctrl_grp,
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 0/5] Smart Card(SC) interface, TI USIM & NxP SC phy driver
From: Satish Patel @ 2014-01-30 5:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390192434-19386-1-git-send-email-satish.patel@ti.com>
On 1/20/2014 10:03 AM, Satish Patel wrote:
> Changes from v1:
> * RFC(v1) comments are fixed
>
> ** removed "gpio_to_irq" as GPIO controller process cell from DT and
> give it to DT node
> ** comments on documentation
> ** few other comments on null checks are resolved
>
> * BWT timing configuration is added to ti-usim driver
>
> v1 cover letter link#
> https://lkml.org/lkml/2014/1/6/250
>
> Satish Patel (5):
> sc_phy:SmartCard(SC) PHY interface to SC controller
> misc: tda8026: Add NXP TDA8026 PHY driver
> char: ti-usim: Add driver for USIM module on AM43xx
> ARM: dts: AM43xx: DT entries added for ti-usim
> ARM: dts: AM43xx-epos-evm: DT entries for ti-usim and phy
>
> Documentation/devicetree/bindings/misc/tda8026.txt | 19 +
> .../devicetree/bindings/ti-usim/ti-usim.txt | 31 +
> Documentation/sc_phy.txt | 171 ++
> arch/arm/boot/dts/am4372.dtsi | 10 +
> arch/arm/boot/dts/am43x-epos-evm.dts | 43 +
> drivers/char/Kconfig | 7 +
> drivers/char/Makefile | 1 +
> drivers/char/ti-usim-hw.h | 863 +++++++++
> drivers/char/ti-usim.c | 1859 ++++++++++++++++++++
> drivers/misc/Kconfig | 7 +
> drivers/misc/Makefile | 1 +
> drivers/misc/tda8026.c | 1255 +++++++++++++
> include/linux/sc_phy.h | 132 ++
> include/linux/ti-usim.h | 98 +
> 14 files changed, 4497 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/misc/tda8026.txt
> create mode 100644 Documentation/devicetree/bindings/ti-usim/ti-usim.txt
> create mode 100644 Documentation/sc_phy.txt
> create mode 100644 drivers/char/ti-usim-hw.h
> create mode 100644 drivers/char/ti-usim.c
> create mode 100644 drivers/misc/tda8026.c
> create mode 100644 include/linux/sc_phy.h
> create mode 100644 include/linux/ti-usim.h
Any comments on this patch series ?
If not,
Can you accept these patches for next merge window
Thanks
Satish
>
>
^ permalink raw reply
* [PATCH v2] pwm: add CSR SiRFSoC PWM driver
From: Barry Song @ 2014-01-30 5:52 UTC (permalink / raw)
To: linux-arm-kernel
From: Rongjun Ying <Rongjun.ying@csr.com>
PWM controller of CSR SiRFSoC can generate 7 independent outputs. Each output
duty cycle can be adjusted by setting the corresponding wait & hold registers.
Supports 7 independent channel output: 6 for external(channel0-5) and 1 for
internal(channel6).
Supports wide frequency range: divide by 2 to 65536*2 of source clock.
Signed-off-by: Rongjun Ying <Rongjun.ying@csr.com>
Signed-off-by: Huayi Li <Huayi.Li@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
---
-v2: clean the source clock of PWM wave, use OSC(26MHz)
drivers/pwm/Kconfig | 9 ++
drivers/pwm/Makefile | 1 +
drivers/pwm/pwm-sirf.c | 294 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 304 insertions(+), 0 deletions(-)
create mode 100644 drivers/pwm/pwm-sirf.c
diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
index 7acab93..0a252f8 100644
--- a/drivers/pwm/Kconfig
+++ b/drivers/pwm/Kconfig
@@ -166,6 +166,15 @@ config PWM_SAMSUNG
To compile this driver as a module, choose M here: the module
will be called pwm-samsung.
+config PWM_SIRF
+ tristate "SiRF PWM support"
+ depends on ARCH_SIRF
+ help
+ Generic PWM framework driver for SiRF SoC.
+
+ To compile this driver as a module, choose M here: the module
+ will be called pwm-sirf.
+
config PWM_SPEAR
tristate "STMicroelectronics SPEAr PWM support"
depends on PLAT_SPEAR
diff --git a/drivers/pwm/Makefile b/drivers/pwm/Makefile
index 4abf337..49ab0d7 100644
--- a/drivers/pwm/Makefile
+++ b/drivers/pwm/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_PWM_PUV3) += pwm-puv3.o
obj-$(CONFIG_PWM_PXA) += pwm-pxa.o
obj-$(CONFIG_PWM_RENESAS_TPU) += pwm-renesas-tpu.o
obj-$(CONFIG_PWM_SAMSUNG) += pwm-samsung.o
+obj-$(CONFIG_PWM_SIRF) += pwm-sirf.o
obj-$(CONFIG_PWM_SPEAR) += pwm-spear.o
obj-$(CONFIG_PWM_TEGRA) += pwm-tegra.o
obj-$(CONFIG_PWM_TIECAP) += pwm-tiecap.o
diff --git a/drivers/pwm/pwm-sirf.c b/drivers/pwm/pwm-sirf.c
new file mode 100644
index 0000000..1a5c5b7
--- /dev/null
+++ b/drivers/pwm/pwm-sirf.c
@@ -0,0 +1,294 @@
+/*
+ * SIRF serial SoC PWM device core driver
+ *
+ * Copyright (c) 2014 Cambridge Silicon Radio Limited, a CSR plc group company.
+ *
+ * Licensed under GPLv2 or later.
+ */
+#include <linux/kernel.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/device.h>
+#include <linux/platform_device.h>
+#include <linux/clk.h>
+#include <linux/delay.h>
+#include <linux/pwm.h>
+#include <linux/of.h>
+#include <linux/io.h>
+
+#define SIRF_PWM_SELECT_PRECLK 0x0
+#define SIRF_PWM_OE 0x4
+#define SIRF_PWM_ENABLE_PRECLOCK 0x8
+#define SIRF_PWM_ENABLE_POSTCLOCK 0xC
+#define SIRF_PWM_GET_WAIT_OFFSET(n) (0x10 + 0x8*n)
+#define SIRF_PWM_GET_HOLD_OFFSET(n) (0x14 + 0x8*n)
+
+#define SIRF_PWM_TR_STEP(n) (0x48 + 0x8*n)
+#define SIRF_PWM_STEP_HOLD(n) (0x4c + 0x8*n)
+
+#define SRC_FIELD_SIZE 3
+#define BYPASS_MODE_BIT 21
+#define TRANS_MODE_SELECT_BIT 7
+
+#define SIRF_PWM_CHL_NUM 7
+#define SIRF_PWM_BLS_GRP_NUM 16
+
+struct sirf_pwm {
+ void __iomem *base;
+ struct clk *clk;
+ struct pwm_chip chip;
+};
+
+#define to_sirf_chip(chip) container_of(chip, struct sirf_pwm, chip)
+
+static unsigned int sirf_pwm_ns_to_cycles(struct pwm_chip *chip, unsigned int time_ns)
+{
+ u64 dividend;
+ unsigned int cycle;
+ /*
+ * on SiRFSoC, OSC input is const, we use it as the source to generate
+ * PWM wave
+ */
+#define SRC_OSC_RATE 26000000ULL
+ dividend = SRC_OSC_RATE * time_ns + NSEC_PER_SEC / 2;
+ do_div(dividend, NSEC_PER_SEC);
+
+ cycle = dividend & 0xFFFFFFFFUL;
+
+ return cycle > 1 ? cycle : 1;
+}
+
+static int sirf_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
+ int duty_ns, int period_ns)
+{
+ unsigned int period_cycles, high_cycles, low_cycles;
+ unsigned int val;
+ struct sirf_pwm *spwm = to_sirf_chip(chip);
+
+ period_cycles = sirf_pwm_ns_to_cycles(chip, period_ns);
+
+ high_cycles = sirf_pwm_ns_to_cycles(chip, duty_ns);
+ low_cycles = period_cycles - high_cycles;
+
+ if (period_cycles == 1) {
+ /* bypass mode */
+ val = readl(spwm->base + SIRF_PWM_SELECT_PRECLK);
+ val |= 0x1 << (BYPASS_MODE_BIT + pwm->hwpwm);
+ writel(val, spwm->base + SIRF_PWM_SELECT_PRECLK);
+ dev_warn(chip->dev, "period is too short!\n");
+ } else {
+ /* divider mode */
+ val = readl(spwm->base + SIRF_PWM_SELECT_PRECLK);
+ val &= ~(0x1 << (BYPASS_MODE_BIT + pwm->hwpwm));
+ writel(val, spwm->base + SIRF_PWM_SELECT_PRECLK);
+
+ if (high_cycles == period_cycles) {
+ high_cycles--;
+ low_cycles = 1;
+ }
+
+ writel(high_cycles, spwm->base + SIRF_PWM_GET_WAIT_OFFSET(pwm->hwpwm));
+ writel(low_cycles, spwm->base + SIRF_PWM_GET_HOLD_OFFSET(pwm->hwpwm));
+ }
+
+ return 0;
+}
+
+static int sirf_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ struct sirf_pwm *spwm = to_sirf_chip(chip);
+ unsigned int val;
+
+ /* disable preclock */
+ val = readl(spwm->base + SIRF_PWM_ENABLE_PRECLOCK);
+ val &= ~(1 << pwm->hwpwm);
+ writel(val, spwm->base + SIRF_PWM_ENABLE_PRECLOCK);
+
+ /* select preclock source must after disable preclk*/
+ val = readl(spwm->base + SIRF_PWM_SELECT_PRECLK);
+ val &= ~(0x7 << (SRC_FIELD_SIZE * pwm->hwpwm));
+ writel(val, spwm->base + SIRF_PWM_SELECT_PRECLK);
+ /* wait for some time */
+ udelay(100);
+
+ /* enable preclock */
+ val = readl(spwm->base + SIRF_PWM_ENABLE_PRECLOCK);
+ val |= (1 << pwm->hwpwm);
+ writel(val, spwm->base + SIRF_PWM_ENABLE_PRECLOCK);
+
+ /* enable post clock*/
+ val = readl(spwm->base + SIRF_PWM_ENABLE_POSTCLOCK);
+ val |= (1 << pwm->hwpwm);
+ writel(val, spwm->base + SIRF_PWM_ENABLE_POSTCLOCK);
+
+ /* enable output */
+ val = readl(spwm->base + SIRF_PWM_OE);
+ val |= 1 << pwm->hwpwm;
+ val &= ~(1 << (pwm->hwpwm + TRANS_MODE_SELECT_BIT));
+
+ writel(val, spwm->base + SIRF_PWM_OE);
+
+ return 0;
+}
+
+static void sirf_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
+{
+ unsigned int val;
+ struct sirf_pwm *spwm = to_sirf_chip(chip);
+ /* disable output */
+ val = readl(spwm->base + SIRF_PWM_OE);
+ val &= ~(1 << pwm->hwpwm);
+ writel(val, spwm->base + SIRF_PWM_OE);
+
+ /* disable postclock */
+ val = readl(spwm->base + SIRF_PWM_ENABLE_POSTCLOCK);
+ val &= ~(1 << pwm->hwpwm);
+ writel(val, spwm->base + SIRF_PWM_ENABLE_POSTCLOCK);
+
+ /* disable preclock */
+ val = readl(spwm->base + SIRF_PWM_ENABLE_PRECLOCK);
+ val &= ~(1 << pwm->hwpwm);
+ writel(val, spwm->base + SIRF_PWM_ENABLE_PRECLOCK);
+}
+
+static struct pwm_ops sirf_pwm_ops = {
+ .enable = sirf_pwm_enable,
+ .disable = sirf_pwm_disable,
+ .config = sirf_pwm_config,
+ .owner = THIS_MODULE,
+};
+
+static int sirf_pwm_probe(struct platform_device *pdev)
+{
+ struct sirf_pwm *spwm;
+ struct resource *mem_res;
+ int ret;
+
+ spwm = devm_kzalloc(&pdev->dev, sizeof(struct sirf_pwm),
+ GFP_KERNEL);
+ if (!spwm)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, spwm);
+
+ mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ spwm->base = devm_ioremap_resource(&pdev->dev, mem_res);
+ if (!spwm->base)
+ return -ENOMEM;
+
+ spwm->clk = devm_clk_get(&pdev->dev, NULL);
+ if (IS_ERR(spwm->clk)) {
+ dev_err(&pdev->dev, "Get clock failed.\n");
+ return PTR_ERR(spwm->clk);
+ }
+
+ clk_prepare_enable(spwm->clk);
+
+ spwm->chip.dev = &pdev->dev;
+ spwm->chip.ops = &sirf_pwm_ops;
+ spwm->chip.base = 0;
+ spwm->chip.npwm = SIRF_PWM_CHL_NUM;
+
+ ret = pwmchip_add(&spwm->chip);
+ if (ret < 0) {
+ dev_err(&pdev->dev, "failed to register pwm\n");
+ clk_disable_unprepare(spwm->clk);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int sirf_pwm_remove(struct platform_device *pdev)
+{
+ struct sirf_pwm *spwm = platform_get_drvdata(pdev);
+ clk_disable_unprepare(spwm->clk);
+
+ pwmchip_remove(&spwm->chip);
+ return 0;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int sirf_pwm_suspend(struct device *dev)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct sirf_pwm *spwm = platform_get_drvdata(pdev);
+
+ clk_disable_unprepare(spwm->clk);
+
+ return 0;
+}
+
+static void sirf_pwm_config_restore(struct sirf_pwm *spwm)
+{
+ struct pwm_device *pwm;
+ int i;
+
+ for (i = 0; i < spwm->chip.npwm; i++) {
+ pwm = &spwm->chip.pwms[i];
+ /*
+ * while restoring from hibernation, state of pwm is enabled,
+ * but PWM hardware is not re-enabled
+ */
+ if (test_bit(PWMF_REQUESTED, &pwm->flags) &&
+ test_bit(PWMF_ENABLED, &pwm->flags))
+ sirf_pwm_enable(&spwm->chip, pwm);
+ }
+}
+
+static int sirf_pwm_resume(struct device *dev)
+{
+ struct sirf_pwm *spwm = dev_get_drvdata(dev);
+
+ clk_prepare_enable(spwm->clk);
+
+ sirf_pwm_config_restore(spwm);
+
+ return 0;
+}
+
+static int sirf_pwm_restore(struct device *dev)
+{
+ struct sirf_pwm *spwm = dev_get_drvdata(dev);
+
+ /* back from hibernation, clock is already enabled */
+ sirf_pwm_config_restore(spwm);
+
+ return 0;
+}
+
+#else
+#define sirf_pwm_resume NULL
+#define sirf_pwm_suspend NULL
+#define sirf_pwm_restore NULL
+#endif
+
+static const struct dev_pm_ops sirf_pwm_pm_ops = {
+ .suspend = sirf_pwm_suspend,
+ .resume = sirf_pwm_resume,
+ .restore = sirf_pwm_restore,
+};
+
+static const struct of_device_id sirf_pwm_of_match[] = {
+ { .compatible = "sirf,prima2-pwm", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, sirf_pwm_of_match);
+
+static struct platform_driver sirf_pwm_driver = {
+ .driver = {
+ .name = "prima2-pwm",
+ .owner = THIS_MODULE,
+ .pm = &sirf_pwm_pm_ops,
+ .of_match_table = sirf_pwm_of_match,
+ },
+ .probe = sirf_pwm_probe,
+ .remove = sirf_pwm_remove,
+};
+
+module_platform_driver(sirf_pwm_driver);
+
+MODULE_DESCRIPTION("SIRF serial SoC PWM device core driver");
+MODULE_AUTHOR("RongJun Ying <Rongjun.Ying@csr.com>, "
+ "Huayi Li <huayi.li@csr.com>");
+MODULE_LICENSE("GPL v2");
--
1.7.5.4
^ permalink raw reply related
* [PATCH v2 1/6] idle: move the cpuidle entry point to the generic idle loop
From: Preeti U Murthy @ 2014-01-30 5:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.11.1401300021530.1652@knanqh.ubzr>
Hi Nicolas,
On 01/30/2014 10:58 AM, Nicolas Pitre wrote:
> On Thu, 30 Jan 2014, Preeti U Murthy wrote:
>
>> Hi Nicolas,
>>
>> On 01/30/2014 02:01 AM, Nicolas Pitre wrote:
>>> On Wed, 29 Jan 2014, Nicolas Pitre wrote:
>>>
>>>> In order to integrate cpuidle with the scheduler, we must have a better
>>>> proximity in the core code with what cpuidle is doing and not delegate
>>>> such interaction to arch code.
>>>>
>>>> Architectures implementing arch_cpu_idle() should simply enter
>>>> a cheap idle mode in the absence of a proper cpuidle driver.
>>>>
>>>> Signed-off-by: Nicolas Pitre <nico@linaro.org>
>>>> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org>
>>>
>>> As mentioned in my reply to Olof's comment on patch #5/6, here's a new
>>> version of this patch adding the safety local_irq_enable() to the core
>>> code.
>>>
>>> ----- >8
>>>
>>> From: Nicolas Pitre <nicolas.pitre@linaro.org>
>>> Subject: idle: move the cpuidle entry point to the generic idle loop
>>>
>>> In order to integrate cpuidle with the scheduler, we must have a better
>>> proximity in the core code with what cpuidle is doing and not delegate
>>> such interaction to arch code.
>>>
>>> Architectures implementing arch_cpu_idle() should simply enter
>>> a cheap idle mode in the absence of a proper cpuidle driver.
>>>
>>> In both cases i.e. whether it is a cpuidle driver or the default
>>> arch_cpu_idle(), the calling convention expects IRQs to be disabled
>>> on entry and enabled on exit. There is a warning in place already but
>>> let's add a forced IRQ enable here as well. This will allow for
>>> removing the forced IRQ enable some implementations do locally and
>>
>> Why would this patch allow for removing the forced IRQ enable that are
>> being done on some archs in arch_cpu_idle()? Isn't this patch expecting
>> the default arch_cpu_idle() to have re-enabled the interrupts after
>> exiting from the default idle state? Its supposed to only catch faulty
>> cpuidle drivers that haven't enabled IRQs on exit from idle state but
>> are expected to have done so, isn't it?
>
> Exact. However x86 currently does this:
>
> if (cpuidle_idle_call())
> x86_idle();
> else
> local_irq_enable();
>
> So whenever cpuidle_idle_call() is successful then IRQs are
> unconditionally enabled whether or not the underlying cpuidle driver has
> properly done it or not. And the reason is that some of the x86 cpuidle
> do fail to enable IRQs before returning.
>
> So the idea is to get rid of this unconditional IRQ enabling and let the
> core issue a warning instead (as well as enabling IRQs to allow the
> system to run).
Oh ok, thank you for clarifying this:)
Regards
Preeti U Murthy
>
>
> Nicolas
>
^ permalink raw reply
* [PATCH v2 2/2] drivers/media: s5p-mfc: Add Horizontal and Vertical MV Search Range
From: Amit Grover @ 2014-01-30 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391060563-27015-1-git-send-email-amit.grover@samsung.com>
This patch adds Controls to set Horizontal and Vertical search range
for Motion Estimation block for Samsung MFC video Encoders.
Signed-off-by: Swami Nathan <swaminath.p@samsung.com>
Signed-off-by: Amit Grover <amit.grover@samsung.com>
---
drivers/media/platform/s5p-mfc/regs-mfc-v6.h | 1 +
drivers/media/platform/s5p-mfc/s5p_mfc_common.h | 2 ++
drivers/media/platform/s5p-mfc/s5p_mfc_enc.c | 24 +++++++++++++++++++++++
drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c | 8 ++------
4 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
index 2398cdf..8d0b686 100644
--- a/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
+++ b/drivers/media/platform/s5p-mfc/regs-mfc-v6.h
@@ -229,6 +229,7 @@
#define S5P_FIMV_E_PADDING_CTRL_V6 0xf7a4
#define S5P_FIMV_E_MV_HOR_RANGE_V6 0xf7ac
#define S5P_FIMV_E_MV_VER_RANGE_V6 0xf7b0
+#define S5P_FIMV_E_MV_RANGE_V6_MASK 0x3fff
#define S5P_FIMV_E_VBV_BUFFER_SIZE_V6 0xf84c
#define S5P_FIMV_E_VBV_INIT_DELAY_V6 0xf850
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
index 6920b54..b90ee34 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_common.h
@@ -430,6 +430,8 @@ struct s5p_mfc_vp8_enc_params {
struct s5p_mfc_enc_params {
u16 width;
u16 height;
+ u32 mv_h_range;
+ u32 mv_v_range;
u16 gop_size;
enum v4l2_mpeg_video_multi_slice_mode slice_mode;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
index 4ff3b6c..704f30c1 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
@@ -208,6 +208,24 @@ static struct mfc_control controls[] = {
.default_value = 0,
},
{
+ .id = V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "Horizontal MV Search Range",
+ .minimum = 16,
+ .maximum = 128,
+ .step = 16,
+ .default_value = 32,
+ },
+ {
+ .id = V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE,
+ .type = V4L2_CTRL_TYPE_INTEGER,
+ .name = "Vertical MV Search Range",
+ .minimum = 16,
+ .maximum = 128,
+ .step = 16,
+ .default_value = 32,
+ },
+ {
.id = V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE,
.type = V4L2_CTRL_TYPE_INTEGER,
.minimum = 0,
@@ -1377,6 +1395,12 @@ static int s5p_mfc_enc_s_ctrl(struct v4l2_ctrl *ctrl)
case V4L2_CID_MPEG_VIDEO_VBV_SIZE:
p->vbv_size = ctrl->val;
break;
+ case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
+ p->mv_h_range = ctrl->val;
+ break;
+ case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
+ p->mv_v_range = ctrl->val;
+ break;
case V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE:
p->codec.h264.cpb_size = ctrl->val;
break;
diff --git a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
index 461358c..3c10188 100644
--- a/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
+++ b/drivers/media/platform/s5p-mfc/s5p_mfc_opr_v6.c
@@ -727,14 +727,10 @@ static int s5p_mfc_set_enc_params(struct s5p_mfc_ctx *ctx)
WRITEL(reg, S5P_FIMV_E_RC_CONFIG_V6);
/* setting for MV range [16, 256] */
- reg = 0;
- reg &= ~(0x3FFF);
- reg = 256;
+ reg = (p->mv_h_range & S5P_FIMV_E_MV_RANGE_V6_MASK);
WRITEL(reg, S5P_FIMV_E_MV_HOR_RANGE_V6);
- reg = 0;
- reg &= ~(0x3FFF);
- reg = 256;
+ reg = (p->mv_v_range & S5P_FIMV_E_MV_RANGE_V6_MASK);
WRITEL(reg, S5P_FIMV_E_MV_VER_RANGE_V6);
WRITEL(0x0, S5P_FIMV_E_FRAME_INSERTION_V6);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 1/2] drivers/media: v4l2: Add settings for Horizontal and Vertical MV Search Range
From: Amit Grover @ 2014-01-30 5:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391060563-27015-1-git-send-email-amit.grover@samsung.com>
Adding V4L2 controls for horizontal and vertical search range in pixels
for motion estimation module in video encoder.
Signed-off-by: Swami Nathan <swaminath.p@samsung.com>
Signed-off-by: Amit Grover <amit.grover@samsung.com>
---
Documentation/DocBook/media/v4l/controls.xml | 20 ++++++++++++++++++++
drivers/media/v4l2-core/v4l2-ctrls.c | 14 ++++++++++++++
include/uapi/linux/v4l2-controls.h | 2 ++
3 files changed, 36 insertions(+)
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml
index 7a3b49b..be04d18 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2258,6 +2258,26 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry>
VBV buffer control.</entry>
</row>
+ <row><entry></entry></row>
+ <row id=""v4l2-mpeg-video-hor-search-range">
+ <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE</constant> </entry>
+ <entry>integer</entry>
+ </row>
+ <row><entry spanname="descr">Horizontal search range defines maximum horizontal search area in pixels
+to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
+horizontal search range for motion estimation module in video encoder.</entry>
+ </row>
+
+ <row><entry></entry></row>
+ <row id="v4l2-mpeg-video-vert-search-range">
+ <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE</constant> </entry>
+ <entry>integer</entry>
+ </row>
+ <row><entry spanname="descr">Vertical search range defines maximum vertical search area in pixels
+to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
+vertical search range for motion estimation module in video encoder.</entry>
+ </row>
+
<row><entry></entry></row>
<row>
<entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant> </entry>
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c b/drivers/media/v4l2-core/v4l2-ctrls.c
index fb46790..e775388 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -735,6 +735,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_MPEG_VIDEO_DEC_PTS: return "Video Decoder PTS";
case V4L2_CID_MPEG_VIDEO_DEC_FRAME: return "Video Decoder Frame Count";
case V4L2_CID_MPEG_VIDEO_VBV_DELAY: return "Initial Delay for VBV Control";
+ case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE: return "Horizontal MV Search Range";
+ case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE: return "Vertical MV Search Range";
case V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER: return "Repeat Sequence Header";
/* VPX controls */
@@ -905,6 +907,18 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum v4l2_ctrl_type *type,
*min = 0;
*max = *step = 1;
break;
+ case V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE:
+ *type = V4L2_CTRL_TYPE_INTEGER;
+ *min = 16;
+ *max = 128;
+ *step = 16;
+ break;
+ case V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE:
+ *type = V4L2_CTRL_TYPE_INTEGER;
+ *min = 16;
+ *max = 128;
+ *step = 16;
+ break;
case V4L2_CID_PAN_RESET:
case V4L2_CID_TILT_RESET:
case V4L2_CID_FLASH_STROBE:
diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h
index 1666aab..80e1def 100644
--- a/include/uapi/linux/v4l2-controls.h
+++ b/include/uapi/linux/v4l2-controls.h
@@ -372,6 +372,8 @@ enum v4l2_mpeg_video_multi_slice_mode {
#define V4L2_CID_MPEG_VIDEO_DEC_FRAME (V4L2_CID_MPEG_BASE+224)
#define V4L2_CID_MPEG_VIDEO_VBV_DELAY (V4L2_CID_MPEG_BASE+225)
#define V4L2_CID_MPEG_VIDEO_REPEAT_SEQ_HEADER (V4L2_CID_MPEG_BASE+226)
+#define V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE (V4L2_CID_MPEG_BASE+227)
+#define V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE (V4L2_CID_MPEG_BASE+228)
#define V4L2_CID_MPEG_VIDEO_H263_I_FRAME_QP (V4L2_CID_MPEG_BASE+300)
#define V4L2_CID_MPEG_VIDEO_H263_P_FRAME_QP (V4L2_CID_MPEG_BASE+301)
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox