Re: [PATCH] clk: sunxi-ng: v3s: add support for variable rate audio pll output
于 2021年2月18日 GMT+08:00 下午5:18:39, Tobias Schramm 写到: >Hi Icenowy, > > > We have introducee SDM-based accurate audio PLL on several >> other SoCs. Some people is quite sensitive about audio-related >things. > > >While it is possible to support 24MHz * 128 / 25 / 5 = 24.576MHz >without >delta sigma modulation, matching 22.5792MHz is indeed not possible. I >read you'd prefer me to use SDM like the other SoCs though? Shall I >send >a v2 utilizing SDM? Yes, I think so. > >Cheers, >Tobias
Re: [PATCH] clk: sunxi-ng: v3s: add support for variable rate audio pll output
于 2021年2月18日 GMT+08:00 下午3:58:35, Maxime Ripard 写到: >Hi, > >On Fri, Feb 12, 2021 at 02:57:25PM +0100, Tobias Schramm wrote: >> Previously the variable rate audio pll output was fixed to a divider >of >> four. This is unfortunately incompatible with generating commonly >used >> I2S core clock rates like 24.576MHz from the 24MHz parent clock. >> This commit adds support for arbitrary audio pll output dividers to >fix >> that. >> >> Signed-off-by: Tobias Schramm > >It's not really clear to me how that would help. We have introducee SDM-based accurate audio PLL on several other SoCs. Some people is quite sensitive about audio-related things. > >The closest frequency we can provide for 24.576MHz would be 24580645 >Hz, >with N = 127, M = 31 and P = 4, so it would work with what we have >already? > >Maxime
Re: [PATCH v3] ovl: use a dedicated semaphore for dir upperfile caching
在 2021-01-21星期四的 09:07 +0100，Miklos Szeredi写道：
> On Thu, Jan 21, 2021 at 4:43 AM Icenowy Zheng
> wrote:
> >
> > 在 2021-01-20星期三的 11:20 +0100，Miklos Szeredi写道：
> > > On Tue, Jan 05, 2021 at 08:47:41AM +0200, Amir Goldstein wrote:
> > > > On Tue, Jan 5, 2021 at 2:36 AM Icenowy Zheng
> > > > wrote:
> > > > >
> > > > > The function ovl_dir_real_file() currently uses the semaphore
> > > > > of
> > > > > the
> > > > > inode to synchronize write to the upperfile cache field.
> > > >
> > > > Although the inode lock is a rw_sem it is referred to as the
> > > > "inode
> > > > lock"
> > > > and you also left semaphore in the commit subject.
> > > > No need to re-post. This can be fixed on commit.
> > > >
> > > > >
> > > > > However, this function will get called by
> > > > > ovl_ioctl_set_flags(),
> > > > > which
> > > > > utilizes the inode semaphore too. In this case
> > > > > ovl_dir_real_file() will
> > > > > try to claim a lock that is owned by a function in its call
> > > > > stack, which
> > > > > won't get released before ovl_dir_real_file() returns.
> > > > >
> > > > > Define a dedicated semaphore for the upperfile cache, so that
> > > > > the
> > > > > deadlock won't happen.
> > > > >
> > > > > Fixes: 61536bed2149 ("ovl: support [S|G]ETFLAGS and
> > > > > FS[S|G]ETXATTR ioctls for directories")
> > > > > Cc: sta...@vger.kernel.org # v5.10
> > > > > Signed-off-by: Icenowy Zheng
> > > > > ---
> > > > > Changes in v2:
> > > > > - Fixed missing replacement in error handling path.
> > > > > Changes in v3:
> > > > > - Use mutex instead of semaphore.
> > > > >
> > > > > fs/overlayfs/readdir.c | 10 +-
> > > > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
> > > > > index 01620ebae1bd..3980f9982f34 100644
> > > > > --- a/fs/overlayfs/readdir.c
> > > > > +++ b/fs/overlayfs/readdir.c
> > > > > @@ -56,6 +56,7 @@ struct ovl_dir_file {
> > > > > struct list_head *cursor;
> > > > > struct file *realfile;
> > > > > struct file *upperfile;
> > > > > + struct mutex upperfile_mutex;
> > > >
> > > > That's a very specific name.
> > > > This mutex protects members of struct ovl_dir_file, which could
> > > > evolve
> > > > into struct ovl_file one day (because no reason to cache only
> > > > dir
> > > > upper file),
> > > > so I would go with a more generic name, but let's leave it to
> > > > Miklos to decide.
> > > >
> > > > He could have a different idea altogether for fixing this bug.
> > >
> > > How about this (untested) patch?
> > >
> > > It's a cleanup as well as a fix, but maybe we should separate the
> > > cleanup from
> > > the fix...
> >
> > If you are going to post this, feel free to add
> >
> > Tested-by: Icenowy Zheng
>
> Okay, thanks.
>
> > (And if you remove the IS_ERR(realfile) part, the tested-by tag
> > still
> > applies.)
>
> Dropping the IS_ERR(realfile) here would mean having to add the same
> check before relevant fput() calls, which would make it more complex
> not less.
>
> Or did you mean something else?
I mean "seperate the cleanup from the fix".
This is only for when you do the seperation.
>
> Thanks,
> Miklos
Re: [PATCH v3] ovl: use a dedicated semaphore for dir upperfile caching
在 2021-01-20星期三的 11:20 +0100，Miklos Szeredi写道：
> On Tue, Jan 05, 2021 at 08:47:41AM +0200, Amir Goldstein wrote:
> > On Tue, Jan 5, 2021 at 2:36 AM Icenowy Zheng
> > wrote:
> > >
> > > The function ovl_dir_real_file() currently uses the semaphore of
> > > the
> > > inode to synchronize write to the upperfile cache field.
> >
> > Although the inode lock is a rw_sem it is referred to as the "inode
> > lock"
> > and you also left semaphore in the commit subject.
> > No need to re-post. This can be fixed on commit.
> >
> > >
> > > However, this function will get called by ovl_ioctl_set_flags(),
> > > which
> > > utilizes the inode semaphore too. In this case
> > > ovl_dir_real_file() will
> > > try to claim a lock that is owned by a function in its call
> > > stack, which
> > > won't get released before ovl_dir_real_file() returns.
> > >
> > > Define a dedicated semaphore for the upperfile cache, so that the
> > > deadlock won't happen.
> > >
> > > Fixes: 61536bed2149 ("ovl: support [S|G]ETFLAGS and
> > > FS[S|G]ETXATTR ioctls for directories")
> > > Cc: sta...@vger.kernel.org # v5.10
> > > Signed-off-by: Icenowy Zheng
> > > ---
> > > Changes in v2:
> > > - Fixed missing replacement in error handling path.
> > > Changes in v3:
> > > - Use mutex instead of semaphore.
> > >
> > > fs/overlayfs/readdir.c | 10 +-
> > > 1 file changed, 5 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
> > > index 01620ebae1bd..3980f9982f34 100644
> > > --- a/fs/overlayfs/readdir.c
> > > +++ b/fs/overlayfs/readdir.c
> > > @@ -56,6 +56,7 @@ struct ovl_dir_file {
> > > struct list_head *cursor;
> > > struct file *realfile;
> > > struct file *upperfile;
> > > + struct mutex upperfile_mutex;
> >
> > That's a very specific name.
> > This mutex protects members of struct ovl_dir_file, which could
> > evolve
> > into struct ovl_file one day (because no reason to cache only dir
> > upper file),
> > so I would go with a more generic name, but let's leave it to
> > Miklos to decide.
> >
> > He could have a different idea altogether for fixing this bug.
>
> How about this (untested) patch?
>
> It's a cleanup as well as a fix, but maybe we should separate the
> cleanup from
> the fix...
If you are going to post this, feel free to add
Tested-by: Icenowy Zheng
(And if you remove the IS_ERR(realfile) part, the tested-by tag still
applies.)
>
> Thanks,
> Miklos
> ---
>
> fs/overlayfs/readdir.c | 23 +++
> 1 file changed, 7 insertions(+), 16 deletions(-)
>
> --- a/fs/overlayfs/readdir.c
> +++ b/fs/overlayfs/readdir.c
> @@ -865,7 +865,7 @@ struct file *ovl_dir_real_file(const str
>
> struct ovl_dir_file *od = file->private_data;
> struct dentry *dentry = file->f_path.dentry;
> - struct file *realfile = od->realfile;
> + struct file *old, *realfile = od->realfile;
>
> if (!OVL_TYPE_UPPER(ovl_path_type(dentry)))
> return want_upper ? NULL : realfile;
> @@ -874,29 +874,20 @@ struct file *ovl_dir_real_file(const str
> * Need to check if we started out being a lower dir, but got
> copied up
> */
> if (!od->is_upper) {
> - struct inode *inode = file_inode(file);
> -
> realfile = READ_ONCE(od->upperfile);
> if (!realfile) {
> struct path upperpath;
>
> ovl_path_upper(dentry, &upperpath);
> realfile = ovl_dir_open_realfile(file,
> &upperpath);
> + if (IS_ERR(realfile))
> + return realfile;
>
> - inode_lock(inode);
> - if (!od->upperfile) {
> - if (IS_ERR(realfile)) {
> - inode_unlock(inode);
> - return realfile;
> - }
> - smp_store_release(&od->upperfile,
> realfile);
> - } else {
> - /* somebody has beaten us to it */
> - if (!IS_ERR(realfile))
> - fput(realfile);
> - realfile = od->upperfile;
> + old = cmpxchg_release(&od->upperfile, NULL,
> realfile);
> + if (old) {
> + fput(realfile);
> + realfile = old;
> }
> - inode_unlock(inode);
> }
> }
>
Re: [PATCH] drm/panel: feiyang-fy07024di26a30d: cleanup if panel attaching failed
于 2021年1月6日 GMT+08:00 下午5:47:20, Jagan Teki 写到:
>On Sat, Nov 28, 2020 at 6:23 PM Icenowy Zheng wrote:
>>
>> Attaching the panel can fail, so cleanup work is necessary, otherwise
>> a pointer to freed struct drm_panel* will remain in drm_panel code.
>>
>> Do the cleanup if panel attaching failed.
>>
>> Fixes: 69dc678abc2b ("drm/panel: Add Feiyang FY07024DI26A30-D
>MIPI-DSI LCD panel")
>
>The fact that this has failed to probe due to recent changes in
>sun6i_mipi_dsi.c I don't know how to put that into the commit message.
It's not related, we shouldn't assume this panel driver will always
be used with sunxi SoCs.
It's a panel driver bug that cannot deal with -EPROBE_DEFER well.
>> Signed-off-by: Icenowy Zheng
>> ---
>
>Reviewed-by: Jagan Teki
[PATCH v3] ovl: use a dedicated semaphore for dir upperfile caching
The function ovl_dir_real_file() currently uses the semaphore of the
inode to synchronize write to the upperfile cache field.
However, this function will get called by ovl_ioctl_set_flags(), which
utilizes the inode semaphore too. In this case ovl_dir_real_file() will
try to claim a lock that is owned by a function in its call stack, which
won't get released before ovl_dir_real_file() returns.
Define a dedicated semaphore for the upperfile cache, so that the
deadlock won't happen.
Fixes: 61536bed2149 ("ovl: support [S|G]ETFLAGS and FS[S|G]ETXATTR ioctls for
directories")
Cc: sta...@vger.kernel.org # v5.10
Signed-off-by: Icenowy Zheng
---
Changes in v2:
- Fixed missing replacement in error handling path.
Changes in v3:
- Use mutex instead of semaphore.
fs/overlayfs/readdir.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
index 01620ebae1bd..3980f9982f34 100644
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -56,6 +56,7 @@ struct ovl_dir_file {
struct list_head *cursor;
struct file *realfile;
struct file *upperfile;
+ struct mutex upperfile_mutex;
};
static struct ovl_cache_entry *ovl_cache_entry_from_node(struct rb_node *n)
@@ -874,8 +875,6 @@ struct file *ovl_dir_real_file(const struct file *file,
bool want_upper)
* Need to check if we started out being a lower dir, but got copied up
*/
if (!od->is_upper) {
- struct inode *inode = file_inode(file);
-
realfile = READ_ONCE(od->upperfile);
if (!realfile) {
struct path upperpath;
@@ -883,10 +882,10 @@ struct file *ovl_dir_real_file(const struct file *file,
bool want_upper)
ovl_path_upper(dentry, &upperpath);
realfile = ovl_dir_open_realfile(file, &upperpath);
- inode_lock(inode);
+ mutex_lock(&od->upperfile_mutex);
if (!od->upperfile) {
if (IS_ERR(realfile)) {
- inode_unlock(inode);
+ mutex_unlock(&od->upperfile_mutex);
return realfile;
}
smp_store_release(&od->upperfile, realfile);
@@ -896,7 +895,7 @@ struct file *ovl_dir_real_file(const struct file *file,
bool want_upper)
fput(realfile);
realfile = od->upperfile;
}
- inode_unlock(inode);
+ mutex_unlock(&od->upperfile_mutex);
}
}
@@ -959,6 +958,7 @@ static int ovl_dir_open(struct inode *inode, struct file
*file)
od->realfile = realfile;
od->is_real = ovl_dir_is_real(file->f_path.dentry);
od->is_upper = OVL_TYPE_UPPER(type);
+ mutex_init(&od->upperfile_mutex);
file->private_data = od;
return 0;
--
2.28.0
Re: [PATCH v2] ovl: use a dedicated semaphore for dir upperfile caching
于 2021年1月4日 GMT+08:00 下午3:28:35, Icenowy Zheng 写到:
>The function ovl_dir_real_file() currently uses the semaphore of the
>inode to synchronize write to the upperfile cache field.
>
>However, this function will get called by ovl_ioctl_set_flags(), which
>utilizes the inode semaphore too. In this case ovl_dir_real_file() will
>try to claim a lock that is owned by a function in its call stack,
>which
>won't get released before ovl_dir_real_file() returns.
>
>Define a dedicated semaphore for the upperfile cache, so that the
>deadlock won't happen.
>
>Fixes: 61536bed2149 ("ovl: support [S|G]ETFLAGS and FS[S|G]ETXATTR
>ioctls for directories")
>Cc: sta...@vger.kernel.org # v5.10
>Signed-off-by: Icenowy Zheng
>---
Sorry for lack of changelog.
A missing replacement of inode_lock() is added in v2.
> fs/overlayfs/readdir.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
>diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
>index 01620ebae1bd..fa1844ff8db4 100644
>--- a/fs/overlayfs/readdir.c
>+++ b/fs/overlayfs/readdir.c
>@@ -56,6 +56,7 @@ struct ovl_dir_file {
> struct list_head *cursor;
> struct file *realfile;
> struct file *upperfile;
>+ struct semaphore upperfile_sem;
> };
>
>static struct ovl_cache_entry *ovl_cache_entry_from_node(struct rb_node
>*n)
>@@ -874,8 +875,6 @@ struct file *ovl_dir_real_file(const struct file
>*file, bool want_upper)
>* Need to check if we started out being a lower dir, but got copied
>up
>*/
> if (!od->is_upper) {
>- struct inode *inode = file_inode(file);
>-
> realfile = READ_ONCE(od->upperfile);
> if (!realfile) {
> struct path upperpath;
>@@ -883,10 +882,10 @@ struct file *ovl_dir_real_file(const struct file
>*file, bool want_upper)
> ovl_path_upper(dentry, &upperpath);
> realfile = ovl_dir_open_realfile(file, &upperpath);
>
>- inode_lock(inode);
>+ down(&od->upperfile_sem);
> if (!od->upperfile) {
> if (IS_ERR(realfile)) {
>- inode_unlock(inode);
>+ up(&od->upperfile_sem);
> return realfile;
> }
> smp_store_release(&od->upperfile, realfile);
>@@ -896,7 +895,7 @@ struct file *ovl_dir_real_file(const struct file
>*file, bool want_upper)
> fput(realfile);
> realfile = od->upperfile;
> }
>- inode_unlock(inode);
>+ up(&od->upperfile_sem);
> }
> }
>
>@@ -959,6 +958,7 @@ static int ovl_dir_open(struct inode *inode, struct
>file *file)
> od->realfile = realfile;
> od->is_real = ovl_dir_is_real(file->f_path.dentry);
> od->is_upper = OVL_TYPE_UPPER(type);
>+ sema_init(&od->upperfile_sem, 1);
> file->private_data = od;
>
> return 0;
Re: [PATCH] ovl: use a dedicated semaphore for dir upperfile caching
于 2021年1月4日 GMT+08:00 下午4:35:20, Amir Goldstein 写到:
>On Mon, Jan 4, 2021 at 9:28 AM Icenowy Zheng wrote:
>>
>> 在 2021-01-03星期日的 16:10 +0200，Amir Goldstein写道：
>> > On Fri, Jan 1, 2021 at 10:12 PM Icenowy Zheng
>> > wrote:
>> > >
>> > > The function ovl_dir_real_file() currently uses the semaphore of
>> > > the
>> > > inode to synchronize write to the upperfile cache field.
>> > >
>> > > However, this function will get called by ovl_ioctl_set_flags(),
>> > > which
>> > > utilizes the inode semaphore too. In this case
>ovl_dir_real_file()
>> > > will
>> > > try to claim a lock that is owned by a function in its call
>stack,
>> > > which
>> > > won't get released before ovl_dir_real_file() returns.
>> >
>> > oops. I wondered why I didn't see any warnings on this from
>lockdep.
>> > Ah! because the xfstest that exercises ovl_ioctl_set_flags() on
>> > directory,
>> > generic/079, starts with an already upper dir.
>> >
>> > And the xfstest that checks chattr+i on lower/upper files,
>> > overlay/040,
>> > does not check chattr on dirs (ioctl on overlay dirs wasn't
>supported
>> > at
>> > the time the test was written).
>> >
>> > Would you be able to create a variant of test overlay/040 that also
>> > tests
>> > chattr +i on lower/upper dirs to test your patch and confirm that
>the
>> > test
>> > fails on master with the appropriate Kconfig debug options.
>>
>> https://gist.github.com/Icenowy/c7d8decb6812d6e5064d143c57281ad3
>>
>> Here's a test that would break on master (I used linux-next/master
>for
>> test).
>
>Thanks.
>I am working on another test to improve overlay/030 that may also
>cover this bug, so maybe no need for both tests. I'll let you know when
>I'm done.
>If you like, I can post your test for you with your Signed-of-by if I
>think
>it is also needed.
>
>>
>> [ 246.521880] INFO: task chattr:715 blocked for more than 122
>seconds.
>> [ 246.525659] Not tainted 5.11.0-rc1-next-20210104+ #20
>> [ 246.528498] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>> disables this message.
>> [ 246.535076] task:chattr state:D stack:13736 pid: 715
>ppid:
>> 529 flags:0x
>> [ 246.538923] Call Trace:
>> [ 246.540241] __schedule+0x2a9/0x820
>> [ 246.541986] schedule+0x56/0xc0
>> [ 246.543616] rwsem_down_write_slowpath+0x375/0x630
>> [ 246.545565] ovl_dir_real_file+0xc1/0x120
>> [ 246.547512] ovl_real_fdget+0x35/0x80
>> [ 246.549303] ovl_real_ioctl+0x26/0x90
>> [ 246.551050] ? mnt_drop_write+0x2c/0x70
>> [ 246.553068] ovl_ioctl_set_flags+0x93/0x110
>> [ 246.555407] __x64_sys_ioctl+0x7e/0xb0
>> [ 246.557175] do_syscall_64+0x33/0x40
>> [ 246.558869] entry_SYSCALL_64_after_hwframe+0x44/0xa9
>> [ 246.561057] RIP: 0033:0x7fe4a3830b67
>> [ 246.565799] RSP: 002b:7ffe7ad504f8 EFLAGS: 0246 ORIG_RAX:
>> 0010
>> [ 246.569438] RAX: ffda RBX: 0001 RCX:
>> 7fe4a3830b67
>> [ 246.572061] RDX: 7ffe7ad5050c RSI: 40086602 RDI:
>> 0003
>> [ 246.575509] RBP: 0003 R08: 0001 R09:
>>
>> [ 246.578932] R10: R11: 0246 R12:
>> 0010
>> [ 246.581014] R13: 7ffe7ad50810 R14: 0002 R15:
>> 0001
>> [ 246.582818]
>> [ 246.582818] Showing all locks held in the system:
>> [ 246.584741] 1 lock held by khungtaskd/18:
>> [ 246.586085] #0: 9e951540 (rcu_read_lock){}-{1:2}, at:
>> debug_show_all_locks+0x15/0x100
>> [ 246.589775] 3 locks held by chattr/715:
>> [ 246.591364] #0: 96a74b92c450 (sb_writers#11){}-{0:0}, at:
>> ovl_ioctl_set_flags+0x2f/0x110
>> [ 246.597182] #1: 96a7489c3500
>> (&ovl_i_mutex_dir_key[depth]){}-{3:3}, at:
>> ovl_ioctl_set_flags+0x54/0x110
>> [ 246.601325] #2: 96a7489c3500
>> (&ovl_i_mutex_dir_key[depth]){}-{3:3}, at:
>> ovl_dir_real_file+0xc1/0x120
>>
>> >
>> > >
>> > > Define a dedicated semaphore for the upperfile cache, so that the
>> > > deadlock won't happen.
>> > >
>> > > Fixes: 61536bed2149 ("ovl: support [S|G]ETFLAGS and
>FS[S|G]ETXATTR
>> > > ioctls for directories")
>> > > Cc: sta...@vger.kernel.org # v5.10
>> > > Signed-off-by: Icenowy Zheng
>> > > ---
>> > > fs/overlayfs/readdir.c | 6 --
>> > > 1 file changed, 4 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
>> > > index 01620ebae1bd..f10701aabb71 100644
>> > > --- a/fs/overlayfs/readdir.c
>> > > +++ b/fs/overlayfs/readdir.c
>> > > @@ -56,6 +56,7 @@ struct ovl_dir_file {
>> > > struct list_head *cursor;
>> > > struct file *realfile;
>> > > struct file *upperfile;
>> > > + struct semaphore upperfile_sem;
>> >
>> > mutex please
>> >
>
>You missed this comment.
>semaphore is discouraged as a locking primitive.
>Please use struct mutex.
Okay, sorry.
I will check it out.
>
>Thanks,
>Amir.
[PATCH v2] ovl: use a dedicated semaphore for dir upperfile caching
The function ovl_dir_real_file() currently uses the semaphore of the
inode to synchronize write to the upperfile cache field.
However, this function will get called by ovl_ioctl_set_flags(), which
utilizes the inode semaphore too. In this case ovl_dir_real_file() will
try to claim a lock that is owned by a function in its call stack, which
won't get released before ovl_dir_real_file() returns.
Define a dedicated semaphore for the upperfile cache, so that the
deadlock won't happen.
Fixes: 61536bed2149 ("ovl: support [S|G]ETFLAGS and FS[S|G]ETXATTR ioctls for
directories")
Cc: sta...@vger.kernel.org # v5.10
Signed-off-by: Icenowy Zheng
---
fs/overlayfs/readdir.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
index 01620ebae1bd..fa1844ff8db4 100644
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -56,6 +56,7 @@ struct ovl_dir_file {
struct list_head *cursor;
struct file *realfile;
struct file *upperfile;
+ struct semaphore upperfile_sem;
};
static struct ovl_cache_entry *ovl_cache_entry_from_node(struct rb_node *n)
@@ -874,8 +875,6 @@ struct file *ovl_dir_real_file(const struct file *file,
bool want_upper)
* Need to check if we started out being a lower dir, but got copied up
*/
if (!od->is_upper) {
- struct inode *inode = file_inode(file);
-
realfile = READ_ONCE(od->upperfile);
if (!realfile) {
struct path upperpath;
@@ -883,10 +882,10 @@ struct file *ovl_dir_real_file(const struct file *file,
bool want_upper)
ovl_path_upper(dentry, &upperpath);
realfile = ovl_dir_open_realfile(file, &upperpath);
- inode_lock(inode);
+ down(&od->upperfile_sem);
if (!od->upperfile) {
if (IS_ERR(realfile)) {
- inode_unlock(inode);
+ up(&od->upperfile_sem);
return realfile;
}
smp_store_release(&od->upperfile, realfile);
@@ -896,7 +895,7 @@ struct file *ovl_dir_real_file(const struct file *file,
bool want_upper)
fput(realfile);
realfile = od->upperfile;
}
- inode_unlock(inode);
+ up(&od->upperfile_sem);
}
}
@@ -959,6 +958,7 @@ static int ovl_dir_open(struct inode *inode, struct file
*file)
od->realfile = realfile;
od->is_real = ovl_dir_is_real(file->f_path.dentry);
od->is_upper = OVL_TYPE_UPPER(type);
+ sema_init(&od->upperfile_sem, 1);
file->private_data = od;
return 0;
--
2.28.0
Re: [PATCH] ovl: use a dedicated semaphore for dir upperfile caching
在 2021-01-03星期日的 16:10 +0200，Amir Goldstein写道：
> On Fri, Jan 1, 2021 at 10:12 PM Icenowy Zheng
> wrote:
> >
> > The function ovl_dir_real_file() currently uses the semaphore of
> > the
> > inode to synchronize write to the upperfile cache field.
> >
> > However, this function will get called by ovl_ioctl_set_flags(),
> > which
> > utilizes the inode semaphore too. In this case ovl_dir_real_file()
> > will
> > try to claim a lock that is owned by a function in its call stack,
> > which
> > won't get released before ovl_dir_real_file() returns.
>
> oops. I wondered why I didn't see any warnings on this from lockdep.
> Ah! because the xfstest that exercises ovl_ioctl_set_flags() on
> directory,
> generic/079, starts with an already upper dir.
>
> And the xfstest that checks chattr+i on lower/upper files,
> overlay/040,
> does not check chattr on dirs (ioctl on overlay dirs wasn't supported
> at
> the time the test was written).
>
> Would you be able to create a variant of test overlay/040 that also
> tests
> chattr +i on lower/upper dirs to test your patch and confirm that the
> test
> fails on master with the appropriate Kconfig debug options.
https://gist.github.com/Icenowy/c7d8decb6812d6e5064d143c57281ad3
Here's a test that would break on master (I used linux-next/master for
test).
[ 246.521880] INFO: task chattr:715 blocked for more than 122 seconds.
[ 246.525659] Not tainted 5.11.0-rc1-next-20210104+ #20
[ 246.528498] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
disables this message.
[ 246.535076] task:chattr state:D stack:13736 pid: 715 ppid:
529 flags:0x
[ 246.538923] Call Trace:
[ 246.540241] __schedule+0x2a9/0x820
[ 246.541986] schedule+0x56/0xc0
[ 246.543616] rwsem_down_write_slowpath+0x375/0x630
[ 246.545565] ovl_dir_real_file+0xc1/0x120
[ 246.547512] ovl_real_fdget+0x35/0x80
[ 246.549303] ovl_real_ioctl+0x26/0x90
[ 246.551050] ? mnt_drop_write+0x2c/0x70
[ 246.553068] ovl_ioctl_set_flags+0x93/0x110
[ 246.555407] __x64_sys_ioctl+0x7e/0xb0
[ 246.557175] do_syscall_64+0x33/0x40
[ 246.558869] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 246.561057] RIP: 0033:0x7fe4a3830b67
[ 246.565799] RSP: 002b:7ffe7ad504f8 EFLAGS: 0246 ORIG_RAX:
0010
[ 246.569438] RAX: ffda RBX: 0001 RCX:
7fe4a3830b67
[ 246.572061] RDX: 7ffe7ad5050c RSI: 40086602 RDI:
0003
[ 246.575509] RBP: 0003 R08: 0001 R09:
[ 246.578932] R10: R11: 0246 R12:
0010
[ 246.581014] R13: 7ffe7ad50810 R14: 0002 R15:
0001
[ 246.582818]
[ 246.582818] Showing all locks held in the system:
[ 246.584741] 1 lock held by khungtaskd/18:
[ 246.586085] #0: 9e951540 (rcu_read_lock){}-{1:2}, at:
debug_show_all_locks+0x15/0x100
[ 246.589775] 3 locks held by chattr/715:
[ 246.591364] #0: 96a74b92c450 (sb_writers#11){}-{0:0}, at:
ovl_ioctl_set_flags+0x2f/0x110
[ 246.597182] #1: 96a7489c3500
(&ovl_i_mutex_dir_key[depth]){}-{3:3}, at:
ovl_ioctl_set_flags+0x54/0x110
[ 246.601325] #2: 96a7489c3500
(&ovl_i_mutex_dir_key[depth]){}-{3:3}, at:
ovl_dir_real_file+0xc1/0x120
>
> >
> > Define a dedicated semaphore for the upperfile cache, so that the
> > deadlock won't happen.
> >
> > Fixes: 61536bed2149 ("ovl: support [S|G]ETFLAGS and FS[S|G]ETXATTR
> > ioctls for directories")
> > Cc: sta...@vger.kernel.org # v5.10
> > Signed-off-by: Icenowy Zheng
> > ---
> > fs/overlayfs/readdir.c | 6 --
> > 1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
> > index 01620ebae1bd..f10701aabb71 100644
> > --- a/fs/overlayfs/readdir.c
> > +++ b/fs/overlayfs/readdir.c
> > @@ -56,6 +56,7 @@ struct ovl_dir_file {
> > struct list_head *cursor;
> > struct file *realfile;
> > struct file *upperfile;
> > + struct semaphore upperfile_sem;
>
> mutex please
>
> > };
> >
> > static struct ovl_cache_entry *ovl_cache_entry_from_node(struct
> > rb_node *n)
> > @@ -883,7 +884,7 @@ struct file *ovl_dir_real_file(const struct
> > file *file, bool want_upper)
> > ovl_path_upper(dentry, &upperpath);
> > realfile = ovl_dir_open_realfile(file,
> > &upperpath);
> >
> > - inode_lock(inode);
> > + down(&od->upperfile_sem);
> > if (!od->upperfile) {
> > if (IS_ERR(realfile)) {
> > inode_unlock(inode);
>
> You missed this unlock
Thanks, will send v2 now.
>
> Thanks,
> Amir.
[PATCH] ovl: use a dedicated semaphore for dir upperfile caching
The function ovl_dir_real_file() currently uses the semaphore of the
inode to synchronize write to the upperfile cache field.
However, this function will get called by ovl_ioctl_set_flags(), which
utilizes the inode semaphore too. In this case ovl_dir_real_file() will
try to claim a lock that is owned by a function in its call stack, which
won't get released before ovl_dir_real_file() returns.
Define a dedicated semaphore for the upperfile cache, so that the
deadlock won't happen.
Fixes: 61536bed2149 ("ovl: support [S|G]ETFLAGS and FS[S|G]ETXATTR ioctls for
directories")
Cc: sta...@vger.kernel.org # v5.10
Signed-off-by: Icenowy Zheng
---
fs/overlayfs/readdir.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fs/overlayfs/readdir.c b/fs/overlayfs/readdir.c
index 01620ebae1bd..f10701aabb71 100644
--- a/fs/overlayfs/readdir.c
+++ b/fs/overlayfs/readdir.c
@@ -56,6 +56,7 @@ struct ovl_dir_file {
struct list_head *cursor;
struct file *realfile;
struct file *upperfile;
+ struct semaphore upperfile_sem;
};
static struct ovl_cache_entry *ovl_cache_entry_from_node(struct rb_node *n)
@@ -883,7 +884,7 @@ struct file *ovl_dir_real_file(const struct file *file,
bool want_upper)
ovl_path_upper(dentry, &upperpath);
realfile = ovl_dir_open_realfile(file, &upperpath);
- inode_lock(inode);
+ down(&od->upperfile_sem);
if (!od->upperfile) {
if (IS_ERR(realfile)) {
inode_unlock(inode);
@@ -896,7 +897,7 @@ struct file *ovl_dir_real_file(const struct file *file,
bool want_upper)
fput(realfile);
realfile = od->upperfile;
}
- inode_unlock(inode);
+ up(&od->upperfile_sem);
}
}
@@ -959,6 +960,7 @@ static int ovl_dir_open(struct inode *inode, struct file
*file)
od->realfile = realfile;
od->is_real = ovl_dir_is_real(file->f_path.dentry);
od->is_upper = OVL_TYPE_UPPER(type);
+ sema_init(&od->upperfile_sem, 1);
file->private_data = od;
return 0;
--
2.28.0
[PATCH] drm/panel: ilitek-ili9881c: fix attach failure cleanup
When mipi_dsi_attach() fails (e.g. got a -EPROBE_DEFER), the panel should
be removed, otherwise a pointer to it will be kept and then lead to
use-after-free when DRM panel codes are called (e.g. the panel is probed
again).
Fix this by adding cleanup code after mipi_dsi_attach() failure.
Fixes: 26aec25593c2 ("drm/panel: Add Ilitek ILI9881c panel driver")
Cc: sta...@vger.kernel.org
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 0145129d7c66..22f2268f00f7 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -674,7 +674,13 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->lanes = 4;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_panel_remove(&ctx->panel);
+ return ret;
+ }
+
+ return 0;
}
static int ili9881c_dsi_remove(struct mipi_dsi_device *dsi)
--
2.28.0
[PATCH v2 3/3] dt-bindings: arm: sunxi: document orig PineTab DT as sample
As the original PineTab DT (which uses sun50i-a64-pinetab name) is only
for development samples, document this.
Signed-off-by: Icenowy Zheng
---
Documentation/devicetree/bindings/arm/sunxi.yaml | 2 +-
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml
b/Documentation/devicetree/bindings/arm/sunxi.yaml
index 8c62a1e2a498..7eec85be7ab9 100644
--- a/Documentation/devicetree/bindings/arm/sunxi.yaml
+++ b/Documentation/devicetree/bindings/arm/sunxi.yaml
@@ -695,7 +695,7 @@ properties:
- const: pine64,pinephone-1.2
- const: allwinner,sun50i-a64
- - description: Pine64 PineTab
+ - description: Pine64 PineTab, Development Sample
items:
- const: pine64,pinetab
- const: allwinner,sun50i-a64
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
index 0494bfaf2ffa..422a8507f674 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -14,7 +14,7 @@
#include
/ {
- model = "PineTab";
+ model = "PineTab, Development Sample";
compatible = "pine64,pinetab", "allwinner,sun50i-a64";
aliases {
--
2.28.0
[PATCH v2 2/3] arm64: allwinner: dts: a64: add DT for Early Adopter's PineTab
PineTabs since Early Adopter batch will use a new LCD panel.
Add device tree for PineTab with the new panel.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../sun50i-a64-pinetab-early-adopter.dts | 26 +++
2 files changed, 27 insertions(+)
create mode 100644
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-early-adopter.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index 211d1e9d4701..41ce680e5f8d 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.0.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-early-adopter.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-early-adopter.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-early-adopter.dts
new file mode 100644
index ..652fc0cce304
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-early-adopter.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pinetab.dts"
+
+/ {
+ model = "PineTab, Early Adopter's version";
+ compatible = "pine64,pinetab-early-adopter", "allwinner,sun50i-a64";
+};
+
+&dsi {
+ /delete-node/ panel@0;
+
+ panel@0 {
+ compatible = "feixin,k101-im2byl02";
+ reg = <0>;
+ power-supply = <®_dc1sw>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+ backlight = <&backlight>;
+ };
+};
--
2.28.0
[PATCH v2 1/3] dt-bindings: arm: sunxi: add PineTab Early Adopter edition
Early adopter's PineTabs (and further releases) will have a new LCD panel different with the one that is used when in development (because the old panel's supply discontinued). Add a new DT compatible for it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 6db32fbf813f..8c62a1e2a498 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -700,6 +700,11 @@ properties: - const: pine64,pinetab - const: allwinner,sun50i-a64 + - description: Pine64 PineTab, Early Adopter's batch (and maybe later ones) +items: + - const: pine64,pinetab-early-adopter + - const: allwinner,sun50i-a64 + - description: Pine64 SoPine Baseboard items: - const: pine64,sopine-baseboard -- 2.28.0
Re: [linux-sunxi] Re: [PATCH 1/3] dt-bindings: arm: sunxi: add PineTab new panel DT binding
在 2020-12-16星期三的 14:00 +0100，Maxime Ripard写道： > On Tue, Dec 15, 2020 at 06:59:33AM +0800, Icenowy Zheng wrote: > > 于 2020年12月14日 GMT+08:00 下午6:37:04, Maxime Ripard > > 写到: > > > On Thu, Dec 10, 2020 at 04:42:32PM +0800, Icenowy Zheng wrote: > > > > Early adopters' PineTabs (and all further releases) will have a > > > > new > > > LCD > > > > panel different with the one that is used when in development > > > (because > > > > the old panel's supply discontinued). > > > > > > > > Add a new DT compatible for it. > > > > > > > > Signed-off-by: Icenowy Zheng > > > > --- > > > > Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + > > > > 1 file changed, 5 insertions(+) > > > > > > > > diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml > > > b/Documentation/devicetree/bindings/arm/sunxi.yaml > > > > index 6db32fbf813f..73a6c8421172 100644 > > > > --- a/Documentation/devicetree/bindings/arm/sunxi.yaml > > > > +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml > > > > @@ -700,6 +700,11 @@ properties: > > > >- const: pine64,pinetab > > > >- const: allwinner,sun50i-a64 > > > > > > > > + - description: Pine64 PineTab with new LCD panel > > > > +items: > > > > + - const: pine64,pinetab-new-panel > > > > + - const: allwinner,sun50i-a64 > > > > + > > > > > > We're on the right track, but new panel seems a bit too vague. > > > What is > > > going to happen when they will change the panel again? > > > > > > pinetab-early-adopter seems more robust there > > > > This name will only match a batch. > > Look, I know the situation sucks. Can we actually move forward? Descriptive name will match more things. I think we should still have something descriptive, even if "new panel" is too generic. > > Maxime
Re: [linux-sunxi] Re: [PATCH 1/3] dt-bindings: arm: sunxi: add PineTab new panel DT binding
于 2020年12月14日 GMT+08:00 下午6:37:04, Maxime Ripard 写到: >On Thu, Dec 10, 2020 at 04:42:32PM +0800, Icenowy Zheng wrote: >> Early adopters' PineTabs (and all further releases) will have a new >LCD >> panel different with the one that is used when in development >(because >> the old panel's supply discontinued). >> >> Add a new DT compatible for it. >> >> Signed-off-by: Icenowy Zheng >> --- >> Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml >b/Documentation/devicetree/bindings/arm/sunxi.yaml >> index 6db32fbf813f..73a6c8421172 100644 >> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml >> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml >> @@ -700,6 +700,11 @@ properties: >>- const: pine64,pinetab >>- const: allwinner,sun50i-a64 >> >> + - description: Pine64 PineTab with new LCD panel >> +items: >> + - const: pine64,pinetab-new-panel >> + - const: allwinner,sun50i-a64 >> + > >We're on the right track, but new panel seems a bit too vague. What is >going to happen when they will change the panel again? > >pinetab-early-adopter seems more robust there This name will only match a batch. > >Maxime
Re: [RFC PATCH 05/12] pinctrl: sunxi: add pinctrl driver for V831/V833
于 2020年12月14日 GMT+08:00 下午10:21:18, Maxime Ripard 写到: >On Sat, Dec 12, 2020 at 12:04:23PM +0800, Icenowy Zheng wrote: >> V831/V833 are new chips from Allwinner. They're the same die with >> different package. >> >> Add a pinctrl driver for them. >> >> The difference between V831/V833 pinctrl is implemented based on the >> user manual. >> >> Cc: Linus Walleij >> Cc: linux-g...@vger.kernel.org >> Signed-off-by: Icenowy Zheng >> --- >> drivers/pinctrl/sunxi/Kconfig | 5 + >> drivers/pinctrl/sunxi/Makefile | 1 + >> drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c | 743 >+ >> drivers/pinctrl/sunxi/pinctrl-sunxi.h | 2 + >> 4 files changed, 751 insertions(+) >> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c >> >> diff --git a/drivers/pinctrl/sunxi/Kconfig >b/drivers/pinctrl/sunxi/Kconfig >> index 593293584ecc..fc13335a3eda 100644 >> --- a/drivers/pinctrl/sunxi/Kconfig >> +++ b/drivers/pinctrl/sunxi/Kconfig >> @@ -73,6 +73,11 @@ config PINCTRL_SUN8I_V3S >> default MACH_SUN8I >> select PINCTRL_SUNXI >> >> +config PINCTRL_SUN8I_V83X >> +bool "Support for the Allwinner V831/V833 PIO" >> +default MACH_SUN8I >> +select PINCTRL_SUNXI >> + > >We're not using the wildcard much, and I'd rather be consistent with >the >name / Kconfig option scheme used for the clock driver (and the rest of >the SoCs in a similar situation) Well, call everything V831, or call everything V833, or call things usable on V831 V831 and things only available to V833 V833? > >Maxime
Re: [PATCH v2 14/21] phy: sun4i-usb: Rework "pmu_unk1" handling
在 2020-12-14星期一的 01:35 +，André Przywara写道：
> On 13/12/2020 18:24, Icenowy Zheng wrote:
> > 在 2020-12-11星期五的 01:19 +，Andre Przywara写道：
> > > Newer SoCs (A100, H616) need to clear a different bit in our
> > > "unknown"
> > > PMU PHY register.
> >
> > It looks like that the unknown PHY register is PHYCTL register for
> > each
> > individual PHY, and the bit that is cleared is
> > called SUNXI_HCI_PHY_CTRL_SIDDQ in the BSP (similar to
> > the USBC_PHY_CTL_SIDDQ we cleared for main PHYCTL).
In addition, both the BIT(1) in old PHYs and the BIT(3) in new PHYs are
SIDDQ. (In BSP it's a #define inside #if)
Should we add some flag for 28nm PHY?
>
> Oh, right, somehow I failed to find this in the BSP, I guess I got
> confused over that similar symbol. I will put proper names to it.
In addition, the region at 0x800 is not PMU at all, but some [OE]HCI-
related control registers. The name "PMU" can only cover the first
register here.
We may need to address this.
>
> Thanks!
> Andre
>
> > > Generalise the existing code by allowing configs to specify a
> > > bitmask
> > > of bits to clear.
> > >
> > > Signed-off-by: Andre Przywara
> > > ---
> > > drivers/phy/allwinner/phy-sun4i-usb.c | 28 +++
> > >
> > >
> > > 1 file changed, 11 insertions(+), 17 deletions(-)
> > >
> > > diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
> > > b/drivers/phy/allwinner/phy-sun4i-usb.c
> > > index 651d5e2a25ce..4ba0699e0bb4 100644
> > > --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> > > +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> > > @@ -115,9 +115,9 @@ struct sun4i_usb_phy_cfg {
> > > int hsic_index;
> > > enum sun4i_usb_phy_type type;
> > > u32 disc_thresh;
> > > + u32 pmu_unk1_clrbits;
> > > u8 phyctl_offset;
> > > bool dedicated_clocks;
> > > - bool enable_pmu_unk1;
> > > bool phy0_dual_route;
> > > int missing_phys;
> > > };
> > > @@ -288,6 +288,12 @@ static int sun4i_usb_phy_init(struct phy
> > > *_phy)
> > > return ret;
> > > }
> > >
> > > + if (phy->pmu && data->cfg->pmu_unk1_clrbits) {
> > > + val = readl(phy->pmu + REG_PMU_UNK1);
> > > + val &= ~data->cfg->pmu_unk1_clrbits;
> > > + writel(val, phy->pmu + REG_PMU_UNK1);
> > > + }
> > > +
> > > if (data->cfg->type == sun8i_a83t_phy ||
> > > data->cfg->type == sun50i_h6_phy) {
> > > if (phy->index == 0) {
> > > @@ -297,11 +303,6 @@ static int sun4i_usb_phy_init(struct phy
> > > *_phy)
> > > writel(val, data->base + data->cfg-
> > > > phyctl_offset);
> > > }
> > > } else {
> > > - if (phy->pmu && data->cfg->enable_pmu_unk1) {
> > > - val = readl(phy->pmu + REG_PMU_UNK1);
> > > - writel(val & ~2, phy->pmu + REG_PMU_UNK1);
> > > - }
> > > -
> > > /* Enable USB 45 Ohm resistor calibration */
> > > if (phy->index == 0)
> > > sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN,
> > > 0x01, 1);
> > > @@ -867,7 +868,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun4i_a10_cfg = {
> > > .disc_thresh = 3,
> > > .phyctl_offset = REG_PHYCTL_A10,
> > > .dedicated_clocks = false,
> > > - .enable_pmu_unk1 = false,
> > > };
> > >
> > > static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
> > > @@ -876,7 +876,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun5i_a13_cfg = {
> > > .disc_thresh = 2,
> > > .phyctl_offset = REG_PHYCTL_A10,
> > > .dedicated_clocks = false,
> > > - .enable_pmu_unk1 = false,
> > > };
> > >
> > > static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
> > > @@ -885,7 +884,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun6i_a31_cfg = {
> > > .disc_thresh = 3,
> > > .phyctl_offset = REG_PHYCTL_A10,
> > > .dedicated_clocks = true,
> > > - .enable_pmu_unk1 = false,
> > > };
> > >
> > > static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
> > > @@ -894,7 +892,6 @@ static const struct sun4i_usb_phy_cfg
> > > sun7i_a20_cfg = {
> > > .disc_thresh = 2,
Re: [PATCH v2 14/21] phy: sun4i-usb: Rework "pmu_unk1" handling
在 2020-12-11星期五的 01:19 +，Andre Przywara写道：
> Newer SoCs (A100, H616) need to clear a different bit in our
> "unknown"
> PMU PHY register.
It looks like that the unknown PHY register is PHYCTL register for each
individual PHY, and the bit that is cleared is
called SUNXI_HCI_PHY_CTRL_SIDDQ in the BSP (similar to
the USBC_PHY_CTL_SIDDQ we cleared for main PHYCTL).
>
> Generalise the existing code by allowing configs to specify a bitmask
> of bits to clear.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/phy/allwinner/phy-sun4i-usb.c | 28 +++
>
> 1 file changed, 11 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
> b/drivers/phy/allwinner/phy-sun4i-usb.c
> index 651d5e2a25ce..4ba0699e0bb4 100644
> --- a/drivers/phy/allwinner/phy-sun4i-usb.c
> +++ b/drivers/phy/allwinner/phy-sun4i-usb.c
> @@ -115,9 +115,9 @@ struct sun4i_usb_phy_cfg {
> int hsic_index;
> enum sun4i_usb_phy_type type;
> u32 disc_thresh;
> + u32 pmu_unk1_clrbits;
> u8 phyctl_offset;
> bool dedicated_clocks;
> - bool enable_pmu_unk1;
> bool phy0_dual_route;
> int missing_phys;
> };
> @@ -288,6 +288,12 @@ static int sun4i_usb_phy_init(struct phy *_phy)
> return ret;
> }
>
> + if (phy->pmu && data->cfg->pmu_unk1_clrbits) {
> + val = readl(phy->pmu + REG_PMU_UNK1);
> + val &= ~data->cfg->pmu_unk1_clrbits;
> + writel(val, phy->pmu + REG_PMU_UNK1);
> + }
> +
> if (data->cfg->type == sun8i_a83t_phy ||
> data->cfg->type == sun50i_h6_phy) {
> if (phy->index == 0) {
> @@ -297,11 +303,6 @@ static int sun4i_usb_phy_init(struct phy *_phy)
> writel(val, data->base + data->cfg-
> >phyctl_offset);
> }
> } else {
> - if (phy->pmu && data->cfg->enable_pmu_unk1) {
> - val = readl(phy->pmu + REG_PMU_UNK1);
> - writel(val & ~2, phy->pmu + REG_PMU_UNK1);
> - }
> -
> /* Enable USB 45 Ohm resistor calibration */
> if (phy->index == 0)
> sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN,
> 0x01, 1);
> @@ -867,7 +868,6 @@ static const struct sun4i_usb_phy_cfg
> sun4i_a10_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A10,
> .dedicated_clocks = false,
> - .enable_pmu_unk1 = false,
> };
>
> static const struct sun4i_usb_phy_cfg sun5i_a13_cfg = {
> @@ -876,7 +876,6 @@ static const struct sun4i_usb_phy_cfg
> sun5i_a13_cfg = {
> .disc_thresh = 2,
> .phyctl_offset = REG_PHYCTL_A10,
> .dedicated_clocks = false,
> - .enable_pmu_unk1 = false,
> };
>
> static const struct sun4i_usb_phy_cfg sun6i_a31_cfg = {
> @@ -885,7 +884,6 @@ static const struct sun4i_usb_phy_cfg
> sun6i_a31_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A10,
> .dedicated_clocks = true,
> - .enable_pmu_unk1 = false,
> };
>
> static const struct sun4i_usb_phy_cfg sun7i_a20_cfg = {
> @@ -894,7 +892,6 @@ static const struct sun4i_usb_phy_cfg
> sun7i_a20_cfg = {
> .disc_thresh = 2,
> .phyctl_offset = REG_PHYCTL_A10,
> .dedicated_clocks = false,
> - .enable_pmu_unk1 = false,
> };
>
> static const struct sun4i_usb_phy_cfg sun8i_a23_cfg = {
> @@ -903,7 +900,6 @@ static const struct sun4i_usb_phy_cfg
> sun8i_a23_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A10,
> .dedicated_clocks = true,
> - .enable_pmu_unk1 = false,
> };
>
> static const struct sun4i_usb_phy_cfg sun8i_a33_cfg = {
> @@ -912,7 +908,6 @@ static const struct sun4i_usb_phy_cfg
> sun8i_a33_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A33,
> .dedicated_clocks = true,
> - .enable_pmu_unk1 = false,
> };
>
> static const struct sun4i_usb_phy_cfg sun8i_a83t_cfg = {
> @@ -929,7 +924,7 @@ static const struct sun4i_usb_phy_cfg
> sun8i_h3_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A33,
> .dedicated_clocks = true,
> - .enable_pmu_unk1 = true,
> + .pmu_unk1_clrbits = BIT(1),
> .phy0_dual_route = true,
> };
>
> @@ -939,7 +934,7 @@ static const struct sun4i_usb_phy_cfg
> sun8i_r40_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A33,
> .dedicated_clocks = true,
> - .enable_pmu_unk1 = true,
> + .pmu_unk1_clrbits = BIT(1),
> .phy0_dual_route = true,
> };
>
> @@ -949,7 +944,7 @@ static const struct sun4i_usb_phy_cfg
> sun8i_v3s_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A33,
> .dedicated_clocks = true,
> - .enable_pmu_unk1 = true,
> + .pmu_unk1_clrbits = BIT(1),
> .phy0_dual_route = true,
> };
>
> @@ -959,7 +954,7 @@ static const struct sun4i_usb_phy_cfg
> sun50i_a64_cfg = {
> .disc_thresh = 3,
> .phyctl_offset = REG_PHYCTL_A33,
> .dedicated_clocks =
Re: [PATCH v2 00/21] arm64: sunxi: Initial Allwinner H616 SoC support
在 2020-12-11星期五的 01:19 +，Andre Przywara写道： > Hi, > > this is the quite expanded second version of the support series for > the > Allwinner H616 SoC. > Besides many fixes for the bugs discovered by the diligent reviewers > (many thanks for that!) this version adds some patches to support > some > slightly changed devices, like the second EMAC and the AXP not having > an interrupt. > Also I added quite some DT binding doc patches. > USB still does not work, but I include the patches anyway, hoping > that > someone can help spotting the issue. > For a more detailed changelog see below. > > Thanks! > Andre > > == > This series gathers patches to support the Allwinner H616 SoC. This > is > a rather uninspired SoC (Quad-A53 with the usual peripherals), but > allows for some cheap development boards and TV boxes, and supports > up to 4GB of DRAM. > > Various DT binding patches are sprinkled throughout the series, to > add > the new compatible names right before they are used. > Patch 1/21 is the usual drive-by fix, discovered while staring at > the H6 clock code. > Patch 3 and 4 add pinctrl support, with the "-R" controller now being > crippled down to two I2C pins only. If we grow tired of repeating > this > exercise for every new SoC variant, I am happy to revive my more > versatile sunxi pinctrl driver effort from a few years back [1]. > Patch 6 and 7 add clock support. For the -R clock this is shared with > the H6 code, as the clocks are identical, with the H616 just having > fewer of them. The main clocks are different enough to warrant a > separate > file. > Patch 08/21 is pulling a patch from Yangtao's A100 series, since we > need > the same fix for MMC support. This will probably be merged > separately, > I just include this here to provide a bootable solution. > Patch 10 teaches the AXP MFD driver to get along without having an > interrupt, as the H616 apparently does not have an NMI controller > anymore. > Patch 12 and 13 add some tweaks to the syscon and EMAC driver, to > deal > with the second EMAC clock used for the second Ethernet controller. > Patches 14 and 15 *try* to add USB support. The same approach works > with > the very similar U-Boot PHY driver, but for some reason still fail in > Linux. Maybe someone spots the issue and can help fixing it? There's a judge currently checks for phy type A83T/H6. You may need to add H616 there. Or should we have a bool in the data struct to mark it? I think all chips that need that is 28nm. > > The remaining patches add DT bindings, which just add the new > compatible > string along with an existing name as a fallback string. > Eventually we get the .dtsi for the SoC in patch 19, and the .dts for > the OrangePi Zero2 board[2] in the last patch. > > We have U-Boot and Trusted-Firmware support in a working state, > booting > via FEL and even TFTPing kernels work already [3][4]. > > Many thanks to Jernej for his tremendous help on this, also for the > awesome input and help from the #linux-sunxi Freenode channel. > > The whole series can also be found here: > https://github.com/apritzel/linux/commits/h616-v2 > > Happy reviewing! > > Cheers, > Andre > > [1] > https://patchwork.ozlabs.org/project/linux-gpio/cover/20171113012523.2328-1-andre.przyw...@arm.com/ > [2] https://linux-sunxi.org/Xunlong_Orange_Pi_Zero2 > [3] https://github.com/jernejsk/u-boot/commits/h616-v1 > [4] https://github.com/apritzel/arm-trusted-firmware/commits/h616-WIP > > Changelog v1 .. v2: > - pinctrl: adjust irq bank map to cover undocumented GPIO bank IRQs > - use differing h_i2s0 pin output names > - r-ccu: fix number of used clocks > - ccu: remove PLL-PERIPHy(4X) > - ccu: fix gpu1 divider range > - ccu: fix usb-phy3 parent > - ccu: add missing TV clocks > - ccu: rework to CLK_OF_DECLARE style > - ccu: enable output bit for PLL clocks > - ccu: renumber clocks > - .dtsi: drop sun50i-a64-system-control fallback > - .dtsi: drop unknown SRAM regions > - .dtsi: add more (undocumented) GPIO interrupts > - .dtsi: fix I2C3 pin names > - .dtsi: use a100-emmc fallback for MMC2 > - .dtsi: add second EMAC controller > - .dtsi: use H3 MUSB controller fallback > - .dtsi: fix frame size for USB PHY PMU registers > - .dtsi: add USB0 PHY references > - .dtsi: fix IR controller clock source > - .dts: fix LED naming and swap pins > - .dts: use 5V supply parent for USB supply > - .dts: drop dummy IRQ for AXP > - .dts: enable 3V3 header pin power rail > - .dts: add SPI flash node > - .dts: make USB-C port peripheral only > - add IRQ-less AXP support > - add two patches to support more than one EMAC clock > - add patch to rework and extend USB PHY support > - add DT binding documentation patches > > Andre Przywara (18): > clk: sunxi-ng: h6: Fix clock divider range on some clocks > dt-bindings: pinctrl: Add Allwinner H616 compatible strings > pinctrl: sunxi: Add support for the Allwinner H616 pin controller > pinctrl: sunxi: Add support for the Allwinner H616-R pin c
Re: [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
在 2020-12-02星期三的 13:54 +，Andre Przywara写道：
> Port A is used for an internal connection to some analogue circuitry
> which looks like an AC200 IP (as in the H6), though this is not
> mentioned in the manual.
When developing for V831, I found that PIO controller in H616 (and
V831) has the functionality of selecting IO voltage of PF bank (needed
to handle UHS-I).
How should we model this in PIO driver?
>
> Signed-off-by: Andre Przywara
> ---
> drivers/pinctrl/sunxi/Kconfig | 5 +
> drivers/pinctrl/sunxi/Makefile | 1 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c | 549
>
> 3 files changed, 555 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
>
> diff --git a/drivers/pinctrl/sunxi/Kconfig
> b/drivers/pinctrl/sunxi/Kconfig
> index 593293584ecc..73e88ce71a48 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -119,4 +119,9 @@ config PINCTRL_SUN50I_H6_R
> default ARM64 && ARCH_SUNXI
> select PINCTRL_SUNXI
>
> +config PINCTRL_SUN50I_H616
> + bool "Support for the Allwinner H616 PIO"
> + default ARM64 && ARCH_SUNXI
> + select PINCTRL_SUNXI
> +
> endif
> diff --git a/drivers/pinctrl/sunxi/Makefile
> b/drivers/pinctrl/sunxi/Makefile
> index 8b7ff0dc3bdf..5359327a3c8f 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -23,5 +23,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_V3S) +=
> pinctrl-sun8i-v3s.o
> obj-$(CONFIG_PINCTRL_SUN50I_H5) += pinctrl-sun50i-h5.o
> obj-$(CONFIG_PINCTRL_SUN50I_H6) += pinctrl-sun50i-h6.o
> obj-$(CONFIG_PINCTRL_SUN50I_H6_R)+= pinctrl-sun50i-h6-r.o
> +obj-$(CONFIG_PINCTRL_SUN50I_H616)+= pinctrl-sun50i-h616.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80) += pinctrl-sun9i-a80.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80_R)+= pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> new file mode 100644
> index ..734f63eb08dd
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
> @@ -0,0 +1,549 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Allwinner H616 SoC pinctrl driver.
> + *
> + * Copyright (C) 2020 Arm Ltd.
> + * based on the H6 pinctrl driver
> + * Copyright (C) 2017 Icenowy Zheng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin h616_pins[] = {
> + /* Internal connection to the AC200 part */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ECRS_DV */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXERR */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXCK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7),
> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXEN */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 8),
> + SUNXI_FUNCTION(0x2, "emac1")), /* EMDC */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 9),
> + SUNXI_FUNCTION(0x2, "emac1")), /* EMDIO */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 10),
> + SUNXI_FUNCTION(0x2, "i2c3")), /* SCK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 11),
> + SUNXI_FUNCTION(0x2, "i2c3")), /* SDA */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 12),
> + SUNXI_FUNCTION(0x2, "pwm5")),
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* WE */
> + SUNXI_FUNCTION(0x3, "mmc2"), /* DS */
> + SUNXI_FUNCTION(0x4, "spi0"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PC_EINT0
> */
> + SUNX
[RFC PATCH 12/12] [DO NOT MERGE] ARM: dts: sun8i: v831: add a device tree file for Y20GA
Yi Y20GA is an IP camera with QG2101A chip (a rebranded Allwinner V831).
Add a device tree for it.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/Makefile| 3 +-
arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts | 53 +++
2 files changed, 55 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ce66ffd5a1bb..2b2e93bb9ee2 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1212,7 +1212,8 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-t3-cqa3t-bv3.dtb \
sun8i-v3s-licheepi-zero.dtb \
sun8i-v3s-licheepi-zero-dock.dtb \
- sun8i-v40-bananapi-m2-berry.dtb
+ sun8i-v40-bananapi-m2-berry.dtb \
+ sun8i-v831-yi-y20ga.dtb
dtb-$(CONFIG_MACH_SUN9I) += \
sun9i-a80-optimus.dtb \
sun9i-a80-cubieboard4.dtb
diff --git a/arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts
b/arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts
new file mode 100644
index ..16f4b6dbe0d2
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts
@@ -0,0 +1,53 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng
+ */
+
+/dts-v1/;
+#include "sun8i-v831.dtsi"
+#include
+
+/ {
+ model = "Yi Camera Y20GA";
+ compatible = "xiaoyi,y20ga", "allwinner,sun8i-v831";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ reg_vcc3v3: vcc3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ };
+};
+
+&mmc0 {
+ vmmc-supply = <®_vcc3v3>;
+ cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ status = "okay";
+};
+
+&spi0 {
+ pinctrl-0 = <&spi0_qspi_pins>, <&spi0_cs_pin>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ flash@0 {
+ compatible = "winbond,w25q128", "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <400>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_ph9_ph10_pins>;
+ status = "okay";
+};
--
2.28.0
[RFC PATCH 11/12] ARM: dts: sun8i: add DTSI file for V831
V831 is a new chip by Allwinner, and its functionality is a subset of
V833 (another new chip with the same die but larger pin count).
Add a DTSI file for V831.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v831.dtsi | 244 ++
1 file changed, 244 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-v831.dtsi
diff --git a/arch/arm/boot/dts/sun8i-v831.dtsi
b/arch/arm/boot/dts/sun8i-v831.dtsi
new file mode 100644
index ..7ddc4d33d8b2
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-v831.dtsi
@@ -0,0 +1,244 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng
+ */
+
+#include
+#include
+#include
+
+/ {
+ interrupt-parent = <&gic>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <0>;
+ clocks = <&ccu CLK_CPUX>;
+ };
+ };
+
+ osc24M: osc24M_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ clock-output-names = "osc24M";
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ ccu: clock@3001000 {
+ compatible = "allwinner,sun8i-v833-ccu";
+ reg = <0x03001000 0x1000>;
+ clocks = <&osc24M>, <&rtc 0>, <&rtc 2>;
+ clock-names = "hosc", "losc", "iosc";
+ #clock-cells = <1>;
+ #reset-cells = <1>;
+ };
+
+ watchdog: watchdog@30090a0 {
+ compatible = "allwinner,sun8i-v831-wdt",
+"allwinner,sun6i-a31-wdt";
+ reg = <0x030090a0 0x20>;
+ interrupts = ;
+ clocks = <&osc24M>;
+ };
+
+ pio: pinctrl@300b000 {
+ compatible = "allwinner,sun8i-v831-pinctrl";
+ reg = <0x0300b000 0x400>;
+ interrupts = ,
+,
+,
+,
+,
+,
+;
+ clocks = <&ccu CLK_APB1>, <&osc24M>, <&rtc 0>;
+ clock-names = "apb", "hosc", "losc";
+ gpio-controller;
+ #gpio-cells = <3>;
+ interrupt-controller;
+ #interrupt-cells = <3>;
+
+ mmc0_pins: mmc0-pins {
+ pins = "PF0", "PF1", "PF2", "PF3",
+ "PF4", "PF5";
+ function = "mmc0";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ /omit-if-no-ref/
+ mmc1_pins: mmc1-pins {
+ pins = "PG0", "PG1", "PG2", "PG3",
+ "PG4", "PG5";
+ function = "mmc1";
+ drive-strength = <30>;
+ bias-pull-up;
+ };
+
+ /omit-if-no-ref/
+ spi0_qspi_pins: spi0-qspi-pins {
+ pins = "PC0", "PC2", "PC3", "PC4", "PC5";
+ function = "spi0";
+ };
+
+ /omit-if-no-ref/
+ spi0_cs_pin: spi0-cs-pin {
+ pins = "PC1";
+ function = "spi0";
+ };
+
+ uart0_ph9_
[RFC PATCH 10/12] dt-bindings: spi: sun6i: add compatible for V831 SPI
V831 has a SPI controller similar to the H6 one. Add a compatible string for it. Cc: Mark Brown Cc: linux-...@vger.kernel.org Signed-off-by: Icenowy Zheng --- H6 and V831 SPI controllers is not totally the same with H3: they have QSPI support added. Here V831 compatible string is just added in parallel with H6 one, but maybe we should make H6 SPI do not fallback to H3 one, and add H6 one as fallback to V831? .../devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml index 7866a655d81c..a620ff30033e 100644 --- a/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml +++ b/Documentation/devicetree/bindings/spi/allwinner,sun6i-a31-spi.yaml @@ -24,6 +24,7 @@ properties: - items: - enum: - allwinner,sun8i-r40-spi + - allwinner,sun8i-v831-spi - allwinner,sun50i-h6-spi - const: allwinner,sun8i-h3-spi -- 2.28.0
[RFC PATCH 09/12] dt-bindings: watchdog: sunxi: add compatible string for V831/V833 WDT
V831/V833 has a watchdog similar to the ones on previous Allwinner SoCs after sun6i. Add a compatible string for it. Cc: Wim Van Sebroeck Cc: Guenter Roeck Cc: linux-watch...@vger.kernel.org Signed-off-by: Icenowy Zheng --- .../devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml index e8f226376108..2f3c350b0057 100644 --- a/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/allwinner,sun4i-a10-wdt.yaml @@ -18,6 +18,9 @@ properties: oneOf: - const: allwinner,sun4i-a10-wdt - const: allwinner,sun6i-a31-wdt + - items: + - const: allwinner,sun8i-v831-wdt + - const: allwinner,sun6i-a31-wdt - items: - const: allwinner,sun50i-a64-wdt - const: allwinner,sun6i-a31-wdt -- 2.28.0
[RFC PATCH 08/12] dt-bindings: mmc: sunxi: add compatible strings for V831 MMC
V831 has MMC controllers similar to the ones on H6. Add a compatible string for them. The eMMC controller compatible is not added, because the eMMC controller is not available on V831, only V833. Cc: Ulf Hansson Cc: linux-...@vger.kernel.org Signed-off-by: Icenowy Zheng --- .../devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml index e82c9a07b6fb..985586cb93b4 100644 --- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml @@ -35,6 +35,9 @@ properties: - items: - const: allwinner,sun8i-r40-mmc - const: allwinner,sun50i-a64-mmc + - items: + - const: allwinner,sun8i-v831-mmc + - const: allwinner,sun50i-a64-mmc - items: - const: allwinner,sun50i-h5-emmc - const: allwinner,sun50i-a64-emmc -- 2.28.0
[RFC PATCH 07/12] rtc: sun6i: add compatible string for V831/V833 RTC
These chips share the same die, and the RTC block is similar to H6
one, but with functionality of dividing 24M clock to get 32k (useful for
32k clock output).
Add compatible string for it. The special clock divider is TODO.
Cc: Alessandro Zummo
Cc: Alexandre Belloni
Cc: linux-...@vger.kernel.org
Signed-off-by: Icenowy Zheng
---
drivers/rtc/rtc-sun6i.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index e2b8b150bcb4..c9a1f2319f92 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -378,6 +378,23 @@ static void __init sun50i_h6_rtc_clk_init(struct
device_node *node)
CLK_OF_DECLARE_DRIVER(sun50i_h6_rtc_clk, "allwinner,sun50i-h6-rtc",
sun50i_h6_rtc_clk_init);
+static const struct sun6i_rtc_clk_data sun8i_v831_rtc_data = {
+ .rc_osc_rate = 1600,
+ .fixed_prescaler = 32,
+ .has_prescaler = 1,
+ .has_out_clk = 1,
+ .export_iosc = 1,
+ .has_losc_en = 1,
+ .has_auto_swt = 1,
+};
+
+static void __init sun8i_v831_rtc_clk_init(struct device_node *node)
+{
+ sun6i_rtc_clk_init(node, &sun8i_v831_rtc_data);
+}
+CLK_OF_DECLARE_DRIVER(sun8i_v831_rtc_clk, "allwinner,sun8i-v831-rtc",
+ sun8i_v831_rtc_clk_init);
+
/*
* The R40 user manual is self-conflicting on whether the prescaler is
* fixed or configurable. The clock diagram shows it as fixed, but there
@@ -745,6 +762,7 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
{ .compatible = "allwinner,sun8i-h3-rtc" },
{ .compatible = "allwinner,sun8i-r40-rtc" },
{ .compatible = "allwinner,sun8i-v3-rtc" },
+ { .compatible = "allwinner,sun8i-v831-rtc" },
{ .compatible = "allwinner,sun50i-h5-rtc" },
{ .compatible = "allwinner,sun50i-h6-rtc" },
{ /* sentinel */ },
--
2.28.0
[RFC PATCH 06/12] dt-bindings: rtc: sun6i: add compatible string for V831/V833 RTC
V831/V833 SoCs (the same die) have a RTC block similar to the one in H6, but allow to generate the osc32k clock from osc24M. Add a new compatible string for that. The functionality of dividing osc24M to generate osc32k is still TODO. Cc: Alessandro Zummo Cc: Alexandre Belloni Cc: linux-...@vger.kernel.org Signed-off-by: Icenowy Zheng --- .../devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml| 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml index 37c2a601c3fa..6e3a3b14db7b 100644 --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml @@ -21,6 +21,7 @@ properties: - const: allwinner,sun8i-h3-rtc - const: allwinner,sun8i-r40-rtc - const: allwinner,sun8i-v3-rtc + - const: allwinner,sun8i-v831-rtc - const: allwinner,sun50i-h5-rtc - items: - const: allwinner,sun50i-a64-rtc @@ -97,6 +98,7 @@ allOf: properties: compatible: contains: +const: allwinner,sun8i-v831-rtc const: allwinner,sun50i-h6-rtc then: -- 2.28.0
[RFC PATCH 05/12] pinctrl: sunxi: add pinctrl driver for V831/V833
V831/V833 are new chips from Allwinner. They're the same die with
different package.
Add a pinctrl driver for them.
The difference between V831/V833 pinctrl is implemented based on the
user manual.
Cc: Linus Walleij
Cc: linux-g...@vger.kernel.org
Signed-off-by: Icenowy Zheng
---
drivers/pinctrl/sunxi/Kconfig | 5 +
drivers/pinctrl/sunxi/Makefile | 1 +
drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c | 743 +
drivers/pinctrl/sunxi/pinctrl-sunxi.h | 2 +
4 files changed, 751 insertions(+)
create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index 593293584ecc..fc13335a3eda 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -73,6 +73,11 @@ config PINCTRL_SUN8I_V3S
default MACH_SUN8I
select PINCTRL_SUNXI
+config PINCTRL_SUN8I_V83X
+ bool "Support for the Allwinner V831/V833 PIO"
+ default MACH_SUN8I
+ select PINCTRL_SUNXI
+
config PINCTRL_SUN9I_A80
bool "Support for the Allwinner A80 PIO"
default MACH_SUN9I
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index 8b7ff0dc3bdf..8bcca109e942 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_PINCTRL_SUN8I_A83T_R)+=
pinctrl-sun8i-a83t-r.o
obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
obj-$(CONFIG_PINCTRL_SUN8I_H3_R) += pinctrl-sun8i-h3-r.o
obj-$(CONFIG_PINCTRL_SUN8I_V3S)+= pinctrl-sun8i-v3s.o
+obj-$(CONFIG_PINCTRL_SUN8I_V83X) += pinctrl-sun8i-v83x.o
obj-$(CONFIG_PINCTRL_SUN50I_H5)+= pinctrl-sun50i-h5.o
obj-$(CONFIG_PINCTRL_SUN50I_H6)+= pinctrl-sun50i-h6.o
obj-$(CONFIG_PINCTRL_SUN50I_H6_R) += pinctrl-sun50i-h6-r.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c
b/drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c
new file mode 100644
index ..19d035dcebbf
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c
@@ -0,0 +1,743 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020 Icenowy Zheng
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun8i_v83x_pins[] = {
+ /* Hole */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_VARIANT(0x3,
+"mmc2",/* DS */
+PINCTRL_SUN8I_V833),
+ SUNXI_FUNCTION(0x4, "spi0"), /* CLK */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_VARIANT(0x3,
+"mmc2",/* RST */
+PINCTRL_SUN8I_V833),
+ SUNXI_FUNCTION(0x4, "spi0"), /* CS0 */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_VARIANT(0x3,
+"mmc2",/* CLK */
+PINCTRL_SUN8I_V833),
+ SUNXI_FUNCTION(0x4, "spi0"), /* MOSI */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_VARIANT(0x3,
+"mmc2",/* CMD */
+PINCTRL_SUN8I_V833),
+ SUNXI_FUNCTION(0x4, "spi0"), /* MISO */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION_VARIANT(0x3,
+"mmc2",/* WP */
+PINCTRL_SUN8I_V833),
+ SUNXI_FUNCTION(0x4, "spi0"), /* D3 */
+ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTI
[RFC PATCH 04/12] dt-bindings: pinctrl: sunxi: add compatible for V831/V833 pinctrl
V831/V833 are a pair of new Allwinner chips. The difference between them is similar to V3s/V3, but the chip design is similar to newer Allwinner chips started from H6. Add compatible strings for V831/V833 pinctrl. Cc: Linus Walleij Cc: linux-g...@vger.kernel.org Signed-off-by: Icenowy Zheng --- .../bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml index 5240487dfe50..3d6855856594 100644 --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sun4i-a10-pinctrl.yaml @@ -44,6 +44,8 @@ properties: - allwinner,sun8i-r40-pinctrl - allwinner,sun8i-v3-pinctrl - allwinner,sun8i-v3s-pinctrl + - allwinner,sun8i-v831-pinctrl + - allwinner,sun8i-v833-pinctrl - allwinner,sun9i-a80-pinctrl - allwinner,sun9i-a80-r-pinctrl - allwinner,sun50i-a64-pinctrl @@ -189,6 +191,8 @@ allOf: enum: - allwinner,sun8i-a23-pinctrl - allwinner,sun8i-a83t-pinctrl +- allwinner,sun8i-v831-pinctrl +- allwinner,sun8i-v833-pinctrl - allwinner,sun50i-a64-pinctrl - allwinner,sun50i-h5-pinctrl - allwinner,suniv-f1c100s-pinctrl -- 2.28.0
[RFC PATCH 03/12] clk: sunxi-ng: add CCU driver for V831/V833
V831/V833 are new chips from Allwinner targeting camera market. The
difference between them is similar to V3s/V3, the former one is a
reduced-pin package with co-packaged DDR2 and the latter one is a BGA
package w/o DRAM packaged in.
Add a CCU driver for them. As the user manual didn't have marks for
different chips (V831 and V833 shares the same user manual file), only
implementing a full-functional CCU driver with V833 compatible.
Signed-off-by: Icenowy Zheng
---
There's a PLL that is called PLL_UNI in the user manual. However a duck
test shows that it is quite similar to PLL_PERI1 on other SoCs: it
functions as parent to some peripherals, occupies the same register
offset with PLL_PERI1 and have the same clock rate configuration with
PLL_PERI1. Here I called it as pll-uni to follow the official document,
but I doubt whether we should call it pll-periph1 to be consistent with
other SoCs.
drivers/clk/sunxi-ng/Kconfig | 5 +
drivers/clk/sunxi-ng/Makefile | 1 +
drivers/clk/sunxi-ng/ccu-sun8i-v833.c | 930 ++
drivers/clk/sunxi-ng/ccu-sun8i-v833.h | 46 ++
4 files changed, 982 insertions(+)
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-v833.c
create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-v833.h
diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-ng/Kconfig
index ce5f5847d5d3..eb038d0f48d7 100644
--- a/drivers/clk/sunxi-ng/Kconfig
+++ b/drivers/clk/sunxi-ng/Kconfig
@@ -77,6 +77,11 @@ config SUN8I_V3S_CCU
default MACH_SUN8I
depends on MACH_SUN8I || COMPILE_TEST
+config SUN8I_V833_CCU
+ bool "Support for the Allwinner V833 CCU"
+ default MACH_SUN8I
+ depends on MACH_SUN8I || COMPILE_TEST
+
config SUN8I_DE2_CCU
bool "Support for the Allwinner SoCs DE2 CCU"
default MACH_SUN8I || (ARM64 && ARCH_SUNXI)
diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-ng/Makefile
index 3eb5cff40eac..dd33aba983bb 100644
--- a/drivers/clk/sunxi-ng/Makefile
+++ b/drivers/clk/sunxi-ng/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_SUN8I_A33_CCU) += ccu-sun8i-a33.o
obj-$(CONFIG_SUN8I_A83T_CCU) += ccu-sun8i-a83t.o
obj-$(CONFIG_SUN8I_H3_CCU) += ccu-sun8i-h3.o
obj-$(CONFIG_SUN8I_V3S_CCU)+= ccu-sun8i-v3s.o
+obj-$(CONFIG_SUN8I_V833_CCU) += ccu-sun8i-v833.o
obj-$(CONFIG_SUN8I_DE2_CCU)+= ccu-sun8i-de2.o
obj-$(CONFIG_SUN8I_R_CCU) += ccu-sun8i-r.o
obj-$(CONFIG_SUN8I_R40_CCU)+= ccu-sun8i-r40.o
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-v833.c
b/drivers/clk/sunxi-ng/ccu-sun8i-v833.c
new file mode 100644
index ..c60178035117
--- /dev/null
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-v833.c
@@ -0,0 +1,930 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2020 Icenowy Zheng
+ * Based on the H616 CCU driver, which is:
+ * Copyright (c) 2020 Arm Ltd.
+ */
+
+#include
+#include
+#include
+#include
+
+#include "ccu_common.h"
+#include "ccu_reset.h"
+
+#include "ccu_div.h"
+#include "ccu_gate.h"
+#include "ccu_mp.h"
+#include "ccu_mult.h"
+#include "ccu_nk.h"
+#include "ccu_nkm.h"
+#include "ccu_nkmp.h"
+#include "ccu_nm.h"
+
+#include "ccu-sun8i-v833.h"
+
+/*
+ * The CPU PLL is actually NP clock, with P being /1, /2 or /4. However
+ * P should only be used for output frequencies lower than 288 MHz.
+ *
+ * For now we can just model it as a multiplier clock, and force P to /1.
+ *
+ * The M factor is present in the register's description, but not in the
+ * frequency formula, and it's documented as "M is only used for backdoor
+ * testing", so it's not modelled and then force to 0.
+ */
+#define SUN8I_V833_PLL_CPUX_REG0x000
+static struct ccu_mult pll_cpux_clk = {
+ .enable = BIT(31),
+ .lock = BIT(28),
+ .mult = _SUNXI_CCU_MULT_MIN(8, 8, 12),
+ .common = {
+ .reg= 0x000,
+ .hw.init= CLK_HW_INIT("pll-cpux", "osc24M",
+ &ccu_mult_ops,
+ CLK_SET_RATE_UNGATE),
+ },
+};
+
+/* Some PLLs are input * N / div1 / P. Model them as NKMP with no K */
+#define SUN8I_V833_PLL_DDR0_REG0x010
+static struct ccu_nkmp pll_ddr0_clk = {
+ .enable = BIT(31),
+ .lock = BIT(28),
+ .n = _SUNXI_CCU_MULT_MIN(8, 8, 12),
+ .m = _SUNXI_CCU_DIV(1, 1), /* input divider */
+ .p = _SUNXI_CCU_DIV(0, 1), /* output divider */
+ .common = {
+ .reg= 0x010,
+ .hw.init= CLK_HW_INIT("pll-ddr0", "osc24M",
+ &ccu_nkmp_ops,
+ CLK_SET_RATE_UNGATE),
+
[RFC PATCH 00/12] Support for Allwinner V831 SoC
Allwinner V831 is a new SoC by Allwinner oriented at the camera market. It has a QFN88 package with co-packaged 64MiB DDR2 DRAM. Another SoC, V833, is also available, which has the same die with V831 but w/o co-packaged DRAM (thus a BGA package). This patchset tries to add basical support for V831, with consideration of V833 in many drivers. The DT is only for a temporary test device w/o schematics, development will be shifted to another device when the patchset leaves RFC. Icenowy Zheng (12): dt-bindings: clock: sunxi-ng: add compatible for V831/V833 CCU dt-bindings: clk: sunxi-ng: add V833 CCU clock/reset indices headers clk: sunxi-ng: add CCU driver for V831/V833 dt-bindings: pinctrl: sunxi: add compatible for V831/V833 pinctrl pinctrl: sunxi: add pinctrl driver for V831/V833 dt-bindings: rtc: sun6i: add compatible string for V831/V833 RTC rtc: sun6i: add compatible string for V831/V833 RTC dt-bindings: mmc: sunxi: add compatible strings for V831 MMC dt-bindings: watchdog: sunxi: add compatible string for V831/V833 WDT dt-bindings: spi: sun6i: add compatible for V831 SPI ARM: dts: sun8i: add DTSI file for V831 [DO NOT MERGE] ARM: dts: sun8i: v831: add a device tree file for Y20GA .../clock/allwinner,sun4i-a10-ccu.yaml| 2 + .../bindings/mmc/allwinner,sun4i-a10-mmc.yaml | 3 + .../pinctrl/allwinner,sun4i-a10-pinctrl.yaml | 4 + .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 2 + .../bindings/spi/allwinner,sun6i-a31-spi.yaml | 1 + .../watchdog/allwinner,sun4i-a10-wdt.yaml | 3 + arch/arm/boot/dts/Makefile| 3 +- arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts | 53 + arch/arm/boot/dts/sun8i-v831.dtsi | 244 + drivers/clk/sunxi-ng/Kconfig | 5 + drivers/clk/sunxi-ng/Makefile | 1 + drivers/clk/sunxi-ng/ccu-sun8i-v833.c | 930 ++ drivers/clk/sunxi-ng/ccu-sun8i-v833.h | 46 + drivers/pinctrl/sunxi/Kconfig | 5 + drivers/pinctrl/sunxi/Makefile| 1 + drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c| 743 ++ drivers/pinctrl/sunxi/pinctrl-sunxi.h | 2 + drivers/rtc/rtc-sun6i.c | 18 + include/dt-bindings/clock/sun8i-v833-ccu.h| 89 ++ include/dt-bindings/reset/sun8i-v833-ccu.h| 52 + 20 files changed, 2206 insertions(+), 1 deletion(-) create mode 100644 arch/arm/boot/dts/sun8i-v831-yi-y20ga.dts create mode 100644 arch/arm/boot/dts/sun8i-v831.dtsi create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-v833.c create mode 100644 drivers/clk/sunxi-ng/ccu-sun8i-v833.h create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-v83x.c create mode 100644 include/dt-bindings/clock/sun8i-v833-ccu.h create mode 100644 include/dt-bindings/reset/sun8i-v833-ccu.h -- 2.28.0
[RFC PATCH 02/12] dt-bindings: clk: sunxi-ng: add V833 CCU clock/reset indices headers
As the device tree needs the clock/reset indices, add them to DT binding headers. The driver itself will be then added. Signed-off-by: Icenowy Zheng --- include/dt-bindings/clock/sun8i-v833-ccu.h | 89 ++ include/dt-bindings/reset/sun8i-v833-ccu.h | 52 + 2 files changed, 141 insertions(+) create mode 100644 include/dt-bindings/clock/sun8i-v833-ccu.h create mode 100644 include/dt-bindings/reset/sun8i-v833-ccu.h diff --git a/include/dt-bindings/clock/sun8i-v833-ccu.h b/include/dt-bindings/clock/sun8i-v833-ccu.h new file mode 100644 index ..885f3462eab6 --- /dev/null +++ b/include/dt-bindings/clock/sun8i-v833-ccu.h @@ -0,0 +1,89 @@ +/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */ +/* + * Copyright (C) 2020 Icenowy Zheng + */ + +#ifndef _DT_BINDINGS_CLK_SUN8I_V833_H_ +#define _DT_BINDINGS_CLK_SUN8I_V833_H_ + +#define CLK_CPUX 14 + +#define CLK_APB1 19 + +#define CLK_DE 21 +#define CLK_BUS_DE 22 +#define CLK_G2D23 +#define CLK_BUS_G2D24 +#define CLK_CE 25 +#define CLK_BUS_CE 26 +#define CLK_VE 27 +#define CLK_BUS_VE 28 +#define CLK_EISE 29 +#define CLK_BUS_EISE 30 +#define CLK_NPU31 +#define CLK_BUS_NPU32 +#define CLK_BUS_DMA33 +#define CLK_BUS_HSTIMER34 +#define CLK_AVS35 +#define CLK_BUS_DBG36 +#define CLK_BUS_PSI37 +#define CLK_BUS_PWM38 +#define CLK_MBUS_DMA 40 +#define CLK_MBUS_VE41 +#define CLK_MBUS_CE42 +#define CLK_MBUS_TS43 +#define CLK_MBUS_NAND 44 +#define CLK_MBUS_G2D 45 +#define CLK_MBUS_EISE 46 +#define CLK_MBUS_VDPO 47 +#define CLK_MMC0 49 +#define CLK_MMC1 50 +#define CLK_MMC2 51 +#define CLK_BUS_MMC0 52 +#define CLK_BUS_MMC1 53 +#define CLK_BUS_MMC2 54 +#define CLK_BUS_UART0 55 +#define CLK_BUS_UART1 56 +#define CLK_BUS_UART2 57 +#define CLK_BUS_UART3 58 +#define CLK_BUS_I2C0 59 +#define CLK_BUS_I2C1 60 +#define CLK_BUS_I2C2 61 +#define CLK_BUS_I2C3 62 +#define CLK_SPI0 63 +#define CLK_SPI1 64 +#define CLK_SPI2 65 +#define CLK_BUS_SPI0 66 +#define CLK_BUS_SPI1 67 +#define CLK_BUS_SPI2 68 +#define CLK_EMAC_25M 69 +#define CLK_BUS_EMAC0 70 +#define CLK_BUS_GPADC 71 +#define CLK_BUS_THS72 +#define CLK_I2S0 73 +#define CLK_I2S1 74 +#define CLK_BUS_I2S0 75 +#define CLK_BUS_I2S1 76 +#define CLK_AUDIO_CODEC_1X 77 +#define CLK_AUDIO_CODEC_4X 78 +#define CLK_BUS_AUDIO_CODEC79 +#define CLK_USB_OHCI0 80 +#define CLK_USB_PHY0 81 +#define CLK_BUS_OHCI0 82 +#define CLK_BUS_EHCI0 83 +#define CLK_BUS_OTG84 +#define CLK_MIPI_DSI_DPHY0_HS 85 +#define CLK_MIPI_DSI_HOST0 86 +#define CLK_BUS_MIPI_DSI 87 +#define CLK_BUS_TCON_TOP 88 +#define CLK_TCON_LCD0 89 +#define CLK_BUS_TCON_LCD0 90 +#define CLK_CSI_TOP91 +#define CLK_CSI_MCLK0 92 +#define CLK_CSI_MCLK1 93 +#define CLK_ISP94 +#define CLK_BUS_CSI95 +#define CLK_DSPO 96 +#define CLK_BUS_DSPO 97 + +#endif /* _DT_BINDINGS_CLK_SUN8I_V833_H_ */ diff --git a/include/dt-bindings/reset/sun8i-v833-ccu.h b/include/dt-bindings/reset/sun8i-v833-ccu.h new file mode 100644 index ..fb2b0e3b287f --- /dev/null +++ b/include/dt-bindings/reset/sun8i-v833-ccu.h @@ -0,0 +1,52 @@ +/* SPDX-License-Identifier: (GPL-2.0+ or MIT) */ +/* + * Copyright (C) 2017 Icenowy Zheng + */ + +#ifndef _DT_BINDINGS_RESET_SUN8I_V833_H_ +#define _DT_BINDINGS_RESET_SUN8I_V833_H_ + +#define RST_MBUS 0 +#define RST_BUS_DE 1 +#define RST_BUS_G2D2 +#define RST_BUS_CE 3 +#define RST_BUS_VE 4 +#define RST_BUS_EISE 5 +#define RST_BUS_NPU6 +#define RST_BUS_DMA7 +#define RST_BUS_HSTIMER8 +#define RST_BUS_DBG9 +#define RST_BUS_PSI10 +#define RST_BUS_PWM11 +#define RST_BUS_DRAM 12 +#define RST_BUS_MMC0 13 +#define RST_BUS_MMC1 14 +#define RST_BUS_MMC2 15 +#define RST_BUS_UART0 16 +#define RST_BUS_UART1 17 +#define RST_BUS_UART2 18 +#define RST_BUS_UART3 19 +#define RST_BUS_I2C0 20 +#define RST_BUS_I2C1 21 +#define RST_BUS_I2C2 22 +#define RST_BUS_I2C3 23 +#define RST_BUS_SPI0 24 +#define RST_BUS_SPI1 25 +#define
[RFC PATCH 01/12] dt-bindings: clock: sunxi-ng: add compatible for V831/V833 CCU
V831/V833 has a CCU similar to the ones on H6/A100. Add a compatible string for it. As the user manual do not mention the difference between V831 and V833 in the CCU chapter, only a single compatible string for V833 (full-functional chip) is made. Signed-off-by: Icenowy Zheng --- .../devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml index 3b45344ed758..b874d887995a 100644 --- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml +++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml @@ -33,6 +33,7 @@ properties: - allwinner,sun8i-r40-ccu - allwinner,sun8i-v3-ccu - allwinner,sun8i-v3s-ccu + - allwinner,sun8i-v833-ccu - allwinner,sun9i-a80-ccu - allwinner,sun50i-a64-ccu - allwinner,sun50i-a64-r-ccu @@ -98,6 +99,7 @@ else: properties: compatible: enum: + - allwinner,sun8i-v833-ccu - allwinner,sun50i-a100-ccu - allwinner,sun50i-h6-ccu -- 2.28.0
Re: [linux-sunxi] [PATCH 5/8] clk: sunxi-ng: Add support for the Allwinner H616 CCU
在 2020-12-02星期三的 13:54 +，Andre Przywara写道：
> While the clocks are fairly similar to the H6, many differ in tiny
> details, so a separate clock driver seems indicated.
>
> Derived from the H6 clock driver, and adjusted according to the
> manual.
>
> Signed-off-by: Andre Przywara
> ---
> drivers/clk/sunxi-ng/Kconfig|7 +-
> drivers/clk/sunxi-ng/Makefile |1 +
> drivers/clk/sunxi-ng/ccu-sun50i-h616.c | 1134
> +++
> drivers/clk/sunxi-ng/ccu-sun50i-h616.h | 58 +
> include/dt-bindings/clock/sun50i-h616-ccu.h | 110 ++
> include/dt-bindings/reset/sun50i-h616-ccu.h | 67 ++
> 6 files changed, 1376 insertions(+), 1 deletion(-)
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> create mode 100644 drivers/clk/sunxi-ng/ccu-sun50i-h616.h
> create mode 100644 include/dt-bindings/clock/sun50i-h616-ccu.h
> create mode 100644 include/dt-bindings/reset/sun50i-h616-ccu.h
>
> diff --git a/drivers/clk/sunxi-ng/Kconfig b/drivers/clk/sunxi-
> ng/Kconfig
> index ce5f5847d5d3..cd46d8853876 100644
> --- a/drivers/clk/sunxi-ng/Kconfig
> +++ b/drivers/clk/sunxi-ng/Kconfig
> @@ -32,8 +32,13 @@ config SUN50I_H6_CCU
> default ARM64 && ARCH_SUNXI
> depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
>
> +config SUN50I_H616_CCU
> + bool "Support for the Allwinner H616 CCU"
> + default ARM64 && ARCH_SUNXI
> + depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
> +
> config SUN50I_H6_R_CCU
> - bool "Support for the Allwinner H6 PRCM CCU"
> + bool "Support for the Allwinner H6 and H616 PRCM CCU"
> default ARM64 && ARCH_SUNXI
> depends on (ARM64 && ARCH_SUNXI) || COMPILE_TEST
>
> diff --git a/drivers/clk/sunxi-ng/Makefile b/drivers/clk/sunxi-
> ng/Makefile
> index 3eb5cff40eac..96c324306d97 100644
> --- a/drivers/clk/sunxi-ng/Makefile
> +++ b/drivers/clk/sunxi-ng/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_SUN50I_A64_CCU)+= ccu-sun50i-
> a64.o
> obj-$(CONFIG_SUN50I_A100_CCU)+= ccu-sun50i-a100.o
> obj-$(CONFIG_SUN50I_A100_R_CCU) += ccu-sun50i-a100-r.o
> obj-$(CONFIG_SUN50I_H6_CCU) += ccu-sun50i-h6.o
> +obj-$(CONFIG_SUN50I_H616_CCU)+= ccu-sun50i-h616.o
> obj-$(CONFIG_SUN50I_H6_R_CCU)+= ccu-sun50i-h6-r.o
> obj-$(CONFIG_SUN4I_A10_CCU) += ccu-sun4i-a10.o
> obj-$(CONFIG_SUN5I_CCU) += ccu-sun5i.o
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> new file mode 100644
> index 0000..3fbb258f0354
> --- /dev/null
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h616.c
> @@ -0,0 +1,1134 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Arm Ltd.
> + * Based on the H6 CCU driver, which is:
> + * Copyright (c) 2017 Icenowy Zheng
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include "ccu_common.h"
> +#include "ccu_reset.h"
> +
> +#include "ccu_div.h"
> +#include "ccu_gate.h"
> +#include "ccu_mp.h"
> +#include "ccu_mult.h"
> +#include "ccu_nk.h"
> +#include "ccu_nkm.h"
> +#include "ccu_nkmp.h"
> +#include "ccu_nm.h"
> +
> +#include "ccu-sun50i-h616.h"
> +
> +/*
> + * The CPU PLL is actually NP clock, with P being /1, /2 or /4.
> However
> + * P should only be used for output frequencies lower than 288 MHz.
> + *
> + * For now we can just model it as a multiplier clock, and force P
> to /1.
> + *
> + * The M factor is present in the register's description, but not in
> the
> + * frequency formula, and it's documented as "M is only used for
> backdoor
> + * testing", so it's not modelled and then force to 0.
> + */
> +#define SUN50I_H616_PLL_CPUX_REG 0x000
> +static struct ccu_mult pll_cpux_clk = {
> + .enable = BIT(31),
> + .lock = BIT(28),
> + .mult = _SUNXI_CCU_MULT_MIN(8, 8, 12),
> + .common = {
> + .reg= 0x000,
> + .hw.init= CLK_HW_INIT("pll-cpux", "osc24M",
> + &ccu_mult_ops,
> + CLK_SET_RATE_UNGATE),
> + },
> +};
> +
> +/* Some PLLs are input * N / div1 / P. Model them as NKMP with no K
> */
> +#define SUN50I_H616_PLL_DDR0_REG 0x010
> +static struct ccu_nkmp pll_ddr0_clk = {
> + .enable = BIT(31),
> + .lock = BIT(28),
> + .n = _SUNXI_C
[PATCH 3/3] dt-bindings: arm: sunxi: note that old PineTab compatible has old panel
As the old LCD panel used by PineTab developer samples are discontinued, there won't be furtherly any more units of the sample, and this should be noted in the document. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 73a6c8421172..9f29b5811aa1 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -695,7 +695,7 @@ properties: - const: pine64,pinephone-1.2 - const: allwinner,sun50i-a64 - - description: Pine64 PineTab + - description: Pine64 PineTab (developers' sample with old discontinued LCD panel, discontinued) items: - const: pine64,pinetab - const: allwinner,sun50i-a64 -- 2.28.0
[PATCH 2/3] arm64: allwinner: dts: a64: add DT for PineTab with new LCD panel
Further released PineTabs will have a new LCD panel that is different
with the one used in developers' samples.
Add device tree for PineTab with the new panel.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../sun50i-a64-pinetab-new-panel.dts | 26 +++
2 files changed, 27 insertions(+)
create mode 100644
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-new-panel.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index 211d1e9d4701..83c6d1ea197f 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.0.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-new-panel.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-new-panel.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-new-panel.dts
new file mode 100644
index ..f3da9653be3e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-new-panel.dts
@@ -0,0 +1,26 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pinetab.dts"
+
+/ {
+ model = "PineTab with new LCD panel";
+ compatible = "pine64,pinetab-new-panel", "allwinner,sun50i-a64";
+};
+
+&dsi {
+ /delete-node/ panel@0;
+
+ panel@0 {
+ compatible = "feixin,k101-im2byl02";
+ reg = <0>;
+ power-supply = <®_dc1sw>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+ backlight = <&backlight>;
+ };
+};
--
2.28.0
[PATCH 1/3] dt-bindings: arm: sunxi: add PineTab new panel DT binding
Early adopters' PineTabs (and all further releases) will have a new LCD panel different with the one that is used when in development (because the old panel's supply discontinued). Add a new DT compatible for it. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 6db32fbf813f..73a6c8421172 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -700,6 +700,11 @@ properties: - const: pine64,pinetab - const: allwinner,sun50i-a64 + - description: Pine64 PineTab with new LCD panel +items: + - const: pine64,pinetab-new-panel + - const: allwinner,sun50i-a64 + - description: Pine64 SoPine Baseboard items: - const: pine64,sopine-baseboard -- 2.28.0
[PATCH 0/3] PineTab with new panel DT
As discussed on the mailing list, here introduces a new DT for new PineTabs. Icenowy Zheng (3): dt-bindings: arm: sunxi: add PineTab new panel DT binding arm64: allwinner: dts: a64: add DT for PineTab with new LCD panel dt-bindings: arm: sunxi: note that old PineTab compatible has old panel .../devicetree/bindings/arm/sunxi.yaml| 7 - arch/arm64/boot/dts/allwinner/Makefile| 1 + .../sun50i-a64-pinetab-new-panel.dts | 26 +++ 3 files changed, 33 insertions(+), 1 deletion(-) create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-new-panel.dts -- 2.28.0
Re: [linux-sunxi] [PATCH 2/8] pinctrl: sunxi: Add support for the Allwinner H616 pin controller
于 2020年12月6日 GMT+08:00 下午10:52:17, "André Przywara" 写到:
>On 06/12/2020 12:42, Jernej Škrabec wrote:
>
>Hi,
>
>> Dne nedelja, 06. december 2020 ob 13:32:49 CET je Clément Péron
>napisal(a):
>>> Hi Andre,
>>>
>>> On Wed, 2 Dec 2020 at 14:54, Andre Przywara
>wrote:
>>>> Port A is used for an internal connection to some analogue
>circuitry
>>>> which looks like an AC200 IP (as in the H6), though this is not
>>>> mentioned in the manual.
>>>>
>>>> Signed-off-by: Andre Przywara
>>>> ---
>>>>
>>>> drivers/pinctrl/sunxi/Kconfig | 5 +
>>>> drivers/pinctrl/sunxi/Makefile | 1 +
>>>> drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c | 549
>
>>>> 3 files changed, 555 insertions(+)
>>>> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
>>>>
>>>> diff --git a/drivers/pinctrl/sunxi/Kconfig
>b/drivers/pinctrl/sunxi/Kconfig
>>>> index 593293584ecc..73e88ce71a48 100644
>>>> --- a/drivers/pinctrl/sunxi/Kconfig
>>>> +++ b/drivers/pinctrl/sunxi/Kconfig
>>>> @@ -119,4 +119,9 @@ config PINCTRL_SUN50I_H6_R
>>>>
>>>> default ARM64 && ARCH_SUNXI
>>>> select PINCTRL_SUNXI
>>>>
>>>> +config PINCTRL_SUN50I_H616
>>>> + bool "Support for the Allwinner H616 PIO"
>>>> + default ARM64 && ARCH_SUNXI
>>>> + select PINCTRL_SUNXI
>>>> +
>>>>
>>>> endif
>>>>
>>>> diff --git a/drivers/pinctrl/sunxi/Makefile
>>>> b/drivers/pinctrl/sunxi/Makefile index 8b7ff0dc3bdf..5359327a3c8f
>100644
>>>> --- a/drivers/pinctrl/sunxi/Makefile
>>>> +++ b/drivers/pinctrl/sunxi/Makefile
>>>> @@ -23,5 +23,6 @@ obj-$(CONFIG_PINCTRL_SUN8I_V3S) +=
>>>> pinctrl-sun8i-v3s.o>
>>>> obj-$(CONFIG_PINCTRL_SUN50I_H5)+=
>pinctrl-sun50i-h5.o
>>>> obj-$(CONFIG_PINCTRL_SUN50I_H6)+=
>pinctrl-sun50i-h6.o
>>>> obj-$(CONFIG_PINCTRL_SUN50I_H6_R) += pinctrl-sun50i-h6-r.o
>>>>
>>>> +obj-$(CONFIG_PINCTRL_SUN50I_H616) += pinctrl-sun50i-h616.o
>>>>
>>>> obj-$(CONFIG_PINCTRL_SUN9I_A80)+=
>pinctrl-sun9i-a80.o
>>>> obj-$(CONFIG_PINCTRL_SUN9I_A80_R) += pinctrl-sun9i-a80-r.o
>>>>
>>>> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
>>>> b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c new file mode 100644
>>>> index ..734f63eb08dd
>>>> --- /dev/null
>>>> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c
>>>> @@ -0,0 +1,549 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +/*
>>>> + * Allwinner H616 SoC pinctrl driver.
>>>> + *
>>>> + * Copyright (C) 2020 Arm Ltd.
>>>> + * based on the H6 pinctrl driver
>>>> + * Copyright (C) 2017 Icenowy Zheng
>>>> + */
>>>> +
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +#include
>>>> +
>>>> +#include "pinctrl-sunxi.h"
>>>> +
>>>> +static const struct sunxi_desc_pin h616_pins[] = {
>>>> + /* Internal connection to the AC200 part */
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD1 */
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXD0 */
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ECRS_DV
>*/
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ERXERR
>*/
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD1 */
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXD0 */
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6),
>>>> + SUNXI_FUNCTION(0x2, "emac1")), /* ETXCK */
>>>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7),
>>
Re: [linux-sunxi] Re: [PATCH 5/8] clk: sunxi-ng: Add support for the Allwinner H616 CCU
ne CLK_CPUX 23 > > > + > > > +#define CLK_APB1 28 > > > + > > > +#define CLK_DE 31 > > > +#define CLK_BUS_DE 32 > > > +#define CLK_DEINTERLACE 33 > > > +#define CLK_BUS_DEINTERLACE 34 > > > +#define CLK_G2D 35 > > > +#define CLK_BUS_G2D 36 > > > +#define CLK_GPU0 37 > > > +#define CLK_BUS_GPU 38 > > > +#define CLK_GPU1 39 > > > +#define CLK_CE 40 > > > +#define CLK_BUS_CE 41 > > > +#define CLK_VE 42 > > > +#define CLK_BUS_VE 43 > > > +#define CLK_BUS_DMA 44 > > > +#define CLK_BUS_HSTIMER 45 > > > +#define CLK_AVS 46 > > > +#define CLK_BUS_DBG 47 > > > +#define CLK_BUS_PSI 48 > > > +#define CLK_BUS_PWM 49 > > > +#define CLK_BUS_IOMMU50 > > > + > > > +#define CLK_MBUS_DMA 52 > > > +#define CLK_MBUS_VE 53 > > > +#define CLK_MBUS_CE 54 > > > +#define CLK_MBUS_TS 55 > > > +#define CLK_MBUS_NAND56 > > > +#define CLK_MBUS_G2D 57 > > > + > > > +#define CLK_NAND059 > > > +#define CLK_NAND160 > > > +#define CLK_BUS_NAND 61 > > > +#define CLK_MMC0 62 > > > +#define CLK_MMC1 63 > > > +#define CLK_MMC2 64 > > > +#define CLK_BUS_MMC0 65 > > > +#define CLK_BUS_MMC1 66 > > > +#define CLK_BUS_MMC2 67 > > > +#define CLK_BUS_UART068 > > > +#define CLK_BUS_UART169 > > > +#define CLK_BUS_UART270 > > > +#define CLK_BUS_UART371 > > > +#define CLK_BUS_UART472 > > > +#define CLK_BUS_UART573 > > > +#define CLK_BUS_I2C0 74 > > > +#define CLK_BUS_I2C1 75 > > > +#define CLK_BUS_I2C2 76 > > > +#define CLK_BUS_I2C3 77 > > > +#define CLK_BUS_I2C4 78 > > > +#define CLK_SPI0 79 > > > +#define CLK_SPI1 80 > > > +#define CLK_BUS_SPI0 81 > > > +#define CLK_BUS_SPI1 82 > > > +#define CLK_EMAC_25M 83 > > > +#define CLK_BUS_EMAC084 > > > +#define CLK_BUS_EMAC185 > > > +#define CLK_TS 86 > > > +#define CLK_BUS_TS 87 > > > +#define CLK_BUS_THS 88 > > > +#define CLK_SPDIF89 > > > +#define CLK_BUS_SPDIF90 > > > +#define CLK_DMIC 91 > > > +#define CLK_BUS_DMIC 92 > > > +#define CLK_AUDIO_CODEC_1X 93 > > > +#define CLK_AUDIO_CODEC_4X 94 > > > +#define CLK_BUS_AUDIO_CODEC 95 > > > +#define CLK_AUDIO_HUB96 > > > +#define CLK_BUS_AUDIO_HUB97 > > > +#define CLK_USB_OHCI098 > > > +#define CLK_USB_PHY0 99 > > > +#define CLK_USB_OHCI1100 > > > +#define CLK_USB_PHY1 101 > > > +#define CLK_USB_OHCI2102 > > > +#define CLK_USB_PHY2 103 > > > +#define CLK_USB_OHCI3104 > > > +#define CLK_USB_PHY3 105 > > > +#define CLK_BUS_OHCI0106 > > > +#define CLK_BUS_OHCI1107 > > > +#define CLK_BUS_OHCI2108 > > > +#define CLK_BUS_OHCI3109 > > > +#define CLK_BUS_EHCI0110 > > > +#define CLK_BUS_EHCI1111 > > > +#define CLK_BUS_EHCI2112 > > > +#define CLK_BUS_EHCI3113 > > > +#define CLK_BUS_OTG 114 > > > +#define CLK_BUS_KEYADC 115 > > > +#define CLK_HDMI 116 > > > +#define CLK_HDMI_SLOW117 > > > +#define CLK_HDMI_CEC 118 > > > +#define CLK_BUS_HDMI 119 > > > +#define CLK_BUS_TCON_TOP 120 > > > +#define CLK_TCON_TV0 121 > > > +#define CLK_BUS_TCON_TV0 122 > > > +#define CLK_HDCP 123 > > > +#define CLK_BUS_HDCP 124 > > > + > > > +#endif /* _DT_BINDINGS_CLK_SUN50I_H616_H_ */ > > > diff --git a/include/dt-bindings/reset/sun50i-h616-ccu.h >
Re: [linux-sunxi] Re: [PATCH 4/8] clk: sunxi-ng: Add support for the Allwinner H616 R-CCU
于 2020年12月3日 GMT+08:00 下午7:07:02, "André Przywara" 写到:
>On 02/12/2020 14:31, Icenowy Zheng wrote:
>
>Hi,
>
>> 于 2020年12月2日 GMT+08:00 下午9:54:05, Andre Przywara
> 写到:
>>> The clocks itself are identical to the H6 R-CCU, it's just that the
>>> H616
>>> has not all of them implemented (or connected).
>>
>> For selective clocks, try to follow the practice of V3(s) driver?
>
>Not sure what you mean, isn't that what I do? Having a separate
>sunxi_ccu_desc for each SoC and referencing separate structs? At least
>that's what I see in ccu-sun8i-v3s.c.
>
>What am I missing?
Sorry, I misred it.
Ignore my disturbance.
>
>Cheers,
>Andre
>
>>>
>>> Signed-off-by: Andre Przywara
>>> ---
>>> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 47
>+-
>>> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 3 +-
>>> 2 files changed, 48 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>>> b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>>> index 50f8d1bc7046..119d1797f501 100644
>>> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>>> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>>> @@ -136,6 +136,15 @@ static struct ccu_common
>*sun50i_h6_r_ccu_clks[] =
>>> {
>>> &w1_clk.common,
>>> };
>>>
>>> +static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
>>> + &r_apb1_clk.common,
>>> + &r_apb2_clk.common,
>>> + &r_apb1_twd_clk.common,
>>> + &r_apb2_i2c_clk.common,
>>> + &r_apb1_ir_clk.common,
>>> + &ir_clk.common,
>>> +};
>>> +
>>> static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
>>> .hws= {
>>> [CLK_AR100] = &ar100_clk.common.hw,
>>> @@ -152,7 +161,20 @@ static struct clk_hw_onecell_data
>>> sun50i_h6_r_hw_clks = {
>>> [CLK_IR]= &ir_clk.common.hw,
>>> [CLK_W1]= &w1_clk.common.hw,
>>> },
>>> - .num= CLK_NUMBER,
>>> + .num= CLK_NUMBER_H616,
>>> +};
>>> +
>>> +static struct clk_hw_onecell_data sun50i_h616_r_hw_clks = {
>>> + .hws= {
>>> + [CLK_R_AHB] = &r_ahb_clk.hw,
>>> + [CLK_R_APB1]= &r_apb1_clk.common.hw,
>>> + [CLK_R_APB2]= &r_apb2_clk.common.hw,
>>> + [CLK_R_APB1_TWD]= &r_apb1_twd_clk.common.hw,
>>> + [CLK_R_APB2_I2C]= &r_apb2_i2c_clk.common.hw,
>>> + [CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
>>> + [CLK_IR]= &ir_clk.common.hw,
>>> + },
>>> + .num= CLK_NUMBER_H616,
>>> };
>>>
>>> static struct ccu_reset_map sun50i_h6_r_ccu_resets[] = {
>>> @@ -165,6 +187,12 @@ static struct ccu_reset_map
>>> sun50i_h6_r_ccu_resets[] = {
>>> [RST_R_APB1_W1] = { 0x1ec, BIT(16) },
>>> };
>>>
>>> +static struct ccu_reset_map sun50i_h616_r_ccu_resets[] = {
>>> + [RST_R_APB1_TWD]= { 0x12c, BIT(16) },
>>> + [RST_R_APB2_I2C]= { 0x19c, BIT(16) },
>>> + [RST_R_APB1_IR] = { 0x1cc, BIT(16) },
>>> +};
>>> +
>>> static const struct sunxi_ccu_desc sun50i_h6_r_ccu_desc = {
>>> .ccu_clks = sun50i_h6_r_ccu_clks,
>>> .num_ccu_clks = ARRAY_SIZE(sun50i_h6_r_ccu_clks),
>>> @@ -175,6 +203,16 @@ static const struct sunxi_ccu_desc
>>> sun50i_h6_r_ccu_desc = {
>>> .num_resets = ARRAY_SIZE(sun50i_h6_r_ccu_resets),
>>> };
>>>
>>> +static const struct sunxi_ccu_desc sun50i_h616_r_ccu_desc = {
>>> + .ccu_clks = sun50i_h616_r_ccu_clks,
>>> + .num_ccu_clks = ARRAY_SIZE(sun50i_h616_r_ccu_clks),
>>> +
>>> + .hw_clks= &sun50i_h616_r_hw_clks,
>>> +
>>> + .resets = sun50i_h616_r_ccu_resets,
>>> + .num_resets = ARRAY_SIZE(sun50i_h616_r_ccu_resets),
>>> +};
>>> +
>>> static void __init sunxi_r_ccu_init(struct device_node *node,
>>> const struct sunxi_ccu_desc *desc)
>>> {
>>> @@ -195,3 +233,10 @@ static void __init sun50i_h6_r_ccu_setup(struct
>>> device_node *node)
>>> }
>>> CLK_OF_DECLARE(sun50i_h6_r_ccu, "allwinner,sun50i-h6-r-ccu",
>>>sun50i_h6_r_ccu_setup);
>>> +
>>> +static void __init sun50i_h616_r_ccu_setup(struct device_node
>*node)
>>> +{
>>> + sunxi_r_ccu_init(node, &sun50i_h616_r_ccu_desc);
>>> +}
>>> +CLK_OF_DECLARE(sun50i_h616_r_ccu, "allwinner,sun50i-h616-r-ccu",
>>> + sun50i_h616_r_ccu_setup);
>>> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
>>> b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
>>> index 782117dc0b28..128302696ca1 100644
>>> --- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
>>> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
>>> @@ -14,6 +14,7 @@
>>>
>>> #define CLK_R_APB2 3
>>>
>>> -#define CLK_NUMBER (CLK_W1 + 1)
>>> +#define CLK_NUMBER_H6 (CLK_W1 + 1)
>>> +#define CLK_NUMBER_H616(CLK_IR + 1)
>>>
>>> #endif /* _CCU_SUN50I_H6_R_H */
Re: [PATCH 7/8] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
于 2020年12月3日 GMT+08:00 上午12:05:04, Maxime Ripard 写到:
>On Wed, Dec 02, 2020 at 01:54:08PM +, Andre Przywara wrote:
>> This (relatively) new SoC is similar to the H6, but drops the
>(broken)
>> PCIe support and the USB 3.0 controller. It also gets the management
>> controller removed, which in turn removes *some*, but not all of the
>> devices formerly dedicated to the ARISC (CPUS).
>> There does not seem to be an external interrupt controller anymore,
>so
>> no external interrupts through an NMI pin. The AXP driver needs to
>learn
>> living with that.
>>
>> Signed-off-by: Andre Przywara
>> ---
>> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 704
>++
>> 1 file changed, 704 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>> new file mode 100644
>> index ..dcffbfdcd26b
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>> @@ -0,0 +1,704 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +// Copyright (C) 2020 Arm Ltd.
>> +// based on the H6 dtsi, which is:
>> +// Copyright (C) 2017 Icenowy Zheng
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +/ {
>> +interrupt-parent = <&gic>;
>> +#address-cells = <2>;
>> +#size-cells = <2>;
>> +
>> +cpus {
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +
>> +cpu0: cpu@0 {
>> +compatible = "arm,cortex-a53";
>> +device_type = "cpu";
>> +reg = <0>;
>> +enable-method = "psci";
>> +clocks = <&ccu CLK_CPUX>;
>> +};
>> +
>> +cpu1: cpu@1 {
>> +compatible = "arm,cortex-a53";
>> +device_type = "cpu";
>> +reg = <1>;
>> +enable-method = "psci";
>> +clocks = <&ccu CLK_CPUX>;
>> +};
>> +
>> +cpu2: cpu@2 {
>> +compatible = "arm,cortex-a53";
>> +device_type = "cpu";
>> +reg = <2>;
>> +enable-method = "psci";
>> +clocks = <&ccu CLK_CPUX>;
>> +};
>> +
>> +cpu3: cpu@3 {
>> +compatible = "arm,cortex-a53";
>> +device_type = "cpu";
>> +reg = <3>;
>> +enable-method = "psci";
>> +clocks = <&ccu CLK_CPUX>;
>> +};
>> +};
>> +
>> +reserved-memory {
>> +#address-cells = <2>;
>> +#size-cells = <2>;
>> +ranges;
>> +
>> +/* 512KiB reserved for ARM Trusted Firmware (BL31) */
>> +secmon_reserved: secmon@4000 {
>> +reg = <0x0 0x4000 0x0 0x8>;
>> +no-map;
>> +};
>> +};
>
>I'm not sure why that node is there, the previous SoCs didn't have it?
Previously we (ab)use SRAM A2 (designed for ARISC) for ATF.
But H616 has no SRAM A2.
>Shouldn't ATF patch it itself?
>
>> +osc24M: osc24M_clk {
>> +#clock-cells = <0>;
>> +compatible = "fixed-clock";
>> +clock-frequency = <2400>;
>> +clock-output-names = "osc24M";
>> +};
>> +
>> +pmu {
>> +compatible = "arm,cortex-a53-pmu";
>> +interrupts = ,
>> + ,
>> + ,
>> + ;
>> +interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>, <&cpu3>;
>> +};
>> +
>> +psci {
>> +compatible = "arm,psci-0.2";
>> +method = "smc";
>> +};
>> +
>> +timer {
>> +compatible = "arm,armv8-timer";
>> +arm,no-tick-in-suspend;
>
>
Re: [PATCH 7/8] arm64: dts: allwinner: Add Allwinner H616 .dtsi file
在 2020-12-02星期三的 13:54 +，Andre Przywara写道：
> This (relatively) new SoC is similar to the H6, but drops the
> (broken)
> PCIe support and the USB 3.0 controller. It also gets the management
> controller removed, which in turn removes *some*, but not all of the
> devices formerly dedicated to the ARISC (CPUS).
> There does not seem to be an external interrupt controller anymore,
> so
> no external interrupts through an NMI pin. The AXP driver needs to
> learn
> living with that.
>
> Signed-off-by: Andre Przywara
> ---
> .../arm64/boot/dts/allwinner/sun50i-h616.dtsi | 704
> ++
> 1 file changed, 704 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> new file mode 100644
> index ..dcffbfdcd26b
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616.dtsi
> @@ -0,0 +1,704 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +// Copyright (C) 2020 Arm Ltd.
> +// based on the H6 dtsi, which is:
> +// Copyright (C) 2017 Icenowy Zheng
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + interrupt-parent = <&gic>;
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu0: cpu@0 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <0>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu1: cpu@1 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <1>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu2: cpu@2 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <2>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> +
> + cpu3: cpu@3 {
> + compatible = "arm,cortex-a53";
> + device_type = "cpu";
> + reg = <3>;
> + enable-method = "psci";
> + clocks = <&ccu CLK_CPUX>;
> + };
> + };
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + /* 512KiB reserved for ARM Trusted Firmware (BL31) */
> + secmon_reserved: secmon@4000 {
> + reg = <0x0 0x4000 0x0 0x8>;
> + no-map;
> + };
Should this node be dynamically added by the firmware? This is only
some effort taken by our community, not from Allwinner. (Although
Allwinner reserves much more memory in their BSP.)
(In my opinion, it should be applied by ATF to U-Boot DT, and then U-
Boot add it to Linux DT.)
> + };
> +
> + osc24M: osc24M_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <2400>;
> + clock-output-names = "osc24M";
> + };
> +
> + pmu {
> + compatible = "arm,cortex-a53-pmu";
> + interrupts = ,
> + ,
> + ,
> + ;
> + interrupt-affinity = <&cpu0>, <&cpu1>, <&cpu2>,
> <&cpu3>;
> + };
> +
> + psci {
> + compatible = "arm,psci-0.2";
> + method = "smc";
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + arm,no-tick-in-suspend;
> + interrupts = + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> + + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
> + + (GIC_CPU_MASK_SIMPLE(4) |
> IRQ_TYPE_LEVEL_HIGH)>,
&
Re: [PATCH 8/8] arm64: dts: allwinner: Add OrangePi Zero 2 .dts
在 2020-12-02星期三的 13:54 +，Andre Przywara写道：
> The OrangePi Zero 2 is a development board with the new H616 SoC.
>
> It features the usual connectors used on those small boards, and
> comes
> with the AXP305, which seems to be compatible with the AXP805.
>
> For more details see: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero2
>
> Signed-off-by: Andre Przywara
> ---
> arch/arm64/boot/dts/allwinner/Makefile| 1 +
> .../allwinner/sun50i-h616-orangepi-zero2.dts | 228
> ++
> 2 files changed, 229 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h616-
> orangepi-zero2.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
> b/arch/arm64/boot/dts/allwinner/Makefile
> index 211d1e9d4701..0cf8299b1ce7 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -35,3 +35,4 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-orangepi-one-
> plus.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-pine-h64-model-b.dtb
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h6-tanix-tx6.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h616-orangepi-zero2.dtb
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-
> zero2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-
> zero2.dts
> new file mode 100644
> index ..814f5b4fec7c
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h616-orangepi-zero2.dts
> @@ -0,0 +1,228 @@
> +// SPDX-License-Identifier: (GPL-2.0+ or MIT)
> +/*
> + * Copyright (C) 2020 Arm Ltd.
> + */
> +
> +/dts-v1/;
> +
> +#include "sun50i-h616.dtsi"
> +
> +#include
> +#include
> +
> +/ {
> + model = "OrangePi Zero2";
> + compatible = "xunlong,orangepi-zero2", "allwinner,sun50i-h616";
> +
> + aliases {
> + ethernet0 = &emac0;
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + power {
> + label = "orangepi:red:power";
> + gpios = <&pio 2 13 GPIO_ACTIVE_HIGH>; /* PC13
> */
> + default-state = "on";
> + };
> +
> + status {
> + label = "orangepi:green:status";
> + gpios = <&pio 2 12 GPIO_ACTIVE_HIGH>; /* PC12
> */
> + };
> + };
> +
> + reg_vcc5v: vcc5v {
> + /* board wide 5V supply directly from the USB-C socket
> */
> + compatible = "regulator-fixed";
> + regulator-name = "vcc-5v";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + regulator-always-on;
> + };
> +
> + reg_usb1_vbus: usb1-vbus {
> + compatible = "regulator-fixed";
> + regulator-name = "usb1-vbus";
> + regulator-min-microvolt = <500>;
> + regulator-max-microvolt = <500>;
> + enable-active-high;
> + gpio = <&pio 2 16 GPIO_ACTIVE_HIGH>; /* PC16 */
> + status = "okay";
> + };
> +};
> +
> +&ehci0 {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +/* USB 2 & 3 are on headers only. */
> +
> +&emac0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ext_rgmii_pins>;
> + phy-mode = "rgmii";
> + phy-handle = <&ext_rgmii_phy>;
> + phy-supply = <®_dcdce>;
> + allwinner,rx-delay-ps = <3100>;
> + allwinner,tx-delay-ps = <700>;
> + status = "okay";
> +};
> +
> +&mdio {
> + ext_rgmii_phy: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + };
> +};
> +
> +&mmc0 {
> + vmmc-supply = <®_dcdce>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
> + bus-width = <4>;
> + status = "okay";
> +};
> +
> +&ohci0 {
> + status = "okay";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
> +
> +&r_i2c {
> + status = "okay";
> +
> + axp305: pmic@36 {
> + compatible = "x-powers,axp305", "x-powers,axp805",
> + "x-powers,axp806";
> + reg = <0x36>;
> +
> + /* dummy interrupt to appease the driver for now */
> + interrupts = ;
> + interrupt-controller;
> + #interrupt-cells = <1>;
Is dummy interrupt future-proof?
> +
> + x-powers,self-working-mode;
> + vina-supply = <®_vcc5v>;
> + vinb-supply = <®_vcc5v>;
> + vinc-supply = <®_vcc5v>;
> + vind-supply = <®_vcc5v>;
> + vine-supply = <®_vcc5v>;
> + aldoin-supply = <®_vcc5v>;
> + bldoin-supply = <®_vcc5v>;
> + cldoin-supply = <®_vcc5v>;
> +
> + regulators {
> + reg_aldo1: aldo1 {
> + regulator-always-on;
> +
Re: [PATCH 4/8] clk: sunxi-ng: Add support for the Allwinner H616 R-CCU
于 2020年12月2日 GMT+08:00 下午9:54:05, Andre Przywara 写到:
>The clocks itself are identical to the H6 R-CCU, it's just that the
>H616
>has not all of them implemented (or connected).
For selective clocks, try to follow the practice of V3(s) driver?
>
>Signed-off-by: Andre Przywara
>---
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c | 47 +-
> drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h | 3 +-
> 2 files changed, 48 insertions(+), 2 deletions(-)
>
>diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>index 50f8d1bc7046..119d1797f501 100644
>--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.c
>@@ -136,6 +136,15 @@ static struct ccu_common *sun50i_h6_r_ccu_clks[] =
>{
> &w1_clk.common,
> };
>
>+static struct ccu_common *sun50i_h616_r_ccu_clks[] = {
>+ &r_apb1_clk.common,
>+ &r_apb2_clk.common,
>+ &r_apb1_twd_clk.common,
>+ &r_apb2_i2c_clk.common,
>+ &r_apb1_ir_clk.common,
>+ &ir_clk.common,
>+};
>+
> static struct clk_hw_onecell_data sun50i_h6_r_hw_clks = {
> .hws= {
> [CLK_AR100] = &ar100_clk.common.hw,
>@@ -152,7 +161,20 @@ static struct clk_hw_onecell_data
>sun50i_h6_r_hw_clks = {
> [CLK_IR]= &ir_clk.common.hw,
> [CLK_W1]= &w1_clk.common.hw,
> },
>- .num= CLK_NUMBER,
>+ .num= CLK_NUMBER_H616,
>+};
>+
>+static struct clk_hw_onecell_data sun50i_h616_r_hw_clks = {
>+ .hws= {
>+ [CLK_R_AHB] = &r_ahb_clk.hw,
>+ [CLK_R_APB1]= &r_apb1_clk.common.hw,
>+ [CLK_R_APB2]= &r_apb2_clk.common.hw,
>+ [CLK_R_APB1_TWD]= &r_apb1_twd_clk.common.hw,
>+ [CLK_R_APB2_I2C]= &r_apb2_i2c_clk.common.hw,
>+ [CLK_R_APB1_IR] = &r_apb1_ir_clk.common.hw,
>+ [CLK_IR]= &ir_clk.common.hw,
>+ },
>+ .num= CLK_NUMBER_H616,
> };
>
> static struct ccu_reset_map sun50i_h6_r_ccu_resets[] = {
>@@ -165,6 +187,12 @@ static struct ccu_reset_map
>sun50i_h6_r_ccu_resets[] = {
> [RST_R_APB1_W1] = { 0x1ec, BIT(16) },
> };
>
>+static struct ccu_reset_map sun50i_h616_r_ccu_resets[] = {
>+ [RST_R_APB1_TWD]= { 0x12c, BIT(16) },
>+ [RST_R_APB2_I2C]= { 0x19c, BIT(16) },
>+ [RST_R_APB1_IR] = { 0x1cc, BIT(16) },
>+};
>+
> static const struct sunxi_ccu_desc sun50i_h6_r_ccu_desc = {
> .ccu_clks = sun50i_h6_r_ccu_clks,
> .num_ccu_clks = ARRAY_SIZE(sun50i_h6_r_ccu_clks),
>@@ -175,6 +203,16 @@ static const struct sunxi_ccu_desc
>sun50i_h6_r_ccu_desc = {
> .num_resets = ARRAY_SIZE(sun50i_h6_r_ccu_resets),
> };
>
>+static const struct sunxi_ccu_desc sun50i_h616_r_ccu_desc = {
>+ .ccu_clks = sun50i_h616_r_ccu_clks,
>+ .num_ccu_clks = ARRAY_SIZE(sun50i_h616_r_ccu_clks),
>+
>+ .hw_clks= &sun50i_h616_r_hw_clks,
>+
>+ .resets = sun50i_h616_r_ccu_resets,
>+ .num_resets = ARRAY_SIZE(sun50i_h616_r_ccu_resets),
>+};
>+
> static void __init sunxi_r_ccu_init(struct device_node *node,
> const struct sunxi_ccu_desc *desc)
> {
>@@ -195,3 +233,10 @@ static void __init sun50i_h6_r_ccu_setup(struct
>device_node *node)
> }
> CLK_OF_DECLARE(sun50i_h6_r_ccu, "allwinner,sun50i-h6-r-ccu",
> sun50i_h6_r_ccu_setup);
>+
>+static void __init sun50i_h616_r_ccu_setup(struct device_node *node)
>+{
>+ sunxi_r_ccu_init(node, &sun50i_h616_r_ccu_desc);
>+}
>+CLK_OF_DECLARE(sun50i_h616_r_ccu, "allwinner,sun50i-h616-r-ccu",
>+ sun50i_h616_r_ccu_setup);
>diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
>b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
>index 782117dc0b28..128302696ca1 100644
>--- a/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
>+++ b/drivers/clk/sunxi-ng/ccu-sun50i-h6-r.h
>@@ -14,6 +14,7 @@
>
> #define CLK_R_APB23
>
>-#define CLK_NUMBER(CLK_W1 + 1)
>+#define CLK_NUMBER_H6 (CLK_W1 + 1)
>+#define CLK_NUMBER_H616 (CLK_IR + 1)
>
> #endif /* _CCU_SUN50I_H6_R_H */
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道： > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote: > > > > > > > Okay. But I'm not satisfied with a non-public sample > > > > > > > occupies > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a > > > > > > > pinetab-retail okay? > > > > > > > > > > > > To me, naming the production version anything but "pinetab" > > > > > > isn't > > > > > > satisfying either. > > > > > > > > > > I understand where you're coming from, but the point I was > > > > > making my > > > > > previous mail is precisely that it's not really possible. > > > > > > > > > > You want to name the early adopter version _the_ production > > > > > version. Let's assume the hardware changes again between the > > > > > early > > > > > adopter and mass-production version. Which one will be _the_ > > > > > production version? The early-adopter or the mass-produced > > > > > one? > > > > > > > > > > There's really no good answer here, and both would suck in > > > > > their > > > > > own way. The only way to deal with this is to simply avoid > > > > > defining one version as the one true board, and just loading > > > > > the > > > > > proper DT in u-boot based on whatever clue we have of the > > > > > hardware > > > > > revision. > > > > Then will it be okay to rename current pinetab DT to > > > > pinetab-sample and then introduce new DTs all with suffixes? > > > > > > No. From my previous mail: > > > > It can be seen as dropping the PineTab DT and introduce new DTs > > with > > suffix. > > > > Do we have rule that we cannot drop boards? > > Are you really arguing that removing a DT and then adding an > identical > one under a different name is not renaming it? Then we can just keep confusing name? If we do so, how can we mark the new DT as "the user should use this one"?
[PATCH] drm/panel: feiyang-fy07024di26a30d: cleanup if panel attaching failed
Attaching the panel can fail, so cleanup work is necessary, otherwise
a pointer to freed struct drm_panel* will remain in drm_panel code.
Do the cleanup if panel attaching failed.
Fixes: 69dc678abc2b ("drm/panel: Add Feiyang FY07024DI26A30-D MIPI-DSI LCD
panel")
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
index 581661b506f8..f9c1f7bc8218 100644
--- a/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
+++ b/drivers/gpu/drm/panel/panel-feiyang-fy07024di26a30d.c
@@ -227,7 +227,13 @@ static int feiyang_dsi_probe(struct mipi_dsi_device *dsi)
dsi->format = MIPI_DSI_FMT_RGB888;
dsi->lanes = 4;
- return mipi_dsi_attach(dsi);
+ ret = mipi_dsi_attach(dsi);
+ if (ret < 0) {
+ drm_panel_remove(&ctx->panel);
+ return ret;
+ }
+
+ return 0;
}
static int feiyang_dsi_remove(struct mipi_dsi_device *dsi)
--
2.28.0
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月28日 GMT+08:00 下午7:54:04, "Clément Péron" 写到: >Hi Icenowy, > >On Sat, 28 Nov 2020 at 12:28, Icenowy Zheng wrote: >> >> 在 2020-11-28星期六的 11:38 +0100，Maxime Ripard写道： >> > On Mon, Nov 23, 2020 at 09:10:38PM +0800, Icenowy Zheng wrote: >> > > > > > > > Okay. But I'm not satisfied with a non-public sample >> > > > > > > > occupies >> > > > > > > > the pinetab name. Is rename it to pinetab-dev and add a >> > > > > > > > pinetab-retail okay? >> > > > > > > >> > > > > > > To me, naming the production version anything but >"pinetab" >> > > > > > > isn't >> > > > > > > satisfying either. >> > > > > > >> > > > > > I understand where you're coming from, but the point I was >> > > > > > making my >> > > > > > previous mail is precisely that it's not really possible. >> > > > > > >> > > > > > You want to name the early adopter version _the_ production >> > > > > > version. Let's assume the hardware changes again between >the >> > > > > > early >> > > > > > adopter and mass-production version. Which one will be >_the_ >> > > > > > production version? The early-adopter or the mass-produced >> > > > > > one? >> > > > > > >> > > > > > There's really no good answer here, and both would suck in >> > > > > > their >> > > > > > own way. The only way to deal with this is to simply avoid >> > > > > > defining one version as the one true board, and just >loading >> > > > > > the >> > > > > > proper DT in u-boot based on whatever clue we have of the >> > > > > > hardware >> > > > > > revision. >> > > > > Then will it be okay to rename current pinetab DT to >> > > > > pinetab-sample and then introduce new DTs all with suffixes? >> > > > >> > > > No. From my previous mail: >> > > >> > > It can be seen as dropping the PineTab DT and introduce new DTs >> > > with >> > > suffix. >> > > >> > > Do we have rule that we cannot drop boards? >> > >> > Are you really arguing that removing a DT and then adding an >> > identical >> > one under a different name is not renaming it? >> >> Then we can just keep confusing name? > >Sorry maybe I missed some information >But why don't you do like pinephone? They're the same board revision with different LCD panels. And the major problem is that the DT for samples is already submitted under the name "PineTab". >sun50i-a64-pinetab-1.0.dts >sun50i-a64-pinetab-1.1.dts > >-dev is also a confusing name I think, as the board has been already >shipped. > >Regards, >Clement > > >> >> If we do so, how can we mark the new DT as "the user should use this >> one"? >> >> -- >> You received this message because you are subscribed to the Google >Groups "linux-sunxi" group. >> To unsubscribe from this group and stop receiving emails from it, >send an email to linux-sunxi+unsubscr...@googlegroups.com. >> To view this discussion on the web, visit >https://groups.google.com/d/msgid/linux-sunxi/1666a61f6ea3e7d573795f9000a0b096c7b7dee0.camel%40aosc.io.
Re: [PATCH] ARM: dts: sun8i: s3: pinecube: add ethernet alias for Wi-Fi
在 2020-11-25星期三的 06:59 +0800，Icenowy Zheng写道：
> The PineCube board has a RTL8189ES Wi-Fi module on board, and the
> module
> doesn't have any MAC address programmed in.
Sorry, but now I'm unsure about this.
The module seems to have MAC address programmed.
>
> Add a ethernet alias in the DT, thus the bootloader will then be able
> to
> generate a MAC address into the device tree node of Wi-Fi.
>
> Signed-off-by: Icenowy Zheng
> ---
> arch/arm/boot/dts/sun8i-s3-pinecube.dts | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
> b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
> index 4aa0ee897a0a..5086f713467a 100644
> --- a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
> +++ b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
> @@ -13,6 +13,7 @@ / {
> compatible = "pine64,pinecube", "sochip,s3", "allwinner,sun8i-
> v3";
>
> aliases {
> + ethernet0 = &rtl8189es;
> serial0 = &uart2;
> };
>
> @@ -156,6 +157,10 @@ &mmc1 {
> bus-width = <4>;
> non-removable;
> status = "okay";
> +
> + rtl8189es: wifi@1 {
> + reg = <1>;
> + };
> };
>
> &pio {
[PATCH] ARM: dts: sun8i: s3: pinecube: add ethernet alias for Wi-Fi
The PineCube board has a RTL8189ES Wi-Fi module on board, and the module
doesn't have any MAC address programmed in.
Add a ethernet alias in the DT, thus the bootloader will then be able to
generate a MAC address into the device tree node of Wi-Fi.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-s3-pinecube.dts | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
index 4aa0ee897a0a..5086f713467a 100644
--- a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
+++ b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
@@ -13,6 +13,7 @@ / {
compatible = "pine64,pinecube", "sochip,s3", "allwinner,sun8i-v3";
aliases {
+ ethernet0 = &rtl8189es;
serial0 = &uart2;
};
@@ -156,6 +157,10 @@ &mmc1 {
bus-width = <4>;
non-removable;
status = "okay";
+
+ rtl8189es: wifi@1 {
+ reg = <1>;
+ };
};
&pio {
--
2.28.0
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月23日 GMT+08:00 下午8:53:32, Maxime Ripard 写到:
>On Mon, Nov 23, 2020 at 07:25:47PM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2020年11月23日 GMT+08:00 下午7:15:12, Maxime Ripard
>写到:
>> >Hi!
>> >
>> >On Fri, Nov 20, 2020 at 08:51:48PM -0600, Samuel Holland wrote:
>> >> On 11/20/20 5:30 PM, Icenowy Zheng wrote:
>> >> >>>>>>> +/ {
>> >> >>>>>>> + model = "PineTab Developer Sample";
>> >> >>>>>>> + compatible = "pine64,pinetab-dev",
>"allwinner,sun50i-a64";
>> >> >>>>>>> +};
>> >> >>>>>>
>> >> >>>>>> Changing the DT and the compatible half-way through it
>isn't
>> >ok. Please
>> >> >>>>>> add a new DT with the newer revision like we did for the
>> >pinephone
>> >> >>>>>
>> >> >>>>> We did this on Pine H64.
>> >> >>>>
>> >> >>>> What are you referring to? I couldn't find a commit where we
>did
>> >what
>> >> >>>> you suggested in that patch to the pine H64.
>> >> >>>
>> >> >>> Oh the situation is complex. On Pine H64, we didn't specify
>> >anything at
>> >> >>> start (which is the same here), the DT is originally
>> >version-neutral
>> >> >>> but then transitioned to model B, then reverted to model A.
>Here
>> >the DT is always
>> >> >>> for the sample.
>> >> >>>
>> >> >>> However, for Pine H64 there's model A/B names, but for PineTab
>> >there's no
>> >> >>> any samples that are sold, thus except who got the samples,
>all
>> >PineTab
>> >> >>> owners simply owns a "PineTab", not a "PineTab xxx version".
>> >> >>
>> >> >> It's fairly simple really, we can't really predict the future,
>so
>> >any DT
>> >> >> submitted is for the current version of whatever board there
>is.
>> >This is
>> >>
>> >> I don't think that was the intention at all. The DT was submitted
>for
>> >a
>> >> future product, whatever that future product ends up being at the
>> >time
>> >> of its release. Since there are necessarily no users until the
>> >product
>> >> ships, there is no chance of breaking users by modifying the DT.
>> >
>> >There was no indication of that in the commit though
>> >
>> >> >> what we (somewhat messily) did for the PineH64, for the
>pinephone,
>> >or
>> >> >> really any other board that has several revisions
>> >>
>> >> Surely a non-public prototype doesn't count as a separate
>revision!
>> >This
>> >> sort of policy strongly discourages ever shipping a board with
>> >> out-of-the-box mainline Linux support. Because if there any
>hardware
>> >> bugs fixed between initial upstreaming and production, the
>> >manufacture
>> >> must come up with a new DT name.
>> >>
>> >> This is hostile to the users as well, because the "canonical" DT
>name
>> >no
>> >> longer matches the "canonical" (read: the only one ever available)
>> >> version of the hardware.
>> >>
>> >> Do you want manufacturers to submit their initial board DT as
>> >> "$BOARD-prototype.dts", just in case they have to make a change
>> >before
>> >> production? And only after the board is shipped (with out-of-tree
>> >> patches, of course, to use $BOARD.dts, since the shipped board is
>> >*not*
>> >> the prototype) submit a "$BOARD.dts" to mainline?
>> >>
>> >> Maxime, can you clarify specifically what the line is where a
>device
>> >> tree is "locked down" and further changes to the hardware require
>a
>> >new
>> >> name? First sample leaves the factory? $NUMBER units produced?
>First
>> >> sold to the public for money?
>> >
>> >The first board that is shipped to a user. From the wiki, the
>version
>> >supported here (I guess?) has been shipped to around 100 people, so
>it
>> >doesn't really qualify for the "non-public proto
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月23日 GMT+08:00 下午7:15:12, Maxime Ripard 写到:
>Hi!
>
>On Fri, Nov 20, 2020 at 08:51:48PM -0600, Samuel Holland wrote:
>> On 11/20/20 5:30 PM, Icenowy Zheng wrote:
>> >>>>>>> +/ {
>> >>>>>>> +model = "PineTab Developer Sample";
>> >>>>>>> +compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> >>>>>>> +};
>> >>>>>>
>> >>>>>> Changing the DT and the compatible half-way through it isn't
>ok. Please
>> >>>>>> add a new DT with the newer revision like we did for the
>pinephone
>> >>>>>
>> >>>>> We did this on Pine H64.
>> >>>>
>> >>>> What are you referring to? I couldn't find a commit where we did
>what
>> >>>> you suggested in that patch to the pine H64.
>> >>>
>> >>> Oh the situation is complex. On Pine H64, we didn't specify
>anything at
>> >>> start (which is the same here), the DT is originally
>version-neutral
>> >>> but then transitioned to model B, then reverted to model A. Here
>the DT is always
>> >>> for the sample.
>> >>>
>> >>> However, for Pine H64 there's model A/B names, but for PineTab
>there's no
>> >>> any samples that are sold, thus except who got the samples, all
>PineTab
>> >>> owners simply owns a "PineTab", not a "PineTab xxx version".
>> >>
>> >> It's fairly simple really, we can't really predict the future, so
>any DT
>> >> submitted is for the current version of whatever board there is.
>This is
>>
>> I don't think that was the intention at all. The DT was submitted for
>a
>> future product, whatever that future product ends up being at the
>time
>> of its release. Since there are necessarily no users until the
>product
>> ships, there is no chance of breaking users by modifying the DT.
>
>There was no indication of that in the commit though
>
>> >> what we (somewhat messily) did for the PineH64, for the pinephone,
>or
>> >> really any other board that has several revisions
>>
>> Surely a non-public prototype doesn't count as a separate revision!
>This
>> sort of policy strongly discourages ever shipping a board with
>> out-of-the-box mainline Linux support. Because if there any hardware
>> bugs fixed between initial upstreaming and production, the
>manufacture
>> must come up with a new DT name.
>>
>> This is hostile to the users as well, because the "canonical" DT name
>no
>> longer matches the "canonical" (read: the only one ever available)
>> version of the hardware.
>>
>> Do you want manufacturers to submit their initial board DT as
>> "$BOARD-prototype.dts", just in case they have to make a change
>before
>> production? And only after the board is shipped (with out-of-tree
>> patches, of course, to use $BOARD.dts, since the shipped board is
>*not*
>> the prototype) submit a "$BOARD.dts" to mainline?
>>
>> Maxime, can you clarify specifically what the line is where a device
>> tree is "locked down" and further changes to the hardware require a
>new
>> name? First sample leaves the factory? $NUMBER units produced? First
>> sold to the public for money?
>
>The first board that is shipped to a user. From the wiki, the version
>supported here (I guess?) has been shipped to around 100 people, so it
>doesn't really qualify for the "non-public prototype". We still have to
>support these users, whether we like it or not.
>
>> Without some guidance, or a change in policy, this problem is going
>to
>> keep coming up again and again.
>
>There's a few things that are interleaved here. First, there's two hard
>rules: never change the DT name and never change the compatible of a
>board.
>
>The former would break any build system, boot script or documentation,
>and the latter would break the DT compatibility.
>
>Aside from this, things get a bit blurrier since it's mostly about the
>intent. I'm fine with having a DT for a non-public prototype if it's
>clear from day one that it is. In this particular case, the DT just
>stated that support for the pinetab was added. I guess anyone would
>make
>the assumption without any context that this would be for the (or a)
>final design.
>
>Finally, I'd also
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月20日 GMT+08:00 下午11:59:39, Maxime Ripard 写到:
>On Tue, Nov 17, 2020 at 02:36:48AM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2020年11月16日 GMT+08:00 下午11:55:08, Maxime Ripard
>写到:
>> >On Tue, Nov 10, 2020 at 06:41:37PM +0800, Icenowy Zheng wrote:
>> >>
>> >>
>> >> 于 2020年11月10日 GMT+08:00 下午6:39:25, Maxime Ripard
>
>> >写到:
>> >> >On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
>> >> >> Some developers received PineTab samples that used an old LCD
>> >panel.
>> >> >>
>> >> >> Add device tree for these samples.
>> >> >>
>> >> >> Signed-off-by: Icenowy Zheng
>> >> >> ---
>> >> >> arch/arm64/boot/dts/allwinner/Makefile| 1 +
>> >> >> .../dts/allwinner/sun50i-a64-pinetab-dev.dts | 28
>> >> >+++
>> >> >> 2 files changed, 29 insertions(+)
>> >> >> create mode 100644
>> >> >arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> >>
>> >> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> index 211d1e9d4701..a221dcebfad4 100644
>> >> >> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> >> >> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) +=
>> >> >sun50i-a64-pinephone-1.0.dtb
>> >> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
>> >> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
>> >> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
>> >> >> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
>> >> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> >> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> >> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
>> >> >> diff --git
>> >a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> >> new file mode 100644
>> >> >> index ..3a4153890f3e
>> >> >> --- /dev/null
>> >> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> >> @@ -0,0 +1,28 @@
>> >> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> >> >> +/*
>> >> >> + * Copyright (C) 2020 Icenowy Zheng
>> >> >> + *
>> >> >> + */
>> >> >> +
>> >> >> +/dts-v1/;
>> >> >> +
>> >> >> +#include "sun50i-a64-pinetab.dts"
>> >> >> +
>> >> >> +/ {
>> >> >> + model = "PineTab Developer Sample";
>> >> >> + compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> >> >> +};
>> >> >
>> >> >Changing the DT and the compatible half-way through it isn't ok.
>> >Please
>> >> >add a new DT with the newer revision like we did for the
>pinephone
>> >>
>> >> We did this on Pine H64.
>> >
>> >What are you referring to? I couldn't find a commit where we did
>what
>> >you suggested in that patch to the pine H64.
>>
>> Oh the situation is complex. On Pine H64, we didn't specify anything
>at
>> start (which is the same here), the DT is originally version-neutral
>> but then transitioned to model B, then reverted to model A. Here the
>DT is always
>> for the sample.
>>
>> However, for Pine H64 there's model A/B names, but for PineTab
>there's no
>> any samples that are sold, thus except who got the samples, all
>PineTab
>> owners simply owns a "PineTab", not a "PineTab xxx version".
>
>It's fairly simple really, we can't really predict the future, so any
>DT
>submitted is for the current version of whatever board there is. This
>is
>what we (somewhat messily) did for the PineH64, for the pinephone, or
>really any other board that has several revisions
Okay. But I'm not satisfied with a non-public sample occupies
the pinetab name. Is rename it to pinetab-dev and add a
pinetab-retail okay?
>
>Maxime
[PATCH] ARM: dts: sun8i: v3s: fix GIC node memory range
Currently the GIC node in V3s DTSI follows some old DT examples, and
being broken. This leads a warning at boot.
Fix this.
Fixes: f989086ccbc6 ("ARM: dts: sunxi: add dtsi file for V3s SoC")
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 7b2d684aeb97..f8f19d8fa795 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -545,7 +545,7 @@ csi1: camera@1cb4000 {
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
- <0x01c82000 0x1000>,
+ <0x01c82000 0x2000>,
<0x01c84000 0x2000>,
<0x01c86000 0x2000>;
interrupt-controller;
--
2.28.0
Re: [linux-sunxi] Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月16日 GMT+08:00 下午11:55:08, Maxime Ripard 写到:
>On Tue, Nov 10, 2020 at 06:41:37PM +0800, Icenowy Zheng wrote:
>>
>>
>> 于 2020年11月10日 GMT+08:00 下午6:39:25, Maxime Ripard
>写到:
>> >On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
>> >> Some developers received PineTab samples that used an old LCD
>panel.
>> >>
>> >> Add device tree for these samples.
>> >>
>> >> Signed-off-by: Icenowy Zheng
>> >> ---
>> >> arch/arm64/boot/dts/allwinner/Makefile| 1 +
>> >> .../dts/allwinner/sun50i-a64-pinetab-dev.dts | 28
>> >+++
>> >> 2 files changed, 29 insertions(+)
>> >> create mode 100644
>> >arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >>
>> >> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>> >b/arch/arm64/boot/dts/allwinner/Makefile
>> >> index 211d1e9d4701..a221dcebfad4 100644
>> >> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> >> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> >> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) +=
>> >sun50i-a64-pinephone-1.0.dtb
>> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
>> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
>> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
>> >> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
>> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> >> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
>> >> diff --git
>a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> new file mode 100644
>> >> index ..3a4153890f3e
>> >> --- /dev/null
>> >> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> >> @@ -0,0 +1,28 @@
>> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> >> +/*
>> >> + * Copyright (C) 2020 Icenowy Zheng
>> >> + *
>> >> + */
>> >> +
>> >> +/dts-v1/;
>> >> +
>> >> +#include "sun50i-a64-pinetab.dts"
>> >> +
>> >> +/ {
>> >> + model = "PineTab Developer Sample";
>> >> + compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> >> +};
>> >
>> >Changing the DT and the compatible half-way through it isn't ok.
>Please
>> >add a new DT with the newer revision like we did for the pinephone
>>
>> We did this on Pine H64.
>
>What are you referring to? I couldn't find a commit where we did what
>you suggested in that patch to the pine H64.
Oh the situation is complex. On Pine H64, we didn't specify anything at
start (which is the same here), the DT is originally version-neutral
but then transitioned to model B, then reverted to model A. Here the DT is
always
for the sample.
However, for Pine H64 there's model A/B names, but for PineTab there's no
any samples that are sold, thus except who got the samples, all PineTab
owners simply owns a "PineTab", not a "PineTab xxx version".
>
>Maxime
Re: [PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
于 2020年11月10日 GMT+08:00 下午6:39:25, Maxime Ripard 写到:
>On Sat, Nov 07, 2020 at 08:53:32PM +0800, Icenowy Zheng wrote:
>> Some developers received PineTab samples that used an old LCD panel.
>>
>> Add device tree for these samples.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> arch/arm64/boot/dts/allwinner/Makefile| 1 +
>> .../dts/allwinner/sun50i-a64-pinetab-dev.dts | 28
>+++
>> 2 files changed, 29 insertions(+)
>> create mode 100644
>arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>>
>> diff --git a/arch/arm64/boot/dts/allwinner/Makefile
>b/arch/arm64/boot/dts/allwinner/Makefile
>> index 211d1e9d4701..a221dcebfad4 100644
>> --- a/arch/arm64/boot/dts/allwinner/Makefile
>> +++ b/arch/arm64/boot/dts/allwinner/Makefile
>> @@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) +=
>sun50i-a64-pinephone-1.0.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
>> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
>> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
>> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> new file mode 100644
>> index ..3a4153890f3e
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
>> @@ -0,0 +1,28 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +/*
>> + * Copyright (C) 2020 Icenowy Zheng
>> + *
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "sun50i-a64-pinetab.dts"
>> +
>> +/ {
>> +model = "PineTab Developer Sample";
>> +compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
>> +};
>
>Changing the DT and the compatible half-way through it isn't ok. Please
>add a new DT with the newer revision like we did for the pinephone
We did this on Pine H64.
>
>Maxime
[RFC PATCH 2/2] clk: sunxi-ng: a64: disable mux and pll notifiers for CPUX reclocking
After the dividers of PLL-CPUX disabled, there's no need for PLL-CPUX to
be gated when tweaking the clock of CPUX, thus reparenting CPUX to
osc24M is also now not needed.
Remove these notifiers.
Preventing reparenting CPUX is said to be able to help solving the issue
that the timer jumps backward according to Ondrej Jirman.
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 6108d150a0e3..67d570efe5bd 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -943,7 +943,6 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
struct resource *res;
void __iomem *reg;
u32 val;
- int ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
reg = devm_ioremap_resource(&pdev->dev, res);
@@ -1029,18 +1028,7 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
writel(val, reg + SUN50I_A64_CPUX_AXI_REG);
}
- ret = sunxi_ccu_probe(pdev->dev.of_node, reg, &sun50i_a64_ccu_desc);
- if (ret)
- return ret;
-
- /* Gate then ungate PLL CPU after any rate changes */
- ccu_pll_notifier_register(&sun50i_a64_pll_cpu_nb);
-
- /* Reparent CPU during PLL CPU rate changes */
- ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
- &sun50i_a64_cpu_nb);
-
- return 0;
+ return sunxi_ccu_probe(pdev->dev.of_node, reg, &sun50i_a64_ccu_desc);
}
static const struct of_device_id sun50i_a64_ccu_ids[] = {
--
2.28.0
[RFC PATCH 1/2] clk: sunxi-ng: a64: disable dividers in PLL-CPUX
According to the user manual, PLL-CPUX have two dividers, in which P is
only allowed when the desired rate is less than 240MHz. As the CCU
framework have no such feature yet and the clock rate that allows P is
much lower than where we normally operate, disallow the usage of P
factor now.
M is not restricted in the user manual, however according to the BSP PLL
setup table (see [1]), it's not used at all. To follow what the BSP
does, disable this factor too.
Disabling the dividers will make it possible to remove the need to
switch to osc24M when doing frequency scaling on PLL-CPUX.
In order to prevent boot-time usage of dividers (current known mainline
U-Boot implementation use m = 2), tweaking of the factors are done when
probing CCU driver.
Signed-off-by: Icenowy Zheng
---
drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 79 ++-
1 file changed, 77 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 5f66bf879772..6108d150a0e3 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -23,13 +24,14 @@
#include "ccu-sun50i-a64.h"
+#define SUN50I_A64_PLL_CPUX_REG0x000
static struct ccu_nkmp pll_cpux_clk = {
.enable = BIT(31),
.lock = BIT(28),
.n = _SUNXI_CCU_MULT(8, 5),
.k = _SUNXI_CCU_MULT(4, 2),
- .m = _SUNXI_CCU_DIV(0, 2),
- .p = _SUNXI_CCU_DIV_MAX(16, 2, 4),
+ .m = _SUNXI_CCU_DIV_MAX(16, 2, 1),
+ .p = _SUNXI_CCU_DIV_MAX(0, 2, 1),
.common = {
.reg= 0x000,
.hw.init= CLK_HW_INIT("pll-cpux",
@@ -215,6 +217,7 @@ static SUNXI_CCU_NM_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
BIT(28), /* lock */
CLK_SET_RATE_UNGATE);
+#define SUN50I_A64_CPUX_AXI_REG0x050
static const char * const cpux_parents[] = { "osc32k", "osc24M",
"pll-cpux", "pll-cpux" };
static SUNXI_CCU_MUX(cpux_clk, "cpux", cpux_parents,
@@ -954,6 +957,78 @@ static int sun50i_a64_ccu_probe(struct platform_device
*pdev)
writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG);
+ /* Disable any possible dividers on PLL-CPUX */
+ val = readl(reg + SUN50I_A64_PLL_CPUX_REG);
+ if (val & (GENMASK(17, 16) | GENMASK(1, 0))) {
+ unsigned int n, k, m, p;
+
+ n = ((val & GENMASK(12, 8)) >> 8) + 1;
+ k = ((val & GENMASK(5, 4)) >> 4) + 1;
+ m = (val & GENMASK(1, 0)) + 1;
+ p = 1 << ((val & GENMASK(17, 16)) >> 16);
+
+ /*
+* Known mainline U-Boot revisions never uses
+* divider p, and it will only use m when k = 3 or 4.
+* Specially judge for these cases, to satisfy
+* what will most possibly happen.
+* For m = 2 and k = 3, fractional change will be
+* applied to n, to mostly keep the clock rate.
+* For m = 2 and k = 4, just change to m = 1 and k = 2.
+* For other cases, just try to divide it from N.
+*/
+ if (p >= 2) {
+ n /= p;
+ p = 1;
+ }
+
+ if (m == 2) {
+ if (k == 3) {
+ k = 2;
+ n = n * 3 / 4;
+ m = 1;
+ }
+ if (k == 4) {
+ k = 2;
+ m = 1;
+ }
+ }
+
+ if (m >= 2) {
+ n /= m;
+ m = 1;
+ }
+
+ /* The user manual constrains n*k >= 10 */
+ if (n * k < 10) {
+ n = 10;
+ k = 1;
+ }
+
+ /* Switch CPUX clock to osc24M temporarily */
+ val = readl(reg + SUN50I_A64_CPUX_AXI_REG);
+ val &= ~GENMASK(17, 16);
+ val |= (1 << 16);
+ writel(val, reg + SUN50I_A64_CPUX_AXI_REG);
+ udelay(1);
+
+ /* Setup PLL-CPUX with new factors */
+ val = ((n - 1) << 8) | ((k - 1) << 4);
+ writel(val, reg + SUN50I_A64_PLL_CPUX_REG);
+ val |= BIT(31);
+ writel(val, reg + SUN50I_A64_PLL_CPUX_REG);
+ do {
+ /* Wait the PLL to lock */
+
[RFC PATCH 0/2] clk: sunxi-ng: a64: Remove CPUX mux switching
According to Ondrej Jirman, switching of the mux of CPUX clock is one of the sources of timer jumps on A64 (and maybe this will also lead to timer jump on H3). This patchset tries to remove this mux by disabling the dividers in PLL-CPUX. Both the lack of reparent when relocking and the prevention of PLL-CPUX dividers are behaviors of the BSP kernel. Icenowy Zheng (2): clk: sunxi-ng: a64: disable dividers in PLL-CPUX clk: sunxi-ng: a64: disable mux and pll notifiers for CPUX reclocking drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 93 ++- 1 file changed, 78 insertions(+), 15 deletions(-) -- 2.28.0
[PATCH 3/3] arm64: allwinner: dts: a64: add DT for PineTab developer sample
Some developers received PineTab samples that used an old LCD panel.
Add device tree for these samples.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/Makefile| 1 +
.../dts/allwinner/sun50i-a64-pinetab-dev.dts | 28 +++
2 files changed, 29 insertions(+)
create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
diff --git a/arch/arm64/boot/dts/allwinner/Makefile
b/arch/arm64/boot/dts/allwinner/Makefile
index 211d1e9d4701..a221dcebfad4 100644
--- a/arch/arm64/boot/dts/allwinner/Makefile
+++ b/arch/arm64/boot/dts/allwinner/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.0.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.1.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinephone-1.2.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab.dtb
+dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pinetab-dev.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-sopine-baseboard.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-teres-i.dtb
dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a100-allwinner-perf1.dtb
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
new file mode 100644
index ..3a4153890f3e
--- /dev/null
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2020 Icenowy Zheng
+ *
+ */
+
+/dts-v1/;
+
+#include "sun50i-a64-pinetab.dts"
+
+/ {
+ model = "PineTab Developer Sample";
+ compatible = "pine64,pinetab-dev", "allwinner,sun50i-a64";
+};
+
+&dsi {
+ /delete-node/ panel@0;
+
+ panel@0 {
+ compatible = "feixin,k101-im2ba02";
+ reg = <0>;
+ avdd-supply = <®_dc1sw>;
+ dvdd-supply = <®_dc1sw>;
+ cvdd-supply = <®_ldo_io1>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ backlight = <&backlight>;
+ };
+};
--
2.28.0
[PATCH 2/3] dt-bindings: arm: sunxi: add PineTab developer sample DT binding
Some developer samples of PineTab are distributed with the old and incompatible LCD panel. Add a device tree binding for this version of PineTab. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index ea07f57379d3..9cc5990dc311 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -682,6 +682,11 @@ properties: - const: pine64,pinetab - const: allwinner,sun50i-a64 + - description: Pine64 PineTab (Developer sample with the old LCD panel) +items: + - const: pine64,pinetab-dev + - const: allwinner,sun50i-a64 + - description: Pine64 SoPine Baseboard items: - const: pine64,sopine-baseboard -- 2.28.0
[PATCH 1/3] arm64: allwinner: dts: a64: pinetab: switch LCD panel to production one
All retail PineTabs use the new panel. Devices with the old panel are
only available to several developers as sample.
Switch the main PineTab DT to use the new panel, as it should reflect
what the retail device uses. Another DT for developers' sample will be
added later.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
index 0494bfaf2ffa..d91a019301bf 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -150,12 +150,10 @@ &dsi {
status = "okay";
panel@0 {
- compatible = "feixin,k101-im2ba02";
+ compatible = "feixin,k101-im2byl02";
reg = <0>;
- avdd-supply = <®_dc1sw>;
- dvdd-supply = <®_dc1sw>;
- cvdd-supply = <®_ldo_io1>;
- reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
+ power-supply = <®_dc1sw>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
backlight = <&backlight>;
};
};
--
2.28.0
[PATCH 0/3] Switch PineTab DT LCD panel to retail one
Retail PineTabs switched to K101-IM2BYL02 panel. This patchset tries to reflect this change, and add a DT for samples that still have K101-IM2BA02. Icenowy Zheng (3): arm64: allwinner: dts: a64: pinetab: switch LCD panel to production one dt-bindings: arm: sunxi: add PineTab developer sample DT binding arm64: allwinner: dts: a64: add DT for PineTab developer sample .../devicetree/bindings/arm/sunxi.yaml| 5 arch/arm64/boot/dts/allwinner/Makefile| 1 + .../dts/allwinner/sun50i-a64-pinetab-dev.dts | 28 +++ .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 8 ++ 4 files changed, 37 insertions(+), 5 deletions(-) create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab-dev.dts -- 2.28.0
Re: [PATCH 4/5] dt-bindings: arm: sunxi: add Elimo bindings
于 2020年10月30日 GMT+08:00 上午8:24:04, Matteo Scordino 写到: >Hello, > >thank you both for reviewing. > >I didn't realise the file was kept in alphabetical order, I will fix >that. >And I agree that board/som + "sochip,s3, allwinner,sun8i-v3" makes >sense, >I will resubmit the patch with those (and sync them with the dt >bindings file). > >Should I submit a patch to update the pinecube to use "sochip,s3, >allwinner,sun8i-v3", too? If possible, thanks.
Re: [PATCH 4/5] dt-bindings: arm: sunxi: add Elimo bindings
于 2020年10月29日 GMT+08:00 下午6:13:04, Maxime Ripard 写到: >Hi, > >On Thu, Oct 29, 2020 at 02:19:59AM +, Matteo Scordino wrote: >> Document board compatible names for Elimo Engineering Impetus and >Initium >> >> Signed-off-by: Matteo Scordino >> --- >> Documentation/devicetree/bindings/arm/sunxi.yaml | 10 ++ >> 1 file changed, 10 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml >b/Documentation/devicetree/bindings/arm/sunxi.yaml >> index 0f23133672a3..55405809ec91 100644 >> --- a/Documentation/devicetree/bindings/arm/sunxi.yaml >> +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml >> @@ -898,3 +898,13 @@ properties: >> items: >>- const: xunlong,orangepi-zero-plus2-h3 >>- const: allwinner,sun8i-h3 >> + >> + - description: Elimo Engineering Impetus SoM >> +items: >> + - const: elimo,impetus >> + - const: allwinner,sun8i-s3 >> + >> + - description: Elimo Engineering Initium >> +items: >> + - const: elimo,initium >> + - const: allwinner,sun8i-s3 > >This should be ordered alphabetically, and most importantly, must match >the ones you have in the DT. > >Here, we have kind of a mess already: the Lichee Zero+ uses >,sipeed,lichee-zero-plus, sochip,s3, allwinner,sun8i-v3, while the >pinecube uses pine64,pinecube, allwinner,sun8i-s3 > >IIRC the S3 and V3 are pretty much the same SoCs, so the first one >seems >to make more sense to me, but then we should fix the pinecube. I agree with this. PineCube is originally designed for S3L (which is branded under Allwinner) but switch to S3 finally, so I may made error when adapting. > >Maxime
Re: [linux-sunxi] [PATCH 02/10] ARM: dts: sun6i: a31-hummingbird: Enable RGMII RX/TX delay on Ethernet PHY
于 2020年10月25日 GMT+08:00 上午2:30:35, "Jernej Škrabec"
写到:
>Dne sobota, 24. oktober 2020 ob 19:51:06 CEST je Icenowy Zheng
>napisal(a):
>> 在 2020-10-25星期日的 00:25 +0800，Chen-Yu Tsai写道：
>>
>> > From: Chen-Yu Tsai
>> >
>> > The Ethernet PHY on the A31 Hummingbird has the RX and TX delays
>> > enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins.
>> >
>> > Fix the phy-mode description to correct reflect this so that the
>> > implementation doesn't reconfigure the delays incorrectly. This
>> > happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e
>> > rx/tx delay config").
>>
>> Personally I think they should revert this commit, and consider other
>> solution.
>>
>> This commit breaks everything.
>>
>
>Previously broken driver allowed inproper DT to work, so you have to
>fix
>everything eventually.
There is no "improper DT" if it's already shipped, DT should suffer driver
change, not changed to match driver.
I think at least Fedora tends to ship a DT with a system image that will
not get updated when kernel gets updated.
>
>Plus side, there is no need to have hack for Pine64 Plus ethernet
>anymore.
>
>Best regards,
>Jernej
>
>> (Although the patch on individual DT patches are technically correct)
>>
>> > Fixes: c220aec2bb79 ("ARM: dts: sun6i: Add Merrii A31 Hummingbird
>> > support")
>> > Signed-off-by: Chen-Yu Tsai
>> > ---
>> >
>> > arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> > b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> > index 049e6ab3cf56..73de34ae37fd 100644
>> > --- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> > +++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
>> > @@ -154,7 +154,7 @@ &gmac {
>> >
>> >pinctrl-names = "default";
>> >pinctrl-0 = <&gmac_rgmii_pins>;
>> >phy-handle = <&phy1>;
>> >
>> > - phy-mode = "rgmii";
>> > + phy-mode = "rgmii-id";
>> >
>> >status = "okay";
>> >
>> > };
Re: [linux-sunxi] [PATCH 02/10] ARM: dts: sun6i: a31-hummingbird: Enable RGMII RX/TX delay on Ethernet PHY
在 2020-10-25星期日的 00:25 +0800，Chen-Yu Tsai写道：
> From: Chen-Yu Tsai
>
> The Ethernet PHY on the A31 Hummingbird has the RX and TX delays
> enabled on the PHY, using pull-ups on the RXDLY and TXDLY pins.
>
> Fix the phy-mode description to correct reflect this so that the
> implementation doesn't reconfigure the delays incorrectly. This
> happened with commit bbc4d71d6354 ("net: phy: realtek: fix rtl8211e
> rx/tx delay config").
Personally I think they should revert this commit, and consider other
solution.
This commit breaks everything.
(Although the patch on individual DT patches are technically correct)
>
> Fixes: c220aec2bb79 ("ARM: dts: sun6i: Add Merrii A31 Hummingbird
> support")
> Signed-off-by: Chen-Yu Tsai
> ---
> arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> index 049e6ab3cf56..73de34ae37fd 100644
> --- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> +++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
> @@ -154,7 +154,7 @@ &gmac {
> pinctrl-names = "default";
> pinctrl-0 = <&gmac_rgmii_pins>;
> phy-handle = <&phy1>;
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
> status = "okay";
> };
>
> --
> 2.28.0
>
[PATCH 1/2] ARM: dts: sun8i: s3: drop bogus cells for CSI subnode on PineCube
The address and size cells infomation in CSI subnode is not necessary
(because the camera subnode has no reg property).
Drop them.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-s3-pinecube.dts | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
index 9bab6b7f4014..76c8a29e355b 100644
--- a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
+++ b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
@@ -64,9 +64,6 @@ &csi1 {
status = "okay";
port {
- #address-cells = <1>;
- #size-cells = <0>;
-
csi1_ep: endpoint {
remote-endpoint = <&ov5640_ep>;
bus-width = <8>;
--
2.28.0
[PATCH 2/2] dt-bindings: sram: sunxi-sram: add V3s compatible string
Add compatible string for V3s, with H3 one as fallback. This is used in device tree now, but not standardized in DT binding. Signed-off-by: Icenowy Zheng --- .../bindings/sram/allwinner,sun4i-a10-system-control.yaml | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml index 6ebcbc153691..b66a07e21d1e 100644 --- a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml +++ b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml @@ -33,6 +33,9 @@ properties: - const: allwinner,sun4i-a10-system-control - const: allwinner,sun8i-a23-system-control - const: allwinner,sun8i-h3-system-control + - items: + - const: allwinner,sun8i-v3s-system-control + - const: allwinner,sun8i-h3-system-control - items: - const: allwinner,sun8i-r40-system-control - const: allwinner,sun4i-a10-system-control -- 2.28.0
[PATCH 0/2] Try to fix DT schema problems for V3-series DTs
This patchset tries to fix DT schema verification errors that exist in V3-series device trees. The first patch drops bogus properties that is not needed in PineCube DT, and the second one adds compatible to the binding. Icenowy Zheng (2): ARM: dts: sun8i: s3: drop bogus cells for CSI subnode on PineCube dt-bindings: sram: sunxi-sram: add V3s compatible string .../bindings/sram/allwinner,sun4i-a10-system-control.yaml | 3 +++ arch/arm/boot/dts/sun8i-s3-pinecube.dts| 3 --- 2 files changed, 3 insertions(+), 3 deletions(-) -- 2.28.0
Re: [linux-sunxi] Re: [PATCH 0/7] Pine64 PineCube support
hema:
>/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:
>['allwinner,sun8i-v3s-system-control',
>'allwinner,sun8i-h3-system-control'] is not valid under any of the
>given schemas (Possible causes of the failure):
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible: Additional items are not allowed
>('allwinner,sun8i-h3-system-control' was unexpected)
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun4i-a10-sram-controller' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun4i-a10-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun5i-a13-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun7i-a20-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun8i-a23-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun8i-h3-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun8i-r40-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun50i-a64-sram-controller' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun50i-a64-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,sun50i-h5-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c00000: compatible:0:
>'allwinner,sun50i-h6-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:0:
>'allwinner,suniv-f1c100s-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:1:
>'allwinner,sun4i-a10-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:1:
>'allwinner,sun4i-a10-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:1:
>'allwinner,sun50i-a64-system-control' was expected
>/arch/arm/boot/dts/sun8i-v3s-licheepi-zero-dock.dt.yaml:
>system-control@1c0: compatible:1:
>'allwinner,sun4i-a10-system-control' was expected
>
>Regards,
>Clement
>
>On Fri, 25 Sep 2020 at 17:12, Maxime Ripard wrote:
>>
>> Hi,
>>
>> On Wed, Sep 23, 2020 at 08:57:02AM +0800, Icenowy Zheng wrote:
>> > Pine64 PineCube is an IP camera based on Allwinner S3 chip.
>> >
>> > This patchset tries to add support for it.
>> >
>> > In order to make sure the system do not hang when camera is brought
>up,
>> > a fix to AXP209 driver is needed (sent individually), otherwise the
>> > system will hang because it changes the voltage of LDO2 when LDO4
>> > tweaking.
>>
>> Queued all the patches for 5.11
>>
>> > Icenowy Zheng (7):
>> > ARM: dts: sun8i: V3/V3s/S3/S3L: add Ethernet support
>> > ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for UART2 RX/TX
>> > ARM: dts: sun8i: V3/V3s/S3/S3L: add CSI1 device node
>> > ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for 8-bit parallel
>CSI
>> > ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for I2C1 at PE bank
>> > dt-bindings: arm: sunxi: add Pine64 PineCube binding
>> > ARM: dts: sun8i: s3l: add support for Pine64 PineCube IP camera
>>
>> However, I guess for the next patches to the v3s DTSI we should just
>> have a simpler prefix (like v3), it's really taking a lot of
>characters
>> here :)
>>
>> Maxime
>>
>> --
>> You received this message because you are subscribed to the Google
>Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it,
>send an email to linux-sunxi+unsubscr...@googlegroups.com.
>> To view this discussion on the web, visit
>https://groups.google.com/d/msgid/linux-sunxi/20200925151241.kfmytlff4grswtzh%40gilmour.lan.
[PATCH 5/7] ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for I2C1 at PE bank
I2C1 controller is available at PE bank, usually used for
connecting an I2C-controlled camera sensor.
Add pinctrl node for it.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 19fba1a9115b..bae8fa9e356a 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -331,6 +331,12 @@ i2c0_pins: i2c0-pins {
function = "i2c0";
};
+ /omit-if-no-ref/
+ i2c1_pe_pins: i2c1-pe-pins {
+ pins = "PE21", "PE22";
+ function = "i2c1";
+ };
+
uart0_pb_pins: uart0-pb-pins {
pins = "PB8", "PB9";
function = "uart0";
--
2.27.0
[PATCH 6/7] dt-bindings: arm: sunxi: add Pine64 PineCube binding
Document board compatible names for Pine64 PineCube IP camera. Signed-off-by: Icenowy Zheng --- Documentation/devicetree/bindings/arm/sunxi.yaml | 5 + 1 file changed, 5 insertions(+) diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index 5957a22c2e95..584b3fbf6e08 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -631,6 +631,11 @@ properties: - const: pine64,pine64-plus - const: allwinner,sun50i-a64 + - description: Pine64 PineCube +items: + - const: pine64,pinecube + - const: allwinner,sun8i-v3 + - description: Pine64 PineH64 model A items: - const: pine64,pine-h64 -- 2.27.0
[PATCH 7/7] ARM: dts: sun8i: s3l: add support for Pine64 PineCube IP camera
The Pine64 PineCube IP camera is an IP camera with SoChip S3 SoC.
It comes with a main board, an expansion board and a camera.
The main board features a Micro-USB power-only jack, a USB Type-A port,
an Ethernet port connected to the internal PHY of the SoC and a Realtek
RTL8189ES SDIO Wi-Fi module. A RGB LCD connector is reserved on the
board.
The expansion board features a TF slot, a microphone, a speaker
connector with on-board amplifier and a few IR LEDs.
Add support for the kit, with features on the main board and the
expansion board now.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun8i-s3-pinecube.dts | 235
2 files changed, 236 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-s3-pinecube.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index e7c59d0c8598..b163c8f1cefc 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -1198,6 +1198,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
sun8i-r16-parrot.dtb \
sun8i-r40-bananapi-m2-ultra.dtb \
sun8i-s3-lichee-zero-plus.dtb \
+ sun8i-s3-pinecube.dtb \
sun8i-t3-cqa3t-bv3.dtb \
sun8i-v3s-licheepi-zero.dtb \
sun8i-v3s-licheepi-zero-dock.dtb \
diff --git a/arch/arm/boot/dts/sun8i-s3-pinecube.dts
b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
new file mode 100644
index ..9bab6b7f4014
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-s3-pinecube.dts
@@ -0,0 +1,235 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR X11)
+/*
+ * Copyright 2019 Icenowy Zheng
+ */
+
+/dts-v1/;
+#include "sun8i-v3.dtsi"
+#include
+#include
+
+/ {
+ model = "PineCube IP Camera";
+ compatible = "pine64,pinecube", "allwinner,sun8i-s3";
+
+ aliases {
+ serial0 = &uart2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led1 {
+ label = "pine64:ir:led1";
+ gpios = <&pio 1 10 GPIO_ACTIVE_LOW>; /* PB10 */
+ };
+
+ led2 {
+ label = "pine64:ir:led2";
+ gpios = <&pio 1 12 GPIO_ACTIVE_LOW>; /* PB12 */
+ };
+ };
+
+ reg_vcc5v0: vcc5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0";
+ regulator-min-microvolt = <500>;
+ regulator-max-microvolt = <500>;
+ };
+
+ reg_vcc_wifi: vcc-wifi {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc-wifi";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ gpio = <&pio 1 2 GPIO_ACTIVE_LOW>; /* PB2 WIFI-EN */
+ vin-supply = <®_dcdc3>;
+ startup-delay-us = <20>;
+ };
+
+ wifi_pwrseq: wifi_pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&pio 1 3 GPIO_ACTIVE_LOW>; /* PB3 WIFI-RST */
+ post-power-on-delay-ms = <200>;
+ };
+};
+
+&csi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&csi1_8bit_pins>;
+ status = "okay";
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi1_ep: endpoint {
+ remote-endpoint = <&ov5640_ep>;
+ bus-width = <8>;
+ hsync-active = <1>; /* Active high */
+ vsync-active = <0>; /* Active low */
+ data-active = <1>; /* Active high */
+ pclk-sample = <1>; /* Rising */
+ };
+ };
+};
+
+&emac {
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ axp209: pmic@34 {
+ compatible = "x-powers,axp203",
+"x-powers,axp209";
+ reg = <0x34>;
+ interrupt-parent = <&gic>;
+ interrupts = ;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pe_pins>;
+ status = "okay";
+
+ ov5640: camera@3c {
+ compatible = "ovti,ov5640";
+ reg = <0x3c>;
+ pinctrl-names = "default";
+
[PATCH 4/7] ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for 8-bit parallel CSI
The CSI1 controller of V3/V3s/S3/S3L SoCs is used for parallel CSI.
As we're going to add support for Pine64 SCC board, which uses 8-bit
parallel CSI (and the MCLK output), add the pinctrl node of 8-bit
CSI and MCLK to the DTSI file.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 3e079973672d..19fba1a9115b 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -312,6 +312,20 @@ pio: pinctrl@1c20800 {
interrupt-controller;
#interrupt-cells = <3>;
+ /omit-if-no-ref/
+ csi1_8bit_pins: csi1-8bit-pins {
+ pins = "PE0", "PE2", "PE3", "PE8", "PE9",
+ "PE10", "PE11", "PE12", "PE13", "PE14",
+ "PE15";
+ function = "csi";
+ };
+
+ /omit-if-no-ref/
+ csi1_mclk_pin: csi1-mclk-pin {
+ pins = "PE1";
+ function = "csi";
+ };
+
i2c0_pins: i2c0-pins {
pins = "PB6", "PB7";
function = "i2c0";
--
2.27.0
[PATCH 4/7] ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for 8-bit parallel CSI
The CSI1 controller of V3/V3s/S3/S3L SoCs is used for parallel CSI.
As we're going to add support for Pine64 SCC board, which uses 8-bit
parallel CSI (and the MCLK output), add the pinctrl node of 8-bit
CSI and MCLK to the DTSI file.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 3e079973672d..19fba1a9115b 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -312,6 +312,20 @@ pio: pinctrl@1c20800 {
interrupt-controller;
#interrupt-cells = <3>;
+ /omit-if-no-ref/
+ csi1_8bit_pins: csi1-8bit-pins {
+ pins = "PE0", "PE2", "PE3", "PE8", "PE9",
+ "PE10", "PE11", "PE12", "PE13", "PE14",
+ "PE15";
+ function = "csi";
+ };
+
+ /omit-if-no-ref/
+ csi1_mclk_pin: csi1-mclk-pin {
+ pins = "PE1";
+ function = "csi";
+ };
+
i2c0_pins: i2c0-pins {
pins = "PB6", "PB7";
function = "i2c0";
--
2.27.0
[PATCH 2/7] ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for UART2 RX/TX
The UART2 RX/TX pins on Allwinner V3 series is at PB0/1, which is used
as debugging UART on some boards.
Add pinctrl node for them.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 7d40897dab09..4cfdf193cf88 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -322,6 +322,11 @@ uart0_pb_pins: uart0-pb-pins {
function = "uart0";
};
+ uart2_pins: uart2-pins {
+ pins = "PB0", "PB1";
+ function = "uart2";
+ };
+
mmc0_pins: mmc0-pins {
pins = "PF0", "PF1", "PF2", "PF3",
"PF4", "PF5";
@@ -397,6 +402,8 @@ uart2: serial@1c28800 {
reg-io-width = <4>;
clocks = <&ccu CLK_BUS_UART2>;
resets = <&ccu RST_BUS_UART2>;
+ pinctrl-0 = <&uart2_pins>;
+ pinctrl-names = "default";
status = "disabled";
};
--
2.27.0
[PATCH 3/7] ARM: dts: sun8i: V3/V3s/S3/S3L: add CSI1 device node
The CSI1 controller of V3/V3s/S3/S3L chips is used for parallel CSI.
Add the device tree node of it.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3s.dtsi | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 4cfdf193cf88..3e079973672d 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -488,6 +488,18 @@ spi0: spi@1c68000 {
#size-cells = <0>;
};
+ csi1: camera@1cb4000 {
+ compatible = "allwinner,sun8i-v3s-csi";
+ reg = <0x01cb4000 0x3000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_CSI>,
+<&ccu CLK_CSI1_SCLK>,
+<&ccu CLK_DRAM_CSI>;
+ clock-names = "bus", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@1c81000 {
compatible = "arm,gic-400";
reg = <0x01c81000 0x1000>,
--
2.27.0
[PATCH] regulator: axp20x: fix LDO2/4 description
Currently we wrongly set the mask of value of LDO2/4 both to the mask of
LDO2, and the LDO4 voltage configuration is left untouched. This leads
to conflict when LDO2/4 are both in use.
Fix this issue by setting different vsel_mask to both regulators.
Fixes: db4a555f7c4c ("regulator: axp20x: use defines for masks")
Signed-off-by: Icenowy Zheng
---
drivers/regulator/axp20x-regulator.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/regulator/axp20x-regulator.c
b/drivers/regulator/axp20x-regulator.c
index 1bacb37e8a99..cd1224182ad7 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -42,8 +42,9 @@
#define AXP20X_DCDC2_V_OUT_MASKGENMASK(5, 0)
#define AXP20X_DCDC3_V_OUT_MASKGENMASK(7, 0)
-#define AXP20X_LDO24_V_OUT_MASKGENMASK(7, 4)
+#define AXP20X_LDO2_V_OUT_MASK GENMASK(7, 4)
#define AXP20X_LDO3_V_OUT_MASK GENMASK(6, 0)
+#define AXP20X_LDO4_V_OUT_MASK GENMASK(3, 0)
#define AXP20X_LDO5_V_OUT_MASK GENMASK(7, 4)
#define AXP20X_PWR_OUT_EXTEN_MASK BIT_MASK(0)
@@ -542,14 +543,14 @@ static const struct regulator_desc axp20x_regulators[] = {
AXP20X_PWR_OUT_CTRL, AXP20X_PWR_OUT_DCDC3_MASK),
AXP_DESC_FIXED(AXP20X, LDO1, "ldo1", "acin", 1300),
AXP_DESC(AXP20X, LDO2, "ldo2", "ldo24in", 1800, 3300, 100,
-AXP20X_LDO24_V_OUT, AXP20X_LDO24_V_OUT_MASK,
+AXP20X_LDO24_V_OUT, AXP20X_LDO2_V_OUT_MASK,
AXP20X_PWR_OUT_CTRL, AXP20X_PWR_OUT_LDO2_MASK),
AXP_DESC(AXP20X, LDO3, "ldo3", "ldo3in", 700, 3500, 25,
AXP20X_LDO3_V_OUT, AXP20X_LDO3_V_OUT_MASK,
AXP20X_PWR_OUT_CTRL, AXP20X_PWR_OUT_LDO3_MASK),
AXP_DESC_RANGES(AXP20X, LDO4, "ldo4", "ldo24in",
axp20x_ldo4_ranges, AXP20X_LDO4_V_OUT_NUM_VOLTAGES,
- AXP20X_LDO24_V_OUT, AXP20X_LDO24_V_OUT_MASK,
+ AXP20X_LDO24_V_OUT, AXP20X_LDO4_V_OUT_MASK,
AXP20X_PWR_OUT_CTRL, AXP20X_PWR_OUT_LDO4_MASK),
AXP_DESC_IO(AXP20X, LDO5, "ldo5", "ldo5in", 1800, 3300, 100,
AXP20X_LDO5_V_OUT, AXP20X_LDO5_V_OUT_MASK,
--
2.27.0
[PATCH 1/7] ARM: dts: sun8i: V3/V3s/S3/S3L: add Ethernet support
The Allwinner V3/V3s/S3L/SoChip S3 Ethernet MAC and internal PHY is quite
similar to the ones on Allwinner H3, except for V3s the external MII is
not wired out.
Add ethernet support to V3/V3s/S3/S3L.
Signed-off-by: Icenowy Zheng
---
arch/arm/boot/dts/sun8i-v3.dtsi | 13
arch/arm/boot/dts/sun8i-v3s.dtsi | 52
2 files changed, 65 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-v3.dtsi b/arch/arm/boot/dts/sun8i-v3.dtsi
index 6ae8645ade50..ca4672ed2e02 100644
--- a/arch/arm/boot/dts/sun8i-v3.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3.dtsi
@@ -9,6 +9,19 @@ &ccu {
compatible = "allwinner,sun8i-v3-ccu";
};
+&emac {
+ /delete-property/ phy-handle;
+ /delete-property/ phy-mode;
+};
+
+&mdio_mux {
+ external_mdio: mdio@2 {
+ reg = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+};
+
&pio {
compatible = "allwinner,sun8i-v3-pinctrl";
};
diff --git a/arch/arm/boot/dts/sun8i-v3s.dtsi b/arch/arm/boot/dts/sun8i-v3s.dtsi
index 6eb9c39aa93f..7d40897dab09 100644
--- a/arch/arm/boot/dts/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/sun8i-v3s.dtsi
@@ -138,6 +138,15 @@ mixer0_out_tcon0: endpoint {
};
};
+ syscon: system-control@1c0 {
+ compatible = "allwinner,sun8i-v3s-system-control",
+"allwinner,sun8i-h3-system-control";
+ reg = <0x01c0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+ };
+
tcon0: lcd-controller@1c0c000 {
compatible = "allwinner,sun8i-v3s-tcon";
reg = <0x01c0c000 0x1000>;
@@ -415,6 +424,49 @@ i2c1: i2c@1c2b000 {
#size-cells = <0>;
};
+ emac: ethernet@1c3 {
+ compatible = "allwinner,sun8i-v3s-emac";
+ syscon = <&syscon>;
+ reg = <0x01c3 0x1>;
+ interrupts = ;
+ interrupt-names = "macirq";
+ resets = <&ccu RST_BUS_EMAC>;
+ reset-names = "stmmaceth";
+ clocks = <&ccu CLK_BUS_EMAC>;
+ clock-names = "stmmaceth";
+ phy-handle = <&int_mii_phy>;
+ phy-mode = "mii";
+ status = "disabled";
+
+ mdio: mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "snps,dwmac-mdio";
+ };
+
+ mdio_mux: mdio-mux {
+ compatible = "allwinner,sun8i-h3-mdio-mux";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio-parent-bus = <&mdio>;
+ /* Only one MDIO is usable at the time */
+ internal_mdio: mdio@1 {
+ compatible =
"allwinner,sun8i-h3-mdio-internal";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ int_mii_phy: ethernet-phy@1 {
+ compatible =
"ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ clocks = <&ccu CLK_BUS_EPHY>;
+ resets = <&ccu RST_BUS_EPHY>;
+ };
+ };
+ };
+ };
+
spi0: spi@1c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
--
2.27.0
[PATCH 0/7] Pine64 PineCube support
Pine64 PineCube is an IP camera based on Allwinner S3 chip. This patchset tries to add support for it. In order to make sure the system do not hang when camera is brought up, a fix to AXP209 driver is needed (sent individually), otherwise the system will hang because it changes the voltage of LDO2 when LDO4 tweaking. Icenowy Zheng (7): ARM: dts: sun8i: V3/V3s/S3/S3L: add Ethernet support ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for UART2 RX/TX ARM: dts: sun8i: V3/V3s/S3/S3L: add CSI1 device node ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for 8-bit parallel CSI ARM: dts: sun8i: V3/V3s/S3/S3L: add pinctrl for I2C1 at PE bank dt-bindings: arm: sunxi: add Pine64 PineCube binding ARM: dts: sun8i: s3l: add support for Pine64 PineCube IP camera .../devicetree/bindings/arm/sunxi.yaml| 5 + arch/arm/boot/dts/Makefile| 1 + arch/arm/boot/dts/sun8i-s3-pinecube.dts | 235 ++ arch/arm/boot/dts/sun8i-v3.dtsi | 13 + arch/arm/boot/dts/sun8i-v3s.dtsi | 91 +++ 5 files changed, 345 insertions(+) create mode 100644 arch/arm/boot/dts/sun8i-s3-pinecube.dts -- 2.27.0
Re: [PATCH 1/1] mfd: mfd-core: Ensure disabled devices are ignored without error
在 2020-08-19星期三的 11:54 +0100，Lee Jones写道：
> Commit e49aa9a9bd22 ("mfd: core: Make a best effort attempt to match
> devices with the correct of_nodes") changed the semantics for
> disabled
> devices in mfd_add_device(). Instead of silently ignoring a disabled
> child device, an error was returned. On receipt of the error
> mfd_add_devices() the precedes to remove *all* child devices and
> returns an all-failed error to the caller, which will inevitably fail
> the parent device as well.
>
> This patch reverts back to the old semantics and ignores child
> devices
> which are disabled in Device Tree.
>
> Fixes: e49aa9a9bd22 ("mfd: core: Make a best effort attempt to match
> devices with the correct of_nodes")
> Reported-by: Icenowy Zheng
> Signed-off-by: Lee Jones
Tested-by: Icenowy Zheng
> ---
> drivers/mfd/mfd-core.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index c3651f06684fa..30f90a15ceaab 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -126,10 +126,6 @@ static int mfd_match_of_node_to_dev(struct
> platform_device *pdev,
> const __be32 *reg;
> u64 of_node_addr;
>
> - /* Skip devices 'disabled' by Device Tree */
> - if (!of_device_is_available(np))
> - return -ENODEV;
> -
> /* Skip if OF node has previously been allocated to a device */
> list_for_each_entry(of_entry, &mfd_of_node_list, list)
> if (of_entry->np == np)
> @@ -212,6 +208,12 @@ static int mfd_add_device(struct device *parent,
> int id,
> if (IS_ENABLED(CONFIG_OF) && parent->of_node && cell-
> >of_compatible) {
> for_each_child_of_node(parent->of_node, np) {
> if (of_device_is_compatible(np, cell-
> >of_compatible)) {
> + /* Ignore 'disabled' devices error free
> */
> + if (!of_device_is_available(np)) {
> + ret = 0;
> + goto fail_alias;
> + }
> +
> ret = mfd_match_of_node_to_dev(pdev,
> np, cell);
> if (ret == -EAGAIN)
> continue;
Re: [PATCH] mfd: core: Fix handle of OF disabled MFD cells
在 2020-08-19星期三的 09:11 +0100，Lee Jones写道：
> On Sat, 01 Aug 2020, Icenowy Zheng wrote:
>
> > When rewriting the OF match code of MFD core, addition of cells
> > disabled
> > in OF will result in a failure with error -ENODEV. This is an
> > unexpected
> > behavior, as the previous behavior is silently ignore the cell. On
> > SBCs with AXP20x PMICs, this leads to boot failure if AXP20x PMIC
> > support is built-in and some cells (especially power supply ones)
> > are
> > disabled.
>
> Thanks for reporting this.
>
> Do you mind if I fix this another way? I plan to reinstate the old
> code that was removed as part of the offending patch. I will of
> course add your Reported-by tag.
I think it's okay.
I will test it once it's out.
>
> > Silently ignore the cell when -ENODEV occurs.
> >
> > Fixes: e49aa9a9bd22 ("mfd: core: Make a best effort attempt to
> > match devices with the correct of_nodes")
> > Signed-off-by: Icenowy Zheng
> > ---
> > drivers/mfd/mfd-core.c | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> > index c3ef58a802bee..31b363c64f4b4 100644
> > --- a/drivers/mfd/mfd-core.c
> > +++ b/drivers/mfd/mfd-core.c
> > @@ -215,8 +215,13 @@ static int mfd_add_device(struct device
> > *parent, int id,
> > ret = mfd_match_of_node_to_dev(pdev,
> > np, cell);
> > if (ret == -EAGAIN)
> > continue;
> > - if (ret)
> > + if (ret) {
> > + if (ret == -ENODEV) {
> > + /* Ignore disabled
> > devices error free */
> > + ret = 0;
> > + }
> > goto fail_alias;
> > + }
> >
> > break;
> > }
[PATCH] mfd: core: Fix handle of OF disabled MFD cells
When rewriting the OF match code of MFD core, addition of cells disabled
in OF will result in a failure with error -ENODEV. This is an unexpected
behavior, as the previous behavior is silently ignore the cell. On
SBCs with AXP20x PMICs, this leads to boot failure if AXP20x PMIC
support is built-in and some cells (especially power supply ones) are
disabled.
Silently ignore the cell when -ENODEV occurs.
Fixes: e49aa9a9bd22 ("mfd: core: Make a best effort attempt to match devices
with the correct of_nodes")
Signed-off-by: Icenowy Zheng
---
drivers/mfd/mfd-core.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
index c3ef58a802bee..31b363c64f4b4 100644
--- a/drivers/mfd/mfd-core.c
+++ b/drivers/mfd/mfd-core.c
@@ -215,8 +215,13 @@ static int mfd_add_device(struct device *parent, int id,
ret = mfd_match_of_node_to_dev(pdev, np, cell);
if (ret == -EAGAIN)
continue;
- if (ret)
+ if (ret) {
+ if (ret == -ENODEV) {
+ /* Ignore disabled devices
error free */
+ ret = 0;
+ }
goto fail_alias;
+ }
break;
}
--
2.27.0
Re: [PATCH] thermal: sun8i: Be loud when probe fails
在 2020-07-08星期三的 12:03 +0100，Russell King - ARM Linux admin写道：
> On Wed, Jul 08, 2020 at 12:55:27PM +0200, Ondrej Jirman wrote:
> > I noticed several mobile Linux distributions failing to enable the
> > thermal regulation correctly, because the kernel is silent
> > when thermal driver fails to probe. Add enough error reporting
> > to debug issues and warn users in case thermal sensor is failing
> > to probe.
> >
> > Failing to notify users means, that SoC can easily overheat under
> > load.
> >
> > Signed-off-by: Ondrej Jirman
> > ---
> > drivers/thermal/sun8i_thermal.c | 55 ++---
> >
> > 1 file changed, 43 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/thermal/sun8i_thermal.c
> > b/drivers/thermal/sun8i_thermal.c
> > index 74d73be16496..9065e79ae743 100644
> > --- a/drivers/thermal/sun8i_thermal.c
> > +++ b/drivers/thermal/sun8i_thermal.c
> > @@ -287,8 +287,12 @@ static int sun8i_ths_calibrate(struct
> > ths_device *tmdev)
> >
> > calcell = devm_nvmem_cell_get(dev, "calibration");
> > if (IS_ERR(calcell)) {
> > + dev_err(dev, "Failed to get calibration nvmem cell
> > (%ld)\n",
> > + PTR_ERR(calcell));
>
> Consider using:
>
> dev_err(dev, "Failed to get calibration nvmem cell
> (%pe)\n",
> calcell);
>
> which means the kernel can print the symbolic errno value.
Oh interesting format here.
When we need to deal with a int return value, is it "%e"?
Thanks
>
[PATCH 1/4] drm/panel: ilitek-ili9881c: prepare for adding support for extra panels
There're more panels with ILI9881C controller than the Bananapi one
supported by this driver.
Extract the mode and init sequence part, to prepare the driver for
adding new panels.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 56 ---
1 file changed, 37 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 3ed8635a6fbdf..4f8e6865029f1 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include
@@ -20,14 +21,6 @@
#include
-struct ili9881c {
- struct drm_panelpanel;
- struct mipi_dsi_device *dsi;
-
- struct regulator*power;
- struct gpio_desc*reset;
-};
-
enum ili9881c_op {
ILI9881C_SWITCH_PAGE,
ILI9881C_COMMAND,
@@ -45,6 +38,21 @@ struct ili9881c_instr {
} arg;
};
+struct ili9881c_desc {
+ const struct ili9881c_instr *init;
+ const size_t init_length;
+ const struct drm_display_mode *mode;
+};
+
+struct ili9881c {
+ struct drm_panelpanel;
+ struct mipi_dsi_device *dsi;
+ const struct ili9881c_desc *desc;
+
+ struct regulator*power;
+ struct gpio_desc*reset;
+};
+
#define ILI9881C_SWITCH_PAGE_INSTR(_page) \
{ \
.op = ILI9881C_SWITCH_PAGE, \
@@ -64,7 +72,7 @@ struct ili9881c_instr {
}, \
}
-static const struct ili9881c_instr ili9881c_init[] = {
+static const struct ili9881c_instr lhr050h41_init[] = {
ILI9881C_SWITCH_PAGE_INSTR(3),
ILI9881C_COMMAND_INSTR(0x01, 0x00),
ILI9881C_COMMAND_INSTR(0x02, 0x00),
@@ -311,8 +319,8 @@ static int ili9881c_prepare(struct drm_panel *panel)
gpiod_set_value(ctx->reset, 0);
msleep(20);
- for (i = 0; i < ARRAY_SIZE(ili9881c_init); i++) {
- const struct ili9881c_instr *instr = &ili9881c_init[i];
+ for (i = 0; i < ctx->desc->init_length; i++) {
+ const struct ili9881c_instr *instr = &ctx->desc->init[i];
if (instr->op == ILI9881C_SWITCH_PAGE)
ret = ili9881c_switch_page(ctx, instr->arg.page);
@@ -368,7 +376,7 @@ static int ili9881c_unprepare(struct drm_panel *panel)
return 0;
}
-static const struct drm_display_mode bananapi_default_mode = {
+static const struct drm_display_mode lhr050h41_default_mode = {
.clock = 62000,
.hdisplay = 720,
@@ -380,6 +388,9 @@ static const struct drm_display_mode bananapi_default_mode
= {
.vsync_start= 1280 + 10,
.vsync_end = 1280 + 10 + 10,
.vtotal = 1280 + 10 + 10 + 20,
+
+ .width_mm = 62,
+ .height_mm = 110,
};
static int ili9881c_get_modes(struct drm_panel *panel,
@@ -388,12 +399,12 @@ static int ili9881c_get_modes(struct drm_panel *panel,
struct ili9881c *ctx = panel_to_ili9881c(panel);
struct drm_display_mode *mode;
- mode = drm_mode_duplicate(connector->dev, &bananapi_default_mode);
+ mode = drm_mode_duplicate(connector->dev, ctx->desc->mode);
if (!mode) {
dev_err(&ctx->dsi->dev, "failed to add mode %ux%ux@%u\n",
- bananapi_default_mode.hdisplay,
- bananapi_default_mode.vdisplay,
- drm_mode_vrefresh(&bananapi_default_mode));
+ ctx->desc->mode->hdisplay,
+ ctx->desc->mode->vdisplay,
+ drm_mode_vrefresh(ctx->desc->mode));
return -ENOMEM;
}
@@ -402,8 +413,8 @@ static int ili9881c_get_modes(struct drm_panel *panel,
mode->type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED;
drm_mode_probed_add(connector, mode);
- connector->display_info.width_mm = 62;
- connector->display_info.height_mm = 110;
+ connector->display_info.width_mm = mode->width_mm;
+ connector->display_info.height_mm = mode->height_mm;
return 1;
}
@@ -426,6 +437,7 @@ static int ili9881c_dsi_probe(struct mipi_dsi_device *dsi)
return -ENOMEM;
mipi_dsi_set_drvdata(dsi, ctx);
ctx->dsi = dsi;
+ ctx->desc = of_device_get_match_data(&dsi->dev);
drm_panel_init(&ctx->panel, &dsi->dev, &ili9881c_funcs,
DRM_MODE_CONNECTOR_DSI);
@@ -467,8 +479,14 @@ static int ili9881c_dsi_remove(struct mipi_dsi_device *dsi)
return 0;
}
+static const struct ili9881c_desc lhr050h41_desc = {
+ .init = lhr050h41
[PATCH 4/4] [DO NOT MERGE] arm64: allwinner: dts: a64: enable K101-IM2BYL02 panel for PineTab
Newer PineTab may switch to K101-IM2BYL02.
Signed-off-by: Icenowy Zheng
---
arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
index dc4ab6b434f97..15c4f5b5b17a7 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinetab.dts
@@ -152,6 +152,7 @@ &dsi {
vcc-dsi-supply = <®_dldo1>;
status = "okay";
+#if 0
panel@0 {
compatible = "feixin,k101-im2ba02";
reg = <0>;
@@ -161,6 +162,15 @@ panel@0 {
reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* PD24 */
backlight = <&backlight>;
};
+#endif
+
+ panel@0 {
+ compatible = "feixin,k101-im2byl02";
+ reg = <0>;
+ power-supply = <®_dc1sw>;
+ reset-gpios = <&pio 3 24 GPIO_ACTIVE_LOW>; /* PD24 */
+ backlight = <&backlight>;
+ };
};
&ehci0 {
--
2.27.0
[PATCH 2/4] dt-bindings: ili9881c: add compatible string for Feixin K101-IM2BYL02
Feixin K101-IM2BYL02 is a drop-in replacement of K101-IM2BA02 panel (which is already supported by panel-feixin-k101-im2ba02 driver) with the same pinout. It utilizes an Ilitek ILI9881C controller chip, so its compatible string should be added to ilitek,ili9881c file. Add the compatible string for it. Signed-off-by: Icenowy Zheng --- .../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml index a39332276bab2..c60b3bd74337e 100644 --- a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml +++ b/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.yaml @@ -14,6 +14,7 @@ properties: items: - enum: - bananapi,lhr050h41 +- feixin,k101-im2byl02 - const: ilitek,ili9881c -- 2.27.0
[PATCH 3/4] drm/panel: ilitek-ili9881c: add support for Feixin K101-IM2BYL02 panel
Feixin K101-IM2BYL02 is a new panel by Feixin designed as a replacement
to their K101-IM2BA02 panel. This panel utilizes the Ilitek ILI9881C
controller.
Add this panel's initialzation sequence and timing to ILI9881C driver.
Signed-off-by: Icenowy Zheng
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 217 ++
1 file changed, 217 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
index 4f8e6865029f1..638108c519f02 100644
--- a/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
+++ b/drivers/gpu/drm/panel/panel-ilitek-ili9881c.c
@@ -260,6 +260,199 @@ static const struct ili9881c_instr lhr050h41_init[] = {
ILI9881C_COMMAND_INSTR(0xD3, 0x3F),
};
+static const struct ili9881c_instr k101_im2byl02_init[] = {
+ ILI9881C_SWITCH_PAGE_INSTR(3),
+ ILI9881C_COMMAND_INSTR(0x01, 0x00),
+ ILI9881C_COMMAND_INSTR(0x02, 0x00),
+ ILI9881C_COMMAND_INSTR(0x03, 0x73),
+ ILI9881C_COMMAND_INSTR(0x04, 0x00),
+ ILI9881C_COMMAND_INSTR(0x05, 0x00),
+ ILI9881C_COMMAND_INSTR(0x06, 0x08),
+ ILI9881C_COMMAND_INSTR(0x07, 0x00),
+ ILI9881C_COMMAND_INSTR(0x08, 0x00),
+ ILI9881C_COMMAND_INSTR(0x09, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0A, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0B, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0C, 0x00),
+ ILI9881C_COMMAND_INSTR(0x0D, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0E, 0x01),
+ ILI9881C_COMMAND_INSTR(0x0F, 0x00),
+ ILI9881C_COMMAND_INSTR(0x10, 0x00),
+ ILI9881C_COMMAND_INSTR(0x11, 0x00),
+ ILI9881C_COMMAND_INSTR(0x12, 0x00),
+ ILI9881C_COMMAND_INSTR(0x13, 0x00),
+ ILI9881C_COMMAND_INSTR(0x14, 0x00),
+ ILI9881C_COMMAND_INSTR(0x15, 0x00),
+ ILI9881C_COMMAND_INSTR(0x16, 0x00),
+ ILI9881C_COMMAND_INSTR(0x17, 0x00),
+ ILI9881C_COMMAND_INSTR(0x18, 0x00),
+ ILI9881C_COMMAND_INSTR(0x19, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1A, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1B, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1C, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1D, 0x00),
+ ILI9881C_COMMAND_INSTR(0x1E, 0x40),
+ ILI9881C_COMMAND_INSTR(0x1F, 0xC0),
+ ILI9881C_COMMAND_INSTR(0x20, 0x06),
+ ILI9881C_COMMAND_INSTR(0x21, 0x01),
+ ILI9881C_COMMAND_INSTR(0x22, 0x06),
+ ILI9881C_COMMAND_INSTR(0x23, 0x01),
+ ILI9881C_COMMAND_INSTR(0x24, 0x88),
+ ILI9881C_COMMAND_INSTR(0x25, 0x88),
+ ILI9881C_COMMAND_INSTR(0x26, 0x00),
+ ILI9881C_COMMAND_INSTR(0x27, 0x00),
+ ILI9881C_COMMAND_INSTR(0x28, 0x3B),
+ ILI9881C_COMMAND_INSTR(0x29, 0x03),
+ ILI9881C_COMMAND_INSTR(0x2A, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2B, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2C, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2D, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2E, 0x00),
+ ILI9881C_COMMAND_INSTR(0x2F, 0x00),
+ ILI9881C_COMMAND_INSTR(0x30, 0x00),
+ ILI9881C_COMMAND_INSTR(0x31, 0x00),
+ ILI9881C_COMMAND_INSTR(0x32, 0x00),
+ ILI9881C_COMMAND_INSTR(0x33, 0x00),
+ ILI9881C_COMMAND_INSTR(0x34, 0x00), /* GPWR1/2 non overlap time 2.62us
*/
+ ILI9881C_COMMAND_INSTR(0x35, 0x00),
+ ILI9881C_COMMAND_INSTR(0x36, 0x00),
+ ILI9881C_COMMAND_INSTR(0x37, 0x00),
+ ILI9881C_COMMAND_INSTR(0x38, 0x00),
+ ILI9881C_COMMAND_INSTR(0x39, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3A, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3B, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3C, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3D, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3E, 0x00),
+ ILI9881C_COMMAND_INSTR(0x3F, 0x00),
+ ILI9881C_COMMAND_INSTR(0x40, 0x00),
+ ILI9881C_COMMAND_INSTR(0x41, 0x00),
+ ILI9881C_COMMAND_INSTR(0x42, 0x00),
+ ILI9881C_COMMAND_INSTR(0x43, 0x00),
+ ILI9881C_COMMAND_INSTR(0x44, 0x00),
+ ILI9881C_COMMAND_INSTR(0x50, 0x01),
+ ILI9881C_COMMAND_INSTR(0x51, 0x23),
+ ILI9881C_COMMAND_INSTR(0x52, 0x45),
+ ILI9881C_COMMAND_INSTR(0x53, 0x67),
+ ILI9881C_COMMAND_INSTR(0x54, 0x89),
+ ILI9881C_COMMAND_INSTR(0x55, 0xAB),
+ ILI9881C_COMMAND_INSTR(0x56, 0x01),
+ ILI9881C_COMMAND_INSTR(0x57, 0x23),
+ ILI9881C_COMMAND_INSTR(0x58, 0x45),
+ ILI9881C_COMMAND_INSTR(0x59, 0x67),
+ ILI9881C_COMMAND_INSTR(0x5A, 0x89),
+ ILI9881C_COMMAND_INSTR(0x5B, 0xAB),
+ ILI9881C_COMMAND_INSTR(0x5C, 0xCD),
+ ILI9881C_COMMAND_INSTR(0x5D, 0xEF),
+ ILI9881C_COMMAND_INSTR(0x5E, 0x00),
+ ILI9881C_COMMAND_INSTR(0x5F, 0x01),
+ ILI9881C_COMMAND_INSTR(0x60, 0x01),
+ ILI9881C_COMMAND_INSTR(0x61, 0x06),
+ ILI9881C_COMMAND_INSTR(0x62, 0x06),
+ ILI9881C_COMMAND_INSTR(0x63, 0x07),
+ ILI9881C_COMMAND_INSTR(0x64, 0x07),
+ ILI9881C_COMMAND_INSTR(0x65, 0x00),
+ ILI9881C_COMMAND_INSTR(0x66, 0x00),
+ ILI9881C_COMMAND_INSTR(0x67, 0x02),
+ ILI9881C_COMMAND_INSTR(0x68,
[PATCH 0/4] Add support for Feixin K101-IM2BYL02 panel
The controller chip of Feixin K101-IM2BA02 is going to be discontinued, so Feixin start to provide K101-IM2BYL02 panel as a replacement, which utilizes Ilitek ILI9881C controller. Add support for K101-IM2BYL02 panel. By the way, is there a way that can try both kind of panels in the same kernel/DTB combo? K101-IM2BYL02 has the same pinout with K101-IM2BA02, and PineTab schedule to switch to it w/o modifying the mainboard. Icenowy Zheng (4): drm/panel: ilitek-ili9881c: prepare for adding support for extra panels dt-bindings: ili9881c: add compatible string for Feixin K101-IM2BYL02 drm/panel: ilitek-ili9881c: add support for Feixin K101-IM2BYL02 panel [DO NOT MERGE] arm64: allwinner: dts: a64: enable K101-IM2BYL02 panel for PineTab .../display/panel/ilitek,ili9881c.yaml| 1 + .../boot/dts/allwinner/sun50i-a64-pinetab.dts | 10 + drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 273 -- 3 files changed, 265 insertions(+), 19 deletions(-) -- 2.27.0
Re: [PATCH] iio: light: stk3310: add chip id for STK3311-X variant
在 2020-07-04星期六的 17:29 +0100，Jonathan Cameron写道：
> On Fri, 3 Jul 2020 21:44:05 +0200
> Ondrej Jirman wrote:
>
> > From: Icenowy Zheng
> >
> > The STK3311 chip has a variant called STK3311-X, which has a
> > different
> > chip id of 0x12.
> >
> > Add the chip id to the driver.
> >
> > Signed-off-by: Icenowy Zheng
> > Signed-off-by: Ondrej Jirman
>
> Given this is clearly not quite compatible with the stk3311 probably
> best to also add a an id to the of id table. Any idea what else
> is different?
By the way, STK3311 seems to have many variants lying around, and all
of them have different IDs. The pinouts seem to be different but the
registers are compatible.
[1] is a datasheet of STK3311-S34 with ID 0x1e.
[2] is a datasheet of STK3311-A with ID 0x15.
I cannot find the datasheet of STK3311-X, 0x12 is read from the device.
The model number itself is mentioned at [3], the official website of
sensortek.
[1]
http://pro0fc108.hkpic1.websiteonline.cn/upload/STK3311-S34Datasheetv1.pdf
[2]
http://pro0fc108.hkpic1.websiteonline.cn/upload/STK3311-ADatasheetv1.pdf
[3]
http://www.sensortek.com.tw/index.php/en/products/proximity-sensor-with-als/
>
> Thanks,
>
> Jonathan
>
> > ---
> > drivers/iio/light/stk3310.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/iio/light/stk3310.c
> > b/drivers/iio/light/stk3310.c
> > index 185c24a75ae6..1a8401d198a4 100644
> > --- a/drivers/iio/light/stk3310.c
> > +++ b/drivers/iio/light/stk3310.c
> > @@ -37,6 +37,7 @@
> >
> > #define STK3310_CHIP_ID_VAL0x13
> > #define STK3311_CHIP_ID_VAL0x1D
> > +#define STK3311X_CHIP_ID_VAL 0x12
> > #define STK3335_CHIP_ID_VAL0x51
> > #define STK3310_PSINT_EN 0x01
> > #define STK3310_PS_MAX_VAL 0x
> > @@ -453,6 +454,7 @@ static int stk3310_init(struct iio_dev
> > *indio_dev)
> >
> > if (chipid != STK3310_CHIP_ID_VAL &&
> > chipid != STK3311_CHIP_ID_VAL &&
> > + chipid != STK3311X_CHIP_ID_VAL &&
> > chipid != STK3335_CHIP_ID_VAL) {
> > dev_err(&client->dev, "invalid chip id: 0x%x\n",
> > chipid);
> > return -ENODEV;
Re: [PATCH v6 13/13] arm64: dts: sun50i-a64-pinephone: Add touchscreen support
于 2020年7月1日 GMT+08:00 下午6:31:26, Ondrej Jirman 写到:
>Pinephone has a Goodix GT917S capacitive touchscreen controller on
>I2C0 bus. Add support for it.
>
>Signed-off-by: Ondrej Jirman
>Acked-by: Linus Walleij
>---
> .../dts/allwinner/sun50i-a64-pinephone.dtsi | 19 +++
> 1 file changed, 19 insertions(+)
>
>diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
>b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
>index 85a7aa5efd32..2d5694446d17 100644
>--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
>+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone.dtsi
>@@ -123,6 +123,25 @@ &ehci1 {
> status = "okay";
> };
>
>+&i2c0 {
>+ pinctrl-names = "default";
>+ pinctrl-0 = <&i2c0_pins>;
>+ status = "okay";
>+
>+ touchscreen@5d {
>+ compatible = "goodix,gt917s", "goodix,gt911";
Please drop gt911 here. GT917S belong to the GT1x product line, not the same
line with GT911.
You will see this in the driver.
>+ reg = <0x5d>;
>+ interrupt-parent = <&pio>;
>+ interrupts = <7 4 IRQ_TYPE_LEVEL_HIGH>; /* PH4 */
>+ irq-gpios = <&pio 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
>+ reset-gpios = <&pio 7 11 GPIO_ACTIVE_HIGH>; /* PH11 */
>+ AVDD28-supply = <®_ldo_io0>;
>+ VDDIO-supply = <®_ldo_io0>;
>+ touchscreen-size-x = <720>;
>+ touchscreen-size-y = <1440>;
>+ };
>+};
>+
> &i2c1 {
> status = "okay";
>
Re: [linux-sunxi] [PATCH 2/2] power: supply: axp20x_usb_power: add applied max Vbus support for AXP813
于 2019年10月8日 GMT+08:00 上午12:07:05, Chen-Yu Tsai 写到:
>Hi,
>
>On Wed, Oct 2, 2019 at 7:27 PM Icenowy Zheng wrote:
>>
>> AXP813 PMIC has two Vbus maximum value settings -- one is the default
>> value, which is currently the only supported one; the other is the
>> really applied value, which is set according to the default value if
>the
>> BC detection module detected a charging port, or 500mA if no charging
>> port is detected.
>>
>> Add support for reading and writing of the really applied Vbus
>maxmium
>> value. Interestingly it has a larger range than the default value.
>>
>> Signed-off-by: Icenowy Zheng
>> ---
>> drivers/power/supply/axp20x_usb_power.c | 132
>+++-
>> 1 file changed, 129 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/power/supply/axp20x_usb_power.c
>b/drivers/power/supply/axp20x_usb_power.c
>> index 5f0a5722b19e..905668a2727f 100644
>> --- a/drivers/power/supply/axp20x_usb_power.c
>> +++ b/drivers/power/supply/axp20x_usb_power.c
>
>[...]
>
>> @@ -354,6 +451,9 @@ static int axp20x_usb_power_set_property(struct
>power_supply *psy,
>>
>val->intval);
>> return axp20x_usb_power_set_current_max(power,
>val->intval);
>>
>> + case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
>> + return
>axp20x_usb_power_set_input_current_limit(power, val->intval);
>> +
>
>So I think there are two things that should be adjusted.
>
>First, we should be using POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT for all
>PMICs.
>As far as the sysfs documents go, CURRENT_MAX is read-only, and should
>refer to
>the hard limit the hardware can support, i.e. maximum power ratings.
>INPUT_CURRENT_LIMIT and INPUT_VOLTAGE_LIMIT are for configurable upper
>and lower
>limits respectively.
>
>Sebastian, is my understanding of this correct?
>
>We already use INPUT_CURRENT_LIMIT for the AXP813 in the axp20x-ac
>driver, and
>it would be nice to have both drivers expose the same attributes.
>
>Second, since the value set in register 0x35 is the one that actually
>has an
>effect, as opposed to just being a default, we should just use that
>one.
However, that default value is also important, otherwise users will
get dropped back to 500mAh each time they re-insert USB jack.
Is there a property to export the default value?
BTW, if possible, apply patch 1 first, because it can raise current to 1.5A
in the default situation.
>
>Could you restructure the series based on what I described, with a new
>patch 1
>switching from CURRENT_MAX to INPUT_CURRENT_LIMIT, and then this patch
>as patch 2?
>And both patches should have Fixes tags and possibly CC stable so they
>get backported
>for people that are using stable kernels? And then the original patch
>2 as patch 3.
>
>ChenYu
>
>> default:
>> return -EINVAL;
>> }
>> @@ -365,7 +465,8 @@ static int axp20x_usb_power_prop_writeable(struct
>power_supply *psy,
>>enum power_supply_property
>psp)
>> {
>> return psp == POWER_SUPPLY_PROP_VOLTAGE_MIN ||
>> - psp == POWER_SUPPLY_PROP_CURRENT_MAX;
>> + psp == POWER_SUPPLY_PROP_CURRENT_MAX ||
>> + psp == POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT;
>> }
>>
>> static enum power_supply_property axp20x_usb_power_properties[] = {
>> @@ -386,6 +487,15 @@ static enum power_supply_property
>axp22x_usb_power_properties[] = {
>> POWER_SUPPLY_PROP_CURRENT_MAX,
>> };
>>
>> +static enum power_supply_property axp813_usb_power_properties[] = {
>> + POWER_SUPPLY_PROP_HEALTH,
>> + POWER_SUPPLY_PROP_PRESENT,
>> + POWER_SUPPLY_PROP_ONLINE,
>> + POWER_SUPPLY_PROP_VOLTAGE_MIN,
>> + POWER_SUPPLY_PROP_CURRENT_MAX,
>> + POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT,
>> +};
>> +
>> static const struct power_supply_desc axp20x_usb_power_desc = {
>> .name = "axp20x-usb",
>> .type = POWER_SUPPLY_TYPE_USB,
>> @@ -406,6 +516,16 @@ static const struct power_supply_desc
>axp22x_usb_power_desc = {
>> .set_property = axp20x_usb_power_set_property,
>> };
>>
>> +static const struct power_supply_desc axp813_usb_power_desc = {
>> + .name = "axp20x-usb",
>> + .type = POWER_SUPPLY_TYPE_USB,
>> + .properties = axp813_usb_power_properties,
>> + .num_properties = ARRAY_SIZE(axp813_usb_power_properties),
>>
[PATCH 2/2] power: supply: axp20x_usb_power: add applied max Vbus support for AXP813
AXP813 PMIC has two Vbus maximum value settings -- one is the default
value, which is currently the only supported one; the other is the
really applied value, which is set according to the default value if the
BC detection module detected a charging port, or 500mA if no charging
port is detected.
Add support for reading and writing of the really applied Vbus maxmium
value. Interestingly it has a larger range than the default value.
Signed-off-by: Icenowy Zheng
---
drivers/power/supply/axp20x_usb_power.c | 132 +++-
1 file changed, 129 insertions(+), 3 deletions(-)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index 5f0a5722b19e..905668a2727f 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -50,6 +50,18 @@
#define AXP813_BC_EN BIT(0)
+#define AXP813_VBUS_CLIMIT_REAL_MASK GENMASK(7, 4)
+#define AXP813_VBUS_CLIMIT_REAL_100mA (0 << 4)
+#define AXP813_VBUS_CLIMIT_REAL_500mA (1 << 4)
+#define AXP813_VBUS_CLIMIT_REAL_900mA (2 << 4)
+#define AXP813_VBUS_CLIMIT_REAL_1500mA (3 << 4)
+#define AXP813_VBUS_CLIMIT_REAL_2000mA (4 << 4)
+#define AXP813_VBUS_CLIMIT_REAL_2500mA (5 << 4)
+#define AXP813_VBUS_CLIMIT_REAL_3000mA (6 << 4)
+#define AXP813_VBUS_CLIMIT_REAL_3500mA (7 << 4)
+#define AXP813_VBUS_CLIMIT_REAL_4000mA (8 << 4)
+/* The remaining values are all 4000mA according to the datasheet */
+
/*
* Note do not raise the debounce time, we must report Vusb high within
* 100ms otherwise we get Vbus errors in musb.
@@ -159,6 +171,47 @@ static int axp813_get_current_max(struct axp20x_usb_power
*power, int *val)
return 0;
}
+static int axp813_get_input_current_limit(struct axp20x_usb_power *power, int
*val)
+{
+ unsigned int v;
+ int ret = regmap_read(power->regmap, AXP22X_CHRG_CTRL3, &v);
+
+ if (ret)
+ return ret;
+
+ switch (v & AXP813_VBUS_CLIMIT_REAL_MASK) {
+ case AXP813_VBUS_CLIMIT_REAL_100mA:
+ *val = 10;
+ break;
+ case AXP813_VBUS_CLIMIT_REAL_500mA:
+ *val = 50;
+ break;
+ case AXP813_VBUS_CLIMIT_REAL_900mA:
+ *val = 90;
+ break;
+ case AXP813_VBUS_CLIMIT_REAL_1500mA:
+ *val = 150;
+ break;
+ case AXP813_VBUS_CLIMIT_REAL_2000mA:
+ *val = 200;
+ break;
+ case AXP813_VBUS_CLIMIT_REAL_2500mA:
+ *val = 250;
+ break;
+ case AXP813_VBUS_CLIMIT_REAL_3000mA:
+ *val = 300;
+ break;
+ case AXP813_VBUS_CLIMIT_REAL_3500mA:
+ *val = 350;
+ break;
+ default:
+ /* All other cases are 4000mA */
+ *val = 400;
+ break;
+ }
+ return 0;
+}
+
static int axp20x_usb_power_get_property(struct power_supply *psy,
enum power_supply_property psp, union power_supply_propval *val)
{
@@ -200,6 +253,8 @@ static int axp20x_usb_power_get_property(struct
power_supply *psy,
if (power->axp20x_id == AXP813_ID)
return axp813_get_current_max(power, &val->intval);
return axp20x_get_current_max(power, &val->intval);
+ case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+ return axp813_get_input_current_limit(power, &val->intval);
case POWER_SUPPLY_PROP_CURRENT_NOW:
if (IS_ENABLED(CONFIG_AXP20X_ADC)) {
ret = iio_read_channel_processed(power->vbus_i,
@@ -338,6 +393,48 @@ static int axp20x_usb_power_set_current_max(struct
axp20x_usb_power *power,
return -EINVAL;
}
+static int axp20x_usb_power_set_input_current_limit(struct axp20x_usb_power
*power,
+ int intval)
+{
+ int val;
+
+ switch (intval) {
+ case 10:
+ val = AXP813_VBUS_CLIMIT_REAL_100mA;
+ break;
+ case 50:
+ val = AXP813_VBUS_CLIMIT_REAL_500mA;
+ break;
+ case 90:
+ val = AXP813_VBUS_CLIMIT_REAL_900mA;
+ break;
+ case 150:
+ val = AXP813_VBUS_CLIMIT_REAL_1500mA;
+ break;
+ case 200:
+ val = AXP813_VBUS_CLIMIT_REAL_2000mA;
+ break;
+ case 250:
+ val = AXP813_VBUS_CLIMIT_REAL_2500mA;
+ break;
+ case 300:
+ val = AXP813_VBUS_CLIMIT_REAL_3000mA;
+ break;
+ case 350:
+ val = AXP813_VBUS_CLIMIT_REAL_3500mA;
+ break;
+ case 400:
+ val = AXP813_VBUS_CLIMIT_REAL_4000mA;
+ break;
+ default:
[PATCH 1/2] power: supply: axp20x_usb_power: enable USB BC detection on AXP813
The AXP813 PMIC has support for detection of USB Battery Charging
specification, and it will limit the current to 500mA by default when
the detection is not enabled or the detection result is SDP.
Enable the BC detection to allow correctly selection of the current.
Signed-off-by: Icenowy Zheng
---
drivers/power/supply/axp20x_usb_power.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/power/supply/axp20x_usb_power.c
b/drivers/power/supply/axp20x_usb_power.c
index dc4c316eff81..5f0a5722b19e 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -48,6 +48,8 @@
#define AXP20X_VBUS_MON_VBUS_VALID BIT(3)
+#define AXP813_BC_EN BIT(0)
+
/*
* Note do not raise the debounce time, we must report Vusb high within
* 100ms otherwise we get Vbus errors in musb.
@@ -495,6 +497,12 @@ static int axp20x_usb_power_probe(struct platform_device
*pdev)
return -EINVAL;
}
+ if (power->axp20x_id == AXP813_ID) {
+ /* Enable USB Battery Charging specification detection */
+ regmap_update_bits(axp20x->regmap, AXP288_BC_GLOBAL,
+ AXP813_BC_EN, AXP813_BC_EN);
+ }
+
psy_cfg.of_node = pdev->dev.of_node;
psy_cfg.drv_data = power;
--
2.21.0
[PATCH 0/2] Enable USB BC detection to raise AXP813 Vbus current
Unlike previous AXP PMICs, the AXP813 PMIC (and AXP803) supports port detection defined in USB Battery Charging Specification 1.2, and sets the real Vbus current based on a pre-defined value (which is the original Vbus current limitation field) and the port status. However, the detection needs manual activision. If it's not active, the PMIC will assume a SDP and limit the Vbus current to 500mA. This patchset contains two patches, one enables the USB BC 1.2 detection, the other exports the real applied Vbus limitation. Icenowy Zheng (2): power: supply: axp20x_usb_power: enable USB BC detection on AXP813 power: supply: axp20x_usb_power: add applied max Vbus support for AXP813 drivers/power/supply/axp20x_usb_power.c | 140 +++- 1 file changed, 137 insertions(+), 3 deletions(-) -- 2.21.0
Re: [PATCH 0/3] Pine64+ specific hacks for RTL8211E Ethernet PHY
于 2019年10月2日 GMT+08:00 上午12:30:00, David Miller 写到: >From: Icenowy Zheng >Date: Wed, 02 Oct 2019 00:08:39 +0800 > >> >> >> 于 2019年10月2日 GMT+08:00 上午12:06:51, David Miller >写到: >>>From: Icenowy Zheng >>>Date: Tue, 1 Oct 2019 16:29:09 +0800 >>> >>>> There're some Pine64+ boards known to have broken RTL8211E chips, >and >>>> a hack is given by Pine64+, which is said to be from Realtek. >>>> >>>> This patchset adds the hack. >>>> >>>> The hack is taken from U-Boot, and it contains magic numbers >without >>>> any document. >>> >>>Please contact Realtek and try to get an explanation about this. >> >> Sorry, but Realtek never shows any idea to add more infomation about >this. >> >> These hacks had existed and worked for years. > >Have you actually tried to communicate with an appropriate contact >yourself? > >If not, I am asking you to do so. I have tried to ask via TL Lim from Pine64, because I have no way to communicate directly to Realtek. However TL cannot get anything more from Realtek. > >___ >linux-arm-kernel mailing list >linux-arm-ker...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- 使用 K-9 Mail 发送自我的Android设备。
Re: [PATCH 0/3] Pine64+ specific hacks for RTL8211E Ethernet PHY
于 2019年10月2日 GMT+08:00 上午12:06:51, David Miller 写到: >From: Icenowy Zheng >Date: Tue, 1 Oct 2019 16:29:09 +0800 > >> There're some Pine64+ boards known to have broken RTL8211E chips, and >> a hack is given by Pine64+, which is said to be from Realtek. >> >> This patchset adds the hack. >> >> The hack is taken from U-Boot, and it contains magic numbers without >> any document. > >Please contact Realtek and try to get an explanation about this. Sorry, but Realtek never shows any idea to add more infomation about this. These hacks had existed and worked for years. > >I understand that eventually we may not get a proper explanation >but I really want you to put forth real effort to nail down whats >going on here before I even consider these patches seriously. > >Thank you. > >___ >linux-arm-kernel mailing list >linux-arm-ker...@lists.infradead.org >http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
