* Re: [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF
From: Esben Haabendal @ 2019-04-29 14:25 UTC (permalink / raw)
To: Andy Shevchenko
Cc: open list:SERIAL DRIVERS, Greg Kroah-Hartman, Jiri Slaby,
Darwin Dingel, He Zhe, Jisheng Zhang, Sebastian Andrzej Siewior,
Linux Kernel Mailing List
In-Reply-To: <20190429133535.GG9224@smile.fi.intel.com>
Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> On Mon, Apr 29, 2019 at 11:29:05AM +0200, Esben Haabendal wrote:
>> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
>> > On Mon, Apr 29, 2019 at 9:27 AM Esben Haabendal <esben@haabendal.dk> wrote:
>> >> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
>> >> > On Sat, Apr 27, 2019 at 12:01 PM Esben Haabendal <esben@haabendal.dk>
>> >> > wrote:
>> >> >> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
>> >> >> > On Fri, Apr 26, 2019 at 06:54:05PM +0200, Esben Haabendal wrote:
>> >> >> >> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
>
>> So maybe we should go down that direction intead, extending 8250 driver
>> to replace mapbase with a resource struct instead?
>>
>> > Btw, we have PCI MFD driver which enumerates 8250 (more precisely
>> > 8250_dw) w/o any issues.
>>
>> I am aware of that (sm501.c). It avoids the problem by not requesting
>> the parent memory region (sm->io_res), and requesting all child memory
>> regions directly in root instead of relative to the sm->io_res parent.
>>
>> But as resoure management is designed for managing a parent/child
>> resource tree, this looks much more like a workaround than the right
>> solution.
>>
>> >> It would be nice if child drivers requesting memory would pass the
>> >> parent memory resource. Maybe 8250 driver could be changed to accept a
>> >> struct resource pointer instead of a simple mapbase value, allowing to
>> >> setup the resource with parent pointing to the MFD memory resource.
>> >
>> > I don't see the problem in certain driver, I guess you are trying to
>> > workaround existin Linux device resource model.
>>
>> No, I actually try to do the right thing in relation to Linux device
>> resource model. But 8250 is just not behaving very well in that
>> respect, not having been made really aware of the resource model.
>
> The point here is that. MFD driver can re-use existing platform drivers which
> may be used standalone. They and only they are the right owners of the
> requesting *their* resources.
>
> When parent request resources on the behalf of its child it simple will break
> this flexibility.
I hear what you say. And I agree, parent/mfd drivers should not request
resources on behalf of it's children.
But on the other side, something is broken by design in mfd, if it is
not possible for parent/mfd driver to request the resources for itself,
which naturally contains the resources for all it's mfd
functions/childs.
Please take a look at mfd_add_device() in drivers/mfd/mfd-core.c, and
the use of the cell and mem_base arguments in particular.
for (r = 0; r < cell->num_resources; r++) {
res[r].name = cell->resources[r].name;
res[r].flags = cell->resources[r].flags;
/* Find out base to use */
if ((cell->resources[r].flags & IORESOURCE_MEM) && mem_base) {
res[r].parent = mem_base;
res[r].start = mem_base->start +
cell->resources[r].start;
res[r].end = mem_base->start +
cell->resources[r].end;
It really is a core part of mfd drivers that you request a memory
resource for the mfd driver, and then have one or more child memory
resources requsted with the parent memory resource as base.
Many mfd drivers handle resources like this, like: htc/pasic3.c,
sta2x11-mfd.c and intel-lpss.c.
Ofcourse, the sm501.c driver does not, as it does not use the mfd API at
all, and is thus not a good example of a mfd driver, and there is
therefore no good examples of using 8250 with an mfd driver.
/Esben
^ permalink raw reply
* Re: [PATCH 01/41] drivers: tty: serial: dz: use dev_err() instead of printk()
From: Greg KH @ 2019-04-29 14:23 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: Enrico Weigelt, metux IT consult, linux-kernel, andrew,
andriy.shevchenko, macro, vz, slemieux.tyco, khilman, liviu.dudau,
sudeep.holla, lorenzo.pieralisi, davem, jacmet, linux,
matthias.bgg, linux-mips, linux-serial, linux-ia64, linux-amlogic,
linuxppc-dev, sparclinux
In-Reply-To: <e10175d0-bc3b-a4ab-cb47-0b4761bfb629@metux.net>
On Mon, Apr 29, 2019 at 04:11:15PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 27.04.19 15:29, Greg KH wrote:
> > On Sat, Apr 27, 2019 at 02:51:42PM +0200, Enrico Weigelt, metux IT consult wrote:
> >> Using dev_err() instead of printk() for more consistent output.
> >> (prints device name, etc).
> >>
> >> Signed-off-by: Enrico Weigelt <info@metux.net>
> >
> > Your "From:" line does not match the signed-off-by line, so I can't take
> > any of these if I wanted to :(
>
> Grmpf. I've manually changed it, as you isisted in having my company
> name remove from it ....
Yes, that's fine, but the lines have to match. See the documentation
for how to have a "From:" in the changelog text to override whatever
your email client happens to pollute the email with :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 01/41] drivers: tty: serial: dz: use dev_err() instead of printk()
From: Enrico Weigelt, metux IT consult @ 2019-04-29 14:11 UTC (permalink / raw)
To: Greg KH, Enrico Weigelt, metux IT consult
Cc: linux-kernel, andrew, andriy.shevchenko, macro, vz, slemieux.tyco,
khilman, liviu.dudau, sudeep.holla, lorenzo.pieralisi, davem,
jacmet, linux, matthias.bgg, linux-mips, linux-serial, linux-ia64,
linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <20190427132959.GA11368@kroah.com>
On 27.04.19 15:29, Greg KH wrote:
> On Sat, Apr 27, 2019 at 02:51:42PM +0200, Enrico Weigelt, metux IT consult wrote:
>> Using dev_err() instead of printk() for more consistent output.
>> (prints device name, etc).
>>
>> Signed-off-by: Enrico Weigelt <info@metux.net>
>
> Your "From:" line does not match the signed-off-by line, so I can't take
> any of these if I wanted to :(
Grmpf. I've manually changed it, as you isisted in having my company
name remove from it ....
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF
From: Andy Shevchenko @ 2019-04-29 13:35 UTC (permalink / raw)
To: Esben Haabendal
Cc: open list:SERIAL DRIVERS, Greg Kroah-Hartman, Jiri Slaby,
Darwin Dingel, He Zhe, Jisheng Zhang, Sebastian Andrzej Siewior,
Linux Kernel Mailing List
In-Reply-To: <87ef5lxiqm.fsf@haabendal.dk>
On Mon, Apr 29, 2019 at 11:29:05AM +0200, Esben Haabendal wrote:
> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> > On Mon, Apr 29, 2019 at 9:27 AM Esben Haabendal <esben@haabendal.dk> wrote:
> >> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> >> > On Sat, Apr 27, 2019 at 12:01 PM Esben Haabendal <esben@haabendal.dk> wrote:
> >> >> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> >> >> > On Fri, Apr 26, 2019 at 06:54:05PM +0200, Esben Haabendal wrote:
> >> >> >> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> So maybe we should go down that direction intead, extending 8250 driver
> to replace mapbase with a resource struct instead?
>
> > Btw, we have PCI MFD driver which enumerates 8250 (more precisely
> > 8250_dw) w/o any issues.
>
> I am aware of that (sm501.c). It avoids the problem by not requesting
> the parent memory region (sm->io_res), and requesting all child memory
> regions directly in root instead of relative to the sm->io_res parent.
>
> But as resoure management is designed for managing a parent/child
> resource tree, this looks much more like a workaround than the right
> solution.
>
> >> It would be nice if child drivers requesting memory would pass the
> >> parent memory resource. Maybe 8250 driver could be changed to accept a
> >> struct resource pointer instead of a simple mapbase value, allowing to
> >> setup the resource with parent pointing to the MFD memory resource.
> >
> > I don't see the problem in certain driver, I guess you are trying to
> > workaround existin Linux device resource model.
>
> No, I actually try to do the right thing in relation to Linux device
> resource model. But 8250 is just not behaving very well in that
> respect, not having been made really aware of the resource model.
The point here is that. MFD driver can re-use existing platform drivers which
may be used standalone. They and only they are the right owners of the
requesting *their* resources.
When parent request resources on the behalf of its child it simple will break
this flexibility.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 40/41] drivers: tty: serial: helper for setting mmio range
From: Andy Shevchenko @ 2019-04-29 13:28 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: Enrico Weigelt, metux IT consult, linux-kernel, gregkh, andrew,
macro, vz, slemieux.tyco, khilman, liviu.dudau, sudeep.holla,
lorenzo.pieralisi, davem, jacmet, linux, matthias.bgg, linux-mips,
linux-serial, linux-ia64, linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <c75f4ca9-367c-25d5-2597-75f2dccf6e1c@metux.net>
On Mon, Apr 29, 2019 at 12:12:35PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 28.04.19 17:39, Andy Shevchenko wrote:
> seems I've forgot to add "RFC:" in the subject - I'm not entirely happy
> w/ that patch myself, just want to hear your oppinions.
>
> Moreover, the size argument seems wrong here.
Something went wrong with quoting style in your reply.
> hmm, I'm actually not sure yet, what the correct size really would be,
> where the value actually comes from. Just assumed that it would be the
> whole area that the BAR tells. But now I recognized that I'd need to
> substract 'offset' here.
It will be still wrong. The driver in question defines resource window based on
several parameters. So, this should be supplied with a real understanding of
all variety of hardware the certain driver serves for.
> Rethinking it further, we'd probably could deduce the UPIO_* from the
> struct resource, too.
>
> >> + uart_memres_set_start_len(>> + &port,>> + FRODO_BASE + FRODO_APCI_OFFSET(1), 0);> > Please,
> avoid such splitting, first parameter is quite fit above line.
>
> Ok. My intention was having both parameters starting at the same line,
> but then the second line would get too long again. > ...and here, and
> maybe in other places you split the assignments to the members> in two
> part. Better to call your function before or after these blocks of>
> assignments.
> the reason what I've just replaced the exactly the assignments, trying
> not to touch too much ;-)
> I'll have a closer look on what can be moved w/o side effects.
Just try to avoid
foo(
bar, ...
-like splitting.
> >> +static inline void uart_memres_set_res(struct uart_port *port,
> >
> > Perhaps better name can be found.
> > Especially taking into account that it handles IO / MMIO here.
>
> hmm, lacking creativity here ;-)
> any suggestions ?
No immediate suggestions.
uart_set_io_resource()
uart_clear_io_resource()
at least sounds more plausible to me.
> >> + struct resource *res)
> >> +{
> >> + if (!res) {
> >
> > It should return an error in such case.
>
> It's not an error, but desired behaviour: NULL resource
> clears the value.
Oh, then why it's in this function, which is *setter* according to its name,
at all?
>
> >> + port->mapsize = 0;
> >> + port->mapbase = 0;
> >> + port->iobase = 0;
> >> + return;
> >> + }
> >> +
> >> + if (resource_type(res) == IORESOURCE_IO) {
> >> + port->iotype = UPIO_PORT;
> >> + port->iobase = resource->start;
> >> + return;
> >> + }
> >> +
> >> + uart->mapbase = res->start;
> >> + uart->mapsize = resource_size(res);
> >
> >> + uart->iotype = UPIO_MEM;
> >
> > Only one type? Why type is even set here?
>
> It's the default case. The special cases (eg. UPIO_MEM32) need to be
> set explicitly, after that call.
Which is weird.
> Not really nice, but haven't found a better solution yet.
Just simple not touching it?
> I don't like
> the idea of passing an UPIO_* parameter to the function, most callers
> should not care, if they don't really need to.
They do care. The driver on its own knows better than any generic code what
type of hardware it serves to.
> >> + */
> >
> >> +static inline void uart_memres_set_start_len(struct uart_driver *uart,
> >> + resource_size_t start,
> >> + resource_size_t len)
> >
> > The comment doesn't tell why this is needed when we have one for struct
> > resource.
>
> Renamed it to uart_memres_set_mmio_range().
See also above about naming patterns.
>
> This helper is meant for drivers that don't work w/ struct resource,
> or explicitly set their own len.
Then why it's not mentioned in the description of the function?
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 37/41] drivers: tty: serial: 8250: simplify io resource size computation
From: Andy Shevchenko @ 2019-04-29 13:19 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: Enrico Weigelt, metux IT consult, linux-kernel, gregkh, andrew,
macro, vz, slemieux.tyco, khilman, liviu.dudau, sudeep.holla,
lorenzo.pieralisi, davem, jacmet, linux, matthias.bgg, linux-mips,
linux-serial, linux-ia64, linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <431b36fe-3071-fcfd-b04e-b4b293e79a80@metux.net>
On Mon, Apr 29, 2019 at 08:48:53AM +0200, Enrico Weigelt, metux IT consult wrote:
> On 28.04.19 17:21, Andy Shevchenko wrote:
> >> +#define SERIAL_RT2880_IOSIZE 0x100
> >
> > And why this is in the header file and not in corresponding C one?
>
> hmm, no particular reason, maybe just an old habit to put definitions
> into .h files ;-)
>
> I can move it to 8250_of.c if you like me to.
Please, do.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 01/41] drivers: tty: serial: dz: use dev_err() instead of printk()
From: Greg KH @ 2019-04-29 13:12 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: Enrico Weigelt, metux IT consult, linux-kernel, andrew,
andriy.shevchenko, macro, vz, slemieux.tyco, khilman, liviu.dudau,
sudeep.holla, lorenzo.pieralisi, davem, jacmet, linux,
matthias.bgg, linux-mips, linux-serial, linux-ia64, linux-amlogic,
linuxppc-dev, sparclinux
In-Reply-To: <bae3f23b-8823-f089-c40e-024ba225555f@metux.net>
On Mon, Apr 29, 2019 at 02:37:04PM +0200, Enrico Weigelt, metux IT consult wrote:
> On 27.04.19 15:31, Greg KH wrote:
> > On Sat, Apr 27, 2019 at 02:51:42PM +0200, Enrico Weigelt, metux IT consult wrote:
> >> Using dev_err() instead of printk() for more consistent output.
> >> (prints device name, etc).
> >>
> >> Signed-off-by: Enrico Weigelt <info@metux.net>
> >> ---
> >> drivers/tty/serial/dz.c | 8 ++++----
> >
> > Do you have this hardware to test any of these changes with?
>
> Unfortunately not :(
Then I can take the "basic" types of patches for the driver (like this
one), but not any others, sorry.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF
From: Enrico Weigelt, metux IT consult @ 2019-04-29 12:56 UTC (permalink / raw)
To: Esben Haabendal, Andy Shevchenko
Cc: Andy Shevchenko, open list:SERIAL DRIVERS, Greg Kroah-Hartman,
Jiri Slaby, Darwin Dingel, He Zhe, Jisheng Zhang,
Sebastian Andrzej Siewior, Linux Kernel Mailing List
In-Reply-To: <87ef5lxiqm.fsf@haabendal.dk>
On 29.04.19 11:29, Esben Haabendal wrote:
> So maybe we should go down that direction intead, extending 8250 driver
> to replace mapbase with a resource struct instead?
Yeah, I already was up to do that. But that would be a pretty massive
change, as the actual use of fields like mapsize/mapbase in the drivers
is so diverse. Some even don't use mapsize.
That's why I started harmonizing that step by step. In little steps,
that are easier to review (unfortunately, don't have the corresponding
hardware to do real tests).
Finally, I'd like to have all drivers just use appropriate helpers to
declare their IO area and let the core do all the mapping stuff. Then we
IMHO could easily switch to struct resource internally.
> No, I actually try to do the right thing in relation to Linux device
> resource model. But 8250 is just not behaving very well in that
> respect, not having been made really aware of the resource model.
I see it the same way. The serial (especially 8250) drivers are a tricky
thing, and I'd like to make it simpler / easier to understand.
But I can understand that Greg is pretty reluctant to any changes, as
some actual hardware seems to be hard to get. (OTOH, if it's so rare,
could we risk some potential breaks and just wait for anybody
complaining ?)
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 3/4] dt-bindings: dma: uart: rename binding
From: Rob Herring @ 2019-04-29 12:48 UTC (permalink / raw)
To: Long Cheng
Cc: Vinod Koul, Randy Dunlap, Rob Herring, Mark Rutland, Ryder Lee,
Sean Wang, Nicolas Boichat, Matthias Brugger, Dan Williams,
Greg Kroah-Hartman, Jiri Slaby, Sean Wang, dmaengine, devicetree,
linux-arm-kernel, linux-mediatek, linux-kernel, linux-serial,
srv_heupstream, Yingjoe Chen, YT Shen, Zhenbao Liu <zhenb>
In-Reply-To: <1556336193-15198-4-git-send-email-long.cheng@mediatek.com>
On Sat, 27 Apr 2019 11:36:32 +0800, Long Cheng wrote:
> The filename matches mtk-uart-apdma.c.
> So using "mtk-uart-apdma.txt" should be better.
> And add some property.
>
> Signed-off-by: Long Cheng <long.cheng@mediatek.com>
> ---
> .../devicetree/bindings/dma/8250_mtk_dma.txt | 33 ------------
> .../devicetree/bindings/dma/mtk-uart-apdma.txt | 55 ++++++++++++++++++++
> 2 files changed, 55 insertions(+), 33 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/dma/8250_mtk_dma.txt
> create mode 100644 Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt
>
Please add Acked-by/Reviewed-by tags when posting new versions. However,
there's no need to repost patches *only* to add the tags. The upstream
maintainer will do that for acks received on the version they apply.
If a tag was not added on purpose, please state why and what changed.
^ permalink raw reply
* Re: [PATCH 01/41] drivers: tty: serial: dz: use dev_err() instead of printk()
From: Enrico Weigelt, metux IT consult @ 2019-04-29 12:37 UTC (permalink / raw)
To: Greg KH, Enrico Weigelt, metux IT consult
Cc: linux-kernel, andrew, andriy.shevchenko, macro, vz, slemieux.tyco,
khilman, liviu.dudau, sudeep.holla, lorenzo.pieralisi, davem,
jacmet, linux, matthias.bgg, linux-mips, linux-serial, linux-ia64,
linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <20190427133117.GC11368@kroah.com>
On 27.04.19 15:31, Greg KH wrote:
> On Sat, Apr 27, 2019 at 02:51:42PM +0200, Enrico Weigelt, metux IT consult wrote:
>> Using dev_err() instead of printk() for more consistent output.
>> (prints device name, etc).
>>
>> Signed-off-by: Enrico Weigelt <info@metux.net>
>> ---
>> drivers/tty/serial/dz.c | 8 ++++----
>
> Do you have this hardware to test any of these changes with?
Unfortunately not :(
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 40/41] drivers: tty: serial: helper for setting mmio range
From: Enrico Weigelt, metux IT consult @ 2019-04-29 10:12 UTC (permalink / raw)
To: Andy Shevchenko, Enrico Weigelt, metux IT consult
Cc: linux-kernel, gregkh, andrew, macro, vz, slemieux.tyco, khilman,
liviu.dudau, sudeep.holla, lorenzo.pieralisi, davem, jacmet,
linux, matthias.bgg, linux-mips, linux-serial, linux-ia64,
linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <20190428153905.GR9224@smile.fi.intel.com>
On 28.04.19 17:39, Andy Shevchenko wrote:
Hi,
seems I've forgot to add "RFC:" in the subject - I'm not entirely happy
w/ that patch myself, just want to hear your oppinions.
>> - port->port.iotype = UPIO_MEM;>> - port->port.mapbase = pci_resource_start(pcidev, bar) + offset;>> +
uart_memres_set_start_len(&port->port,>> +
pci_resource_start(pcidev, bar) + offset,>> +
pci_resource_len(pcidev, bar));>> +> > I don't see how it's better.>
Moreover, the size argument seems wrong here.
hmm, I'm actually not sure yet, what the correct size really would be,
where the value actually comes from. Just assumed that it would be the
whole area that the BAR tells. But now I recognized that I'd need to
substract 'offset' here.
Rethinking it further, we'd probably could deduce the UPIO_* from the
struct resource, too.
>> + uart_memres_set_start_len(>> + &port,>> + FRODO_BASE + FRODO_APCI_OFFSET(1), 0);> > Please,
avoid such splitting, first parameter is quite fit above line.
Ok. My intention was having both parameters starting at the same line,
but then the second line would get too long again. > ...and here, and
maybe in other places you split the assignments to the members> in two
part. Better to call your function before or after these blocks of>
assignments.
the reason what I've just replaced the exactly the assignments, trying
not to touch too much ;-)
I'll have a closer look on what can be moved w/o side effects.
>> - uport->mapsize = ZS_CHAN_IO_SIZE;
>> - uport->mapbase = dec_kn_slot_base +
>> - zs_parms.scc[chip] +
>> - (side ^ ZS_CHAN_B) * ZS_CHAN_IO_SIZE;
>> +
>> + uart_memres_set_start_len(dec_kn_slot_base +
>> + zs_parms.scc[chip] +
>> + (side ^ ZS_CHAN_B) *
>> + ZS_CHAN_IO_SIZE,
>> + ZS_CHAN_IO_SIZE);
>
> This looks hard to read. Think of temporary variables and better formatting
> style.
Ok.
>
>> /*
>> + * set physical io range from struct resource
>> + * if resource is NULL, clear the fields
>> + * also set the iotype to UPIO_MEM
>
> Something wrong with punctuation and style. Please, use proper casing and
> sentences split.
Ok. fixed it.
>> +static inline void uart_memres_set_res(struct uart_port *port,
>
> Perhaps better name can be found.
> Especially taking into account that it handles IO / MMIO here.
hmm, lacking creativity here ;-)
any suggestions ?
>
>> + struct resource *res)
>> +{
>> + if (!res) {
>
> It should return an error in such case.
It's not an error, but desired behaviour: NULL resource
clears the value.
>> + port->mapsize = 0;
>> + port->mapbase = 0;
>> + port->iobase = 0;
>> + return;
>> + }
>> +
>> + if (resource_type(res) == IORESOURCE_IO) {
>> + port->iotype = UPIO_PORT;
>> + port->iobase = resource->start;
>> + return;
>> + }
>> +
>> + uart->mapbase = res->start;
>> + uart->mapsize = resource_size(res);
>
>> + uart->iotype = UPIO_MEM;
>
> Only one type? Why type is even set here?
It's the default case. The special cases (eg. UPIO_MEM32) need to be
set explicitly, after that call.
Not really nice, but haven't found a better solution yet. I don't like
the idea of passing an UPIO_* parameter to the function, most callers
should not care, if they don't really need to.
>> + */
>
>> +static inline void uart_memres_set_start_len(struct uart_driver *uart,
>> + resource_size_t start,
>> + resource_size_t len)
>
> The comment doesn't tell why this is needed when we have one for struct
> resource.
Renamed it to uart_memres_set_mmio_range().
This helper is meant for drivers that don't work w/ struct resource,
or explicitly set their own len.
Thanks for your review.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 40/41] drivers: tty: serial: helper for setting mmio range
From: Enrico Weigelt, metux IT consult @ 2019-04-29 9:43 UTC (permalink / raw)
To: Esben Haabendal, Enrico Weigelt, metux IT consult
Cc: linux-kernel, gregkh, andrew, andriy.shevchenko, macro, vz,
slemieux.tyco, khilman, liviu.dudau, sudeep.holla,
lorenzo.pieralisi, davem, jacmet, linux, matthias.bgg, linux-mips,
linux-serial, linux-ia64, linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <87ef5lz423.fsf@haabendal.dk>
On 29.04.19 09:03, Esben Haabendal wrote:
> Why not simply replace iobase, mapbase and mapsize with a struct
> resource value instead?
That was actually my original goal, when I started this. But the
situation is a bit more tricky. Many drivers (especially the old ones)
initialize these fields in different ways. And there're many places
accessing these fields.
Drivers for old devices should be handled w/ great care. I don't have
access to all that hardware, so I can't test it. Therefore, I'm trying
to move in small steps. One step ahead another.
One of my next steps would be factoring out more common operations
(eg. mapping, etc) into helpers, up to a point, where someday no driver
is accessing these fields directly anymore.
Then we could easily move everything into struct resource. On that
road, we'd also need to find a way for handling the specialities of
the various UPIO_* modes via struct resource.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF
From: Esben Haabendal @ 2019-04-29 9:29 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Andy Shevchenko, open list:SERIAL DRIVERS, Greg Kroah-Hartman,
Jiri Slaby, Darwin Dingel, He Zhe, Jisheng Zhang,
Sebastian Andrzej Siewior, Linux Kernel Mailing List
In-Reply-To: <CAHp75Vc6cLnLztXtvTcWisjAqDUTEWBBgv20CA34ZQmBEAvpbA@mail.gmail.com>
Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> On Mon, Apr 29, 2019 at 9:27 AM Esben Haabendal <esben@haabendal.dk> wrote:
>> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
>> > On Sat, Apr 27, 2019 at 12:01 PM Esben Haabendal <esben@haabendal.dk> wrote:
>> >> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
>> >> > On Fri, Apr 26, 2019 at 06:54:05PM +0200, Esben Haabendal wrote:
>> >> >> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
>> >> >> The reason for this patch is to be able to do exactly that (set port
>> >> >> type and UPF_FIXED_TYPE) without having UPF_BOOT_AUTOCONF added.
>> >> >>
>> >> >> In the current serial8250_register_8250_port() there is:
>> >> >>
>> >> >> uart->port.flags = up->port.flags | UPF_BOOT_AUTOCONF;
>> >> >>
>> >> >> So, even though I set UPF_FIXED_TYPE, I get
>> >> >> UPF_FIXED_TYPE|UPF_BOOT_AUTOCONF.
>> >> >
>> >> > Yes.
>> >> >
>> >> >> So I need this patch.
>> >> >
>> >> > Why? I don't see any problems to have these flags set.
>> >>
>> >> The problem with having UPF_BOOT_AUTOCONF is the call to
>> >> serial8250_request_std_resource(). It calls request_mem_region(), which
>> >> fails if the MFD driver already have requested the memory region for the
>> >> MFD device.
>> >
>> > If it's MFD, why it requested the region for its child?
>> > Isn't it a bug in MFD driver?
>>
>> It is a PCI driver, which calls pci_request_regions(). The PCI device
>> carries a lot of different functions, which uses small slices of the PCI
>> memory region(s). With the resources being a tree structure, I don't
>> think it is a bug when a parent driver requests the entire memory
>> region.
>
> If it's MFD driver, it's not its business to do something
> child-related on child behalf.
The MFD driver is not doing anything on behalf of the child. Being the
parent (MFD), it is requesting the memory region of the MFD/parent
device, using pci_request_regions(), similar to how it is done in
fx. janz-cmodio.c.
> In any case, Linux device resource model uses exclusive region
> slicing. If you do like above, you call for a problems.
Linux device resource model supports a parent/child/sibling
structure, specifically to allow for doing something like this.
Requesting memory resources are not restricted to use the iomem_resource
root.
For example, drivers/pcmcia/soc_common.c:soc_pcmcia_add_one()
ret = request_resource(&iomem_resource, &skt->res_skt);
if (ret)
goto out_err_1;
ret = request_resource(&skt->res_skt, &skt->res_io);
if (ret)
goto out_err_2;
As an example of a parent/child memory resource request.
The problem is that the 8250 driver only allows for requesting memory
region from the root (iomem_resource), as it uses a single
resource_size_t mapbase value for specifying the memory resource instead
of a full struct resource, which would allow passing in a parent.
So maybe we should go down that direction intead, extending 8250 driver
to replace mapbase with a resource struct instead?
> Btw, we have PCI MFD driver which enumerates 8250 (more precisely
> 8250_dw) w/o any issues.
I am aware of that (sm501.c). It avoids the problem by not requesting
the parent memory region (sm->io_res), and requesting all child memory
regions directly in root instead of relative to the sm->io_res parent.
But as resoure management is designed for managing a parent/child
resource tree, this looks much more like a workaround than the right
solution.
>> It would be nice if child drivers requesting memory would pass the
>> parent memory resource. Maybe 8250 driver could be changed to accept a
>> struct resource pointer instead of a simple mapbase value, allowing to
>> setup the resource with parent pointing to the MFD memory resource.
>
> I don't see the problem in certain driver, I guess you are trying to
> workaround existin Linux device resource model.
No, I actually try to do the right thing in relation to Linux device
resource model. But 8250 is just not behaving very well in that
respect, not having been made really aware of the resource model.
And sm501.c MFD driver ignores the way resource model is designed, and
just make things work.
/Esben
^ permalink raw reply
* Re: [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF
From: Andy Shevchenko @ 2019-04-29 8:33 UTC (permalink / raw)
To: Esben Haabendal
Cc: Andy Shevchenko, open list:SERIAL DRIVERS, Greg Kroah-Hartman,
Jiri Slaby, Darwin Dingel, He Zhe, Jisheng Zhang,
Sebastian Andrzej Siewior, Linux Kernel Mailing List
In-Reply-To: <87y33tz5oz.fsf@haabendal.dk>
On Mon, Apr 29, 2019 at 9:27 AM Esben Haabendal <esben@haabendal.dk> wrote:
> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> > On Sat, Apr 27, 2019 at 12:01 PM Esben Haabendal <esben@haabendal.dk> wrote:
> >> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> >> > On Fri, Apr 26, 2019 at 06:54:05PM +0200, Esben Haabendal wrote:
> >> >> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
> >> >> The reason for this patch is to be able to do exactly that (set port
> >> >> type and UPF_FIXED_TYPE) without having UPF_BOOT_AUTOCONF added.
> >> >>
> >> >> In the current serial8250_register_8250_port() there is:
> >> >>
> >> >> uart->port.flags = up->port.flags | UPF_BOOT_AUTOCONF;
> >> >>
> >> >> So, even though I set UPF_FIXED_TYPE, I get
> >> >> UPF_FIXED_TYPE|UPF_BOOT_AUTOCONF.
> >> >
> >> > Yes.
> >> >
> >> >> So I need this patch.
> >> >
> >> > Why? I don't see any problems to have these flags set.
> >>
> >> The problem with having UPF_BOOT_AUTOCONF is the call to
> >> serial8250_request_std_resource(). It calls request_mem_region(), which
> >> fails if the MFD driver already have requested the memory region for the
> >> MFD device.
> >
> > If it's MFD, why it requested the region for its child?
> > Isn't it a bug in MFD driver?
>
> It is a PCI driver, which calls pci_request_regions(). The PCI device
> carries a lot of different functions, which uses small slices of the PCI
> memory region(s). With the resources being a tree structure, I don't
> think it is a bug when a parent driver requests the entire memory
> region.
If it's MFD driver, it's not its business to do something
child-related on child behalf.
In any case, Linux device resource model uses exclusive region
slicing. If you do like above, you call for a problems.
Btw, we have PCI MFD driver which enumerates 8250 (more precisely
8250_dw) w/o any issues.
> It would be nice if child drivers requesting memory would pass the
> parent memory resource. Maybe 8250 driver could be changed to accept a
> struct resource pointer instead of a simple mapbase value, allowing to
> setup the resource with parent pointing to the MFD memory resource.
I don't see the problem in certain driver, I guess you are trying to
workaround existin Linux device resource model.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 01/41] drivers: tty: serial: dz: use dev_err() instead of printk()
From: Enrico Weigelt, metux IT consult @ 2019-04-29 7:23 UTC (permalink / raw)
To: Greg KH, Enrico Weigelt, metux IT consult
Cc: linux-kernel, andrew, andriy.shevchenko, macro, vz, slemieux.tyco,
khilman, liviu.dudau, sudeep.holla, lorenzo.pieralisi, davem,
jacmet, linux, matthias.bgg, linux-mips, linux-serial, linux-ia64,
linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <20190427133117.GC11368@kroah.com>
On 27.04.19 15:31, Greg KH wrote:
> On Sat, Apr 27, 2019 at 02:51:42PM +0200, Enrico Weigelt, metux IT consult wrote:
>> Using dev_err() instead of printk() for more consistent output.
>> (prints device name, etc).
>>
>> Signed-off-by: Enrico Weigelt <info@metux.net>
>> ---
>> drivers/tty/serial/dz.c | 8 ++++----
>
> Do you have this hardware to test any of these changes with?
Unfortunately not :(
Do you happen to know anybody who has ?
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 35/41] drivers: tty: serial: 8250: add mapsize to platform data
From: Esben Haabendal @ 2019-04-29 7:06 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, gregkh, andrew, andriy.shevchenko, macro, vz,
slemieux.tyco, khilman, liviu.dudau, sudeep.holla,
lorenzo.pieralisi, davem, jacmet, linux, matthias.bgg, linux-mips,
linux-serial, linux-ia64, linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <1556369542-13247-36-git-send-email-info@metux.net>
"Enrico Weigelt, metux IT consult" <info@metux.net> writes:
> Adding a mapsize field for the 8250 port platform data struct,
> so we can now set the resource size (eg. *1) and don't need
> funny runtime detections like serial8250_port_size() anymore.
>
> For now, serial8250_port_size() is called everytime we need
> the io resource size. That function checks which chip we
> actually have and returns the appropriate size. This approach
> is a bit clumpsy and not entirely easy to understand, and
> it's a violation of layers :p
>
> Obviously, that information cannot change after the driver init,
> so we can safely do that probing once on driver init and just
> use the stored value later.
>
> *1) arch/mips/alchemy/common/platform.c
>
> Signed-off-by: Enrico Weigelt <info@metux.net>
> ---
> drivers/tty/serial/8250/8250_core.c | 1 +
> include/linux/serial_8250.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
> index e441221..71a398b 100644
> --- a/drivers/tty/serial/8250/8250_core.c
> +++ b/drivers/tty/serial/8250/8250_core.c
> @@ -814,6 +814,7 @@ static int serial8250_probe(struct platform_device *dev)
> uart.port.iotype = p->iotype;
> uart.port.flags = p->flags;
> uart.port.mapbase = p->mapbase;
> + uart.port.mapsize = p->mapsize;
> uart.port.hub6 = p->hub6;
> uart.port.private_data = p->private_data;
> uart.port.type = p->type;
> diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
> index 5a655ba..8b8183a 100644
> --- a/include/linux/serial_8250.h
> +++ b/include/linux/serial_8250.h
> @@ -22,6 +22,7 @@ struct plat_serial8250_port {
> unsigned long iobase; /* io base address */
> void __iomem *membase; /* ioremap cookie or NULL */
> resource_size_t mapbase; /* resource base */
> + resource_size_t mapsize; /* resource size */
> unsigned int irq; /* interrupt number */
> unsigned long irqflags; /* request_irq flags */
> unsigned int uartclk; /* UART clock rate */
Or replace iobase, mapbase and mapsize with a struct resource value?
/Esben
^ permalink raw reply
* Re: [PATCH 40/41] drivers: tty: serial: helper for setting mmio range
From: Esben Haabendal @ 2019-04-29 7:03 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, gregkh, andrew, andriy.shevchenko, macro, vz,
slemieux.tyco, khilman, liviu.dudau, sudeep.holla,
lorenzo.pieralisi, davem, jacmet, linux, matthias.bgg, linux-mips,
linux-serial, linux-ia64, linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <1556369542-13247-41-git-send-email-info@metux.net>
"Enrico Weigelt, metux IT consult" <info@metux.net> writes:
> Introduce a little helpers for settings the mmio range from an
> struct resource or start/len parameters with less code.
> (also setting iotype to UPIO_MEM)
>
> Also converting drivers to use these new helpers as well as
> fetching mapsize field instead of using hardcoded values.
> (the runtime overhead of that should be negligible)
>
> The idea is moving to a consistent scheme, so later common
> calls like request+ioremap combination can be done by generic
> helpers.
Why not simply replace iobase, mapbase and mapsize with a struct
resource value instead?
Incidentally, that would allow to specify a memory resource with a
parent memory resource :)
/Esben
^ permalink raw reply
* Re: [PATCH 40/41] drivers: tty: serial: helper for setting mmio range
From: Esben Haabendal @ 2019-04-29 6:57 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, gregkh, andrew, andriy.shevchenko, macro, vz,
slemieux.tyco, khilman, liviu.dudau, sudeep.holla,
lorenzo.pieralisi, davem, jacmet, linux, matthias.bgg, linux-mips,
linux-serial, linux-ia64, linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <1556369542-13247-41-git-send-email-info@metux.net>
"Enrico Weigelt, metux IT consult" <info@metux.net> writes:
> @@ -131,7 +133,8 @@ int __init hp300_setup_serial_console(void)
> pr_info("Serial console is HP DCA at select code %d\n", scode);
>
> port.uartclk = HPDCA_BAUD_BASE * 16;
> - port.mapbase = (pa + UART_OFFSET);
> +
> + uart_memres_set_start_len(&port, (pa + UART_OFFSET));
Missing length argument here.
> port.membase = (char *)(port.mapbase + DIO_VIRADDRBASE);
> port.regshift = 1;
> port.irq = DIO_IPL(pa + DIO_VIRADDRBASE);
> diff --git a/drivers/tty/serial/xilinx_uartps.c b/drivers/tty/serial/xilinx_uartps.c
> index cf8ca66..895c90c 100644
> --- a/drivers/tty/serial/xilinx_uartps.c
> +++ b/drivers/tty/serial/xilinx_uartps.c
> @@ -1626,8 +1626,7 @@ static int cdns_uart_probe(struct platform_device *pdev)
> * This function also registers this device with the tty layer
> * and triggers invocation of the config_port() entry point.
> */
> - port->mapbase = res->start;
> - port->mapsize = CDNS_UART_REGISTER_SPACE;
> + uart_memres_set_start_len(res->start, CDNS_UART_REGISTER_SPACE);
Missing 1st (port) argument here.
> port->irq = irq;
> port->dev = &pdev->dev;
> port->uartclk = clk_get_rate(cdns_uart_data->uartclk);
> diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
> index 5fe2b03..d891c8d 100644
> --- a/include/linux/serial_core.h
> +++ b/include/linux/serial_core.h
> @@ -427,6 +427,46 @@ void uart_console_write(struct uart_port *port, const char *s,
> int uart_match_port(struct uart_port *port1, struct uart_port *port2);
>
> /*
> + * set physical io range from struct resource
> + * if resource is NULL, clear the fields
> + * also set the iotype to UPIO_MEM
> + */
> +static inline void uart_memres_set_res(struct uart_port *port,
> + struct resource *res)
> +{
> + if (!res) {
> + port->mapsize = 0;
> + port->mapbase = 0;
> + port->iobase = 0;
> + return;
> + }
> +
> + if (resource_type(res) == IORESOURCE_IO) {
> + port->iotype = UPIO_PORT;
> + port->iobase = resource->start;
> + return;
> + }
> +
> + uart->mapbase = res->start;
> + uart->mapsize = resource_size(res);
> + uart->iotype = UPIO_MEM;
Hardcoding UPIO_MEM like does not work for drivers using other kind of
memory access, like UPIO_MEM16, UPIO_MEM32 and UPIO_MEM32BE.
Why not leave the control of iotype to drivers as before this patch?
> +}
> +
> +/*
> + * set physical io range by start address and length
> + * if resource is NULL, clear the fields
> + * also set the iotype to UPIO_MEM
> + */
> +static inline void uart_memres_set_start_len(struct uart_driver *uart,
> + resource_size_t start,
> + resource_size_t len)
> +{
> + uart->mapbase = start;
> + uart->mapsize = len;
> + uart->iotype = UPIO_MEM;
Same here, other iotype values must be possible.
> +}
> +
> +/*
> * Power Management
> */
> int uart_suspend_port(struct uart_driver *reg, struct uart_port *port);
/Esben
^ permalink raw reply
* Re: [PATCH 37/41] drivers: tty: serial: 8250: simplify io resource size computation
From: Enrico Weigelt, metux IT consult @ 2019-04-29 6:48 UTC (permalink / raw)
To: Andy Shevchenko, Enrico Weigelt, metux IT consult
Cc: linux-kernel, gregkh, andrew, macro, vz, slemieux.tyco, khilman,
liviu.dudau, sudeep.holla, lorenzo.pieralisi, davem, jacmet,
linux, matthias.bgg, linux-mips, linux-serial, linux-ia64,
linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <20190428152103.GP9224@smile.fi.intel.com>
On 28.04.19 17:21, Andy Shevchenko wrote:
>
>> +#define SERIAL_RT2880_IOSIZE 0x100
>
> And why this is in the header file and not in corresponding C one?
hmm, no particular reason, maybe just an old habit to put definitions
into .h files ;-)
I can move it to 8250_of.c if you like me to.
--mtx
--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287
^ permalink raw reply
* Re: [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF
From: Esben Haabendal @ 2019-04-29 6:37 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: Andy Shevchenko, linux-serial, Greg Kroah-Hartman, Jiri Slaby,
Darwin Dingel, He Zhe, Jisheng Zhang, Sebastian Andrzej Siewior,
linux-kernel
In-Reply-To: <7a1fd6cc-050f-a077-6169-03552a89c563@metux.net>
"Enrico Weigelt, metux IT consult" <lkml@metux.net> writes:
> On 27.04.19 10:58, Esben Haabendal wrote:
>
> Hi folks,
>
>> That said, the purpose of UPF_BOOT_AUTOCONF (for 8250 driver) is to
>> request and map the register memory. So when that is already done by
>> the parent MFD driver, I think it is silly to workaround problems
>> caused by UPF_BOOT_AUTOCONF being force setted, when it really
>> shouldn't.
> I tend to agree. Maybe we should give serial8250_register_8250_port()
> some flags for controlling this, or add another function for those
> cases.
Changing serial8250_register_8250_port() would break existing drivers,
as I have seen that some explicitly rely on the automtic addition of
UPF_BOOT_AUTOCONF.
> A minimal-invasive approach could be introducing an
> serial8250_register_8250_port_ext() with extra parameters, and let
> serial8250_register_8250_port() just call it.
So basically a rename of __serial8250_register_8250_port() in my patch
to serial8250_register_8250_port_ext()? Fine with me. Should we give
it an EXPORT_SYMBOL() also, as it is just as valid to use in modules as
the current serial8250_register_8250_port()?
/Esben
^ permalink raw reply
* Re: [PATCH 1/2] serial: 8250: Allow port registration without UPF_BOOT_AUTOCONF
From: Esben Haabendal @ 2019-04-29 6:27 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Andy Shevchenko, open list:SERIAL DRIVERS, Greg Kroah-Hartman,
Jiri Slaby, Darwin Dingel, He Zhe, Jisheng Zhang,
Sebastian Andrzej Siewior, Linux Kernel Mailing List
In-Reply-To: <CAHp75VfZMuQ3xagGSt6dXv1tZbSfanUdaw0SgjTqq3YET5YBKQ@mail.gmail.com>
Andy Shevchenko <andy.shevchenko@gmail.com> writes:
> On Sat, Apr 27, 2019 at 12:01 PM Esben Haabendal <esben@haabendal.dk> wrote:
>> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
>> > On Fri, Apr 26, 2019 at 06:54:05PM +0200, Esben Haabendal wrote:
>> >> Andy Shevchenko <andriy.shevchenko@linux.intel.com> writes:
>> >> The reason for this patch is to be able to do exactly that (set port
>> >> type and UPF_FIXED_TYPE) without having UPF_BOOT_AUTOCONF added.
>> >>
>> >> In the current serial8250_register_8250_port() there is:
>> >>
>> >> uart->port.flags = up->port.flags | UPF_BOOT_AUTOCONF;
>> >>
>> >> So, even though I set UPF_FIXED_TYPE, I get
>> >> UPF_FIXED_TYPE|UPF_BOOT_AUTOCONF.
>> >
>> > Yes.
>> >
>> >> So I need this patch.
>> >
>> > Why? I don't see any problems to have these flags set.
>>
>> The problem with having UPF_BOOT_AUTOCONF is the call to
>> serial8250_request_std_resource(). It calls request_mem_region(), which
>> fails if the MFD driver already have requested the memory region for the
>> MFD device.
>
> If it's MFD, why it requested the region for its child?
> Isn't it a bug in MFD driver?
It is a PCI driver, which calls pci_request_regions(). The PCI device
carries a lot of different functions, which uses small slices of the PCI
memory region(s). With the resources being a tree structure, I don't
think it is a bug when a parent driver requests the entire memory
region.
It would be nice if child drivers requesting memory would pass the
parent memory resource. Maybe 8250 driver could be changed to accept a
struct resource pointer instead of a simple mapbase value, allowing to
setup the resource with parent pointing to the MFD memory resource.
/Esben
^ permalink raw reply
* Re: [PATCH 1/2] serial: 8250-mtk: add follow control
From: Sean Wang @ 2019-04-28 17:40 UTC (permalink / raw)
To: Long Cheng
Cc: Greg Kroah-Hartman, Zhenbao Liu, Peter Shih, srv_heupstream,
Gustavo A. R. Silva, Changqi Hu, linux-kernel, linux-mediatek,
linux-serial, Jiri Slaby, Matthias Brugger, Yingjoe Chen,
linux-arm-kernel
In-Reply-To: <1556181691-10293-2-git-send-email-long.cheng@mediatek.com>
Hi, Long
I guess you should mean "flow control", not "follow control".
And the commit subject should be swapped between 1/2 and 2/2,
otherwise, the subject is inconsistent with its own content.
Sean
On Thu, Apr 25, 2019 at 1:41 AM Long Cheng <long.cheng@mediatek.com> wrote:
>
> Add SW and HW follow control function.
>
> Signed-off-by: Long Cheng <long.cheng@mediatek.com>
> ---
> drivers/tty/serial/8250/8250_mtk.c | 60 ++++++++++++++++++++++--------------
> 1 file changed, 37 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/tty/serial/8250/8250_mtk.c b/drivers/tty/serial/8250/8250_mtk.c
> index c1fdbc0..959fd85 100644
> --- a/drivers/tty/serial/8250/8250_mtk.c
> +++ b/drivers/tty/serial/8250/8250_mtk.c
> @@ -21,12 +21,14 @@
>
> #include "8250.h"
>
> -#define UART_MTK_HIGHS 0x09 /* Highspeed register */
> -#define UART_MTK_SAMPLE_COUNT 0x0a /* Sample count register */
> -#define UART_MTK_SAMPLE_POINT 0x0b /* Sample point register */
> +#define MTK_UART_HIGHS 0x09 /* Highspeed register */
> +#define MTK_UART_SAMPLE_COUNT 0x0a /* Sample count register */
> +#define MTK_UART_SAMPLE_POINT 0x0b /* Sample point register */
> #define MTK_UART_RATE_FIX 0x0d /* UART Rate Fix Register */
> -
> #define MTK_UART_DMA_EN 0x13 /* DMA Enable register */
> +#define MTK_UART_RXTRI_AD 0x14 /* RX Trigger address */
> +#define MTK_UART_FRACDIV_L 0x15 /* Fractional divider LSB address */
> +#define MTK_UART_FRACDIV_M 0x16 /* Fractional divider MSB address */
> #define MTK_UART_DMA_EN_TX 0x2
> #define MTK_UART_DMA_EN_RX 0x5
>
> @@ -46,6 +48,7 @@ enum dma_rx_status {
> struct mtk8250_data {
> int line;
> unsigned int rx_pos;
> + unsigned int clk_count;
> struct clk *uart_clk;
> struct clk *bus_clk;
> struct uart_8250_dma *dma;
> @@ -196,9 +199,15 @@ static void mtk8250_shutdown(struct uart_port *port)
> mtk8250_set_termios(struct uart_port *port, struct ktermios *termios,
> struct ktermios *old)
> {
> + unsigned short fraction_L_mapping[] = {
> + 0, 1, 0x5, 0x15, 0x55, 0x57, 0x57, 0x77, 0x7F, 0xFF, 0xFF
> + };
> + unsigned short fraction_M_mapping[] = {
> + 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 3
> + };
> struct uart_8250_port *up = up_to_u8250p(port);
> + unsigned int baud, quot, fraction;
> unsigned long flags;
> - unsigned int baud, quot;
>
> #ifdef CONFIG_SERIAL_8250_DMA
> if (up->dma) {
> @@ -214,7 +223,7 @@ static void mtk8250_shutdown(struct uart_port *port)
> serial8250_do_set_termios(port, termios, old);
>
> /*
> - * Mediatek UARTs use an extra highspeed register (UART_MTK_HIGHS)
> + * Mediatek UARTs use an extra highspeed register (MTK_UART_HIGHS)
> *
> * We need to recalcualte the quot register, as the claculation depends
> * on the vaule in the highspeed register.
> @@ -230,18 +239,11 @@ static void mtk8250_shutdown(struct uart_port *port)
> port->uartclk / 16 / UART_DIV_MAX,
> port->uartclk);
>
> - if (baud <= 115200) {
> - serial_port_out(port, UART_MTK_HIGHS, 0x0);
> + if (baud < 115200) {
> + serial_port_out(port, MTK_UART_HIGHS, 0x0);
> quot = uart_get_divisor(port, baud);
> - } else if (baud <= 576000) {
> - serial_port_out(port, UART_MTK_HIGHS, 0x2);
> -
> - /* Set to next lower baudrate supported */
> - if ((baud == 500000) || (baud == 576000))
> - baud = 460800;
> - quot = DIV_ROUND_UP(port->uartclk, 4 * baud);
> } else {
> - serial_port_out(port, UART_MTK_HIGHS, 0x3);
> + serial_port_out(port, MTK_UART_HIGHS, 0x3);
> quot = DIV_ROUND_UP(port->uartclk, 256 * baud);
> }
>
> @@ -258,17 +260,29 @@ static void mtk8250_shutdown(struct uart_port *port)
> /* reset DLAB */
> serial_port_out(port, UART_LCR, up->lcr);
>
> - if (baud > 460800) {
> + if (baud >= 115200) {
> unsigned int tmp;
>
> - tmp = DIV_ROUND_CLOSEST(port->uartclk, quot * baud);
> - serial_port_out(port, UART_MTK_SAMPLE_COUNT, tmp - 1);
> - serial_port_out(port, UART_MTK_SAMPLE_POINT,
> - (tmp - 2) >> 1);
> + tmp = (port->uartclk / (baud * quot)) - 1;
> + serial_port_out(port, MTK_UART_SAMPLE_COUNT, tmp);
> + serial_port_out(port, MTK_UART_SAMPLE_POINT,
> + (tmp >> 1) - 1);
> +
> + /*count fraction to set fractoin register */
> + fraction = ((port->uartclk * 100) / baud / quot) % 100;
> + fraction = DIV_ROUND_CLOSEST(fraction, 10);
> + serial_port_out(port, MTK_UART_FRACDIV_L,
> + fraction_L_mapping[fraction]);
> + serial_port_out(port, MTK_UART_FRACDIV_M,
> + fraction_M_mapping[fraction]);
> } else {
> - serial_port_out(port, UART_MTK_SAMPLE_COUNT, 0x00);
> - serial_port_out(port, UART_MTK_SAMPLE_POINT, 0xff);
> + serial_port_out(port, MTK_UART_SAMPLE_COUNT, 0x00);
> + serial_port_out(port, MTK_UART_SAMPLE_POINT, 0xff);
> + serial_port_out(port, MTK_UART_FRACDIV_L, 0x00);
> + serial_port_out(port, MTK_UART_FRACDIV_M, 0x00);
> }
> + if (uart_console(port))
> + up->port.cons->cflag = termios->c_cflag;
>
> spin_unlock_irqrestore(&port->lock, flags);
> /* Don't rewrite B0 */
> --
> 1.7.9.5
>
>
> _______________________________________________
> Linux-mediatek mailing list
> Linux-mediatek@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH 40/41] drivers: tty: serial: helper for setting mmio range
From: Andy Shevchenko @ 2019-04-28 15:39 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, gregkh, andrew, macro, vz, slemieux.tyco, khilman,
liviu.dudau, sudeep.holla, lorenzo.pieralisi, davem, jacmet,
linux, matthias.bgg, linux-mips, linux-serial, linux-ia64,
linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <1556369542-13247-41-git-send-email-info@metux.net>
On Sat, Apr 27, 2019 at 02:52:21PM +0200, Enrico Weigelt, metux IT consult wrote:
> Introduce a little helpers for settings the mmio range from an
> struct resource or start/len parameters with less code.
> (also setting iotype to UPIO_MEM)
>
> Also converting drivers to use these new helpers as well as
> fetching mapsize field instead of using hardcoded values.
> (the runtime overhead of that should be negligible)
>
> The idea is moving to a consistent scheme, so later common
> calls like request+ioremap combination can be done by generic
> helpers.
> --- a/drivers/tty/serial/8250/8250_exar.c
> +++ b/drivers/tty/serial/8250/8250_exar.c
> @@ -134,8 +134,10 @@ static int default_setup(struct exar8250 *priv, struct pci_dev *pcidev,
> const struct exar8250_board *board = priv->board;
> unsigned int bar = 0;
>
> - port->port.iotype = UPIO_MEM;
> - port->port.mapbase = pci_resource_start(pcidev, bar) + offset;
> + uart_memres_set_start_len(&port->port,
> + pci_resource_start(pcidev, bar) + offset,
> + pci_resource_len(pcidev, bar));
> +
I don't see how it's better.
Moreover, the size argument seems wrong here.
> + uart_memres_set_start_len(
> + &port,
> + FRODO_BASE + FRODO_APCI_OFFSET(1), 0);
Please, avoid such splitting, first parameter is quite fit above line.
> port.uartclk = HPDCA_BAUD_BASE * 16;
> - port.mapbase = (pa + UART_OFFSET);
> +
> + uart_memres_set_start_len(&port, (pa + UART_OFFSET));
> port.membase = (char *)(port.mapbase + DIO_VIRADDRBASE);
> port.regshift = 1;
> port.irq = DIO_IPL(pa + DIO_VIRADDRBASE);
Here...
> uart.port.flags = UPF_SKIP_TEST | UPF_SHARE_IRQ | UPF_BOOT_AUTOCONF;
> uart.port.irq = d->ipl;
> uart.port.uartclk = HPDCA_BAUD_BASE * 16;
> - uart.port.mapbase = (d->resource.start + UART_OFFSET);
> + uart_memres_set_start_len(&uart.port,
> + (d->resource.start + UART_OFFSET),
> + resource_size(&d->resource));
> uart.port.membase = (char *)(uart.port.mapbase + DIO_VIRADDRBASE);
> uart.port.regshift = 1;
> uart.port.dev = &d->dev;
...and here, and maybe in other places you split the assignments to the members
in two part. Better to call your function before or after these blocks of
assignments.
> - uport->mapsize = ZS_CHAN_IO_SIZE;
> - uport->mapbase = dec_kn_slot_base +
> - zs_parms.scc[chip] +
> - (side ^ ZS_CHAN_B) * ZS_CHAN_IO_SIZE;
> +
> + uart_memres_set_start_len(dec_kn_slot_base +
> + zs_parms.scc[chip] +
> + (side ^ ZS_CHAN_B) *
> + ZS_CHAN_IO_SIZE,
> + ZS_CHAN_IO_SIZE);
This looks hard to read. Think of temporary variables and better formatting
style.
> /*
> + * set physical io range from struct resource
> + * if resource is NULL, clear the fields
> + * also set the iotype to UPIO_MEM
Something wrong with punctuation and style. Please, use proper casing and
sentences split.
> + */
Shouldn't be kernel-doc formatted?
> +static inline void uart_memres_set_res(struct uart_port *port,
Perhaps better name can be found.
Especially taking into account that it handles IO / MMIO here.
> + struct resource *res)
> +{
> + if (!res) {
It should return an error in such case.
> + port->mapsize = 0;
> + port->mapbase = 0;
> + port->iobase = 0;
> + return;
> + }
> +
> + if (resource_type(res) == IORESOURCE_IO) {
> + port->iotype = UPIO_PORT;
> + port->iobase = resource->start;
> + return;
> + }
> +
> + uart->mapbase = res->start;
> + uart->mapsize = resource_size(res);
> + uart->iotype = UPIO_MEM;
Only one type? Why type is even set here?
> +}
> +
> +/*
> + * set physical io range by start address and length
> + * if resource is NULL, clear the fields
> + * also set the iotype to UPIO_MEM
Should be fixed as told above.
> + */
> +static inline void uart_memres_set_start_len(struct uart_driver *uart,
> + resource_size_t start,
> + resource_size_t len)
The comment doesn't tell why this is needed when we have one for struct
resource.
> +{
> + uart->mapbase = start;
> + uart->mapsize = len;
> + uart->iotype = UPIO_MEM;
Only one type?
> +}
> +
> +/*
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 37/41] drivers: tty: serial: 8250: simplify io resource size computation
From: Andy Shevchenko @ 2019-04-28 15:21 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, gregkh, andrew, macro, vz, slemieux.tyco, khilman,
liviu.dudau, sudeep.holla, lorenzo.pieralisi, davem, jacmet,
linux, matthias.bgg, linux-mips, linux-serial, linux-ia64,
linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <1556369542-13247-38-git-send-email-info@metux.net>
On Sat, Apr 27, 2019 at 02:52:18PM +0200, Enrico Weigelt, metux IT consult wrote:
> Simpily io resource size computation by setting mapsize field.
>
> Some of the special cases handled by serial8250_port_size() can be
> simplified by putting this data to corresponding platform data
> or probe function.
> --- a/drivers/tty/serial/8250/8250.h
> +++ b/drivers/tty/serial/8250/8250.h
> @@ -105,6 +105,7 @@ struct serial8250_config {
>
> #define SERIAL8250_PORT(_base, _irq) SERIAL8250_PORT_FLAGS(_base, _irq, 0)
>
> +#define SERIAL_RT2880_IOSIZE 0x100
And why this is in the header file and not in corresponding C one?
> diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c
> index d09af4c..51d6076 100644
> --- a/drivers/tty/serial/8250/8250_port.c
> +++ b/drivers/tty/serial/8250/8250_port.c
> @@ -2833,11 +2833,7 @@ unsigned int serial8250_port_size(struct uart_8250_port *pt)
> {
> if (pt->port.mapsize)
> return pt->port.mapsize;
> - if (pt->port.iotype == UPIO_AU) {
> - if (pt->port.type == PORT_RT2880)
> - return 0x100;
> - return 0x1000;
> - }
> +
> if (is_omap1_8250(pt))
> return 0x16 << pt->port.regshift;
This is good. We definitely need to get rid of custom stuff in generic
8250_port, etc.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 36/41] drivers: tty: serial: 8250: store mmio resource size in port struct
From: Andy Shevchenko @ 2019-04-28 15:18 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, gregkh, andrew, macro, vz, slemieux.tyco, khilman,
liviu.dudau, sudeep.holla, lorenzo.pieralisi, davem, jacmet,
linux, matthias.bgg, linux-mips, linux-serial, linux-ia64,
linux-amlogic, linuxppc-dev, sparclinux
In-Reply-To: <1556369542-13247-37-git-send-email-info@metux.net>
On Sat, Apr 27, 2019 at 02:52:17PM +0200, Enrico Weigelt, metux IT consult wrote:
> The io resource size is currently recomputed when it's needed but this
> actually needs to be done once (or drivers could specify fixed values)
io -> IO
>
> Simplify that by doing this computation only once and storing the result
> into the mapsize field. serial8250_register_8250_port() is now called
> only once on driver init, the previous call sites now just fetch the
> value from the mapsize field.
Do I understand correctly that this has no side effects?
Which hardware did you test this on?
> @@ -979,6 +979,9 @@ int serial8250_register_8250_port(struct uart_8250_port *up)
> if (up->port.uartclk == 0)
> return -EINVAL;
>
> + /* compute the mapsize in case the driver didn't specify one */
> + up->mapsize = serial8250_port_size(up);
I don't know all quirks in 8250 drivers by heart, though can you guarantee that
at this point the device reports correct IO resource size? (If I'm not mistaken
some broken hardware needs some magic to be done before card can be properly
handled)
> - unsigned int size = serial8250_port_size(up);
> struct uart_port *port = &up->port;
> - int ret = 0;
This and Co is a separate change that can be done in its own patch.
> + port->membase = ioremap_nocache(port->mapbase,
> + port->mapsize);
You may increase readability by introducing temporary variables
... mapbase = port->mapbase;
... mapsize = port->mapsize;
...
port->membase = ioremap_nocache(mapbase, mapsize);
...
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox