Re: [PATCH v1 0/2] serial: 8250_pci: Split Pericom driver

On 11/21/21 2:16 AM, Andy Shevchenko wrote:

On Sat, Nov 20, 2021 at 11:46 PM Jay Dolan [off-list ref] wrote:

quoted

On 11/19/21 6:33 AM, Jay Dolan wrote:

quoted

On 11/19/21 12:23 AM, Andy Shevchenko wrote:

quoted

On Thu, Nov 18, 2021 at 10:32:51PM -0800, Jay Dolan wrote:

quoted

On 11/17/21 6:57 AM, Andy Shevchenko wrote:

quoted

quoted

quoted

quoted

quoted

Split Pericom driver to a separate module.
While at it, re-enable high baud rates.

Jay, can you, please, test this on as many hardware as you have?

The series depends on the fix-series:
https://lore.kernel.org/linux-serial/20211117145502.43645-1-andriy.shevchenko@linux.intel.com/T/#u (local)

quoted

I have my current state here:
https://github.com/accesio/linux/blob/split-pericom-driver/drivers/tty/serial/8250/8250_pericom.c


* Change port type to UPIO_PORT
* Add in pericom_do_startup() because the UPF_MAGIC_MULTIPLIER doesn't
stick.

Thanks, I have updated my local tree with these changes.

quoted

When I'm testing baud rates greater than baud_base I'm seeing strange
things
on the scope.

Can you confirm that there are no issues with the first (fixes) series?

Yes. The fixes series has no issues, and was tested up to baud_base for
both 14 and 24 MHz crystals.

quoted

I have slightly changed your set_divisor() refactoring, it may be that
issue
is there.

quoted

Maybe I'm just tired, and it's human error. I should be able
to get back to it and get it done on Saturday.

Thank you.

Latest code is still here
https://github.com/accesio/linux/blob/split-pericom-driver/drivers/tty/serial/8250/8250_pericom.c

Changes from last update:
* Avoid divide by zero when initializing delta

Thanks for digging into it. But doesn't it mean that the issue is in
the fix series as I assumed before?

Yes. It just happens to not get hit at any of the standard baud rates 
that I found in the termbits.h files. So testing didn't find it until 
testing rates greater than what is allowed without the magic multiplier 
flag.
I found it when doing the math on 3000000 because that causes it with 
the 14 MHz crystal.

quoted

I retested and verified on the scope that speeds are now being set
correctly.

I have also confirmed that all of the ACCES four port cards in the
driver do have the offset fourth port. The item I raised about PCI was a
misunderstanding that was all on my end.

Good to know that is not relevant.

quoted

Are there any other action items I should be handling?

I think I have to issue two new iterations of each series and collect
your formal Tested-by on the second one.