[PATCH linux dev-4.10] ARM: dts: aspeed: gpio controller register range
Patrick Venture
venture at google.com
Sat Dec 9 04:10:32 AEDT 2017
Thanks for the feedback. I'm still working on getting a few kinks
worked out in the driver, for instance, verifying that waiting on the
rising edge for the J1 gpio (on the ast2400) is required for stable
writing -- which has been true. We were actually seeing the serial
gpios wedge to a specific value on the quanta-q71l board, but having
it wait on that prevents this case... so more work is going into
verifying behaviors and caveats. I'm without a motherboard that has
serial gpios and the ast2500 for testing...
Thanks,
Patrick
On Thu, Dec 7, 2017 at 10:30 PM, Joel Stanley <joel at jms.id.au> wrote:
> On Fri, Dec 1, 2017 at 2:05 AM, Patrick Venture <venture at google.com> wrote:
>> On Wed, Nov 29, 2017 at 7:53 PM, Joel Stanley <joel at jms.id.au> wrote:
>>> On Thu, Nov 30, 2017 at 5:03 AM, Patrick Venture <venture at google.com> wrote:
>>>> Can I get a status on this patch? The device datasheet has 4K
>>>> reserved for the range, but only the first 512 are registers
>>>> controlled by this driver. The rest will be handled by a separate
>>>> driver. Or at least that's how it's planned.
>>>
>>> +cc the people who have worked on this.
>>>
>>> I think that's okay, but lets see what the others have to say.
>>>
>>> Do you have a driver for the rest of the GPIOs you can submit? I'd
>>> like to see that code so we can decide if there is good reason to
>>> make that completely separate, and not part of the existing driver.
>>>
>>> This work is best done upstream, as you will need to make the same
>>> arguments there.
>>
>> I should have a driver ready sometime late next week that I'll be
>> sending upstream first. I still need to finish up a few loose ends on
>> it. It wouldn't be unreasonable to have them in the same driver,
>> you'd just end up with two groups of gpios that are handled
>> differently, and extra soft-irqs. That said, if you have two large
>> groups of things that need to be treated differently, then that's
>> somewhat of an argument for having them separate. :)
>>
>> I'd actually appreciate hearing some thoughts at this point on which
>> way to go, since merging the serial handling into the main driver will
>> require re-working a few things -- I'd rather take the extra time to
>> handle that merge if it's going to head in that direction anyway.
>>
>> I have read through the gpio-aspeed driver before, as it was a bit
>> useful as a guide, and I could see it getting a bit cluttered with
>> also handling the serial gpios.
>
> It sounds like a call that could go either way. If you think it would
> be easier to maintain two separate drivers then we can go that
> direction.
>
> I'd suggest discussing it upstream.
>
> The best way to discuss it would be in the form of a patch. Even if
> it's not complete, post it as a RFC.
>
> Cheers,
>
> Joel
More information about the openbmc
mailing list