-
Notifications
You must be signed in to change notification settings - Fork 8.3k
drivers: adc: microchip: Different channels per package type #80933
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
093f95c to
7e1d8c7
Compare
scottwcpg
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please remove all MEC174x and MEC175x stuff from this PR.
These two code bases cannot be mixed together due to Google rejecting the use of HAL's.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NO. Please DO NOT add MEC1743 and MEC1753 to this code!
MEC174x, MEC175x, and all future chips will be based on a the new MEC5 HAL and will NOT EVER use the old MEC172x drivers.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is there some documentation regarding the 'MEC5 HAL' and it's use cases or restrictions/limits? I will update the PR, but i'd like it if there was some guidance i could follow (other than 'ignore MEC17[45]x for MEC150x/MEC172x driver updates')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The new MEC5 HAL is a work in progress.
The HAL was created due to the request of yet another large customer. The original goal for MEC5 HAL were all chips after MEC172x. Since the customer demanded no direct HW register access in the drivers we can't use the current MEC172x drivers. This meant new SoC, boards, drivers, etc as if MEC5 are completely different chips. Unfortunately, said customer came back and demanded MEC172x be added to MEC5 HAL. It is a huge mess with no good solution so the rule is:
MEC152x uses old header files from hal_microchip/mec folder
MEC172x does not use any header/code from hal_microchip due to Google chromebook Zephyr requirement.
MEC174x, MEC175x, and hopefully all future chips will use hal_microchip/mec5 headers and peripheral C code.
MEC174x, MEC175x require new SoC, DTS, board, and drivers.
Their are only a new select header files that may be shared: the GPIO dt-bindings and PINCTRL dt-bindings. Anything else is not shared because we don't want to break legacy MEC172x.
No one is happy about it.
7e1d8c7 to
201837a
Compare
LJ packages have 16 ADC channels vs 8 for SZ packages. Enhance devicetree to account for this as well as conditional defines/code. Signed-off-by: Jeff Daly <[email protected]>
201837a to
c5ed284
Compare
|
ping. is this to be merged? |
|
Hi @jjdalynh , Can you confirm this PR has been tested on both the LJ and SZ packages? |
|
We are seeing exception on SZ package, in the adc_xec_init function when the config register is accessed. The code is accessing offset 0x5C for the config register when actually the config register is at 0x7C offset. Can you create a PR to fix this? |
|
This issue was pointed out when the changes where done initially here |
|
Will do. I'll have to go see what part number I have on my dev board, but on my production board I only have LJ parts.
I'll apply the fix that was proposed before.
From: jvasanth1 ***@***.***>
Sent: Thursday, December 19, 2024 12:56 PM
To: zephyrproject-rtos/zephyr ***@***.***>
Cc: Jeff Daly ***@***.***>; Mention ***@***.***>
Subject: Re: [zephyrproject-rtos/zephyr] drivers: adc: microchip: Different channels per package type (PR #80933)
Caution: This is an external email. Please take care when clicking links or opening attachments.
We are seeing exception on SZ package, in the adc_xec_init function when the config register is accessed. The code is accessing offset 0x5C for the config register when actually the config register is at 0x7C offset.
Can you create a PR to fix this?
-
Reply to this email directly, view it on GitHub<#80933 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ASDWUUDMKEYCJHPM3KI3RV32GMCCPAVCNFSM6AAAAABRG5GZRKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJVGQYTONZSGA>.
You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>
|
Fixed bug calculating offset of registers after unused space in the ADC register space for the SZ package parts. Signed-off-by: Jeff Daly <[email protected]>
Fixed bug calculating offset of registers after unused space in the ADC register space for the SZ package parts. Signed-off-by: Jeff Daly <[email protected]>
Fixed bug calculating offset of registers after unused space in the ADC register space for the SZ package parts. Signed-off-by: Jeff Daly <[email protected]>
Fixed bug calculating offset of registers after unused space in the ADC register space for the SZ package parts. Signed-off-by: Jeff Daly <[email protected]>

LJ packages have 16 ADC channels vs 8 for SZ packages. Enhance devicetree to account for this as well as conditional defines/code.