[PATCH v3 1/1] staging: ion: Prevent incorrect reference counting behavour
Supply additional checks in order to prevent unexpected results.
Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
Suggested-by: Dan Carpenter
Signed-off-by: Lee Jones
---
Destined for v4.4.y and v4.9.y
drivers/staging/android/ion/ion.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 806e9b30b9dc8..aac9b38b8c25c 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -489,6 +489,9 @@ static void *ion_buffer_kmap_get(struct ion_buffer *buffer)
void *vaddr;
if (buffer->kmap_cnt) {
+ if (buffer->kmap_cnt == INT_MAX)
+ return ERR_PTR(-EOVERFLOW);
+
buffer->kmap_cnt++;
return buffer->vaddr;
}
@@ -509,6 +512,9 @@ static void *ion_handle_kmap_get(struct ion_handle *handle)
void *vaddr;
if (handle->kmap_cnt) {
+ if (handle->kmap_cnt == INT_MAX)
+ return ERR_PTR(-EOVERFLOW);
+
handle->kmap_cnt++;
return buffer->vaddr;
}
--
2.34.0.rc2.393.gf8c9666880-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
On Fri, 26 Nov 2021, Greg KH wrote:
> On Fri, Nov 26, 2021 at 08:56:27AM +0000, Lee Jones wrote:
> > On Fri, 26 Nov 2021, Dan Carpenter wrote:
> >
> > > On Thu, Nov 25, 2021 at 06:18:22PM +0300, Dan Carpenter wrote:
> > > > I had thought that ->kmap_cnt was a regular int and not an unsigned
> > > > int, but I would have to pull a stable tree to see where I misread the
> > > > code.
> > >
> > > I was looking at (struct ion_buffer)->kmap_cnt but this is
> > > (struct ion_handle)->kmap_cnt. I'm not sure how those are related but
> > > it makes me nervous that one can go higher than the other. Also both
> > > probably need overflow protection.
> > >
> > > So I guess I would just do something like:
> > >
> > > diff --git a/drivers/staging/android/ion/ion.c
> > > b/drivers/staging/android/ion/ion.c
> > > index 806e9b30b9dc8..e8846279b33b5 100644
> > > --- a/drivers/staging/android/ion/ion.c
> > > +++ b/drivers/staging/android/ion/ion.c
> > > @@ -489,6 +489,8 @@ static void *ion_buffer_kmap_get(struct ion_buffer
> > > *buffer)
> > > void *vaddr;
> > >
> > > if (buffer->kmap_cnt) {
> > > + if (buffer->kmap_cnt == INT_MAX)
> > > + return ERR_PTR(-EOVERFLOW);
> > > buffer->kmap_cnt++;
> > > return buffer->vaddr;
> > > }
> > > @@ -509,6 +511,8 @@ static void *ion_handle_kmap_get(struct ion_handle
> > > *handle)
> > > void *vaddr;
> > >
> > > if (handle->kmap_cnt) {
> > > + if (handle->kmap_cnt == INT_MAX)
> > > + return ERR_PTR(-EOVERFLOW);
> > > handle->kmap_cnt++;
> > > return buffer->vaddr;
> > > }
> >
> > Which is all well and good until somebody changes the type.
>
> That's hard to do on code that is removed from the kernel tree :)
That's a difficult stance to take when reviewing a patch which changes
the very code you base your argument on. :D
I'll do with Dan's PoV though - no sympathy given. :)
v3 to follow.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
On Fri, 26 Nov 2021, Dan Carpenter wrote:
> On Thu, Nov 25, 2021 at 06:18:22PM +0300, Dan Carpenter wrote:
> > I had thought that ->kmap_cnt was a regular int and not an unsigned
> > int, but I would have to pull a stable tree to see where I misread the
> > code.
>
> I was looking at (struct ion_buffer)->kmap_cnt but this is
> (struct ion_handle)->kmap_cnt. I'm not sure how those are related but
> it makes me nervous that one can go higher than the other. Also both
> probably need overflow protection.
>
> So I guess I would just do something like:
>
> diff --git a/drivers/staging/android/ion/ion.c
> b/drivers/staging/android/ion/ion.c
> index 806e9b30b9dc8..e8846279b33b5 100644
> --- a/drivers/staging/android/ion/ion.c
> +++ b/drivers/staging/android/ion/ion.c
> @@ -489,6 +489,8 @@ static void *ion_buffer_kmap_get(struct ion_buffer
> *buffer)
> void *vaddr;
>
> if (buffer->kmap_cnt) {
> + if (buffer->kmap_cnt == INT_MAX)
> + return ERR_PTR(-EOVERFLOW);
> buffer->kmap_cnt++;
> return buffer->vaddr;
> }
> @@ -509,6 +511,8 @@ static void *ion_handle_kmap_get(struct ion_handle
> *handle)
> void *vaddr;
>
> if (handle->kmap_cnt) {
> + if (handle->kmap_cnt == INT_MAX)
> + return ERR_PTR(-EOVERFLOW);
> handle->kmap_cnt++;
> return buffer->vaddr;
> }
Which is all well and good until somebody changes the type.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
On Thu, 25 Nov 2021, Dan Carpenter wrote:
> On Thu, Nov 25, 2021 at 03:07:37PM +0000, Lee Jones wrote:
> > On Thu, 25 Nov 2021, Dan Carpenter wrote:
> >
> > > On Thu, Nov 25, 2021 at 02:20:04PM +, Lee Jones wrote:
> > > > Supply additional checks in order to prevent unexpected results.
> > > >
> > > > Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
> > > > Signed-off-by: Lee Jones
> > > > ---
> > > > Should be back-ported from v4.9 and earlier.
> > > >
> > > > drivers/staging/android/ion/ion.c | 5 +
> > > > 1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/staging/android/ion/ion.c
> > > > b/drivers/staging/android/ion/ion.c
> > > > index 806e9b30b9dc8..402b74f5d7e69 100644
> > > > --- a/drivers/staging/android/ion/ion.c
> > > > +++ b/drivers/staging/android/ion/ion.c
> > > > @@ -29,6 +29,7 @@
> > > > #include
> > > > #include
> > > > #include
> > > > +#include
> > > > #include
> > > > #include
> > > > #include
> > > > @@ -509,6 +510,10 @@ static void *ion_handle_kmap_get(struct ion_handle
> > > > *handle)
> > > > void *vaddr;
> > > >
> > > > if (handle->kmap_cnt) {
> > > > + if (check_add_overflow(handle->kmap_cnt,
> > > > + (unsigned int) 1,
> > > > >kmap_cnt))
> > > ^
> > >
> > > > + return ERR_PTR(-EOVERFLOW);
> > > > +
> > > > handle->kmap_cnt++;
> > > ^^^
> > > This will not do what you want at all. It's a double increment on the
> > > success path and it leave handle->kmap_cnt overflowed on failure path.
> >
> > I read the helper to take copies of the original variables.
> >
> > #define __unsigned_add_overflow(a, b, d) ({ \
> > typeof(a) __a = (a);\
> > typeof(b) __b = (b);\
> > typeof(d) __d = (d);\
> > (void) (&__a == &__b); \
> > (void) (&__a == __d); \
> > *__d = __a + __b; \
>
> This assignment sets handle->kmap_cnt to the overflowed value.
>
> > *__d < __a; \
> > })
> >
> > Maybe I misread it.
> >
> > So the original patch [0] was better?
> >
> > [0]
> > https://lore.kernel.org/stable/20211125120234.67987-1-lee.jo...@linaro.org/
>
> The original at least worked. :P
>
> You're catching me right as I'm knocking off for the day so I'm not
> sure how to write this code. I had thought that ->kmap_cnt was a
> regular int and not an unsigned int, but I would have to pull a stable
> tree to see where I misread the code.
>
> I'll look at this tomorrow Nairobi time, but I expect by then you'll
> already have it all figured out.
There's no rush. This has been broken for a long time.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
On Thu, 25 Nov 2021, Lee Jones wrote:
> On Thu, 25 Nov 2021, Dan Carpenter wrote:
>
> > On Thu, Nov 25, 2021 at 02:20:04PM +0000, Lee Jones wrote:
> > > Supply additional checks in order to prevent unexpected results.
> > >
> > > Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
> > > Signed-off-by: Lee Jones
> > > ---
> > > Should be back-ported from v4.9 and earlier.
> > >
> > > drivers/staging/android/ion/ion.c | 5 +
> > > 1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/staging/android/ion/ion.c
> > > b/drivers/staging/android/ion/ion.c
> > > index 806e9b30b9dc8..402b74f5d7e69 100644
> > > --- a/drivers/staging/android/ion/ion.c
> > > +++ b/drivers/staging/android/ion/ion.c
> > > @@ -29,6 +29,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > @@ -509,6 +510,10 @@ static void *ion_handle_kmap_get(struct ion_handle
> > > *handle)
> > > void *vaddr;
> > >
> > > if (handle->kmap_cnt) {
> > > + if (check_add_overflow(handle->kmap_cnt,
> > > +(unsigned int) 1, >kmap_cnt))
> > ^
> >
> > > + return ERR_PTR(-EOVERFLOW);
> > > +
> > > handle->kmap_cnt++;
> > ^^^
> > This will not do what you want at all. It's a double increment on the
> > success path and it leave handle->kmap_cnt overflowed on failure path.
>
> I read the helper to take copies of the original variables.
>
> #define __unsigned_add_overflow(a, b, d) ({ \
> typeof(a) __a = (a);\
> typeof(b) __b = (b);\
> typeof(d) __d = (d);\
> (void) (&__a == &__b); \
> (void) (&__a == __d); \
> *__d = __a + __b; \
> *__d < __a; \
> })
>
> Maybe I misread it.
I think I see now.
Copies are taken, but because 'd' is a pointer, dereferencing the copy
is just like dereferencing the original, thus the memory address
provided by 'd' is written to, updating the variable.
In this case, you're right, this is not what I was trying to achieve.
> So the original patch [0] was better?
>
> [0]
> https://lore.kernel.org/stable/20211125120234.67987-1-lee.jo...@linaro.org/
Greg, are you able to take the original patch for v4.4 and v4.9 please?
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
On Thu, 25 Nov 2021, Dan Carpenter wrote:
> On Thu, Nov 25, 2021 at 02:20:04PM +0000, Lee Jones wrote:
> > Supply additional checks in order to prevent unexpected results.
> >
> > Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
> > Signed-off-by: Lee Jones
> > ---
> > Should be back-ported from v4.9 and earlier.
> >
> > drivers/staging/android/ion/ion.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/staging/android/ion/ion.c
> > b/drivers/staging/android/ion/ion.c
> > index 806e9b30b9dc8..402b74f5d7e69 100644
> > --- a/drivers/staging/android/ion/ion.c
> > +++ b/drivers/staging/android/ion/ion.c
> > @@ -29,6 +29,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > @@ -509,6 +510,10 @@ static void *ion_handle_kmap_get(struct ion_handle
> > *handle)
> > void *vaddr;
> >
> > if (handle->kmap_cnt) {
> > + if (check_add_overflow(handle->kmap_cnt,
> > + (unsigned int) 1, >kmap_cnt))
> ^
>
> > + return ERR_PTR(-EOVERFLOW);
> > +
> > handle->kmap_cnt++;
> ^^^
> This will not do what you want at all. It's a double increment on the
> success path and it leave handle->kmap_cnt overflowed on failure path.
I read the helper to take copies of the original variables.
#define __unsigned_add_overflow(a, b, d) ({ \
typeof(a) __a = (a);\
typeof(b) __b = (b);\
typeof(d) __d = (d);\
(void) (&__a == &__b); \
(void) (&__a == __d); \
*__d = __a + __b; \
*__d < __a; \
})
Maybe I misread it.
So the original patch [0] was better?
[0] https://lore.kernel.org/stable/20211125120234.67987-1-lee.jo...@linaro.org/
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
Supply additional checks in order to prevent unexpected results.
Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
Signed-off-by: Lee Jones
---
Should be back-ported from v4.9 and earlier.
drivers/staging/android/ion/ion.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 806e9b30b9dc8..402b74f5d7e69 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -509,6 +510,10 @@ static void *ion_handle_kmap_get(struct ion_handle *handle)
void *vaddr;
if (handle->kmap_cnt) {
+ if (check_add_overflow(handle->kmap_cnt,
+ (unsigned int) 1, >kmap_cnt))
+ return ERR_PTR(-EOVERFLOW);
+
handle->kmap_cnt++;
return buffer->vaddr;
}
--
2.34.0.rc2.393.gf8c9666880-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
On Thu, 25 Nov 2021, Greg KH wrote:
> On Thu, Nov 25, 2021 at 01:03:46PM +0000, Lee Jones wrote:
> > On Thu, 25 Nov 2021, Greg KH wrote:
> >
> > > On Thu, Nov 25, 2021 at 12:46:23PM +, Lee Jones wrote:
> > > > On Thu, 25 Nov 2021, Greg KH wrote:
> > > >
> > > > > On Thu, Nov 25, 2021 at 12:02:34PM +, Lee Jones wrote:
> > > > > > Supply additional checks in order to prevent unexpected results.
> > > > > >
> > > > > > Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
> > > > > > Signed-off-by: Lee Jones
> > > > > > ---
> > > > > > drivers/staging/android/ion/ion.c | 3 +++
> > > > > > 1 file changed, 3 insertions(+)
> > > > > >
> > > > > > diff --git a/drivers/staging/android/ion/ion.c
> > > > > > b/drivers/staging/android/ion/ion.c
> > > > > > index 806e9b30b9dc8..30f359faba575 100644
> > > > > > --- a/drivers/staging/android/ion/ion.c
> > > > > > +++ b/drivers/staging/android/ion/ion.c
> > > > > > @@ -509,6 +509,9 @@ static void *ion_handle_kmap_get(struct
> > > > > > ion_handle *handle)
> > > > > > void *vaddr;
> > > > > >
> > > > > > if (handle->kmap_cnt) {
> > > > > > + if (handle->kmap_cnt + 1 < handle->kmap_cnt)
> > > > >
> > > > > What about using the nice helpers in overflow.h for this?
> > > >
> > > > I haven't heard of these before.
> > > >
> > > > Looks like they're not widely used.
> > > >
> > > > I'll try them out and see how they go.
> > > >
> > > > > > + return ERR_PTR(-EOVERFLOW);
> > > > > > +
> > > > > > handle->kmap_cnt++;
> > > > > > return buffer->vaddr;
> > > > > > }
> > > > >
> > > > > What stable kernel branch(es) is this for?
> > > >
> > > > I assumed your magic scripts could determine this from the Fixes:
> > > > tag. I'll be more explicit in v2.
> > >
> > > The fixes tag says how far back for it to go, but not where to start
> > > that process from :)
> >
> > What's your preferred method for identifying a start-point?
> >
> > In the [PATCH] tag or appended on to Cc: stable ... # ?
> >
> > I know both work, but what makes your life easier?
>
> Easiest is below the --- line say:
> ---
> This is for kernel versions X.X and older.
Understood, thanks.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
On Thu, 25 Nov 2021, Greg KH wrote:
> On Thu, Nov 25, 2021 at 12:46:23PM +0000, Lee Jones wrote:
> > On Thu, 25 Nov 2021, Greg KH wrote:
> >
> > > On Thu, Nov 25, 2021 at 12:02:34PM +, Lee Jones wrote:
> > > > Supply additional checks in order to prevent unexpected results.
> > > >
> > > > Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
> > > > Signed-off-by: Lee Jones
> > > > ---
> > > > drivers/staging/android/ion/ion.c | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/drivers/staging/android/ion/ion.c
> > > > b/drivers/staging/android/ion/ion.c
> > > > index 806e9b30b9dc8..30f359faba575 100644
> > > > --- a/drivers/staging/android/ion/ion.c
> > > > +++ b/drivers/staging/android/ion/ion.c
> > > > @@ -509,6 +509,9 @@ static void *ion_handle_kmap_get(struct ion_handle
> > > > *handle)
> > > > void *vaddr;
> > > >
> > > > if (handle->kmap_cnt) {
> > > > + if (handle->kmap_cnt + 1 < handle->kmap_cnt)
> > >
> > > What about using the nice helpers in overflow.h for this?
> >
> > I haven't heard of these before.
> >
> > Looks like they're not widely used.
> >
> > I'll try them out and see how they go.
> >
> > > > + return ERR_PTR(-EOVERFLOW);
> > > > +
> > > > handle->kmap_cnt++;
> > > > return buffer->vaddr;
> > > > }
> > >
> > > What stable kernel branch(es) is this for?
> >
> > I assumed your magic scripts could determine this from the Fixes:
> > tag. I'll be more explicit in v2.
>
> The fixes tag says how far back for it to go, but not where to start
> that process from :)
What's your preferred method for identifying a start-point?
In the [PATCH] tag or appended on to Cc: stable ... # ?
I know both work, but what makes your life easier?
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
On Thu, 25 Nov 2021, Greg KH wrote:
> On Thu, Nov 25, 2021 at 12:02:34PM +0000, Lee Jones wrote:
> > Supply additional checks in order to prevent unexpected results.
> >
> > Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
> > Signed-off-by: Lee Jones
> > ---
> > drivers/staging/android/ion/ion.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/staging/android/ion/ion.c
> > b/drivers/staging/android/ion/ion.c
> > index 806e9b30b9dc8..30f359faba575 100644
> > --- a/drivers/staging/android/ion/ion.c
> > +++ b/drivers/staging/android/ion/ion.c
> > @@ -509,6 +509,9 @@ static void *ion_handle_kmap_get(struct ion_handle
> > *handle)
> > void *vaddr;
> >
> > if (handle->kmap_cnt) {
> > + if (handle->kmap_cnt + 1 < handle->kmap_cnt)
>
> What about using the nice helpers in overflow.h for this?
I haven't heard of these before.
Looks like they're not widely used.
I'll try them out and see how they go.
> > + return ERR_PTR(-EOVERFLOW);
> > +
> > handle->kmap_cnt++;
> > return buffer->vaddr;
> > }
>
> What stable kernel branch(es) is this for?
I assumed your magic scripts could determine this from the Fixes:
tag. I'll be more explicit in v2.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/1] staging: ion: Prevent incorrect reference counting behavour
Supply additional checks in order to prevent unexpected results.
Fixes: b892bf75b2034 ("ion: Switch ion to use dma-buf")
Signed-off-by: Lee Jones
---
drivers/staging/android/ion/ion.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/android/ion/ion.c
b/drivers/staging/android/ion/ion.c
index 806e9b30b9dc8..30f359faba575 100644
--- a/drivers/staging/android/ion/ion.c
+++ b/drivers/staging/android/ion/ion.c
@@ -509,6 +509,9 @@ static void *ion_handle_kmap_get(struct ion_handle *handle)
void *vaddr;
if (handle->kmap_cnt) {
+ if (handle->kmap_cnt + 1 < handle->kmap_cnt)
+ return ERR_PTR(-EOVERFLOW);
+
handle->kmap_cnt++;
return buffer->vaddr;
}
--
2.34.0.rc2.393.gf8c9666880-goog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v7 01/13] dt-bindings: mfd: Add 'nxp,imx8mq-vpu-ctrl' to syscon list
On Mon, 29 Mar 2021, Benjamin Gaignard wrote: > Add 'nxp,imx8mq-vpu-ctrl' in the list of possible syscon. > It will used to access to the VPU control registers. > > Signed-off-by: Benjamin Gaignard > Acked-by: Rob Herring > --- > version 7: > - Add Rob ack > Documentation/devicetree/bindings/mfd/syscon.yaml | 1 + > 1 file changed, 1 insertion(+) Acked-by: Lee Jones -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 18/21] mfd: hi6421-spmi-pmic: move driver from staging
On Fri, 29 Jan 2021, Mauro Carvalho Chehab wrote:
> Hi Lee,
>
> Em Wed, 27 Jan 2021 11:05:37 +0000
> Lee Jones escreveu:
>
> > On Tue, 19 Jan 2021, Mauro Carvalho Chehab wrote:
> >
> > > This driver is ready for mainstream. So, move it out of staging.
> > >
>
> > Replied to an earlier submission where I was able to reply in-line.
>
> Sorry! Infradead seemed to have some problem between Jan 26-27: emails
> got late-delivered.
No problem.
> > > +static const struct mfd_cell hi6421v600_devs[] = {
> > > + { .name = "hi6421v600-regulator", },
> > > +};
> >
> > Where are the reset of the devices?
>
> Not sure what you mean here.
>
> This MFD device provides:
>
> - an IRQ handler;
> - several LDO lines used by a regulator driver.
>
> The IRQ handler is properly initialized here, while the
> regulators are initialized by the regulator driver. The initial
> state of this device is set up by u-boot.
>
> So, AFAIKT, there's no need to have any reset line
> attached here.
Oh wow! Sorry about that. It's a misspelling.
"Where are the *rest* of the devices?"
Registering one device does not qualify this as an MFD.
> Yet, I'm still figuring out how the PCIe chips at Hikey 970
> should be properly initialized. So, I may need to add something
> somewhere in order to properly reset and power up the Ethernet,
> M.2 and PCIe 1x slot.
>
> Those are linked to the LDO 33.
>
> > > +static void hi6421_spmi_irq_mask(struct irq_data *d)
> > > +{
> > > + struct hi6421_spmi_pmic *pmic = irq_data_get_irq_chip_data(d);
> > > + unsigned long flags;
> > > + unsigned int data;
> > > + u32 offset;
> > > +
> > > + offset = (irqd_to_hwirq(d) >> 3);
> >
> > Why 3?
>
> No idea. I don't have any datasheets from this device.
>
> > Probably better to define these shifts/masks rather than use
> > magic numbers with no comments.
>
> I'll change the above to:
>
> #define HISI_IRQ_MASK GENMASK(1, 0)
>
> offset = (irqd_to_hwirq(d) >> HISI_IRQ_MASK);
This is a shift surely? Marks are usually &'ed.
> > > + regmap_read(pmic->map, offset, );
> > > + data |= (1 << (irqd_to_hwirq(d) & 0x07));
> >
> > What are you doing here?
> >
> > Maybe improved defines will be enough. If not, please supply a
> > suitable comment.
>
> Again, no idea. The only documentation I had access to this chip is
> at:
>
> https://www.96boards.org/documentation/consumer/hikey/hikey970/
>
> With doesn't mention any register details.
>
> The driver itself came from the Linaro's 96boards git tree, with also
> doesn't contain any register mapping.
Well that's awkward.
I'm not keen on merging code that no one knows what it does.
Maybe I can do some digging.
> > > + pr_debug("PMU IRQ address value:irq[0x%x] = 0x%x\n",
> > > + SOC_PMIC_IRQ0_ADDR + i, pending);
> >
> > Again, is this actually useful to anyone now that the driver is nearly
> > 10 years old. Particularly anyone who can't add a quick printk()
> > during a debug session?
>
> With regards to the debug stuff, I'm dropping everything.
Great.
> On a side comment, I doubt that the driver has 10 years old ;-)
>
> See, Hikey 970 uses Kirin 970 SoC, which it was launched in Sept, 2017.
The header has a copyright from 2011.
// Copyright (c) 2013 Linaro Ltd.
// Copyright (c) 2011 Hisilicon.
> The original version of this driver publicly debuted on this tree:
>
>
> https://github.com/96boards-hikey/linux/blob/hikey970-v4.9/drivers/mfd/hisi_pmic_spmi.c
>
> On a commit made on Feb, 2018.
>
> Ok, Hi6421v600 is a separate silicon, probably derivative from
> Hi6421 (used on Hikey 960). Its copyright mentions 2011, but
> that's probably because the code itself came from older generations
> of the regulator chipset.
So we've inherited a copyright from another driver?
Sounds suspect.
> Please see the enclosed patch for the new code after fixing the issues
> you pointed. I'll re-submit it as a series once you're ok with the
> code.
Would you mind just resubmitting please? We can go from there.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v6 5/7] mfd: hi6421-spmi-pmic: move driver from staging
On Wed, 27 Jan 2021, Mauro Carvalho Chehab wrote:
> This driver is ready for mainstream. So, move it out of staging.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> .../mfd}/hisilicon,hi6421-spmi-pmic.yaml| 0
> MAINTAINERS | 7 +++
> drivers/mfd/Kconfig | 15 +++
> drivers/mfd/Makefile| 1 +
> .../hikey9xx => mfd}/hi6421-spmi-pmic.c | 0
> drivers/staging/hikey9xx/Kconfig| 17 -
> drivers/staging/hikey9xx/Makefile | 1 -
> 7 files changed, 23 insertions(+), 18 deletions(-)
> rename {drivers/staging/hikey9xx =>
> Documentation/devicetree/bindings/mfd}/hisilicon,hi6421-spmi-pmic.yaml (100%)
> rename drivers/{staging/hikey9xx => mfd}/hi6421-spmi-pmic.c (100%)
I've already reviewed this:
https://lore.kernel.org/driverdev-devel/20210127110537.GI4903@dell/
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 19/21] mfd: hi6421-spmi-pmic: move driver from staging
On Thu, 21 Jan 2021, Mauro Carvalho Chehab wrote:
> This driver is ready for mainstream. So, move it out of staging.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> .../mfd}/hisilicon,hi6421-spmi-pmic.yaml | 0
> MAINTAINERS | 7 +++
> drivers/mfd/Kconfig | 15 +++
> drivers/mfd/Makefile | 1 +
> .../{staging/hikey9xx => mfd}/hi6421-spmi-pmic.c | 0
> drivers/staging/hikey9xx/Kconfig | 16
> drivers/staging/hikey9xx/Makefile| 1 -
> 7 files changed, 23 insertions(+), 17 deletions(-)
> rename {drivers/staging/hikey9xx =>
> Documentation/devicetree/bindings/mfd}/hisilicon,hi6421-spmi-pmic.yaml (100%)
> rename drivers/{staging/hikey9xx => mfd}/hi6421-spmi-pmic.c (100%)
Replied to an earlier submission where I was able to reply in-line.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 18/21] mfd: hi6421-spmi-pmic: move driver from staging
one who can't add a quick printk()
during a debug session?
> + regmap_write(pmic->map, SOC_PMIC_IRQ0_ADDR + i,
> + HISI_MASK_STATE);
> + }
> +}
> +
> +static const struct regmap_config spmi_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 8,
> + .max_register = 0x,
> + .fast_io= true
> +};
> +
> +static int hi6421_spmi_pmic_probe(struct spmi_device *pdev)
> +{
> + struct device *dev = >dev;
> + struct device_node *np = dev->of_node;
> + struct hi6421_spmi_pmic *pmic;
> + struct regmap *map;
> + unsigned int virq;
> + int ret, i;
> +
> + pmic = devm_kzalloc(dev, sizeof(*pmic), GFP_KERNEL);
Nit: My personal preference for local driver data is 'ddata'.
> + if (!pmic)
> + return -ENOMEM;
> +
> + map = devm_regmap_init_spmi_ext(pdev, _regmap_config);
We talk about IRQ maps above. 'regmap' would be better here.
> + if (IS_ERR(map))
> + return PTR_ERR(map);
> +
> + spin_lock_init(>lock);
> +
> + pmic->dev = dev;
> + pmic->map = map;
> +
> + pmic->gpio = of_get_gpio(np, 0);
Why do you use local variable 'map' above and just assign the ddata
value directly here? I think the latter would be better throughout.
> + if (pmic->gpio < 0)
> + return pmic->gpio;
> +
> + if (!gpio_is_valid(pmic->gpio))
> + return -EINVAL;
> +
> + ret = devm_gpio_request_one(dev, pmic->gpio, GPIOF_IN, "pmic");
> + if (ret < 0) {
> + dev_err(dev, "failed to request gpio%d\n", pmic->gpio);
> + return ret;
> + }
> +
> + pmic->irq = gpio_to_irq(pmic->gpio);
> +
> + hi6421_spmi_pmic_irq_prc(pmic);
What does prc mean?
> + pmic->irqs = devm_kzalloc(dev, HISI_IRQ_NUM * sizeof(int), GFP_KERNEL);
> + if (!pmic->irqs)
> + goto irq_malloc;
malloc?
> + pmic->domain = irq_domain_add_simple(np, HISI_IRQ_NUM, 0,
> + _spmi_domain_ops, pmic);
> + if (!pmic->domain) {
> + dev_err(dev, "failed irq domain add simple!\n");
Too specific in my opinion. No need to mention the call.
"Failed to create IRQ domain" would be better IMHO.
> + ret = -ENODEV;
> + goto irq_malloc;
> + }
> +
> + for (i = 0; i < HISI_IRQ_NUM; i++) {
> + virq = irq_create_mapping(pmic->domain, i);
> + if (!virq) {
> + dev_err(dev, "Failed mapping hwirq\n");
"Failed to map H/W IRQ"
> + ret = -ENOSPC;
> + goto irq_malloc;
> + }
> + pmic->irqs[i] = virq;
> + dev_dbg(dev, "%s: pmic->irqs[%d] = %d\n",
> + __func__, i, pmic->irqs[i]);
This is ugly. Please remove it.
> + }
> +
> + ret = request_threaded_irq(pmic->irq, hi6421_spmi_irq_handler, NULL,
> +IRQF_TRIGGER_LOW | IRQF_SHARED |
> IRQF_NO_SUSPEND,
> +"pmic", pmic);
> + if (ret < 0) {
> + dev_err(dev, "could not claim pmic IRQ: error %d\n", ret);
This is inconsistent with other prints. Better to start with a
capital I think. Also, it should be "PMIC", as it's an abbreviation.
> + goto irq_malloc;
> + }
> +
> + dev_set_drvdata(>dev, pmic);
> +
> + /*
> + * The logic below will rely that the pmic is already stored at
> + * drvdata.
> + */
Which logic?
> + dev_dbg(>dev, "SPMI-PMIC: adding children for %pOF\n",
> + pdev->dev.of_node);
Please remove this.
> + ret = devm_mfd_add_devices(>dev, PLATFORM_DEVID_NONE,
> +hi6421v600_devs, ARRAY_SIZE(hi6421v600_devs),
> +NULL, 0, NULL);
> + if (!ret)
> + return 0;
> +
> + dev_err(dev, "Failed to add child devices: %d\n", ret);
> +
> +irq_malloc:
> + free_irq(pmic->irq, pmic);
Does gpio_to_irq() need freeing?
> + return ret;
> +}
> +
> +static void hi6421_spmi_pmic_remove(struct spmi_device *pdev)
> +{
> + struct hi6421_spmi_pmic *pmic = dev_get_drvdata(>dev);
> +
> + free_irq(pmic->irq, pmic);
> +}
> +
> +static const struct of_device_id pmic_spmi_id_table[] = {
> + { .compatible = "hisilicon,hi6421-spmi" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, pmic_spmi_id_table);
> +
> +static struct spmi_driver hi6421_spmi_pmic_driver = {
> + .driver = {
> + .name = "hi6421-spmi-pmic",
Odd spacing. Just use one ' ' please.
> + .of_match_table = pmic_spmi_id_table,
> + },
> + .probe = hi6421_spmi_pmic_probe,
> + .remove = hi6421_spmi_pmic_remove,
> +};
> +module_spmi_driver(hi6421_spmi_pmic_driver);
> +
> +MODULE_DESCRIPTION("HiSilicon Hi6421v600 SPMI PMIC driver");
> +MODULE_LICENSE("GPL v2");
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 00/21] Move Hisilicon 6421v600 SPMI driver set out of staging
On Wed, 27 Jan 2021, Greg Kroah-Hartman wrote: > On Tue, Jan 26, 2021 at 06:11:24PM +, Mark Brown wrote: > > On Tue, Jan 26, 2021 at 07:02:39PM +0100, Greg Kroah-Hartman wrote: > > > On Tue, Jan 26, 2021 at 05:57:52PM +, Mark Brown wrote: > > > > > > Is there a branch we can pull from? > > > > > Once 0-day passes, you can pull from my staging-testing branch from > > > staging.git on git.kernel.org if you want. Give it 24 hours to pass > > > before it hits that location. > > > > Thanks. > > Should be out there now if you want to pull. > > > > Do you need a tag to pull from? > > > > It'd be nice but not essential. > > Why do you want/need this? Having these changes in your tree is good, > but what about other coding style cleanups that I will end up applying > over time before the 5.12-rc1 merge window opens? Are you wanting to > take the moved driver in your tree, or something else? > > Traditionally moving drivers out of staging can be done 2 ways: > - all happens in the staging tree, I take an ack from the > subsystem maintainer that this is ok to do. > - A new driver enters the "real" subsystem tree, and then I > delete the driver in the staging tree. This doesn't preserve > history as well (not at all), but can be easier for trees that > move quickly (like networking.) > > Which ever works for you is fine with me, but relying on the code to > stay "not touched" in my tree after you pull it almost never happens due > to the number of drive-by coding style cleanups that end up in the > staging tree every week. I would have expected the whole set to be merged as a set into a single tree, placed on an immutable branch and a pull-request to be sent out for the other maintainers to pull from (if they so wished). This would ensure development could continue on any/all of the affected drivers/files. If it's not too late, I'd be more than happy to facilitate. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 10/13] mfd: hi6421-spmi-pmic: move driver from staging
On Mon, 18 Jan 2021, Mauro Carvalho Chehab wrote: > Em Mon, 18 Jan 2021 15:12:27 + > Lee Jones escreveu: > > > On Mon, 18 Jan 2021, Mauro Carvalho Chehab wrote: > > > > > This driver is ready for mainstream. So, move it out of staging. > > > > > > Signed-off-by: Mauro Carvalho Chehab > > > --- > > > .../mfd/hisilicon,hi6421-spmi-pmic.yaml | 133 +++ > > > MAINTAINERS | 7 + > > > drivers/mfd/Kconfig | 15 + > > > drivers/mfd/Makefile | 1 + > > > drivers/mfd/hi6421-spmi-pmic.c| 342 ++ > > > drivers/staging/hikey9xx/Kconfig | 16 - > > > drivers/staging/hikey9xx/Makefile | 1 - > > > drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 342 -- > > > .../hikey9xx/hisilicon,hi6421-spmi-pmic.yaml | 133 --- > > > 9 files changed, 498 insertions(+), 492 deletions(-) > > > > Could you please resubmit this will the correct flags. > > > > I believe it's the `git format-patch` -M flag that you want. > > As explained at patch 00/13, this was intentionally generated with > --no-merges, in order to allow reviewers to view the entire source > code at the patch. That's a fair point. Please leave it as it is for now then. I'll get around to the review soon I hope. > Anyway, I'll re-send the series with -M, as it makes easier to merge, > if everything is ok. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 10/13] mfd: hi6421-spmi-pmic: move driver from staging
On Mon, 18 Jan 2021, Mauro Carvalho Chehab wrote: > This driver is ready for mainstream. So, move it out of staging. > > Signed-off-by: Mauro Carvalho Chehab > --- > .../mfd/hisilicon,hi6421-spmi-pmic.yaml | 133 +++ > MAINTAINERS | 7 + > drivers/mfd/Kconfig | 15 + > drivers/mfd/Makefile | 1 + > drivers/mfd/hi6421-spmi-pmic.c| 342 ++ > drivers/staging/hikey9xx/Kconfig | 16 - > drivers/staging/hikey9xx/Makefile | 1 - > drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 342 -- > .../hikey9xx/hisilicon,hi6421-spmi-pmic.yaml | 133 --- > 9 files changed, 498 insertions(+), 492 deletions(-) Could you please resubmit this will the correct flags. I believe it's the `git format-patch` -M flag that you want. -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 5/6] staging: net: wimax: i2400m: tx: Fix a few kernel-doc misdemeanours
Fixes the following W=1 kernel build warning(s): drivers/net/wimax/i2400m/tx.c:715: warning: Function parameter or member 'i2400m' not described in 'i2400m_tx' drivers/net/wimax/i2400m/tx.c:964: warning: Function parameter or member 'i2400m' not described in 'i2400m_tx_setup' drivers/net/wimax/i2400m/tx.c:1005: warning: Function parameter or member 'i2400m' not described in 'i2400m_tx_release' Cc: Greg Kroah-Hartman Cc: Inaky Perez-Gonzalez Cc: linux-wi...@intel.com Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Yanir Lubetkin Cc: net...@vger.kernel.org Cc: de...@driverdev.osuosl.org Signed-off-by: Lee Jones --- drivers/staging/wimax/i2400m/tx.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/staging/wimax/i2400m/tx.c b/drivers/staging/wimax/i2400m/tx.c index 1255302e251e4..e9436212fe54d 100644 --- a/drivers/staging/wimax/i2400m/tx.c +++ b/drivers/staging/wimax/i2400m/tx.c @@ -681,6 +681,8 @@ void i2400m_tx_close(struct i2400m *i2400m) /** * i2400m_tx - send the data in a buffer to the device * + * @i2400m: device descriptor + * * @buf: pointer to the buffer to transmit * * @buf_len: buffer size @@ -955,6 +957,8 @@ EXPORT_SYMBOL_GPL(i2400m_tx_msg_sent); /** * i2400m_tx_setup - Initialize the TX queue and infrastructure * + * @i2400m: device descriptor + * * Make sure we reset the TX sequence to zero, as when this function * is called, the firmware has been just restarted. Same rational * for tx_in, tx_out, tx_msg_size and tx_msg. We reset them since @@ -998,7 +1002,7 @@ int i2400m_tx_setup(struct i2400m *i2400m) } -/** +/* * i2400m_tx_release - Tear down the TX queue and infrastructure */ void i2400m_tx_release(struct i2400m *i2400m) -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 3/6] staging: net: wimax: i2400m: fw: Fix some function header misdemeanours
Fixes the following W=1 kernel build warning(s): drivers/net/wimax/i2400m/fw.c:584: warning: Function parameter or member 'i2400m' not described in 'i2400m_bm_cmd' drivers/net/wimax/i2400m/fw.c:584: warning: Excess function parameter 'returns' description in 'i2400m_bm_cmd' drivers/net/wimax/i2400m/fw.c:646: warning: Function parameter or member 'chunk' not described in 'i2400m_download_chunk' drivers/net/wimax/i2400m/fw.c:646: warning: Function parameter or member '__chunk_len' not described in 'i2400m_download_chunk' drivers/net/wimax/i2400m/fw.c:646: warning: Excess function parameter 'buf' description in 'i2400m_download_chunk' drivers/net/wimax/i2400m/fw.c:646: warning: Excess function parameter 'buf_len' description in 'i2400m_download_chunk' drivers/net/wimax/i2400m/fw.c:1548: warning: Function parameter or member 'flags' not described in 'i2400m_dev_bootstrap' Cc: Greg Kroah-Hartman Cc: Inaky Perez-Gonzalez Cc: linux-wi...@intel.com Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Yanir Lubetkin Cc: net...@vger.kernel.org Cc: de...@driverdev.osuosl.org Signed-off-by: Lee Jones --- drivers/staging/wimax/i2400m/fw.c | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/drivers/staging/wimax/i2400m/fw.c b/drivers/staging/wimax/i2400m/fw.c index 6c9a41bff2e0a..9970857063374 100644 --- a/drivers/staging/wimax/i2400m/fw.c +++ b/drivers/staging/wimax/i2400m/fw.c @@ -534,6 +534,7 @@ ssize_t __i2400m_bm_ack_verify(struct i2400m *i2400m, int opcode, /** * i2400m_bm_cmd - Execute a boot mode command * + * @i2400m: device descriptor * @cmd: buffer containing the command data (pointing at the header). * This data can be ANYWHERE (for USB, we will copy it to an * specific buffer). Make sure everything is in proper little @@ -566,7 +567,7 @@ ssize_t __i2400m_bm_ack_verify(struct i2400m *i2400m, int opcode, * * @flags: see I2400M_BM_CMD_* above. * - * @returns: bytes received by the notification; if < 0, an errno code + * Returns: bytes received by the notification; if < 0, an errno code * denoting an error or: * * -ERESTARTSYS The device has rebooted @@ -634,8 +635,8 @@ ssize_t i2400m_bm_cmd(struct i2400m *i2400m, * i2400m_download_chunk - write a single chunk of data to the device's memory * * @i2400m: device descriptor - * @buf: the buffer to write - * @buf_len: length of the buffer to write + * @chunk: the buffer to write + * @chunk_len: length of the buffer to write * @addr: address in the device memory space * @direct: bootrom write mode * @do_csum: should a checksum validation be performed @@ -1533,6 +1534,13 @@ void i2400m_fw_put(struct i2400m_fw *i2400m_fw) * i2400m_dev_bootstrap - Bring the device to a known state and upload firmware * * @i2400m: device descriptor + * @flags: + * I2400M_BRI_SOFT: a reboot barker has been seen + * already, so don't wait for it. + * + * I2400M_BRI_NO_REBOOT: Don't send a reboot command, but wait + * for a reboot barker notification. This is a one shot; if + * the state machine needs to send a reboot command it will. * * Returns: >= 0 if ok, < 0 errno code on error. * -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 1/6] staging: net: wimax: i2400m: control: Fix some misspellings in i2400m_set_init_config()'s docs
Fixes the following W=1 kernel build warning(s): drivers/net/wimax/i2400m/control.c:1195: warning: Function parameter or member 'arg' not described in 'i2400m_set_init_config' drivers/net/wimax/i2400m/control.c:1195: warning: Excess function parameter 'arg_size' description in 'i2400m_set_init_config' Cc: Greg Kroah-Hartman Cc: Inaky Perez-Gonzalez Cc: linux-wi...@intel.com Cc: "David S. Miller" Cc: Jakub Kicinski Cc: net...@vger.kernel.org Cc: de...@driverdev.osuosl.org Signed-off-by: Lee Jones --- drivers/staging/wimax/i2400m/control.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/wimax/i2400m/control.c b/drivers/staging/wimax/i2400m/control.c index fe885aa56cf37..1e270b2101e86 100644 --- a/drivers/staging/wimax/i2400m/control.c +++ b/drivers/staging/wimax/i2400m/control.c @@ -1183,11 +1183,11 @@ static int i2400m_cmd_get_state(struct i2400m *i2400m) * Set basic configuration settings * * @i2400m: device descriptor - * @args: array of pointers to the TLV headers to send for + * @arg: array of pointers to the TLV headers to send for * configuration (each followed by its payload). * TLV headers and payloads must be properly initialized, with the * right endianess (LE). - * @arg_size: number of pointers in the @args array + * @args: number of pointers in the @arg array */ static int i2400m_set_init_config(struct i2400m *i2400m, const struct i2400m_tlv_hdr **arg, -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 4/6] staging: net: wimax: i2400m: netdev: Demote non-conformant function header
Fixes the following W=1 kernel build warning(s):
drivers/net/wimax/i2400m/netdev.c:583: warning: Function parameter or member
'net_dev' not described in 'i2400m_netdev_setup'
Cc: Greg Kroah-Hartman
Cc: Inaky Perez-Gonzalez
Cc: linux-wi...@intel.com
Cc: "David S. Miller"
Cc: Jakub Kicinski
Cc: Yanir Lubetkin
Cc: net...@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Signed-off-by: Lee Jones
---
drivers/staging/wimax/i2400m/netdev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wimax/i2400m/netdev.c
b/drivers/staging/wimax/i2400m/netdev.c
index a7fcbceb6e6be..8339d600e77b5 100644
--- a/drivers/staging/wimax/i2400m/netdev.c
+++ b/drivers/staging/wimax/i2400m/netdev.c
@@ -574,7 +574,7 @@ static const struct ethtool_ops i2400m_ethtool_ops = {
.get_link = ethtool_op_get_link,
};
-/**
+/*
* i2400m_netdev_setup - Setup setup @net_dev's i2400m private data
*
* Called by alloc_netdev()
--
2.25.1
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 6/6] staging: net: wimax: i2400m: fw: Fix incorrectly spelt function parameter in documentation
Fixes the following W=1 kernel build warning(s): drivers/net/wimax/i2400m/fw.c:647: warning: Function parameter or member '__chunk_len' not described in 'i2400m_download_chunk' drivers/net/wimax/i2400m/fw.c:647: warning: Excess function parameter 'chunk_len' description in 'i2400m_download_chunk' Cc: Greg Kroah-Hartman Cc: Inaky Perez-Gonzalez Cc: linux-wi...@intel.com Cc: "David S. Miller" Cc: Jakub Kicinski Cc: Yanir Lubetkin Cc: net...@vger.kernel.org Cc: de...@driverdev.osuosl.org Signed-off-by: Lee Jones --- drivers/staging/wimax/i2400m/fw.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/staging/wimax/i2400m/fw.c b/drivers/staging/wimax/i2400m/fw.c index 9970857063374..edb5eba0898b0 100644 --- a/drivers/staging/wimax/i2400m/fw.c +++ b/drivers/staging/wimax/i2400m/fw.c @@ -636,7 +636,7 @@ ssize_t i2400m_bm_cmd(struct i2400m *i2400m, * * @i2400m: device descriptor * @chunk: the buffer to write - * @chunk_len: length of the buffer to write + * @__chunk_len: length of the buffer to write * @addr: address in the device memory space * @direct: bootrom write mode * @do_csum: should a checksum validation be performed -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 2/6] staging: net: wimax: i2400m: driver: Demote some non-conformant kernel-docs, fix others
Fixes the following W=1 kernel build warning(s): drivers/net/wimax/i2400m/driver.c:681: warning: Function parameter or member 'i2400m' not described in 'i2400m_dev_reset_handle' drivers/net/wimax/i2400m/driver.c:681: warning: Function parameter or member 'reason' not described in 'i2400m_dev_reset_handle' drivers/net/wimax/i2400m/driver.c:775: warning: Function parameter or member 'i2400m' not described in 'i2400m_init' drivers/net/wimax/i2400m/driver.c:842: warning: Function parameter or member 'bm_flags' not described in 'i2400m_setup' drivers/net/wimax/i2400m/driver.c:942: warning: Function parameter or member 'i2400m' not described in 'i2400m_release' Cc: Greg Kroah-Hartman Cc: Inaky Perez-Gonzalez Cc: linux-wi...@intel.com Cc: "David S. Miller" Cc: Jakub Kicinski Cc: net...@vger.kernel.org Cc: de...@driverdev.osuosl.org Signed-off-by: Lee Jones --- drivers/staging/wimax/i2400m/driver.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/drivers/staging/wimax/i2400m/driver.c b/drivers/staging/wimax/i2400m/driver.c index dc8939ff78c0e..f5186458bb3d4 100644 --- a/drivers/staging/wimax/i2400m/driver.c +++ b/drivers/staging/wimax/i2400m/driver.c @@ -665,7 +665,7 @@ void __i2400m_dev_reset_handle(struct work_struct *ws) } -/** +/* * i2400m_dev_reset_handle - Handle a device's reset in a thread context * * Schedule a device reset handling out on a thread context, so it @@ -685,7 +685,7 @@ int i2400m_dev_reset_handle(struct i2400m *i2400m, const char *reason) EXPORT_SYMBOL_GPL(i2400m_dev_reset_handle); - /* +/* * The actual work of error recovery. * * The current implementation of error recovery is to trigger a bus reset. @@ -766,7 +766,7 @@ void i2400m_bm_buf_free(struct i2400m *i2400m) } -/** +/* * i2400m_init - Initialize a 'struct i2400m' from all zeroes * * This is a bus-generic API call. @@ -831,6 +831,7 @@ EXPORT_SYMBOL_GPL(i2400m_reset); * i2400m_setup - bus-generic setup function for the i2400m device * * @i2400m: device descriptor (bus-specific parts have been initialized) + * @bm_flags: boot mode flags * * Returns: 0 if ok, < 0 errno code on error. * @@ -933,7 +934,7 @@ int i2400m_setup(struct i2400m *i2400m, enum i2400m_bri bm_flags) EXPORT_SYMBOL_GPL(i2400m_setup); -/** +/* * i2400m_release - release the bus-generic driver resources * * Sends a disconnect message and undoes any setup done by i2400m_setup() -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH 0/6] Rid i2400m driver set of W=1 issues
This set is part of a larger effort attempting to clean-up W=1 kernel builds, which are currently overwhelmingly riddled with niggly little warnings. This is a rebased set that went to Net before the move to Staging. Lee Jones (6): staging: net: wimax: i2400m: control: Fix some misspellings in i2400m_set_init_config()'s docs staging: net: wimax: i2400m: driver: Demote some non-conformant kernel-docs, fix others staging: net: wimax: i2400m: fw: Fix some function header misdemeanours staging: net: wimax: i2400m: netdev: Demote non-conformant function header staging: net: wimax: i2400m: tx: Fix a few kernel-doc misdemeanours staging: net: wimax: i2400m: fw: Fix incorrectly spelt function parameter in documentation drivers/staging/wimax/i2400m/control.c | 4 ++-- drivers/staging/wimax/i2400m/driver.c | 9 + drivers/staging/wimax/i2400m/fw.c | 14 +++--- drivers/staging/wimax/i2400m/netdev.c | 2 +- drivers/staging/wimax/i2400m/tx.c | 6 +- 5 files changed, 24 insertions(+), 11 deletions(-) Cc: "David S. Miller" Cc: de...@driverdev.osuosl.org Cc: Greg Kroah-Hartman Cc: Inaky Perez-Gonzalez Cc: Jakub Kicinski Cc: linux-wi...@intel.com Cc: net...@vger.kernel.org Cc: Yanir Lubetkin -- 2.25.1 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 00/44] SPMI patches needed by Hikey 970
> staging: regulator: hi6421v600-regulator: cleanup debug messages > staging: regulator: hi6421v600-regulator: use shorter names for OF > properties > staging: regulator: hi6421v600-regulator: better handle modes > staging: regulator: hi6421v600-regulator: change namespace > staging: regulator: hi6421v600-regulator: convert to use get/set > voltage_sel > staging: regulator: hi6421v600-regulator: don't use usleep_range for > off_on_delay > staging: regulator: hi6421v600-regulator: add a driver-specific debug > macro > staging: regulator: hi6421v600-regulator: initialize ramp_delay > staging: regulator: hi6421v600-regulator: cleanup DT settings > staging: regulator: hi6421v600-regulator: fix some coding style issues > staging: regulator: hi6421v600-regulator: add it to the building > system > staging: regulator: hi6421v600-regulator: code cleanup > staging: hikey9xx: add a TODO list > MAINTAINERS: add an entry for HiSilicon 6421v600 drivers > dt: document HiSilicon SPMI controller and mfd/regulator properties > dt: hisilicon: add support for the PMIC found on Hikey 970 > > Mayulong (3): > staging: spmi: add Hikey 970 SPMI controller driver > staging: mfd: add a PMIC driver for HiSilicon 6421 SPMI version > staging: regulator: add a regulator driver for HiSilicon 6421v600 SPMI > PMIC > > .../mfd/hisilicon,hi6421-spmi-pmic.yaml | 182 +++ > .../spmi/hisilicon,hisi-spmi-controller.yaml | 54 ++ > MAINTAINERS | 6 + > .../boot/dts/hisilicon/hi3670-hikey970.dts| 16 +- > .../boot/dts/hisilicon/hikey970-pmic.dtsi | 200 > drivers/staging/Kconfig | 2 + > drivers/staging/Makefile | 1 + > drivers/staging/hikey9xx/Kconfig | 35 ++ > drivers/staging/hikey9xx/Makefile | 5 + > drivers/staging/hikey9xx/TODO | 5 + > drivers/staging/hikey9xx/hi6421-spmi-pmic.c | 381 ++ > .../staging/hikey9xx/hi6421v600-regulator.c | 479 ++ > .../staging/hikey9xx/hisi-spmi-controller.c | 351 + > include/linux/mfd/hi6421-spmi-pmic.h | 68 +++ > 14 files changed, 1773 insertions(+), 12 deletions(-) > create mode 100644 > Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml > create mode 100644 > Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml > create mode 100644 arch/arm64/boot/dts/hisilicon/hikey970-pmic.dtsi > create mode 100644 drivers/staging/hikey9xx/Kconfig > create mode 100644 drivers/staging/hikey9xx/Makefile > create mode 100644 drivers/staging/hikey9xx/TODO > create mode 100644 drivers/staging/hikey9xx/hi6421-spmi-pmic.c > create mode 100644 drivers/staging/hikey9xx/hi6421v600-regulator.c > create mode 100644 drivers/staging/hikey9xx/hisi-spmi-controller.c > create mode 100644 include/linux/mfd/hi6421-spmi-pmic.h > -- Lee Jones [李琼斯] Senior Technical Lead - Developer Services Linaro.org │ Open source software for Arm SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: staging: rtsx: Add support for RTS5260
On Mon, 16 Oct 2017, mario.limoncie...@dell.com wrote: > > -Original Message- > > From: Lee Jones [mailto:lee.jo...@linaro.org] > > Sent: Friday, October 13, 2017 4:15 PM > > To: Limonciello, Mario <mario_limoncie...@dell.com> > > Cc: rui_f...@realsil.com.cn; gre...@linuxfoundation.org; linux- > > ker...@vger.kernel.org; de...@driverdev.osuosl.org; ricky...@realtek.com; > > wei_w...@realsil.com.cn > > Subject: Re: staging: rtsx: Add support for RTS5260 > > > > On Fri, 13 Oct 2017, Mario Limonciello wrote: > > > On 10/13/2017 03:50 AM, rui_f...@realsil.com.cn wrote: > > > > From: rui_feng <rui_f...@realsil.com.cn> > > > > > > > > Add support for new chip rts5260. > > > > In order to support rts5260，the definitions of some internal > > > > registers and workflow have to be modified and are different from its > > > > predecessors and OCP function is added for RTS5260. > > > > So we need this patch to ensure RTS5260 can work. > > > > > > > > Signed-off-by: Rui Feng <rui_f...@realsil.com.cn> > > > > --- > > > > drivers/mfd/Makefile | 4 + > > > > drivers/mfd/rtsx_pcr.c| 127 ++- > > > > drivers/mfd/rtsx_pcr.h| 12 + > > > > drivers/staging/Kconfig | 2 + > > > > drivers/staging/rts5260/Kconfig | 6 + > > > > drivers/staging/rts5260/rts5260.c | 748 > > ++ > > > > drivers/staging/rts5260/rts5260.h | 45 +++ > > > > include/linux/mfd/rtsx_pci.h | 234 +++- > > > > 8 files changed, 1173 insertions(+), 5 deletions(-) > > > > create mode 100644 drivers/staging/rts5260/Kconfig > > > > create mode 100644 drivers/staging/rts5260/rts5260.c > > > > create mode 100644 drivers/staging/rts5260/rts5260.h > > > > [nearly 1000 lines snipped] > > > > Wow, that's a lot of scrolling to get to your reply! > > > > It would be helpful if you'd please snip your replies in the future. > > Yes, sorry about that. > > > > > > > There are a number of drivers in this family which currently reside in > > > > MFD. These were accepted before my time. After a recent review I've > > > > made the decision that these aren't MFD drivers at all. > > > > > > If all these other similar drivers don't belong in MFD, why are they > > > still there? Have they been moved in -next? > > > > No effort has been made to move them yet. We still don't have a > > suitable home for them. That's what we're discussing. > > I see that on a part of this thread I wasn't on CC that drivers/misc > was decided. > > > > > > As recently as last month I still see patches being accepted into > > > MFD regarding Realtek card readers. > > > > > > https://patchwork.kernel.org/patch/9941753/ > > > > Changes to existing drivers, yes. > > > > I only noticed what was going on when this new driver was submitted. > > > > I'm now not accepting new ones. > > > > > I miss how it's reasonable to expect the submitter who is adding support > > > for new HW that is similar to other hardware in the past to be able to > > > know where to put it if this change hasn't already happened. > > > > It's perfectly reasonable to reject a new driver which doesn't > > belong. > > > > > What's actually wrong with accepting it in MFD like the other drivers > > > similar to it and then moving them all at once when the right place > > > is figured out? > > > > Because it removes the incentive for someone to take the initiative and > > move them. I can't work with promises. Too many times I've heard "if > > you just accept this patch, I'll do XYZ as a subsequent piece of > > work", then move on. They are either never seen again, or we have the > > same conversation when they attempt to submit something else. Things > > don't get done that way. > > > > > Then its much clearer for future drivers similar to this one that they > > > live in the new place (misc, or wherever makes sense). > > > > I've I would have accepted the original patch into MFD, we would not > > be having this conversation, people like yourself and Greg would not > > be aware and (the chances are - just going by previous experience > > here) nothing would have changed/improved. > > > > > It seems like it would
Re: staging: rtsx: Add support for RTS5260
On Fri, 13 Oct 2017, Mario Limonciello wrote: > On 10/13/2017 03:50 AM, rui_f...@realsil.com.cn wrote: > > From: rui_feng <rui_f...@realsil.com.cn> > > > > Add support for new chip rts5260. > > In order to support rts5260，the definitions of some internal > > registers and workflow have to be modified and are different from its > > predecessors and OCP function is added for RTS5260. > > So we need this patch to ensure RTS5260 can work. > > > > Signed-off-by: Rui Feng <rui_f...@realsil.com.cn> > > --- > > drivers/mfd/Makefile | 4 + > > drivers/mfd/rtsx_pcr.c| 127 ++- > > drivers/mfd/rtsx_pcr.h| 12 + > > drivers/staging/Kconfig | 2 + > > drivers/staging/rts5260/Kconfig | 6 + > > drivers/staging/rts5260/rts5260.c | 748 > > ++ > > drivers/staging/rts5260/rts5260.h | 45 +++ > > include/linux/mfd/rtsx_pci.h | 234 +++- > > 8 files changed, 1173 insertions(+), 5 deletions(-) > > create mode 100644 drivers/staging/rts5260/Kconfig > > create mode 100644 drivers/staging/rts5260/rts5260.c > > create mode 100644 drivers/staging/rts5260/rts5260.h [nearly 1000 lines snipped] Wow, that's a lot of scrolling to get to your reply! It would be helpful if you'd please snip your replies in the future. > > There are a number of drivers in this family which currently reside in > > MFD. These were accepted before my time. After a recent review I've > > made the decision that these aren't MFD drivers at all. > > If all these other similar drivers don't belong in MFD, why are they > still there? Have they been moved in -next? No effort has been made to move them yet. We still don't have a suitable home for them. That's what we're discussing. > As recently as last month I still see patches being accepted into > MFD regarding Realtek card readers. > > https://patchwork.kernel.org/patch/9941753/ Changes to existing drivers, yes. I only noticed what was going on when this new driver was submitted. I'm now not accepting new ones. > I miss how it's reasonable to expect the submitter who is adding support > for new HW that is similar to other hardware in the past to be able to > know where to put it if this change hasn't already happened. It's perfectly reasonable to reject a new driver which doesn't belong. > What's actually wrong with accepting it in MFD like the other drivers > similar to it and then moving them all at once when the right place > is figured out? Because it removes the incentive for someone to take the initiative and move them. I can't work with promises. Too many times I've heard "if you just accept this patch, I'll do XYZ as a subsequent piece of work", then move on. They are either never seen again, or we have the same conversation when they attempt to submit something else. Things don't get done that way. > Then its much clearer for future drivers similar to this one that they > live in the new place (misc, or wherever makes sense). I've I would have accepted the original patch into MFD, we would not be having this conversation, people like yourself and Greg would not be aware and (the chances are - just going by previous experience here) nothing would have changed/improved. > It seems like it would be the same result but with less pain. That cannot be guaranteed. If people's words would have been their bond in the past, I would have more trust and the world would be a nicer place. :) > > Ok, how does it hook up to the hardware to talk to the reader? > > This particular case its PCIe. I don't know if their chip is > used in any other packages, but I wouldn't be surprised if so. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtsx: Add support for RTS5260
On Fri, 13 Oct 2017, Greg KH wrote: > On Fri, Oct 13, 2017 at 10:54:22AM +0100, Lee Jones wrote: > > On Fri, 13 Oct 2017, Greg KH wrote: > > > > > On Fri, Oct 13, 2017 at 04:50:35PM +0800, rui_f...@realsil.com.cn wrote: > > > > From: rui_feng <rui_f...@realsil.com.cn> > > > > > > > > Add support for new chip rts5260. > > > > In order to support rts5260，the definitions of some internal > > > > registers and workflow have to be modified and are different from its > > > > predecessors and OCP function is added for RTS5260. > > > > So we need this patch to ensure RTS5260 can work. > > > > > > > > Signed-off-by: Rui Feng <rui_f...@realsil.com.cn> > > > > > > Your from and signed-off-by name does not match :( > > > > > > > --- > > > > drivers/mfd/Makefile | 4 + > > > > drivers/mfd/rtsx_pcr.c| 127 ++- > > > > drivers/mfd/rtsx_pcr.h| 12 + > > > > drivers/staging/Kconfig | 2 + > > > > drivers/staging/rts5260/Kconfig | 6 + > > > > drivers/staging/rts5260/rts5260.c | 748 > > > > ++ > > > > drivers/staging/rts5260/rts5260.h | 45 +++ > > > > include/linux/mfd/rtsx_pci.h | 234 +++- > > > > > > I do not see a reason why this is a staging driver. Where is the TODO > > > file listing what needs to be done to get it out of staging? Why can it > > > not just go into the "real" part of the kernel? > > > > It's not a staging driver. Rui's focus appears to be to have this > > driver accepted into Mainline by hook or by crock. He's tried MFD, > > Misc and now Staging! > > Yeah, I've watched it too :) > > > Background: > > > > There are a number of drivers in this family which currently reside in > > MFD. These were accepted before my time. After a recent review I've > > made the decision that these aren't MFD drivers at all. > > > > MFD drivers are ones which aid in registering and setting up shared > > resources for sub-devices which reside on the same piece of silicon. > > This driver does basically none of that. Instead it *is* the (what we > > describe above as) sub-device. It does everything. > > I agree with your assessment. > > > In the absence of a subsystem which covers this type of device, I > > suggested Misk as a good location to place these drivers. Sorry, that should have been "Misc" > What type of device is this thing? I can't seem to figure that out. If > we can determine that, then we can find the proper place for it in the > kernel. It's a card (MMC, (u)SD, etc) reader. > Rui, what does this hardware do? What is the interface between the > hardware and userspace that this driver is creating? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: rtsx: Add support for RTS5260
On Fri, 13 Oct 2017, Greg KH wrote: > On Fri, Oct 13, 2017 at 04:50:35PM +0800, rui_f...@realsil.com.cn wrote: > > From: rui_feng <rui_f...@realsil.com.cn> > > > > Add support for new chip rts5260. > > In order to support rts5260，the definitions of some internal > > registers and workflow have to be modified and are different from its > > predecessors and OCP function is added for RTS5260. > > So we need this patch to ensure RTS5260 can work. > > > > Signed-off-by: Rui Feng <rui_f...@realsil.com.cn> > > Your from and signed-off-by name does not match :( > > > --- > > drivers/mfd/Makefile | 4 + > > drivers/mfd/rtsx_pcr.c| 127 ++- > > drivers/mfd/rtsx_pcr.h| 12 + > > drivers/staging/Kconfig | 2 + > > drivers/staging/rts5260/Kconfig | 6 + > > drivers/staging/rts5260/rts5260.c | 748 > > ++ > > drivers/staging/rts5260/rts5260.h | 45 +++ > > include/linux/mfd/rtsx_pci.h | 234 +++- > > I do not see a reason why this is a staging driver. Where is the TODO > file listing what needs to be done to get it out of staging? Why can it > not just go into the "real" part of the kernel? It's not a staging driver. Rui's focus appears to be to have this driver accepted into Mainline by hook or by crock. He's tried MFD, Misc and now Staging! Background: There are a number of drivers in this family which currently reside in MFD. These were accepted before my time. After a recent review I've made the decision that these aren't MFD drivers at all. MFD drivers are ones which aid in registering and setting up shared resources for sub-devices which reside on the same piece of silicon. This driver does basically none of that. Instead it *is* the (what we describe above as) sub-device. It does everything. In the absence of a subsystem which covers this type of device, I suggested Misk as a good location to place these drivers. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/3] [media] include/media: move platform_data to linux/platform_data/media
On Mon, 16 Nov 2015, Mauro Carvalho Chehab wrote:
> Let's not mix platform_data headers with the core headers. Instead, let's
> create a subdir at linux/platform_data and move the headers to that
> common place, adding it to MAINTAINERS.
>
> The headers were moved with:
> mkdir include/linux/platform_data/media/; git mv
> include/media/gpio-ir-recv.h include/media/ir-rx51.h
> include/media/mmp-camera.h include/media/omap1_camera.h
> include/media/omap4iss.h include/media/s5p_hdmi.h include/media/si4713.h
> include/media/sii9234.h include/media/smiapp.h include/media/soc_camera.h
> include/media/soc_camera_platform.h include/media/timb_radio.h
> include/media/timb_video.h include/linux/platform_data/media/
>
> And the references fixed with this script:
> MAIN_DIR="linux/platform_data/"
> PREV_DIR="media/"
> DIRS="media/"
>
> echo "Checking affected files" >&2
> for i in $DIRS; do
> for j in $(find include/$MAIN_DIR/$i -type f -name '*.h'); do
>n=`basename $j`
> git grep -l $n
> done
> done|sort|uniq >files && (
> echo "Handling files..." >&2;
> echo "for i in \$(cat files|grep -v Documentation); do cat \$i | \\";
> (
> cd include/$MAIN_DIR;
> for j in $DIRS; do
> for i in $(ls $j); do
> echo "perl -ne 's,(include
> [\\\"\\<])$PREV_DIR($i)([\\\"\\>]),\1$MAIN_DIR$j\2\3,; print \$_' |\\";
> done;
> done;
> echo "cat > a && mv a \$i; done";
> );
> echo "Handling documentation..." >&2;
> echo "for i in MAINTAINERS \$(cat files); do cat \$i | \\";
> (
> cd include/$MAIN_DIR;
> for j in $DIRS; do
> for i in $(ls $j); do
> echo " perl -ne
> 's,include/$PREV_DIR($i)\b,include/$MAIN_DIR$j\1,; print \$_' |\\";
> done;
> done;
> echo "cat > a && mv a \$i; done"
> );
> ) >script && . ./script
>
> Signed-off-by: Mauro Carvalho Chehab <mche...@osg.samsung.com>
> ---
> Documentation/video4linux/omap4_camera.txt| 2 +-
> Documentation/video4linux/si4713.txt | 2 +-
> MAINTAINERS | 1 +
> arch/arm/mach-omap1/include/mach/camera.h | 2 +-
> arch/arm/mach-omap2/board-rx51-peripherals.c | 4 ++--
> arch/arm/plat-samsung/devs.c | 2 +-
> arch/sh/boards/mach-ap325rxa/setup.c | 2 +-
> drivers/media/platform/marvell-ccic/mmp-driver.c | 2 +-
> drivers/media/platform/s5p-tv/hdmi_drv.c | 2 +-
> drivers/media/platform/s5p-tv/sii9234_drv.c | 2 +-
> drivers/media/platform/soc_camera/omap1_camera.c | 2 +-
> drivers/media/platform/soc_camera/soc_camera_platform.c | 2 +-
> drivers/media/platform/timblogiw.c| 2 +-
> drivers/media/radio/radio-timb.c | 2 +-
> drivers/media/radio/si4713/radio-usb-si4713.c | 2 +-
> drivers/media/radio/si4713/si4713.h | 2 +-
> drivers/media/rc/gpio-ir-recv.c | 2 +-
> drivers/media/rc/ir-rx51.c| 2 +-
> drivers/mfd/timberdale.c | 4 ++--
Acked-by: Lee Jones <lee.jo...@linaro.org>
> drivers/staging/media/omap4iss/iss.h | 2 +-
> drivers/staging/media/omap4iss/iss_csiphy.h | 2 +-
> include/{ => linux/platform_data}/media/gpio-ir-recv.h| 1 -
> include/{ => linux/platform_data}/media/ir-rx51.h | 0
> include/{ => linux/platform_data}/media/mmp-camera.h | 0
> include/{ => linux/platform_data}/media/omap1_camera.h| 0
> include/{ => linux/platform_data}/media/omap4iss.h| 0
> include/{ => linux/platform_data}/media/s5p_hdmi.h| 1 -
> include/{ => linux/platform_data}/media/si4713.h | 2 +-
> include/{ => linux/platform_data}/media/sii9234.h | 0
> include/{ => linux/platform_data}/media/soc_camera_platform.h | 0
> include/{ => linux/platform_data}/media/timb_radio.h | 0
> include/{ => linux/platform_data}/media/timb_video.h
Re: [RESEND] mfd: rtsx: add support for rts522A
On Sat, 10 Oct 2015, 敬锐 wrote:
> Sorry for bother you, but I still can't see this patch applied.
> Is there something wrong?
Sorry about that Micky, I guess this one fell through the gaps.
Re-applied, should be in -next by tomorrow.
> On 07/08/2015 03:38 PM, Lee Jones wrote:
> > On Wed, 08 Jul 2015, 敬锐 wrote:
> >
> >>
> >> On 07/07/2015 07:46 PM, Lee Jones wrote:
> >>> On Mon, 29 Jun 2015, micky_ch...@realsil.com.cn wrote:
> >>>
> >>>> From: Micky Ching <micky_ch...@realsil.com.cn>
> >>>>
> >>>> rts522a(rts5227s) is derived from rts5227, and mainly same with rts5227.
> >>>> Add it to file mfd/rts5227.c to support this chip.
> >>>>
> >>>> Signed-off-by: Micky Ching <micky_ch...@realsil.com.cn>
> >>>> ---
> >>>>drivers/mfd/Kconfig | 7 ++--
> >>>>drivers/mfd/rts5227.c| 77
> >>>> ++--
> >>>>drivers/mfd/rtsx_pcr.c | 5 +++
> >>>>drivers/mfd/rtsx_pcr.h | 3 ++
> >>>>include/linux/mfd/rtsx_pci.h | 6
> >>>>5 files changed, 93 insertions(+), 5 deletions(-)
> >>> I Acked this once already.
> >>>
> >>> What's changed since then?
> >> It's not changed, but I don't have time to fix magic numbers these days,
> >> so, I prefer you apply this patch not waiting next patch.
> > Subsequent patches are irrelevant. I Acked this patch, so the Ack
> > should carry forward.
> >
> > I'll apply the patch for now, but please bear this in mind for the
> > future.
> >
> > Patch applied, thanks.
> >
> >>>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> >>>> index 6538159..614c146 100644
> >>>> --- a/drivers/mfd/Kconfig
> >>>> +++ b/drivers/mfd/Kconfig
> >>>> @@ -686,9 +686,10 @@ config MFD_RTSX_PCI
> >>>> select MFD_CORE
> >>>> help
> >>>>This supports for Realtek PCI-Express card reader including
> >>>> rts5209,
> >>>> - rts5229, rtl8411, etc. Realtek card reader supports access to
> >>>> many
> >>>> - types of memory cards, such as Memory Stick, Memory Stick Pro,
> >>>> - Secure Digital and MultiMediaCard.
> >>>> + rts5227, rts522A, rts5229, rts5249, rts524A, rts525A,
> >>>> rtl8411, etc.
> >>>> + Realtek card reader supports access to many types of memory
> >>>> cards,
> >>>> + such as Memory Stick, Memory Stick Pro, Secure Digital and
> >>>> + MultiMediaCard.
> >>>>
> >>>>config MFD_RT5033
> >>>> tristate "Richtek RT5033 Power Management IC"
> >>>> diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
> >>>> index ce012d7..cf13e66 100644
> >>>> --- a/drivers/mfd/rts5227.c
> >>>> +++ b/drivers/mfd/rts5227.c
> >>>> @@ -26,6 +26,14 @@
> >>>>
> >>>>#include "rtsx_pcr.h"
> >>>>
> >>>> +static u8 rts5227_get_ic_version(struct rtsx_pcr *pcr)
> >>>> +{
> >>>> +u8 val;
> >>>> +
> >>>> +rtsx_pci_read_register(pcr, DUMMY_REG_RESET_0, );
> >>>> +return val & 0x0F;
> >>>> +}
> >>>> +
> >>>>static void rts5227_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
> >>>>{
> >>>> u8 driving_3v3[4][3] = {
> >>>> @@ -88,7 +96,7 @@ static void rts5227_force_power_down(struct rtsx_pcr
> >>>> *pcr, u8 pm_state)
> >>>> rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
> >>>>
> >>>> if (pm_state == HOST_ENTER_S3)
> >>>> -rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
> >>>> +rtsx_pci_write_register(pcr, pcr->reg_pm_ctrl3, 0x10,
> >>>> 0x10);
> >>>>
> >>>> rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
> >>>>}
> >>>> @@ -121,7 +129,7 @@ static int rts5227_extra_init_hw(struct rtsx_pcr
> >>>> *pcr)
> >>>> rtsx_pci_add_cmd(pcr, WRITE_REG_
Re: [RESEND] mfd: rtsx: add support for rts522A
On Wed, 08 Jul 2015, 敬锐 wrote:
On 07/07/2015 07:46 PM, Lee Jones wrote:
On Mon, 29 Jun 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
rts522a(rts5227s) is derived from rts5227, and mainly same with rts5227.
Add it to file mfd/rts5227.c to support this chip.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/Kconfig | 7 ++--
drivers/mfd/rts5227.c| 77
++--
drivers/mfd/rtsx_pcr.c | 5 +++
drivers/mfd/rtsx_pcr.h | 3 ++
include/linux/mfd/rtsx_pci.h | 6
5 files changed, 93 insertions(+), 5 deletions(-)
I Acked this once already.
What's changed since then?
It's not changed, but I don't have time to fix magic numbers these days,
so, I prefer you apply this patch not waiting next patch.
Subsequent patches are irrelevant. I Acked this patch, so the Ack
should carry forward.
I'll apply the patch for now, but please bear this in mind for the
future.
Patch applied, thanks.
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 6538159..614c146 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -686,9 +686,10 @@ config MFD_RTSX_PCI
select MFD_CORE
help
This supports for Realtek PCI-Express card reader including rts5209,
-rts5229, rtl8411, etc. Realtek card reader supports access to many
-types of memory cards, such as Memory Stick, Memory Stick Pro,
-Secure Digital and MultiMediaCard.
+rts5227, rts522A, rts5229, rts5249, rts524A, rts525A, rtl8411, etc.
+Realtek card reader supports access to many types of memory cards,
+such as Memory Stick, Memory Stick Pro, Secure Digital and
+MultiMediaCard.
config MFD_RT5033
tristate Richtek RT5033 Power Management IC
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index ce012d7..cf13e66 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -26,6 +26,14 @@
#include rtsx_pcr.h
+static u8 rts5227_get_ic_version(struct rtsx_pcr *pcr)
+{
+ u8 val;
+
+ rtsx_pci_read_register(pcr, DUMMY_REG_RESET_0, val);
+ return val 0x0F;
+}
+
static void rts5227_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
{
u8 driving_3v3[4][3] = {
@@ -88,7 +96,7 @@ static void rts5227_force_power_down(struct rtsx_pcr
*pcr, u8 pm_state)
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
if (pm_state == HOST_ENTER_S3)
- rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
+ rtsx_pci_write_register(pcr, pcr-reg_pm_ctrl3, 0x10, 0x10);
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
}
@@ -121,7 +129,7 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8);
else
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88);
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, pcr-reg_pm_ctrl3, 0x10, 0x00);
return rtsx_pci_send_cmd(pcr, 100);
}
@@ -298,8 +306,73 @@ void rts5227_init_params(struct rtsx_pcr *pcr)
pcr-tx_initial_phase = SET_CLOCK_PHASE(27, 27, 15);
pcr-rx_initial_phase = SET_CLOCK_PHASE(30, 7, 7);
+ pcr-ic_version = rts5227_get_ic_version(pcr);
pcr-sd_pull_ctl_enable_tbl = rts5227_sd_pull_ctl_enable_tbl;
pcr-sd_pull_ctl_disable_tbl = rts5227_sd_pull_ctl_disable_tbl;
pcr-ms_pull_ctl_enable_tbl = rts5227_ms_pull_ctl_enable_tbl;
pcr-ms_pull_ctl_disable_tbl = rts5227_ms_pull_ctl_disable_tbl;
+
+ pcr-reg_pm_ctrl3 = PM_CTRL3;
+}
+
+static int rts522a_optimize_phy(struct rtsx_pcr *pcr)
+{
+ int err;
+
+ err = rtsx_pci_write_register(pcr, RTS522A_PM_CTRL3, D3_DELINK_MODE_EN,
+ 0x00);
+ if (err 0)
+ return err;
+
+ if (is_version(pcr, 0x522A, IC_VER_A)) {
+ err = rtsx_pci_write_phy_register(pcr, PHY_RCR2,
+ PHY_RCR2_INIT_27S);
+ if (err)
+ return err;
+
+ rtsx_pci_write_phy_register(pcr, PHY_RCR1, PHY_RCR1_INIT_27S);
+ rtsx_pci_write_phy_register(pcr, PHY_FLD0, PHY_FLD0_INIT_27S);
+ rtsx_pci_write_phy_register(pcr, PHY_FLD3, PHY_FLD3_INIT_27S);
+ rtsx_pci_write_phy_register(pcr, PHY_FLD4, PHY_FLD4_INIT_27S);
+ }
+
+ return 0;
+}
+
+static int rts522a_extra_init_hw(struct rtsx_pcr *pcr)
+{
+ rts5227_extra_init_hw(pcr);
+
+ rtsx_pci_write_register(pcr, FUNC_FORCE_CTL, FUNC_FORCE_UPME_XMT_DBG,
+ FUNC_FORCE_UPME_XMT_DBG);
+ rtsx_pci_write_register(pcr, PCLK_CTL, 0x04, 0x04);
+ rtsx_pci_write_register(pcr, PM_EVENT_DEBUG, PME_DEBUG_0, PME_DEBUG_0);
+ rtsx_pci_write_register(pcr, PM_CLK_FORCE_CTL, 0xFF, 0x11);
+
+ return 0;
+}
+
+/* rts522a operations mainly derived from rts5227
Re: [RESEND] mfd: rtsx: add support for rts522A
= rts5227_enable_auto_blink,
+ .disable_auto_blink = rts5227_disable_auto_blink,
+ .card_power_on = rts5227_card_power_on,
+ .card_power_off = rts5227_card_power_off,
+ .switch_output_voltage = rts5227_switch_output_voltage,
+ .cd_deglitch = NULL,
+ .conv_clk_and_div_n = NULL,
+ .force_power_down = rts5227_force_power_down,
+};
+
+void rts522a_init_params(struct rtsx_pcr *pcr)
+{
+ rts5227_init_params(pcr);
+
+ pcr-reg_pm_ctrl3 = RTS522A_PM_CTRL3;
}
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index a66540a..ccd8918 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -55,6 +55,7 @@ static const struct pci_device_id rtsx_pci_ids[] = {
{ PCI_DEVICE(0x10EC, 0x5229), PCI_CLASS_OTHERS 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5289), PCI_CLASS_OTHERS 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5227), PCI_CLASS_OTHERS 16, 0xFF },
+ { PCI_DEVICE(0x10EC, 0x522A), PCI_CLASS_OTHERS 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5249), PCI_CLASS_OTHERS 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5287), PCI_CLASS_OTHERS 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5286), PCI_CLASS_OTHERS 16, 0xFF },
@@ -1102,6 +1103,10 @@ static int rtsx_pci_init_chip(struct rtsx_pcr *pcr)
rts5227_init_params(pcr);
break;
+ case 0x522A:
+ rts522a_init_params(pcr);
+ break;
+
case 0x5249:
rts5249_init_params(pcr);
break;
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index ce48842..931d1ae 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -27,6 +27,8 @@
#define MIN_DIV_N_PCR80
#define MAX_DIV_N_PCR208
+#define RTS522A_PM_CTRL3 0xFF7E
+
#define RTS524A_PME_FORCE_CTL0xFF78
#define RTS524A_PM_CTRL3 0xFF7E
@@ -38,6 +40,7 @@ void rts5229_init_params(struct rtsx_pcr *pcr);
void rtl8411_init_params(struct rtsx_pcr *pcr);
void rtl8402_init_params(struct rtsx_pcr *pcr);
void rts5227_init_params(struct rtsx_pcr *pcr);
+void rts522a_init_params(struct rtsx_pcr *pcr);
void rts5249_init_params(struct rtsx_pcr *pcr);
void rts524a_init_params(struct rtsx_pcr *pcr);
void rts525a_init_params(struct rtsx_pcr *pcr);
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index ff843e7..7eb7cba 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -589,6 +589,7 @@
#define FORCE_ASPM_NO_ASPM 0x00
#define PM_CLK_FORCE_CTL 0xFE58
#define FUNC_FORCE_CTL 0xFE59
+#define FUNC_FORCE_UPME_XMT_DBG0x02
#define PERST_GLITCH_WIDTH 0xFE5C
#define CHANGE_LINK_STATE0xFE5B
#define RESET_LOAD_REG 0xFE5E
@@ -712,6 +713,7 @@
#define PHY_RCR1 0x02
#define PHY_RCR1_ADP_TIME_40x0400
#define PHY_RCR1_VCO_COARSE0x001F
+#define PHY_RCR1_INIT_27S 0x0A1F
#define PHY_SSCCR2 0x02
#define PHY_SSCCR2_PLL_NCODE 0x0A00
#define PHY_SSCCR2_TIME0 0x001C
@@ -724,6 +726,7 @@
#define PHY_RCR2_FREQSEL_120x0040
#define PHY_RCR2_CDR_SC_12P0x0010
#define PHY_RCR2_CALIB_LATE0x0002
+#define PHY_RCR2_INIT_27S 0xC152
#define PHY_SSCCR3 0x03
#define PHY_SSCCR3_STEP_IN 0x2740
#define PHY_SSCCR3_CHECK_DELAY 0x0008
@@ -800,12 +803,14 @@
#define PHY_ANA1A_RXT_BIST 0x0500
#define PHY_ANA1A_TXR_BIST 0x0040
#define PHY_ANA1A_REV 0x0006
+#define PHY_FLD0_INIT_27S 0x2546
#define PHY_FLD1 0x1B
#define PHY_FLD2 0x1C
#define PHY_FLD3 0x1D
#define PHY_FLD3_TIMER_4 0x0800
#define PHY_FLD3_TIMER_6 0x0020
#define PHY_FLD3_RXDELINK 0x0004
+#define PHY_FLD3_INIT_27S 0x0004
#define PHY_ANA1D0x1D
#define PHY_ANA1D_DEBUG_ADDR 0x0004
#define _PHY_FLD00x1D
@@ -824,6 +829,7 @@
#define PHY_FLD4_BER_COUNT 0x00E0
#define PHY_FLD4_BER_TIMER 0x000A
#define PHY_FLD4_BER_CHK_EN0x0001
+#define PHY_FLD4_INIT_27S 0x5C7F
#define PHY_DIG1E0x1E
#define PHY_DIG1E_REV 0x4000
#define PHY_DIG1E_D0_X_D1 0x1000
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] mfd: rtsx: add support for rts522A
On Fri, 17 Apr 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
rts522a(rts5227s) is derived from rts5227, and mainly same with rts5227.
Add it to file mfd/rts5227.c to support this chip.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/Kconfig | 7 ++--
drivers/mfd/rts5227.c| 77
++--
drivers/mfd/rtsx_pcr.c | 5 +++
drivers/mfd/rtsx_pcr.h | 3 ++
include/linux/mfd/rtsx_pci.h | 6
5 files changed, 93 insertions(+), 5 deletions(-)
In a subsequent patch, can you define all of the magic numbers used in
this driver please?
Apart from that, patch looks fine:
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 38356e3..2c52f93 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -646,9 +646,10 @@ config MFD_RTSX_PCI
select MFD_CORE
help
This supports for Realtek PCI-Express card reader including rts5209,
- rts5229, rtl8411, etc. Realtek card reader supports access to many
- types of memory cards, such as Memory Stick, Memory Stick Pro,
- Secure Digital and MultiMediaCard.
+ rts5227, rts522A, rts5229, rts5249, rts524A, rts525A, rtl8411, etc.
+ Realtek card reader supports access to many types of memory cards,
+ such as Memory Stick, Memory Stick Pro, Secure Digital and
+ MultiMediaCard.
config MFD_RT5033
tristate Richtek RT5033 Power Management IC
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index ce012d7..cf13e66 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -26,6 +26,14 @@
#include rtsx_pcr.h
+static u8 rts5227_get_ic_version(struct rtsx_pcr *pcr)
+{
+ u8 val;
+
+ rtsx_pci_read_register(pcr, DUMMY_REG_RESET_0, val);
+ return val 0x0F;
+}
+
static void rts5227_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
{
u8 driving_3v3[4][3] = {
@@ -88,7 +96,7 @@ static void rts5227_force_power_down(struct rtsx_pcr *pcr,
u8 pm_state)
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
if (pm_state == HOST_ENTER_S3)
- rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
+ rtsx_pci_write_register(pcr, pcr-reg_pm_ctrl3, 0x10, 0x10);
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
}
@@ -121,7 +129,7 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8);
else
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88);
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, pcr-reg_pm_ctrl3, 0x10, 0x00);
return rtsx_pci_send_cmd(pcr, 100);
}
@@ -298,8 +306,73 @@ void rts5227_init_params(struct rtsx_pcr *pcr)
pcr-tx_initial_phase = SET_CLOCK_PHASE(27, 27, 15);
pcr-rx_initial_phase = SET_CLOCK_PHASE(30, 7, 7);
+ pcr-ic_version = rts5227_get_ic_version(pcr);
pcr-sd_pull_ctl_enable_tbl = rts5227_sd_pull_ctl_enable_tbl;
pcr-sd_pull_ctl_disable_tbl = rts5227_sd_pull_ctl_disable_tbl;
pcr-ms_pull_ctl_enable_tbl = rts5227_ms_pull_ctl_enable_tbl;
pcr-ms_pull_ctl_disable_tbl = rts5227_ms_pull_ctl_disable_tbl;
+
+ pcr-reg_pm_ctrl3 = PM_CTRL3;
+}
+
+static int rts522a_optimize_phy(struct rtsx_pcr *pcr)
+{
+ int err;
+
+ err = rtsx_pci_write_register(pcr, RTS522A_PM_CTRL3, D3_DELINK_MODE_EN,
+ 0x00);
+ if (err 0)
+ return err;
+
+ if (is_version(pcr, 0x522A, IC_VER_A)) {
+ err = rtsx_pci_write_phy_register(pcr, PHY_RCR2,
+ PHY_RCR2_INIT_27S);
+ if (err)
+ return err;
+
+ rtsx_pci_write_phy_register(pcr, PHY_RCR1, PHY_RCR1_INIT_27S);
+ rtsx_pci_write_phy_register(pcr, PHY_FLD0, PHY_FLD0_INIT_27S);
+ rtsx_pci_write_phy_register(pcr, PHY_FLD3, PHY_FLD3_INIT_27S);
+ rtsx_pci_write_phy_register(pcr, PHY_FLD4, PHY_FLD4_INIT_27S);
+ }
+
+ return 0;
+}
+
+static int rts522a_extra_init_hw(struct rtsx_pcr *pcr)
+{
+ rts5227_extra_init_hw(pcr);
+
+ rtsx_pci_write_register(pcr, FUNC_FORCE_CTL, FUNC_FORCE_UPME_XMT_DBG,
+ FUNC_FORCE_UPME_XMT_DBG);
+ rtsx_pci_write_register(pcr, PCLK_CTL, 0x04, 0x04);
+ rtsx_pci_write_register(pcr, PM_EVENT_DEBUG, PME_DEBUG_0, PME_DEBUG_0);
+ rtsx_pci_write_register(pcr, PM_CLK_FORCE_CTL, 0xFF, 0x11);
+
+ return 0;
+}
+
+/* rts522a operations mainly derived from rts5227, except phy/hw init
setting.
+ */
+static const struct pcr_ops rts522a_pcr_ops = {
+ .fetch_vendor_settings = rts5227_fetch_vendor_settings,
+ .extra_init_hw = rts522a_extra_init_hw,
+ .optimize_phy = rts522a_optimize_phy,
+ .turn_on_led
Re: [PATCH v4 11/20] power_supply: Change ownership from driver to core
On Mon, 23 Feb 2015, Krzysztof Kozlowski wrote: Change the ownership of power_supply structure from each driver implementing the class to the power supply core. The patch changes power_supply_register() function thus all drivers implementing power supply class are adjusted. Each driver provides the implementation of power supply. However it should not be the owner of power supply class instance because it is exposed by core to other subsystems with power_supply_get_by_name(). These other subsystems have no knowledge when the driver will unregister the power supply. This leads to several issues when driver is unbound - mostly because user of power supply accesses freed memory. Instead let the core own the instance of struct 'power_supply'. Other users of this power supply will still access valid memory because it will be freed when device reference count reaches 0. Currently this means it will leak but power_supply_put() call in next patches will solve it. This solves invalid memory references in following race condition scenario: Thread 1: charger manager Thread 2: power supply driver, used by charger manager THREAD 1 (charger manager) THREAD 2 (power supply driver) == == psy = power_supply_get_by_name() Driver unbind, .remove power_supply_unregister() Device fully removed [...] include/linux/mfd/abx500/ux500_chargalg.h | 11 +- include/linux/mfd/rt5033.h| 2 +- include/linux/mfd/wm8350/supply.h | 6 +- Acked-by: Lee Jones lee.jo...@linaro.org -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 6/9] mfd: rtsx: remove LCTLR defination
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
To enable/disable ASPM we should find LINK CONTROL register
in PCI config space. All old chip use 0x80 address, but new
chip may use another address, so we using pci_find_capability()
to get LINK CONTROL address.
rtsx_gops.c was removed, we consider to put some common operations
to this file, but the actual thing is, only a group of chips
are in common ops1, and another group of chips in common ops2,
it is hard to decide put which ops into generic ops file.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/Makefile | 2 +-
drivers/mfd/rts5227.c| 2 +-
drivers/mfd/rts5249.c| 3 +--
drivers/mfd/rtsx_gops.c | 37 -
drivers/mfd/rtsx_pcr.c | 22 +-
include/linux/mfd/rtsx_pci.h | 10 +-
6 files changed, 21 insertions(+), 55 deletions(-)
delete mode 100644 drivers/mfd/rtsx_gops.c
Applied, thanks.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..2cd7e74 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_MFD_CROS_EC) += cros_ec.o
obj-$(CONFIG_MFD_CROS_EC_I2C)+= cros_ec_i2c.o
obj-$(CONFIG_MFD_CROS_EC_SPI)+= cros_ec_spi.o
-rtsx_pci-objs:= rtsx_pcr.o rtsx_gops.o rts5209.o
rts5229.o rtl8411.o rts5227.o rts5249.o
+rtsx_pci-objs:= rtsx_pcr.o rts5209.o rts5229.o
rtl8411.o rts5227.o rts5249.o
obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
obj-$(CONFIG_MFD_RTSX_USB) += rtsx_usb.o
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 1f387d4..0c02831 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -130,7 +130,7 @@ static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
{
int err;
- err = rtsx_gops_pm_reset(pcr);
+ err = rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
if (err 0)
return err;
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 8de8220..3c77058 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -119,7 +119,6 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0xB0);
else
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0x80);
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
return rtsx_pci_send_cmd(pcr, 100);
}
@@ -128,7 +127,7 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
{
int err;
- err = rtsx_gops_pm_reset(pcr);
+ err = rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
if (err 0)
return err;
diff --git a/drivers/mfd/rtsx_gops.c b/drivers/mfd/rtsx_gops.c
deleted file mode 100644
index b1a98c6..000
--- a/drivers/mfd/rtsx_gops.c
+++ /dev/null
@@ -1,37 +0,0 @@
-/* Driver for Realtek PCI-Express card reader
- *
- * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2, or (at your option) any
- * later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, see http://www.gnu.org/licenses/.
- *
- * Author:
- * Micky Ching micky_ch...@realsil.com.cn
- */
-
-#include linux/mfd/rtsx_pci.h
-#include rtsx_pcr.h
-
-int rtsx_gops_pm_reset(struct rtsx_pcr *pcr)
-{
- int err;
-
- /* init aspm */
- rtsx_pci_write_register(pcr, ASPM_FORCE_CTL, 0xFF, 0x00);
- err = rtsx_pci_update_cfg_byte(pcr, LCTLR, ~LCTLR_ASPM_CTL_MASK, 0x00);
- if (err 0)
- return err;
-
- /* reset PM_CTRL3 before send buffer cmd */
- return rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
-}
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 30f7ca8..81b9c2c 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -63,6 +63,18 @@ static const struct pci_device_id rtsx_pci_ids[] = {
MODULE_DEVICE_TABLE(pci, rtsx_pci_ids);
+static inline void rtsx_pci_enable_aspm(struct rtsx_pcr *pcr)
+{
+ rtsx_pci_update_cfg_byte(pcr, pcr-pcie_cap + PCI_EXP_LNKCTL,
+ 0xFC, pcr-aspm_en);
+}
+
+static inline void rtsx_pci_disable_aspm(struct rtsx_pcr *pcr)
+{
+ rtsx_pci_update_cfg_byte(pcr, pcr-pcie_cap
Re: [PATCH v3 8/9] mfd: rtsx: add support for rts525A
},
+ { PCI_DEVICE(0x10EC, 0x525A), PCI_CLASS_OTHERS 16, 0xFF },
{ 0, }
};
@@ -1114,6 +1115,10 @@ static int rtsx_pci_init_chip(struct rtsx_pcr *pcr)
rts524a_init_params(pcr);
break;
+ case 0x525A:
+ rts525a_init_params(pcr);
+ break;
+
case 0x5287:
rtl8411b_init_params(pcr);
break;
@@ -1159,7 +1164,7 @@ static int rtsx_pci_probe(struct pci_dev *pcidev,
struct rtsx_pcr *pcr;
struct pcr_handle *handle;
u32 base, len;
- int ret, i;
+ int ret, i, bar = 0;
dev_dbg((pcidev-dev),
: Realtek PCI-E Card Reader found at %s [%04x:%04x] (rev
%x)\n,
@@ -1204,8 +1209,10 @@ static int rtsx_pci_probe(struct pci_dev *pcidev,
pcr-pci = pcidev;
dev_set_drvdata(pcidev-dev, handle);
- len = pci_resource_len(pcidev, 0);
- base = pci_resource_start(pcidev, 0);
+ if (CHK_PCI_PID(pcr, 0x525A))
+ bar = 1;
+ len = pci_resource_len(pcidev, bar);
+ base = pci_resource_start(pcidev, bar);
pcr-remap_addr = ioremap_nocache(base, len);
if (!pcr-remap_addr) {
ret = -ENOMEM;
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index e7daf6f..ce48842 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -40,6 +40,7 @@ void rtl8402_init_params(struct rtsx_pcr *pcr);
void rts5227_init_params(struct rtsx_pcr *pcr);
void rts5249_init_params(struct rtsx_pcr *pcr);
void rts524a_init_params(struct rtsx_pcr *pcr);
+void rts525a_init_params(struct rtsx_pcr *pcr);
void rtl8411b_init_params(struct rtsx_pcr *pcr);
static inline u8 map_sd_drive(int idx)
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 754a18d..ff843e7 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -727,6 +727,10 @@
#define PHY_SSCCR3 0x03
#define PHY_SSCCR3_STEP_IN 0x2740
#define PHY_SSCCR3_CHECK_DELAY 0x0008
+#define _PHY_ANA03 0x03
+#define _PHY_ANA03_TIMER_MAX 0x2700
+#define _PHY_ANA03_OOBS_DEB_EN 0x0040
+#define _PHY_CMU_DEBUG_EN 0x0008
#define PHY_RTCR 0x04
#define PHY_RDR 0x05
@@ -785,6 +789,10 @@
#define PHY_REV_STOP_CLKRD 0x0020
#define PHY_REV_RX_PWST0x0008
#define PHY_REV_STOP_CLKWR 0x0004
+#define _PHY_REV00x19
+#define _PHY_REV0_FILTER_OUT 0x3800
+#define _PHY_REV0_CDR_BYPASS_PFD 0x0100
+#define _PHY_REV0_CDR_RX_IDLE_BYPASS 0x0002
#define PHY_FLD0 0x1A
#define PHY_ANA1A0x1A
@@ -800,6 +808,13 @@
#define PHY_FLD3_RXDELINK 0x0004
#define PHY_ANA1D0x1D
#define PHY_ANA1D_DEBUG_ADDR 0x0004
+#define _PHY_FLD00x1D
+#define _PHY_FLD0_CLK_REQ_20C 0x8000
+#define _PHY_FLD0_RX_IDLE_EN 0x1000
+#define _PHY_FLD0_BIT_ERR_RSTN 0x0800
+#define _PHY_FLD0_BER_COUNT0x01E0
+#define _PHY_FLD0_BER_TIMER0x001E
+#define _PHY_FLD0_CHECK_EN 0x0001
#define PHY_FLD4 0x1E
#define PHY_FLD4_FLDEN_SEL 0x4000
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 7/9] mfd: rtsx: add support for rts524A
0x03
+#define PHY_SSCCR3_STEP_IN 0x2740
+#define PHY_SSCCR3_CHECK_DELAY 0x0008
#define PHY_RTCR 0x04
#define PHY_RDR 0x05
@@ -663,6 +741,16 @@
#define PHY_TUNE_TUNED18 0x01C0
#define PHY_TUNE_TUNED12 0X0020
#define PHY_TUNE_TUNEA12 0x0004
+#define PHY_TUNE_VOLTAGE_MASK 0xFC3F
+#define PHY_TUNE_VOLTAGE_3V3 0x03C0
+#define PHY_TUNE_D18_1V8 0x0100
+#define PHY_TUNE_D18_1V7 0x0080
+#define PHY_ANA080x08
+#define PHY_ANA08_RX_EQ_DCGAIN 0x5000
+#define PHY_ANA08_SEL_RX_EN0x0400
+#define PHY_ANA08_RX_EQ_VAL0x03C0
+#define PHY_ANA08_SCP 0x0020
+#define PHY_ANA08_SEL_IPI 0x0004
#define PHY_IMR 0x09
#define PHY_BPCR 0x0A
@@ -678,6 +766,7 @@
#define PHY_HOST_CLK_CTRL0x0F
#define PHY_DMR 0x10
#define PHY_BACR 0x11
+#define PHY_BACR_BASIC_MASK0xFFF3
#define PHY_IER 0x12
#define PHY_BCSR 0x13
#define PHY_BPR 0x14
@@ -698,12 +787,19 @@
#define PHY_REV_STOP_CLKWR 0x0004
#define PHY_FLD0 0x1A
+#define PHY_ANA1A0x1A
+#define PHY_ANA1A_TXR_LOOPBACK 0x2000
+#define PHY_ANA1A_RXT_BIST 0x0500
+#define PHY_ANA1A_TXR_BIST 0x0040
+#define PHY_ANA1A_REV 0x0006
#define PHY_FLD1 0x1B
#define PHY_FLD2 0x1C
#define PHY_FLD3 0x1D
#define PHY_FLD3_TIMER_4 0x0800
#define PHY_FLD3_TIMER_6 0x0020
#define PHY_FLD3_RXDELINK 0x0004
+#define PHY_ANA1D0x1D
+#define PHY_ANA1D_DEBUG_ADDR 0x0004
#define PHY_FLD4 0x1E
#define PHY_FLD4_FLDEN_SEL 0x4000
@@ -713,7 +809,18 @@
#define PHY_FLD4_BER_COUNT 0x00E0
#define PHY_FLD4_BER_TIMER 0x000A
#define PHY_FLD4_BER_CHK_EN0x0001
-
+#define PHY_DIG1E0x1E
+#define PHY_DIG1E_REV 0x4000
+#define PHY_DIG1E_D0_X_D1 0x1000
+#define PHY_DIG1E_RX_ON_HOST 0x0800
+#define PHY_DIG1E_RCLK_REF_HOST0x0400
+#define PHY_DIG1E_RCLK_TX_EN_KEEP 0x0040
+#define PHY_DIG1E_RCLK_TX_TERM_KEEP0x0020
+#define PHY_DIG1E_RCLK_RX_EIDLE_ON 0x0010
+#define PHY_DIG1E_TX_TERM_KEEP 0x0008
+#define PHY_DIG1E_RX_TERM_KEEP 0x0004
+#define PHY_DIG1E_TX_EN_KEEP 0x0002
+#define PHY_DIG1E_RX_EN_KEEP 0x0001
#define PHY_DUM_REG 0x1F
#define PCR_SETTING_REG1 0x724
@@ -729,6 +836,8 @@ struct pcr_handle {
};
struct pcr_ops {
+ int (*write_phy)(struct rtsx_pcr *pcr, u8 addr, u16 val);
+ int (*read_phy)(struct rtsx_pcr *pcr, u8 addr, u16 *val);
int (*extra_init_hw)(struct rtsx_pcr *pcr);
int (*optimize_phy)(struct rtsx_pcr *pcr);
int (*turn_on_led)(struct rtsx_pcr *pcr);
@@ -823,6 +932,8 @@ struct rtsx_pcr {
const struct pcr_ops*ops;
enum PDEV_STAT state;
+ u16 reg_pm_ctrl3;
+
int num_slots;
struct rtsx_slot*slots;
};
@@ -830,6 +941,10 @@ struct rtsx_pcr {
#define CHK_PCI_PID(pcr, pid)((pcr)-pci-device == (pid))
#define PCI_VID(pcr) ((pcr)-pci-vendor)
#define PCI_PID(pcr) ((pcr)-pci-device)
+#define is_version(pcr, pid, ver)\
+ (CHK_PCI_PID(pcr, pid) (pcr)-ic_version == (ver))
+#define pcr_dbg(pcr, fmt, arg...)\
+ dev_dbg((pcr)-pci-dev, fmt, ##arg)
#define SDR104_PHASE(val)((val) 0xFF)
#define SDR50_PHASE(val) (((val) 8) 0xFF)
@@ -899,4 +1014,17 @@ static inline void rtsx_pci_write_be32(struct rtsx_pcr
*pcr, u16 reg, u32 val)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
}
+static inline int rtsx_pci_update_phy(struct rtsx_pcr *pcr, u8 addr,
+ u16 mask, u16 append)
+{
+ int err;
+ u16 val;
+
+ err = rtsx_pci_read_phy_register(pcr, addr, val);
+ if (err 0)
+ return err;
+
+ return rtsx_pci_write_phy_register(pcr, addr, (val mask) | append);
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http
Re: [PATCH v3 4/9] mfd: rtsx: update driving settings
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
update card drive settings, This setting can be used for rts5249
rts524A and rts525A.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/rts5249.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
Applied, thanks.
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 225ad55..2fe2854 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -36,16 +36,16 @@ static u8 rts5249_get_ic_version(struct rtsx_pcr *pcr)
static void rts5249_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
{
u8 driving_3v3[4][3] = {
- {0x11, 0x11, 0x11},
+ {0x11, 0x11, 0x18},
{0x55, 0x55, 0x5C},
- {0x99, 0x99, 0x92},
- {0x99, 0x99, 0x92},
+ {0xFF, 0xFF, 0xFF},
+ {0x96, 0x96, 0x96},
};
u8 driving_1v8[4][3] = {
+ {0xC4, 0xC4, 0xC4},
{0x3C, 0x3C, 0x3C},
- {0xB3, 0xB3, 0xB3},
{0xFE, 0xFE, 0xFE},
- {0xC4, 0xC4, 0xC4},
+ {0xB3, 0xB3, 0xB3},
};
u8 (*driving)[3], drive_sel;
@@ -341,7 +341,7 @@ void rts5249_init_params(struct rtsx_pcr *pcr)
pcr-flags = 0;
pcr-card_drive_sel = RTSX_CARD_DRIVE_DEFAULT;
- pcr-sd30_drive_sel_1v8 = CFG_DRIVER_TYPE_C;
+ pcr-sd30_drive_sel_1v8 = CFG_DRIVER_TYPE_B;
pcr-sd30_drive_sel_3v3 = CFG_DRIVER_TYPE_B;
pcr-aspm_en = ASPM_L1_EN;
pcr-tx_initial_phase = SET_CLOCK_PHASE(1, 29, 16);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 5/9] mfd: rtsx: update phy register
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn Update some phy register name and value for rts5249, the updated value makes chip more stable on some platform. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- drivers/mfd/rts5249.c| 29 +++- include/linux/mfd/rtsx_pci.h | 109 ++- 2 files changed, 72 insertions(+), 66 deletions(-) Acked-by: Lee Jones lee.jo...@linaro.org diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c index 2fe2854..8de8220 100644 --- a/drivers/mfd/rts5249.c +++ b/drivers/mfd/rts5249.c @@ -132,11 +132,12 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr) if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV, - PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED | - PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN | - PHY_REG_REV_RX_PWST | PHY_REG_REV_CLKREQ_DLY_TIMER_1_0 | - PHY_REG_REV_STOP_CLKRD | PHY_REG_REV_STOP_CLKWR); + err = rtsx_pci_write_phy_register(pcr, PHY_REV, + PHY_REV_RESV | PHY_REV_RXIDLE_LATCHED | + PHY_REV_P1_EN | PHY_REV_RXIDLE_EN | + PHY_REV_CLKREQ_TX_EN | PHY_REV_RX_PWST | + PHY_REV_CLKREQ_DT_1_0 | PHY_REV_STOP_CLKRD | + PHY_REV_STOP_CLKWR); if (err 0) return err; @@ -147,19 +148,21 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr) PHY_BPCR_IB_FILTER | PHY_BPCR_CMIRROR_EN); if (err 0) return err; + err = rtsx_pci_write_phy_register(pcr, PHY_PCR, PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 | PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 | - PHY_PCR_RSSI_EN); + PHY_PCR_RSSI_EN | PHY_PCR_RX10K); if (err 0) return err; + err = rtsx_pci_write_phy_register(pcr, PHY_RCR2, PHY_RCR2_EMPHASE_EN | PHY_RCR2_NADJR | - PHY_RCR2_CDR_CP_10 | PHY_RCR2_CDR_SR_2 | - PHY_RCR2_FREQSEL_12 | PHY_RCR2_CPADJEN | - PHY_RCR2_CDR_SC_8 | PHY_RCR2_CALIB_LATE); + PHY_RCR2_CDR_SR_2 | PHY_RCR2_FREQSEL_12 | + PHY_RCR2_CDR_SC_12P | PHY_RCR2_CALIB_LATE); if (err 0) return err; + err = rtsx_pci_write_phy_register(pcr, PHY_FLD4, PHY_FLD4_FLDEN_SEL | PHY_FLD4_REQ_REF | PHY_FLD4_RXAMP_OFF | PHY_FLD4_REQ_ADDA | @@ -167,11 +170,12 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr) PHY_FLD4_BER_CHK_EN); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_RDR, PHY_RDR_RXDSEL_1_9); + err = rtsx_pci_write_phy_register(pcr, PHY_RDR, + PHY_RDR_RXDSEL_1_9 | PHY_SSC_AUTO_PWD); if (err 0) return err; err = rtsx_pci_write_phy_register(pcr, PHY_RCR1, - PHY_RCR1_ADP_TIME | PHY_RCR1_VCO_COARSE); + PHY_RCR1_ADP_TIME_4 | PHY_RCR1_VCO_COARSE); if (err 0) return err; err = rtsx_pci_write_phy_register(pcr, PHY_FLD3, @@ -179,10 +183,11 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr) PHY_FLD3_RXDELINK); if (err 0) return err; + return rtsx_pci_write_phy_register(pcr, PHY_TUNE, PHY_TUNE_TUNEREF_1_0 | PHY_TUNE_VBGSEL_1252 | PHY_TUNE_SDBUS_33 | PHY_TUNE_TUNED18 | - PHY_TUNE_TUNED12); + PHY_TUNE_TUNED12 | PHY_TUNE_TUNEA12); } static int rts5249_turn_on_led(struct rtsx_pcr *pcr) diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h index 87cff60..0103210 100644 --- a/include/linux/mfd/rtsx_pci.h +++ b/include/linux/mfd/rtsx_pci.h @@ -630,16 +630,47 @@ /* Phy register */ #define PHY_PCR 0x00 +#define PHY_PCR_FORCE_CODE 0xB000 +#define PHY_PCR_OOBS_CALI_50 0x0800 +#define PHY_PCR_OOBS_VCM_080x0200 +#define PHY_PCR_OOBS_SEN_900x0040 +#define PHY_PCR_RSSI_EN0x0002 +#define PHY_PCR_RX10K 0x0001 + #define PHY_RCR0 0x01 #define PHY_RCR1 0x02 +#define PHY_RCR1_ADP_TIME_40x0400 +#define PHY_RCR1_VCO_COARSE0x001F + #define PHY_RCR2 0x03 +#define PHY_RCR2_EMPHASE_EN0x8000 +#define PHY_RCR2_NADJR 0x4000 +#define PHY_RCR2_CDR_SR_2 0x0100 +#define PHY_RCR2_FREQSEL_120x0040 +#define
Re: [PATCH v3 3/9] mfd: rtsx: update PETXCFG address
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn PETXCFG is defined at 0xFF03, the old 0xFE49 not used any more. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn Acked-by: Lee Jones lee.jo...@linaro.org --- drivers/mfd/rts5227.c| 6 ++ drivers/mfd/rts5249.c| 6 ++ include/linux/mfd/rtsx_pci.h | 2 +- 3 files changed, 5 insertions(+), 9 deletions(-) Applied, thanks. diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c index 3240740..1f387d4 100644 --- a/drivers/mfd/rts5227.c +++ b/drivers/mfd/rts5227.c @@ -118,11 +118,9 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr) rts5227_fill_driving(pcr, OUTPUT_3V3); /* Configure force_clock_req */ if (pcr-flags PCR_REVERSE_SOCKET) - rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, - AUTOLOAD_CFG_BASE + 3, 0xB8, 0xB8); + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8); else - rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, - AUTOLOAD_CFG_BASE + 3, 0xB8, 0x88); + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88); rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00); return rtsx_pci_send_cmd(pcr, 100); diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c index cf425cc..225ad55 100644 --- a/drivers/mfd/rts5249.c +++ b/drivers/mfd/rts5249.c @@ -116,11 +116,9 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr) /* Configure driving */ rts5249_fill_driving(pcr, OUTPUT_3V3); if (pcr-flags PCR_REVERSE_SOCKET) - rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, - AUTOLOAD_CFG_BASE + 3, 0xB0, 0xB0); + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0xB0); else - rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, - AUTOLOAD_CFG_BASE + 3, 0xB0, 0x80); + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0x80); rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00); return rtsx_pci_send_cmd(pcr, 100); diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h index e81f2bb..87cff60 100644 --- a/include/linux/mfd/rtsx_pci.h +++ b/include/linux/mfd/rtsx_pci.h @@ -572,7 +572,6 @@ #define MSGTXDATA2 0xFE46 #define MSGTXDATA3 0xFE47 #define MSGTXCTL 0xFE48 -#define PETXCFG 0xFE49 #define LTR_CTL 0xFE4A #define OBFF_CFG 0xFE4C @@ -606,6 +605,7 @@ #define DUMMY_REG_RESET_00xFE90 #define AUTOLOAD_CFG_BASE0xFF00 +#define PETXCFG 0xFF03 #define PM_CTRL1 0xFF44 #define PM_CTRL2 0xFF45 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v3 1/9] mfd: rtsx: replace TAB by SPC after #define
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn Re-format coding-style, using uniform SPC after #define keyword instead of mixing using TAB and SPC. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn Acked-by: Lee Jones lee.jo...@linaro.org --- include/linux/mfd/rtsx_pci.h | 254 +-- 1 file changed, 127 insertions(+), 127 deletions(-) Applied, thanks. diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h index 0c12628..a9c2a14 100644 --- a/include/linux/mfd/rtsx_pci.h +++ b/include/linux/mfd/rtsx_pci.h @@ -175,9 +175,9 @@ /* CARD_SHARE_MODE */ #define CARD_SHARE_MASK 0x0F #define CARD_SHARE_MULTI_LUN 0x00 -#define CARD_SHARE_NORMAL 0x00 -#define CARD_SHARE_48_SD0x04 -#define CARD_SHARE_48_MS0x08 +#define CARD_SHARE_NORMAL0x00 +#define CARD_SHARE_48_SD 0x04 +#define CARD_SHARE_48_MS 0x08 /* CARD_SHARE_MODE for barossa */ #define CARD_SHARE_BAROSSA_SD0x01 #define CARD_SHARE_BAROSSA_MS0x02 @@ -249,76 +249,76 @@ #define CD_AUTO_DISABLE 0x40 /* SD_STAT1 */ -#define SD_CRC7_ERR 0x80 -#define SD_CRC16_ERR0x40 -#define SD_CRC_WRITE_ERR0x20 -#define SD_CRC_WRITE_ERR_MASK 0x1C -#define GET_CRC_TIME_OUT0x02 -#define SD_TUNING_COMPARE_ERR 0x01 +#define SD_CRC7_ERR 0x80 +#define SD_CRC16_ERR 0x40 +#define SD_CRC_WRITE_ERR 0x20 +#define SD_CRC_WRITE_ERR_MASK0x1C +#define GET_CRC_TIME_OUT 0x02 +#define SD_TUNING_COMPARE_ERR0x01 /* SD_STAT2 */ -#define SD_RSP_80CLK_TIMEOUT0x01 +#define SD_RSP_80CLK_TIMEOUT 0x01 /* SD_BUS_STAT */ -#define SD_CLK_TOGGLE_EN0x80 -#define SD_CLK_FORCE_STOP 0x40 -#define SD_DAT3_STATUS 0x10 -#define SD_DAT2_STATUS 0x08 -#define SD_DAT1_STATUS 0x04 -#define SD_DAT0_STATUS 0x02 -#define SD_CMD_STATUS 0x01 +#define SD_CLK_TOGGLE_EN 0x80 +#define SD_CLK_FORCE_STOP0x40 +#define SD_DAT3_STATUS 0x10 +#define SD_DAT2_STATUS 0x08 +#define SD_DAT1_STATUS 0x04 +#define SD_DAT0_STATUS 0x02 +#define SD_CMD_STATUS0x01 /* SD_PAD_CTL */ -#define SD_IO_USING_1V8 0x80 -#define SD_IO_USING_3V3 0x7F -#define TYPE_A_DRIVING 0x00 -#define TYPE_B_DRIVING 0x01 -#define TYPE_C_DRIVING 0x02 -#define TYPE_D_DRIVING 0x03 +#define SD_IO_USING_1V8 0x80 +#define SD_IO_USING_3V3 0x7F +#define TYPE_A_DRIVING 0x00 +#define TYPE_B_DRIVING 0x01 +#define TYPE_C_DRIVING 0x02 +#define TYPE_D_DRIVING 0x03 /* SD_SAMPLE_POINT_CTL */ -#define DDR_FIX_RX_DAT 0x00 -#define DDR_VAR_RX_DAT 0x80 -#define DDR_FIX_RX_DAT_EDGE 0x00 -#define DDR_FIX_RX_DAT_14_DELAY 0x40 -#define DDR_FIX_RX_CMD 0x00 -#define DDR_VAR_RX_CMD 0x20 -#define DDR_FIX_RX_CMD_POS_EDGE 0x00 -#define DDR_FIX_RX_CMD_14_DELAY 0x10 -#define SD20_RX_POS_EDGE0x00 -#define SD20_RX_14_DELAY0x08 +#define DDR_FIX_RX_DAT 0x00 +#define DDR_VAR_RX_DAT 0x80 +#define DDR_FIX_RX_DAT_EDGE 0x00 +#define DDR_FIX_RX_DAT_14_DELAY 0x40 +#define DDR_FIX_RX_CMD 0x00 +#define DDR_VAR_RX_CMD 0x20 +#define DDR_FIX_RX_CMD_POS_EDGE 0x00 +#define DDR_FIX_RX_CMD_14_DELAY 0x10 +#define SD20_RX_POS_EDGE 0x00 +#define SD20_RX_14_DELAY 0x08 #define SD20_RX_SEL_MASK 0x08 /* SD_PUSH_POINT_CTL */ -#define DDR_FIX_TX_CMD_DAT 0x00 -#define DDR_VAR_TX_CMD_DAT 0x80 -#define DDR_FIX_TX_DAT_14_TSU 0x00 -#define DDR_FIX_TX_DAT_12_TSU 0x40 -#define DDR_FIX_TX_CMD_NEG_EDGE 0x00 -#define DDR_FIX_TX_CMD_14_AHEAD 0x20 -#define SD20_TX_NEG_EDGE0x00 -#define SD20_TX_14_AHEAD0x10 +#define DDR_FIX_TX_CMD_DAT 0x00 +#define
Re: [PATCH v3 2/9] mfd: rtsx: place register address and values togather
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn It is more readable to place register address and values define togather. The values define add two leading space indicate belong to the register address defined above. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn Acked-by: Lee Jones lee.jo...@linaro.org --- include/linux/mfd/rtsx_pci.h | 836 +++ 1 file changed, 369 insertions(+), 467 deletions(-) Applied, thanks. diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h index a9c2a14..e81f2bb 100644 --- a/include/linux/mfd/rtsx_pci.h +++ b/include/linux/mfd/rtsx_pci.h @@ -28,74 +28,72 @@ #define MAX_RW_REG_CNT 1024 -/* PCI Operation Register Address */ #define RTSX_HCBAR 0x00 #define RTSX_HCBCTLR 0x04 +#define STOP_CMD (0x01 28) +#define READ_REG_CMD 0 +#define WRITE_REG_CMD 1 +#define CHECK_REG_CMD 2 + #define RTSX_HDBAR 0x08 +#define SG_INT 0x04 +#define SG_END 0x02 +#define SG_VALID 0x01 +#define SG_NO_OP 0x00 +#define SG_TRANS_DATA (0x02 4) +#define SG_LINK_DESC (0x03 4) #define RTSX_HDBCTLR 0x0C +#define SDMA_MODE 0x00 +#define ADMA_MODE (0x02 26) +#define STOP_DMA (0x01 28) +#define TRIG_DMA (0x01 31) + #define RTSX_HAIMR 0x10 -#define RTSX_BIPR0x14 -#define RTSX_BIER0x18 +#define HAIMR_TRANS_START (0x01 31) +#define HAIMR_READ 0x00 +#define HAIMR_WRITE(0x01 30) +#define HAIMR_READ_START (HAIMR_TRANS_START | HAIMR_READ) +#define HAIMR_WRITE_START (HAIMR_TRANS_START | HAIMR_WRITE) +#define HAIMR_TRANS_END(HAIMR_TRANS_START) -/* Host command buffer control register */ -#define STOP_CMD (0x01 28) - -/* Host data buffer control register */ -#define SDMA_MODE0x00 -#define ADMA_MODE(0x02 26) -#define STOP_DMA (0x01 28) -#define TRIG_DMA (0x01 31) - -/* Host access internal memory register */ -#define HAIMR_TRANS_START(0x01 31) -#define HAIMR_READ 0x00 -#define HAIMR_WRITE (0x01 30) -#define HAIMR_READ_START (HAIMR_TRANS_START | HAIMR_READ) -#define HAIMR_WRITE_START(HAIMR_TRANS_START | HAIMR_WRITE) -#define HAIMR_TRANS_END (HAIMR_TRANS_START) - -/* Bus interrupt pending register */ -#define CMD_DONE_INT (1 31) -#define DATA_DONE_INT(1 30) -#define TRANS_OK_INT (1 29) -#define TRANS_FAIL_INT (1 28) -#define XD_INT (1 27) -#define MS_INT (1 26) -#define SD_INT (1 25) -#define GPIO0_INT(1 24) -#define OC_INT (1 23) -#define SD_WRITE_PROTECT (1 19) -#define XD_EXIST (1 18) -#define MS_EXIST (1 17) -#define SD_EXIST (1 16) -#define DELINK_INT GPIO0_INT -#define MS_OC_INT(1 23) -#define SD_OC_INT(1 22) +#define RTSX_BIPR0x14 +#define CMD_DONE_INT (1 31) +#define DATA_DONE_INT (1 30) +#define TRANS_OK_INT (1 29) +#define TRANS_FAIL_INT (1 28) +#define XD_INT (1 27) +#define MS_INT (1 26) +#define SD_INT (1 25) +#define GPIO0_INT (1 24) +#define OC_INT (1 23) +#define SD_WRITE_PROTECT (1 19) +#define XD_EXIST (1 18) +#define MS_EXIST (1 17) +#define SD_EXIST (1 16) +#define DELINK_INT GPIO0_INT +#define MS_OC_INT (1 23) +#define SD_OC_INT (1 22) #define CARD_INT (XD_INT | MS_INT | SD_INT) #define NEED_COMPLETE_INT(DATA_DONE_INT | TRANS_OK_INT | TRANS_FAIL_INT) #define RTSX_INT (CMD_DONE_INT | NEED_COMPLETE_INT | \ CARD_INT | GPIO0_INT | OC_INT) - #define CARD_EXIST (XD_EXIST | MS_EXIST | SD_EXIST) -/* Bus interrupt enable register */ -#define
Re: [PATCH v3 9/9] mfd: rtsx: using pcr_dbg replace dev_dbg
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
pcr_dbg is a wrapper of dev_dbg, which can save some code,
and help to enable/disable debug message static.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
Acked-by: Lee Jones lee.jo...@linaro.org
---
drivers/mfd/rtl8411.c | 11 +--
drivers/mfd/rts5209.c | 4 ++--
drivers/mfd/rts5227.c | 4 ++--
drivers/mfd/rts5229.c | 4 ++--
drivers/mfd/rts5249.c | 4 ++--
drivers/mfd/rtsx_pcr.c | 49 ++---
6 files changed, 35 insertions(+), 41 deletions(-)
Applied, thanks.
diff --git a/drivers/mfd/rtl8411.c b/drivers/mfd/rtl8411.c
index fdd34c8..b3ae659 100644
--- a/drivers/mfd/rtl8411.c
+++ b/drivers/mfd/rtl8411.c
@@ -53,7 +53,7 @@ static void rtl8411_fetch_vendor_settings(struct rtsx_pcr
*pcr)
u8 reg3 = 0;
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg1);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg1);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg1);
if (!rtsx_vendor_setting_valid(reg1))
return;
@@ -65,7 +65,7 @@ static void rtl8411_fetch_vendor_settings(struct rtsx_pcr
*pcr)
pcr-card_drive_sel |= rtsx_reg_to_card_drive_sel(reg1);
rtsx_pci_read_config_byte(pcr, PCR_SETTING_REG3, reg3);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG3, reg3);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG3, reg3);
pcr-sd30_drive_sel_3v3 = rtl8411_reg_to_sd30_drive_sel_3v3(reg3);
}
@@ -74,7 +74,7 @@ static void rtl8411b_fetch_vendor_settings(struct rtsx_pcr
*pcr)
u32 reg = 0;
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
if (!rtsx_vendor_setting_valid(reg))
return;
@@ -260,9 +260,8 @@ static unsigned int rtl8411_cd_deglitch(struct rtsx_pcr
*pcr)
rtsx_pci_write_register(pcr, CARD_PWR_CTL,
BPP_POWER_MASK, BPP_POWER_OFF);
- dev_dbg((pcr-pci-dev),
- After CD deglitch, card_exist = 0x%x\n,
- card_exist);
+ pcr_dbg(pcr, After CD deglitch, card_exist = 0x%x\n,
+ card_exist);
}
if (card_exist MS_EXIST) {
diff --git a/drivers/mfd/rts5209.c b/drivers/mfd/rts5209.c
index cb04174..373e253 100644
--- a/drivers/mfd/rts5209.c
+++ b/drivers/mfd/rts5209.c
@@ -38,7 +38,7 @@ static void rts5209_fetch_vendor_settings(struct rtsx_pcr
*pcr)
u32 reg;
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
if (rts5209_vendor_setting1_valid(reg)) {
if (rts5209_reg_check_ms_pmos(reg))
@@ -47,7 +47,7 @@ static void rts5209_fetch_vendor_settings(struct rtsx_pcr
*pcr)
}
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG2, reg);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG2, reg);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG2, reg);
if (rts5209_vendor_setting2_valid(reg)) {
pcr-sd30_drive_sel_1v8 =
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 0c02831..ce012d7 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -63,7 +63,7 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr
*pcr)
u32 reg;
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
if (!rtsx_vendor_setting_valid(reg))
return;
@@ -74,7 +74,7 @@ static void rts5227_fetch_vendor_settings(struct rtsx_pcr
*pcr)
pcr-card_drive_sel |= rtsx_reg_to_card_drive_sel(reg);
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG2, reg);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG2, reg);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG2, reg);
pcr-sd30_drive_sel_3v3 = rtsx_reg_to_sd30_drive_sel_3v3(reg);
if (rtsx_reg_check_reverse_socket(reg))
pcr-flags |= PCR_REVERSE_SOCKET;
diff --git a/drivers/mfd/rts5229.c b/drivers/mfd/rts5229.c
index 6353f5d..ace4538 100644
--- a/drivers/mfd/rts5229.c
+++ b/drivers/mfd/rts5229.c
@@ -38,7 +38,7 @@ static void rts5229_fetch_vendor_settings(struct rtsx_pcr
*pcr)
u32 reg;
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg);
- dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
+ pcr_dbg(pcr, Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
if (!rtsx_vendor_setting_valid(reg))
return;
@@ -50,7
Re: [PATCH v3 7/9] mfd: rtsx: add support for rts524A
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
add support for new chip rts524A.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/rts5249.c| 186
---
drivers/mfd/rtsx_pcr.c | 25 +-
drivers/mfd/rtsx_pcr.h | 7 ++
include/linux/mfd/rtsx_pci.h | 132 +-
4 files changed, 318 insertions(+), 32 deletions(-)
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 3c77058..32be803 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -65,15 +65,17 @@ static void rts5249_fill_driving(struct rtsx_pcr *pcr, u8
voltage)
0xFF, driving[drive_sel][2]);
}
-static void rts5249_fetch_vendor_settings(struct rtsx_pcr *pcr)
+static void rtsx_base_fetch_vendor_settings(struct rtsx_pcr *pcr)
{
u32 reg;
rtsx_pci_read_config_dword(pcr, PCR_SETTING_REG1, reg);
dev_dbg((pcr-pci-dev), Cfg 0x%x: 0x%x\n, PCR_SETTING_REG1, reg);
- if (!rtsx_vendor_setting_valid(reg))
+ if (!rtsx_vendor_setting_valid(reg)) {
+ pcr_dbg(pcr, skip fetch vendor setting\n);
return;
+ }
pcr-aspm_en = rtsx_reg_to_aspm(reg);
pcr-sd30_drive_sel_1v8 = rtsx_reg_to_sd30_drive_sel_1v8(reg);
@@ -87,7 +89,7 @@ static void rts5249_fetch_vendor_settings(struct rtsx_pcr
*pcr)
pcr-flags |= PCR_REVERSE_SOCKET;
}
-static void rts5249_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
+static void rtsx_base_force_power_down(struct rtsx_pcr *pcr, u8 pm_state)
{
/* Set relink_time to 0 */
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 1, 0xFF, 0);
@@ -95,7 +97,8 @@ static void rts5249_force_power_down(struct rtsx_pcr *pcr,
u8 pm_state)
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
if (pm_state == HOST_ENTER_S3)
- rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x10);
+ rtsx_pci_write_register(pcr, pcr-reg_pm_ctrl3,
+ D3_DELINK_MODE_EN, D3_DELINK_MODE_EN);
rtsx_pci_write_register(pcr, FPDCTL, 0x03, 0x03);
}
@@ -104,6 +107,8 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
{
rtsx_pci_init_cmd(pcr);
+ /* Rest L1SUB Config */
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, L1SUB_CONFIG3, 0xFF, 0x00);
/* Configure GPIO as output */
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, GPIO_CTL, 0x02, 0x02);
/* Reset ASPM state to default value */
@@ -189,27 +194,27 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
PHY_TUNE_TUNED12 | PHY_TUNE_TUNEA12);
}
-static int rts5249_turn_on_led(struct rtsx_pcr *pcr)
+static int rtsx_base_turn_on_led(struct rtsx_pcr *pcr)
{
return rtsx_pci_write_register(pcr, GPIO_CTL, 0x02, 0x02);
}
-static int rts5249_turn_off_led(struct rtsx_pcr *pcr)
+static int rtsx_base_turn_off_led(struct rtsx_pcr *pcr)
{
return rtsx_pci_write_register(pcr, GPIO_CTL, 0x02, 0x00);
}
-static int rts5249_enable_auto_blink(struct rtsx_pcr *pcr)
+static int rtsx_base_enable_auto_blink(struct rtsx_pcr *pcr)
{
return rtsx_pci_write_register(pcr, OLT_LED_CTL, 0x08, 0x08);
}
-static int rts5249_disable_auto_blink(struct rtsx_pcr *pcr)
+static int rtsx_base_disable_auto_blink(struct rtsx_pcr *pcr)
{
return rtsx_pci_write_register(pcr, OLT_LED_CTL, 0x08, 0x00);
}
-static int rts5249_card_power_on(struct rtsx_pcr *pcr, int card)
+static int rtsx_base_card_power_on(struct rtsx_pcr *pcr, int card)
{
int err;
@@ -236,7 +241,7 @@ static int rts5249_card_power_on(struct rtsx_pcr *pcr,
int card)
return 0;
}
-static int rts5249_card_power_off(struct rtsx_pcr *pcr, int card)
+static int rtsx_base_card_power_off(struct rtsx_pcr *pcr, int card)
{
rtsx_pci_init_cmd(pcr);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, CARD_PWR_CTL,
@@ -246,22 +251,35 @@ static int rts5249_card_power_off(struct rtsx_pcr *pcr,
int card)
return rtsx_pci_send_cmd(pcr, 100);
}
-static int rts5249_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+static int rtsx_base_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
{
int err;
+ u16 append;
- if (voltage == OUTPUT_3V3) {
- err = rtsx_pci_write_phy_register(pcr, PHY_TUNE, 0x4FC0 | 0x24);
+ switch (voltage) {
+ case OUTPUT_3V3:
+ err = rtsx_pci_update_phy(pcr, PHY_TUNE, PHY_TUNE_VOLTAGE_MASK,
+ PHY_TUNE_VOLTAGE_3V3);
if (err 0)
return err;
- } else if (voltage == OUTPUT_1V8) {
- err = rtsx_pci_write_phy_register(pcr, PHY_BACR, 0x3C02);
+ break;
+ case OUTPUT_1V8:
+ append = PHY_TUNE_D18_1V8
Re: [PATCH v3 8/9] mfd: rtsx: add support for rts525A
On Wed, 25 Feb 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
add support for new chip rts525A.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/rts5249.c| 103
+++
drivers/mfd/rtsx_pcr.c | 13 --
drivers/mfd/rtsx_pcr.h | 1 +
include/linux/mfd/rtsx_pci.h | 15 +++
4 files changed, 129 insertions(+), 3 deletions(-)
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 32be803..d1ff32f 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -487,3 +487,106 @@ void rts524a_init_params(struct rtsx_pcr *pcr)
pcr-ops = rts524a_pcr_ops;
}
+static int rts525a_card_power_on(struct rtsx_pcr *pcr, int card)
+{
+ rtsx_pci_write_register(pcr, LDO_VCC_CFG1,
+ LDO_VCC_TUNE_MASK, LDO_VCC_3V3);
+ return rtsx_base_card_power_on(pcr, card);
+}
+
+static int rts525a_switch_output_voltage(struct rtsx_pcr *pcr, u8 voltage)
+{
+ switch (voltage) {
+ case OUTPUT_3V3:
+ rtsx_pci_write_register(pcr, LDO_CONFIG2,
+ LDO_D3318_MASK, LDO_D3318_33V);
+ rtsx_pci_write_register(pcr, SD_PAD_CTL, SD_IO_USING_1V8, 0);
+ break;
+ case OUTPUT_1V8:
+ rtsx_pci_write_register(pcr, LDO_CONFIG2,
+ LDO_D3318_MASK, LDO_D3318_18V);
+ rtsx_pci_write_register(pcr, SD_PAD_CTL, SD_IO_USING_1V8,
+ SD_IO_USING_1V8);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ rtsx_pci_init_cmd(pcr);
+ rts5249_fill_driving(pcr, voltage);
+ return rtsx_pci_send_cmd(pcr, 100);
+}
+
+static int rts525a_optimize_phy(struct rtsx_pcr *pcr)
+{
+ int err;
+
+ err = rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3,
+ D3_DELINK_MODE_EN, 0x00);
+ if (err 0)
+ return err;
+
+ rtsx_pci_write_phy_register(pcr, _PHY_FLD0,
+ _PHY_FLD0_CLK_REQ_20C | _PHY_FLD0_RX_IDLE_EN |
+ _PHY_FLD0_BIT_ERR_RSTN | _PHY_FLD0_BER_COUNT |
+ _PHY_FLD0_BER_TIMER | _PHY_FLD0_CHECK_EN);
+
+ rtsx_pci_write_phy_register(pcr, _PHY_ANA03,
+ _PHY_ANA03_TIMER_MAX | _PHY_ANA03_OOBS_DEB_EN |
+ _PHY_CMU_DEBUG_EN);
+
+ if (is_version(pcr, 0x525A, IC_VER_A))
+ rtsx_pci_write_phy_register(pcr, _PHY_REV0,
+ _PHY_REV0_FILTER_OUT | _PHY_REV0_CDR_BYPASS_PFD |
+ _PHY_REV0_CDR_RX_IDLE_BYPASS);
+
+ return 0;
+}
+
+static int rts525a_extra_init_hw(struct rtsx_pcr *pcr)
+{
+ rts5249_extra_init_hw(pcr);
+
+ rtsx_pci_write_register(pcr, PCLK_CTL, PCLK_MODE_SEL, PCLK_MODE_SEL);
+ if (is_version(pcr, 0x525A, IC_VER_A)) {
+ rtsx_pci_write_register(pcr, L1SUB_CONFIG2,
+ L1SUB_AUTO_CFG, L1SUB_AUTO_CFG);
+ rtsx_pci_write_register(pcr, RREF_CFG,
+ RREF_VBGSEL_MASK, RREF_VBGSEL_1V25);
+ rtsx_pci_write_register(pcr, LDO_VIO_CFG,
+ LDO_VIO_TUNE_MASK, LDO_VIO_1V7);
+ rtsx_pci_write_register(pcr, LDO_DV12S_CFG,
+ LDO_D12_TUNE_MASK, LDO_D12_TUNE_DF);
+ rtsx_pci_write_register(pcr, LDO_AV12S_CFG,
+ LDO_AV12S_TUNE_MASK, LDO_AV12S_TUNE_DF);
+ rtsx_pci_write_register(pcr, LDO_VCC_CFG0,
+ LDO_VCC_LMTVTH_MASK, LDO_VCC_LMTVTH_2A);
+ rtsx_pci_write_register(pcr, OOBS_CONFIG,
+ OOBS_AUTOK_DIS | OOBS_VAL_MASK, 0x89);
+ }
+
+ return 0;
+}
+
+static const struct pcr_ops rts525a_pcr_ops = {
+ .fetch_vendor_settings = rtsx_base_fetch_vendor_settings,
+ .extra_init_hw = rts525a_extra_init_hw,
+ .optimize_phy = rts525a_optimize_phy,
+ .turn_on_led = rtsx_base_turn_on_led,
+ .turn_off_led = rtsx_base_turn_off_led,
+ .enable_auto_blink = rtsx_base_enable_auto_blink,
+ .disable_auto_blink = rtsx_base_disable_auto_blink,
+ .card_power_on = rts525a_card_power_on,
+ .card_power_off = rtsx_base_card_power_off,
+ .switch_output_voltage = rts525a_switch_output_voltage,
+ .force_power_down = rtsx_base_force_power_down,
+};
+
+void rts525a_init_params(struct rtsx_pcr *pcr)
+{
+ rts5249_init_params(pcr);
+
+ pcr-reg_pm_ctrl3 = RTS524A_PM_CTRL3;
+ pcr-ops = rts525a_pcr_ops;
+}
+
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index e6d97ad..433cb41 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -59,6 +59,7 @@ static const struct pci_device_id rtsx_pci_ids[] = {
{ PCI_DEVICE(0x10EC, 0x5287), PCI_CLASS_OTHERS 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5286), PCI_CLASS_OTHERS 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x524A), PCI_CLASS_OTHERS 16
Re: [RESEND PATCH v2 7/9] mfd: rtsx: add support for rts524A
On Wed, 25 Feb 2015, 敬锐 wrote:
On 02/16/2015 10:28 PM, Lee Jones wrote:
+static int rts524a_optimize_phy(struct rtsx_pcr *pcr)
+{
+ int err;
+
+ err = rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3,
+ D3_DELINK_MODE_EN, 0x00);
+ if (err 0)
+ return err;
+
+ rtsx_pci_write_phy_register(pcr, PHY_PCR,
+ PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 |
+ PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 | PHY_PCR_RSSI_EN);
+ rtsx_pci_write_phy_register(pcr, PHY_SSCCR3,
+ PHY_SSCCR3_STEP_IN | PHY_SSCCR3_CHECK_DELAY);
+
+ if (is_version(pcr, 0x524A, IC_VER_A)) {
+ rtsx_pci_write_phy_register(pcr, PHY_SSCCR3,
+ PHY_SSCCR3_STEP_IN | PHY_SSCCR3_CHECK_DELAY);
+ rtsx_pci_write_phy_register(pcr, PHY_SSCCR2,
+ PHY_SSCCR2_PLL_NCODE | PHY_SSCCR2_TIME0 |
+ PHY_SSCCR2_TIME2_WIDTH);
+ rtsx_pci_write_phy_register(pcr, PHY_ANA1A,
+ PHY_ANA1A_TXR_LOOPBACK | PHY_ANA1A_RXT_BIST |
+ PHY_ANA1A_TXR_BIST | PHY_ANA1A_REV);
+ rtsx_pci_write_phy_register(pcr, PHY_ANA1D,
+ PHY_ANA1D_DEBUG_ADDR);
+ rtsx_pci_write_phy_register(pcr, PHY_DIG1E,
+ PHY_DIG1E_REV | PHY_DIG1E_D0_X_D1 |
+ PHY_DIG1E_RX_ON_HOST | PHY_DIG1E_RCLK_REF_HOST |
+ PHY_DIG1E_RCLK_TX_EN_KEEP |
+ PHY_DIG1E_RCLK_TX_TERM_KEEP |
+ PHY_DIG1E_RCLK_RX_EIDLE_ON | PHY_DIG1E_TX_TERM_KEEP |
+ PHY_DIG1E_RX_TERM_KEEP | PHY_DIG1E_TX_EN_KEEP |
+ PHY_DIG1E_RX_EN_KEEP);
+ }
+
+ rtsx_pci_write_phy_register(pcr, PHY_ANA08,
+ PHY_ANA08_RX_EQ_DCGAIN | PHY_ANA08_SEL_RX_EN |
+ PHY_ANA08_RX_EQ_VAL | PHY_ANA08_SCP | PHY_ANA08_SEL_IPI);
To the uninitiated this function is mostly randomness. How about some
nice comments to illuminate?
I'm not clear with these setting either, it is used to fix some phy
setting, the default phy setting
it not stable on some special platform, so we have to modify them by driver,
newer version of chip will change its default value to more stable
configure, so some value is
no need to setting for Version B/C...
That doesn't help me in any way. Use the datasheet, look-up the
values and insert a nice, succinct explanation of what you're doing
and why it's required please.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH v2 5/9] mfd: rtsx: update phy register
On Thu, 22 Jan 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn update phy register value and using direct value instead of macros. It is much easier to debug using constant value than a lot of macros. We usually need compare the value directly to check the configure. This is no longer an adequate description of the patch. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- drivers/mfd/rts5249.c| 55 -- include/linux/mfd/rtsx_pci.h | 109 ++- 2 files changed, 85 insertions(+), 79 deletions(-) diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c index 2fe2854..d8072f6 100644 --- a/drivers/mfd/rts5249.c +++ b/drivers/mfd/rts5249.c @@ -132,57 +132,62 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr) if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV, - PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED | - PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN | - PHY_REG_REV_RX_PWST | PHY_REG_REV_CLKREQ_DLY_TIMER_1_0 | - PHY_REG_REV_STOP_CLKRD | PHY_REG_REV_STOP_CLKWR); + err = rtsx_pci_write_phy_register(pcr, PHY_REV, + PHY_REV_RESV | PHY_REV_RXIDLE_LATCHED | + PHY_REV_P1_EN | PHY_REV_RXIDLE_EN | + PHY_REV_CLKREQ_TX_EN | PHY_REV_RX_PWST | + PHY_REV_CLKREQ_DT_1_0 | PHY_REV_STOP_CLKRD | + PHY_REV_STOP_CLKWR); The tabbing changes make it difficult to see what you're _really_ doing. If you think the tabs are important (I think they were better before personally), then send them as a separate patch. if (err 0) return err; msleep(1); err = rtsx_pci_write_phy_register(pcr, PHY_BPCR, - PHY_BPCR_IBRXSEL | PHY_BPCR_IBTXSEL | - PHY_BPCR_IB_FILTER | PHY_BPCR_CMIRROR_EN); + PHY_BPCR_IBRXSEL | PHY_BPCR_IBTXSEL | + PHY_BPCR_IB_FILTER | PHY_BPCR_CMIRROR_EN); More nonsense? if (err 0) return err; + err = rtsx_pci_write_phy_register(pcr, PHY_PCR, - PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 | - PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 | - PHY_PCR_RSSI_EN); + PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 | + PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 | + PHY_PCR_RSSI_EN | PHY_PCR_RX10K); Etc. I'm going to stop here. Please resubmit this patch properly. [...] -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH v2 6/9] mfd: rtsx: remove LCTLR defination
On Thu, 22 Jan 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn To enable/disable ASPM we should find LINK CONTROL register in PCI config space. All old chip use 0x80 address, but new chip may use another address, so we using pci_find_capability() to get LINK CONTROL address. rtsx_gops.c was removed, we consider to put some common operations to this file, but the actual thing is, only a group of chips are in common ops1, and another group of chips in common ops2, it is hard to decide put which ops into generic ops file. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- drivers/mfd/Makefile | 2 +- drivers/mfd/rts5227.c| 2 +- drivers/mfd/rts5249.c| 3 +-- drivers/mfd/rtsx_gops.c | 37 - drivers/mfd/rtsx_pcr.c | 22 +- include/linux/mfd/rtsx_pci.h | 10 +- 6 files changed, 21 insertions(+), 55 deletions(-) delete mode 100644 drivers/mfd/rtsx_gops.c Acked-by: Lee Jones lee.jo...@linaro.org -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH v2 7/9] mfd: rtsx: add support for rts524A
0x001F
+#define PHY_SSCCR2 0x02
+#define PHY_SSCCR2_PLL_NCODE 0x0A00
+#define PHY_SSCCR2_TIME0 0x001C
+#define PHY_SSCCR2_TIME2_WIDTH 0x0003
#define PHY_RCR2 0x03
#define PHY_RCR2_EMPHASE_EN0x8000
@@ -649,6 +724,9 @@
#define PHY_RCR2_FREQSEL_120x0040
#define PHY_RCR2_CDR_SC_12P0x0010
#define PHY_RCR2_CALIB_LATE0x0002
+#define PHY_SSCCR3 0x03
+#define PHY_SSCCR3_STEP_IN 0x2740
+#define PHY_SSCCR3_CHECK_DELAY 0x0008
#define PHY_RTCR 0x04
#define PHY_RDR 0x05
@@ -663,6 +741,12 @@
#define PHY_TUNE_TUNED18 0x01C0
#define PHY_TUNE_TUNED12 0X0020
#define PHY_TUNE_TUNEA12 0x0004
+#define PHY_ANA080x08
+#define PHY_ANA08_RX_EQ_DCGAIN 0x5000
+#define PHY_ANA08_SEL_RX_EN0x0400
+#define PHY_ANA08_RX_EQ_VAL0x03C0
+#define PHY_ANA08_SCP 0x0020
+#define PHY_ANA08_SEL_IPI 0x0004
#define PHY_IMR 0x09
#define PHY_BPCR 0x0A
@@ -698,12 +782,19 @@
#define PHY_REV_STOP_CLKWR 0x0004
#define PHY_FLD0 0x1A
+#define PHY_ANA1A0x1A
+#define PHY_ANA1A_TXR_LOOPBACK 0x2000
+#define PHY_ANA1A_RXT_BIST 0x0500
+#define PHY_ANA1A_TXR_BIST 0x0040
+#define PHY_ANA1A_REV 0x0006
#define PHY_FLD1 0x1B
#define PHY_FLD2 0x1C
#define PHY_FLD3 0x1D
#define PHY_FLD3_TIMER_4 0x0800
#define PHY_FLD3_TIMER_6 0x0020
#define PHY_FLD3_RXDELINK 0x0004
+#define PHY_ANA1D0x1D
+#define PHY_ANA1D_DEBUG_ADDR 0x0004
#define PHY_FLD4 0x1E
#define PHY_FLD4_FLDEN_SEL 0x4000
@@ -713,7 +804,18 @@
#define PHY_FLD4_BER_COUNT 0x00E0
#define PHY_FLD4_BER_TIMER 0x000A
#define PHY_FLD4_BER_CHK_EN0x0001
-
+#define PHY_DIG1E0x1E
+#define PHY_DIG1E_REV 0x4000
+#define PHY_DIG1E_D0_X_D1 0x1000
+#define PHY_DIG1E_RX_ON_HOST 0x0800
+#define PHY_DIG1E_RCLK_REF_HOST0x0400
+#define PHY_DIG1E_RCLK_TX_EN_KEEP 0x0040
+#define PHY_DIG1E_RCLK_TX_TERM_KEEP0x0020
+#define PHY_DIG1E_RCLK_RX_EIDLE_ON 0x0010
+#define PHY_DIG1E_TX_TERM_KEEP 0x0008
+#define PHY_DIG1E_RX_TERM_KEEP 0x0004
+#define PHY_DIG1E_TX_EN_KEEP 0x0002
+#define PHY_DIG1E_RX_EN_KEEP 0x0001
#define PHY_DUM_REG 0x1F
#define PCR_SETTING_REG1 0x724
@@ -729,6 +831,8 @@ struct pcr_handle {
};
struct pcr_ops {
+ int (*write_phy)(struct rtsx_pcr *pcr, u8 addr, u16 val);
+ int (*read_phy)(struct rtsx_pcr *pcr, u8 addr, u16 *val);
int (*extra_init_hw)(struct rtsx_pcr *pcr);
int (*optimize_phy)(struct rtsx_pcr *pcr);
int (*turn_on_led)(struct rtsx_pcr *pcr);
@@ -830,6 +934,10 @@ struct rtsx_pcr {
#define CHK_PCI_PID(pcr, pid)((pcr)-pci-device == (pid))
#define PCI_VID(pcr) ((pcr)-pci-vendor)
#define PCI_PID(pcr) ((pcr)-pci-device)
+#define is_version(pcr, pid, ver)\
+ (CHK_PCI_PID(pcr, pid) (pcr)-ic_version == (ver))
+#define pcr_dbg(pcr, fmt, arg...)\
+ dev_dbg((pcr)-pci-dev, fmt, ##arg)
#define SDR104_PHASE(val)((val) 0xFF)
#define SDR50_PHASE(val) (((val) 8) 0xFF)
@@ -899,4 +1007,17 @@ static inline void rtsx_pci_write_be32(struct rtsx_pcr
*pcr, u16 reg, u32 val)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
}
+static inline int rtsx_pci_update_phy(struct rtsx_pcr *pcr, u8 addr,
+ u16 mask, u16 append)
+{
+ int err;
+ u16 val;
+
+ err = rtsx_pci_read_phy_register(pcr, addr, val);
+ if (err 0)
+ return err;
+
+ return rtsx_pci_write_phy_register(pcr, addr, (val mask) | append);
+}
Why is this in here?
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH v2 8/9] mfd: rtsx: add support for rts525A
On Thu, 22 Jan 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
add support for new chip rts525A.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/rts5249.c| 104
++-
drivers/mfd/rtsx_pcr.c | 13 --
drivers/mfd/rtsx_pcr.h | 1 +
include/linux/mfd/rtsx_pci.h | 15 +++
4 files changed, 129 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 97dde92..134e03f 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -97,7 +97,7 @@ static void rtsx_base_force_power_down(struct rtsx_pcr
*pcr, u8 pm_state)
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
if (pm_state == HOST_ENTER_S3) {
- if (PCI_PID(pcr) == 0x524A)
+ if (PCI_PID(pcr) == 0x524A || PCI_PID(pcr) == 0x525A)
Please consider holding a pm_ctrl_reg attribute in the device data
structure, then only doing this once during initialisation.
Other than that, I have the same comments as before.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [RESEND PATCH v2 7/9] mfd: rtsx: add support for rts524A
0x001C
+#define PHY_SSCCR2_TIME2_WIDTH 0x0003
#define PHY_RCR2 0x03
#define PHY_RCR2_EMPHASE_EN 0x8000
@@ -649,6 +724,9 @@
#define PHY_RCR2_FREQSEL_12 0x0040
#define PHY_RCR2_CDR_SC_12P 0x0010
#define PHY_RCR2_CALIB_LATE 0x0002
+#define PHY_SSCCR3 0x03
+#define PHY_SSCCR3_STEP_IN 0x2740
+#define PHY_SSCCR3_CHECK_DELAY 0x0008
#define PHY_RTCR 0x04
#define PHY_RDR 0x05
@@ -663,6 +741,12 @@
#define PHY_TUNE_TUNED180x01C0
#define PHY_TUNE_TUNED120X0020
#define PHY_TUNE_TUNEA120x0004
+#define PHY_ANA08 0x08
+#define PHY_ANA08_RX_EQ_DCGAIN 0x5000
+#define PHY_ANA08_SEL_RX_EN 0x0400
+#define PHY_ANA08_RX_EQ_VAL 0x03C0
+#define PHY_ANA08_SCP0x0020
+#define PHY_ANA08_SEL_IPI0x0004
#define PHY_IMR 0x09
#define PHY_BPCR 0x0A
@@ -698,12 +782,19 @@
#define PHY_REV_STOP_CLKWR 0x0004
#define PHY_FLD0 0x1A
+#define PHY_ANA1A 0x1A
+#define PHY_ANA1A_TXR_LOOPBACK 0x2000
+#define PHY_ANA1A_RXT_BIST 0x0500
+#define PHY_ANA1A_TXR_BIST 0x0040
+#define PHY_ANA1A_REV0x0006
#define PHY_FLD1 0x1B
#define PHY_FLD2 0x1C
#define PHY_FLD3 0x1D
#define PHY_FLD3_TIMER_40x0800
#define PHY_FLD3_TIMER_60x0020
#define PHY_FLD3_RXDELINK 0x0004
+#define PHY_ANA1D 0x1D
+#define PHY_ANA1D_DEBUG_ADDR 0x0004
#define PHY_FLD4 0x1E
#define PHY_FLD4_FLDEN_SEL 0x4000
@@ -713,7 +804,18 @@
#define PHY_FLD4_BER_COUNT 0x00E0
#define PHY_FLD4_BER_TIMER 0x000A
#define PHY_FLD4_BER_CHK_EN 0x0001
-
+#define PHY_DIG1E 0x1E
+#define PHY_DIG1E_REV0x4000
+#define PHY_DIG1E_D0_X_D10x1000
+#define PHY_DIG1E_RX_ON_HOST 0x0800
+#define PHY_DIG1E_RCLK_REF_HOST 0x0400
+#define PHY_DIG1E_RCLK_TX_EN_KEEP0x0040
+#define PHY_DIG1E_RCLK_TX_TERM_KEEP 0x0020
+#define PHY_DIG1E_RCLK_RX_EIDLE_ON 0x0010
+#define PHY_DIG1E_TX_TERM_KEEP 0x0008
+#define PHY_DIG1E_RX_TERM_KEEP 0x0004
+#define PHY_DIG1E_TX_EN_KEEP 0x0002
+#define PHY_DIG1E_RX_EN_KEEP 0x0001
#define PHY_DUM_REG 0x1F
#define PCR_SETTING_REG1 0x724
@@ -729,6 +831,8 @@ struct pcr_handle {
};
struct pcr_ops {
+ int (*write_phy)(struct rtsx_pcr *pcr, u8 addr, u16 val);
+ int (*read_phy)(struct rtsx_pcr *pcr, u8 addr, u16 *val);
int (*extra_init_hw)(struct rtsx_pcr *pcr);
int (*optimize_phy)(struct rtsx_pcr *pcr);
int (*turn_on_led)(struct rtsx_pcr *pcr);
@@ -830,6 +934,10 @@ struct rtsx_pcr {
#define CHK_PCI_PID(pcr, pid) ((pcr)-pci-device == (pid))
#define PCI_VID(pcr) ((pcr)-pci-vendor)
#define PCI_PID(pcr) ((pcr)-pci-device)
+#define is_version(pcr, pid, ver) \
+ (CHK_PCI_PID(pcr, pid) (pcr)-ic_version == (ver))
+#define pcr_dbg(pcr, fmt, arg...) \
+ dev_dbg((pcr)-pci-dev, fmt, ##arg)
#define SDR104_PHASE(val) ((val) 0xFF)
#define SDR50_PHASE(val) (((val) 8) 0xFF)
@@ -899,4 +1007,17 @@ static inline void rtsx_pci_write_be32(struct
rtsx_pcr *pcr, u16 reg, u32 val)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
}
+static inline int rtsx_pci_update_phy(struct rtsx_pcr *pcr, u8 addr,
+ u16 mask, u16 append)
+{
+ int err;
+ u16 val;
+
+ err = rtsx_pci_read_phy_register(pcr, addr, val);
+ if (err 0)
+ return err;
+
+ return rtsx_pci_write_phy_register(pcr, addr, (val mask) | append);
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 0/9] mfd: rtsx: add support for new rts524A and rts525A
Have you reworked all of these patches? If not, why haven't my Acks been carried forward? Please [RESEND] with the Acks applied. From: Micky Ching micky_ch...@realsil.com.cn v2: - remove debug info when access failed. - using macro list for phy register init. - rename function for multi chip prefix with rtsx_base_ - save pcie_cap offset when init chip, not calling pci_find_capacity() every time. - add pcr-ops: write_phy/read_phy for special chip. This patchset including re-format some coding-style and add two new chip rts524A and rts525A. Micky Ching (9): mfd: rtsx: replace TAB by SPC after #define mfd: rtsx: place register address and values togather mfd: rtsx: update PETXCFG address mfd: rtsx: update driving settings mfd: rtsx: update phy register mfd: rtsx: remove LCTLR defination mfd: rtsx: add support for rts524A mfd: rtsx: add support for rts525A mfd: rtsx: using pcr_dbg replace dev_dbg drivers/mfd/Makefile |2 +- drivers/mfd/rtl8411.c| 11 +- drivers/mfd/rts5209.c|4 +- drivers/mfd/rts5227.c| 12 +- drivers/mfd/rts5229.c|4 +- drivers/mfd/rts5249.c| 368 +++--- drivers/mfd/rtsx_gops.c | 37 -- drivers/mfd/rtsx_pcr.c | 110 +++-- drivers/mfd/rtsx_pcr.h |8 + include/linux/mfd/rtsx_pci.h | 1109 ++ 10 files changed, 966 insertions(+), 699 deletions(-) delete mode 100644 drivers/mfd/rtsx_gops.c -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 06/10] mfd: rtsx: update phy register
On Tue, 20 Jan 2015, 敬锐 wrote: On 01/19/2015 03:47 PM, Lee Jones wrote: On Mon, 19 Jan 2015, 敬锐 wrote: On 01/18/2015 08:29 PM, Lee Jones wrote: On Thu, 15 Jan 2015,micky_ch...@realsil.com.cn wrote: From: Micky Chingmicky_ch...@realsil.com.cn update phy register value and using direct value instead of macros. It is much easier to debug using constant value than a lot of macros. We usually need compare the value directly to check the configure. NACK. This is the opposite of what I would like to see. When we debug, we usually need to compare the value provided from hardware, of course we can compare by print them to kernel log. but I think it more convenient from source code. And we only set phy register when initialize chip, so the value will not scattered everywhere, we will not benefit from macros. if we want to know the meaning of setting, we can look at the register define. This is not acceptable and is the complete opposite of what we're trying to achieve. I promote readability (by humans) as one of the highest priorities when writing code. 0xFE6C is far from readable. Because the truly thing we concerned is the address and value, not a lot of macros. 0xFE6C is a magic number, but a lot of macros even hide the magic number we curious. To verify if the source code is right, we only need to compare the value, if too much macros joined together, the work is boring and easy to inject errors. I completely disagree and think the converse to be true. It's _much_ easier to get the magic number incorrect. I hate magic number too, but in this case using magic number is deserved for correctness. Two method can help enhance readability. (1). define register address and values If we want to know what the bit field means, we can jump to the register define. This is very easy by tag system. eg. rtsx_pci_write_phy_register(pcr, PHY_BPCR, 0x05C0); we can jump to PHY_BPCR to see bit-field define. (2). add comment for magic number. I don't like comment. If you still like macro list, I will update the register next patch. Defining register values and bit fields is the _correct_ way to do this. Using magic numbers is the _wrong_ way. I'm sorry Micky, but I am not moving on this. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 1/6] mfd: rtsx: add func to split u32 into register
On Tue, 23 Dec 2014, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Add helper function to write u32 to registers, if we want to put u32
value to 4 continuous register, this can help us reduce tedious work.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
Acked-by: Lee Jones lee.jo...@linaro.org
---
include/linux/mfd/rtsx_pci.h | 9 +
1 file changed, 9 insertions(+)
Applied, thanks.
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..9234449 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -558,6 +558,7 @@
#define SD_SAMPLE_POINT_CTL 0xFDA7
#define SD_PUSH_POINT_CTL0xFDA8
#define SD_CMD0 0xFDA9
+#define SD_CMD_START 0x40
#define SD_CMD1 0xFDAA
#define SD_CMD2 0xFDAB
#define SD_CMD3 0xFDAC
@@ -967,4 +968,12 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr
*pcr)
return (u8 *)(pcr-host_cmds_ptr);
}
+static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32
val)
+{
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val 24);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val 16);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val 8);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] mfd: rtsx_usb: Fix runtime PM deadlock
On Tue, 20 Jan 2015, Roger Tseng wrote: On Mon, 2015-01-19 at 09:45 +, Lee Jones wrote: On Thu, 15 Jan 2015, Roger Tseng wrote: sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the device is awake while initializing a newly inserted card. Once it is called during suspending state and explicitly before rtsx_usb_suspend() acquires the same dev_mutex, both routine deadlock and further hang the driver because pm_runtime_get_sync() waits the pending PM operations. Fix this by using an empty suspend method. mmc_core always turns the LED off after a request is done and thus it is ok to remove the only rtsx_usb_turn_off_led() here. Cc: sta...@vger.kernel.org # v3.16+ Fixes: 730876be2566 (mfd: Add realtek USB card reader driver) Signed-off-by: Roger Tseng rogera...@realtek.com --- drivers/mfd/rtsx_usb.c | 9 - 1 file changed, 9 deletions(-) Applied, thanks. I'm sorry but build bot from Intel just reported me that I forgot to delete an unused variable ucr between two commits. My bad. Do I have a chance to send v2? You're lucky I'm in a good mood. ;) I fixed it already. diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c index dbdd0faeb6ce..076694126e5d 100644 --- a/drivers/mfd/rtsx_usb.c +++ b/drivers/mfd/rtsx_usb.c @@ -687,15 +687,6 @@ static int rtsx_usb_suspend(struct usb_interface *intf, pm_message_t message) dev_dbg(intf-dev, %s called with pm message 0x%04x\n, __func__, message.event); - /* - * Call to make sure LED is off during suspend to save more power. - * It is NOT a permanent state and could be turned on anytime later. - * Thus no need to call turn_on when resunming. - */ - mutex_lock(ucr-dev_mutex); - rtsx_usb_turn_off_led(ucr); - mutex_unlock(ucr-dev_mutex); - return 0; } -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v5 1/6] mfd: rtsx: add func to split u32 into register
On Tue, 20 Jan 2015, Ulf Hansson wrote:
On 20 January 2015 at 15:47, Lee Jones lee.jo...@linaro.org wrote:
On Tue, 23 Dec 2014, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Add helper function to write u32 to registers, if we want to put u32
value to 4 continuous register, this can help us reduce tedious work.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
Acked-by: Lee Jones lee.jo...@linaro.org
---
include/linux/mfd/rtsx_pci.h | 9 +
1 file changed, 9 insertions(+)
Applied, thanks.
This one has already been queued by you, for 3.19, and it's in Linus tree. :-)
For your reference, I have queued the mmc patches which depends on
$subject patch for 3.20.
I discovered this myself when I attempted to apply it. :)
Thanks for the heads-up though.
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..9234449 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -558,6 +558,7 @@
#define SD_SAMPLE_POINT_CTL 0xFDA7
#define SD_PUSH_POINT_CTL0xFDA8
#define SD_CMD0 0xFDA9
+#define SD_CMD_START 0x40
#define SD_CMD1 0xFDAA
#define SD_CMD2 0xFDAB
#define SD_CMD3 0xFDAC
@@ -967,4 +968,12 @@ static inline u8 *rtsx_pci_get_cmd_data(struct
rtsx_pcr *pcr)
return (u8 *)(pcr-host_cmds_ptr);
}
+static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32
val)
+{
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val 24);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val 16);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val 8);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/10] mfd: rtsx: remove LCTLR defination
On Mon, 19 Jan 2015, 敬锐 wrote:
On 01/18/2015 08:28 PM, Lee Jones wrote:
On Thu, 15 Jan 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
To enable/disable ASPM we should find LINK CONTROL register
in PCI config space. All old chip use 0x80 address, but new
chip may use another address, so we using pci_find_capability()
to get LINK CONTROL address.
rtsx_gops.c was removed, we consider to put some common operations
to this file, but the actual thing is, only a group of chips
are in common ops1, and another group of chips in common ops2,
it is hard to decide put which ops into generic ops file.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/Makefile | 2 +-
drivers/mfd/rts5227.c| 2 +-
drivers/mfd/rts5249.c| 3 +--
drivers/mfd/rtsx_gops.c | 37 -
drivers/mfd/rtsx_pcr.c | 25 -
include/linux/mfd/rtsx_pci.h | 9 -
6 files changed, 23 insertions(+), 55 deletions(-)
delete mode 100644 drivers/mfd/rtsx_gops.c
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..2cd7e74 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -13,7 +13,7 @@ obj-$(CONFIG_MFD_CROS_EC)+= cros_ec.o
obj-$(CONFIG_MFD_CROS_EC_I2C)+= cros_ec_i2c.o
obj-$(CONFIG_MFD_CROS_EC_SPI)+= cros_ec_spi.o
-rtsx_pci-objs := rtsx_pcr.o rtsx_gops.o rts5209.o
rts5229.o rtl8411.o rts5227.o rts5249.o
+rtsx_pci-objs := rtsx_pcr.o rts5209.o rts5229.o
rtl8411.o rts5227.o rts5249.o
obj-$(CONFIG_MFD_RTSX_PCI) += rtsx_pci.o
obj-$(CONFIG_MFD_RTSX_USB) += rtsx_usb.o
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 1f387d4..0c02831 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -130,7 +130,7 @@ static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
{
int err;
- err = rtsx_gops_pm_reset(pcr);
+ err = rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
if (err 0)
return err;
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 00208d1..5eb9819 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -119,7 +119,6 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0xB0);
else
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0x80);
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00);
What's this doing? Why is it not required anymore?
PM_CTRL3 have been set in rts5249_optimize_phy, this function
rts5249_extra_init will be call for rts524A/rts525A, but their PM_CTRL3
address is redefined to RTS524A_PM_CTRL3, using a different address.
if we set PM_CTRL3 here, the rts524A/rts525A will also set,
but it's not a right address.
Okay.
return rtsx_pci_send_cmd(pcr, 100);
}
@@ -128,7 +127,7 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
{
int err;
- err = rtsx_gops_pm_reset(pcr);
+ err = rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
if (err 0)
return err;
diff --git a/drivers/mfd/rtsx_gops.c b/drivers/mfd/rtsx_gops.c
deleted file mode 100644
index b1a98c6..000
--- a/drivers/mfd/rtsx_gops.c
+++ /dev/null
@@ -1,37 +0,0 @@
-/* Driver for Realtek PCI-Express card reader
- *
- * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the
- * Free Software Foundation; either version 2, or (at your option) any
- * later version.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License along
- * with this program; if not, see http://www.gnu.org/licenses/.
- *
- * Author:
- * Micky Ching micky_ch...@realsil.com.cn
- */
-
-#include linux/mfd/rtsx_pci.h
-#include rtsx_pcr.h
-
-int rtsx_gops_pm_reset(struct rtsx_pcr *pcr)
-{
- int err;
-
- /* init aspm */
- rtsx_pci_write_register(pcr, ASPM_FORCE_CTL, 0xFF, 0x00);
- err = rtsx_pci_update_cfg_byte(pcr, LCTLR, ~LCTLR_ASPM_CTL_MASK, 0x00);
- if (err 0)
- return err;
-
- /* reset PM_CTRL3 before send buffer cmd */
- return rtsx_pci_write_register(pcr, PM_CTRL3, D3_DELINK_MODE_EN, 0x00);
-}
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 92f5a41..3065edc 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b
Re: [PATCH 1/2] mfd: rtsx_usb: Fix runtime PM deadlock
On Thu, 15 Jan 2015, Roger Tseng wrote: sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the device is awake while initializing a newly inserted card. Once it is called during suspending state and explicitly before rtsx_usb_suspend() acquires the same dev_mutex, both routine deadlock and further hang the driver because pm_runtime_get_sync() waits the pending PM operations. Fix this by using an empty suspend method. mmc_core always turns the LED off after a request is done and thus it is ok to remove the only rtsx_usb_turn_off_led() here. Cc: sta...@vger.kernel.org # v3.16+ Fixes: 730876be2566 (mfd: Add realtek USB card reader driver) Signed-off-by: Roger Tseng rogera...@realtek.com --- drivers/mfd/rtsx_usb.c | 9 - 1 file changed, 9 deletions(-) Applied, thanks. diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c index dbdd0faeb6ce..076694126e5d 100644 --- a/drivers/mfd/rtsx_usb.c +++ b/drivers/mfd/rtsx_usb.c @@ -687,15 +687,6 @@ static int rtsx_usb_suspend(struct usb_interface *intf, pm_message_t message) dev_dbg(intf-dev, %s called with pm message 0x%04x\n, __func__, message.event); - /* - * Call to make sure LED is off during suspend to save more power. - * It is NOT a permanent state and could be turned on anytime later. - * Thus no need to call turn_on when resunming. - */ - mutex_lock(ucr-dev_mutex); - rtsx_usb_turn_off_led(ucr); - mutex_unlock(ucr-dev_mutex); - return 0; } -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 2/2] mfd: rtsx_usb: Defer autosuspend while card exists
On Thu, 15 Jan 2015, Roger Tseng wrote:
A card insertion happens after the lastest polling before reader is
suspended may never have a chance to be detected. Under current 1-HZ
polling interval setting in mmc_core, the worst case of such
undetectablility is about 1 second.
To further reduce the undetectability, detect card slot again in suspend
method and defer the autosuspend if the slot is loaded. The default 2
second autosuspend delay of USB subsystem should let the next polling
detects the card.
Signed-off-by: Roger Tseng rogera...@realtek.com
---
drivers/mfd/rtsx_usb.c | 14 ++
1 file changed, 14 insertions(+)
Applied, thanks.
diff --git a/drivers/mfd/rtsx_usb.c b/drivers/mfd/rtsx_usb.c
index 076694126e5d..63883fd025c0 100644
--- a/drivers/mfd/rtsx_usb.c
+++ b/drivers/mfd/rtsx_usb.c
@@ -687,6 +687,20 @@ static int rtsx_usb_suspend(struct usb_interface *intf,
pm_message_t message)
dev_dbg(intf-dev, %s called with pm message 0x%04x\n,
__func__, message.event);
+ if (PMSG_IS_AUTO(message)) {
+ if (mutex_trylock(ucr-dev_mutex)) {
+ rtsx_usb_get_card_status(ucr, val);
+ mutex_unlock(ucr-dev_mutex);
+
+ /* Defer the autosuspend if card exists */
+ if (val (SD_CD | MS_CD))
+ return -EAGAIN;
+ } else {
+ /* There is an ongoing operation*/
+ return -EAGAIN;
+ }
+ }
+
return 0;
}
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 06/10] mfd: rtsx: update phy register
On Mon, 19 Jan 2015, 敬锐 wrote: On 01/18/2015 08:29 PM, Lee Jones wrote: On Thu, 15 Jan 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn update phy register value and using direct value instead of macros. It is much easier to debug using constant value than a lot of macros. We usually need compare the value directly to check the configure. NACK. This is the opposite of what I would like to see. When we debug, we usually need to compare the value provided from hardware, of course we can compare by print them to kernel log. but I think it more convenient from source code. And we only set phy register when initialize chip, so the value will not scattered everywhere, we will not benefit from macros. if we want to know the meaning of setting, we can look at the register define. This is not acceptable and is the complete opposite of what we're trying to achieve. I promote readability (by humans) as one of the highest priorities when writing code. 0xFE6C is far from readable. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- drivers/mfd/rts5249.c | 46 ++ 1 file changed, 14 insertions(+), 32 deletions(-) diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c index 2fe2854..00208d1 100644 --- a/drivers/mfd/rts5249.c +++ b/drivers/mfd/rts5249.c @@ -132,57 +132,39 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr) if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV, - PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED | - PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN | - PHY_REG_REV_RX_PWST | PHY_REG_REV_CLKREQ_DLY_TIMER_1_0 | - PHY_REG_REV_STOP_CLKRD | PHY_REG_REV_STOP_CLKWR); + err = rtsx_pci_write_phy_register(pcr, 0x19, 0xFE6C); if (err 0) return err; msleep(1); - err = rtsx_pci_write_phy_register(pcr, PHY_BPCR, - PHY_BPCR_IBRXSEL | PHY_BPCR_IBTXSEL | - PHY_BPCR_IB_FILTER | PHY_BPCR_CMIRROR_EN); + err = rtsx_pci_write_phy_register(pcr, 0x0A, 0x05C0); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_PCR, - PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 | - PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 | - PHY_PCR_RSSI_EN); + + err = rtsx_pci_write_phy_register(pcr, 0x00, 0xBA43); + if (err 0) + return err; + err = rtsx_pci_write_phy_register(pcr, 0x03, 0xC152); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_RCR2, - PHY_RCR2_EMPHASE_EN | PHY_RCR2_NADJR | - PHY_RCR2_CDR_CP_10 | PHY_RCR2_CDR_SR_2 | - PHY_RCR2_FREQSEL_12 | PHY_RCR2_CPADJEN | - PHY_RCR2_CDR_SC_8 | PHY_RCR2_CALIB_LATE); + err = rtsx_pci_write_phy_register(pcr, 0x1E, 0x78EB); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_FLD4, - PHY_FLD4_FLDEN_SEL | PHY_FLD4_REQ_REF | - PHY_FLD4_RXAMP_OFF | PHY_FLD4_REQ_ADDA | - PHY_FLD4_BER_COUNT | PHY_FLD4_BER_TIMER | - PHY_FLD4_BER_CHK_EN); + err = rtsx_pci_write_phy_register(pcr, 0x05, 0x4600); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_RDR, PHY_RDR_RXDSEL_1_9); + err = rtsx_pci_write_phy_register(pcr, 0x02, 0x041F); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_RCR1, - PHY_RCR1_ADP_TIME | PHY_RCR1_VCO_COARSE); + err = rtsx_pci_write_phy_register(pcr, 0x1D, 0x0824); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_FLD3, - PHY_FLD3_TIMER_4 | PHY_FLD3_TIMER_6 | - PHY_FLD3_RXDELINK); + err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4FE4); if (err 0) return err; - return rtsx_pci_write_phy_register(pcr, PHY_TUNE, - PHY_TUNE_TUNEREF_1_0 | PHY_TUNE_VBGSEL_1252 | - PHY_TUNE_SDBUS_33 | PHY_TUNE_TUNED18 | - PHY_TUNE_TUNED12); + + return 0; } static int rts5249_turn_on_led(struct rtsx_pcr *pcr) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 08/10] mfd: rtsx: add support for rts524A
On Mon, 19 Jan 2015, 敬锐 wrote:
On 01/18/2015 08:20 PM, Lee Jones wrote:
+static int rts524a_optimize_phy(struct rtsx_pcr *pcr)
+{
+ int err;
+
+ err = rtsx_pci_write_register(pcr, RTS524A_PM_CTRL3,
+ D3_DELINK_MODE_EN, 0x00);
+ if (err 0)
+ return err;
if (err)
err value will never be positive, but I have to make it consistence
with driver in other place, because all the check using if (err 0) form.
Then all of them should be changed.
And maybe, it make reserved for future the function may return positive
value.
I'd prefer not to live in the world of 'what if'. I think only
checking for a less than zero error value insinuates that a greater
than zero return is acceptable, but in this case is it not.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 09/10] mfd: rtsx: add support for rts525A
On Mon, 19 Jan 2015, 敬锐 wrote:
On 01/18/2015 07:13 PM, Lee Jones wrote:
@@ -97,7 +97,7 @@ static void rts5249_force_power_down(struct rtsx_pcr
*pcr, u8 pm_state)
rtsx_pci_write_register(pcr, AUTOLOAD_CFG_BASE + 3, 0x01, 0);
if (pm_state == HOST_ENTER_S3) {
- if (PCI_PID(pcr) == 0x524A)
+ if (PCI_PID(pcr) == 0x524A || PCI_PID(pcr) == 0x525A)
Shouldn't these be defined somewhere?
I have a particular distaste for magic numbers.
This is the chip ID number, no need define, just using it.
if we define, it will like RTS525A_PCI_ID, so bad.
Looks good. Please do that.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 01/10] mfd: rtsx: replace TAB by SPC after #define
On Mon, 19 Jan 2015, 敬锐 wrote: On 01/18/2015 08:39 PM, Lee Jones wrote: On Thu, 15 Jan 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn Re-format coding-style, using uniform SPC after #define keyword instead of mixing using TAB and SPC. Tabs and spaces in this context usually have different meanings i.e. space after #define usually denotes that the following define is a register address, whereas a tab commonly describes a bit field. Please ensure you're not messing with these conventions. By the looks of it you are not, but I need you to confirm that you know what you're doing. if using TAB describe a bit field, and define TAB length = 8 SPC, the editor will not show any difference(if not highlight TAB/SPC). And the mix is not to show difference between address and field. so all replaced by space, and show difference by next patch(02/10). Okay, so you have gone for a 1 space/2 space to differentiate. Sounds good. Acked-by: Lee Jones lee.jo...@linaro.org Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- include/linux/mfd/rtsx_pci.h | 254 +-- 1 file changed, 127 insertions(+), 127 deletions(-) diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h index 0c12628..a9c2a14 100644 --- a/include/linux/mfd/rtsx_pci.h +++ b/include/linux/mfd/rtsx_pci.h @@ -175,9 +175,9 @@ /* CARD_SHARE_MODE */ #define CARD_SHARE_MASK 0x0F #define CARD_SHARE_MULTI_LUN 0x00 -#define CARD_SHARE_NORMAL 0x00 -#define CARD_SHARE_48_SD0x04 -#define CARD_SHARE_48_MS0x08 +#define CARD_SHARE_NORMAL 0x00 +#define CARD_SHARE_48_SD 0x04 +#define CARD_SHARE_48_MS 0x08 /* CARD_SHARE_MODE for barossa */ #define CARD_SHARE_BAROSSA_SD0x01 #define CARD_SHARE_BAROSSA_MS0x02 @@ -249,76 +249,76 @@ #define CD_AUTO_DISABLE 0x40 /* SD_STAT1 */ -#define SD_CRC7_ERR 0x80 -#define SD_CRC16_ERR0x40 -#define SD_CRC_WRITE_ERR0x20 -#define SD_CRC_WRITE_ERR_MASK 0x1C -#define GET_CRC_TIME_OUT0x02 -#define SD_TUNING_COMPARE_ERR 0x01 +#define SD_CRC7_ERR 0x80 +#define SD_CRC16_ERR 0x40 +#define SD_CRC_WRITE_ERR 0x20 +#define SD_CRC_WRITE_ERR_MASK 0x1C +#define GET_CRC_TIME_OUT 0x02 +#define SD_TUNING_COMPARE_ERR 0x01 /* SD_STAT2 */ -#define SD_RSP_80CLK_TIMEOUT0x01 +#define SD_RSP_80CLK_TIMEOUT 0x01 /* SD_BUS_STAT */ -#define SD_CLK_TOGGLE_EN0x80 -#define SD_CLK_FORCE_STOP 0x40 -#define SD_DAT3_STATUS 0x10 -#define SD_DAT2_STATUS 0x08 -#define SD_DAT1_STATUS 0x04 -#define SD_DAT0_STATUS 0x02 -#define SD_CMD_STATUS 0x01 +#define SD_CLK_TOGGLE_EN 0x80 +#define SD_CLK_FORCE_STOP 0x40 +#define SD_DAT3_STATUS0x10 +#define SD_DAT2_STATUS0x08 +#define SD_DAT1_STATUS0x04 +#define SD_DAT0_STATUS0x02 +#define SD_CMD_STATUS 0x01 /* SD_PAD_CTL */ -#define SD_IO_USING_1V8 0x80 -#define SD_IO_USING_3V3 0x7F -#define TYPE_A_DRIVING 0x00 -#define TYPE_B_DRIVING 0x01 -#define TYPE_C_DRIVING 0x02 -#define TYPE_D_DRIVING 0x03 +#define SD_IO_USING_1V8 0x80 +#define SD_IO_USING_3V3 0x7F +#define TYPE_A_DRIVING0x00 +#define TYPE_B_DRIVING0x01 +#define TYPE_C_DRIVING0x02 +#define TYPE_D_DRIVING0x03 /* SD_SAMPLE_POINT_CTL */ -#define DDR_FIX_RX_DAT 0x00 -#define DDR_VAR_RX_DAT 0x80 -#define DDR_FIX_RX_DAT_EDGE 0x00 -#define DDR_FIX_RX_DAT_14_DELAY 0x40 -#define DDR_FIX_RX_CMD 0x00 -#define DDR_VAR_RX_CMD 0x20 -#define DDR_FIX_RX_CMD_POS_EDGE 0x00 -#define DDR_FIX_RX_CMD_14_DELAY 0x10 -#define SD20_RX_POS_EDGE0x00 -#define SD20_RX_14_DELAY0x08 +#define DDR_FIX_RX_DAT0x00 +#define DDR_VAR_RX_DAT0x80 +#define DDR_FIX_RX_DAT_EDGE 0x00 +#define DDR_FIX_RX_DAT_14_DELAY 0x40 +#define DDR_FIX_RX_CMD0x00 +#define DDR_VAR_RX_CMD0x20 +#define
Re: [PATCH 08/10] mfd: rtsx: add support for rts524A
On Mon, 19 Jan 2015, 敬锐 wrote:
On 01/18/2015 08:20 PM, Lee Jones wrote:
+};
+
+void rts524a_init_params(struct rtsx_pcr *pcr)
+{
+ rts5249_init_params(pcr);
+
+ pcr-ops = rts524a_pcr_ops;
+}
I see a couple of these now. Why don't you make 'ops' a parameter of
*_init_params().
*_init_params() is called from rtsx_pcr.c, and the ops parameter should
be static, if we make ops as a parameter, the rts524a_pcr_ops defination
should move to rtsx_pcr.c, not reasonable.
Fair enough.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 09/10] mfd: rtsx: add support for rts525A
/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -59,6 +59,7 @@ static const struct pci_device_id rtsx_pci_ids[] = {
{ PCI_DEVICE(0x10EC, 0x5287), PCI_CLASS_OTHERS 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x5286), PCI_CLASS_OTHERS 16, 0xFF },
{ PCI_DEVICE(0x10EC, 0x524A), PCI_CLASS_OTHERS 16, 0xFF },
+ { PCI_DEVICE(0x10EC, 0x525A), PCI_CLASS_OTHERS 16, 0xFF },
{ 0, }
};
@@ -1113,6 +1114,10 @@ static int rtsx_pci_init_chip(struct rtsx_pcr *pcr)
rts524a_init_params(pcr);
break;
+ case 0x525A:
+ rts525a_init_params(pcr);
+ break;
+
case 0x5287:
rtl8411b_init_params(pcr);
break;
@@ -1158,7 +1163,7 @@ static int rtsx_pci_probe(struct pci_dev *pcidev,
struct rtsx_pcr *pcr;
struct pcr_handle *handle;
u32 base, len;
- int ret, i;
+ int ret, i, bar = 0;
dev_dbg((pcidev-dev),
: Realtek PCI-E Card Reader found at %s [%04x:%04x] (rev
%x)\n,
@@ -1203,8 +1208,10 @@ static int rtsx_pci_probe(struct pci_dev *pcidev,
pcr-pci = pcidev;
dev_set_drvdata(pcidev-dev, handle);
- len = pci_resource_len(pcidev, 0);
- base = pci_resource_start(pcidev, 0);
+ if (PCI_PID(pcr) == 0x525A)
+ bar = 1;
+ len = pci_resource_len(pcidev, bar);
+ base = pci_resource_start(pcidev, bar);
pcr-remap_addr = ioremap_nocache(base, len);
if (!pcr-remap_addr) {
ret = -ENOMEM;
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 0535265..4c00544 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -37,6 +37,7 @@ void rtl8402_init_params(struct rtsx_pcr *pcr);
void rts5227_init_params(struct rtsx_pcr *pcr);
void rts5249_init_params(struct rtsx_pcr *pcr);
void rts524a_init_params(struct rtsx_pcr *pcr);
+void rts525a_init_params(struct rtsx_pcr *pcr);
void rtl8411b_init_params(struct rtsx_pcr *pcr);
static inline u8 map_sd_drive(int idx)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 05/10] mfd: rtsx: update driving settings
On Thu, 15 Jan 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
update card drive settings, This setting can be used for rts5249
rts524A and rts525A.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/rts5249.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
There is no way for me to know if this is correct or not.
Code looks fine though, so:
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 225ad55..2fe2854 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -36,16 +36,16 @@ static u8 rts5249_get_ic_version(struct rtsx_pcr *pcr)
static void rts5249_fill_driving(struct rtsx_pcr *pcr, u8 voltage)
{
u8 driving_3v3[4][3] = {
- {0x11, 0x11, 0x11},
+ {0x11, 0x11, 0x18},
{0x55, 0x55, 0x5C},
- {0x99, 0x99, 0x92},
- {0x99, 0x99, 0x92},
+ {0xFF, 0xFF, 0xFF},
+ {0x96, 0x96, 0x96},
};
u8 driving_1v8[4][3] = {
+ {0xC4, 0xC4, 0xC4},
{0x3C, 0x3C, 0x3C},
- {0xB3, 0xB3, 0xB3},
{0xFE, 0xFE, 0xFE},
- {0xC4, 0xC4, 0xC4},
+ {0xB3, 0xB3, 0xB3},
};
u8 (*driving)[3], drive_sel;
@@ -341,7 +341,7 @@ void rts5249_init_params(struct rtsx_pcr *pcr)
pcr-flags = 0;
pcr-card_drive_sel = RTSX_CARD_DRIVE_DEFAULT;
- pcr-sd30_drive_sel_1v8 = CFG_DRIVER_TYPE_C;
+ pcr-sd30_drive_sel_1v8 = CFG_DRIVER_TYPE_B;
pcr-sd30_drive_sel_3v3 = CFG_DRIVER_TYPE_B;
pcr-aspm_en = ASPM_L1_EN;
pcr-tx_initial_phase = SET_CLOCK_PHASE(1, 29, 16);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 08/10] mfd: rtsx: add support for rts524A
0xFE8E
+#define L1SUB_AUTO_CFG 0x02
+#define L1SUB_CONFIG30xFE8F
+
#define DUMMY_REG_RESET_00xFE90
#define AUTOLOAD_CFG_BASE0xFF00
#define PETXCFG 0xFF03
#define PM_CTRL1 0xFF44
+#define CD_RESUME_EN_MASK 0xF0
+
#define PM_CTRL2 0xFF45
#define PM_CTRL3 0xFF46
#define SDIO_SEND_PME_EN 0x80
@@ -628,6 +641,61 @@
#define IMAGE_FLAG_ADDR0 0xCE80
#define IMAGE_FLAG_ADDR1 0xCE81
+#define RREF_CFG 0xFF6C
+#define RREF_VBGSEL_MASK 0x38
+#define RREF_VBGSEL_1V25 0x28
+
+#define OOBS_CONFIG 0xFF6E
+#define OOBS_AUTOK_DIS 0x80
+#define OOBS_VAL_MASK 0x1F
+
+#define LDO_DV18_CFG 0xFF70
+#define LDO_DV18_SR_MASK 0xC0
+#define LDO_DV18_SR_DF 0x40
+
+#define LDO_CONFIG2 0xFF71
+#define LDO_D3318_MASK 0x07
+#define LDO_D3318_33V 0x07
+#define LDO_D3318_18V 0x02
+
+#define LDO_VCC_CFG0 0xFF72
+#define LDO_VCC_LMTVTH_MASK0x30
+#define LDO_VCC_LMTVTH_2A 0x10
+
+#define LDO_VCC_CFG1 0xFF73
+#define LDO_VCC_REF_TUNE_MASK 0x30
+#define LDO_VCC_REF_1V20x20
+#define LDO_VCC_TUNE_MASK 0x07
+#define LDO_VCC_1V80x04
+#define LDO_VCC_3V30x07
+#define LDO_VCC_LMT_EN 0x08
+
+#define LDO_VIO_CFG 0xFF75
+#define LDO_VIO_SR_MASK0xC0
+#define LDO_VIO_SR_DF 0x40
+#define LDO_VIO_REF_TUNE_MASK 0x30
+#define LDO_VIO_REF_1V20x20
+#define LDO_VIO_TUNE_MASK 0x07
+#define LDO_VIO_1V70x03
+#define LDO_VIO_1V80x04
+#define LDO_VIO_3V30x07
+
+#define LDO_DV12S_CFG0xFF76
+#define LDO_REF12_TUNE_MASK0x18
+#define LDO_REF12_TUNE_DF 0x10
+#define LDO_D12_TUNE_MASK 0x07
+#define LDO_D12_TUNE_DF0x04
+
+#define LDO_AV12S_CFG0xFF77
+#define LDO_AV12S_TUNE_MASK0x07
+#define LDO_AV12S_TUNE_DF 0x04
+
+#define SD40_LDO_CTL10xFE7D
+#define SD40_VIO_TUNE_MASK 0x70
+#define SD40_VIO_TUNE_1V7 0x30
+#define SD_VIO_LDO_1V8 0x40
+#define SD_VIO_LDO_3V3 0x70
+
/* Phy register */
#define PHY_PCR 0x00
#define PHY_RCR0 0x01
@@ -828,7 +896,8 @@ struct rtsx_pcr {
#define CHK_PCI_PID(pcr, pid)((pcr)-pci-device == (pid))
#define PCI_VID(pcr) ((pcr)-pci-vendor)
#define PCI_PID(pcr) ((pcr)-pci-device)
-
+#define is_version(pcr, pid, ver)\
+ (CHK_PCI_PID(pcr, pid) (pcr)-ic_version == (ver))
#define pcr_dbg(pcr, fmt, arg...)\
dev_dbg((pcr)-pci-dev, fmt, ##arg)
#define SDR104_PHASE(val)((val) 0xFF)
@@ -899,4 +968,18 @@ static inline void rtsx_pci_write_be32(struct rtsx_pcr
*pcr, u16 reg, u32 val)
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
}
+static inline int rtsx_pci_update_phy(struct rtsx_pcr *pcr, u8 addr,
+ u16 mask, u16 append)
+{
+ int err = 0;
+ u16 val = 0;
Not sure why you've pre-initialised these?
+ err = rtsx_pci_read_phy_register(pcr, addr, val);
+ if (err 0)
if (err)
+ return err;
+
+ err = rtsx_pci_write_phy_register(pcr, addr, (val mask) | append);
+ return err;
Just return right away. No need to load 'err'.
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 01/10] mfd: rtsx: replace TAB by SPC after #define
#define SD_VPCLK0_CTL0xFC2A #define SD_VPCLK1_CTL0xFC2B #define SD_DCMPS0_CTL0xFC2C -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 03/10] mfd: rtsx: add debug info when access register failed
On Thu, 15 Jan 2015, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Add debug info when access register failed, this is useful for
debug.
Pull the creation of the macro into another patch. I'm happy to apply
that, but I don't really want dbg prints scattered everywhere. Feel
free to keep this patch on a branch and apply it when you need it, but
I'm not keen on having them in Mainline.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/rtsx_pcr.c | 22 +-
include/linux/mfd/rtsx_pci.h | 2 ++
2 files changed, 19 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/rtsx_pcr.c b/drivers/mfd/rtsx_pcr.c
index 30f7ca8..92f5a41 100644
--- a/drivers/mfd/rtsx_pcr.c
+++ b/drivers/mfd/rtsx_pcr.c
@@ -96,12 +96,16 @@ int rtsx_pci_write_register(struct rtsx_pcr *pcr, u16
addr, u8 mask, u8 data)
for (i = 0; i MAX_RW_REG_CNT; i++) {
val = rtsx_pci_readl(pcr, RTSX_HAIMR);
if ((val HAIMR_TRANS_END) == 0) {
- if (data != (u8)val)
+ if (data != (u8)val) {
+ pcr_dbg(pcr, write register 0x%02x failed\n,
+ addr);
return -EIO;
+ }
return 0;
}
}
+ pcr_dbg(pcr, write register 0x%02x failed\n, addr);
return -ETIMEDOUT;
}
EXPORT_SYMBOL_GPL(rtsx_pci_write_register);
@@ -120,8 +124,10 @@ int rtsx_pci_read_register(struct rtsx_pcr *pcr, u16
addr, u8 *data)
break;
}
- if (i = MAX_RW_REG_CNT)
+ if (i = MAX_RW_REG_CNT) {
+ pcr_dbg(pcr, read register 0x%02x failed\n, addr);
return -ETIMEDOUT;
+ }
if (data)
*data = (u8)(val 0xFF);
@@ -157,8 +163,10 @@ int rtsx_pci_write_phy_register(struct rtsx_pcr *pcr, u8
addr, u16 val)
}
}
- if (!finished)
+ if (!finished) {
+ pcr_dbg(pcr, write phy 0x%x failed\n, addr);
return -ETIMEDOUT;
+ }
return 0;
}
@@ -190,8 +198,10 @@ int rtsx_pci_read_phy_register(struct rtsx_pcr *pcr, u8
addr, u16 *val)
}
}
- if (!finished)
+ if (!finished) {
+ pcr_dbg(pcr, read phy 0x%x failed\n, addr);
return -ETIMEDOUT;
+ }
rtsx_pci_init_cmd(pcr);
@@ -199,8 +209,10 @@ int rtsx_pci_read_phy_register(struct rtsx_pcr *pcr, u8
addr, u16 *val)
rtsx_pci_add_cmd(pcr, READ_REG_CMD, PHYDATA1, 0, 0);
err = rtsx_pci_send_cmd(pcr, 100);
- if (err 0)
+ if (err 0) {
+ pcr_dbg(pcr, read phy 0x%x failed\n, addr);
return err;
+ }
ptr = rtsx_pci_get_cmd_data(pcr);
data = ((u16)ptr[1] 8) | ptr[0];
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index e81f2bb..a680427 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -838,6 +838,8 @@ struct rtsx_pcr {
#define PCI_VID(pcr) ((pcr)-pci-vendor)
#define PCI_PID(pcr) ((pcr)-pci-device)
+#define pcr_dbg(pcr, fmt, arg...)\
+ dev_dbg((pcr)-pci-dev, fmt, ##arg)
#define SDR104_PHASE(val)((val) 0xFF)
#define SDR50_PHASE(val) (((val) 8) 0xFF)
#define DDR50_PHASE(val) (((val) 16) 0xFF)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 10/10] mfd: rtsx: using pcr_dbg replace dev_dbg
On Thu, 15 Jan 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn pcr_dbg is a wrapper of dev_dbg, which can save some code, and help to enable/disable debug message static. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- drivers/mfd/rtl8411.c | 11 +-- drivers/mfd/rts5209.c | 4 ++-- drivers/mfd/rts5227.c | 4 ++-- drivers/mfd/rts5229.c | 4 ++-- drivers/mfd/rts5249.c | 4 ++-- drivers/mfd/rtsx_pcr.c | 49 ++--- 6 files changed, 35 insertions(+), 41 deletions(-) Looks fine. Acked-by: Lee Jones lee.jo...@linaro.org -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 06/10] mfd: rtsx: update phy register
On Thu, 15 Jan 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn update phy register value and using direct value instead of macros. It is much easier to debug using constant value than a lot of macros. We usually need compare the value directly to check the configure. NACK. This is the opposite of what I would like to see. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- drivers/mfd/rts5249.c | 46 ++ 1 file changed, 14 insertions(+), 32 deletions(-) diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c index 2fe2854..00208d1 100644 --- a/drivers/mfd/rts5249.c +++ b/drivers/mfd/rts5249.c @@ -132,57 +132,39 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr) if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV, - PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED | - PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN | - PHY_REG_REV_RX_PWST | PHY_REG_REV_CLKREQ_DLY_TIMER_1_0 | - PHY_REG_REV_STOP_CLKRD | PHY_REG_REV_STOP_CLKWR); + err = rtsx_pci_write_phy_register(pcr, 0x19, 0xFE6C); if (err 0) return err; msleep(1); - err = rtsx_pci_write_phy_register(pcr, PHY_BPCR, - PHY_BPCR_IBRXSEL | PHY_BPCR_IBTXSEL | - PHY_BPCR_IB_FILTER | PHY_BPCR_CMIRROR_EN); + err = rtsx_pci_write_phy_register(pcr, 0x0A, 0x05C0); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_PCR, - PHY_PCR_FORCE_CODE | PHY_PCR_OOBS_CALI_50 | - PHY_PCR_OOBS_VCM_08 | PHY_PCR_OOBS_SEN_90 | - PHY_PCR_RSSI_EN); + + err = rtsx_pci_write_phy_register(pcr, 0x00, 0xBA43); + if (err 0) + return err; + err = rtsx_pci_write_phy_register(pcr, 0x03, 0xC152); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_RCR2, - PHY_RCR2_EMPHASE_EN | PHY_RCR2_NADJR | - PHY_RCR2_CDR_CP_10 | PHY_RCR2_CDR_SR_2 | - PHY_RCR2_FREQSEL_12 | PHY_RCR2_CPADJEN | - PHY_RCR2_CDR_SC_8 | PHY_RCR2_CALIB_LATE); + err = rtsx_pci_write_phy_register(pcr, 0x1E, 0x78EB); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_FLD4, - PHY_FLD4_FLDEN_SEL | PHY_FLD4_REQ_REF | - PHY_FLD4_RXAMP_OFF | PHY_FLD4_REQ_ADDA | - PHY_FLD4_BER_COUNT | PHY_FLD4_BER_TIMER | - PHY_FLD4_BER_CHK_EN); + err = rtsx_pci_write_phy_register(pcr, 0x05, 0x4600); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_RDR, PHY_RDR_RXDSEL_1_9); + err = rtsx_pci_write_phy_register(pcr, 0x02, 0x041F); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_RCR1, - PHY_RCR1_ADP_TIME | PHY_RCR1_VCO_COARSE); + err = rtsx_pci_write_phy_register(pcr, 0x1D, 0x0824); if (err 0) return err; - err = rtsx_pci_write_phy_register(pcr, PHY_FLD3, - PHY_FLD3_TIMER_4 | PHY_FLD3_TIMER_6 | - PHY_FLD3_RXDELINK); + err = rtsx_pci_write_phy_register(pcr, 0x08, 0x4FE4); if (err 0) return err; - return rtsx_pci_write_phy_register(pcr, PHY_TUNE, - PHY_TUNE_TUNEREF_1_0 | PHY_TUNE_VBGSEL_1252 | - PHY_TUNE_SDBUS_33 | PHY_TUNE_TUNED18 | - PHY_TUNE_TUNED12); + + return 0; } static int rts5249_turn_on_led(struct rtsx_pcr *pcr) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 04/10] mfd: rtsx: update PETXCFG address
On Thu, 15 Jan 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn PETXCFG is defined at 0xFF03, the old 0xFE49 not used any more. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- drivers/mfd/rts5227.c| 6 ++ drivers/mfd/rts5249.c| 6 ++ include/linux/mfd/rtsx_pci.h | 2 +- 3 files changed, 5 insertions(+), 9 deletions(-) Acked-by: Lee Jones lee.jo...@linaro.org diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c index 3240740..1f387d4 100644 --- a/drivers/mfd/rts5227.c +++ b/drivers/mfd/rts5227.c @@ -118,11 +118,9 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr) rts5227_fill_driving(pcr, OUTPUT_3V3); /* Configure force_clock_req */ if (pcr-flags PCR_REVERSE_SOCKET) - rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, - AUTOLOAD_CFG_BASE + 3, 0xB8, 0xB8); + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0xB8); else - rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, - AUTOLOAD_CFG_BASE + 3, 0xB8, 0x88); + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB8, 0x88); rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00); return rtsx_pci_send_cmd(pcr, 100); diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c index cf425cc..225ad55 100644 --- a/drivers/mfd/rts5249.c +++ b/drivers/mfd/rts5249.c @@ -116,11 +116,9 @@ static int rts5249_extra_init_hw(struct rtsx_pcr *pcr) /* Configure driving */ rts5249_fill_driving(pcr, OUTPUT_3V3); if (pcr-flags PCR_REVERSE_SOCKET) - rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, - AUTOLOAD_CFG_BASE + 3, 0xB0, 0xB0); + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0xB0); else - rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, - AUTOLOAD_CFG_BASE + 3, 0xB0, 0x80); + rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PETXCFG, 0xB0, 0x80); rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, PM_CTRL3, 0x10, 0x00); return rtsx_pci_send_cmd(pcr, 100); diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h index a680427..80baa10 100644 --- a/include/linux/mfd/rtsx_pci.h +++ b/include/linux/mfd/rtsx_pci.h @@ -572,7 +572,6 @@ #define MSGTXDATA2 0xFE46 #define MSGTXDATA3 0xFE47 #define MSGTXCTL 0xFE48 -#define PETXCFG 0xFE49 #define LTR_CTL 0xFE4A #define OBFF_CFG 0xFE4C @@ -606,6 +605,7 @@ #define DUMMY_REG_RESET_00xFE90 #define AUTOLOAD_CFG_BASE0xFF00 +#define PETXCFG 0xFF03 #define PM_CTRL1 0xFF44 #define PM_CTRL2 0xFF45 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 07/10] mfd: rtsx: remove LCTLR defination
= pci_find_capability(pcr-pci, PCI_CAP_ID_EXP);
+
+ rtsx_pci_update_cfg_byte(pcr, exp + PCI_EXP_LNKCTL, 0xFC, 0);
+}
+
void rtsx_pci_start_run(struct rtsx_pcr *pcr)
{
/* If pci device removed, don't queue idle work any more */
@@ -75,7 +89,8 @@ void rtsx_pci_start_run(struct rtsx_pcr *pcr)
pcr-ops-enable_auto_blink(pcr);
if (pcr-aspm_en)
- rtsx_pci_write_config_byte(pcr, LCTLR, 0);
+ rtsx_pci_disable_aspm(pcr);
+
?
}
mod_delayed_work(system_wq, pcr-idle_work, msecs_to_jiffies(200));
@@ -954,7 +969,7 @@ static void rtsx_pci_idle_work(struct work_struct *work)
pcr-ops-turn_off_led(pcr);
if (pcr-aspm_en)
- rtsx_pci_write_config_byte(pcr, LCTLR, pcr-aspm_en);
+ rtsx_pci_enable_aspm(pcr);
mutex_unlock(pcr-pcr_mutex);
}
@@ -979,6 +994,7 @@ static void rtsx_pci_power_off(struct rtsx_pcr *pcr, u8
pm_state)
static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
{
int err;
+ int exp = pci_find_capability(pcr-pci, PCI_CAP_ID_EXP);
rtsx_pci_writel(pcr, RTSX_HCBAR, pcr-host_cmds_addr);
@@ -992,6 +1008,7 @@ static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
/* Wait SSC power stable */
udelay(200);
+ rtsx_pci_disable_aspm(pcr);
if (pcr-ops-optimize_phy) {
err = pcr-ops-optimize_phy(pcr);
if (err 0)
@@ -1040,10 +1057,8 @@ static int rtsx_pci_init_hw(struct rtsx_pcr *pcr)
if (err 0)
return err;
- rtsx_pci_write_config_byte(pcr, LCTLR, 0);
-
/* Enable clk_request_n to enable clock power management */
- rtsx_pci_write_config_byte(pcr, 0x81, 1);
+ rtsx_pci_write_config_byte(pcr, exp + PCI_EXP_LNKCTL + 1, 1);
/* Enter L1 when host tx idle */
rtsx_pci_write_config_byte(pcr, 0x70F, 0x5B);
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 80baa10..f7cebdb 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -662,15 +662,6 @@
#define PHY_FLD4 0x1E
#define PHY_DUM_REG 0x1F
-#define LCTLR0x80
-#define LCTLR_EXT_SYNC 0x80
-#define LCTLR_COMMON_CLOCK_CFG 0x40
-#define LCTLR_RETRAIN_LINK 0x20
-#define LCTLR_LINK_DISABLE 0x10
-#define LCTLR_RCB 0x08
-#define LCTLR_RESERVED 0x04
-#define LCTLR_ASPM_CTL_MASK0x03
-
#define PCR_SETTING_REG1 0x724
#define PCR_SETTING_REG2 0x814
#define PCR_SETTING_REG3 0x747
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 02/10] mfd: rtsx: place register address and values togather
On Thu, 15 Jan 2015, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn It is more readable to place register address and values define togather. The values define add two leading space indicate belong to the register address defined above. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- include/linux/mfd/rtsx_pci.h | 836 +++ 1 file changed, 369 insertions(+), 467 deletions(-) As you wish. Acked-by: Lee Jones lee.jo...@linaro.org diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h index a9c2a14..e81f2bb 100644 --- a/include/linux/mfd/rtsx_pci.h +++ b/include/linux/mfd/rtsx_pci.h @@ -28,74 +28,72 @@ #define MAX_RW_REG_CNT 1024 -/* PCI Operation Register Address */ #define RTSX_HCBAR 0x00 #define RTSX_HCBCTLR 0x04 +#define STOP_CMD (0x01 28) +#define READ_REG_CMD 0 +#define WRITE_REG_CMD 1 +#define CHECK_REG_CMD 2 + #define RTSX_HDBAR 0x08 +#define SG_INT 0x04 +#define SG_END 0x02 +#define SG_VALID 0x01 +#define SG_NO_OP 0x00 +#define SG_TRANS_DATA (0x02 4) +#define SG_LINK_DESC (0x03 4) #define RTSX_HDBCTLR 0x0C +#define SDMA_MODE 0x00 +#define ADMA_MODE (0x02 26) +#define STOP_DMA (0x01 28) +#define TRIG_DMA (0x01 31) + #define RTSX_HAIMR 0x10 -#define RTSX_BIPR0x14 -#define RTSX_BIER0x18 +#define HAIMR_TRANS_START (0x01 31) +#define HAIMR_READ 0x00 +#define HAIMR_WRITE(0x01 30) +#define HAIMR_READ_START (HAIMR_TRANS_START | HAIMR_READ) +#define HAIMR_WRITE_START (HAIMR_TRANS_START | HAIMR_WRITE) +#define HAIMR_TRANS_END(HAIMR_TRANS_START) -/* Host command buffer control register */ -#define STOP_CMD (0x01 28) - -/* Host data buffer control register */ -#define SDMA_MODE0x00 -#define ADMA_MODE(0x02 26) -#define STOP_DMA (0x01 28) -#define TRIG_DMA (0x01 31) - -/* Host access internal memory register */ -#define HAIMR_TRANS_START(0x01 31) -#define HAIMR_READ 0x00 -#define HAIMR_WRITE (0x01 30) -#define HAIMR_READ_START (HAIMR_TRANS_START | HAIMR_READ) -#define HAIMR_WRITE_START(HAIMR_TRANS_START | HAIMR_WRITE) -#define HAIMR_TRANS_END (HAIMR_TRANS_START) - -/* Bus interrupt pending register */ -#define CMD_DONE_INT (1 31) -#define DATA_DONE_INT(1 30) -#define TRANS_OK_INT (1 29) -#define TRANS_FAIL_INT (1 28) -#define XD_INT (1 27) -#define MS_INT (1 26) -#define SD_INT (1 25) -#define GPIO0_INT(1 24) -#define OC_INT (1 23) -#define SD_WRITE_PROTECT (1 19) -#define XD_EXIST (1 18) -#define MS_EXIST (1 17) -#define SD_EXIST (1 16) -#define DELINK_INT GPIO0_INT -#define MS_OC_INT(1 23) -#define SD_OC_INT(1 22) +#define RTSX_BIPR0x14 +#define CMD_DONE_INT (1 31) +#define DATA_DONE_INT (1 30) +#define TRANS_OK_INT (1 29) +#define TRANS_FAIL_INT (1 28) +#define XD_INT (1 27) +#define MS_INT (1 26) +#define SD_INT (1 25) +#define GPIO0_INT (1 24) +#define OC_INT (1 23) +#define SD_WRITE_PROTECT (1 19) +#define XD_EXIST (1 18) +#define MS_EXIST (1 17) +#define SD_EXIST (1 16) +#define DELINK_INT GPIO0_INT +#define MS_OC_INT (1 23) +#define SD_OC_INT (1 22) #define CARD_INT (XD_INT | MS_INT | SD_INT) #define NEED_COMPLETE_INT(DATA_DONE_INT | TRANS_OK_INT | TRANS_FAIL_INT) #define RTSX_INT (CMD_DONE_INT | NEED_COMPLETE_INT | \ CARD_INT | GPIO0_INT | OC_INT) - #define CARD_EXIST (XD_EXIST | MS_EXIST | SD_EXIST) -/* Bus interrupt enable register */ -#define
Re: [PATCH v4 1/6] mfd: rtsx: add func to split u32 into register
On Fri, 05 Dec 2014, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Add helper function to write u32 to registers, if we want to put u32
value to 4 continuous register, this can help us reduce tedious work.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
Acked-by: Lee Jones lee.jo...@linaro.org
---
include/linux/mfd/rtsx_pci.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..9234449 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -558,6 +558,7 @@
#define SD_SAMPLE_POINT_CTL 0xFDA7
#define SD_PUSH_POINT_CTL0xFDA8
#define SD_CMD0 0xFDA9
+#define SD_CMD_START 0x40
This is a different format at the others in the group on two counts;
firstly you have 3 whitespace characters after the #define and
secondly all of the other hex digits in the set are 4 a breast.
Please add the leading zeros to conform to this format.
#define SD_CMD1 0xFDAA
#define SD_CMD2 0xFDAB
#define SD_CMD3 0xFDAC
@@ -967,4 +968,12 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr
*pcr)
return (u8 *)(pcr-host_cmds_ptr);
}
+static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32
val)
+{
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val 24);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val 16);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val 8);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/6] mfd: rtsx: add func to split u32 into register
On Fri, 05 Dec 2014, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Add helper function to write u32 to registers, if we want to put u32
value to 4 continuous register, this can help us reduce tedious work.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
Acked-by: Lee Jones lee.jo...@linaro.org
---
include/linux/mfd/rtsx_pci.h | 9 +
1 file changed, 9 insertions(+)
Applied, thanks.
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..9234449 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -558,6 +558,7 @@
#define SD_SAMPLE_POINT_CTL 0xFDA7
#define SD_PUSH_POINT_CTL0xFDA8
#define SD_CMD0 0xFDA9
+#define SD_CMD_START 0x40
#define SD_CMD1 0xFDAA
#define SD_CMD2 0xFDAB
#define SD_CMD3 0xFDAC
@@ -967,4 +968,12 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr
*pcr)
return (u8 *)(pcr-host_cmds_ptr);
}
+static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32
val)
+{
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val 24);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val 16);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val 8);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/6] mfd: rtsx: add func to split u32 into register
On Mon, 08 Dec 2014, 敬锐 wrote: On 12/08/2014 04:49 PM, Lee Jones wrote: diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h index 74346d5..9234449 100644 --- a/include/linux/mfd/rtsx_pci.h +++ b/include/linux/mfd/rtsx_pci.h @@ -558,6 +558,7 @@ #define SD_SAMPLE_POINT_CTL 0xFDA7 #define SD_PUSH_POINT_CTL 0xFDA8 #define SD_CMD0 0xFDA9 +#define SD_CMD_START 0x40 This is a different format at the others in the group on two counts; firstly you have 3 whitespace characters after the #define and secondly all of the other hex digits in the set are 4 a breast. Please add the leading zeros to conform to this format. Hi lee, This format is more readable, add 2 space means this value is in groups under register SD_CMD0, and each register value is u8 type, so use 2 hex digits is right. The original file make register address and its related value separated, and group register together. But I like to write register address and value together, add 2 space for value to indicate this value is related to above register. If we add new address/value, I recommend write register define format as below: #define REGISTERaddr #define REG_VAL1 val1 #define REG_VAL2 val2 Okay, I see that there are other occurrences using this format in that file. Please consider converting the entire file into this format. I don't mind it either way, but it looks odd if they are mixed. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v4 1/6] mfd: rtsx: add func to split u32 into register
On Mon, 08 Dec 2014, Ulf Hansson wrote: On 8 December 2014 at 10:57, Lee Jones lee.jo...@linaro.org wrote: On Fri, 05 Dec 2014, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn Add helper function to write u32 to registers, if we want to put u32 value to 4 continuous register, this can help us reduce tedious work. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn Acked-by: Lee Jones lee.jo...@linaro.org --- include/linux/mfd/rtsx_pci.h | 9 + 1 file changed, 9 insertions(+) Applied, thanks. Lee, I suppose you queued this for 3.19? I don't intend to queue anything more before the merge window and thus the mmc patches can later be handled without any dependence to mfd, I guess!? All correct. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] mfd: rtsx: add func to split u32 into register
On Thu, 27 Nov 2014, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Add helper function to write u32 to registers, if we want to put u32
value to 4 continuous register, this can help us reduce tedious work.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
include/linux/mfd/rtsx_pci.h | 15 +++
1 file changed, 15 insertions(+)
Okay, I'm happy that Dan is now satisfied.
Can I take this patch, or does patch 2 depend on it?
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..bf45ea2 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -967,4 +967,19 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr
*pcr)
return (u8 *)(pcr-host_cmds_ptr);
}
+static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32
val)
+{
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val 24);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val 16);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val 8);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
+}
+
+static inline void rtsx_pci_write_le32(struct rtsx_pcr *pcr, u16 reg, u32
val)
+{
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val 8);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val 16);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val 24);
+}
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] mfd: rtsx: add func to split u32 into register
On Fri, 28 Nov 2014, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Add helper function to write u32 to registers, if we want to put u32
value to 4 continuous register, this can help us reduce tedious work.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
include/linux/mfd/rtsx_pci.h | 9 +
1 file changed, 9 insertions(+)
Does this supersede patch Dan was commenting on?
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..9234449 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -558,6 +558,7 @@
#define SD_SAMPLE_POINT_CTL 0xFDA7
#define SD_PUSH_POINT_CTL0xFDA8
#define SD_CMD0 0xFDA9
+#define SD_CMD_START 0x40
#define SD_CMD1 0xFDAA
#define SD_CMD2 0xFDAB
#define SD_CMD3 0xFDAC
@@ -967,4 +968,12 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr
*pcr)
return (u8 *)(pcr-host_cmds_ptr);
}
+static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32
val)
+{
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val 24);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val 16);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val 8);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] mfd: rtsx: add func to split u32 into register
On Fri, 28 Nov 2014, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Add helper function to write u32 to registers, if we want to put u32
value to 4 continuous register, this can help us reduce tedious work.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
include/linux/mfd/rtsx_pci.h | 9 +
1 file changed, 9 insertions(+)
Looks fine to me. Let me know how you want to handle this:
For my own reference:
Acked-by: Lee Jones lee.jo...@linaro.org
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..9234449 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -558,6 +558,7 @@
#define SD_SAMPLE_POINT_CTL 0xFDA7
#define SD_PUSH_POINT_CTL0xFDA8
#define SD_CMD0 0xFDA9
+#define SD_CMD_START 0x40
#define SD_CMD1 0xFDAA
#define SD_CMD2 0xFDAB
#define SD_CMD3 0xFDAC
@@ -967,4 +968,12 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr
*pcr)
return (u8 *)(pcr-host_cmds_ptr);
}
+static inline void rtsx_pci_write_be32(struct rtsx_pcr *pcr, u16 reg, u32
val)
+{
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg, 0xFF, val 24);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 1, 0xFF, val 16);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 2, 0xFF, val 8);
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, reg + 3, 0xFF, val);
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] mfd: rtsx: fix PM suspend for 5227 5249
RESET_PIN_WAKE 0x02
+#define PM_WAKE_EN 0x01
#define PM_CTRL4 0xFF47
/* Memory mapping */
@@ -752,6 +760,14 @@
#define PHY_DUM_REG 0x1F
#define LCTLR0x80
+#define LCTLR_EXT_SYNC 0x80
+#define LCTLR_COMMON_CLOCK_CFG 0x40
+#define LCTLR_RETRAIN_LINK 0x20
+#define LCTLR_LINK_DISABLE 0x10
+#define LCTLR_RCB 0x08
+#define LCTLR_RESERVED 0x04
+#define LCTLR_ASPM_CTL_MASK0x03
+
#define PCR_SETTING_REG1 0x724
#define PCR_SETTING_REG2 0x814
#define PCR_SETTING_REG3 0x747
@@ -967,4 +983,16 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr
*pcr)
return (u8 *)(pcr-host_cmds_ptr);
}
+static inline int rtsx_pci_update_cfg_byte(struct rtsx_pcr *pcr, int addr,
+ u8 mask, u8 append)
+{
+ int err;
+ u8 val;
+
+ err = pci_read_config_byte(pcr-pci, addr, val);
+ if (err 0)
+ return err;
+ return pci_write_config_byte(pcr-pci, addr, (val mask) | append);
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] mfd: rtsx: fix PM suspend for 5227 5249
On Fri, 10 Oct 2014, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn Fix rts52275249 failed send buffer cmd after suspend, PM_CTRL3 should reset before send any buffer cmd after suspend. Otherwise, buffer cmd will failed, this will lead resume fail. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- drivers/mfd/Makefile | 2 +- drivers/mfd/rts5227.c| 6 ++ drivers/mfd/rts5249.c| 4 drivers/mfd/rtsx_gops.c | 37 + drivers/mfd/rtsx_pcr.h | 3 +++ include/linux/mfd/rtsx_pci.h | 28 These are Card Reader drivers right? Do you know why these are in MFD? 6 files changed, 79 insertions(+), 1 deletion(-) create mode 100644 drivers/mfd/rtsx_gops.c -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2] mfd: rtsx: fix PM suspend for 5227 5249
On Fri, 10 Oct 2014, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Fix rts52275249 failed send buffer cmd after suspend,
PM_CTRL3 should reset before send any buffer cmd after suspend.
Otherwise, buffer cmd will failed, this will lead resume fail.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/Makefile | 2 +-
drivers/mfd/rts5227.c| 6 ++
drivers/mfd/rts5249.c| 4
drivers/mfd/rtsx_gops.c | 37 +
drivers/mfd/rtsx_pcr.h | 3 +++
include/linux/mfd/rtsx_pci.h | 28
6 files changed, 79 insertions(+), 1 deletion(-)
create mode 100644 drivers/mfd/rtsx_gops.c
[...]
+static inline int rtsx_pci_update_cfg_byte(struct rtsx_pcr *pcr, int addr,
+ u8 mask, u8 append)
+{
+ int err;
+ u8 val;
+
+ err = pci_read_config_byte(pcr-pci, addr, val);
+ if (err 0)
+ return err;
+ return pci_write_config_byte(pcr-pci, addr, (val mask) | append);
+}
+
Why is this in here? Why not put it in the generic ops file?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
On Thu, 09 Oct 2014, Catalin Marinas wrote:
On Tue, Oct 07, 2014 at 09:00:48AM +0100, Lee Jones wrote:
On Mon, 06 Oct 2014, Guenter Roeck wrote:
--- a/drivers/mfd/ab8500-sysctrl.c
+++ b/drivers/mfd/ab8500-sysctrl.c
@@ -6,6 +6,7 @@
[...]
+static int ab8500_power_off(struct notifier_block *this, unsigned long
unused1,
+ void *unused2)
{
sigset_t old;
sigset_t all;
@@ -34,11 +36,6 @@ static void ab8500_power_off(void)
struct power_supply *psy;
int ret;
- if (sysctrl_dev == NULL) {
- pr_err(%s: sysctrl not initialized\n, __func__);
- return;
- }
Can you explain the purpose of this change please?
I guess it's because the sysctrl_dev is already initialised when
registering the power_off handler, so there isn't a way to call the
above function with a NULL sysctrl_dev. Probably even with the original
code you didn't need this check (after some race fix in
ab8500_sysctrl_remove but races is one of the things Guenter's patches
try to address).
Sounds reasonable, although I think this change should be part of
another patch.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
On Thu, 09 Oct 2014, Guenter Roeck wrote:
On 10/09/2014 03:49 AM, Lee Jones wrote:
On Thu, 09 Oct 2014, Catalin Marinas wrote:
On Tue, Oct 07, 2014 at 09:00:48AM +0100, Lee Jones wrote:
On Mon, 06 Oct 2014, Guenter Roeck wrote:
--- a/drivers/mfd/ab8500-sysctrl.c
+++ b/drivers/mfd/ab8500-sysctrl.c
@@ -6,6 +6,7 @@
[...]
+static int ab8500_power_off(struct notifier_block *this, unsigned long
unused1,
+ void *unused2)
{
sigset_t old;
sigset_t all;
@@ -34,11 +36,6 @@ static void ab8500_power_off(void)
struct power_supply *psy;
int ret;
- if (sysctrl_dev == NULL) {
- pr_err(%s: sysctrl not initialized\n, __func__);
- return;
- }
Can you explain the purpose of this change please?
I guess it's because the sysctrl_dev is already initialised when
registering the power_off handler, so there isn't a way to call the
above function with a NULL sysctrl_dev. Probably even with the original
code you didn't need this check (after some race fix in
ab8500_sysctrl_remove but races is one of the things Guenter's patches
try to address).
Sounds reasonable, although I think this change should be part of
another patch.
Sure, no problem. I'll split this into two patches.
Since we are at it, any idea what to do with the restart function
in the same file ? It is not used anywhere.
You can strip it out with Linus Walleij's Ack. Or I'll be happy to do
it?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 18/44] mfd: twl4030-power: Register with kernel poweroff handler
On Mon, 06 Oct 2014, Guenter Roeck wrote:
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with a low priority value of 64 to reflect that
the original code only sets pm_power_off if it was not already set.
Make twl4030_power_off static as it is only called from the twl4030-power
driver.
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
drivers/mfd/twl4030-power.c | 25 +
include/linux/i2c/twl.h | 1 -
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/twl4030-power.c b/drivers/mfd/twl4030-power.c
index 4d3ff37..bd6b830 100644
--- a/drivers/mfd/twl4030-power.c
+++ b/drivers/mfd/twl4030-power.c
@@ -25,9 +25,10 @@
*/
#include linux/module.h
-#include linux/pm.h
+#include linux/notifier.h
#include linux/i2c/twl.h
#include linux/platform_device.h
+#include linux/pm.h
#include linux/of.h
#include linux/of_device.h
@@ -611,7 +612,8 @@ twl4030_power_configure_resources(const struct
twl4030_power_data *pdata)
* After a successful execution, TWL shuts down the power to the SoC
* and all peripherals connected to it.
*/
-void twl4030_power_off(void)
+static int twl4030_power_off(struct notifier_block *this, unsigned long
unused1,
+ void *unused2)
{
int err;
@@ -619,8 +621,15 @@ void twl4030_power_off(void)
TWL4030_PM_MASTER_P1_SW_EVENTS);
if (err)
pr_err(TWL4030 Unable to power off\n);
+
+ return NOTIFY_DONE;
}
+static struct notifier_block twl4030_poweroff_nb = {
+ .notifier_call = twl4030_power_off,
+ .priority = 64,
64 out of what? How is this calculated? Wouldn't it be better to
define these?
+};
+
static bool twl4030_power_use_poweroff(const struct twl4030_power_data
*pdata,
struct device_node *node)
{
@@ -836,7 +845,7 @@ static int twl4030_power_probe(struct platform_device
*pdev)
}
/* Board has to be wired properly to use this feature */
- if (twl4030_power_use_poweroff(pdata, node) !pm_power_off) {
+ if (twl4030_power_use_poweroff(pdata, node)) {
/* Default for SEQ_OFFSYNC is set, lets ensure this */
err = twl_i2c_read_u8(TWL_MODULE_PM_MASTER, val,
TWL4030_PM_MASTER_CFG_P123_TRANSITION);
@@ -853,7 +862,13 @@ static int twl4030_power_probe(struct platform_device
*pdev)
}
}
- pm_power_off = twl4030_power_off;
+ err = register_poweroff_handler(twl4030_poweroff_nb);
+ if (err) {
+ dev_err(pdev-dev,
+ Failed to register poweroff handler\n);
If this is not fatal, you should issue a dev_warn() instead.
+ /* Not a fatal error */
+ err = 0;
How about using your own variable for this? Then you don't have to
worry about resetting it.
+ }
}
relock:
@@ -869,6 +884,8 @@ relock:
static int twl4030_power_remove(struct platform_device *pdev)
{
+ unregister_poweroff_handler(twl4030_poweroff_nb);
Perhaps a naive question, but is there any way you can do this using
devres (devm_* managed resources)?
return 0;
}
diff --git a/include/linux/i2c/twl.h b/include/linux/i2c/twl.h
index 8cfb50f..f8544f1 100644
--- a/include/linux/i2c/twl.h
+++ b/include/linux/i2c/twl.h
@@ -680,7 +680,6 @@ struct twl4030_power_data {
};
extern int twl4030_remove_script(u8 flags);
-extern void twl4030_power_off(void);
struct twl4030_codec_data {
unsigned int digimic_delay; /* in ms */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 12/44] mfd: ab8500-sysctrl: Register with kernel poweroff handler
On Mon, 06 Oct 2014, Guenter Roeck wrote:
Register with kernel poweroff handler instead of setting pm_power_off
directly. Register with a low priority value of 64 to reflect that
the original code only sets pm_power_off if it was not already set.
Cc: Linus Walleij linus.wall...@linaro.org
Cc: Lee Jones lee.jo...@linaro.org
Cc: Samuel Ortiz sa...@linux.intel.com
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
drivers/mfd/ab8500-sysctrl.c | 26 +++---
1 file changed, 15 insertions(+), 11 deletions(-)
diff --git a/drivers/mfd/ab8500-sysctrl.c b/drivers/mfd/ab8500-sysctrl.c
index 8e0dae5..677438f 100644
--- a/drivers/mfd/ab8500-sysctrl.c
+++ b/drivers/mfd/ab8500-sysctrl.c
@@ -6,6 +6,7 @@
[...]
+static int ab8500_power_off(struct notifier_block *this, unsigned long
unused1,
+ void *unused2)
{
sigset_t old;
sigset_t all;
@@ -34,11 +36,6 @@ static void ab8500_power_off(void)
struct power_supply *psy;
int ret;
- if (sysctrl_dev == NULL) {
- pr_err(%s: sysctrl not initialized\n, __func__);
- return;
- }
Can you explain the purpose of this change please?
/*
* If we have a charger connected and we're powering off,
* reboot into charge-only mode.
@@ -83,8 +80,15 @@ shutdown:
AB8500_STW4500CTRL1_SWRESET4500N);
(void)sigprocmask(SIG_SETMASK, old, NULL);
}
+
+ return NOTIFY_DONE;
}
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] mfd: rtsx: fix PM suspend for 5227 5249
On Thu, 18 Sep 2014, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Fix rts52275249 failed send buffer cmd after suspend,
PM_CTRL3 should reset before send any buffer cmd after suspend.
Otherwise, buffer cmd will failed, this will lead resume fail.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/Makefile |2 +-
drivers/mfd/rts5227.c|6 ++
drivers/mfd/rts5249.c|4
drivers/mfd/rtsx_gops.c | 36
drivers/mfd/rtsx_pcr.h |3 +++
include/linux/mfd/rtsx_pci.h | 12
6 files changed, 62 insertions(+), 1 deletion(-)
create mode 100644 drivers/mfd/rtsx_gops.c
[...]
diff --git a/drivers/mfd/rtsx_gops.c b/drivers/mfd/rtsx_gops.c
new file mode 100644
index 000..3cf596f
--- /dev/null
+++ b/drivers/mfd/rtsx_gops.c
@@ -0,0 +1,36 @@
+/* Driver for Realtek PCI-Express card reader
+ *
+ * Copyright(c) 2009-2013 Realtek Semiconductor Corp. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, see http://www.gnu.org/licenses/.
+ *
+ * Author:
+ * Micky Ching micky_ch...@realsil.com.cn
+ */
+
+#include linux/mfd/rtsx_pci.h
+#include rtsx_pcr.h
+
+int rtsx_gops_pm_reset(struct rtsx_pcr *pcr)
+{
+ int err;
+
+ /* init aspm */
+ err = rtsx_pci_update_cfg_byte(pcr, LCTLR, 0xFC, 0);
I'm not keen on the magic numbers here. Can you #define them?
+ if (err 0)
+ return err;
+
+ /* reset PM_CTRL3 before send buffer cmd */
+ return rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x00);
Same.
+}
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 07e4c2e..fe2bbb6 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -72,4 +72,7 @@ do {
\
pcr-ms_pull_ctl_disable_tbl = __device##_ms_pull_ctl_disable_tbl; \
} while (0)
+/* generic operations */
+int rtsx_gops_pm_reset(struct rtsx_pcr *pcr);
+
#endif
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..b34fec8 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -967,4 +967,16 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr
*pcr)
return (u8 *)(pcr-host_cmds_ptr);
}
+static inline int rtsx_pci_update_cfg_byte(struct rtsx_pcr *pcr, int addr,
+ u8 mask, u8 append)
+{
+ int err;
+ u8 val;
+
+ err = pci_read_config_byte(pcr-pci, addr, val);
+ if (err 0)
+ return err;
+ return pci_write_config_byte(pcr-pci, addr, (val mask) | append);
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] mfd: rtsx: fix PM suspend for 5227 5249
On Thu, 18 Sep 2014, micky wrote: On 09/18/2014 12:53 PM, Lee Jones wrote: On Thu, 18 Sep 2014, micky_ch...@realsil.com.cn wrote: From: Micky Ching micky_ch...@realsil.com.cn Fix rts52275249 failed send buffer cmd after suspend, PM_CTRL3 should reset before send any buffer cmd after suspend. Otherwise, buffer cmd will failed, this will lead resume fail. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- drivers/mfd/rts5227.c| 19 +++ drivers/mfd/rts5249.c|4 drivers/mfd/rtsx_pcr.h |1 + include/linux/mfd/rtsx_pci.h | 12 4 files changed, 36 insertions(+) I think you'll find you just broke the build. What happens when you compile these as modules? I build as modules with no warning or error, did you find anything wrong? Yes, you don't export the functions. EXPORT_SYMBOL() -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 1/2] mfd: rtsx: fix PM suspend for 5227
On Fri, 12 Sep 2014, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Fix rts5227 failed send buffer cmd after suspend,
PM_CTRL3 should reset before send any buffer cmd after suspend.
Otherwise, buffer cmd will failed, this will lead resume fail.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/rts5227.c| 19 +++
include/linux/mfd/rtsx_pci.h | 12
2 files changed, 31 insertions(+)
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 9c8eec8..197f5c1 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -128,8 +128,27 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
return rtsx_pci_send_cmd(pcr, 100);
}
+static int rts5227_pm_reset(struct rtsx_pcr *pcr)
+{
+ int err;
+
+ /* init aspm */
+ err = rtsx_pci_update_cfg_byte(pcr, LCTLR, 0xFC, 0);
+ if (err 0)
+ return err;
+
+ /* reset PM_CTRL3 before send buffer cmd */
+ return rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x00);
+}
+
This is exactly the same function as in the other patch. Please place
it somewhere it can be referenced by both drivers.
static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
{
+ int err;
+
+ err = rts5227_pm_reset(pcr);
+ if (err 0)
+ return err;
+
/* Optimize RX sensitivity */
return rtsx_pci_write_phy_register(pcr, 0x00, 0xBA42);
}
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..b34fec8 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -967,4 +967,16 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr
*pcr)
return (u8 *)(pcr-host_cmds_ptr);
}
+static inline int rtsx_pci_update_cfg_byte(struct rtsx_pcr *pcr, int addr,
+ u8 mask, u8 append)
+{
+ int err;
+ u8 val;
+
+ err = pci_read_config_byte(pcr-pci, addr, val);
+ if (err 0)
+ return err;
+ return pci_write_config_byte(pcr-pci, addr, (val mask) | append);
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] mfd: rtsx: fix PM suspend for 5227 5249
On Thu, 18 Sep 2014, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Fix rts52275249 failed send buffer cmd after suspend,
PM_CTRL3 should reset before send any buffer cmd after suspend.
Otherwise, buffer cmd will failed, this will lead resume fail.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mfd/rts5227.c| 19 +++
drivers/mfd/rts5249.c|4
drivers/mfd/rtsx_pcr.h |1 +
include/linux/mfd/rtsx_pci.h | 12
4 files changed, 36 insertions(+)
I think you'll find you just broke the build.
What happens when you compile these as modules?
diff --git a/drivers/mfd/rts5227.c b/drivers/mfd/rts5227.c
index 9c8eec8..8222a31 100644
--- a/drivers/mfd/rts5227.c
+++ b/drivers/mfd/rts5227.c
@@ -128,8 +128,27 @@ static int rts5227_extra_init_hw(struct rtsx_pcr *pcr)
return rtsx_pci_send_cmd(pcr, 100);
}
+int rts5227_pm_reset(struct rtsx_pcr *pcr)
+{
+ int err;
+
+ /* init aspm */
+ err = rtsx_pci_update_cfg_byte(pcr, LCTLR, 0xFC, 0);
+ if (err 0)
+ return err;
+
+ /* reset PM_CTRL3 before send buffer cmd */
+ return rtsx_pci_write_register(pcr, PM_CTRL3, 0x10, 0x00);
+}
+
static int rts5227_optimize_phy(struct rtsx_pcr *pcr)
{
+ int err;
+
+ err = rts5227_pm_reset(pcr);
+ if (err 0)
+ return err;
+
/* Optimize RX sensitivity */
return rtsx_pci_write_phy_register(pcr, 0x00, 0xBA42);
}
diff --git a/drivers/mfd/rts5249.c b/drivers/mfd/rts5249.c
index 573de7b..0f1b0e6 100644
--- a/drivers/mfd/rts5249.c
+++ b/drivers/mfd/rts5249.c
@@ -130,6 +130,10 @@ static int rts5249_optimize_phy(struct rtsx_pcr *pcr)
{
int err;
+ err = rts5227_pm_reset(pcr);
+ if (err 0)
+ return err;
I don't like this. Place rts52xx_pm_reset() somewhere more central.
Perhaps an inline function in the header would be better?
err = rtsx_pci_write_phy_register(pcr, PHY_REG_REV,
PHY_REG_REV_RESV | PHY_REG_REV_RXIDLE_LATCHED |
PHY_REG_REV_P1_EN | PHY_REG_REV_RXIDLE_EN |
diff --git a/drivers/mfd/rtsx_pcr.h b/drivers/mfd/rtsx_pcr.h
index 07e4c2e..acc7a1e 100644
--- a/drivers/mfd/rtsx_pcr.h
+++ b/drivers/mfd/rtsx_pcr.h
@@ -72,4 +72,5 @@ do {
\
pcr-ms_pull_ctl_disable_tbl = __device##_ms_pull_ctl_disable_tbl; \
} while (0)
+int rts5227_pm_reset(struct rtsx_pcr *pcr);
#endif
diff --git a/include/linux/mfd/rtsx_pci.h b/include/linux/mfd/rtsx_pci.h
index 74346d5..b34fec8 100644
--- a/include/linux/mfd/rtsx_pci.h
+++ b/include/linux/mfd/rtsx_pci.h
@@ -967,4 +967,16 @@ static inline u8 *rtsx_pci_get_cmd_data(struct rtsx_pcr
*pcr)
return (u8 *)(pcr-host_cmds_ptr);
}
+static inline int rtsx_pci_update_cfg_byte(struct rtsx_pcr *pcr, int addr,
+ u8 mask, u8 append)
+{
+ int err;
+ u8 val;
+
+ err = pci_read_config_byte(pcr-pci, addr, val);
+ if (err 0)
+ return err;
+ return pci_write_config_byte(pcr-pci, addr, (val mask) | append);
+}
+
#endif
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 0/2] mmc: rtsx: add support for async request
Chris, Ulf, Sorry for the delay, things have been hectic. The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1: Linux 3.16-rc4 (2014-07-06 12:37:51 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git tags/mfd-mmc-v3.17 for you to fetch changes up to 6291e7153a173f85bbdb13bf0c72fa11b5d74bc0: mmc: rtsx: add support for async request (2014-07-09 14:17:15 +0100) Immutable branch between MFD and MMC due for the v3.17 merge window. Micky Ching (2): mfd: rtsx: Add dma transfer function mmc: rtsx: add support for async request drivers/mfd/rtsx_pcr.c| 76 ++ drivers/mmc/host/rtsx_pci_sdmmc.c | 133 -- include/linux/mfd/rtsx_pci.h | 6 ++ 3 files changed, 181 insertions(+), 34 deletions(-) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] mfd: rtsx: add dma transfer function
On Wed, 02 Jul 2014, micky wrote: On 06/18/2014 04:00 PM, Lee Jones wrote: On Mon, 16 Jun 2014, Ulf Hansson wrote: On 16 June 2014 14:20, Lee Jones lee.jo...@linaro.org wrote: From: Micky Ching micky_ch...@realsil.com.cn rtsx driver using a single function for transfer data, dma map/unmap are placed in one fix function. We need map/unmap dma in different place(for mmc async driver), so add three function for dma map, dma transfer and dma unmap. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- drivers/mfd/rtsx_pcr.c | 76 ++ include/linux/mfd/rtsx_pci.h |6 2 files changed, 54 insertions(+), 28 deletions(-) I don't see any glaring issues with this patch. Does it rely on the first patch, or vise versa, or can it just be applied? The mmc part in patch2 relies on this one, but please go ahead and apply the mfd patch if you see it good. I can later provide my ack for the mmc parts, in patch2, when it's a reviewed properly and thus you can take it through your tree. There's no rush. Once you're happy with the MMC patch, Micky can submit them both again with my Ack on the MFD part and I'll take them as a set. Hi Lee, Can you pick this patch directly? need resend it now? No need to resend, I'll get round to applying it from here. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] mfd: rtsx: add dma transfer function
On Mon, 16 Jun 2014, Ulf Hansson wrote: On 16 June 2014 14:20, Lee Jones lee.jo...@linaro.org wrote: From: Micky Ching micky_ch...@realsil.com.cn rtsx driver using a single function for transfer data, dma map/unmap are placed in one fix function. We need map/unmap dma in different place(for mmc async driver), so add three function for dma map, dma transfer and dma unmap. Signed-off-by: Micky Ching micky_ch...@realsil.com.cn --- drivers/mfd/rtsx_pcr.c | 76 ++ include/linux/mfd/rtsx_pci.h |6 2 files changed, 54 insertions(+), 28 deletions(-) I don't see any glaring issues with this patch. Does it rely on the first patch, or vise versa, or can it just be applied? The mmc part in patch2 relies on this one, but please go ahead and apply the mfd patch if you see it good. I can later provide my ack for the mmc parts, in patch2, when it's a reviewed properly and thus you can take it through your tree. There's no rush. Once you're happy with the MMC patch, Micky can submit them both again with my Ack on the MFD part and I'll take them as a set. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] mfd: rtsx: add dma transfer function
, + int num_sg, bool read); +void rtsx_pci_dma_unmap_sg(struct rtsx_pcr *pcr, struct scatterlist *sglist, + int num_sg, bool read); +int rtsx_pci_dma_transfer(struct rtsx_pcr *pcr, struct scatterlist *sglist, + int count, bool read, int timeout); int rtsx_pci_read_ppbuf(struct rtsx_pcr *pcr, u8 *buf, int buf_len); int rtsx_pci_write_ppbuf(struct rtsx_pcr *pcr, u8 *buf, int buf_len); int rtsx_pci_card_pull_ctl_enable(struct rtsx_pcr *pcr, int card); -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 1/2] mmc: rtsx: Revert mmc: rtsx: modify error handleandremove smatch warnings
It seems Chris is too busy to responding, so would you help to pick this patch for 3.15 fix. H... that's pretty bad timing. I've literally just sent the pull-request containing the MFD/MMC fixup branch to Linus. I guess Ulf will have to do it. From: Micky Chingmicky_ch...@realsil.com.cn This reverts commit 1f7b581b3ffcb2a8437397a02f4af89fa6934d08. The patch depend on commit c42deffd5b53c9e583d83c7964854ede2f12410d mmc: rtsx: add support for pre_req and post_req, but the previous patch was discard. So we have to delete the patch. Signed-off-by: Micky Chingmicky_ch...@realsil.com.cn Acked-by: Ulf Hanssonulf.hans...@linaro.org -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
