Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
Hi Peter, > On Feb 23, 2015, at 20:39 , Peter Hurley wrote: > > Hi Pantelis, > > On 02/19/2015 01:44 PM, Pantelis Antoniou wrote: >> Hi Tony, >> >>> On Feb 19, 2015, at 20:36 , Tony Lindgren wrote: >>> >>> * Pantelis Antoniou [150219 10:32]: > On Feb 19, 2015, at 20:16 , Tony Lindgren wrote: > > Uhh I don't like the idea of duplicating the i2c-omap.c driver under > arch/arm.. And in general we should initialize things later rather > than earlier. > > What's stopping doing these quirk checks later on time with just > a regular device driver, something like drivers/misc/bbone-quirks.c? > We have no choice; we are way early in the boot process, right after the device tree unflattening step. >>> >>> To me it seems the dt patching part should be done with minimal >>> code before any driver like features.. >>> >> >> The way it’s done right now is with minimal code. Reading the EEPROM >> is required. >> I’ve toyed with the idea of using early platform devices but the omap-i2c driver would need some tender love and care to make it work, and I didn’t want to get bogged down with i2c driver details at this point. >>> >>> ..so how about just parse a kernel cmdline for the quirks to apply >>> based on a version string or similar? That can be easily populated >>> by u-boot or set manually with setenv. >>> >>> That leaves out the need for tinkering with i2c super early in >>> the kernel for revision detection. >>> >> >> You assume there’s going to be a bootloader… > > So does this patch. > Proof of concept, first iteration… The beaglebone is just the prototype stage. >> diff --git a/arch/arm/mach-omap2/am33xx-dt-quirks.c >> b/arch/arm/mach-omap2/am33xx-dt-quirks.c > [...] >> + * Note that we rely on the bootloader setting up the muxes >> + * (which is the case for u-boot). > > Regards, > Peter Hurley > Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
Hi Pantelis, On 02/19/2015 01:44 PM, Pantelis Antoniou wrote: > Hi Tony, > >> On Feb 19, 2015, at 20:36 , Tony Lindgren wrote: >> >> * Pantelis Antoniou [150219 10:32]: On Feb 19, 2015, at 20:16 , Tony Lindgren wrote: Uhh I don't like the idea of duplicating the i2c-omap.c driver under arch/arm.. And in general we should initialize things later rather than earlier. What's stopping doing these quirk checks later on time with just a regular device driver, something like drivers/misc/bbone-quirks.c? >>> >>> We have no choice; we are way early in the boot process, right after >>> the device tree unflattening step. >> >> To me it seems the dt patching part should be done with minimal >> code before any driver like features.. >> > > The way it’s done right now is with minimal code. Reading the EEPROM > is required. > >>> I’ve toyed with the idea of using early platform devices but the omap-i2c >>> driver >>> would need some tender love and care to make it work, and I didn’t want to >>> get >>> bogged down with i2c driver details at this point. >> >> ..so how about just parse a kernel cmdline for the quirks to apply >> based on a version string or similar? That can be easily populated >> by u-boot or set manually with setenv. >> >> That leaves out the need for tinkering with i2c super early in >> the kernel for revision detection. >> > > You assume there’s going to be a bootloader… So does this patch. > diff --git a/arch/arm/mach-omap2/am33xx-dt-quirks.c > b/arch/arm/mach-omap2/am33xx-dt-quirks.c [...] > + * Note that we rely on the bootloader setting up the muxes > + * (which is the case for u-boot). Regards, Peter Hurley -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
Hi Pantelis, On 02/19/2015 01:44 PM, Pantelis Antoniou wrote: Hi Tony, On Feb 19, 2015, at 20:36 , Tony Lindgren t...@atomide.com wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [150219 10:32]: On Feb 19, 2015, at 20:16 , Tony Lindgren t...@atomide.com wrote: Uhh I don't like the idea of duplicating the i2c-omap.c driver under arch/arm.. And in general we should initialize things later rather than earlier. What's stopping doing these quirk checks later on time with just a regular device driver, something like drivers/misc/bbone-quirks.c? We have no choice; we are way early in the boot process, right after the device tree unflattening step. To me it seems the dt patching part should be done with minimal code before any driver like features.. The way it’s done right now is with minimal code. Reading the EEPROM is required. I’ve toyed with the idea of using early platform devices but the omap-i2c driver would need some tender love and care to make it work, and I didn’t want to get bogged down with i2c driver details at this point. ..so how about just parse a kernel cmdline for the quirks to apply based on a version string or similar? That can be easily populated by u-boot or set manually with setenv. That leaves out the need for tinkering with i2c super early in the kernel for revision detection. You assume there’s going to be a bootloader… So does this patch. diff --git a/arch/arm/mach-omap2/am33xx-dt-quirks.c b/arch/arm/mach-omap2/am33xx-dt-quirks.c [...] + * Note that we rely on the bootloader setting up the muxes + * (which is the case for u-boot). Regards, Peter Hurley -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
Hi Peter, On Feb 23, 2015, at 20:39 , Peter Hurley pe...@hurleysoftware.com wrote: Hi Pantelis, On 02/19/2015 01:44 PM, Pantelis Antoniou wrote: Hi Tony, On Feb 19, 2015, at 20:36 , Tony Lindgren t...@atomide.com wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [150219 10:32]: On Feb 19, 2015, at 20:16 , Tony Lindgren t...@atomide.com wrote: Uhh I don't like the idea of duplicating the i2c-omap.c driver under arch/arm.. And in general we should initialize things later rather than earlier. What's stopping doing these quirk checks later on time with just a regular device driver, something like drivers/misc/bbone-quirks.c? We have no choice; we are way early in the boot process, right after the device tree unflattening step. To me it seems the dt patching part should be done with minimal code before any driver like features.. The way it’s done right now is with minimal code. Reading the EEPROM is required. I’ve toyed with the idea of using early platform devices but the omap-i2c driver would need some tender love and care to make it work, and I didn’t want to get bogged down with i2c driver details at this point. ..so how about just parse a kernel cmdline for the quirks to apply based on a version string or similar? That can be easily populated by u-boot or set manually with setenv. That leaves out the need for tinkering with i2c super early in the kernel for revision detection. You assume there’s going to be a bootloader… So does this patch. Proof of concept, first iteration… The beaglebone is just the prototype stage. diff --git a/arch/arm/mach-omap2/am33xx-dt-quirks.c b/arch/arm/mach-omap2/am33xx-dt-quirks.c [...] + * Note that we rely on the bootloader setting up the muxes + * (which is the case for u-boot). Regards, Peter Hurley Regards — Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
On 02/19/2015 06:28 PM, Pantelis Antoniou wrote: > Hi Tony, > >> On Feb 19, 2015, at 20:16 , Tony Lindgren wrote: >> >> * Pantelis Antoniou [150218 07:03]: >>> Implement DT quirks for the am33xx beaglebone boards. >>> --- /dev/null >>> +++ b/arch/arm/mach-omap2/am33xx-dt-quirks.c >> ... >>> + >>> +/* >>> + * The board IDs for am33xx board are in an I2C EEPROM >>> + * We are very early in the boot process so we have to >>> + * read the EEPROM directly without using the I2C layer. >>> + * >>> + * Note that we rely on the bootloader setting up the muxes >>> + * (which is the case for u-boot). >>> + */ >>> + >>> +/* I2C Status Register (OMAP_I2C_STAT): */ >>> +#define OMAP_I2C_STAT_XDR (1 << 14) /* TX Buffer draining */ >>> +#define OMAP_I2C_STAT_RDR (1 << 13) /* RX Buffer draining */ >>> +#define OMAP_I2C_STAT_BB (1 << 12) /* Bus busy */ >>> +#define OMAP_I2C_STAT_ROVR (1 << 11) /* Receive overrun */ >>> +#define OMAP_I2C_STAT_XUDF (1 << 10) /* Transmit underflow */ >>> +#define OMAP_I2C_STAT_AAS (1 << 9)/* Address as slave */ >>> +#define OMAP_I2C_STAT_BF (1 << 8)/* Bus Free */ >>> +#define OMAP_I2C_STAT_XRDY (1 << 4)/* Transmit data ready */ >>> +#define OMAP_I2C_STAT_RRDY (1 << 3)/* Receive data ready */ >>> +#define OMAP_I2C_STAT_ARDY (1 << 2)/* Register access ready */ >>> +#define OMAP_I2C_STAT_NACK (1 << 1)/* No ack interrupt enable */ >>> +#define OMAP_I2C_STAT_AL (1 << 0)/* Arbitration lost int ena */ >> ... >> >> Uhh I don't like the idea of duplicating the i2c-omap.c driver under >> arch/arm.. And in general we should initialize things later rather >> than earlier. >> >> What's stopping doing these quirk checks later on time with just >> a regular device driver, something like drivers/misc/bbone-quirks.c? >> > > We have no choice; we are way early in the boot process, right after > the device tree unflattening step. Can you elaborate with an example of why not? Why can't the overlay happen at a later stage in the kernel boot as Tony suggests? One thought would be that ideally devices that are dependent on a particular board variant would be disabled in the base DT blob until you know what board you are. However, that assumes that they can be initialised at a later stage in the boot process and may be for some regulators or other devices this is not possible. I know you mentioned some time restrictions for some devices, but I still don't see why it could not happen later. Jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
On 02/19/2015 06:28 PM, Pantelis Antoniou wrote: Hi Tony, On Feb 19, 2015, at 20:16 , Tony Lindgren t...@atomide.com wrote: * Pantelis Antoniou pantelis.anton...@konsulko.com [150218 07:03]: Implement DT quirks for the am33xx beaglebone boards. --- /dev/null +++ b/arch/arm/mach-omap2/am33xx-dt-quirks.c ... + +/* + * The board IDs for am33xx board are in an I2C EEPROM + * We are very early in the boot process so we have to + * read the EEPROM directly without using the I2C layer. + * + * Note that we rely on the bootloader setting up the muxes + * (which is the case for u-boot). + */ + +/* I2C Status Register (OMAP_I2C_STAT): */ +#define OMAP_I2C_STAT_XDR (1 14) /* TX Buffer draining */ +#define OMAP_I2C_STAT_RDR (1 13) /* RX Buffer draining */ +#define OMAP_I2C_STAT_BB (1 12) /* Bus busy */ +#define OMAP_I2C_STAT_ROVR (1 11) /* Receive overrun */ +#define OMAP_I2C_STAT_XUDF (1 10) /* Transmit underflow */ +#define OMAP_I2C_STAT_AAS (1 9)/* Address as slave */ +#define OMAP_I2C_STAT_BF (1 8)/* Bus Free */ +#define OMAP_I2C_STAT_XRDY (1 4)/* Transmit data ready */ +#define OMAP_I2C_STAT_RRDY (1 3)/* Receive data ready */ +#define OMAP_I2C_STAT_ARDY (1 2)/* Register access ready */ +#define OMAP_I2C_STAT_NACK (1 1)/* No ack interrupt enable */ +#define OMAP_I2C_STAT_AL (1 0)/* Arbitration lost int ena */ ... Uhh I don't like the idea of duplicating the i2c-omap.c driver under arch/arm.. And in general we should initialize things later rather than earlier. What's stopping doing these quirk checks later on time with just a regular device driver, something like drivers/misc/bbone-quirks.c? We have no choice; we are way early in the boot process, right after the device tree unflattening step. Can you elaborate with an example of why not? Why can't the overlay happen at a later stage in the kernel boot as Tony suggests? One thought would be that ideally devices that are dependent on a particular board variant would be disabled in the base DT blob until you know what board you are. However, that assumes that they can be initialised at a later stage in the boot process and may be for some regulators or other devices this is not possible. I know you mentioned some time restrictions for some devices, but I still don't see why it could not happen later. Jon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
On Thu, Feb 19, 2015 at 10:36:00AM -0800, Tony Lindgren wrote: > * Pantelis Antoniou [150219 10:32]: > > > On Feb 19, 2015, at 20:16 , Tony Lindgren wrote: > > > > > > Uhh I don't like the idea of duplicating the i2c-omap.c driver under > > > arch/arm.. And in general we should initialize things later rather > > > than earlier. > > > > > > What's stopping doing these quirk checks later on time with just > > > a regular device driver, something like drivers/misc/bbone-quirks.c? > > > > > > > We have no choice; we are way early in the boot process, right after > > the device tree unflattening step. > > To me it seems the dt patching part should be done with minimal > code before any driver like features.. > > > I’ve toyed with the idea of using early platform devices but the omap-i2c > > driver > > would need some tender love and care to make it work, and I didn’t want to > > get > > bogged down with i2c driver details at this point. > > ..so how about just parse a kernel cmdline for the quirks to apply > based on a version string or similar? That can be easily populated > by u-boot or set manually with setenv. > That would not work for my use case. Again, this is a CPU card plugged into a carrier card, of which there are several variants. The CPU card is similar to a Com Express card (not exactly the same, but the same idea), so it may even be manufactured by a third party. Actually, in some cases it is. Modifying the kernel command line based on the carrier card it is connected to is simply not possible. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
Hi Tony, > On Feb 19, 2015, at 20:36 , Tony Lindgren wrote: > > * Pantelis Antoniou [150219 10:32]: >>> On Feb 19, 2015, at 20:16 , Tony Lindgren wrote: >>> >>> Uhh I don't like the idea of duplicating the i2c-omap.c driver under >>> arch/arm.. And in general we should initialize things later rather >>> than earlier. >>> >>> What's stopping doing these quirk checks later on time with just >>> a regular device driver, something like drivers/misc/bbone-quirks.c? >>> >> >> We have no choice; we are way early in the boot process, right after >> the device tree unflattening step. > > To me it seems the dt patching part should be done with minimal > code before any driver like features.. > The way it’s done right now is with minimal code. Reading the EEPROM is required. >> I’ve toyed with the idea of using early platform devices but the omap-i2c >> driver >> would need some tender love and care to make it work, and I didn’t want to >> get >> bogged down with i2c driver details at this point. > > ..so how about just parse a kernel cmdline for the quirks to apply > based on a version string or similar? That can be easily populated > by u-boot or set manually with setenv. > > That leaves out the need for tinkering with i2c super early in > the kernel for revision detection. > You assume there’s going to be a bootloader… > Regards, > > Tony Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
* Pantelis Antoniou [150219 10:32]: > > On Feb 19, 2015, at 20:16 , Tony Lindgren wrote: > > > > Uhh I don't like the idea of duplicating the i2c-omap.c driver under > > arch/arm.. And in general we should initialize things later rather > > than earlier. > > > > What's stopping doing these quirk checks later on time with just > > a regular device driver, something like drivers/misc/bbone-quirks.c? > > > > We have no choice; we are way early in the boot process, right after > the device tree unflattening step. To me it seems the dt patching part should be done with minimal code before any driver like features.. > I’ve toyed with the idea of using early platform devices but the omap-i2c > driver > would need some tender love and care to make it work, and I didn’t want to get > bogged down with i2c driver details at this point. ..so how about just parse a kernel cmdline for the quirks to apply based on a version string or similar? That can be easily populated by u-boot or set manually with setenv. That leaves out the need for tinkering with i2c super early in the kernel for revision detection. Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
* Pantelis Antoniou [150218 07:03]: > Implement DT quirks for the am33xx beaglebone boards. > --- /dev/null > +++ b/arch/arm/mach-omap2/am33xx-dt-quirks.c ... > + > +/* > + * The board IDs for am33xx board are in an I2C EEPROM > + * We are very early in the boot process so we have to > + * read the EEPROM directly without using the I2C layer. > + * > + * Note that we rely on the bootloader setting up the muxes > + * (which is the case for u-boot). > + */ > + > +/* I2C Status Register (OMAP_I2C_STAT): */ > +#define OMAP_I2C_STAT_XDR(1 << 14) /* TX Buffer draining */ > +#define OMAP_I2C_STAT_RDR(1 << 13) /* RX Buffer draining */ > +#define OMAP_I2C_STAT_BB (1 << 12) /* Bus busy */ > +#define OMAP_I2C_STAT_ROVR (1 << 11) /* Receive overrun */ > +#define OMAP_I2C_STAT_XUDF (1 << 10) /* Transmit underflow */ > +#define OMAP_I2C_STAT_AAS(1 << 9)/* Address as slave */ > +#define OMAP_I2C_STAT_BF (1 << 8)/* Bus Free */ > +#define OMAP_I2C_STAT_XRDY (1 << 4)/* Transmit data ready */ > +#define OMAP_I2C_STAT_RRDY (1 << 3)/* Receive data ready */ > +#define OMAP_I2C_STAT_ARDY (1 << 2)/* Register access ready */ > +#define OMAP_I2C_STAT_NACK (1 << 1)/* No ack interrupt enable */ > +#define OMAP_I2C_STAT_AL (1 << 0)/* Arbitration lost int ena */ ... Uhh I don't like the idea of duplicating the i2c-omap.c driver under arch/arm.. And in general we should initialize things later rather than earlier. What's stopping doing these quirk checks later on time with just a regular device driver, something like drivers/misc/bbone-quirks.c? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
Hi Tony, > On Feb 19, 2015, at 20:16 , Tony Lindgren wrote: > > * Pantelis Antoniou [150218 07:03]: >> Implement DT quirks for the am33xx beaglebone boards. >> --- /dev/null >> +++ b/arch/arm/mach-omap2/am33xx-dt-quirks.c > ... >> + >> +/* >> + * The board IDs for am33xx board are in an I2C EEPROM >> + * We are very early in the boot process so we have to >> + * read the EEPROM directly without using the I2C layer. >> + * >> + * Note that we rely on the bootloader setting up the muxes >> + * (which is the case for u-boot). >> + */ >> + >> +/* I2C Status Register (OMAP_I2C_STAT): */ >> +#define OMAP_I2C_STAT_XDR (1 << 14) /* TX Buffer draining */ >> +#define OMAP_I2C_STAT_RDR (1 << 13) /* RX Buffer draining */ >> +#define OMAP_I2C_STAT_BB(1 << 12) /* Bus busy */ >> +#define OMAP_I2C_STAT_ROVR (1 << 11) /* Receive overrun */ >> +#define OMAP_I2C_STAT_XUDF (1 << 10) /* Transmit underflow */ >> +#define OMAP_I2C_STAT_AAS (1 << 9)/* Address as slave */ >> +#define OMAP_I2C_STAT_BF(1 << 8)/* Bus Free */ >> +#define OMAP_I2C_STAT_XRDY (1 << 4)/* Transmit data ready */ >> +#define OMAP_I2C_STAT_RRDY (1 << 3)/* Receive data ready */ >> +#define OMAP_I2C_STAT_ARDY (1 << 2)/* Register access ready */ >> +#define OMAP_I2C_STAT_NACK (1 << 1)/* No ack interrupt enable */ >> +#define OMAP_I2C_STAT_AL(1 << 0)/* Arbitration lost int ena */ > ... > > Uhh I don't like the idea of duplicating the i2c-omap.c driver under > arch/arm.. And in general we should initialize things later rather > than earlier. > > What's stopping doing these quirk checks later on time with just > a regular device driver, something like drivers/misc/bbone-quirks.c? > We have no choice; we are way early in the boot process, right after the device tree unflattening step. I’ve toyed with the idea of using early platform devices but the omap-i2c driver would need some tender love and care to make it work, and I didn’t want to get bogged down with i2c driver details at this point. > Regards, > > Tony Regards — Pantelis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
Hi Tony, On Feb 19, 2015, at 20:16 , Tony Lindgren t...@atomide.com wrote: * Pantelis Antoniou pantelis.anton...@konsulko.com [150218 07:03]: Implement DT quirks for the am33xx beaglebone boards. --- /dev/null +++ b/arch/arm/mach-omap2/am33xx-dt-quirks.c ... + +/* + * The board IDs for am33xx board are in an I2C EEPROM + * We are very early in the boot process so we have to + * read the EEPROM directly without using the I2C layer. + * + * Note that we rely on the bootloader setting up the muxes + * (which is the case for u-boot). + */ + +/* I2C Status Register (OMAP_I2C_STAT): */ +#define OMAP_I2C_STAT_XDR (1 14) /* TX Buffer draining */ +#define OMAP_I2C_STAT_RDR (1 13) /* RX Buffer draining */ +#define OMAP_I2C_STAT_BB(1 12) /* Bus busy */ +#define OMAP_I2C_STAT_ROVR (1 11) /* Receive overrun */ +#define OMAP_I2C_STAT_XUDF (1 10) /* Transmit underflow */ +#define OMAP_I2C_STAT_AAS (1 9)/* Address as slave */ +#define OMAP_I2C_STAT_BF(1 8)/* Bus Free */ +#define OMAP_I2C_STAT_XRDY (1 4)/* Transmit data ready */ +#define OMAP_I2C_STAT_RRDY (1 3)/* Receive data ready */ +#define OMAP_I2C_STAT_ARDY (1 2)/* Register access ready */ +#define OMAP_I2C_STAT_NACK (1 1)/* No ack interrupt enable */ +#define OMAP_I2C_STAT_AL(1 0)/* Arbitration lost int ena */ ... Uhh I don't like the idea of duplicating the i2c-omap.c driver under arch/arm.. And in general we should initialize things later rather than earlier. What's stopping doing these quirk checks later on time with just a regular device driver, something like drivers/misc/bbone-quirks.c? We have no choice; we are way early in the boot process, right after the device tree unflattening step. I’ve toyed with the idea of using early platform devices but the omap-i2c driver would need some tender love and care to make it work, and I didn’t want to get bogged down with i2c driver details at this point. Regards, Tony Regards — Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
Hi Tony, On Feb 19, 2015, at 20:36 , Tony Lindgren t...@atomide.com wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [150219 10:32]: On Feb 19, 2015, at 20:16 , Tony Lindgren t...@atomide.com wrote: Uhh I don't like the idea of duplicating the i2c-omap.c driver under arch/arm.. And in general we should initialize things later rather than earlier. What's stopping doing these quirk checks later on time with just a regular device driver, something like drivers/misc/bbone-quirks.c? We have no choice; we are way early in the boot process, right after the device tree unflattening step. To me it seems the dt patching part should be done with minimal code before any driver like features.. The way it’s done right now is with minimal code. Reading the EEPROM is required. I’ve toyed with the idea of using early platform devices but the omap-i2c driver would need some tender love and care to make it work, and I didn’t want to get bogged down with i2c driver details at this point. ..so how about just parse a kernel cmdline for the quirks to apply based on a version string or similar? That can be easily populated by u-boot or set manually with setenv. That leaves out the need for tinkering with i2c super early in the kernel for revision detection. You assume there’s going to be a bootloader… Regards, Tony Regards — Pantelis -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
* Pantelis Antoniou pa...@antoniou-consulting.com [150219 10:32]: On Feb 19, 2015, at 20:16 , Tony Lindgren t...@atomide.com wrote: Uhh I don't like the idea of duplicating the i2c-omap.c driver under arch/arm.. And in general we should initialize things later rather than earlier. What's stopping doing these quirk checks later on time with just a regular device driver, something like drivers/misc/bbone-quirks.c? We have no choice; we are way early in the boot process, right after the device tree unflattening step. To me it seems the dt patching part should be done with minimal code before any driver like features.. I’ve toyed with the idea of using early platform devices but the omap-i2c driver would need some tender love and care to make it work, and I didn’t want to get bogged down with i2c driver details at this point. ..so how about just parse a kernel cmdline for the quirks to apply based on a version string or similar? That can be easily populated by u-boot or set manually with setenv. That leaves out the need for tinkering with i2c super early in the kernel for revision detection. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
* Pantelis Antoniou pantelis.anton...@konsulko.com [150218 07:03]: Implement DT quirks for the am33xx beaglebone boards. --- /dev/null +++ b/arch/arm/mach-omap2/am33xx-dt-quirks.c ... + +/* + * The board IDs for am33xx board are in an I2C EEPROM + * We are very early in the boot process so we have to + * read the EEPROM directly without using the I2C layer. + * + * Note that we rely on the bootloader setting up the muxes + * (which is the case for u-boot). + */ + +/* I2C Status Register (OMAP_I2C_STAT): */ +#define OMAP_I2C_STAT_XDR(1 14) /* TX Buffer draining */ +#define OMAP_I2C_STAT_RDR(1 13) /* RX Buffer draining */ +#define OMAP_I2C_STAT_BB (1 12) /* Bus busy */ +#define OMAP_I2C_STAT_ROVR (1 11) /* Receive overrun */ +#define OMAP_I2C_STAT_XUDF (1 10) /* Transmit underflow */ +#define OMAP_I2C_STAT_AAS(1 9)/* Address as slave */ +#define OMAP_I2C_STAT_BF (1 8)/* Bus Free */ +#define OMAP_I2C_STAT_XRDY (1 4)/* Transmit data ready */ +#define OMAP_I2C_STAT_RRDY (1 3)/* Receive data ready */ +#define OMAP_I2C_STAT_ARDY (1 2)/* Register access ready */ +#define OMAP_I2C_STAT_NACK (1 1)/* No ack interrupt enable */ +#define OMAP_I2C_STAT_AL (1 0)/* Arbitration lost int ena */ ... Uhh I don't like the idea of duplicating the i2c-omap.c driver under arch/arm.. And in general we should initialize things later rather than earlier. What's stopping doing these quirk checks later on time with just a regular device driver, something like drivers/misc/bbone-quirks.c? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
On Thu, Feb 19, 2015 at 10:36:00AM -0800, Tony Lindgren wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [150219 10:32]: On Feb 19, 2015, at 20:16 , Tony Lindgren t...@atomide.com wrote: Uhh I don't like the idea of duplicating the i2c-omap.c driver under arch/arm.. And in general we should initialize things later rather than earlier. What's stopping doing these quirk checks later on time with just a regular device driver, something like drivers/misc/bbone-quirks.c? We have no choice; we are way early in the boot process, right after the device tree unflattening step. To me it seems the dt patching part should be done with minimal code before any driver like features.. I’ve toyed with the idea of using early platform devices but the omap-i2c driver would need some tender love and care to make it work, and I didn’t want to get bogged down with i2c driver details at this point. ..so how about just parse a kernel cmdline for the quirks to apply based on a version string or similar? That can be easily populated by u-boot or set manually with setenv. That would not work for my use case. Again, this is a CPU card plugged into a carrier card, of which there are several variants. The CPU card is similar to a Com Express card (not exactly the same, but the same idea), so it may even be manufactured by a third party. Actually, in some cases it is. Modifying the kernel command line based on the carrier card it is connected to is simply not possible. Guenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
Implement DT quirks for the am33xx beaglebone boards.
A single boot DTB supports both the beaglebone white and the beaglebone
black, and on boot time the identifying EEPROM is read and the info
is used to modify the live tree to match the board detected.
Refer to Documentation/devicetree/bindings/quirks/am33xx-bone-quirk.txt
for detailed information.
Signed-off-by: Pantelis Antoniou
---
.../bindings/quirks/am33xx-bone-quirk.txt | 82
arch/arm/mach-omap2/Makefile | 5 +
arch/arm/mach-omap2/am33xx-dt-quirks.c | 498 +
arch/arm/mach-omap2/am33xx-dt-quirks.h | 10 +
arch/arm/mach-omap2/board-generic.c| 1 +
arch/arm/mach-omap2/common.h | 8 +
6 files changed, 604 insertions(+)
create mode 100644
Documentation/devicetree/bindings/quirks/am33xx-bone-quirk.txt
create mode 100644 arch/arm/mach-omap2/am33xx-dt-quirks.c
create mode 100644 arch/arm/mach-omap2/am33xx-dt-quirks.h
diff --git a/Documentation/devicetree/bindings/quirks/am33xx-bone-quirk.txt
b/Documentation/devicetree/bindings/quirks/am33xx-bone-quirk.txt
new file mode 100644
index 000..239dd8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/quirks/am33xx-bone-quirk.txt
@@ -0,0 +1,82 @@
+am33xx Beaglebone White/Black Device Tree Bindings
+--
+
+Beaglebone boards that boot with a common device tree blob contain
+a DT quirk entry with the following properties:
+
+Required properties:
+
+- compatible : should be "ti,am33xx-bone-quirk"
+
+Required child node:
+
+- revs : Contains children nodes that identify boards
+
+ Each child node of revs must be of the following form:
+
+ Required properties:
+
+ - board-id : Contain the board ID as it appears in the EEPROM
+ - board-apply : Should contain the phandle of the quirk to apply
+
+ Optional child node:
+
+ - options : Contain a number of properties that identify options
+ that can be enabled or disabled by external means. For Linux the
+ options are selected by parsing the boot command line.
+ The properties contain a tupple of quirk phandles, the first containing
+ the enable quirk and the second the disable quirk. If the phandle is zero
+ then no quirk is applied.
+
+Any other nodes (like the quirk definitions are ignored).
+
+The following example defines two revisions (white/black) with
+board-id A335BONE for the white and A335BNLT for the black.
+For the beaglebone black we also define two options
+no-emmc and no-hdmi which when are present in the boot command line
+the emmc and hdmi are disabled.
+
+ beaglebone-quirks {
+ compatible = "ti,am33xx-bone-quirk";
+ status = "okay";
+
+ revs {
+ white {
+ board-id = "A335BONE";
+ board-apply = <>;
+ };
+ black {
+ board-id = "A335BNLT";
+ board-apply = <>;
+ options {
+ no-emmc = <0 _enable_emmc>;
+ no-hdmi = <0 _enable_hdmi>;
+ };
+ };
+ };
+
+ overlays {
+ bonewhite: bonewhite {
+ /* quirk for white */
+ ...
+ };
+
+ boneblack: boneblack {
+ /* quirk for black */
+ ...
+ };
+
+ black_enable_hdmi: black_hdmi {
+ /* quirk to enable hdmi */
+ ...
+ };
+
+ black_enable_emmc: black_emmc {
+ /* quirk to enable emmc */
+ ...
+ };
+ };
+ };
+
+
+
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d27dfd..02129e7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -259,6 +259,11 @@ obj-$(CONFIG_MACH_CRANEBOARD) +=
board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
+# DT quirks
+ifneq ($(CONFIG_OF_DYNAMIC),)
+obj-$(CONFIG_SOC_AM33XX) += am33xx-dt-quirks.o
+endif
+
# Platform specific device init code
omap-flash-$(CONFIG_MTD_NAND_OMAP2):= board-flash.o
diff --git a/arch/arm/mach-omap2/am33xx-dt-quirks.c
b/arch/arm/mach-omap2/am33xx-dt-quirks.c
new file mode 100644
index 000..668235c
--- /dev/null
+++ b/arch/arm/mach-omap2/am33xx-dt-quirks.c
@@ -0,0 +1,498 @@
+/*
+ * arch/arm/mach-omap2/am33xx-dt-quirks.c
+ *
+ * AM33xx variant DT quirks
+ *
+ * Copyright (C) 2015 Konsulko Group
+ *
+ * Author:
[PATCH 3/4] arm: am33xx: DT quirks for am33xx based beaglebone variants
Implement DT quirks for the am33xx beaglebone boards.
A single boot DTB supports both the beaglebone white and the beaglebone
black, and on boot time the identifying EEPROM is read and the info
is used to modify the live tree to match the board detected.
Refer to Documentation/devicetree/bindings/quirks/am33xx-bone-quirk.txt
for detailed information.
Signed-off-by: Pantelis Antoniou pantelis.anton...@konsulko.com
---
.../bindings/quirks/am33xx-bone-quirk.txt | 82
arch/arm/mach-omap2/Makefile | 5 +
arch/arm/mach-omap2/am33xx-dt-quirks.c | 498 +
arch/arm/mach-omap2/am33xx-dt-quirks.h | 10 +
arch/arm/mach-omap2/board-generic.c| 1 +
arch/arm/mach-omap2/common.h | 8 +
6 files changed, 604 insertions(+)
create mode 100644
Documentation/devicetree/bindings/quirks/am33xx-bone-quirk.txt
create mode 100644 arch/arm/mach-omap2/am33xx-dt-quirks.c
create mode 100644 arch/arm/mach-omap2/am33xx-dt-quirks.h
diff --git a/Documentation/devicetree/bindings/quirks/am33xx-bone-quirk.txt
b/Documentation/devicetree/bindings/quirks/am33xx-bone-quirk.txt
new file mode 100644
index 000..239dd8d
--- /dev/null
+++ b/Documentation/devicetree/bindings/quirks/am33xx-bone-quirk.txt
@@ -0,0 +1,82 @@
+am33xx Beaglebone White/Black Device Tree Bindings
+--
+
+Beaglebone boards that boot with a common device tree blob contain
+a DT quirk entry with the following properties:
+
+Required properties:
+
+- compatible : should be ti,am33xx-bone-quirk
+
+Required child node:
+
+- revs : Contains children nodes that identify boards
+
+ Each child node of revs must be of the following form:
+
+ Required properties:
+
+ - board-id : Contain the board ID as it appears in the EEPROM
+ - board-apply : Should contain the phandle of the quirk to apply
+
+ Optional child node:
+
+ - options : Contain a number of properties that identify options
+ that can be enabled or disabled by external means. For Linux the
+ options are selected by parsing the boot command line.
+ The properties contain a tupple of quirk phandles, the first containing
+ the enable quirk and the second the disable quirk. If the phandle is zero
+ then no quirk is applied.
+
+Any other nodes (like the quirk definitions are ignored).
+
+The following example defines two revisions (white/black) with
+board-id A335BONE for the white and A335BNLT for the black.
+For the beaglebone black we also define two options
+no-emmc and no-hdmi which when are present in the boot command line
+the emmc and hdmi are disabled.
+
+ beaglebone-quirks {
+ compatible = ti,am33xx-bone-quirk;
+ status = okay;
+
+ revs {
+ white {
+ board-id = A335BONE;
+ board-apply = bonewhite;
+ };
+ black {
+ board-id = A335BNLT;
+ board-apply = boneblack;
+ options {
+ no-emmc = 0 black_enable_emmc;
+ no-hdmi = 0 black_enable_hdmi;
+ };
+ };
+ };
+
+ overlays {
+ bonewhite: bonewhite {
+ /* quirk for white */
+ ...
+ };
+
+ boneblack: boneblack {
+ /* quirk for black */
+ ...
+ };
+
+ black_enable_hdmi: black_hdmi {
+ /* quirk to enable hdmi */
+ ...
+ };
+
+ black_enable_emmc: black_emmc {
+ /* quirk to enable emmc */
+ ...
+ };
+ };
+ };
+
+
+
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 5d27dfd..02129e7 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -259,6 +259,11 @@ obj-$(CONFIG_MACH_CRANEBOARD) +=
board-am3517crane.o
obj-$(CONFIG_MACH_SBC3530) += board-omap3stalker.o
+# DT quirks
+ifneq ($(CONFIG_OF_DYNAMIC),)
+obj-$(CONFIG_SOC_AM33XX) += am33xx-dt-quirks.o
+endif
+
# Platform specific device init code
omap-flash-$(CONFIG_MTD_NAND_OMAP2):= board-flash.o
diff --git a/arch/arm/mach-omap2/am33xx-dt-quirks.c
b/arch/arm/mach-omap2/am33xx-dt-quirks.c
new file mode 100644
index 000..668235c
--- /dev/null
+++ b/arch/arm/mach-omap2/am33xx-dt-quirks.c
@@ -0,0 +1,498 @@
+/*
+ * arch/arm/mach-omap2/am33xx-dt-quirks.c
+ *
+ * AM33xx variant DT quirks
+ *
+ * Copyright
