* [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 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 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
* 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 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
* [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: 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: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 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 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
* 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
* [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
* [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
* [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 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 0/4] clk: mvebu: fix clk init order
From: Gregory CLEMENT @ 2014-01-30 10:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390673950-4521-1-git-send-email-sebastian.hesselbarth@gmail.com>
Hi Sebastian,
On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
> This patch set fixes clk init order that went upside-down with
> v3.14. I haven't really investigated what caused this, but I assume
> it is related with DT node reordering by addresses.
Can you explain what kind of issue do you observe?
I have just tested the master branch of Linus and (excepted for SATA
but Andrew will send a patch set soon), I didn't experiment any
issues on Armada 370 and Armada XP based boards.
Thanks,
Gregory
>
> Anyway, with v3.14 for MVEBU SoCs, the clock gating driver gets
> registered before core clocks driver. Unfortunately, we cannot
> return -EPROBE_DEFER in drivers initialized by clk_of_init. As the
> init order for our drivers is always core clocks before clock gating,
> we maintain init order ourselves by hooking CLK_OF_DECLARE to one
> init function that will register core clocks before clock gating
> driver.
>
> This patch is based on pre-v3.14-rc1 mainline and should go in as
> fixes for it. As we now send MVEBU clk pull-requests to Mike directly,
> I suggest Jason picks it up as a topic branch.
>
> The patches have been boot tested on Dove and compile-tested only
> for Kirkwood, Armada 370 and XP.
>
> Sebastian Hesselbarth (4):
> clk: mvebu: armada-370: maintain clock init order
> clk: mvebu: armada-xp: maintain clock init order
> clk: mvebu: dove: maintain clock init order
> clk: mvebu: kirkwood: maintain clock init order
>
> drivers/clk/mvebu/armada-370.c | 21 ++++++++++-----------
> drivers/clk/mvebu/armada-xp.c | 20 +++++++++-----------
> drivers/clk/mvebu/dove.c | 19 +++++++++----------
> drivers/clk/mvebu/kirkwood.c | 34 ++++++++++++++++------------------
> 4 files changed, 44 insertions(+), 50 deletions(-)
>
> ---
> Cc: Mike Turquette <mturquette@linaro.org>
> Cc: Jason Cooper <jason@lakedaemon.net>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Gregory Clement <gregory.clement@free-electrons.com>
> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> Cc: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Cc: linux-kernel at vger.kernel.org
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH 0/4] clk: mvebu: fix clk init order
From: Sebastian Hesselbarth @ 2014-01-30 10:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EA2875.5020807@free-electrons.com>
On 01/30/14 11:24, Gregory CLEMENT wrote:
> On 25/01/2014 19:19, Sebastian Hesselbarth wrote:
>> This patch set fixes clk init order that went upside-down with
>> v3.14. I haven't really investigated what caused this, but I assume
>> it is related with DT node reordering by addresses.
>
> Can you explain what kind of issue do you observe?
Sure. When probing CLK_OF_DECLAREed clock drivers, clock-gating driver
gets registered before core-clocks. It therefore cannot resolve it's
parent clock name for tclk and all clock gates will have no parent
clock.
Usually, you'll see in some drivers (e.g. v643xx_eth) div_by_zero errors
poping up, when they calculate a frequency division factors based on
clock gate frequency, which should have been tclk but is 0 now.
> I have just tested the master branch of Linus and (excepted for SATA
> but Andrew will send a patch set soon), I didn't experiment any
> issues on Armada 370 and Armada XP based boards.
^ permalink raw reply
* [PATCH v2 3/5] ASoC: tda998x: add DT documentation
From: Jean-Francois Moine @ 2014-01-30 10:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1391081933.git.moinejf@free.fr>
This patch adds the DT documentation of the NXP TDA998x CODEC.
Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
---
Documentation/devicetree/bindings/sound/tda998x.txt | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/tda998x.txt
diff --git a/Documentation/devicetree/bindings/sound/tda998x.txt b/Documentation/devicetree/bindings/sound/tda998x.txt
new file mode 100644
index 0000000..13b73ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tda998x.txt
@@ -0,0 +1,16 @@
+Device-Tree bindings for the NXP TDA998x HDMI transmitter
+
+Required properties:
+ - compatible: must be "nxp,tda998x-codec".
+ - audio-ports: one or two values corresponding to entries in
+ the audio-port-names property.
+ - audio-port-names: must contain "i2s", "spdif" entries
+ matching entries in the audio-ports property.
+
+Example node:
+
+ hdmi_codec: hdmi-codec {
+ compatible = "nxp,tda998x-codec";
+ audio-ports = <0x03>, <0x04>;
+ audio-port-names = "i2s", "spdif";
+ };
--
1.9.rc1
^ permalink raw reply related
* [PATCH v2 0/3] In-kernel PSCI v0.2 emulation for KVM ARM/ARM64
From: Anup Patel @ 2014-01-30 10:41 UTC (permalink / raw)
To: linux-arm-kernel
Currently, KVM ARM/ARM64 only provides in-kernel emulation of Power State
and Coordination Interface (PSCI) v0.1.
This patchset aims at providing newer PSCI v0.2 for KVM ARM/ARM64 VCPUs
such that it does not break current KVM ARM/ARM64 ABI. Also, the patchset
provides emulation of only few PSCI v0.2 functions such as PSCI_VERSION,
CPU_ON, and CPU_OFF. Emulation of other PSCI v0.2 functions will be added
later.
The user space tools (i.e. QEMU or KVMTOOL) will have to explicitly enable
KVM_ARM_VCPU_PSCI_0_2 feature using KVM_ARM_VCPU_INIT ioctl for providing
PSCI v0.2 to VCPUs.
Changlog:
V2:
- Don't rename PSCI return values KVM_PSCI_RET_NI and KVM_PSCI_RET_INVAL
- Added kvm_psci_version() to get PSCI version available to VCPU
- Fixed grammer in Documentation/virtual/kvm/api.txt
V1:
- Initial RFC PATCH
Anup Patel (3):
KVM: Add capability to advertise PSCI v0.2 support
ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
KVM: Documentation: Add info regarding KVM_ARM_VCPU_PSCI_0_2 feature
Documentation/virtual/kvm/api.txt | 2 +
arch/arm/include/asm/kvm_host.h | 2 +-
arch/arm/include/asm/kvm_psci.h | 4 ++
arch/arm/include/uapi/asm/kvm.h | 35 ++++++++++++++-
arch/arm/kvm/arm.c | 1 +
arch/arm/kvm/psci.c | 85 +++++++++++++++++++++++++++++++------
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/arm64/include/asm/kvm_psci.h | 4 ++
arch/arm64/include/uapi/asm/kvm.h | 35 ++++++++++++++-
include/uapi/linux/kvm.h | 1 +
10 files changed, 155 insertions(+), 16 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [PATCH v2 1/3] KVM: Add capability to advertise PSCI v0.2 support
From: Anup Patel @ 2014-01-30 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391078479-7406-1-git-send-email-anup.patel@linaro.org>
User space (i.e. QEMU or KVMTOOL) should be able to check whether KVM
ARM/ARM64 supports in-kernel PSCI v0.2 emulation. For this purpose, we
define KVM_CAP_ARM_PSCI_0_2 in KVM user space interface header.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
include/uapi/linux/kvm.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
index 902f124..d64349e 100644
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@ -674,6 +674,7 @@ struct kvm_ppc_smmu_info {
#define KVM_CAP_ARM_EL1_32BIT 93
#define KVM_CAP_SPAPR_MULTITCE 94
#define KVM_CAP_EXT_EMUL_CPUID 95
+#define KVM_CAP_ARM_PSCI_0_2 96
#ifdef KVM_CAP_IRQ_ROUTING
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 2/3] ARM/ARM64: KVM: Add support for PSCI v0.2 emulation
From: Anup Patel @ 2014-01-30 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391078479-7406-1-git-send-email-anup.patel@linaro.org>
Currently, the in-kernel PSCI emulation provides PSCI v0.1 interface to
VCPUs. This patch extends current in-kernel PSCI emulation to provide
PSCI v0.2 interface to VCPUs.
By default, ARM/ARM64 KVM will always provide PSCI v0.1 interface for
keeping the ABI backward-compatible.
To select PSCI v0.2 interface for VCPUs, the user space (i.e. QEMU or
KVMTOOL) will have to set KVM_ARM_VCPU_PSCI_0_2 feature when doing VCPU
init using KVM_ARM_VCPU_INIT ioctl.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
arch/arm/include/asm/kvm_host.h | 2 +-
arch/arm/include/asm/kvm_psci.h | 4 ++
arch/arm/include/uapi/asm/kvm.h | 35 ++++++++++++++-
arch/arm/kvm/arm.c | 1 +
arch/arm/kvm/psci.c | 85 +++++++++++++++++++++++++++++++------
arch/arm64/include/asm/kvm_host.h | 2 +-
arch/arm64/include/asm/kvm_psci.h | 4 ++
arch/arm64/include/uapi/asm/kvm.h | 35 ++++++++++++++-
8 files changed, 152 insertions(+), 16 deletions(-)
diff --git a/arch/arm/include/asm/kvm_host.h b/arch/arm/include/asm/kvm_host.h
index bce6d32..dc4e3ed 100644
--- a/arch/arm/include/asm/kvm_host.h
+++ b/arch/arm/include/asm/kvm_host.h
@@ -36,7 +36,7 @@
#define KVM_COALESCED_MMIO_PAGE_OFFSET 1
#define KVM_HAVE_ONE_REG
-#define KVM_VCPU_MAX_FEATURES 1
+#define KVM_VCPU_MAX_FEATURES 2
#include <kvm/arm_vgic.h>
diff --git a/arch/arm/include/asm/kvm_psci.h b/arch/arm/include/asm/kvm_psci.h
index 9a83d98..4c0e3e1 100644
--- a/arch/arm/include/asm/kvm_psci.h
+++ b/arch/arm/include/asm/kvm_psci.h
@@ -18,6 +18,10 @@
#ifndef __ARM_KVM_PSCI_H__
#define __ARM_KVM_PSCI_H__
+#define KVM_ARM_PSCI_0_1 1
+#define KVM_ARM_PSCI_0_2 2
+
+int kvm_psci_version(struct kvm_vcpu *vcpu);
bool kvm_psci_call(struct kvm_vcpu *vcpu);
#endif /* __ARM_KVM_PSCI_H__ */
diff --git a/arch/arm/include/uapi/asm/kvm.h b/arch/arm/include/uapi/asm/kvm.h
index c498b60..bf860e2 100644
--- a/arch/arm/include/uapi/asm/kvm.h
+++ b/arch/arm/include/uapi/asm/kvm.h
@@ -83,6 +83,7 @@ struct kvm_regs {
#define KVM_VGIC_V2_CPU_SIZE 0x2000
#define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
+#define KVM_ARM_VCPU_PSCI_0_2 1 /* CPU uses PSCI v0.2 */
struct kvm_vcpu_init {
__u32 target;
@@ -164,7 +165,7 @@ struct kvm_arch_memory_slot {
/* Highest supported SPI, from VGIC_NR_IRQS */
#define KVM_ARM_IRQ_GIC_MAX 127
-/* PSCI interface */
+/* PSCI v0.1 interface */
#define KVM_PSCI_FN_BASE 0x95c1ba5e
#define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
@@ -173,9 +174,41 @@ struct kvm_arch_memory_slot {
#define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
#define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
+/* PSCI v0.2 interface */
+#define KVM_PSCI_0_2_FN_BASE 0x84000000
+#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
+#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
+#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
+
+#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
+#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
+#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
+#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
+#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
+#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
+#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
+ KVM_PSCI_0_2_FN(6)
+#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
+ KVM_PSCI_0_2_FN(7)
+#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
+#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
+
+#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
+#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
+#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
+#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
+#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
+ KVM_PSCI_0_2_FN64(7)
+
+/* PSCI return values */
#define KVM_PSCI_RET_SUCCESS 0
#define KVM_PSCI_RET_NI ((unsigned long)-1)
#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
#define KVM_PSCI_RET_DENIED ((unsigned long)-3)
+#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
+#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
+#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
+#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
+#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
#endif /* __ARM_KVM_H__ */
diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
index 151eb91..e508125 100644
--- a/arch/arm/kvm/arm.c
+++ b/arch/arm/kvm/arm.c
@@ -193,6 +193,7 @@ int kvm_dev_ioctl_check_extension(long ext)
case KVM_CAP_DESTROY_MEMORY_REGION_WORKS:
case KVM_CAP_ONE_REG:
case KVM_CAP_ARM_PSCI:
+ case KVM_CAP_ARM_PSCI_0_2:
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
diff --git a/arch/arm/kvm/psci.c b/arch/arm/kvm/psci.c
index 448f60e..7fdc881 100644
--- a/arch/arm/kvm/psci.c
+++ b/arch/arm/kvm/psci.c
@@ -85,17 +85,57 @@ static unsigned long kvm_psci_vcpu_on(struct kvm_vcpu *source_vcpu)
return KVM_PSCI_RET_SUCCESS;
}
-/**
- * kvm_psci_call - handle PSCI call if r0 value is in range
- * @vcpu: Pointer to the VCPU struct
- *
- * Handle PSCI calls from guests through traps from HVC instructions.
- * The calling convention is similar to SMC calls to the secure world where
- * the function number is placed in r0 and this function returns true if the
- * function number specified in r0 is withing the PSCI range, and false
- * otherwise.
- */
-bool kvm_psci_call(struct kvm_vcpu *vcpu)
+int kvm_psci_version(struct kvm_vcpu *vcpu)
+{
+ if (test_bit(KVM_ARM_VCPU_PSCI_0_2, vcpu->arch.features))
+ return KVM_ARM_PSCI_0_2;
+
+ return KVM_ARM_PSCI_0_1;
+}
+
+static bool kvm_psci_0_2_call(struct kvm_vcpu *vcpu)
+{
+ unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
+ unsigned long val;
+
+ switch (psci_fn) {
+ case KVM_PSCI_0_2_FN_PSCI_VERSION:
+ /*
+ * Bits[31:16] = Major Version = 0
+ * Bits[15:0] = Minor Version = 2
+ */
+ val = 2;
+ break;
+ case KVM_PSCI_0_2_FN_CPU_OFF:
+ kvm_psci_vcpu_off(vcpu);
+ val = KVM_PSCI_RET_SUCCESS;
+ break;
+ case KVM_PSCI_0_2_FN_CPU_ON:
+ case KVM_PSCI_0_2_FN64_CPU_ON:
+ val = kvm_psci_vcpu_on(vcpu);
+ break;
+ case KVM_PSCI_0_2_FN_CPU_SUSPEND:
+ case KVM_PSCI_0_2_FN_AFFINITY_INFO:
+ case KVM_PSCI_0_2_FN_MIGRATE:
+ case KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE:
+ case KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU:
+ case KVM_PSCI_0_2_FN_SYSTEM_OFF:
+ case KVM_PSCI_0_2_FN_SYSTEM_RESET:
+ case KVM_PSCI_0_2_FN64_CPU_SUSPEND:
+ case KVM_PSCI_0_2_FN64_AFFINITY_INFO:
+ case KVM_PSCI_0_2_FN64_MIGRATE:
+ case KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU:
+ val = KVM_PSCI_RET_NI;
+ break;
+ default:
+ return false;
+ }
+
+ *vcpu_reg(vcpu, 0) = val;
+ return true;
+}
+
+static bool kvm_psci_0_1_call(struct kvm_vcpu *vcpu)
{
unsigned long psci_fn = *vcpu_reg(vcpu, 0) & ~((u32) 0);
unsigned long val;
@@ -112,7 +152,6 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
case KVM_PSCI_FN_MIGRATE:
val = KVM_PSCI_RET_NI;
break;
-
default:
return false;
}
@@ -120,3 +159,25 @@ bool kvm_psci_call(struct kvm_vcpu *vcpu)
*vcpu_reg(vcpu, 0) = val;
return true;
}
+
+/**
+ * kvm_psci_call - handle PSCI call if r0 value is in range
+ * @vcpu: Pointer to the VCPU struct
+ *
+ * Handle PSCI calls from guests through traps from HVC instructions.
+ * The calling convention is similar to SMC calls to the secure world where
+ * the function number is placed in r0 and this function returns true if the
+ * function number specified in r0 is withing the PSCI range, and false
+ * otherwise.
+ */
+bool kvm_psci_call(struct kvm_vcpu *vcpu)
+{
+ switch (kvm_psci_version(vcpu)) {
+ case KVM_ARM_PSCI_0_2:
+ return kvm_psci_0_2_call(vcpu);
+ case KVM_ARM_PSCI_0_1:
+ return kvm_psci_0_1_call(vcpu);
+ default:
+ return false;
+ };
+}
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 0a1d697..92242ce 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -39,7 +39,7 @@
#include <kvm/arm_vgic.h>
#include <kvm/arm_arch_timer.h>
-#define KVM_VCPU_MAX_FEATURES 2
+#define KVM_VCPU_MAX_FEATURES 3
struct kvm_vcpu;
int kvm_target_cpu(void);
diff --git a/arch/arm64/include/asm/kvm_psci.h b/arch/arm64/include/asm/kvm_psci.h
index e301a48..e25c658 100644
--- a/arch/arm64/include/asm/kvm_psci.h
+++ b/arch/arm64/include/asm/kvm_psci.h
@@ -18,6 +18,10 @@
#ifndef __ARM64_KVM_PSCI_H__
#define __ARM64_KVM_PSCI_H__
+#define KVM_ARM_PSCI_0_1 1
+#define KVM_ARM_PSCI_0_2 2
+
+int kvm_psci_version(struct kvm_vcpu *vcpu);
bool kvm_psci_call(struct kvm_vcpu *vcpu);
#endif /* __ARM64_KVM_PSCI_H__ */
diff --git a/arch/arm64/include/uapi/asm/kvm.h b/arch/arm64/include/uapi/asm/kvm.h
index d9f026b..b7555d3 100644
--- a/arch/arm64/include/uapi/asm/kvm.h
+++ b/arch/arm64/include/uapi/asm/kvm.h
@@ -77,6 +77,7 @@ struct kvm_regs {
#define KVM_ARM_VCPU_POWER_OFF 0 /* CPU is started in OFF state */
#define KVM_ARM_VCPU_EL1_32BIT 1 /* CPU running a 32bit VM */
+#define KVM_ARM_VCPU_PSCI_0_2 2 /* CPU uses PSCI v0.2 */
struct kvm_vcpu_init {
__u32 target;
@@ -150,7 +151,7 @@ struct kvm_arch_memory_slot {
/* Highest supported SPI, from VGIC_NR_IRQS */
#define KVM_ARM_IRQ_GIC_MAX 127
-/* PSCI interface */
+/* PSCI v0.1 interface */
#define KVM_PSCI_FN_BASE 0x95c1ba5e
#define KVM_PSCI_FN(n) (KVM_PSCI_FN_BASE + (n))
@@ -159,10 +160,42 @@ struct kvm_arch_memory_slot {
#define KVM_PSCI_FN_CPU_ON KVM_PSCI_FN(2)
#define KVM_PSCI_FN_MIGRATE KVM_PSCI_FN(3)
+/* PSCI v0.2 interface */
+#define KVM_PSCI_0_2_FN_BASE 0x84000000
+#define KVM_PSCI_0_2_FN(n) (KVM_PSCI_0_2_FN_BASE + (n))
+#define KVM_PSCI_0_2_FN64_BASE 0xC4000000
+#define KVM_PSCI_0_2_FN64(n) (KVM_PSCI_0_2_FN64_BASE + (n))
+
+#define KVM_PSCI_0_2_FN_PSCI_VERSION KVM_PSCI_0_2_FN(0)
+#define KVM_PSCI_0_2_FN_CPU_SUSPEND KVM_PSCI_0_2_FN(1)
+#define KVM_PSCI_0_2_FN_CPU_OFF KVM_PSCI_0_2_FN(2)
+#define KVM_PSCI_0_2_FN_CPU_ON KVM_PSCI_0_2_FN(3)
+#define KVM_PSCI_0_2_FN_AFFINITY_INFO KVM_PSCI_0_2_FN(4)
+#define KVM_PSCI_0_2_FN_MIGRATE KVM_PSCI_0_2_FN(5)
+#define KVM_PSCI_0_2_FN_MIGRATE_INFO_TYPE \
+ KVM_PSCI_0_2_FN(6)
+#define KVM_PSCI_0_2_FN_MIGRATE_INFO_UP_CPU \
+ KVM_PSCI_0_2_FN(7)
+#define KVM_PSCI_0_2_FN_SYSTEM_OFF KVM_PSCI_0_2_FN(8)
+#define KVM_PSCI_0_2_FN_SYSTEM_RESET KVM_PSCI_0_2_FN(9)
+
+#define KVM_PSCI_0_2_FN64_CPU_SUSPEND KVM_PSCI_0_2_FN64(1)
+#define KVM_PSCI_0_2_FN64_CPU_ON KVM_PSCI_0_2_FN64(3)
+#define KVM_PSCI_0_2_FN64_AFFINITY_INFO KVM_PSCI_0_2_FN64(4)
+#define KVM_PSCI_0_2_FN64_MIGRATE KVM_PSCI_0_2_FN64(5)
+#define KVM_PSCI_0_2_FN64_MIGRATE_INFO_UP_CPU \
+ KVM_PSCI_0_2_FN64(7)
+
+/* PSCI return values */
#define KVM_PSCI_RET_SUCCESS 0
#define KVM_PSCI_RET_NI ((unsigned long)-1)
#define KVM_PSCI_RET_INVAL ((unsigned long)-2)
#define KVM_PSCI_RET_DENIED ((unsigned long)-3)
+#define KVM_PSCI_RET_ALREADY_ON ((unsigned long)-4)
+#define KVM_PSCI_RET_ON_PENDING ((unsigned long)-5)
+#define KVM_PSCI_RET_INTERNAL_FAILURE ((unsigned long)-6)
+#define KVM_PSCI_RET_NOT_PRESENT ((unsigned long)-7)
+#define KVM_PSCI_RET_DISABLED ((unsigned long)-8)
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 3/3] KVM: Documentation: Add info regarding KVM_ARM_VCPU_PSCI_0_2 feature
From: Anup Patel @ 2014-01-30 10:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391078479-7406-1-git-send-email-anup.patel@linaro.org>
We have in-kernel emulation of PSCI v0.2 in KVM ARM/ARM64. To provide
PSCI v0.2 interface to VCPUs, we have to enable KVM_ARM_VCPU_PSCI_0_2
feature when doing KVM_ARM_VCPU_INIT ioctl.
The patch updates documentation of KVM_ARM_VCPU_INIT ioctl to provide
info regarding KVM_ARM_VCPU_PSCI_0_2 feature.
Signed-off-by: Anup Patel <anup.patel@linaro.org>
Signed-off-by: Pranavkumar Sawargaonkar <pranavkumar@linaro.org>
---
Documentation/virtual/kvm/api.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index aad3244..f842588 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -2346,6 +2346,8 @@ Possible features:
Depends on KVM_CAP_ARM_PSCI.
- KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
+ - KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU.
+ Depends on KVM_CAP_ARM_PSCI_0_2.
4.83 KVM_ARM_PREFERRED_TARGET
--
1.7.9.5
^ permalink raw reply related
* [PATCH V3 0/8] PCI:Add SPEAr13xx PCie support
From: Mohit Kumar @ 2014-01-30 10:48 UTC (permalink / raw)
To: linux-arm-kernel
First three patches are improvement and fixes for SPEAr13xx support.
Next patch modify phy-core driver for its initialization during
subsys_initcall(). Platform ahci driver is modified for phy hooks.
Patch#6 and 7 modify/add support for SPEAr13xx SATA and PCIe.
These patches are tested with SPEAr1310 evaluation board:
- INTEL PRO 100/100 EP card
- USB xhci gen2 card
- Above cards connected through LeCROY PTC switch
Modifications for SATA are tested with SPEAr1340-evb board
Changes since v2:
- Incorporated comments to move SPEAr13xx PCIe and SATA phy specific routines to
the phy framework
- Modify ahci driver to include phy hooks
- phy-core driver modifications for subsys_initcall()
Changes since v1:
- Few patches of the series are already accepted and applied to mainline e.g.
pcie designware driver improvements,fixes for IO translation bug, PCIe dw
driver maintainer. So dropped these from v2.
- Incorporated comment to move the common/reset PCIe code to the seperate driver
- PCIe and SATA share common PHY configuration registers, so move SATA
platform code to the system config driver
Fourth patch is improves pcie designware driver and fixes the IO
translation bug. IO translation bug fix leads to the working of PCIe EP devices
connected to RC through switch.
PCIe driver support for SPEAr1310/40 platform board is added.
These patches are tested with SPEAr1310 evaluation board:
- INTEL PRO 100/100 EP card
- USB xhci gen2 card
- Above cards connected through LeCROY PTC switch
Mohit Kumar (2):
SPEAr13xx: defconfig: Update
MAINTAINERS: Add ST SPEAr13xx PCIe driver maintainer
Pratyush Anand (6):
clk: SPEAr13xx: Fix pcie clock name
SPEAr13xx: Fix static mapping table
phy: Initialize phy core with subsys_initcall
ata: ahci platform: Add phy hooks to make it more generic
SPEAr13xx: Fixup: Move SPEAr1340 SATA platform code to phy driver
pcie: SPEAr13xx: Add designware pcie support
Cc: linux-arm-kernel at lists.infradead.org
Cc: devicetree at vger.kernel.org
Cc: linux-ide at vger.kernel.org
Cc: linux-pci at vger.kernel.org
Cc: spear-devel at list.st.com
Cc: Tejun Heo <tj@kernel.org>
.../devicetree/bindings/ata/ahci-platform.txt | 2 +
.../devicetree/bindings/pci/spear13xx-pcie.txt | 7 +
.../devicetree/bindings/phy/spear13xx-miphy.txt | 8 +
MAINTAINERS | 6 +
arch/arm/boot/dts/spear1310-evb.dts | 4 +
arch/arm/boot/dts/spear1310.dtsi | 87 ++++-
arch/arm/boot/dts/spear1340-evb.dts | 4 +
arch/arm/boot/dts/spear1340.dtsi | 29 ++-
arch/arm/boot/dts/spear13xx.dtsi | 10 +-
arch/arm/configs/spear13xx_defconfig | 16 +
arch/arm/mach-spear/Kconfig | 3 +
arch/arm/mach-spear/include/mach/spear.h | 4 +-
arch/arm/mach-spear/spear1340.c | 127 +-----
arch/arm/mach-spear/spear13xx.c | 2 +-
drivers/ata/ahci.h | 2 +
drivers/ata/ahci_platform.c | 20 +
drivers/clk/spear/spear1310_clock.c | 6 +-
drivers/clk/spear/spear1340_clock.c | 2 +-
drivers/pci/host/Kconfig | 5 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-spear13xx.c | 407 +++++++++++++++++
drivers/phy/Kconfig | 6 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-core.c | 2 +-
drivers/phy/phy-spear13xx-sata-pcie.c | 481 ++++++++++++++++++++
25 files changed, 1102 insertions(+), 140 deletions(-)
create mode 100644 Documentation/devicetree/bindings/pci/spear13xx-pcie.txt
create mode 100644 Documentation/devicetree/bindings/phy/spear13xx-miphy.txt
create mode 100644 drivers/pci/host/pcie-spear13xx.c
create mode 100644 drivers/phy/phy-spear13xx-sata-pcie.c
^ permalink raw reply
* [PATCH V3 1/8] clk: SPEAr13xx: Fix pcie clock name
From: Mohit Kumar @ 2014-01-30 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1391077731.git.mohit.kumar@st.com>
From: Pratyush Anand <pratyush.anand@st.com>
Follow dt clock naming convention for PCIe clocks.
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Mohit Kumar <mohit.kumar@st.com>
Cc: Viresh Kumar <viresh.linux@gmail.com>
Cc: spear-devel at list.st.com
Cc: linux-arm-kernel at lists.infradead.org
---
drivers/clk/spear/spear1310_clock.c | 6 +++---
drivers/clk/spear/spear1340_clock.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/spear/spear1310_clock.c b/drivers/clk/spear/spear1310_clock.c
index 65894f7..4daa597 100644
--- a/drivers/clk/spear/spear1310_clock.c
+++ b/drivers/clk/spear/spear1310_clock.c
@@ -742,19 +742,19 @@ void __init spear1310_clk_init(void __iomem *misc_base, void __iomem *ras_base)
clk = clk_register_gate(NULL, "pcie_sata_0_clk", "ahb_clk", 0,
SPEAR1310_PERIP1_CLK_ENB, SPEAR1310_PCIE_SATA_0_CLK_ENB,
0, &_lock);
- clk_register_clkdev(clk, NULL, "dw_pcie.0");
+ clk_register_clkdev(clk, NULL, "b1000000.pcie");
clk_register_clkdev(clk, NULL, "b1000000.ahci");
clk = clk_register_gate(NULL, "pcie_sata_1_clk", "ahb_clk", 0,
SPEAR1310_PERIP1_CLK_ENB, SPEAR1310_PCIE_SATA_1_CLK_ENB,
0, &_lock);
- clk_register_clkdev(clk, NULL, "dw_pcie.1");
+ clk_register_clkdev(clk, NULL, "b1800000.pcie");
clk_register_clkdev(clk, NULL, "b1800000.ahci");
clk = clk_register_gate(NULL, "pcie_sata_2_clk", "ahb_clk", 0,
SPEAR1310_PERIP1_CLK_ENB, SPEAR1310_PCIE_SATA_2_CLK_ENB,
0, &_lock);
- clk_register_clkdev(clk, NULL, "dw_pcie.2");
+ clk_register_clkdev(clk, NULL, "b4000000.pcie");
clk_register_clkdev(clk, NULL, "b4000000.ahci");
clk = clk_register_gate(NULL, "sysram0_clk", "ahb_clk", 0,
diff --git a/drivers/clk/spear/spear1340_clock.c b/drivers/clk/spear/spear1340_clock.c
index fe835c1..5a5c664 100644
--- a/drivers/clk/spear/spear1340_clock.c
+++ b/drivers/clk/spear/spear1340_clock.c
@@ -839,7 +839,7 @@ void __init spear1340_clk_init(void __iomem *misc_base)
clk = clk_register_gate(NULL, "pcie_sata_clk", "ahb_clk", 0,
SPEAR1340_PERIP1_CLK_ENB, SPEAR1340_PCIE_SATA_CLK_ENB,
0, &_lock);
- clk_register_clkdev(clk, NULL, "dw_pcie");
+ clk_register_clkdev(clk, NULL, "b1000000.pcie");
clk_register_clkdev(clk, NULL, "b1000000.ahci");
clk = clk_register_gate(NULL, "sysram0_clk", "ahb_clk", 0,
--
1.7.0.1
^ permalink raw reply related
* [PATCH V3 2/8] SPEAr13xx: Fix static mapping table
From: Mohit Kumar @ 2014-01-30 10:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1391077731.git.mohit.kumar@st.com>
From: Pratyush Anand <pratyush.anand@st.com>
SPEAr13xx was using virtual address space 0xFE000000 to map physical address
space 0xB3000000. pci_remap_io uses 0xFEE00000 as virtual address. So
change 0xFE000000 to 0xF9000000.
Signed-off-by: Pratyush Anand <pratyush.anand@st.com>
Signed-off-by: Mohit Kumar <mohit.kumar@st.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Cc: Viresh Kumar <viresh.linux@gmail.com>
Cc: spear-devel at list.st.com
Cc: stable at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org
---
arch/arm/mach-spear/include/mach/spear.h | 4 ++--
arch/arm/mach-spear/spear13xx.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-spear/include/mach/spear.h b/arch/arm/mach-spear/include/mach/spear.h
index 5cdc53d..f2d6a01 100644
--- a/arch/arm/mach-spear/include/mach/spear.h
+++ b/arch/arm/mach-spear/include/mach/spear.h
@@ -52,10 +52,10 @@
#ifdef CONFIG_ARCH_SPEAR13XX
#define PERIP_GRP2_BASE UL(0xB3000000)
-#define VA_PERIP_GRP2_BASE IOMEM(0xFE000000)
+#define VA_PERIP_GRP2_BASE IOMEM(0xF9000000)
#define MCIF_SDHCI_BASE UL(0xB3000000)
#define SYSRAM0_BASE UL(0xB3800000)
-#define VA_SYSRAM0_BASE IOMEM(0xFE800000)
+#define VA_SYSRAM0_BASE IOMEM(0xF9800000)
#define SYS_LOCATION (VA_SYSRAM0_BASE + 0x600)
#define PERIP_GRP1_BASE UL(0xE0000000)
diff --git a/arch/arm/mach-spear/spear13xx.c b/arch/arm/mach-spear/spear13xx.c
index 7aa6e8c..89212ff 100644
--- a/arch/arm/mach-spear/spear13xx.c
+++ b/arch/arm/mach-spear/spear13xx.c
@@ -52,7 +52,7 @@ void __init spear13xx_l2x0_init(void)
/*
* Following will create 16MB static virtual/physical mappings
* PHYSICAL VIRTUAL
- * 0xB3000000 0xFE000000
+ * 0xB3000000 0xF9000000
* 0xE0000000 0xFD000000
* 0xEC000000 0xFC000000
* 0xED000000 0xFB000000
--
1.7.0.1
^ 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